Sysadmin

(LinuxWorld) -- Before we continue and begin the integration of mail and QuickPage on our Text Messaging Gateway, there are a couple of items that need to be addressed.

The first comes under the general heading of "Errata." It is no show stopper, but in Part 10 of this series, I told you that Debian's Apt utility helps ensure that you get the benefit of their latest security enhancements. Then, I immediately proceeded to leave out an essential line in /etc/apt/sources.list! Okay, I'm an idiot!

Let's take care of this right now. Change to the /etc/apt directory, and with a text editor, open the sources.list file. Because vi (I'll see if I can get a rise from the editor) "sux" (Ed. It's apparent some people [sniff] just don't appreciate elegance.), I'll use Easy Editor:

ee sources.list

Uncomment (remove the "#") the line that reads:

#deb http://security.debian.org stable/updates main contrib non-free

And if you will run:

apt-get update

Followed by:

apt-get upgrade

Then, your machine will get the latest security updates for Debian Potato. As I said, it's not a showstopper, and it won't interfere with the configuration of your Text Messaging Gateway, but it should be corrected soon.

The next item isn't an oversight or error on my part. Back in Part 4 of this series, I extolled the virtues of Slackware for creation of PC X terminals. I find Slackware consistently the easiest Linux distribution to install via NFS (Network File System) on machines with little RAM, small hard drives and no CD-ROM drives.

One of the great features of Slackware has long been the Slackware Forum -- a place to ask questions about installing, configuring and using Slackware Linux. People who posted questions ranging from the most trivial ("How do I change directories in Linux?") to requests for help with parallel computing typically received invaluable assistance within a matter of minutes from a legion of experts (and a few jerks!) who kept a close eye on things.

Unfortunately, the Slackware forums have gone the way of the buffalo. In response to a growing problem with "trolls," Slackware's developer, Patrick Volkerding, closed down the forums, perhaps permanently. With this closure, an important resource for Slackware users is gone as well. Whether this was necessary or a good business decision, I'll leave to others to decide.

However another site, Linux Packages, offers a forum for Slackware users. It doesn't have an inventory of several years' worth of questions and answers to search through for help, but it is frequented by many of the most helpful experts from the suspended Slackware forum. This new forum is well worth a look if you need (or can provide) some assistance with a Slackware-related problem.

Now, let's get back to our Text Messaging Gateway

In Part 10 of our series, we installed and configured QuickPage. We got our dusty old modem to work with it, and we sent our much-abused shipping department worker, Tom Smith, another text message to assure him that he really wasn't fired.

Although QuickPage is running, we aren't done. Not by a long shot. At this point, the only way we can send a text message from our former X terminal is to login at it's local console and send the message using a command line interface. With a bit more work, we could telnet into it to do the same thing, or we could install the QuickPage client software on some Linux workstations -- but none of that is what we want. After all, we began this series by creating a network of Linux X terminals, and we want to leverage X by serving our users a browser enabled, simple to use, interface. Because we also expect to have to support platforms other than Linux, including Macintoshes and Windows machines, we don't want to rely on Linux/Unix client software.

Between the Web server (Apache and Boa are my favorites) that our users see, and QuickPage, we need a CGI-bin application and a local mail server. Since the mail server works directly with QuickPage, we will configure that next, as we work our way from the modem to the Web server.

Step 1. Exim doesn't make the cut

By default, Debian installs Exim as a Mail Transfer Agent (MTA). I'm sure Exim has some great features, but it isn't part of the Cheap and Easy way to configure our Text Messaging Gateway. Exim has to go. apt-get makes it easy to rip it out by the roots:

apt-get remove exim

"But Exim is easier to configure than sendmail," you cry!

Stop whining. This is all part of our Cheap and Easy approach to server-centric Linux computing. Trust me.

Step 2. Sendmail gets a partner

We now need to install procmail, an "autonomous mail processor," and create an /etc/procmailrc file.

Why install procmail as a separate step -- after removing Exim and before installing sendmail? Installation of sendmail with Apt causes procmail to be installed as well. Why not simply install sendmail?

Good question. Unfortunately, I don't have a good answer. All I can tell you is that when I install sendmail, and rely on Apt to install procmail with it, sometimes the resulting installation won't pass e-mails to QuickPage.

I'm not one to fight such things. Maybe it's a bug. Maybe there is a problem with a server. Maybe an errant sub-atomic particle whacks my Text Messaging Gateway's hard drive in just the right place each time and maybe if you try it, it will work fine. At any rate, with Apt, it is no more work to install procmail as a separate step, so:

apt-get install procmail

As soon as procmail is fetched from Debian's server and installed, we create the /etc/procmailrc file. Change to the /etc directory and with a text editor, create the file (again with Easy Editor!):

ee procmailrc

In that new file, type the following three lines:

:0c
* ^To: .*[+-]page@
|/usr/bin/qpage -l 0 -m -p  $LOGNAME

Save your changes to the newly created file. I lifted this script directly from the QuickPage Web site (you can read all about this in the instructions at the QuickPage site) and among it's purposes is to cause QuickPage to handle messages while placing a copy of each in /var/mail. (Yes, /var/mail. /var/spool/mail is a symlink to /var/mail on this Debian system.)

