Software development techniques behind the magic user interface

Multi-Touch Developer Journal

Subscribe to Multi-Touch Developer Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Multi-Touch Developer Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Multi-Touch Authors: Ben Bradley, Qamar Qrsh, Suresh Sambandam, Jayaram Krishnaswamy, Kevin Benedict

Related Topics: Apache Web Server Journal

Apache Web Server: Article

Laying a foundation for free Linux accounting

In part 14 in our 'Linux for Peanuts' series, we start installation of an open-source accounting system.

(LinuxWorld) -- A problem inexperienced Linux users (like me) must overcome is the diversity of Linux distributions that result from free access to source code. Freedom comes at a price, and part of that price is paid when one attempts to install software that comes from third party developers. Their time and resources are limited, and the tendency is to focus on one Linux distribution, particularly during the early stages of development.

Red Hat, as the most widely known commercial Linux distribution, receives the lion's share of attention from developers. Our purpose is to evaluate Nola, and not to review or endorse a particular Linux distribution over its competitors. To evaluate Nola, as "Cheaply and Easily" as possible, we will perform a server install of Red Hat "Enigma," as the platform used by Nola's own creators. In the process, we'll cover some changes in Red Hat since it's earlier releases; show you how to install Red Hat on a minimal and cheap PC for this test, and; show you how to install this two CD distribution easily over the network.

But first, let's explain how and why we chose Nola

Turns out, I'm not the only one who has been looking for the right Linux based financial accounting package. Part 13 in our series generated much e-mail. Readers were particularly interested in my reasons for selecting Nola as the software package we will use to set up our own business accounting/bookkeeping Web server in our "Linux Network for Peanuts."

Many of these e-mails included suggestions about other accounting packages, in various stages of development, and under a variety of licenses, available for Linux. Since I promised to explain my reasons for choosing Nola for this exercise in a later installment, now seems as good a time as any to discuss the matter.

Then we'll get right into the nuts and bolts of installation and configuration, so if you don't give a big rat's rear end why I chose Nola you can skip ahead and get right to work!

Give it to me straight, Doc! I can take it!

In fact, I am in the process of evaluating Nola for use in our own company. Yes, we do have a different Linux-based accounting system in limited production use at this time. No, I won't tell you which one it is, not even if you ask. All I will say is that it is one of the commercial, proprietary offerings and I'm not satisfied with it. Besides, it's cost alone disqualifies it for inclusion in any "Cheap and Easy" Linux network.

The selection criteria I applied are:

  • The package must be designed for business use. Few businesses can use personal financial software, so no matter how good the package is, if it isn't intended for business use, it didn't survive the first cut.
  • If it doesn't support remote access through the network, it need not apply. This series is about networking Linux and we don't budge on that. Another round of cuts.
  • The package must support multi-user access. That knocked out several contenders.
  • GPL. "Free, as in speech." Never again, will I willingly enter into an agreement to pay for accounting software that I can't hire someone to enhance, customize, or simply FIX if the developer isn't interested. Access to source code isn't just for expert programmers. It is an issue for every one of us. Nor am I interested in doing business with proprietary software houses that regard withholding basic installation, configuration, or user information as part of a strategy to provide "value-added services."
  • Again the GPL, and this time, "Free, as in beer." We want to take it for a test drive before we spend any money. Software developers who contend they can't make money by giving away very basic, yet functional, packages haven't adapted to the paradigm represented by Linux. The only way to really test the software is to obtain at least a basic version that isn't deliberately crippled. If it is "good stuff," then we can talk about paying for customizations that are unique to our needs. If that doesn't suit the developer's goals, then perhaps they are in the same situation as a carriage builder who refused to accept the internal combustion engine. I don't make the rules, and I didn't start the entire open source movement. It's a feature of our modern world that one can choose to ignore, but only at one's own peril.
  • Command-line interfaces need not apply. We are already forced to provide X Window System to support browsers and other productivity applications, so we turned that to our advantage and created a powerful network of X terminals. We don't mind using the command line for administrative tasks, in fact, we prefer to do so in many cases. However, our users come from a background of Microsoft Windows, and often don't know that there is such a thing as a command line -- or even that a form of MS-DOS underlies the GUI on most of their home PCs. We insist on point-and-click business accounting because our users complain bitterly if we don't. Still more cuts.
  • Web enabled, for browser access. No, not necessarily accessible from the Internet. Placing your company's financial records in harm's way is a legitimate cause for alarm, and in this series, we intend to tuck our accounting server safely away from the big, bad, Internet -- on our LAN and behind our firewall. Because we already have to endure the hardware and network overhead of providing Web browsers to our users, we may as well give them something useful to do with these browsers, besides surfing porn and spending money at online retail sites.

    The advantages of this (moving accounting from our main application server to a dedicated intranet Web server), including splitting up our load between servers, cross-platform compatibility, freedom to upgrade server OS based on need, etc., were covered in more depth in Part 13.

