The All Linux Office
Bryan C. Andregg Linux is the low-cost, high-powered Internet serving environment that is being adopted by many companies as their server room operating system, and that's all its good for. This popular sentiment is changing as more people are watching the growth of the Linux desktop with a close eye. Projects like GNOME (GNU Network Object Model Environment) and KDE are providing the base, while companies like Corel and StarDivision are providing the applications. This combination offers the user a familiar drag-and-drop, window-based desktop in addition to the stability of Linux. The remote manageability and native Internet Protocol support gives administrators more time to really focus on their other jobs: reading news and playing Quake. This article provides an overview of how to set up an all Linux office that's compatible with users' expectations. User Desktop Environments Desktop environments like GNOME and KDE seek to provide, as the project description (see http://www.gnome.org) says, "a complete, user-friendly desktop based entirely on free software." The features of such a desktop are familiar to those people who use Microsoft and Apple products: drag-and-drop, window-based configuration, integrated help documents, to name a few. These environments do not replace the window manager, which determines what menu choices are available and what the individual windows look like. Instead, window managers should take advantage of the desktop and make use of its features. KDE, (see http://www.kde.org), is the more mature of the two environments, and according to the Web page, "KDE is a completely new desktop, incorporating a large suite of applications for UNIX workstations. KDE includes a window manager, file manager, panel, control center and many other components." Both GNOME and KDE have something to offer the end user and are easy for the administrator to setup. KDE can be installed by downloading the appropriate packages from one of the many mirrors listed at http://www.kde.org/mirrors.html. It also comes as part of many Linux Distributions. The base set of packages required to run the "K Desktop Environment" are kdesupport, kdelibs, and kdebase. To make KDE a fully functional desktop for users, it is also recommended that the following be installed: kdeadmin, kdegraphics, kdemultimedia, kdenetwork, and kdeutils. Obviously, kdegames and kdetoys are equally important. Documentation can be found in the above packages or can be found in one of 14 languages on the Web site. Internationalization of both KDE and GNOME has been a goal from the start of the projects. The KDE desktop requires a special library from Troll Technologies in order to run. This library, Qt, is available at no cost from http://www.troll.no/dl/. The license for Qt is a bit different from the normal GNU Public License that most people associate with Linux, so it should be read closely. Once this library has been downloaded, it is just a few simple steps to have KDE up and running.
1. Install the Qt library and the KDE packages. 2. Make sure that the loopback device is properly configured. 3. Set the PATH environment variable to include the KDE bin directory. 4. Set the KDEDIR environment variable to base the KDE directory. 5. Edit the X Window start scripts (.Xclients or .xsession) to include just startkde.
Once KDE is running, configuration is as easy as reading the on-line help and using the window-based tools (see Figure 1). GNOME is the newcomer in the race to provide a fully functional desktop environment, but is rapidly growing to maturity. Reaching its 1.0 release at the writing of this article, GNOME's goal of not relying on any software that is not under the General public License (GPL) or the Library General Public License (LGPL) sets it apart from KDE. Unlike KDE, which provides the K Window Manager, GNOME doesn't provide its own window manager but instead expects the user to run a window manager that is "GNOME aware." The most popular window manager to run with GNOME is E or Enlightenment, available with Linux distributions or on its own from http://www.enlightenment.org. GNOME has been selected by both the Red Hat and Debian distributions to be the desktop of choice for upcoming releases. Installing GNOME is no more complicated than installing KDE. There are more packages that need to be installed, but under most major distributions this is a very simple process. The list of packages can be found at:
http://www.gnome.org/start/getting-rh.shtml These include the GNOME packages: gnome-core, gnome-libs, and gnome-objc, as well as support packages, such as esound. The steps to getting GNOME running are as follows:
1. Install the GNOME packages. 2. Edit the X Window start scripts (.Xclients or .xsession) to include just exec gnome-session.
GNOME and the Enlightenment window manager will be started and, like KDE, on-line help and a configuration window can be used to fine-tune the desktop (see Figure 2). Once the user has logged in and is using GNOME and KDE they are presented with a pretty standard desktop that includes a "panel" for launching applications, a trash can or "recycle bin" for dragging files to deletion, and a graphical file manager. This file manager is at the heart of both systems because the main complaint from Microsoft users is that the command-line interface is non-intuitive. The file manager seeks to provide easily understood icons as well as a way for users to drag those icons to the desktop, panel, or an application to start. The interactive help systems for both KDE and GNOME are HTML-based and are easy for a local administrator to edit or add to for local customizations. Users can even surf the Web from their help guide, but it doesn't look as nice as lynx. Interoperability There are thousands of applications available for Linux. Unfortunately, when the boss demands to run Quicken at work in order to balance her personal checkbook, it is the administrator's job to make sure that she is happy. Although it is possible to set up workstations and laptops to be able to boot either Linux or another operating system, it makes more sense to pool resources and be able to provide a company-wide solution. One such product on the market is Citrix Metaframe (http://www.citrix.com), which lets a Linux (or other UNIX) access applications from a Windows NT Terminal Server. This also has the added advantage that the Metaframe client can allow the administrator remote access to the NT machine for configuration. The hardware requirements for the Citrix server revolve around RAM, with each session using approximately 4 Megabytes unshared just for the client connection. Depending upon the application, this number could be much higher. The software required includes the Windows NT Terminal Server, some number of licenses for the aforementioned, and the Citrix Metaframe software with some number of licenses. Installing the Metaframe server is pretty straightforward; however, the documentation for administering it is a bit lacking. The client requirements for hardware are negligible, and the software that needs to be installed requires less than 3 Megabytes of space. The client software is installed by default into /usr/lib/ICAClient, and starting the client is as easy as running the command:
$ /usr/lib/ICAClient/wfcmgr This will present the user with an X Window interface to creating connections to the Metaframe server or activating those connections. It is possible for the administrative side of Metaframe to get quite complicated depending upon what Microsoft-based needs exist. It is possible to grant access on an application-by-application basis, either to individual users or to NT groups. It is also possible to grant access to a desktop login that will present the user with an entire NT desktop in a window on their desktop. Hard drive partitions local to the client can be mapped to the server, and server partitions can be mapped local to the client (see Figure 3). Traveling Users Users on the road need to be able to access their mail, internal Web sites, and other information to stay productive. The problem of security in all of these processes becomes even more complicated if the company doesn't offer direct dial-up access and instead requires employees to use an ISP. For the user to safely get the information they need, it may be necessary that the administrator enable them to create a Virtual Private Network (VPN). CIPE, Crypto IP Encapsulation, provides just such a service, see:
http://sites.inka.de/sites/bigred/devel/cipe.html CIPE includes a kernel module, cip3b0, and a daemon, ciped. Each end of the tunnel needs to have both items installed and the daemon started. Configuring CIPE is as easy has having one file on both endpoints called /etc/cipe/options that is root owned and mode 0600, since this is where the private key used in the encryption is stored. The configuration for CIPE requires a few pieces of shared information: encrypting key, tunnel IP addresses, tunnel port, and the real IP address of both end points. Once the tunnel is up, a simple set of routes to direct access to internal resources through the tunnel is all that is required. Depending upon corporate policy, all data may have to go through the tunnel, which is a matter of setting the default route. Assume the remote network is 192.168.0.0/24:
# route add -net 192.168.0.0 netmask 255.255.255.0 dev cip3b0 # route add default gw 192.168.0.254 The CIPE configuration is simple, relying on five pieces of information:
1. The real local and remote IP addresses. 2. The private tunnel addresses. 3. The port to be used for the exchange. 4. The device names. 5. The shared private key.
A sample configuration, /etc/cipe/options, looks like:
device cip3b0 maxerr -1 ptpaddr 10.0.0.1 ipaddr 10.0.0.2 key 643408de668188f3e732cb08b51532c4 ciped is then started, passing some information on the command line:
# ciped me=$LOCAL_IP:$PORT peer=$REMOTE_IP:$PORT Additionally, users on the road need to be protected against possible attacks when they are dialed into foreign networks. The best way to do this is to make use of the native packet filtering capabilities in the Linux kernel. In the 2.0 kernel series, these are accessible via the program ipfwadm(8), and in the 2.2 kernel they are accessible using ipchains(8). Both programs come with a fair amount of documentation and examples. A strict packet filter is the smart choice, and one that only allows data from the encrypting tunnel or from locally initiated connections is generally as loose as it should get, remembering that the tunnel addresses and ports ($REMOTE_IP and $PORT) need to be allowed.
# ipchains -P input REJECT # ipchains -F input # ipchains -A input -j ACCEPT -p udp $REMOTE_IP $PORT # ipchains -A input -j ACCEPT -i cip30 # ipchains -A input -j ACCEPT -i lo # ipchains -A input -p tcp ! -y CIPE can be used not only with dial-up users, but also between remote office sites that have dedicated access. In this way, Linux can extend the desktops reach without the need to pay for very expensive dedicated devices from companies such as Cisco or Checkpoint. Administrators can then work from across the country or the world to ensure that users have access to the resources that they need. Installation Administrators who are used to workstation installations taking a large part of their day should note: now it is possible to install a hundred machines in a day and still have time for Happy Hour! The trick is a feature of the Red Hat installation process called Kickstart. Kickstart makes use of a configuration file either on a floppy or served from the network. This configuration file tells the install process everything from how to partition the hard drives to what packages to install, and even what to do when the install is done. An example Kickstart file begins like this:
lang en network --bootproto dhcp nfs --server k.redhat.com --dir /mnt/5.2/i386 keyboard us This sets up the install language, keyboard option, and specifies how the install is to locate files, using NFS k.redhat.com:/mnt/5.2/i386, and how the machine should configure its Ethernet interface: at boot time with dhcp. Disks are partitioned using a set of part commands, which take a number of options for size:
zerombr yes clearpart --all part / --size 256 part swap --size 96 part /usr --size 1 --grow part /opt --size 1 --grow --maxsize 1024 This first example clears any invalid partition table that might be found on a new disk, clears any and all partitions that exist on the disk from a previous installation, and then creates four partitions. The last two examples are the most interesting because they demonstrate dynamic partition sizing and applying limits to that sizing. Before package selection and finalizing the install, the setup of the workstation must be finished:
install mouse --kickstart generic3ps2 timezone --utc US/Eastern xconfig --monitor "LCD 1280x1024" rootpw FooBar lilo --location mbr This section specifies whether this is an install or an upgrade, sets up the last of the hardware, and sets an initial root password (which can be encrypted if preferred). Package selection is accomplished in the %packages section and can be done using individual package names as well as component groups, which are specified by a @:
%packages @ Networked Workstation @ Dialup Workstation @ C Development ypbind autofs There are two special component groups, @ Workstation and @ Server, which can be used in standard installations. After the package selection comes the most interesting part of the Kickstart file, the post installation section:
%post echo 'Kickstart `date`' > /etc/motd mount 192.168.0.1:/mnt/install /mnt /mnt/local-configure At the very simplest, this section can modify local files to record that Kickstart was used. More complicated examples include using NFS to run local configuration scripts that can make use of everything but name-service. Administrators should be able to boot machines into the install, turn the machine off when it's done, and put a fully functional workstation on a user's desk, all without ever typing anything more than linux ks at the install prompt. All of the time saved by not answering install or upgrade questions can be used to hone Quake skills! Configuration Linux distributions have a decided advantage over other operating systems when it comes to managing the software that is installed. The reason for this advantage is the Package Manager. Many administrators who like a fine amount of control over their software do not like package managers for the wrong reasons. They think that packages have to come from the vendor. The best part about package managers is the ability for the local administrators to build their own local, pre-configured packages. Packages can be installed via ftp, NFS, or even HTTP (Web-based). This means that local repositories can be kept on an Intranet and workstations can be updated by issuing a few rsh commands. Instead of building and installing the latest Sendmail on 100 workstations because of a security problem, and worrying about library and mail client dependencies, you can install a new package and resolve all of the other requirements at the same time. Additionally, local files can be checked against modification using the package databases. Both the RPM Package Manager and the Debian Package Manager offer a full set of features to make upgrading software and configurations as easy as possible. For an example of how packaging can help, consider a local distributed /etc/printcap in a large office. Ideally, all machines in the office should share the same file, this eliminates administrative confusion and lessens the amount of time spent trying to diagnose problems. This package could be called:
printcap-1.0-1.noarch.rpm. When new printers are added and old printers are removed and a new printcap needs to be distributed, it is a simple matter of creating a new package with an increased release number and installing it:
# rpm -U printcap-1.0-2.noarch.rpm If a workstation is having trouble printing, the file can be verified for changes:
# rpm -V printcap To see what has changed between the various releases of the package:
# rpm -q --changelog printcap Additionally, if the printcap package relies on a set of filters being installed, which is considered a separate package, then dependency information can be conveyed during an install or upgrade:
# rpm -i printcap-1.0-1.noarch.rpm
printcap requires print-filters >= 1.0
This allows administrators to spend less time troubleshooting without background information. Conclusion As you can see, Linux can provide regular users with a stable, easy-to-use, environment that offers all of the familiar features of other operating systems but runs more reliably. Users also can run their favorite MS Windows programs without requiring additional workstation resources. Additionally, users can work off site with very little additional administration, thus reducing certain costs. For administrators, Linux offers a stable serving environment that will reduce the number of complaints about down time and poor performance. This combination of benefits gives everybody more time to get real work done, more time to play games and read news, and that's what keeps everyone sane. |