Using Linux in an Office EnvironmentArthur Donkers Although Linux is very popular in certain circles, many people still regard it as a toy operating system, or something for the freak, and do not consider it a full-fledged alternative to the more established commercial UNIX implementations available for the PC platform. An increasing number of companies, however, are starting to use Linux, often as a network-based server for intranet or Internet applications. In this article, I explore the potentials of Linux in a day to day office environment. More than a year ago, Le Reseau was approached by AXY Management Systemen, an application developer based in the Netherlands. They had developed an integrated office application that enables users to send direct mail, make letters, and perform other office-related tasks. All of the data is stored in a database for easy retrieval and integration. Until then the company had used the more common UNIX implementations on the PC platform. However they were not completely satisfied with that combination. First, the support by the supplier was not good enough. They had encountered a number of problems while developing their application, and their supplier could not resolve them easily. Furthermore, the platform did not offer a number of features (symbolic links) they needed. Second, using that particular version of UNIX forced them to use big PCs with large amounts of memory and disk space to accomodate the average number of users. We found through some experimentation that Linux was capable of supporting more concurrent users than the other UNIX implementations on the same hardware. Together we set out to find a better alternative for their basic system configuration - a system that offered more bang for the buck. Requirements The application is based on the Applixware Office Suite that is available for a number of UNIX platforms. And indeed, Applixware is also available for Linux. Their application is partly written in the ELF language of Applix. ELF is a kind of integrated development environment for Applix that enables a developer to easily integrate his or her own application into the Applix office suite. Another part of their application, the database, is written in C. Porting their application to the Linux environment did not prove to be a real problem. The ELF part of the application did not need to be ported because it runs completely in the Applixware ELF environment. The database just needed a rebuild for the Linux platform. It even turned out that the database was easier to build on the Linux platform because Linux is "closer" to the original source. When it turned out that porting the application itself was not a real problem, we could then focus on the other requirements related to maintenance and support. Keep in mind that acquiring a system and implementing one or more solutions on it can cost a lot of money. These costs are very visible because they appear on the bills from the suppliers/implementators and other people that are involved. Also, once the system is up and running, other costs will start to accumulate. These costs are related to the maintenance and support, and normally consist of wages for the people doing the day-to-day maintenance, support contracts, and other related areas. Due to their differentiated nature, these costs are paid for by different departments or come from different budgets. These costs accumulate over the life cycle of the system, which is typically between 3 to 5 years. And although each of the different parts may be relatively small, adding them up over a period of 3 years will amount to a very large sum indeed. This sum will generally exceed the costs of the initial implementation five or to ten times. So when you really want to save some money, you should reduce the costs of the maintenance as much as possible, without sacrificing the quality of the maintenance itself. This philosophy is also the reason behind systems like the Network Computer and Zero Administration Windows. All of these computers run without the ability for the user to change the hardware or software settings (one of the main reasons that support costs can run up very high indeed). Bearing these things in mind, ease of maintenance and support is an important requirement. How this is achieved is described in the next paragraph. Standardize To achieve easy maintenance, the first objective is to standardize on the hardware platform. This can be a bit difficult since the hardware market is changing very fast. What used to be a high-end platform becomes a basic platform in 3 months time. Consider the clock speed of the low-end Pentium processors; 6 months ago a Pentium 133 Mhz was a medium-range processor. Now, it is the slowest Pentium available. So, picking a certain motherboard/CPU is not the best way to standardize. There is no need to restrict yourself in this way because Linux is rather forgiving about the motherboard and CPU it runs on. You do not need to recompile the kernel each time you use a different motherboard/Pentium combination. It is important, however, to select an A brand motherboard from a reliable supplier. The A brand is necessary since the system will be used 24 hours a day, 7 days a week. You also need a reliable supplier so that faulty hardware can be replaced on the spot. Standardizing peripherals like the disk controller and network adapter is far more important. Changing one of these means rebuilding the kernel, reinstalling it, and rebooting the system. We decided to standardize on an Adaptec 2940 SCSI controller (either the Ultra or the Ultra Wide version - both are supported by the same kernel driver in the Linux kernel). The Ultra version is used for smaller servers with a limited number of users. The Ultra Wide version is used for the bigger servers that can support a larger number of users. Either controller is supported by the same hardware, and there are no differences for the users and application developers. The main reason for selecting this controller was the availability through the same supplier as the other hardware. For the network adapter, we selected two 3Com cards, one of which is the venerable 3C509B (also known as the Etherlink III). This card has both a coax and a UTP connection, and by configuring it once you can select the proper interface. When configuring this card, you also need to disable plug-and-play because Linux does not always handle plug-and-play cards correctly. Furthermore, using plug-and-play makes for a more complex setup and thus complicates maintenance. Note that Linux can use plug-and-play cards. Using special software called ISAPNP, you can configure plug-and-play cards. The newer 2.1.x kernel even has PnP support built-in. However, the more software you add to a system, the more complicated it gets. When you use special software like ISAPNP, you cause the correct operation of your hardware to be dependent on a piece of software. Thus, if your ISAPNP configuration is corrupted, it may turn out that you no longer can use the network card making the system inaccessible to your users on the network. If you instead configure the network card to a fixed I/O address and interrupt, the correct functioning of the hardware will be independent of the software (in this case ISAPNP), greatly enhancing the reliability of your machine. This enhanced reliability will definitely reduce the maintenance effort. The other card is a 3Com 905, which is a PCI card. For this card you cannot preset an I/O address or interrupt; this is done by the PCI bios when the system is booted. Each of these peripherals is configured in a standard manner, and the SCSI controller autoconfigures itself. All SCSI peripherals, like disk, tape, and CD-ROM are set to a standard ID scheme. Disks always are set to SCSI ID#0 and #1; a tape is set to ID#2; and a CD-ROM is set to ID#5. To enhance the reliability of the system, the disks are not built into the system case itself, but into a separate external drive casing. Whenever a drive fails, it can be easily replaced with a new one without disassembling the machine. The network adapter is always set to the same I/O address and interrupt level, resulting in a number of advantages. First, once you have found a proper setting, it will work in all systems. Second, you can stock a number of preconfigured network adapters. You can quickly ship a network adapter whenever one fails in one of the systems. The last advantage involves maintaining all of the systems. Whenever we need to track down a problem, we know which settings are used for a card, no matter which system we are working on. If it makes sense to standardize on hardware, it is an obvious necessity to do so on the software front as well. By using a standard distribution, you can ensure that all machines run the same versions of the different programs and kernel. Whenever an error occurs in a specific version of a program, it should be easy to upgrade, and to perform the same task on other systems as a precaution. All systems are based on the Caldera OpenLinux BASE distribution. This is a commecially graded version of Linux with sufficient backing from Caldera. By the way, for all the Red Hat fans out there: this also applies to the Red Hat Linux, but Caldera comes equipped with the Looking Glass drag-and-drop desktop. This desktop makes it easier for inexperienced users to make the most of the Linux system. The following features have been enabled on the Linux server.
. All of these software components are preconfigured the same way and stored on the same location in the file system. This aids in making all the different servers as similar as possible. Based on these standard software packages, Le Reseau has added a number of things to make the maintenance as efficient as possible. Maintenance Measures All of the servers are maintained by Le Reseau. These servers are installed on different locations throughout the country, so the main goal is to allow maintenance tasks to be performed remotely. For this purpose all servers are equipped with a dial-in modem, or a dial-in ISDN connection via the firewall. This firewall is an optional component of this setup that will provide secure and safe access to the Internet. Dialing in can be done in two ways, either straight through PPP or through a dial-in terminal session. With PPP, multiple telnet, web, and ftp sessions can be established with the server. Through these sessions new software can be uploaded, and essential log information can be downloaded. When for some reason a PPP connection cannot be established, a normal dial-in terminal session can be established. This is just like connecting a terminal to the server. It has its limitations; with a regular terminal setup, no multiple sessions are possible, and you can only upload or download software using the Zmodem protocol. However, as a fallback, this is adequate enough. Whether a PPP or a terminal session is established is determined by the dial-in server, mgetty. Newer versions (0.98 or higher) of this well-known dial-in server are capable of determining which kind of dial-in service is requested. By configuring the AutoPPP feature in the login.conf file, you can specify which PPP daemon needs to be started whenever an incoming PPP connection is received. Note that you will have to compile mgetty with the "autoppp" feature enabled (see the Makefile for the actual option). So whenever a problem occurs, we can dial-in and check the system for any problems or errors. We have also partitioned the file system on the server in such a way that a user will never be able to fill up a file system that is also used by the system itself. For this purpose, we have created the following file systems:
Filesystem mounted at size (root) / 64 Mb (user) /usr 600 Mb (logs) /var 400 Mb (application) /opt 300 Mb (home dirs) /home 700 Mb
The root file system contains all files needed to boot the system; and the /usr file system contains all additional software like Samba, email, and fax software. The graphical software is also stored in the /usr part of the file system. The actual application and its associated data are stored in the /opt file system. No other data is stored here. All the home directories of all users (with the exception of root) are stored in the /home file system. If a user fills up this system, it will not interfere with the system-related file systems. All logging, spooling, and the Samba-exported directories are stored in the /var file system. Most Samba directories are exported read-only since they contain network-wide applications and static data. Most changes in a file system are restricted to the /var and /home file system. All other file systems are rather static, and the more static a file system is, the less chance it will be corrupted. Currently, it is not possible to mount most of these static file systems read-only, because too many system utilities need write access to files on them. For example, whenever you change a password, the new password is written to the /etc/passwd file stored on the root file system. As mentioned earlier, the Linux server also doubles as a DHCP server. Through DHCP (which is a superset of BOOTP), all client systems are provided with their network configuration. This DHCP software is still considered Beta, but it offers the ability to centrally administer the network configuration of all the clients. This advantage outweighs the disadvantage of the Beta part. The DHCP software can be configured statically or dynamically. When configured statically, the configuration of a client, especially its IP address, is bound to its Ethernet address. Every time the client boots, it will receive the exact configuration as the last time. When configured dynamically, the IP address of a client is selected from a pool of available addresses. This pool is maintained in a leases file, which contains the actual relations between the Ethernet address and the IP address. At first, we opted for the dynamic configuration. However, whenever a change was made to the DHCP configuration, the leases file had to be removed and all clients needed to reboot. This is not a preferable situation for the users, so we migrated to the static configuration in which all clients are allocated one predefined IP address. Preventing Problems A lot of effort has gone into setting up the system to provide the highest availability and lowest maintenance possible. But still a large number of problems may occur due to user error, system malfunction, or other things. To detect (or even better, prevent) these problems, we developed a special program that keeps an eye on the proper functioning of the system. This program is called sentry, and it is capable of performing a number of regular checks. Each of these checks keeps a close eye on one or more system parameters. Whenever such a parameter exceeds a predefined limit, sentry will send email to an emergency account at Le Reseau. We can then take immediate action in checking the system, solving the problem, or warning the users that something may go wrong. The sentry system consists of a framework that enables us to add special files that check for certain features on the system. These checks can be performed each time sentry runs (which is every minute on a normal installation) or once a day. The daily checks are mainly for checking logfiles and other files for certain error messages. The sentry framework is shown in Listings 1 and 2. The file sentryfun can contain functions that are available to all check files. An example of this sentryfun file is shown in Listing 2. An example of a check file is shown below. It is df.chk, and it checks the disk usage on the system. Whenever it exceeds a predefined limit, a message is sent to Le Reseau. We are currently developing software that will enable us to send an SMS message to one of our cellular phones, just like sending a message to a pager.
.. $SENTRYDIR/sentryfun
Setchecktrap
df | awk '/^\/dev/ { print $0; if ($5 > "98%") \The return value of this script is set to a message that needs to be mailed. This mailing will be done by the sentry script. Conclusions Although this is not the hands-on type of article I usually write, I hope to have shown that Linux can be used in an office environment and provide at least the same (in my humble opinion better) level of reliability that is available from commercial vendors. It can do so at a better price/performance ratio on the same hardware. Furthermore, you can extend the environment of your server so it will detect problems in an early stage and take appropriate measures. About the Author
Arthur Donkers graduated from the Delft University of Technology with a degree in Electrical Engineering, and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands. His primary field of interest is in datacommunications, especially the security aspects involved. He now is the founder and owner of Le Reseau, a company specializing in security-related issues for UNIX, OpenVMS and Windows NT, and the application of Linux in corporate environments.
|