Sysadmin

(LinuxWorld) -- The Information Technology (IT) industry serves acronyms for breakfast, lunch, and dinner seven da... (oops! I meant to write, "24/7 365"). I've searched diligently for the right Linux accounting solution since Q4 Y2K minus 2, and naturally enough, there's an acronym for the type of application we are evaluating together here. Nola (as we are deploying it) is a LAMP application, which merely means that it runs on Linux, it's Web enabled and served to the network with Apache, while data is handled by the MySQL database, and users see, and interact with dynamic Web pages generated by PHP.

Disappointed? Well, don't be. It is an important factor in deciding whether Nola merits attention.

As an application, Nola can be visualized as part of an interface, or front-end, to the MySQL database, and consists of a collection of .php scripts -- ASCII text files -- that are processed by Apache to create dynamic HTML pages sent to our users' Web browsers.

As an open-source application with a small but active developer community, Nola will develop and improve. Updating Nola is mostly a matter of overwriting PHP scripts while your company's data remains safely tucked away in the bowels of the MySQL database. An upgrade that goes awry (it happens) and breaks something, can be reversed quickly by overwriting these files again -- with an even newer, corrected version, or by returning to an earlier version.

Beyond this advantage is the matter of locally developed customizations and enhancements. Certainly Noguska stands ready to provide these services for you. To put it delicately, however, we live in uncertain economic times. What if Noguska is no longer there when you need them? What if you commit your company's critical financial accounting to a solution that becomes orphaned?

Obviously the GPL license governing Nola means you have the right to modify it. While this sounds good, are you ready to tear into source code written in C? No?

Far be it from me to suggest that writing PHP scripts is trivial, but it is more practical for most of us to contemplate learning how to do this, than to learn how to program in C. The GPL guarantees our rights, and Nola's design makes it more likely we can exercise these rights. Nola is an intranet Web site. A complex Web site, when compared to a few pages of static HTML, but a Web site nonetheless. And if we have to, we can deal with that.

What's up with zlib vulnerabilities?

Unless you spent the past several weeks pursuing your favorite hobby of eluding the police by sleeping in abandoned barns and eating choice tidbits pilfered from garbage cans, you are aware of the potential security risks discovered with the zlib and php packages.

The key word is potential. Does this represent a level of risk that makes it desirable for us to divert from the task at hand -- setting up Nola so we can evaluate it as a Linux-based accounting solution we may want to use? Or should we follow conventional wisdom, and drop everything while we apply all the latest security updates?

A quick reality check

Most people searching for a Linux-based accounting solution for small- to medium-sized businesses are looking for an alternative to Windows-based accounting in a peer-to-peer network. We already know that viral infection, and the innocent blunders that happen when Windows users with easy access to administrative utilities aren't careful, trash critical data every day all around the world.

Servers, located within firewall-protected LANs, particularly those used in small business, aren't the targets of coordinated DOS attacks from the Internet. That's why there is a firewall in the first place, and that's also why, unless you are honestly an expert, and actually know what you are doing, you don't configure your firewall to permit connections from the outside world to the inside of your LAN. (If you "gotta' have it," and you're not an expert, hire some one who is an expert. Otherwise, you're asking for trouble -- and trouble may well find you.)

Another consideration is the speed, bandwidth, and type of your firewall-protected Internet connection. It may be the 21st century, but it is still common to find intermittent dial-up service as the sole means of connecting an office, or an entire company, to the Internet. If e-mail is hosted off-site, and only a handful of people need (or are authorized) to surf the Web, 56K dial-up can be a practical, cost-effective solution, and in many cases, it remains the only available solution. A slow connection (and a dynamically assigned IP) is not only impractical to attack in this manner, it isn't an attractive target.

On the other hand, if you:

• Connect via a DS3
• Intend to place your accounting server in a "DMZ" and provide access to it from the Internet
• Work in a large operation with significant risk of internal attack from employees
• Your company or agency is "high profile" and engaged in activities that might attract anything from corporate espionage to terrorist attack
• Or, are simply paranoid and insist on the ultimate in security on general principles

then, by all means, stop the presses, hold the phone, shut down the assembly line, and perform all the security upgrades before proceeding.

However, if any of that applies to you, you really aren't part of the target audience for this article. Duh. Rest assured, switching from the typical small business Windows 9x/NT network to a basic, Linux-based solution, behind a Linux firewall, represents a quantum leap in the protection of your data from viral infection, innocent blunders, and operating system instability.