Our purpose in having a copy of each paging message delivered to the user's mailboxes is two-fold. It's a handy log of messages for troubleshooting. It is also a record, if not necessarily of a successfully delivered message, at least of an attempt to deliver a message. Ours is a litigious age.

Another item of note is that this is not intended to be a "mailbox" for users to retrieve messages from when they leave their pagers and cell phones off. The Text Messaging Gateway, as we are configuring it, isn't available to users as a "POP3" mail server. Since we will use the useradd command (more on this a bit later) to create paging users without also creating a /home directory or login password for them, only the system administrator has access to these mail entries. Helps keep 'em honest, if you know what I mean.

Step 3. "Houston, we are 'Go, for sendmail retrieval'"

Quit worrying, I tell you. Yes, sendmail has a reputation for complexity, but everything we do is both Cheap and Easy. Our use of sendmail will be no different. Ready?

apt-get install sendmail

Apt-get informs us that m4, a "macro processor," will be installed as an "extra package" with sendmail. [shrug] Whatever a macro processor is, somebody figured out that it needs to be installed along with sendmail, and that's good enough for us. Remember, my recurring message of hope is, "You don't have to be an expert to use this stuff."

Let's just permit Debian go about its business and fetch whatever it thinks sendmail may need for companionship.

As soon as sendmail is installed, you are asked if you want to configure it. While the default choice is "N," we have no reason to wait. We answer, "Y."

Guess what? We don't even need to read the questions. We accept every default choice in sendmail's configuration utility including the last one: "Start sendmail now?" We answer "Y."

O'Reilly's "Bat Book," entitled Sendmail, may mass about 1000 kilograms (roughly a metric ton, for those of us from Idaho), but our local configuration is as easy as falling off a log.

Step 4. We can't "sendmail" if we can't send mail...

We are almost ready to test our sendmail integration with QuickPage, but before we can send a text message to a pager or phone as e-mail, we need a Mail User Agent (MUA). Elm is as good as any for our purpose and we use Apt to get it for us:

apt-get install elm

Don't worry that Apt reports, "...selecting elm-me+ instead of elm." It will work just fine.

When Apt completes installation of Elm, we can let Elm create some needed directories. At the command prompt, we type:

elm

Press ENTER.

Elm responds by telling us that it requires a .elm directory and asks if we want it to create one. Tell it, Y and Y when it requests permission to create folders for you.

Now, press q to exit Elm.

Step 4. Time to add paging users to the system. Sort of

Before we can send mail to Tom Smith in the shipping department, we need to add him as a user on our Text Messaging Gateway. If you review Part 10 of our series, you will see that we already added our users (or more precisely, their pagers and cell phones) to /etc/qpage.cf -- but while that allows QuickPage to send them messages from it's command line client -- it does not permit local e-mail messages to be sent to the user's pagers and cell phones.

However, we don't want or need to provide "Tom" a real account on this machine, and that's a "Good Thing" (thanks, Martha) because we don't really trust good ol' Tom! We use the useradd command, rather than the more common adduser, because useradd doesn't create a home directory or ask us to supply a password for Tom. Since we identified Tom's PCS phone in /etc/qpage.cf as tomsmith, we will add the same name as a user on the system. All we do is type:

useradd tomsmith

Press ENTER.

Tom is on the system, but he can't login, and he can't tamper with the record of pages sent to him that are kept in /var/mail. We want to keep it that way.

Step 5. Let's fire up Elm & send Tom another message

Now we can use Elm to send yet another text message to our abused shipping department drudge. (We know him pretty well, and we know how far we can push him before he snaps and attacks us with a forklift.) At the command line:

elm

Followed by ENTER.

Elm's menu appears, and you press m to start the process and enter the address as:

tomsmith+page@localhost

Don't bother with "Copies to:"

Whatever you like as a subject. (It's just mail! You don't need my help with Elm, do you?)

In this installation, by default, Elm automatically uses an external editor to compose the message. The body of the message is typed with (Ed. the wonderfully elegant) vi so remember to use an i before attempting to type the body of your message, and to hit the Esc key, followed by a colon and wq when it is complete, to be returned to Elm's menu.

Press s to send.

In a few seconds, your Text Messaging Gateway will dial out to Tom's PCS phone service provider just as it did when we used the QuickPage command line interface. We are almost there! (And if we didn't send Tom another "disturbing" message, it should be safe to walk to our car in the parking lot when we leave the office tonight.)

In Part 12, we will wrap up the configuration of our Text Messaging Gateway by installing Boa as a lightweight and nimble Web server suited to our minimal hardware and cgiemail to make the creation of our text input forms as "Cheap and Easy," as everything else we have done in our Network for Peanuts. We will write some very basic HTML (read that as "crude and amateurish") that you can copy and modify to create your own Web-based interface to the Text Messaging Gateway you are undoubtedly working feverishly to complete!

For now, turn out the lights, grab your coat and go home to spend an evening watching professional wrestling on the television with -- well, anybody -- while scarfing down some high-cholesterol junk food and a couple of gallons of beer. Get ready for Part 12, and to put your Text Messaging Gateway into production.