Two contenders remain

This brutal process of elimination left two contenders remaining on their feet: Nola and SQL-Ledger Accounting.

Similar in concept, both licensed under the GPL, both under active and ongoing development, and both with an enthusiastic gang of supporters. Without trying both, how to choose?

By scouring each project's Web site for implemented features, that's how. Welcome to Y2K+2. The economy is in the dumps and you might take a good hard look at your receivables. I'll bet they are aging. Accounts that used to pay in 30 days or less are stretching it out to 40, 60, 90 days or more. You have cash-flow problems, my friend.

Here's a little secret: "Snail mail" customer account statements trigger payment. SQL-Ledger Accounting does not yet offer that feature, according to its Web site, and I found no evidence to the contrary after searching through the archives of their mailing list. It is mentioned as planned for a future release, but does not appear to be available now.

That does not mean that SQL-Ledger Accounting isn't a good package, and this is a feature that many "cash and carry" operations will never miss. By the time you read this, the feature may even be implemented. But it isn't listed as available as I write this, and for those of us who permit our customers to pay on account, it is a problem. Thus, as good as SQL-Ledger Accounting may be, it doesn't make the final cut.

That reduced the list to Nola. If I overlooked other projects that meet all these criteria, or made an error in my assessment of SQL-Ledger Accounting's implemented features, let me know, and I'll fess up to my mistake in the next installment.

That is why we are using Nola to build an accounting server for evaluation in our "Cheap and Easy Linux Network for Peanuts."

Laying the foundation

I'm perverse enough to see how Red Hat and Nola work together on a machine that falls short of the minimum recommended Linux hardware of a 200-MHz Pentium and 32 megabytes of RAM. I needed to perform another installation to check my notes for this article, and as it turns out, I have another use for the Cyrix MII-300 machine I used to take my first look at the Nola software package. (Another measure of the depths of depravity to which I happily dive is that I am writing this installment with Easy Editor!)

I grabbed an unsuspecting and ancient P90 with only 16 megabytes of slow Fast Page memory, and added a second hard drive (541 megabytes) to complement the 854-megabyte behemoth already installed. There is no CD-ROM, so we'll have to install Red Hat 7.2 over the network. Not to worry -- this machine has "IBM" emblazoned across its face -- we could probably replace an entire server farm with it, couldn't we?

You're not buying that are you? Well, whatever. You are correct in guessing it won't work. Red Hat has increased the hardware requirements for installation to such a degree, that it is essentially impossible to install the OS without at least 32 megabytes of RAM. Oh well, the decrepit PC's case is already open, and we add two more sticks of Fast Page memory to bring the total RAM up to 32 megabytes.

Now for a short rant: Yes I know, time marches on and nobody uses old beasts for servers. Wrong. People may not use them for production servers, but do use them for testing. I am not alone in using obsolete hardware for test deployments, and it would be nice if the major distributions concentrated more effort on preserving Linux's small appetite for machine resources. Behind many a production roll-out is a back room or basement lab/test LAN of crusty old machines.

Network installation revisited

