You stay on the bleeding edge of the technology curve, and the release number (or name) of your OS is your moniker. It’s inevitable, however, that the distributions higher up the food chain will send out new releases like candy from a piñata!

As you take each small step with minor releases (i.e., 6.0 to 6.1 to 6.2), you notice very little difference. As you leap the grand hurdle of major releases (i.e., 5.2 to 6.0, 6.2 to 7.0), the challenges are somewhat more difficult. I’ve been lucky enough to leap over three of these hurdles: from Red Hat 4.2 (Biltmore) to 5.0 (Hurricane), from 5.2 (Apollo) to 6.0 (Hedwig), and from 6.2 (Zoot) to 7.0 (Guinness). Throughout these leaps, I’ve seen a lot of major changes but none as staggering as the leap to 7.0.

Fortunately for you, I’ve survived that leap and can share my experience with you. In this Daily Drill Down, I’ll give you a helping hand over that hurdle, and you’ll feel nary a stretch!

A look at the obvious
As each distribution makes its way into the major releases, the consumers’ first instinct is to look toward the obvious changes. Both Red Hat and Mandrake put up some pretty solid offerings in the department o’ the obvious. Many of these advancements will affect an enterprise only minimally. (Once we jump into the not-so-obvious arena, you’ll see a much more profound effect. We’ll discuss that a bit later.) Even so, these changes are worth noting simply because they are aimed at garnering more and more users.

The biggest change on the installation front belongs to Mandrake. Not only has it undergone a near-complete aesthetic overhaul, it has taken the installation of Linux—something that is typically thought of as cryptic and for intellectual over-achievers—and created one of the most fundamentally simple and idiot-proof installations known.

Pretty much gone is the guesswork for the Linux installation, all the way down to the configuration of the X Windows system. During the installation on an older Pentium Pro machine (equipped with an on-board, off-brand video card), the Mandrake OS took care of everything. The only X Windows configuration I had to do was to choose which resolution I preferred—something you eventually have to deal with in Windows.

Not only did Mandrake get the X configuration right, it also allowed me to set up a default user so I could bypass the login screen all together! This is quite a step forward for Linux and user-friendliness. Sure, geeks aplenty hold strongly to their roots and to the oh-so-obvious multiuser capabilities of Linux. But there’s a boom of new Linux users who couldn’t care less about how many users can log on to a single Linux machine! With Mandrake allowing the user to bypass (but not get rid of) the login screen (either text or GUI), they’re making a strong stand for the new user. Bravo!

What does this mean for the enterprise IT professional? Quicker, more painless installation and upgrades, greater hardware support (including support for newer cards like the GeForce II MX), and a rapid learning curve. Of course, Linux pundits have been preaching this since the 6.0 releases of their favorite distributions (and I’m certainly not guiltless in that department). This time, however, Mandrake really has hit the nail on the head with its installation process.

Red Hat’s 7.0 release doesn’t greatly improve their GUI (or text-based) installation. Again, as in Mandrake, the big-gun improvements come in the form of the X Windows installation/configuration and the support for more hardware. So much better is Red Hat’s hardware support that it was able to not only detect older and newer cards (AGP, ISA, and PCI type), but to detect the monitor types and proper resolution. Although this is commonplace in today’s industry, it has been a long time coming for Linux—and here it is in full-blown color.

Beyond installation—the desktop
Once the installation is complete, the improvements become even more obvious. Especially in the Mandrake release, the desktop environment is a vast improvement over its last incarnation.

Red Hat still defaults to the GNOME desktop, and that’s just fine with me. The latest GNOME shipped with Red Hat 7.0 is version 1.2 and is a grand improvement over the last official shipment. No more core files and no more hanging processes. Now you will see a leaner, cleaner, and more efficient desktop thanks to GNOME (with a nod to the new default window manager, Sawfish).

The eye popping really begins when you start up Mandrake 7.2 with the default KDE2 desktop! This is sharp and what a desktop really should be all about. You’re treated not only to a simpler interface (and no more X cursor), but to the new Konqueror Web browser/file manager and the highly anticipated KOffice suite of tools. Kudos to Mandrake for shipping with the new KDE!

Outside the obvious
Beyond the desktop, the changes become quite a bit less obvious to the user or administrator and more meaningful at the enterprise level. Most, if not all, of these changes go beyond the GUI and dive into the heart of networking, security, and administration.

Probably one of the most significant changes to either distribution is the migration from the /etc/inetd.conf network service configuration to the /etc/xinetd.d setup.

In the earlier Red Hat releases (> 7.0), in order to enable or disable a networking service you simply commented out the entry for that service in the /etc/inetd.conf file. Typical entries in this file looked like this:
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp wait root /usr/sbin/tcpd in.comsat

