SLES 10 server provides virtualization, availability
Version offers two new features, which will be useful after Novell polishes their edges.
With SLES 10 Novell offers virtualization, armor and availability.
Archive of Network World tests
Subscribe to the Network Product Test Results newsletter
Overall, the new version is comparable in speed to prior iterations and two new features - Xen, which provides server virtualization, and AppArmor, which products network applications - will be useful after Novell polishes their rough edges.
The first noticeable change with this iteration is that the K Development Environment is out of favor (though still available) and Gnome is in as the primary user interface in that it is the default and will likely be best supported by Novell in the long run.
The kernel is SUSE's version of the Linux 2.6.16, the speed of which is comparable to SLES 9. Base process handling is slightly slower; for example, it takes 16% longer to perform a Unix "process fork + exit" (a basic execution metric), but I/O and networking are faster (see graphic below).
| Tracking SLES performance In our battery of tests using the LMBench3 open source benchmarking tool, we found the new SLES 10 platform ran pretty much on par with numbers we achieved with SLES 9 on the same hardware. This chart shows a small sample of the overall benchmark result. | ||||||||||||||||||||||||
|
With each installation, this system performed a selected autoupdate that was painless and fruitful, especially when it was coordinated with the Customer Care program, which sends out numerous notices for patch availabilities, sometimes several per day. Security updates and multimegabyte application updates can be downloaded automatically. Any dependencies in these updates on other components were checked, and updates took place without manual assistance. This puts Novell's care in a comparable competitive position to Red Hat in the service and support arena.
The operating system as a whole is generally well buttoned down for security. The applications that affect security, such as Samba, PHP and other system application configuration files, are up-to-date and secure. But password defaults are overly simple - even those giving away root access. It's preferable to have difficult and/or hardened passwords required for all user, root or administrative accounts.
For authentication purposes, Novell has opted for the Massachusetts Institute of Technology implementation of Kerberos instead of the the Heimdal implementation used in previous versions of the SUSE operating system.
On the downside, some of the extolled features touted by Novell for SLES 10 were disappointments. Xen, an open source-based operating system virtualization server, was buggy and difficult to use. AppArmor, a method for defining application execution characteristics, worked but fell short in some areas, including its lack of useful instrumentation to manage the armor and configuration templates.
Getting going
SLES 10 found most of our test hardware components easily, tripping only on the oddities of ACPI interfaces in older Compaq hardware (see How we tested server). USB device support is now pretty thorough and transparent, though there were some USB-based devices in the lab it could not identify specifically, such as a USB 1.1 USB-flash drive dongle device.
A more sparse default installation bundle gave us most of what we needed without requiring us to do the usual kitchen-sink approach. A newly enhanced Yet another System Tool (YaST) administrative user interface often delivers multiple routes to the same destination by offering the same application on different menus. However, the instrumentation provided by YaST lacks some command line functions.
Xen: No hands clapping
Novell touts Xen as an inexpensive method for using commodity hardware to run multiple instances of the operating system in a partitioned (and therefore an implied secure) fashion. Ostensibly, non-SUSE guest operating systems can be used in a method that's similar to a number of virtualizing methods (think VMware) that have made Linux popular as a hosting platform. In reality, we had a lot of difficulty getting Xen to be stable as there were numerous exceptions to be handled and multiple configuration changes necessary to establish virtualized SLES 10 sessions. Novell is aware of our difficulties and will likely patch Xen by the time the product is released.
Xen places a very low impact on hosted guest operating systems. Xen guest operating systems speak to the host operating system through a method similar to Named Pipes, the dedicated physical-to-virtual block-mode device scheme used by OS/2 and Windows NT.
Xen is activated by creating a hypervisor that boots up on a machine as a microkernel, which in turn loads a host SLES 10 operating system with a modified-for-Xen kernel. This combination serves as the substrate for subsequent operating system sessions that appear as independent instances of SUSE Linux on the same machine. Both sessions, in turn, are diminished in privilege to be used in similar application-deployment profiles (Linux, Apache, MySQL, Perl, Python and PHP, Web, mail or other hostings). SUSE Enterprise 10 also can be hosted under VMware as a virtualized operating system.
Xen translates hardware memory addresses to a guest operating system and its kernels and drivers, as well as virtualizing hardware accessibility. This presents an Achilles' heel for Xen, as open source drivers that can be modified work better than closed source hardware drivers. The impact is that closed source drivers for displays, various wireless network devices and others don't work or produce undesirable results.
The good news is that if the correct CPU(s) are used (currently only Intel Vanderpool Technology and Advanced Micro Devices' SVM/Socket AM2 processors are acceptable), kernels can virtualize and spawn CPU threads to deal with servicing guests. Lacking the correct CPU limits the hypervisor to a single instance of a guest SUSE 2.6.16 modified kernel - practical for development testing but not hosting.
Xen also was unable to use multiple CPUs in a multicore system, because it is limited to the first CPU it finds instead of all subsequent ones. Xen holds a lot of promise for virtualization, but it was unstable and required significant amounts of tuning - and the tuning requirements changed from hardware host to hardware host. The numbers show a significant impact on performance to the hosted Xen kernel. For example, the "processsor fork + exit" test run took almost 89% longer to complete on a Xen-ified kernel than on a native, nonmodified kernel. Also, network I/O processing on a Xen-ified host kernel is overall about 40% of an unmodified SLES 10 kernel.
AppArmor complexities
The AppArmor system, which Novell has released as open source software, controls application behavior and protects applications from surreptitious modification or substitution. AppArmor uses a policy-based profile to control applications by limiting access to such resources as specific network ports or files. AppArmor is enabled on SUSE 10 by default, but is not targeting specific applications at the get-go. Novell provided predefined profiles for a limited number of applications, including Secure Shell (SSH), and Lightweight Directory Access Protocol ().
We did find several extra application profiles, which Novell labeled as "not mature" in the documentation. To turn on AppArmor for the minimal set of services running on our machines, we had to use these extra profiles.
The documentation suggests that one can develop custom profiles, but this appears to be a complex process involving profiling an application and monitoring its use, so the average site is going to want to go with predefined profiles for such standard services as SSH, RADIUS and LDAP.
Overall, AppArmor appears to have potential as a security tool, but it does not replace a host-based and system, because there is too little application instrumentation/choices, and the combination of AppArmor (with no logging), and the built-in firewall (with poor logging) generates insufficient information to integrate into an enterprise-event management infrastructure.
The missing bits
This new version of SUSE Linux lacks a higher degree of security control at the default level. Syslog is used for system logging of error and control messages (via syslog-ng) but has an all-or-nothing approach. While it's possible to use varying scripts to yank specific information from log files, we received either an avalanche or nothing in terms of system error and event logging.
The default configuration also presented security difficulties. SLES 10 uses the Blowfish algorithm for authentication, and while MD5 is available, it's not installed by default. The default installations include and procmail, which should be turned off if a system is considered to be hardened in a default configuration.
We also found difficulty with the initiator and target software components/drivers in the SLES 10 distribution. We were able to connect to SLES 10 servers via the iSCSI file system mounting virtualization scheme easily. However, we had difficulty searching a remotely mounted file system below root level and were greeted with a bus error when exploring down one such system.
Conclusion
SLES 10 is now a component of Novell's SUSE Linux strategy, and the changes we saw were heartening but need refinement. The good news is that most of the problems can be surmounted by configuration and fine-tuning. Our standing concern is with the instability of Xen, but if Novell can stabilize that feature, our hopes are high for SLES 10 making inroads in the enterprise.
Henderson is principal researcher at ExtremeLabs. Thayer is an independent security consultant. Szenes is a researcher at ExtremeLabs.They can be reached at thenderson@extremelabs.com, rodney@canola_jones.com and laszlo@extremelabs.com, respectively.
Henderson, Thayer and Szenes are also 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.
Copyright © 2006 IDG Communications, Inc.