We want to eliminate variables. Look at the requests for help posted at Linux forums all across the Internet. It seems like almost half of them fall in the category of "How do I do this with such-and-such Linux distribution?" It can be tough enough to set up a server without having to deal with the differences between distributions, unsatisfied dependencies, and missing symlinks. If we all perform essentially the same installation, using precisely the same distribution and method, we help ensure that we are all following along in the same environment. Later, once you have a successful configuration of Nola under your belt, you will have a far better chance of getting it installed and configured easily on your favorite distribution -- assuming you don't want to use Red Hat.

Me? Hey, I'm eclectic in my tastes. If it works, I'm happy with it and I don't have any reason not to use Red Hat for my own production deployment, provided Nola meets my needs.

Beginning at Part 4 of our series, we detailed the installation of Linux across the network from an installation CD mounted, and exported via NFS (Network File System), on our "mini-mainframe" application server. You may want to go back and revisit these earlier installments, including Part 6, which covers Red Hat.

Be forewarned however, that there are slight differences with Red Hat 7.2, and since we are also going to perform Red Hat's optional Server installation, rather than the Custom install we used earlier to create an X terminal, we will document this installation in detail.

(Please don't groan.)

Step 1. Mount the CD-ROM

Login as root at your application server, or other NFS server on your LAN, place the first of the two Red Hat 7.2 installation CDs in the CD-ROM drive, and mount it as follows:

mount /dev/cdrom /mnt [ENTER]

Alternatively, if you machine uses a different mount point for the CD-ROM, perhaps something like:.

mount /dev/cdrom /mnt/cdrom [ENTER]

Don't forget, no matter what mount point you specify, it must be listed in /etc/exports, nfsd (Network File System Daemon) and portmapper must be running, and if the machine is running a firewall, such as configured by Gnome lokkit, the firewall must either be turned off, or ports opened temporarily. Otherwise, "it ain't gonna' work."

Step 2. Copying the CDs to the hard drive

Red Hat 7.2 Publisher's Edition is distributed on two CDs. While earlier Red Hat releases required only one CD for a basic i386 installation, starting with 7.2 (Enigma), a second CD is needed about three-quarters of the way through the install.

If the CD-ROM happens to be located in a NFS (Network File System) server, rather than physically installed in the machine on which you are installing Linux, a minor problem occurs. Instead of prompting you to swap CDs, the installer pauses and reports a problem locating files. You can return to your NFS server (in my case, the application server) and unmount the first CD, remove it, replace it with the second CD, mount the new CD, then return to your soon-to-be Nola server and tell the Red Hat 7.2 installer to try again. Not really an arduous task, but sometimes a pain -- particularly if the two machines aren't close to each other.

An alternative is to make a NFS exportable directory on the hard drive of your application server, copy both CDs to that directory, and perform your network installs using that new directory. Here is an example of how to do this...

Place the first of the two Red Hat 7.2 installation CDs in the CD-ROM drive. As root:

mount /dev/cdrom /mnt  [ENTER]
mkdir /home/redhat  [ENTER]
cd /mnt  [ENTER]
cp -r ./ /home/redhat/ [ENTER]

When returned to the command prompt, which will take a while:

cd  [ENTER]
umount /mnt [ENTER]
eject  [ENTER]

Put in the second installation CD, then:

mount /dev/cdrom /mnt  [ENTER]
cd /mnt  [ENTER]
cp -r ./ /home/redhat/  [ENTER]

When returned to the command prompt, you again:

cd  [ENTER]
umount /mnt  [ENTER]
eject  [ENTER]

Now, open /etc/exports with a text editor, such as ee or vi and add a line to the file that reads:

/home/redhat (ro)

The easiest way to cause Linux to read this addition to /etc/exports is to simply reboot the application server, but before you do, you might want to check that the additional files you were instructed to download for your Nola installation in Part 13 of this series are also in an exportable directory. You might create a /home/nola-files directory and add that to /etc/exports if they aren't already in a suitable location.

It is understood that you should warn other users before rebooting the server, isn't it?

By the way, this is also a handy technique if you borrowed the installation CDs and cannot (or don't want to) burn your own copies. It also speeds up installation if your CD-ROM is old and slow and you need to perform multiple, simultaneous installations across the network.

Step 3. Create installation floppies

Place a floppy disk in the first floppy drive of your application server and format it. Most newer Linux distributions use the superformat command with this syntax:

superformat /dev/fd0 [ENTER]

Now, change directories to the CD (or to the /home/redhat directory suggested as an alternative) you mounted in Step 1, above:

cd /mnt [ENTER]

Run the ls utility with the "-l" option to list the file contents:

ls -l [ENTER]

You should see the images directory as the last entry. Change to that directory and run ls -l again to see a change from the earlier Red Hat 7.x releases: the bootnet.img file is there as before, but now the drivers have been split into several disk images to accommodate the every increasing inventory of hardware and file systems that Linux supports.

We will use the dd utility to create the disk:

dd if=bootnet.img of=/dev/fd0 [ENTER]

As soon as the lamp on the floppy drive is extinguished and you are returned to the command prompt, remove and label the disk.

We may as well assume that the limited selection of Ethernet drivers on this disk won't include the necessary driver for your network card, so grab another floppy disk and use the superformat command again to prepare it. Then, using the dd utility once more, create a disk of network drivers:

dd if=drvnet.img of=/dev/fd0 [ENTER]

Lamp goes out, label it, blah, blah, blah. You know what to do.

Step 4. Boot the installer

Not with your foot, fool! Use the bootnet.img disk you just created. Cram it into the first floppy drive of the machine you intend to use to test Nola, and power that monster up.

The installation utility displays the opening, "Welcome to Red Hat Linux 7.2!" Don't even think about installing this in "graphical mode," if, like me, you are using an older machine with only 32 megabytes of RAM, an old SVGA monitor and a low-spec video adapter. It won't work. Besides, we aren't going to install X Window System on this server, so we may as well content ourselves with the command line and Red Hat's ncurses-based installer from the very beginning.

However, don't assume a plain text mode installation is the right choice, either. The bootnet.img disk includes drivers for only a handful of network cards. At the bottom the screen you should see a boot prompt and a flashing cursor. If the machine is equipped with 32 megabytes of RAM, or more, type linux dd text for a non-graphical text-mode installation that will prompt you for the driver disk you created in Step 3, and press ENTER. If there is much less than 32 megabytes of RAM on board, then either give up or add RAM.

Step 5. Load the driver disk

After you press ENTER the process begins by booting Linux from the floppy disk. As soon as the image is loaded in RAM, the installation utility pauses and asks if you have a "Drivers Disk." Answer, "Yes," and at the next screen, you are told to "Insert your driver disk and press 'OK' to continue." So remove the bootnet.img disk and replace it with the drvnet.img disk you created in Step 2, then press "OK."

Step 6. Answering questions and making choices

I speak (and write) a primitive, pidgin English, so I select English as the language to use for the installation at the next screen, and "us" for keyboard type at the screen following that.

Under "What type of media contains the packages to be installed?," I select "NFS image," because the Red Hat installation media (either the CD or a file on the hard drive) is on my application server, and not this machine.

The next screen demands to know which driver to try for the NIC (Network Interface Card). I scroll down to the appropriate driver (in this case, EtherExpress) and then use the Tab key to select "OK" before pressing ENTER.

If you don't know which driver to try, you might review Parts 5, 6 and 7 of our series (see links to earlier installments under "Resources," at the end of this article) to review how to obtain, create and use a Slackware net.i boot disk to learn the model of NIC installed in this machine.

Step 7. Who am I and where's the CD?

As soon as Red Hat 7.2 is satisfied that the appropriate driver for the NIC is loaded, it asks for basic network information. In this series, we assume you will assign static addresses to each machine. We created our network for a demonstration to management and named our network "conference.table" because we put all the machines on a couple of big conference tables. Our Internet firewall/gateway/router was assigned an IP of, our "mini mainframe" application server became, and our eight X terminals were assigned IPs in the range through When we created a Text Messaging Gateway for our network, we assigned it an address of -- not entirely an arbitrary choice -- we decided to give it the next address above that of the Internet gateway, because the Text Messaging Gateway is a gateway to another sort of network.

The machine we are working on now will serve a productivity application: The Nola accounting package and won't act as a gateway to anywhere, so we'll give it an address next to that of our main application server. We will go with and give it a fitting name -- I'm going with "nola.conference.table."

And, at the screen that patiently waited while I wrote the preceding two paragraphs, I use the space bar to unselect "Use dynamic IP configuration," and instead enter:

IP address:
Default gateway:
Primary nameserver:

Which I follow by selecting, "OK." (You really don't need a default gateway, and you can live without a nameserver, but my FreeSCO router performs both services, and hey, it's there.)

Red Hat then reports that it is "Determining host name and domain..." I know it's not going to find them, because I haven't bothered to configure a real name server at my home (where I decided to write this article) that supports "reverse name lookups," so I go grab a cold beverage from my fridge while it struggles.

As soon as I return with a cool one in hand, the monitor displays a screen with a place to enter my "NFS server name," and "Red Hat directory." I type in the address of my application server (, rather than it's name and I enter /mnt (or /home/redhat, as the case may be) as the location of the directory in my network.

As soon as that information is entered, Red Hat attempts to mount the remote CD-ROM and the installation process begins to run from the CD. This may take a minute or more as the installer reports, "Running Anaconda."

Step 8. Got vermin?

I select "None" under "Mouse Selection." We don't need no stinkin' mouse.

Within a minute or two, we are "Welcomed To Red Hat," and ordered to report to their Web site to register. Well, actually, we are invited. This isn't Windows XP. Under duress, we tell them, "OK" so we can move on.

Step 9. What can we get for ya'?

Next up, we are asked, "What type of system would you like to install?"

Select server installation and "Autopartition" at the next screen. I figure this is a good opportunity to see how Red Hat's own gurus would partition this tiny fraction of a terrabyte -- and to see if they have gotten so deep into mainframes and supercomputers that they have forgotten how the rest of us work. That is, unless you don't have enough space on your disks. If that is your situation, jump ahead to Step 8b, below.

When asked, go ahead and let the installation utility "Remove all partitions on this system," too. This machine is dedicated to the sole purpose of testing Nola and we don't want anything else. If you have more than one disk, make sure you select them all by using the space bar to toggle on the asterisk in the brackets to the left of each drive at the same screen. Mine are hda and hdc. Depending upon the controller each is connected to, and type, yours may be different. But you knew that already, didn't you?

And, of course, dire warnings aside, you are "sure you want to do this," so toggle the selection to "Yes" and press ENTER when asked.

Step 10. Yes, (disk) size matters

My two little hard drives came up short! Unlike when confronted with the 10 gigabyte drive in my first Nola test machine, Red Hat 7.2 reported it couldn't be bothered with auto-partitioning such pitiful junk and dumped me unceremoniously into their Disk Druid utility -- Red Hat's answer to fdisk. Fine, I know when I'm not wanted. Here's how I split things up:

   Device    Start   End  Size   Type   Mount Point
   /dev/hda1   1     792  779M   ext3   /
   /dev/hda2  793     827   34M   swap 
   /dev/hdc1   1     203  199M   ext3   /usr/local
   /dev/hdc3  204     524  315M   ext3   /usr/lib

Not necessarily the best solution, but I wanted a guaranteed 200 megabytes for /usr/local, because that's where Nola and all our packages are going. If this wasn't just a test installation, I'd want a larger /usr/local partition to hold data: up to several gigabytes in a large company. (Of course, we wouldn't use a ratty old P90 in that instance, either.)

Putting /usr/lib on the second hard drive was simply an expedient method of freeing up space in the "/" partition so that the "server installation" can proceed without errors.

Step 11. Wanna' swap?

Red Hat looks at our 32 megabytes of installed RAM and sneers. Specifically, it tells us that we don't have much RAM and that it needs to turn on swap space immediately. We could argue, and repeatedly point out that nobody had 32 megabytes RAM just a few short years ago, and that Lockheed designed the SR-71 with slide rules. We could, but it won't do any good, so just select "OK" and press ENTER.

Step 12. Time for some GRUB

Not food, the GRand Unified Bootloader. It's an alternative to LILO (Linux Loader), it seems to work well, and it is the default choice. We go with the default and choose the MBR (Master Boot Record) of our first drive as the appropriate location. We accept the defaults for the next couple of screens and dispense with a GRUB password.

Step 13. I'm not HAL, but who am I?

The Hostname Configuration screen appears, and this is where you get to enter the name and domain of your machine. Ours is nola.conference.table and we type and enter it just like that.

Step 14. Just say no to firewalls

Not yet, that is. Ignore the warnings and select "no firewall." After Nola is up and running, we can come back to this configuration at any time by logging in as root and typing lokkit -- but for now, it will just get in the way.

Step 15. Other languages

That's up to you. I need English only, so I don't add any.

Step 16. Time zone & passwords

If you don't know where you are, or what time it is, I can't help you except to suggest you lay off the beer the next time you attempt to install Linux.

Pick something you will remember for a root password, and add an ordinary user account (again with a password you can remember). Another good argument for limiting beer intake while installing Linux.

Step 17. Package selection

We are near the end of our part of the installation, but before the Red Hat installation utility can really go to work, we need to select, and unselect, some packages. The "server install" of Red Hat 7.2 Publisher's Edition selects, by default, "Classic X Window System." We don't want it, and we don't need it on this server, so we unselect it.

The Publisher's Edition does not default to any other optional packages by default, and that's okay by us, with one possible exception. NFS is a handy way to perform "Cheap and Easy" backups over the network, so you might want to select "NFS File Server" as the sole optional package for installation. If you already have a different backup strategy planned, or don't care because it's only a test installation, you can leave that package out as well.

Everything else is not only unneeded, it is unwanted. So, let 'er rip! Red Hat goes to work formatting file systems and retrieving files across the network. For the moment, our work is done. Now you can break for a beverage!

Step 18. Change CD

When you install Red Hat 7.2 from a local CD-ROM, during the installation, it pauses and alerts you to replace the CD in the drive with the second of two CDs. Not so, during a network installation. It pauses and complains about bad or missing media for an Emacs package. Just go ahead and umount the CD, put in the second Red Hat installation CD, mount it, and tell the installer to try again -- unless...

Step 19. Do nothing

Because you aren't using the CDs, having created a NFS exportable directory, as per Step 2, above. Pat yourself on the back.

About all that remains is to create a boot disk (or not) and reboot the machine after the installation completes. Easy, huh?

A standardized installation -- a foundation, on top of which we can now all build our Nola servers without having to worry about different packages and unresolved dependencies, missing compilers, unwanted Apache installations, etc.

And now for some Nola stuff!

Login as root at your new accounting server and fetch the files we are going to compile and install. These are:

As suggested in Part 13, place these in a NFS exportable directory on your application server. Use the cp command to put them where they need to be if they aren't already.

Then, at the accounting server:

mount -t nfs /mnt [ENTER]
cd /mnt [ENTER]
cp *.* /tmp/ [ENTER]
cd [ENTER]
umount /mnt [ENTER]

All the files are now safely tucked away on your new accounting server in the /tmp directory. Next installment, we will unpack, configure, compile, and install them. We'll also explore some basic security measures made easy by the Red Hat 7.2 distribution and a ncurses-based tool that makes it as easy as falling off a log to turn off services that might make our server vulnerable.

For now, it's been a long day's work. Step away from the computer, go home, talk to your spouse, your children, and your dog. Read some Steinbeck, or change the oil in your lawn mower, because spring is coming! Then, rejoin us in Part 15 as we turn on the lights with our LAMP application called Nola! (As well as an explanation of the term, "LAMP.")

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
Volkan Gul 10/14/03 02:42:45 PM EDT

i want to use linux