Faxing is one of the world's great business constants. This ubiquitous technology has changed the world and can be found in any office and a number of homes around the world. Even when we don't have dedicated fax machines, we use PC or network-based faxing. Putting a fax modem on every PC in your organization doesn't just sound ridiculous—it is. Might I then humbly recommend a great fax solution, free of charge, combined with the dependability of Linux? Wonderful!
While deciding on how to present this article, I thought about all the great free software available for Linux. Your Linux distribution CD contains thousands of such programs. The catch is that not all of them are pretty—extremely functional, but not pretty. Windows users still shudder at the thought of the dreaded command line. So how do we, Linux gurus all, protect them and impress them with the power of our Linux servers? I can hear some of you saying “We don't!”, but seriously, Windows is still out there and will be for some time. Convincing users from the Windows world that hidden behind the command-line interface is a product that will satisfy their needs is sometimes difficult, even when it's something as simple and useful as free network faxing for the office.
As developers and supporters of what will invariably become the next great operating system, both as server and on the desktop, we can ease the confusion of the terrifying command line by wrapping the solutions we offer in friendly, easy-to-use interfaces. My solution often involves hiding the magic of the command line behind a friendly web-style interface. After all, everybody loves their browser—http://www.allplaynowork.com/, anyone?
I will show you how to create an integrated fax solution for your Windows 9x users to make faxing as easy as printing. Using the web-based administration tools, you can then off-load some of the responsibility for watching all those faxes go through to your users.
At the end of the article is a URL link from which you can download the full distribution for MultiFax. Find yourself a nice comfy chair, and we'll begin.
Well, luckily, not much. You should take a moment and think about this one, though. Will you be using your fax modem as a permanent fax solution, or will you be sharing the fax modem with a dial-on-demand PPP connection? The answer will define whether you can use your current fax modem, or whether you should consider adding another to your system. In my case, I use the same connection for Internet access as for faxes. When I need to pick up a fax (or send one out), I simply take down my Internet connection (by killing my diald process), and start a single process for the fax. In a busy office, that may not be such a hot idea.
Gert Doering's mgetty+sendfax is a relatively easy-to-use fax solution for the office, that is, if you're a command-line-savvy Linux user. The great thing is that it comes with your Linux distribution. Red Hat's package includes it as one of the default choices during installation. I checked my SuSE distribution as well as a Caldera CD and they all had it, so finding it should not be a problem. The latest version of mgetty+sendfax is always available at metalab.unc.edu (formerly sunsite.unc.edu) under the pub/Linux/system/serial/getty directory.
Combined with Horst F.'s respond utility for Windows, it provides a rugged and easy-to-use fax mechanism from the Windows desktop. Horst's utility, which lives on your task bar as a tray icon, appears as a fill-in form whenever a user submits a fax to the queue. You enter the destination name and phone number, click OK, and off go your faxes. You can get the respond program at www.boerde.de/~horstfhttp://www.boerde.de/~horstf. While there, make sure you pick up the accompanying printfax.pl Perl script and the recommended smb.conf entry for Samba.
Create a directory on your Windows PCs (or in a shared drive on the network) and copy RESPOND.EXE there. On my office PCs, I put everything communications-related in a directory called C:\COMM. Then I have subdirectories for my applications. RESPOND.EXE lives in C:\COMM\FAX. It doesn't really matter where it lives, so long as you know where you've put it.
Once the mgetty+sendfax package is installed on your Linux system (whether with an RPM install or compiled from source), you will need to set up some basic configurations before moving on. On my Red Hat 5.2 system, most of these live in the /etc/mgetty+sendfax directory. Your distribution or install may put them in a different place.
You can get a lot of detail from the mgetty+sendfax FAQ on setting things up, but if you're in a hurry to get faxes moving, here are some of the basics. The config files I took the time to set up are named sendfax.config, mgetty.config, faxrunq.config and faxheader.
In the sendfax.config file, I set up the following parameters:
fax-devices ttyS1 fax-id 955-555-5555 ignore-carrier y
There are other settings, but I was also in a hurry. Since we have only one fax modem, I set up ttyS1 as my fax-devices entry. The fax-id is the phone number your fax modem announces to the other fax machine. The third line is to correct a nasty US Robotics problem I had with my fax—it tells the fax program not to hang up between pages of my fax transmission.
On to the faxrunq.config file, essentially, I set only one parameter here. That was:
Since we have e-mail set up in our office, my Linux system sends us mail when a fax has been successfully sent out. You may or may not want to set this one. If you are setting up large broadcast fax lists, you may not want to get a hundred or more messages confirming each successful fax, or maybe you do. Whatever you decide, consider this carefully before you set up your system. Fear not, though—you can always go back and change it if you find that you made the wrong decision (after you've read your 300 confirmation e-mails).
In my mgetty.config file, I also make only one change:
More on that change later when I discuss security.
Finally, we have the faxheader file. Mine looks something like this:
FAX FROM: **Marcel & Sally** 955-555-5555 TO: @T@ PAGE: @P@ OF @M@
Okay, so my number is not 955-555-5555—you got me there. This defines the identification information that appears at the top of every fax we send out. Pages are numbered for easy reassembly when they are inadvertently dropped on the floor.
You should also make sure that you have a fax.allow and a fax.deny file in the directory. The fax.allow is a text file with a simple list of user IDs to be allowed fax access. The fax.deny file is a list of people who are not allowed fax access. Alternatively, if you just want everyone to be able to fax, simply omit the fax.allow file and create an empty fax.deny file. If neither file exists, only root can fax. For a network fax solution, this is not a good idea.
One last thing in our mgetty configuration, and we'll move on to the Windows side of the picture. The default umask for /usr/bin/faxspool is 022. Since faxspool is simply a text file, it's easy to modify the netmask so that network users can delete jobs. In the script, we comment out the umask 022 default and add the line umask 000:
# Change umask to 000 so that any user can delete # an old fax # umask 022 umask 000
Earlier, I mentioned security regarding spooled jobs. Security concerns will arise for some users, but in most offices, the fax machine is a fairly public tool. We look at the network fax queue in much the same way. Anyone can check on faxes, clean up their sent jobs, or print out incoming jobs. The odds of a co-worker deleting your job out of spite is generally fairly remote, at least in our office—I can't guarantee civil behavior in yours. As for outside users, I'll assume your firewall already takes care of them.
Speaking of outside users: would you like to receive faxes as well? That one is easy. The mgetty process can be added to your inittab to listen for incoming calls on your fax modem. Edit your /etc/inittab and add this line:
In the above entry, fax1 is an arbitrary name I've chosen. In your case, you may pick a different name just as you may need to specify a different device than my ttyS0. Finally, tell the system to reread the inittab with this command:
mgetty is ready to receive incoming faxes and will restart the listener process each time it hangs up. In my office, we share the fax with our Internet connection, so I simply start a single instance of mgetty with this command:
/sbin/mgetty /dev/ttyS0 &
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide