Colin Mattoon

Subscribe to Colin Mattoon: eMailAlertsEmail Alerts
Get Colin Mattoon: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Apache Web Server Journal

Apache Web Server: Article

Configuring a text-messaging gateway with Linux

Part 9 in our series 'How to create a Linux-based network of computers for peanuts'

(LinuxWorld) -- A previously unstated message of our "Linux network for peanuts" series is, You don't need to know very much about Linux to put it to work in your business or your home.

That's why I do not assume you are an advanced Linux user. We began with the premise that you possess little more than a basic understanding of how to install and configure Linux on a PC and how to physically connect that PC to a LAN. Parts 1 through 8 of our series were intended a first introduction to X terminal-based Linux server-centric computing for many readers and a gentle reminder to experts that not all Linux desktops need to be part of distributed processing networks of multi-gigahertz Pentium 4s and Athlons with 512 terabytes of RAM.

From that humble beginning, we walked through the specifics of how to set up a cheap and easy network of Linux X terminals and an application server. If cutting cost is half of the Linux story, then cutting hardware cost is the unreported part of the story. Follow the links to Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, and Part 8 (and in the process, drive up my page views!)

All of which brings us to the subject at hand: populating our "Cheap and Easy" Linux network with additional features that help increase productivity and improve the bottom line by reducing or eliminating spending. The first extra we are adding is a text messaging gateway -- chosen because it is easy, useful and thousands of dollars less expensive than the Windows-only alternative.

Okay, okay. This is, in part, a contrived training exercise. However, I suggest you follow along anyway even if you have no need for a text messaging gateway and even if you would rather eat worms than set up such a machine on your LAN. Our ulterior purpose is to illustrate two important matters:

  • The power and convenience of apt.
  • A fundamental principle of Linux/Unix system administration.

apt is Debian's package management system and is nothing less than extraordinary in its ability to add and delete software, to update and upgrade your systems and to eliminate repetitive reinstallation of Linux. It is easy to dismiss complaints about Debian GNU/Linux's lack of an automated GUI installation because you install Debian once during the service life of a computer and use apt for subsequent OS upgrades. Contrast that to other distributions that require what amounts to a new installation every 6 to 12 months and you quickly realize that over a 5-year period, you will avoid performing 5 to 10 installations of Linux -- while remaining up-to-date.

The fundamental principle we seek to illustrate is a "building block" approach to administration. Unable to obtain a single "turnkey" application that does what we need, we combine the capabilities of several, relatively small, and quite specialized applications to create something that is greater than the sum of it's parts.

We do this without writing any code, because (as in my case) we don't know how, and because it is not necessary to write code to use Linux for an astounding array of tasks.

Onward and some background

QuickPage is the application at the heart of our text messaging gateway. When harvested from the wilds of the Internet, QuickPage is a highly reliable client/server application that dials paging and digital phone service providers' TAP/IXO modems (more properly: "Telocator Alphanumeric Protocol v 1.8") to transfer a text message to their networks and transmitters.

Problem No. 1 with QuickPage is the client has only a wonderfully geeky command line interface. It works fine, it works reliably, but believe me when I tell you that people who are used to Windows-style point-and-click computing will complain bitterly when forced to use it.

Let's send a message to a PCS phone user named Tom Smith. Once the server is configured and the pager/phone users are added to its configuration file, you send good ol' Tom a text message by opening a terminal window and typing:

qpage tomsmith

Which you follow by pressing the ENTER key.

QuickPage starts and displays:

bash-2.05$qpage tomsmith

Enter the message and end with '.' on a line by itself.

You type:

Tom, this is Dick. Call Harry (451) 555-1212 RE: Your Angus bull is in his cabbage patch.

You press ENTER, and then put a period on the next line:


And press ENTER again.

QuickPage then dials the appropriate service provider's modem and sends the text message. All well and good except for problem No. 2: You wanted to send a text message to Tom Smith. You have 145 different pager and PCS phone users. Does the message go to "tomsmith" (Tom in the shipping department), "tsmith" (Tanya in accounts payable), "toms" (Tom Smythe in sales), or "tmsm" (Terri Margaret Smithers in field service)? There are no good clues and you have to rely on memory or a cheat sheet.

We might live with that except for problem No. 3: We either have to install the QuickPage client software on every machine that will be used to send a text message, or add an account for every computer user in our company on the QuickPage server and require users to telnet into it. That is also the only way the handful of remaining Macs and Windows machines you continue to support are going to work. The Windows telnet client is a nightmare at best.

An important part of migration from Windows to Linux is the preservation of a "point-and-click" environment and our Cheap and Easy network must follow suit. If you don't intend to make the move to Linux on the desktop just yet, and are setting up a text messaging gateway as your first Linux deployment, it better be easy for Windows users to adapt to, or it is likely to be your last Linux deployment for a long time.

In it's basic form, QuickPage is outside the comfort zone for Windows users and recent converts from Windows.

QuickPage needs a more user-friendly interface

QuickPage is ready to work with sendmail, and we might consider integrating QuickPage into our existing mail system. As long as mail can be forwarded to QuickPage without relying on outside and off-site mail servers, we could send text messages to digital cell phones, PCS phones and pagers as an email without compromising speed.

Of course, while sendmail may be small in terms of size, configuration of anything but the most basic operation is a huge task. The book (Sendmail, published by O'Reilly) is so heavy it requires a pack mule to carry it to the office from the book store. In addition, you may not have access to (or authorization to change anything on) your operation's mail server(s).

There are simply too many variables in mail handling to suggest this as a generic approach. We will look for something easier.

Everyone can use a browser

The one type of application familiar to almost every computer user is the browser. Some form of browser, whether GUI or text-based, is already installed on almost every workstation, so it is unlikely that we will need to add any software to any workstation if we can figure out a method to provide access to QuickPage via a Web-based interface.

It is trivially easy to install a Web server on a Linux box. Many (too many?) Linux workstations already run the Apache Web server by default without their owner's knowledge! However, it is one thing to run a Web server by accident, or to deliberately serve a few basic static HTML pages, and quite another to create an interactive Web site that accepts input and that does something with that input other than display an error message.

Clearly, something will be needed between our Web server, whether we run Apache or Boa, and QuickPage. But what?

A clue

Remember, QuickPage is capable of working with sendmail. A change to an existing sendmail configuration can be daunting, and complex configurations are well beyond the abilities of most of us. We have to be honest with ourselves, don't we?

A very basic, or default, sendmail configuration though, can be quite easy if configured for local delivery only. If we can come up with a means to generate an e-mail message from a Web page, we can make an extremely basic sendmail configuration work.

A MAILTO link won't always work for us. We want something that does not rely on any mail handling external to our server. We need something like a CGI-BIN application, but since we don't know how to write Perl code and we don't really understand CGI-BIN programming, we need something that is ready to drop in and use.

That "something" is CGI-EMAIL, which is an application intended to make simple work out of creating e-mail forms.

With this piece of the puzzle in place, our desktop users simply point their browsers at the text messaging gateway. They select the intended recipient of the message from an alphabetized list of pager and digital phone users. "Clicking" on the recipient's name opens a form to enter a message and send it. The resulting e-mail, intended for local delivery only, is handed to QuickPage by sendmail.

Instead of the command line client that limits access to Linux/Unix clients, and instead of an expensive Windows only client/server application, our users first encounter this:

By selecting Tom Smith, the user then sees this:

Somewhat more comfortable for newbie users, no?

Let's get to work

We installed Debian Potato (2.2.4r) on this machine and configured it as an X terminal in Part 7 and Part 8 of our series. Now we want to reconfigure it as a specialized server computer and parts of our simple X terminal configuration may not be appropriate for this re-deployment.

For one thing, we gave the machine a name: Xterm1, Xterm5 or something similar that denotes it as an X terminal on our LAN. We also assigned an IP address in the range of (or some other block we set aside for X terminals). See Part 3 of our series for an explanation of the naming and static addressing scheme we have been following for our network.

Nothing prevents us from leaving the hostname and IP address alone: Xterm5.conference.table and an address of will function perfectly, but we do assume that your Linux network will grow. It is easier to keep track of machines in a growing network if their names make sense and if their addresses are in blocks set aside for certain purposes.

Our gateway/router was assigned, our application server received and our X terminal workstations began at This machine will be a server and since it is also a gateway (not to the Internet, but to paging and phone providers), we might want to give it the next address above that of the gateway router. will do nicely. Since this machine's purpose is to send text messages, let's also give it a new name that reflects that role. We can call it messenger.conference.table.

Of course, there is another issue: we installed X and configured the machine to act as an X terminal on the first available console. (See Part 4 for Debian specific details of configuring the /etc/rc2.d and /etc/init.d files for X terminal operation.)

That is all well and good for ordinary X terminal operation, and in fact, we don't want our ordinary users to be switching between consoles, getting lost, and raising havoc. You and I, on the other hand, possess the all powerful root user's password(s) and we want to be able to switch quickly between a local console on this machine and X terminal operation so we can refer to this series for ongoing help during configuration. Once our text messaging gateway is up and running we may decide to remove X entirely, but for now, it will save us time and effort to keep X available.

Text Messaging Gateway: Step 1

Let's make more consoles available as our first step. Seated at our soon-to-be Text Messaging Gateway, kill the running xserver with:


As soon as the machine presents a command line login prompt, login as root, and change to the /etc/init.d directory:

cd /etc/init.d

Run ls -l and pipe it to less so you can scroll up and down to locate the name of the X terminal script created per Part 4 of this series.

ls -l | less

(Did you remember to install less on your Debian X terminal with apt-get? See Part 8.)

If you followed my advice, you named this script, xterminal. If you took the time to install Easy Editor (ee) using apt, you can take advantage of it's ease of use to edit /etc/init.d/xterminal:

ee xterminal

If you didn't use apt to install ee already, get off your duff and do it now! Otherwise you will have to use vi. (Editor's note: There's nothing wrong with vi!)

Change the line that reads:

/usr/X11R6/bin/X -query

To this:

openvt -c 9 -- /usr/X11R6/bin/X -query

And save your changes to the file. If you are using ee, press the Esc key to see a popup menu of options.

Now, reboot the machine. As soon as the XDM login window of your application server reappears, you should be able to switch between your application server and a local command line interface by pressing:


And back again with:


You can also switch between several local CLI consoles with:

Ctrl + Fx (where "x" is 1,2,3, etc.)

You just gotta' love using a real multi-tasking operating system!

Text Messaging Gateway: Step 2

Now that you can easily switch between your X terminal and the local command line, it's time to give your machine a new name and address. If you did a Google search; if you read the HOWTOs at; if you read the "man pages" for ifconfig and; you are still perplexed, puzzled and bewildered about changing hostnames and addresses -- you are not alone.

Ask for help with this at any Linux forum and you will get as many different answers as there are respondents. Most will direct you to use some utility that isn't even installed on the machine you are trying to reconfigure. Well, I like to be very specific, so:

  • You installed Debian Potato on this machine per Part 7 and Part 8 of this series.
  • You have yet to install and configure a bunch of applications and services like Web servers and mail.
  • The machine was originally configured as nothing but a minimal X terminal as described in Part 4.
  • You used apt to install ee as described in Part 8.
  • You just edited /etc/init.d/xterminal as described in Step 1, above.
  • The machine is named Xterm5.conference.table with an address of
  • You intend to change the name to messenger.conference.table with an address of

Okay? Then let us begin.

Open a local console:


And login as root.

Change to the /etc directory:

cd /etc

And open /etc/hosts with the Easy Editor:

ee hosts

You should see the host IP and address for this machine in the following format: Xterm5.conference.table Xterm5

(Obviously, the actual address and name depends upon what name and address you assigned during installation.)

Change that to read: messenger.conference.table messenger

Save your changes to the file.

Now open /etc/hostname with Easy Editor:

ee hostname

You should see a single entry:


Change this to:


And save your changes to this file.

Next, change to the /etc/network directory (that's network and not networks)

cd network

Open the file called interfaces with Easy Editor:

ee interfaces

Scroll down to a line that reads:


And change that to read:


Save your changes to the file and reboot the machine. Upon reboot, Xterm5 is dead and messenger.conference.table is born.

Text Messaging Gateway: Step 3

You have spent enough time seated at a computer for today. We need a minimal modem to use with QuickPage. No time like the present.

Stand up, stretch, and proceed to the nearest locally owned and operated computer shop. Ask them for a used 9600-baud modem or better, either ISA or external. They will probably offer several to you for free just to clear space in their service shop. Don't accept that offer. Insist they take $5 or $10 (in cash) so that they look forward to your visits instead of cringing when you darken their door.

Then, go home and get to know your family again. Keep watching for Part 10, and the continuation of our saga: Adding a "Cheap and Easy" Text Messaging Gateway to our Linux network for peanuts.

More Stories By Colin Mattoon

When not buried under his real job in commercial two-way radio system design and sales, Colin Mattoon is a part-time Linux system administrator at Northwest Communications in Lewiston, ID.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Mutya Aller 11/12/03 02:19:53 AM EST

I suggested a text messenger in Linux for my Special Problem Proposal, can you help me with suggestions on its probable features that hasn't been developed yet. Thanks!