Indeed, it may well be that using the visible machine as the fax server is the optimal configuration in a cluster in which the system bus is limited to a 10 Mbps shared ethernet hub. As discussed in more detail in other parts of this document, one initial concern I envision is the potential saturation of that hub as cluster use increases. There are elements of the system for which communication over that hub is an absolute pre-requisite for the cluster to serve its intended functionality. Moving fax jobs between the controller and one of the cluster machines could represent a significant enough load to constrain the cluster, especially when the faxes come in large batches. At this point, however, all of this is hypothetical, and part of the rationale for doing this in the first place is to evaluate the interlocking factors that are likely to determine functional capacity under given sets of circumstances.
Hardware and System Software
I consider the first step in setting up a hylafax server to be connecting a modem to the box that will house the server, and to make sure that the box and the modem can talk to each other. I've stated before my preference for external modems in this regard, if for no other reason than you will generally have fewer factors to consider when trying to debug connection problems. The easiest way to check the modem's configuration is to fire up a communications program and try to get the modem to dial. Perhaps betraying my roots, I like to use minicom, a procomm clone for linux. If you use an external modem, most of the time you will find the modem located on ttys0 (the first serial port) or ttys1 (the second). (Actually, these are the device files that communicate with the serial port, rather than the port itself, which is why I said most of the time. You may run into a machine/distribution combination that will have the ports identified as cua0 and cua1. These are simpler versions of the device files that will not block the port when it has been dialed from outside. They are considered deprecated, but if that's all you can get to work they will work with hylafax, relying on hylafax itself to block the port.) Unfortunately, on some machines the top serial connection is the first port and others it is the second, and if the serial connections are on-board and you don't have the manuals (which could easily be the case with surplus hardware) the quickest way to find out which is which would be to simply connect the modem to a port and try to access it through both device files. If neither works move to the other port ... on surplus machines it would not be a surprise to get a machine with a bad port. If neither file works on that port, re-start the machine and go into the bios setup to make sure that the serial ports have not been disabled. If both ports are enabled, you might want to look around to see if you can spot the cua device files, but first I would cart the modem over to a machine on which I knew the serial ports were working, and make sure the modem itself worked.
Installing and Configuring Hylafax
In any event, once you know what port the modem is on and what device file to use to access it you can launch into setting up the hylafax configuration on the server. On debian, there are two ways to set the server up ... to install from the deb package or to build the software itself. In each case, there will be some customization involved before you can get it to work, which stems from the software's origin at Silicon Graphics and the somewhat different structure of their version of unix. Silicon Graphics did us a favor by making the software freely available, but you will have to customize some elements to get it to work for you. Luckily for you, I've already done that, and that's part of what I'm here to tell you. (You can't see me, but I'm sitting back in my chair and preening.) If you install from the deb you will have less control over where files are located, and while you can adjust for that by using startup parameters I've run into a couple of contexts in which it did not seem possible to do that. So it is probably preferable to build the package.
Amusing Anecdote: In the course of figuring out what is going on with hylafax, I've built it perhaps three times. The first couple of times were during my initial construction phase, and the build took quite some time, as I recall several hours. The last time was after I had the mosix cluster going, and I realized the full level of customization required of the hylafax files. I started the build going, then went off to do something else. I came back perhaps half an hour later, looked back at Ralphzilla, and noticed that the lights on the hub were going crazy. I had been deeply inside the hylafax configuration mentally, not really thinking about the fact that the mosix functionality was enabled, and there the darn thing was running. I started mosixview and watched the cluster controller shift the build process around the machines in the cluster for a bit, and then it was done, apparently, but not really, because the threads of the build process that had been sent to other machines continued to execute for several minutes before everything died out. I realized that in this context it's wise to wait for several minutes after a make before running make install. Just thought you'd enjoy that. End Anecdote
To successfully build Hylafax you need to download the source, extract it, and then modify the configure file for the build process. I've included the edited version of that file here. You'll also have to install tools for dealing with tiff files and the zlib compression routines. (This is the kind of thing that the debian dependency system and the apt-get tools handle for you. But it's also a good idea to know a bit of what is going on behind the scenes, both from the standpoint of the application and the system as a whole. For example, since the location of the fax directory for hylafax is specified in the configure process, if you install the packaged binary you'll have to use the default location for the fax spool directory. It might be possible to use a link to that directory ... I've not tried that, because I just built the package for myself. These kinds of considerations are part and parcel of the process of configuring a well-running system. Sometimes you'll figure out a tweak that will make your system run better some months down the road. Don't worry about it, that's the way it works. To return to a refrain that will become common in this document, anyone who says that they can anticipate everything that will happen during the development of a system with several interlocking parts like this is lying to you. And we all know the world is full of those. The key is to remain flexible. If you have a working version of the cluster and decide to reconfigure the software on the server, pull out another box and go for it, moving the new box in as the controller when you are done.) The zlib compression routines are contained in the file zlib1g-dev, which you can install with the command "apt-get install zlib1g-dev". The tiff libraries are contained in the file libtiff3g-dev, but you will also need some binaries that are not included in the library. You'll have to download the gzipped source here, extract and build it (./configure, make, make install ... you know the routine. if you have any questions, read the README file included in the extracted directory.) You can save the configure file I use for hylafax and copy it over the configure file in the root directory of the hylafax source if you wish, but recognize that you are going to want to customize the value of the DIR_SPOOL variable (line 45), and that I make no guarantees of fitness and all that other good lawyerly stuff. It you use it, don't blame me if you machine melts and swarms of killer silicon insects come out of the mass and devour the city in which you live. It's not my fault. Anyway, once the configure file is customized as appropriate for your machine, just type "./configure" while you're in that directory, and once that is done, run make and go off and do something else for awhile. When the make process completes you can run "make install", and you should be done with the setup, except you're not. You'll still need to modify the faxsetup script as I discuss below, although perhaps not as extensively.
If you wish to install from the deb file, of course, all you need to do is run "apt-get install hylafax-server", and the debian package management tools will install the requisite files. As I said, when I was trying to get the hang of Hylafax, and figure out what was wrong with what I was doing, I noted that there were some scripts that did not seem to accept certain parameters from the command line. Specifically, Hylafax is built with the spool directory specified in the configure file. To an extent you can specify that directory from the command line, but once I figured out that I needed to edit the configure file I didn't wait to find out whether a well-running server could be configured that way. I felt more comfortable being able to have the program know where I was putting things and where it should put things. YMMV, and all that, you can pursue whatever course you wish. Whichever course you do pursue, you will need to edit the faxserver script that creates the files that Hylafax uses when the server starts. If you've installed the standard woody set of packages the version here should work for you, again subject to my warning about the killer silicon insects. Copy it into the /usr/sbin directory as faxsetup, replacing the default installed by Hylafax. Specifically, the script needs to reflect the Debian location of system directories as well as the location of the ghostscript files that Hylafax uses to render fax documents. The following table summarizes the changes that need to be made:
| Line 82 - PATH_AFM | Location of ghostscript files ... default debian is /usr/share/ghostscript:/usr/share/gs/6.51:/usr/lib/ghostscript/fonts:/usr/local/lib/ghostscript/fonts |
| Line 69 - INETDCONF | /etc/inetd.conf |
| Line 84 - DIR_LIBDATA | /etc/hylafax |
| Line 85 - DIR_LIBEXEC | /usr/bin |
| Line 89 = DIR_SPOOL | Where you are locating the spool ... Debian creates /var/spool/fax |
Starting the Hylafax Server
Logically enough, configuring the Hylafax software to act as a server consists of three basic steps:
1: start the fax queueing service
2: attach the modem(s) to be used to that service
3: start the fax server, listening on a given port.
If you are going to receive faxes as well as send them, you need to start a service on the machine that will listen on the specified port to respond to incoming calls. The following line, added to the inittab file in the /etc directory, starts such a service on the ttyS0 device: "t2:23:respawn:/usr/sbin/faxgetty ttyS0". (For those not familiar with linux, if you were to research just what this action represents in Debian you will learn a good bit about what happens when a linux machine starts. Come to think of it, I'll just assign that as homework ...) If you make the change, restart the machine, and execute "ps ax" you should show that service running. Although my intent is to configure this machine primarily for outgoing faxes, I've decided that an interesting enhancement will be to work on routing incoming faxes to email addresses, so I've started the service. If you have any question about whether you should as well, just go ahead and do it. It's not likely to be a big deal one way or another. If you don't add it and decide you want to receive incoming faxes later on you can add it then, and if you do add it and don't use it the worst that will happen is that the modem will pick up on wrong numbers.
To start the fax queueing service, just issue the command "/usr/sbin/faxq" (actually, just facq should work. The directory /usr/sbin should be in your path environment variable). Once the service starts, you attach a modem to it by using "faxmodem devicename", in this case "faxmodem ttyS0". In effect, this tells the faxq service that when it has a job in the queue, it can use ttyS0 to send it out. If I were connecting a modem to the second serial port and using it as well I could at this point say "faxmodem ttyS1", and as a result the faxq service would recognize that it has a second modem at its disposal. The actual fax server, which accepts incoming jobs from clients, is represented by the hfaxd daemon. To start the service in its most common configuration, use "hfaxd -i 4559". This starts hfaxd using a client-server protocol and listening on port 4559.
Automating the Server Startup
Once you've started the server manually and know that all of the pieces are working, you'll probably want to get it to start when the system starts. (While it is possible to start the services through the use of the inetd daemon, there will be some overhead involved as inetd calls the script that starts the serivces, while if you load the services at system startup
they'll be there ready to go. If you were to be using Hylafax as an on-board fax service on a workstation, you might want to start it from inetd, but I think the slight increase in system resources consumed from leaving faxq and hfaxd loaded are likely to be offset by reduced throughput. Anyway, to get something to load during the boot of most linux distributions you configure a script loading the package daemons and put the script where it will be called by the init process. The script I use, fax.sh, consists of nothing more than the three commands "faxq"," faxmodem ttyS0", and "hfaxd -i 4559" on separate lines and in order. To add the script to the scripts being called by init, you put it in the /etc/init.d directory. To have the script configured with the default Debain configuration for standard services you then issue the command "update-rc.d fax.sh defaults". It is possible to issue the command to configure a service with runlevels other than the default values for runlevels and sequence code, if you are interested in that you should check the man page for the command. Once you've done this you can restart the machine and the hylafax server will be operational upon boot.
Configuring client access and Software clients
The ability of a client to access the hylafax server is determined by the records in the hylafax hosts file, which exists in the etc subdirectory of the fax spool directory. In a default hylafax configuration this would be /var/spool/fax/etc/hosts. If that file doesn't exist, access is allowed from any user from any address. Using the hosts file, access can be limited to one machine or sets of machines and users. That is, access can be limited so Ralph can access the fax server from one machine, but not from any others, and that access can be password-protected.
There are a number of clients available for hylafax for a number of platforms. I've tested my setup with whfc, a win32 client available from here. This is a fairly straightforward fax client, not very difficult to configure as long as a working server is available and you don't wig out when the dialogues turn from English into German (grin). It is, however, oriented around the use of phone books for sending a large number of faxes, and it is not apparent how to use the client from within an application to send faxes to numbers specified from within the program. There are other clients that appear to be better configured for such use. Evaluating them is on my to do list.