Introduction

The firm I work for had a fax system integrated in the corporate e-mail platform, Microsoft Exchange, for sending and receiving. One day after a software upgrade, the system broke. We needed to find something with the equivalent functionality but with the following conditions:

• Minimum cost, or better still, no cost at all, especially regarding software licenses.
• Transparent integration with the end user's software tools (basically Microsoft Office).
• No need to install any software on the client side, even free software, in order to minimize the work load of the network administrators.

This article describes how the integration of several open source applications on a Linux platform has fulfilled all of these conditions.

Acknowledgments

I want to express my gratitude to various persons or organizations without whose assistant I would have never written this article. First, to the members of the IT department in the Solvay Química S. L. plant at Torrelavega, Spain. Second, to my firm's hierarchy for their approval and support of this article's writing. Last and most especially, to all the contributors to the Open Source projects mentioned throughout this text, to the participants in the HylaFAX mailing list (which have given me essential information) and to Craig Kelly, developer of the smbfax client tool.

System overview

To clarify which computer I'm talking about where, I'll refer to the PC where the fax software is installed as TOSERFAX.

The applied solution involves the HylaFAX software. This application controls the installed modems, distributes the incoming faxes and sends the outgoing ones.

The incoming faxes are converted to PDF format and forwarded via SMTP e-mail to their respective destinations. PDF was chosen because Acrobat Reader is part of the standard software platform at the site. The destination is ascertained via certain rules as will be later explained.

If someone wants to send a fax, he prints the document in a printer queue on TOSERFAX, which Samba makes visible to all the other computers. The print job will cause an e-mail to be sent to the user that has spooled the job. This e-mail includes the URL of a web form created on-the-fly in the Apache web server. The web form allows the user to fill in the fax details, particularly the destination phone number. Once the user has completed the form, upon clicking on the "Send" button, the fax is finally put on the outgoing queue.

Hardware and Software

TOSERFAX's hardware is the following:

• PC Dell Optiplex GX150, running a 1 Ghz Pentium III processor, with 256 MB of RAM and a hard disk of 20 GB. The modems are 3Com US Robotics 56K Faxmodem.

   

As far as software is concerned:

• The base system is the SuSE Linux 7.2 distribution. It includes HylaFAX version 4.1beta2, the Apache web server version 1.3.19 and the SMTP server sendmail version 8.11.3.
• Samba version 2.2.3a.
• Fax sending from the clients is implemented using the package smbfax, version 1.4.

HylaFAX installation and configuration

The installation of HylaFAX was carried out following the standard procedures, clearly explained in the documentation. The most delicate part is the modem configuration. HylaFAX does not include a template for the US Robotics 56K Faxmodem. However, a search in its mailing list provided the needed information, which resulted in the file /var/spool/fax/etc/config.ttyS0 (and config.ttyS1 for the second modem). The first of these files can be found here.

Receiving faxes

Our plant has several telephone numbers that are connected to fax machines. The telephone exchange can divert phone calls originally made to one extension to a different one. This feature makes it possible to centralize the reception of all faxes in TOSERFAX without any change in the phone numbers that are accessible to the public.

For example, suppose the Purchasing Department has 5550001 as fax number, while Logistics has 5550002. One of TOSERFAX's modems is connected to the internal extension 1700. The PBX diverts all incoming calls to 5550001 and 5550002 to the extension 1700, where TOSERFAX receives the fax.

But or course, the person that should receive the faxes to Purchasing is not the same one that should get the ones to Logistics. HylaFAX manages incoming faxes by way of the scripts faxrcvd and FaxDispatch, placed in /var/spool/fax/bin. The discrimination we want requires knowledge of the fax number the fax was originally sent to, which is not known in the standard version of faxrcvd. A workaround is to recover that number from the session log, assigning it to a variable, for instance TOPHONE.

	TOPHONE=$($AWK '/SESSION BEGIN/ {print $NF; exit}' log/c${COMMID})

The new versions of faxrcvd and FaxDispatch can be found here and here.

The standard version of faxrcvd sends the fax to the addressee as a postscript attachment in an e-mail. This is not the best option at my plant, as the standard PC does not include a postscript viewer. But it does include a PDF viewer, and postscript files can be converted to PDF.

However, here we run into a small problem, related to the sending of the e-mail message with the attached file. TOSERFAX uses as SMTP relay a Windows NT server running IIS version 4. For some reason that I have not been able to discover, this server could not distribute the e-mails with attachments created with faxrcvd.

The solution was to use the tool "metasend", included in the packages metamail 2.7.19. The scripts metasend.sh and tiff2pdf.sh succeed in sending the fax, previously transformed into PDF format, in a way that is acceptable for the SMTP relay. It is worth mentioning that these scripts invoke the tools tiff2ps and gs.

Sending faxes

There are several fax clients written to be used with HylaFAX, for multiple platforms. However, IT administrators at Torrelavega would rather avoid any software installation on the clients. The only operation at the site's PCs should be, at the most, the configuration of a network printer, and it should be made automatically by the end user himself, if possible.

Using a printer queue has the added advantage that any application that is able to print a document (that is, practically all applications) will be able to fax. In this respect, the fax solution described in this article is clearly superior to other proprietary systems installed in Microsoft Exchange, which only allow to send faxes generated by some applications, for instance those in the Microsoft Office suite.

