Linux Means Business: Linux for Internet Business Applications

Building an Intranet soon became our next initiative. We installed the Apache WWW server and the Samba Netbios server on the same Dell Linux server. Samba was used to export Linux directories as public shares from the largely Windows 95 user base, or as password-protected private shares for Internet Services, our department. Other departments started attaching data to our Intranet at an amazing rate. Clearly, this simple but powerful technology had filled a big need for information-sharing tools. Both Apache and Samba functions are heavily used throughout the company and have held up quite well. In fact, although we have since off-loaded some functions to other servers, for several months one Pentium Pro-based server running Linux ran mail, DNS, central logging, IMAP, SMB and WWW for over 1000 users with little or no downtime.

We used native Linux tools such as the DBM database and Python utilities such as the calendar suite to add useful content to the Intranet as well. We publish a phone list, which is frequently updated, and a list of Ruppman clients. We keep a calendar of Internet Services activities and schedules on the Intranet and access to a database of people with proxy access to the Internet.

These systems quickly brought Ruppman to a point of basic Internet competence, but far more was required. Preparing for the future of customer service on the Internet involved quite a bit of application development, so a team was assembled in my group for this purpose.

The development team began using a combination of C, C++ and shell scripts, but we quickly settled on Python as our overall development language. Our lead software engineer and I had used C++ as the cornerstone of our previous careers, but we soon came to admire Python's expressive power, comprehensive library and clean syntax. We purchased a Compaq ProLiant 2500 (Pentium II, 300MHz, 64MB RAM) as a development server and failover backup. We anticipated running SCO UNIX on it, but being used to the broad toolset that comes with Linux distributions, we found SCO UNIX to be woefully inadequate in comparison. Efforts to compile or install our favorite tools proved so cumbersome that we quickly abandoned SCO for Caldera OpenLinux. Unfortunately, we then found that Compaq servers are not well-suited for Linux. Compaq adds many proprietary features for its ManageWise server management suite and has not ported the “agents” for these features to Linux, so much of the machine's design has to be bypassed in order to run Linux. Perhaps for this reason, this machine has proved rather slow running Linux, and we are in the process of replacing it with a Dell Poweredge 4200 (Dual Pentium II, 300MHz, 64MB RAM).

The first major development task was to create an Internet dealer locator. This popular web site feature is an application that allows the customer to enter his or her address or zip code, and receive a list of nearby dealers or service centers. Ruppman already had such an application running on a mainframe for telephone representatives, but Internet Services decided to build a locator from scratch using an object-relational database and a geographic-matching (geo-matching) module. We chose PostgresSQL as the database, because it is object-relational and supports spatial relationships (r-trees). It also has a native Python interface, PyGres. The resultant application is heavily disk-I/O bound, and we ended up buying a Sun Ultra Enterprise (Dual UltraSPARC2, 250MHz, 128MB RAM) for its high-bandwidth backplane and its hardware scalability. I have since come to learn more about comparable Linux-based setups on Alpha and even Sun boxes.

Another product developed in my group is a Usenet and web monitoring service, where we search Usenet and the WWW on behalf of clients for consumer discussion of their company or product. First, we clip articles according to a search engine, then our representatives check the clips for relevance. We set up a Linux server and installed NNTP on it, so that /var/spool/news can be searched with a Python script that invokes a recursive grep. Hits are then accumulated in a file which is combed by a representative using a custom web interface.

Many of the powerful web-based applications that were developed so rapidly and at such low cost by my group at Ruppman quickly caught the attention of other departments. Accounting had been trying to implement technology to automatically track employee labor, and had been burned by their experience with an expensive and unsuitable vendor product. They asked us if we could implement a solution. We quickly put together a system that kept increments of time and the codes identifying tasks in a PostgresSql database on a Linux server. Employees can enter their hours through a web interface driven by Javascript and Python CGI, hosted on the Linux Intranet web server (see Figure 2). They can also view the results in a familiar time-sheet format. Supervisors can then review and approve the entries. Once a week, a cron job computes overtime and sends a report of the approved records to accounting, where they are imported into the JD Edwards accounting software.

Figure 2. Employee Time Log

Managing all of these projects and moving them from development server to production soon became a confusing task. Since most of our projects were web-based, we had to move HTML files to the correct HTTPD document directories on the correct servers, CGI executable files had to be specially handled, and we had to maintain libraries of common Python modules. We adopted CVS for revision control, but we couldn't find a general utility to manage even most of our needs, so we wrote a custom tool in Python and Javascript (see Figure 3). The development manager, as we call it, reads a configuration file on the development server which keeps a list of projects, source files and destination locations for publication. It then allows the user to view projects, publish files from the projects, and interface to version control.

Figure 3. Project Development Manager