Are we simply going to ignore security?

No. We are merely setting the matter aside for the moment, to focus on the job at hand, which is to install Nola so we can evaluate it for our use. We will re-visit security later, and for our purposes, this is the more useful approach.

This zlib vulnerability is not the first, nor will it be the last, you will ever confront. If Nola is going to provide a long-term practical solution to our accounting needs, it either needs to be something that lends itself to upgrade and patching after it is placed in production service -- or else we need to plan on carefully hiding it from "hostiles" -- maybe even on a subnet that isn't accessible to most of our own workers.

Let's get busy!

With the necessary ingredients stored in our /tmp directory, we turn our attention to the preparation of our Nola accounting server. For those who have never installed a package from source code, here's a quick, abstract, simplistic, and mostly technically inaccurate, view of the four-step process:

1. Use the tar utility to "unpack," or decompress, the source code package you downloaded as a "tar.gz" file. Once uncompressed, the file provides scripts, instructions ("README's"), the source code itself -- in short --everything needed (we hope!) to build an application that will install and run on your system.
2. The configure command next provides orientation specific to your system -- Linux on an i586, or NT on an Athlon -- as well as the existence, version and location of other essential packages. The configuration step is also the opportunity to specify support for certain options, such as php support in the Apache Web server. The command is entered with a leading "./" ( ./configure).
3. make is the command that "makes" or "builds" the application for for your system by compiling it for the OS and hardware determined during the ./configure step, as well as with any options you provided.
4. make install, as you may well surmise, installs the compiled application on your system.

Step 1. Throwing out some trash...

We did change one procedure as a result of the flap surrounding zlib: We aren't going to use the one we downloaded for anything. We'll use the package that was installed by default during our server installation of Red Hat 7.2 (code named, "Enigma"). The package we downloaded? Throw it away.

Login as root at the local console of you server and change to the /tmp directory where we placed the files we are going to use during Part 14 of our series:

cd /tmp [ENTER]

Delete the zlib "tar ball" with the rm command:

rm zlib-1.1.3.tar.gz [ENTER]

With that bit of unpleasantness out of the way, we move to MySQL, the database behind our accounting server.

Step 2. Introducing a new character

We want to add a group and a user, both named "mysql," before we go further:

groupadd mysql [ENTER]
useradd -g mysql mysql [ENTER]

The first command creates the group mysql and the second creates the user and places the user in the desired group. See man groupadd and man useradd on your system for additional reading.

Step 3. Spreading some tar on our database

Before we can "build" MySQL, we have to decompress MySQL, which we downloaded as a "tarball": a compressed "tape archive." (See man tar and man gunzip for some detailed explanation.) We do this with one command that gives us a pleasingly verbose output as things flash by our eyes on the monitor:

tar xzvf mysql-3.23.47.tar.gz [ENTER]

As soon as this process is complete, we are returned to the command prompt. If we run the ls utility to view the contents of the /tmp directory, we now see our original mysql tarball (mysql-3.23.47.tar.gz) plus, a brand new directory named mysql-3.23.47.

Step 4. Configure MySQL source

Change into the new directory created when MySQL was "untarred."

cd mysql-3.23.47 [ENTER]

We will configure MySQL for installation under /usr/local. It is a common (although not, by any means, universal) practice to set aside /usr/local as the repository for locally installed applications, in contrast to software included with the Linux distribution. We want MySQL to reside in a subdirectory of /usr/local so rather than simply typing ./configure we enter it as follows:

./configure --prefix=/usr/local/mysql

The configure process requires about 8 minutes on my Pentium 90, so even if you are using a much faster machine, don't expect it to complete in the "blink of an eye," or panic when it doesn't. When it completes, you are returned to the command prompt.

Step 5. Compiling MySQL