When commented out (lines starting with a # symbol), such entries would disable the service.

This system was very simple but inflexible and highly prone to security issues. The new system changes this setup altogether. The newer system, based out of the /etc/xinetd.d directory structure, relies on a single file (/ect/xinetd.conf), which looks like this:
# Simple configuration file for xinetd
# Some defaults, and include /etc/xinetd.d/
 instances = 60
 log_type = SYSLOG authpriv
 log_on_success = HOST PID
 log_on_failure = HOST RECORD
includedir /etc/xinetd.d

This file serves, simply enough, to call upon configured files from the /etc/xinetd.d directory.

From the called directory, the application enables all services that meet these two requirements:

  • ·           They have a requisite file in /etc/xinetd.d.
  • ·           They are enabled within their requisite file.

These requirements are what make this newer system both more secure and more flexible.

As you can see, the last line in the above file actually points to the /etc/xinetd.d directory. The xinetd.d directory houses small shell scripts that call and configure various networking services. The default directory looks like this:
amandaidx daytime finger ipop3
ntalk time amidxtape daytime-udp
gssftp klogin pop3s swat time-udp
chargen echo krb5-telnet imap
rexec talk chargen-udp echo-udp
wu-ftp dimaps kshell rlogin
telnet comsat eklogin ipop2
linuxconf-web rsh tftp

As you can see, there are a number of entries. Each of the above files is actually a configuration file that is used by the xinetd daemon. Why is this more efficient? The primary reason is that instead of having daemons running for each individual service (listed above), you have only one (xinetd) that listens to incoming requests. When a request is received, the xinetd daemon compares the request to the matching file (from the /etc/xinetd.d directory) and, if it is allowed, starts the service.

Taking a look at one of the above files (telnet), we see the following:
# default: on
# description: The telnet server serves telnet sessions;
#it uses \ unencrypted username/password pairs
#for authentication.
service telnet
 flags = REUSE
 socket_type = stream
 wait = no
 user = root
 server = /usr/sbin/in.telnetd
 log_on_failure += USERID

The above file consists of the following:

  • Comments: Anything preceded by a # symbol
  • Service name: Begins with the keyword service
  • xinetd arguments: Everything surrounded by braces

Although you’d think that each configuration file would dedicate itself to configuring the particular service, that’s not the purpose of xinetd. Instead, it’s a more robust replacement for the inetd system of previous Linux incarnations.

But what can you do with this system? Let’s take a look at a service that should be disabled. The talk service allows users to simply talk to each other through port 517. This is an insecure service and should not be enabled.

Within the old Red Hat system (and most other Linux distributions), you disabled this service by commenting out the entry in the /etc/inetd.conf file. The line
ntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd

would then read
#ntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd

The service would be disabled, and the daemon would not be started.

With the xinetd system, you see this /etc/xinetd.d/talk file:
# default: off
# description: The talk server accepts talk requests
# for chatting # with users \
# on other systems.
service talk
 disable = yes
 socket_type = dgram
 wait = yes
 user = nobody
 group = tty
 server = /usr/sbin/in.talkd

Notice in the xinetd argument section the line disable = yes. This is the key configuration for this system. In order for each service to run, you need to do only one thing. If you notice in the comments that the default is on, and you want that service disabled, you simply add an entry (in the xinetd configuration section of that file) to disable the service. Take the former telnet entry, for example. To disable this service, we would add the
disable = yes

option. Now when a telnet call comes into the server, it will not run the telnet daemon. Pretty simple as well as efficient—daemons run only when called!

For those who’ve chosen the Mandrake path, 7.2 still depends on the tried-and-true /etc/inetd.conf configuration file for the enabling/disabling of networking services. This brings up a question regarding the Linux Standards Base: Which (if any) system is right? We have two very different methods of turning on/off networking systems: one that boasts familiarity and one that boasts flexibility. Which will wind up on the cutting room floor?

For you network administrators looking for the system best suited for your environment, your best bet is to simply decide which is more important—proven technology or flexibility. Although the newer xinetd system will more than likely prove its worth rather quickly, are you willing to take the time to learn the new system? It’s your call.

As for my position, I like the direction that Red Hat is taking in networking. I prefer much more flexibility and functionality, and I’m willing to take the time to learn the ins and outs of xinetd.

For both distributions, the inclusion of some enterprise-critical security tools spells much-needed relief for an OS that has been down the tough road of acceptance. Fortunately, the inclusion of both OpenSSH and OpenSSL should give both names a boost in enterprise-level sales.

Encryption has been a prime battleground for Linux users. Prior to the release of the 7s, getting encryption technology included on your Linux servers (or desktops) was best left to the sleuths (in the case of ssh) and the Einsteins (in the case of SSL). With Red Hat 7.0, you can have both OpenSSH and OpenSSL working at first boot. Testing this theory was simple. I had installations of Red Hat 6.2 and 7.0 standing side by side. Opening up a browser on the 7.0 installation, I navigated to and ended up with the Apache test page. Perfectly normal. Entering was a whole new ball game, however. After entering this URL in the browser, I was prompted to accept or decline a security certificate! Upon going through the steps of accepting the certificate, I was transported to the same Apache test page—except that it was using SSL! Now understand that this installation of 7.0 had not been reconfigured and that no other software had been added.

Pointing that same browser to the 6.2 installation with gave me the aforementioned (and mentioned and mentioned) Apache test page. When I attempted to browse with SSL (via, my connection was refused by the server. SSL was not compiled into Apache. Too bad for 6.2!
OpenSSL is not limited to secure Web transactions, of course. OpenSSL can also be used as a command-line encryption tool.
SSL and ssh are not the only new security tools included with Red Hat 7.0. Firewall configuration has become a critical need even for the home user! For that reason, Red Hat has included the firewall-config tool. This tool is a very simple-to-use, point-and-click user interface for creating ipchain rules to harden your system’s security. This GUI interface consists primarily of text areas and drop-down menus that allow you to enter or select information about source devices, source IPs, source ports, destination devices, destination IPs, destination ports, protocols, chains, actions, redirect ports, policies, and a host of other ipchain configurations. This tool makes locking down a networked machine a task that nearly any user could manage.

One other important inclusion is that of Kerberos. Kerberos authenticates users in a network environment and allows you to use previously insecure network utilities in a secure fashion. Kerberos is a very powerful, cross-platform system that has implications throughout the whole field of networking.

Another addition (although not primarily for security) is the System Control Configuration tool. This tool has been ripped from Powertweak and deals with some very heavy-duty system tweaks (Dirty blocks to write per wake cycle comes to mind). Using this tool, you can click a button to disable the [Ctrl][Alt][Del] reboot sequence. Many system administrators find it necessary to disable this key combination so that unknowing bystanders cannot reboot a critical server. Unfortunately, figuring out how to accomplish this feat has best been left to the socially disenfranchised. No more!

Obviously, Red Hat has security on the brain (even the changing of passwords has become a menu entry for Red Hat 7.0). Once the IT community becomes aware of this focus, it should spark an even hotter interest in the Linux operating system. In light of the release of Windows 2000, this couldn’t have come at a better time. The simplicity of the new OpenSSH, the OpenSSL tools, and the inclusion of a wealth of smaller security tools make the Red Hat distribution one that an enterprise IT professional in search of simple, reliable, and inexpensive security can no longer deny.

Mandrake, on the other hand, has taken a much more basic approach to system security. The primary security configuration occurs during installation, when you select from a low-, medium-, or high-security installation. Most will go with the medium-security installation, but they must remember that there can be issues that Mandrake alone cannot resolve. Once installed (under a medium install), the security configuration is controlled by an extension of the Linuxconf tool. This Linuxconf firewall tool is quite limited, and you will find yourself wanting for more. Do yourself a favor and download Firestarter so that you can ensure tighter security.

Nonnetworking changes
Naturally the changes don’t stop at the desktop and networking. Not this time. Both OSs have upped the ante in many areas, including the following:

XFree86 4
This one might stump those who are used to editing their X configuration files by hand. While running XFree86 4, you no longer use the /etc/X11/XFree86Config file; you now use /etc/X11/XFree86Config-4. This file has been included so that users can choose between 3.x and 4. The configuration files have actually changed quite drastically. The old file contained the following sections:

  • ·          Files: The location of the RGB database
  • ·          ServerFlags: Used to enable core dumps where a signal is received, to disable the [Ctrl][Alt][BS] server abort sequence, and to disable the [Ctrl][Alt]KP +/- mode-switching sequences
  • ·          Keyboard: Configures the keyboard
  • ·          Pointer: Configures the mouse
  • ·          Monitor: Configures the monitor
  • ·          Device: Configures the video card
  • ·          Screen: Configures the SVGA server

The new XFree86Config-4 file consists of the following sections:

  • ·          ServerLayout: Defines the display information
  • ·          Files: Defines the font path
  • ·          Modules: Loads all video-related modules (i.e., GLcore, dbe, dri, extmod, glx, pex5, record, xie, and v4l)
  • ·          InputDevice: Configures the keyboard and mouse
  • ·          Monitor: Configures the monitor
  • ·          Device: Configures the video card
  • ·          Screen: Configures the SVGA server

Although these two files don’t seem vastly different, they are. If you do happen to prefer to configure your graphics display by hand, it would behoove you to become familiar with the newer XFree86 4 methodology.

The changes are many and not altogether obvious. Both Red Hat and Mandrake have made giant strides with the last few releases, but none have come so far so quickly as Red Hat 7.0 and Mandrake 7.2. Although both distributions are grounded in familiar technology, the nuances that have been added offer higher security, easier networking ability, and plain old user-friendliness that dramatically enhance Linux’s acceptability for everyone from the single user to enterprise deployments.

Without saying that one distribution is superior to the other, it’s simple to conclude that both distributions are creating Linux as a complete evolutionary/revolutionary product. Yes, some of these issues may very well cause problems with the Linux Standards Base, but neither Red Hat nor Mandrakesoft can afford to stagnate while the LSB decides just what the standards are.

If you’ve been hesitant to deploy Linux, it’s now time to give in and try out this exciting operating system. I can say with confidence that either of these distributions will fulfill more of your needs than you can possibly imagine. So what are you waiting for? Download, burn, or buy a copy of one of these new releases and tell me what you think!
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.