The package smbfax, developed by Craig Kelly, fulfills the above mentioned requirement. The underlying idea is very clever: the client prints the document he wants to fax in a printer queue, configured in TOSERFAX with Samba, and which features a postscript printer. The printing provokes in fact the execution of a perl script, which puts the printed document into a file and sends the client an e-mail with an URL in it. This URL is a link to a web form created on the fly in the web server at TOSERFAX (Apache). The client clicks on the URL, fires the browser and, using the web form, fills in the number or numbers the fax should be sent to, chooses whether a cover page should be added, and other details. Finally, upon clicking on the "Send" button, the fax is put in the outbound queue. In case there is any error processing the job, the client will equally be notified by e-mail. Obviously, this system requires knowing the identity of the user who is faxing (it must be possible to get the authentication credentials he have acquired upon logging in the Windows PC) as well as his e-mail address.

The installation of smbfax is straightforward. The package documentation clearly explains the different steps, and repeating them here would just be redundant.

Configuring Samba, on the other hand, does show some interesting tricks. The pertinent file can be seen here. The following lines must be emphasized:

[global]
	workgroup = DOM
	netbios name = TOSERFAX
	security = DOMAIN
	winbind uid = 10000-20000
	winbind gid = 10000-20000
	template homedir = /home/win/%D/%U
	winbind separator = +
	printer admin = @DOM+PRINTADMIN
	...

[print$]
	path = /etc/samba/printers/
	browseable = yes
	read only = yes
	write list = @DOM+PRINTADMIN,root

# The fax queue is configured in this section 
[fax]
	comment = Fax queue
	path = /tmp
	printable = Yes
	writable = no
	create mode = 0700
	guest ok = no
	postscript = Yes
	printing = lprng
	print command = /usr/local/smbfax/smbfax -r queue %u %s
	lpq command = /usr/local/smbfax/smbfax show
	lprm command = /usr/local/smbfax/smbfax dequeue %j

As a Samba server, TOSERFAX is included in a Windows 2000 domain (Active Directory). Samba version 2.2.3 features support for "winbindd", which provides client authentication based on the credentials obtained upon starting a session in the domain. As a consequence, to create the Windows users in the Linux box is no longer needed. Each client that connects for the first time to the Samba server will be identified by the combination <Domain name>+<User name>, and will earn an "uid" in the range 10000 - 20000. Inside the [fax] section, the line

	print command = /usr/local/smbfax/smbfax -r queue %u %s

invokes the program smbfax passing in the parameter %u the name of the user, identified as previously explained.

Inside the [global] section, the line

	printer admin = @DOM+PRINTADMIN

gives administrative rights on the printer queues to all members of the PRINTADMIN group in the NT domain DOM. These users will be able to configure printers, install drivers (for different Windows versions) and grant printing rights to the domain users by means of the standard remote administrative tools which are present in an NT or Windows 2000 box, and that use Remote Procedure Calls (RPC). And all this in a transparent way, without being aware that the printer server is not really a Windows box, but a Linux one.

The members of the DOM+PRINTADMIN group must of course have been granted write access to the path /etc/samba/printers. This is achieved by establishing the necessary permissions in the Linux filesystem:

       $ chown -R DOM+PROWNER:DOM+PRINTADMIN /etc/samba/printers
       $ chmod 0775 /etc/samba/printers

Driver installation is an especially interesting feature. It is possible to install at TOSERFAX the drivers of a postscript printer for all Windows versions that are used at the site: 95, NT and 2000. Once this work is done, any client that connects to the printer queue for the first time will be able to auto-install the needed drivers. We achieve therefore one of the goals of the network administrators: no configuration work needed on the client side.

Additionally, any member of the PRINTADMIN group may restrict access to the printer queue, using the NT access control lists (ACL).

The only question still unanswered is how to reach by e-mail the users that want to send a fax. Thanks to winbindd the user has been authenticated, but, which is the e-mail account? Lacking a way to read this information from the Active Directory, maybe using OpenLDAP, the solution is to manually add to the "aliases" file the list of possible fax users, with their e-mail addresses

	DOM+User1:	This email address is being protected from spambots. You need JavaScript enabled to view it.
	DOM+User2:	This email address is being protected from spambots. You need JavaScript enabled to view it.

and so on. Execute "newaliases" and the system is ready.

System maintenance

Once each and every component is configured, the last thing to do is to automate some basic housekeeping tasks. This is easily fulfilled adding to /etc/crontab the following lines:

0 21 * * * root test -x /usr/sbin/faxqclean && /usr/sbin/faxqclean

25 23 * * * root test -e /usr/sbin/faxcron && sh /usr/sbin/faxcron | mail faxmaster

Beware though that the HylaFAX package included in SuSE 7.2 leaves faxcron in /etc/cron.daily. Therefore, you will have to move it to apply the proposed scheme.

Conclusion

The combination of HylaFAX, Samba, smbfax and other open-source packages on a Linux system has allowed to integrate an efficient centralized fax service in a Windows environment, realizing the expectations of the IT managers, especially the lack of additional software installation on the client side.

 

Pedro Fraile

I first met a computer around 1982, and unless my memory deceives me, it was a Z 80 model. I discovered Linux in 1998, and very soon this OS took hold of my domestic PCs. Computers and programming are among my favorite hobbies.