This is the operation that can make you wish for a much faster processor! During the make phase of this job, my little Pentium never used more than 28 megabytes of the total 32 megabytes RAM installed. But, it worked the dog out of the processor, and on this 90 MHz machine, took 2 hours and 17 minutes to complete. (I forgot to record the time to compile on the Cyrix MII-300 I originally used, but as I recall, it required about 50 minutes. The point is, don't panic and decide something is wrong because it takes a while to compile some of these applications.)

Still in the same directory as when you ran ./configure, you build MySQL:

make [ENTER]

If you are running a slow machine, you may as well go do something else for a while. Unless the build fails, there's nothing to do while MySQL compiles.

Step 6. Installing MySQL

Once MySQL is compiled, and you are returned to the command prompt, it's time to install it. This takes only about 90 seconds on the Pentium 90:

make install

Easy, huh? Congratulations -- you just compiled and installed software from source code. But you can't take all the credit, because the computer did all the hard work for you!

Step 7. Render unto MySQL...

...that which is MySQL's.

MySQL requires that we create some tables and change ownership and permissions of directories created when it was installed. You can read more about the "How's and Why's" behind MySQL installation at the MySQL Web site. For now, we are concerned only with the "What's:" i.e., "What's that?" "What's next?" and "What do I have to do?" For now, "what" means to enter the following commands:

 /usr/local/mysql/bin/mysql_install_db [ENTER]
chown -R mysql:mysql /usr/local/mysql [ENTER]
chmod -R 775 mysql:mysql /usr/local/mysql [ENTER]

If, after that little flurry of touch typing, you change to /usr/local and then run ls -l in that directory -- and in /usr/local/mysql and it's subdirectories until finally you collapse from exhaustion -- you will discover the stuff of databases to come under /usr/local/mysql/var and everything included under /usr/local/mysql is now owned by a user named mysql who is part of a group named mysql and that the permissions for all of the directories and files are now "rwxrwxr-w" (775).

Step 8. Apache user & group

Sometimes it seems more difficult to not install Apache than it is to install it: there must be thousands of Linux boxes happily running the Apache Web server unbeknownst to their users! But not only do these precompiled, mostly-accidently-installed-by-default web servers, represent some security risk and a minor additional demand for machine resources, they aren't built with our specific needs in mind. That's why, even though this Nola accounting server does function as a Web server, we deliberately installed Red Hat Linux without any Web server, in the previous installment of our series.

Like MySQL, Apache needs a user and group, too:

groupadd apache [ENTER]
useradd -g apache apache [ENTER]

Step 9. Configuring Apache

Make certain you are back in the /tmp directory:

cd /tmp

And unpack the apache "tarball."

tar xzvf apache_1.3.22.tar.gz [ENTER]

Now change into the new apache directory created under /tmp:

cd apache_1.3.22 [ENTER]

As with MySQL, we have to run ./configure as our next step. Unlike MySQL, there are a lot of options we must compile into Apache.

Here is my dirty little secret: I am not certain we require all of these modules. My message to you has always been that you don't have to know very much to put Linux to good use. You can learn as you go, and sometimes all you really need are access to specific instructions. I looked at an early version of an automated installation script that was included with the now obsolete Nola ISO image, and eliminated everything I could. The options I list are what remain.

You might want to take a look at "Compiling Apache" by Mark Komarinski and Cary Collett, published here at LinuxWorld, back in 1998. It is still a worthwhile read. Also, you can take a look at /tmp/apache_1.3.22/src/Configuration as soon as you unpack the downloaded tarball for some explanation of the purpose of each of these modules. You'll find that speling is not a typo, and that you are warned to avoid mmap_static, although I haven't encountered any problems in using it.

Make certain you are in the /tmp/apache_1.3.22 directory. What follows is one command, on one line. Just let the line wrap around. Double-check your "speling" because it will puke if you type it wrong. Ready? Here 'tis:

./configure --prefix=/usr/local/apache -- server-uid=apache --server-gid=apache --enable-module=unique_id --enable-module=rewrite --enable-module=speling --enable-module=so --enable-module=mmap_static --enable-shared=unique_id --enable-shared=rewrite --enable-shared=speling -enable-shared=mmap_static [ENTER] (Editor's note: We corrected an error in the above Apache compiler options at 12:40 am Pacific on April 11, 2002. We apologize for any inconvenience.)

Apache's configuration step doesn't take very long, and within a minute or two you are returned to the command prompt.

Step 10. Compiling & Installing Apache

Apache doesn't take very long to compile compared to MySQL. Even my puny old Pentium 90 took little more than 7 minutes -- so don't run off for lunch as soon as you hit Enter!

Still in /tmp/apache_1.3.22:

make [ENTER]

As soon as you are returned to the command prompt:

make install [ENTER]

Step 11. PDF

Documents intended for printing, such as customer account statements, are generated as .pdf files by Nola, and are then downloaded. The pdflib package you downloaded earlier is used to create these files.

Change back to the /tmp directory and then unpack the tarball:

cd /tmp
tar xzvf pdflib-4.0.2.tar.gz

No options are required to build pdflib for our system, so you can enter the following commands without developing carpal tunnel syndrome:

cd pdflib-4.0.2 [ENTER]
./configure [ENTER] 
make [ENTER]
make install [ENTER]

It required a bit more than 30 minutes to do all this on my Pentium 90, with make consuming the bulk of that time (about 28 minutes). If you are testing Nola on a slow machine, grab a quick lunch break!

Step 12. The missing link

We have installed a lot of software, and we need to tell the system where to find many of these files. The GNU linker, known as ld (see man ld) has to be told where to look, so we break from compiling software and add a couple of lines to /etc/ld.so.conf

As much as I would prefer to use Easy Editor (ee), it isn't installed by default on a Red Hat system, and I'm too lazy to download it for the minimal use it will get on our accounting server. I guess I'll have to use vi (sigh). Change to the /etc directory and open the configuration file with the vi text editor:

cd /etc [ENTER]
vi /etc/ld.so.conf [ENTER]

Once you have the file open, add the following lines:

/usr/local/mysql/lib
/usr/local/lib

To the file and save your changes. (Yes, I know: :wq! and all that. It sux pond water, but we have to try and get along...) (Ed. Some people just can't recognize true elegance.)

Next, we enter the command that causes our newly edited configuration file to be re-read:

ldconfig

Or, if you have bollixed up your path through some earlier play:

/sbin/ldconfig

See man ldconfig if you are one of those nosy types.

Step 13. Personal Home Page?

...Pigs Hate People? Pa Howls Pleasingly? No. We are informed this is yet another "recursive acronym," and remain Puzzled as to How the first P fits into the recursion!

Oh well. You can learn more about the PHP Hypertext Preprocessor at its site and pick up some additional information at Zend.

Oh, you say you "don't care, and just want to get it done and over with?" Aaah, gentle reader, you are the future of IT. Enter the following commands, in the order presented, check your "speling" let it line wrap as you type the configuration options and take a break during "make" (My Pentium 90 took 32 minutes to compile PHP):

cd /tmp [ENTER]
tar xzvf php-4.1.1.tar.gz [ENTER]
cd php-4.1.1 [ENTER]
./configure  --with-apxs=/usr/local/apache/bin/apxs 
             --with-gd-dir=/usr/lib  
             --with-mysql=/usr/local/mysql 
             --with-jpeg-dir=/usr/lib 
             --with-png-dir=/usr/lib 
             --with-zlib-dir=/usr/lib 
             --with-pdflib-dir=/usr/local/lib 
             --enable-trans-sid 
             -enable-memory-limit [ENTER]
make [ENTER]
make install [ENTER]

Step 14. Fiiiiiinally, Financial Accounting HAS COME BACK TO LINUXWORLD!!!!

(Sorry about that, but two of my kids are into pro-wrestling, and I hear "The Rock" yelling like this on TV at least once each week. It sort of takes over the frontal lobe, if you know what I mean..."IT DOESN'T MATTER WHAT YOU THINK I MEAN!" ) The time has come to prepare to install Nola. We simply unpack Nola under /usr/local/apache and edit some files in Apache so that Nola's php scripts create the dynamic site content our users see and interact with. There's no "./configure-->make-->make install" here -- we just uncompress it.

Copy nola-1.1.1.tar.gz from wherever you stored it to ../apache. We will assume you put it in /tmp:

cp nola-1.1.1.tar.gz /usr/local/apache/ [ENTER]

Change to this directory:

cd /usr/local/apache [ENTER]

And unpack the compressed file:

tar xzvf nola-1.1.1.tar.gz [ENTER]

Now we fire up that sucky old (Ed. Make that, "svelt and seasoned") vi text editor again. Change directories:

cd /usr/local/apache/conf [ENTER]

Open the configuration file:

vi httpd.conf [ENTER]

Scroll down to a line that reads:

DocumentRoot "/usr/local/apache/htdocs"

Change that line to read:

DocumentRoot "/usr/local/apache/nola"

Then continue scrolling down until you encounter a line that reads:

Edit this line to read:

Now scroll down until you encounter:

# DirectoryIndex: Name of the file or files to use as a pre-written HTML
# directory index. Separate multiple entries with spaces.
#

    DirectoryIndex index.html

And change:

index.html

To:

index.php

You're not done! Continue scrolling downward until you reach:

#AddType application/x-httpd-php .php

And "uncomment" this line, in other words, delete the leading hash mark (#) from it so that it isn't ignored when Apache reads the file.

Now, save your changes to httpd.conf and close the file. (Wheeew!)

Step 15. The last few operations

We're almost there! (The excitement is palpable, the tension is building... NOT)

./nola has to be "owned" by user "apache."

cd /usr/local/apache/ [ENTER]

Change the file ownership of the nola from "root" to "apache:"

chown -R apache:apache nola [ENTER]

Now start the MySQL beastie:

cd /usr/local/mysql/bin [ENTER]
./safe_mysqld --user=mysql & [ENTER]

And crank up the Apache Web server:

cd /usr/local/apache/bin [ENTER]
./apachectl start [ENTER]

Nola comes complete with database tables and some initial data for MySQL and we must install them under MySQL's directory. First we change to location of the tables and data as delivered by Noguska:

cd /usr/local/apache/nola/documentation/sqlscripts/MySQL [ENTER]

Then we copy them over to MySQL:

/usr/local/mysql/bin/mysql < database.sql [ENTER]

Which creates a database named noguska under /usr/local/mysql/var which won't do us any good if we don't put a little data in it, so:

/usr/local/mysql/bin/mysql noguska < filldata.sql [ENTER] Now we enforce some rules:

/usr/local/mysql/bin/mysql mysql -e "update user set host='%' where host='localhost' and user='root'" [ENTER]

And then:

/usr/local/mysql/bin/mysql mysql -e "delete from user where user=' '" [ENTER]

Followed by:

/usr/local/mysql/bin/mysql mysql -e "flush privileges" [ENTER]

Are we there yet? Huh? Huh?

Almost. Be patient. We need to set this up so that Apache and MySQL start at bootup. We are also going to provide some "Cheap and Easy" security for this box, even though it is on our LAN and behind our firewall, before we go home for the evening.

First, the matter of starting things at boot up. We are going to add some lines to /etc/rc.local to execute after the normal system startup scripts run. Change to the /etc directory:

cd /etc [ENTER]

And open rc.local with vi:

vi rc.local [ENTER]

Here is the content you will add to the file:

#
/usr/local/apache/bin/apachectl  start 
/usr/local/mysql/bin/safe_mysqld --user=mysql &' '
sleep 8
clear

Save your changes to the file. Why the "sleep 8" and "clear" lines? Try it without them. If you don't get a "Starting MySQL..." line plastered all over your login prompt, you don't need them. If you do, go back and add them.

Now for some "Cheap and Easy" (Cheap and Nasty?) security before we go home. Red Hat provides an ncurses-based utility under /usr/sbin that provides root with access to basic system configuration utilities. As root (everything you have done today has been as root):

setup [ENTER]

You will be whisked away to:

"Firewall configuration" will take you directly to "Gnome Lokkit," which permits you to define the kernel firewall rules for this machine (not to be confused with the need for a separate firewall between your LAN and the outside world). You can prevent everything but "WWW" connections for now, by selecting the "Customize" key under "Lokkit."

"System services" takes you to Red Hat's ntsysv: a simple-to-use utility for selecting which services are started at boot up. There's no need to increase your exposure by running daemons you don't use. Turn off stuff like telnet and lpd, because they simply increase your exposure.

On most small business LANs, these simple steps will provide far more security than your neighbor can achieve with a Windows-based accounting solution, and should be more than enough for most users. You'll note some "glaring omissions," for example, we haven't changed the mysqladmin password, and we are running the old version of zlib. Oh well...we've waited long enough.

Reboot your Nola accounting server and point your browser at it

I won't bother to show you the login window...you have seen it before and you handle it! Login as "admin" and use "password" as your password.

The left frame that appears, includes an "ADMIN" selection. Click on it and edit user admin to change your Nola administrator password to something more secure than the default "password." Logout, by clicking on the "LOGOUT" selection at the bottom of the left frame.

Then get up and go home. When we return with Part 16 of our series, we will immediately upgrade Nola to the latest stable version, now at 1.1.2 -- an easy process. Tomorrow you can play with the version we just installed. For now, you're too tired to do anything but sleep (and if you aren't -- I am!). Turn out the lights and watch for Part 16.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...