With today’s release of Red Hat Enterprise Linux 5.0, Red Hat is both following and bucking server operating systems trends we’ve witnessed in past Clear Choice Tests of Novell’s SUSE Linux and Microsoft’s Longhorn beta code.
How we tested RHEL5
Archive of Network World tests
Subscribe to the Network Product Test Results newsletter
Also, while Red Hat has made a few minor GUI enhancements, RHEL5 doesn’t offer much in the way of eye-candy adjustments to its interface like Microsoft and Apple consistentely do with their operating-system upgrades.
Security controls
With RHEL 5, SELinux access controls are in place immediately unless you opt out of them at installation. While SELinux was first provided in RHEL 4, we found that Red Hat has made setting user access-control policies much easier in this release, as its SELinux Management Tool can be used to set user policies as well as policies for specific applications by module. However, some administration tasks, such as changing policy characteristics for groups of applications, still require manipulation that the SELinux instrumentation tools in RHEL5 don’t handle out of the box. Red Hat, to its credit, supplies a very good SELinux Troubleshooter application.
SELinux Troubleshooter, which scours system logs looking for problems spawned by users or application misbehavior, is quite articulate in the types of misbehavior it finds. However, the logs needed by SELinux Troubleshooter aren’t found in any ‘default’ location by the application. Also, once you point it in the right direction, the location is not saved by the application for subsequent default-location log-file openings.
Because logs can record the same repeating error, a handy SETroubleShooter filter can be used to separate the discrete error instances from the entire list. What’s missing from TroubleShooter, though, is an automatic alarm mechanism that can send messages to syslog or even straight to an administrator when application, user session or guest operating-system instances start to misbehave.
And while SELinux is set during installation, we found that root and user passwords for the operating system at large have few constraints placed on them. It’s a conundrum that SELinux’s protection of user sessions has evolved, but passwords, unless purposefully hardened, are subject to dictionary attacks.
Xen is Now
Red Hat has made extensive use of the Xen server virtualization technique for the first time in this release. What’s different, we found, is that Red Hat’s Xen implementation is far more evolved than what we found in SUSE 10, although it does lack comprehensive instrumentation.
We could easily get the Xen hypervisor up and running and subsequently build a modified (called “Xenified” hosting) kernel quickly. Guest operating sessions could be built quickly upon these instances and subsequently monitored through Virt-Manager, the basic open source Xen tool included by Red Hat in this release. The malady to how RHEL5 has used Xen is that it isn’t sewn together administratively and begs for an “empirical” Xen-management application rather than nonintuitive sequence of using the standard open source tools.
When we tested the RHEL5 native kernel for performance (using OS install time-chosen defaults, as we normally do) against SUSE 10, we found little notable differences in our LMBench results (see How we tested RHEL5) between the most current versions of these Linux operating systems (see chart with full results, below).
|
Performance is also enhanced by RHEL5’s ability to use multicore CPUs and tap into several of them in the same machine. In our tests, RHEL5 detected the twin Athlon CPUs of our Polywell 2200S machine easily, and made the same short work of our 4-Athlon 64 CPU, dual-core HP 585. In fact, there were no other detection errors except for odd graphics-card geometry problems that we saw on a Dell PowerEdge P280 and our HP DL140 generic servers, and these were trivial.
The impact of introducing Xen’s hypervisor to the subsequently Xen-ified RHEL5 kernel represented only nominal latency from the nat
|
| ||||||||||||||
| ||||||||||||||
Security controls
With RHEL 5, SELinux access controls are in place immediately unless you opt out of them at installation. While SELinux was first provided in RHEL 4, we found that Red Hat has made setting user access-control policies much easier in this release, as its SELinux Management Tool can be used to set user policies as well as policies for specific applications by module. However, some administration tasks, such as changing policy characteristics for groups of applications, still require manipulation that the SELinux instrumentation tools in RHEL5 don’t handle out of the box. Red Hat, to its credit, supplies a very good SELinux Troubleshooter application.
SELinux Troubleshooter, which scours system logs looking for problems spawned by users or application misbehavior, is quite articulate in the types of misbehavior it finds. However, the logs needed by SELinux Troubleshooter aren’t found in any ‘default’ location by the application. Also, once you point it in the right direction, the location is not saved by the application for subsequent default-location log-file openings.
Because logs can record the same repeating error, a handy SETroubleShooter filter can be used to separate the discrete error instances from the entire list. What’s missing from TroubleShooter, though, is an automatic alarm mechanism that can send messages to syslog or even straight to an administrator when application, user session or guest operating-system instances start to misbehave.
And while SELinux is set during installation, we found that root and user passwords for the operating system at large have few constraints placed on them. It’s a conundrum that SELinux’s protection of user sessions has evolved, but passwords, unless purposefully hardened, are subject to dictionary attacks.
Xen is Now
Red Hat has made extensive use of the Xen server virtualization technique for the first time in this release. What’s different, we found, is that Red Hat’s Xen implementation is far more evolved than what we found in SUSE 10, although it does lack comprehensive instrumentation.
We could easily get the Xen hypervisor up and running and subsequently build a modified (called “Xenified” hosting) kernel quickly. Guest operating sessions could be built quickly upon these instances and subsequently monitored through Virt-Manager, the basic open source Xen tool included by Red Hat in this release. The malady to how RHEL5 has used Xen is that it isn’t sewn together administratively and begs for an “empirical” Xen-management application rather than nonintuitive sequence of using the standard open source tools.
When we tested the RHEL5 native kernel for performance (using OS install time-chosen defaults, as we normally do) against SUSE 10, we found little notable differences in our LMBench results (see How we tested RHEL5) between the most current versions of these Linux operating systems (see chart with full results, below).
|
Performance is also enhanced by RHEL5’s ability to use multicore CPUs and tap into several of them in the same machine. In our tests, RHEL5 detected the twin Athlon CPUs of our Polywell 2200S machine easily, and made the same short work of our 4-Athlon 64 CPU, dual-core HP 585. In fact, there were no other detection errors except for odd graphics-card geometry problems that we saw on a Dell PowerEdge P280 and our HP DL140 generic servers, and these were trivial.
The impact of introducing Xen’s hypervisor to the subsequently Xen-ified RHEL5 kernel represented only nominal latency from the native RHEL5 results. We measured the Xen impact on performance, and found that the ‘insertion loss’ of the hypervisor layer and ‘Xenified RHEL5 kernel’ are nominal: Performance isn’t affected much. Adding guest operating systems to the Xenified RHEL5 kernel dragged down performance. We spawned two guest ‘domU’ (as they’re called in Xen parlance) instances and ran LMBench3 concurrently in each OS guest instance. Performance dropped linearly with the added instances.
Red Hat has rebuilt its driver model in a quest to equip hardware vendors with a more consistent code-building exercise. One of the possible payoffs is an open source driver that allows OS instances to use virtualized storage provided via the iSCSI driver’s ability to link to external storage facilities, such as iSCSI hosted SAN assets. This driver allows external iSCSI storage devices to be reached from the operating system as ‘SAN,’ thereby reducing the server hardware footprint. It also give system designers flexible storage options should they need to service virtualized OS instances in a more orderly way.
Less evolved in RHEL5 in both server and client versions are the kinds of flashy GUI enhancements Microsoft and Apple have been putting in their operating systems. There’s really no new lipstick on the Red Hat pig. It’s still using Gnome 7.1; support for high-performance graphics cards has been added. as are the AIGLX libraries, which mime some of the graphics visual effects of competitive GUI features. These include slick minimization, transparency/translucency, fading and window manipulation tricks.
In terms of other notable changes, install-time support options have increased, and RHEL5 includes more sophisticated and comprehensive support for IPV6 in the areas of detection and firewall manipulation.
Summary
Sex appeal doesn’t seem to be the focus of this release. Instead, Red Hat makes a strong statement in its competitive infrastructure in the form well-executed virtualization and user session controls in its RHEL5 release. The aggressive number of components inside this operating system still beg to be sewn together more comprehensively with better administrative tools, but the fundamentals are definitely in there.
Henderson is principal of, and Dvorak is a researcher for, ExtremeLabs in Indianapolis. They can be reached at thenderson@extremelabs.com and rdvorak@extremelabs.com, respectively.
Henderson and Dvorak are members of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.
