Difference between revisions of "Handbook:Basic Server Configuration:Client Access"

HylaFAX client applications such as sendfax do not communicate directly with server processes such as faxq or faxgetty. Instead they communicate with the hfaxd(1M) client-server protocol process. This architecture insulates client applications from the internal structure of a server machine, provides a more robust operating environment, and scales better for many clients.

hfaxd is normally started up when the faxsetup program is run. faxsetup also arranges for hfaxd to be automatically started up each time a server machine is booted; either standalone by a script invoked by the init process or indirectly by the inetd process. The preferred way to run hfaxd is in a standalone mode as this gives optimal performance.

When hfaxd is started the command line arguments specify which of several client-server protocols it should offer. hfaxd currently has support for three protocols:

• the Version 4.0 HylaFAX™ client-server protocol,
• the old HylaFAX™ client-server protocol used in versions prior to 4.0, and
• the Simple Network Pager Protocol (SNPP) that is used to submit alpha-numeric text pager requests.

When operating in a standalone fashion the command line options specify the protocols to support and the ports at which service should be provided. For example, to startup hfaxd in a standalone mode supporting all three protocols the following might be used:

hyla# /usr/local/sbin/hfaxd -i 4559 -o 4557 -s 444 

This specifies that the Version 4.0 protocol is to be offered at port 4559, the old protocol at port 4557, and SNPP at port 444.

It is also possible to have the inetd program startup hfaxd. In this case only a single protocol can be requested since inetd advertises service and establishes the network connection. For example, the following entry might be used in the inetd.conf file to startup hfaxd to service SNPP requests:

snpp stream tcp nowait fax /usr/local/sbin/hfaxd hfaxd -S -d 

The -S option specifies that hfaxd should service SNPP requests using the standard input and output descriptors and the -d option keeps hfaxd from detaching itself from the controlling tty.

It is possible to run hfaxd in a standalone mode as well as indirectly from inetd so long as this is done for separate protocols. Doing this however is of questionable value since it is much more efficient for a single standalone hfaxd process to support multiple protocols than to have multiple unrelated hfaxd processes.

Beware that hfaxd must either be started up by the super-user or be installed setuid-root for proper operation.

Besides arranging for hfaxd to get started up when a server machine is booted, it is necessary to specify which client machines and users can have access to a HylaFAX™ server machine. This is specified by the contents of the etc/hosts.hfaxd file in the HylaFAX spooling area on the server machine. The contents of this file is specified in the hosts.hfaxd(5F) manual page. The default etc/hosts.hfaxd file that comes with HylaFAX permits anyone to have access through the localhost network interface; i.e. the hosts file contains:

localhost
127.0.0.1

It is a good idea to refine the controls specified in this file before providing general access to the server. Access can be restricted both on a per-client-machine basis and by user. Passwords can also be required though support for this is presently somewhat awkward. The etc/hosts.hfaxd file must be owned by the fax user and be mode 0600 or hfaxd will not permit client access.

Note: the 192.168.1. format does NOT seem to work. If you use this format, you will have to list all the valid addresses (ie. 192.168.1.101, 192.168.1.102, ad nauseum)