The master and the apprentice

Dirk Wetter, Dr. Wetter IT-Consulting

This extended report is result of the research and review work done on the recently released Suse Linux Enterprise 10. Part of it is published in the German iX magazine [1,2], known for its in-depth reviews. This article included a few days testing in a lab scenario which we use for paid and other system research, too.
Feel free to link this article if you find the information useful or send us an e-mail. However respect the copyright (see info on bottom of page).

Enduring teething troubles after the redesign of the higher level packet management ZLM/ZMD made it necessary to delay the general availability of (Open)Suse 10.1 and as a consequence also the product internally developed from it: Suse Linux Enterprise Server 10. SLES 10 is Suse's/Novell's third enterprise server distribution. The predecessor SLES 9, released two years ago, was despite the fact that kernel 2.6 was by that time relatively new, known to be stable and made overall a good impression.
Recently joined the Linux server market has Xandros. It is a good chance of comparing what a new born server distribution has to offer as opposed to the veteran Suse/Novell.

Picture 1: SLES 10 with some Yast modules in action (local desktop is SLED 10): Yast's network services (upper right hand side), below that: iSCSI target configuration, right bottom: Heartbeat configuration. Left bottom: Xen SLES in SLES installation with two other virtual machines and a xentop output on top of it.

The market of Linux in the enterprise

Competition for the established Linux enterprise distributors like Novell/Suse as well as Red Hat is getting tougher: Looking at the server market segment there might be still customers migrating to Linux, however since a little bit more than year there are more competitors around offering a server Unix at no costs: A while back Unix grandfather Sun has finally decided to give up its zig-zag course for the PC platform, so that nowadays Solaris/x86 and Solaris/x64 are alternatives to run on cheap PC hardware, if supported. Despite the assumption that nowadays new operating systems don't make quantum leaps, Solaris 10 emerged with a bunch of new features. Recently it included the innovative file system ZFS (Solaris 10 6/06) and e.g. a virtualization technique named zones/containers which is similar to BSD jails. Most of the security and recommended patches in Solaris are for free, for phone and e-mail support of course one has to pay for. To a certain extend this reminds on the rookie in the field of Linux server distributions: Ubuntu 6.06 LTS. The relatively new distribution from South Africa is free, so are the updates, only for support you have to spare some Rand/Isle of Man pounds. LTS stands for Long Term Support: Ubuntu guarantees 5 years software maintenance for server packages, 3 years for desktop. Patches are distributed quickly, in the last time maybe too fast.

There's not so much to say about the well established Novell/Suse and their main rival Red Hat. Both have a freely available community product with 15 to 24 months lifetime and half year release cycle – name confusions aside Suse's version is normally named OpenSuse, Red Hat's Fedora Core. The short life time makes it not reasonable to use it for the enterprise where 2 years or even less is not enough. Every third to fourth iteration of the community distribution serves internally as a development basis for Red Hat's or Novell's enterprise product having up to seven years lifetime. Simultaneously to the – or in the case of Red Had variety of – server product(s), both of the vendors sell a stripped down version without server functionality for the desktop. Novell's recent name for it is Suse Linux Enterprise Desktop (SLED), Red Hat's Red Hat Workstation (WS). Opposed to Solaris or Ubuntu access to both the vendors portals providing maintenance and security patches costs money. The ISO images however are freely available for evaluation by registering with an e-mail address, giving you time-limited access to patches, Red Hat e.g. is granting 60 days.

Picture 2: Xandros management console: xMC

Opposed to those Linux "oldies" with more than a decade experience, Xandros (the company) is relatively new, their server product is only a few months old.
The Canadian based Linux firm headquartered in Ottawa was started in 2001, founded by purchase of the Corel Linux Desktop division. The resulting desktop product Xandros Desktop – advertised with a four-click-installation – made a good impression during a comparison of enterprise Linux desktop distribution in 2004 [3]. Their first server product was released in the beginning of May 2006. So, after reviewing the Xandros desktop in 2004, it was more or less an obligation to review Xandros' server product as well.

Lab environment: installation

For the research done in the lab there were a couple of computers available: In the old-but-still-good-IA32 category there were three PCs with 0.5 to 1.5 megs RAM and a CPU horsepower between 2 and 2.8 GHz available. Also an older IBM Thinkpad with 1 GB of memory, internal 802.11a and bluetooth was supposed to get a desktop installation with SLED 10. For the major part of the test however heavy Opteron iron equipped with plentiful memory was waiting for the SLES and Xandros packages to be installed. For detailed specs of this piece of server hardware, see Under the hood at right hand side.

Novell's enterprise variants SLES and SLED – from now on titled as SLE (Suse Linux Enterprise) – were given birth via PXE and TFTP-boot. With one exception (see below) the installation of SLE was performed via NFS in the Gigabit network in the lab. No use of automated installation was made, however amongst the three possibilities Novell provides of remote installing a computer (SSH, VNC, serial) by providing the right append option to the boot kernel remote installation of SLES via ssh (usessh=1 sshpassword=mysecret) was chosen. For SLED however due to a bug or missing feature, also present e.g. in Suse 10.1, it's not feasible to install the desktop variant remotely: First if you try to, during installation you have to set the runlevel explicitly to 5. In addition after the installation is finished one has to configure X manually, by means of the config tool sax2.

The Xandros server doesn't provide any means to perform the installation over the network, using not the physical console or any way of automate installations.

Lab environment: network scenario

Novell's server and desktop were supposed to be integrated into the lab environment: An existing OpenLDAP server under (Open)Suse 10.1 were authenticating test users via LDAPv3 and SSL. The very same piece of hard- and software was serving home and data directories via NFSv3 which every "candidate" was supposed to mount via local automounter maps. Fixed IP addresses and network settings were handed out by the DHCP server, in addition also IP addresses of the NTP servers using DHCP-options. For central syslogs, root and user e-mails there was another server. A CUPS server was broadcasting its queues. Since with the exception of the DHCP settings for the laptop this environment doesn't make sense, it was set up with local data only.

Without spoiling too much of the story: During the test it turned out that Xandros' first server shot would be more more a sparring partner than a competitive opponent to SLES which according to Novell is working on SGIs 1024 processor monsters^W machines (Altix). After confronting German sales and marketing with some issues encountered, it became clear that the server from Canada is more targetted at SMEs. Thus the 1:1 comparison with SLES has to be postponed. Rumors are around that Xandros seems to work on an advanced server which will compete better. The result of this research on Xandros' server you can find in the box What lies ahead on the right hand side.

Suse Linux Enterprise Server/Desktop 10

As usual the Yast installer is giving a good and lucid overview over the installation process. Before the packet/software installation is started, you get a dialog

Picture 3:Yast's installer defaults (overview tab, SLES x64)

set with reasonable defaults and you have the choice of changing the following options: partitioning / add-on products, software selection, boot loader, time zone, language + keyboard setup, for some of you have to chose the expert tab. That's the same as in the recent community distributions. Compared to (Open)Suse 10.1 the optics changed slighly. The theme is slightly ocher and the arrow indicating the progress of the installation is red. What really changed – this is more a political issue – is the choice of the default desktop: Up to Suse 10.0 the default was KDE. OpenSuse 10.1 was more politically correct and had a preselection dialog in the Yast installer which had no button selected by default. In SLE the default now is GNOME, there's no preselection dialog whatsoever. And as you will see later: it doesn't matter if you deselect all GNOME and select all KDE packages: What you get on your system is GDM and per default a GNOME session. But also the choice of GNOME's revision might not make hardcore GNOME users happy: GNOME 2.12 it's not the latest – born 9/7/2005 – and greatest release – 2.14 has a variety of improvements, notably speed. Also if the user can alter the predefined choice in GDM or set his preference in $HOME/.wmrc, the fact remains: GNOME provides the standard window- and displaymanager now. If you want to change them on a systemwide basis have a look at /etc/sysconfig/{windowmanager,displaymanager}.

Back to the software selection: Since (Open)Suse 10.1 the software selection dialog is a giving a better overview, however in SLE it's more customized for the purpose of the desktop or server distribution. However all of them suffer from the old Suse phenomenon that in the deeper level of the menu the system administrator is bothered more with probably RPM dependencies than with category associations, e.g. you will find g3utils for fax and emacs in kernel development, net-snmp, rrdtool and some libgnome* in KDE.

Picture 4: Yast software selection details

Here a clear selection of single software packets within a category would be better like "I want emacs with x11 support" in "text editing" like Red Hat's installer in RHEL is doing it: emacs base packages, info and lisp files, emacs-X11 will be selected in the background. It's also confusing why basic libraries are selectable, the basic ones should be normally automatically chosen by the selection of the program linked to it. Then – and not earlier – in addition for the expert who might care about disk space or RPMs which he doesn't want to have by some magic installed, a package based menu like to one above would be great. But please: The RPMs should be in the right categories.

The Opteron system was supposed to get the whole nine yards, meaning a full installation of everything was performed.

Picture 5: Yast's network setup dialog

After selecting all checkboxes (see picture) on the left hand side, nod through the license agreements and the obligatory warning that all existing data will be overwritten, the four cores of the AMD machine took 20 minutes to haul close to 1000 packages from the network to the SATA disk. After all was done the post configuration took place: A hostname was suggested, root password had to be set – since a longer time Novell is using blowfish encryption as default – and the network has to be set up. New is the registration procedure which is optionally passing hardware infos to Novell's portal. The mapping to the right portal account at Novell is done by supplying the according e-mail address to the installer. A good thing: If you're just evaluating SLE by following this procedure you get 15 days of updates for free.

Picture 6: Yast's teasing CUPS dialog

The printer configuration in the very end of the installation process was kind of teasing the tester: During every installation it was telling the author that the local CUPS server is listening for broadcasts from other servers. The line below however stated every time that the needed port for the listening requests in the firewall was closed. That wouldn't be taken as teasing if there would be a choice here to open the port, but there's only the choice to do so in the running system. Novell should just add an option during the installation to open port 631.

As expected without any problems, albeit slower, went the other installations over the network, the PCs were just not as fast as the Opteron servers. Worth to mention that one installation of a prerelease of SLES 10 from DVD failed: Suddenly a dialogbox showed up telling that an RPM was not readable and asking whether it should "Abort, Retry, Ignore". Despite clicking on "Ignore" Yast aborted the packet installation and was continuing at the point where normally all packets would have been on the disk, i.e. it tried to set up the system. Needless to say that it left a non-working installation behind. In this case it didn't hurt – except maybe the time spend into it. However if this would have been a scenario where a customer would have run an update from SLES 9, it could have been fatal. The foster father Suse 10.1 had a similar problem: A click on "Retry" at the same point during an upgrade from Suse 10.0 to 10.1 caused a segfault. At the point where this critical dialogbox shows up, Novell should be more careful how to evaluate the clicks and how to handle the return values. But maybe this is already fixed in the golder master.

Juggling the packets

Curious was the more KDE-philic author how his desktop of choice is doing despite the highly political change in Novell's desktop policy. Picked

Picture 7: Yast's teasing CUPS dialog

for this test was the old Thinkpad which was destined for a KDE-only installation. So the GNOME checkbox (see picture 7 on the right) was unchecked in Yast. After resolving the dependencies Yast claimed that a total of 2.8 GB would be installed, during installation the number grew to 3.8 GB, after the initial login it was more than 4 GB. The number was quite critical because the chosen partition had only 4.1 GB. The difference between 2.8 and 3.8 GB were likely due to the fact that the whole nine yards of GNOME packages – including GNOME games – were installed despite the preselection. This could be verified by starting after installation the software module of Yast (yast2 sw_single) where the formerly unchecked GNOME box was now selected again! Also gdm was still configured as the default displaymanager in /etc/sysconfig/displaymanager, so was GNOME in /etc/sysconfig/windowmanager.
Appreciated was the fact that the hot keys Fn-F3, Fn-F4, Fn-F12 (suspend to disk) were properly doing their work. Lid closing was assigned to suspend-to-ram. But since it the ACPI implementation doesn't support this properly yet and Novell as a consequence correctly didn't configure it.
The internal bluetooth device of the Thinkpad was automatically detected and accordingly services started. However despite the WPA configuration done during installation, the prism2_pci kernel module was loaded by SLED 10 instead of the hostap_pci module. The former one doesn't support WPA, so that the wpa_supplicant hiccuped.

Generally the author was missing a possibility to pick a selection of tools normally experienced system administrators are using. The formerly under Suse 10.1 available checkbox Experienced User is gone now. Worse: Despite the fact that for the SLES installation e.g. of the Opteron server all boxes in Selections were checked, tools more or less belonging into the swiss army category like locate, expect, ncftp, nmap, statserial, mii-diag, whois, xpdf had to be manually installed afterwards. A hint: If you don't want to use the search function of yast2 sw_single to correct this, use rug install ABC or yum install ABC on the command line.
Back to the virgin installation: Strange though that yum is only included in the 32 bit version of SLED. Speaking of missing bits and pieces on the core CDs: xemacs is (only) available on the SDK ISO images. Also Eclipse is on the CD and Openwall's John the Ripper (version 1.7.0.2 with MMX but without SSE2 extensions). The SDK has a kind of a shadowy existence for a lot of users which surprises because there are useful additions on the CD.

SLE had no problem with the above mentioned requirements in the test lab. The only thing which needed manual work on the command line was the nullclient configuration of SLES: If you install the yast-mail-server RPM Yast doesn't let you configure a nullclient. That doesn't hurt normally since this kind of configuration is faster achieved by manually editing postfix' main.cf which is Novell's default MTA. Junior system administrators or admins used to Novell's competitors might also miss a possibility to configure syslog forwarding with Yast. In the lab environment this didn't cause headaches, since there's a postinstall script which independent of the syslog flavor and operating system is configuring forwarding to the loghost. Appreciated was the fact that Yast in SLE 10 has better possibilities to configure the NTP client. Besides preselecting servers from pool.ntp.org the complex configuration allows getting NTP servers through DHCP options as in the lab environment. For command line artists: DHCLIENT_MODIFY_NTP_CONF in /etc/sysconfig/network/dhcp is responsible for this. Per default ntpd – Novell uses xntp 4.2 from ntp.org – runs chroot.

Happy meals do play dice

Confused got SLES on one of the 32 bit systems: Besides the SIS900 onboard NIC there was a Sun QFE (quad fast ethernet) card in one PCI slot (the QFE cards were often used for Sun/Veritas clusters). Some of the so called happy meal (hme) ports were having different names every time the system was rebooted: The onboard card was recognized recognized by he kernel as sometimes eth0 or eth4, after booting always named eth0. The second and third port of the QFE card were always ending up as eth1 and eth2. Whereas the first port was the first couple of boot processes somehow undecided and eventually settled on eth5. The last port's name increased with every reboot, the MAC address changed every time! There must be a problem with the hme driver:

slessrv:~ # dmesg |grep eth
eth0-3: Quattro HME (PCI/CheerIO) 10/100baseT Ethernet DEC 21153 PCI Bridge
eth0: Quattro HME slot 0 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:9e:41:84 
eth1: Quattro HME slot 1 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:9e:41:85 
eth2: Quattro HME slot 2 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:9e:41:86 
eth3: Quattro HME slot 3 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:cc:21:3f 
eth4: SiS 900 PCI Fast Ethernet at 0xa000, IRQ 217, 00:e0:18:8d:1c:6d.
eth0 renamed to eth5
eth4 renamed to eth0
eth3 renamed to eth11
eth0: Media Link On 100mbps full-duplex 
slessrv:~ # ifconfig -a | grep ^eth
eth0      Link encap:Ethernet  HWaddr 00:E0:18:8D:1C:6D
eth1      Link encap:Ethernet  HWaddr 08:00:20:9E:41:85
eth2      Link encap:Ethernet  HWaddr 08:00:20:9E:41:86
eth5      Link encap:Ethernet  HWaddr 08:00:20:9E:41:84
eth11     Link encap:Ethernet  HWaddr 08:00:20:CC:21:3F
slessrv:~ #

sunny:~ # uname -prs
SunOS 5.10 sparc
sunny:~ # ifconfig -a | tail -12 | grep -v inet
qfe0: flags=1000802 mtu 1500 index 4
        ether 8:0:20:9e:41:84
qfe1: flags=1000802 mtu 1500 index 5
        ether 8:0:20:9e:41:85
qfe2: flags=1000802 mtu 1500 index 6
        ether 8:0:20:9e:41:86
qfe3: flags=1000802 mtu 1500 index 7
        ether 8:0:20:9e:41:87
sunny:~ #

The QFE card was then moved into a SPARC system, see right box (it's needed to set local-mac-address to true in OBP before) All interfaces have MAC addresses in ascending order (see above). That stayed the same after every reboot.
A similar thing happened a while back randomly on a self-made Linux server under Suse 10.0 with several Intel NICs: dual e1000, dual e100, single e1000 SX. The name of the ethernet interface having a bad misery was eth2xx. That vanished as one of the NICs was removed.

Slimmed

Novell said goodbye to a number of software packets: Mozilla Thunderbird is one them. As a Gnomie you have to use evolution as a MUA (mail user agent), kontact/kmail is the choice for KDE followers. If you're prefer the command line mutt is included in SLES and SLED.
Novell said also goodbye to JFS: The installer Yast doesn't support creating a new JFS anymore but it displays old partitions formatted with IBM's file system. If you want to get around it, here's a hint: at least in the installed system there are still the command line based utilities (jfsutils-RPM).
Opposed to SLES 9 OpenAFS support is missing which probably hurts some costumers who want to use SLES 10 as an operating system for an AFS server. According to Novell AFS was too complex and thus too support-intensive. However: A closer look revealed that "only" the kernel module is missing and the binaries are not included: The Suse 10.1 kernel provided on the CDs/DVDs had to be reconfigured and recompiled to support PAGs (process authentication groups) which is an important part of the AFS security concept; without them AFS tokens are based on Unix UIDs.

Some attention is required if you run a kerberos server and want to upgrade from SLES 9: the old version runs the Heimdal implementation, whereas SLES 10 has now MIT kerberos. You have to create an ASCII dump before the upgrade and import later on SLES 10 the principals on the MIT-KDC. This procedure is described in the release notes which are in the docu directory and are displayed after the upgrade. A clearer reference or a warning before the upgrade would be useful.

Safety measurements

As far as security measures are concerned, Red Hat engineers, marketing and others were advertising in the past that their distribution had more to offer in terms of security. There's more than a single grain of truth in there: The classical binary security model in Unix expired: You don't want an almighty root anymore (zero) and on the other hand more or less almighty users (one). Even Microsoft has implemented in Vista a variety of measures, similar to a Mandatory Access Control (MAC) model. Even Windows 2003 was compiled with hardening measures, though sometimes it's said that the stack protection (canaries) can be defeated.
Thus nowadays some Linux distributors will find it hard to release a product which relies only on a classical Unix security model. Suse addressed this in SP3 of SLES 9 by backporting Immunix' AppArmor. Now SLES 10 has 50% more profiles to protect applications (SLES 9 SP3: 61, SLES 10: 93). AppArmor is switched on per default. It's quality of security is sometimes a matter of discussion amongst experts which say AppArmor is not in the mainstream kernel and claim [5] that the profiles of AppArmor work with fixed paths that under some circumstances could be circumvented. Nevertheless this is a consequent step of Novell moving forward with this. But there's more: SLES 10 makes use of the NX/XD bit of some CPUs and the included gcc 4.1 supports as in RHEL 4 (and as in Microsofts Visual Studio Compiler) canaries (-fstack-protector, -fstack-protector-all). According to Novell's Kurt Garloff, Director at Suse Labs, all packets are compiled with -DFORTIFY_SOURCE, some position independent with -fpie, some with -fstack-protector. The interesting question which application was compiled with which flag however was not answered. Apart from the RPM OPTFLAGS which shows for all binary packets -DFORTIFY_SOURCE one get get more insight by looking into the sources. A quick glance into Apache revealed e.g. that -fpie was used.
During the review phase Novell took between 6 and 8 weeks to fix the current local root exploits (/proc race condition, prctl(PR_SET_DUMPABLE) ). According to Novell especially the kernel in enterprise products needed to be QA'ed and Oracle patches were holding up the release of the fixed kernel.

Non-virtual hype

One of the significant improvements compared to SLES 9 is the virtualization technique: By the end of 2004 – when Suse launched SLES 9 – the only virtualization available in the free software world was UML which SLES supported. Now Xen 3.02 is included in SLES 10. This latest version supports also x86_64 hosts and goes beyond paravirtualization so that also e.g. Windows guest systems can run under the control of the hypervisor. This is being achieved by making use of the processor vendors hardware virtualization techniques VT and SVM: Intel's Virtualization Technology and AMD's Secure Virtual Machine Technology.
Within the Red Hat community Xen virtualization is currenty fueling discussions, specifically some complain about it's stabilty and reliability for the enterprise. We'll see what and how Xen will be integrated in RHEL 5. At least the basis of RHEL 5, the current Fedora Core 6 betas, include Xen.

Picture 8: Yast's Xen module

Novell has even made Xen easier to set up: a Yast module (see also lead picture 1) is helping to pick the right kernel and to configure the boot loader and eventually setting up the guest system. a "SLES in SLES installation" was started within a fingersnip.
The small drawback encountered in the test was only that the GUI module seems to lack support for local installation sources (disk).

Feels good

Suse has the reputation since some years to ease system administration by providing customers – be it beginners or experienced admins who just want to quickly accomplish a task – one graphical user interface: Yast (see also lead picture 1). Already in SLES 9 Suse put some modules on top of what the plain Suse version didn't have: e.g. Yast could help to deal with x509-based certificates (Yast CA module)

Picture 9: Yast's modules (Network Services)

and help to configure an OpenLDAP server as well as Heartbeat. Novell took that in SLES 10 a step forward: The Xen module was mentioned above. The Yast Heartbeat module got better in terms of overview and features. For the features partly responsible is the upgrade to Heartbeat2 which now SLES 10 uses. New is also the support of the cutting edge technology iSCSI: iSCSI is nowadays seen as a SAN technology which has the potential to supersede Fibre Channel: switches and NICs are cheaper, the speed is not limited to 2 or 4 Gbit/s, network admins don't have to learn new stuff. And vendors formerly offering only NAS storage solutions or bigger SAN vendors like EMC, NetApp or LSI have now products supporting iSCSI, a SAN solution. SLES 10 is supporting iSCSI on the client and server side, each with a Yast module. It's a mere child's play to set up both: in the test it took a little less than two minutes for the first copy command into the new filesystem. SLES uses for the client (initiator in iSCSI terminology) (Open-iSCSI) and on the server side (i.e. iSCSI target) IET which stands for iSCSI Enterprise Target.

Yast also became smarter: it realizes if a packet is missing for your intended configuration and prompts you whether the RPM should be installed. This reminds somehow on Mandriva [4]. Also, Yast has now some intelligence built-in for daemons like iSCSI, xntpd, httpd you are about to configure and need to be accessed from the outside through the host-based firewall: In those cases you will be prompted on which of the network interfaces you would like allow to access your server. There's a small catch however: in the test it was only possible to open the port on all interfaces. The background: SuSEfirewall2 distinguishes network interfaces by their assignment to zones (external, internal, DMZ). If there's no zone defined or the interfaces you select are in different zones, that will not work. Better at this point would have been to ask whether the firewall wizard should open the port to this zone, in brackets mentioning the network interface. And if no zones are configured it would make sense to have the wizard setting them up first.
Another small glitch: There was a problem with Mozilla Firefox which worked as expected under SLED. However if the test user (/home was NFS-mounted ) switched back to Suse 10.0 or 10.1 he was not able to install or uninstall any private themes or extensions. Removing the extensions files ~/.mozilla/firefox/*.default/{extensions.cache|.rdf|.ini} and restarting firefox unbanned the user from the problem.

Further technical features in SLE 10: NFS version 4 is fully supported since Suse 9.3. So it's not much of a surprise that SLES 10 has NFSv4 client and server side support as well. Sysadmins who just want to jump at it should be aware of the fact that it's more difficult as easy to set it up as NFSv3/2. For a Yast NFSv4 module probably one has to wait a little bit. A small issue was encountered in the lab: SLE by default, as opposed to a Solaris host in the lab, doesn't set the domainname for NFS version 4's ID mapping daemon idmapd. If you try to use SLE as a NFSv4 server or also as a client you better doublecheck Domain in /etc/idmapd.conf. If idmapd on client and server have different domains set, they don't talk to each other. Since this is an error you can't find out by inspecting the log files or even the network (ethereal^Wwireshark) the right domain is the first thing to check. Further help is providing linux-nfs.org with their troubleshooting recommendations.

Novell seems to take the evolving DMTF standard WBEM more seriously now. The implementation SLE uses is OpenWBEM. There are more CIM providers in version 10, e.g. AppArmor, procfs or sysfs, and even bindings for Yast. The SLES documentation – the PDF has 972 pages – dedicates a whole chapter to CIM (Common Information Model) and WBEM. What is missing, this is more a general Unix issue than a Linux specific, are simple clients, if you don't take the SBLIM (Standards Based Linux Instrumentation for Manageability) client for the command line into account. Using the old snia Java-based client, the owcimomd could be convinced to present an overview of the providers. A good start for using WBEM in SLES 10 is Novell's cool solutions portal.

SLED as well as SLES default's IO scheduler is CFQ (complete fair queueing) as opposed to the standard vanilla kernel's (2.6.16) AS (Anticipatory Scheduler). According to Novell internal tests were on average better using CFQ, since CFQ's development evolved in the past with respect to I/O priorities: Since some time now the I/O from background jobs now treated according their background status. And: CFQ is able, as AS was already, to queue simple successional read transfers and execute them in one go which makes it possible to avoid head movements on simple block devices. Jens Axboe – on the payroll of Novell – has helped considerably improving the I/O schedulers.

Novell's biggest marketing feature for the enterprise desktop is with no doubt the 3D desktop supported by Xgl and compiz. It is supposed to provide some 3D eye candy like MacOS X' Quartz Extreme desktop. The only catch is that the number of graphics cards supported is not very big. For the desktop you're depending on NVIDIA's and ATI's proprietary drivers. For the laptop additionally there are some Intel cards supported. Unfortunately every piece of lab hardware available for the test of SLED was out of the small range of supported cards.

Bottom line

If you don't intend to buy SLED for a larger site Novell's desktop is a bargain: it costs 47 € a year and is offering a long life time alternative to Opensuse which lives 2 years only. However in SLED the set of applications is narrowed down to the ones Novell wants you to use: Of course server applications are missing, but also you have to say goodbye to Mozilla Thunderbird which some customers won't appreciate.
Novell did more to make customers happy who don't want to fiddle around with the command line, especially the Yast modules for iSCSI and Xen will be welcomed by more than a few customers. Taking into account the competitors: You should not forget that much praised Debian or Ubuntu are currently either lacking those technologies at all, or they are not included per default or it's some amount of manual work needed to get it running. As opposed to SLES 10 the free competitor Debian Sarge still lacks full NFSv4 support, Ubuntu Dapper Drake provided full support with an update.
Novell sensed the sign of the time and provided "more" in terms of security: It improved AppArmor, with the support of NX/XD bit, -DFORTIFY_SOURCE and other measures, applications and as a consequence the installed server will be more secure. The host-based firewall SuSEfirewall is since long switched on by default, somewhat intelligent and as opposed to e.g. Red Hat's version logs dropped packets.
As mentioned in the text despite all the good things the research revealed a few dents: The circumstances where a non-readable RPM from the beta made the installation fail needs to be verified with the gold master. The QFE network card is not good enough for production. ZMD which is far from deserving grade A, see Rag-rug. In general the better integration into ZENworks was the right thing to do, since as far as server provisioning, patch rollouts and central administration for a bigger numbers of hosts are concerned, Novell had less to offer before.
How good the backend ZLM now on the server side is competing with Red Hat's as well as Sun Microsystem's management and provisioning solutions is subject to another review in the iX magazine. (avr)

Dirk Wetter, 9/20/2006 « Back

Literature

[1] Dirk Wetter: Zweite Runde mit 2.6er Kernel, Suse Linux Enterprise Server/Desktop 10, iX 9 (2006) 36
[2] Dirk Wetter: Meister und Geselle, Comparison SLES 10, Xandros (Business Server) 1, iX 10 (2006) 54
[3] Dirk Wetter: Klopf auf Holz, Comparison of 5 Enterprise Desktops, iX 5 (2004) 52
[4] Dirk Wetter: Nominiertenrunde, Comparison Enterprise Linux distributions: RHEL 4, SLES 9, UCS 1.2, Mandriva CS 3 (German extract), iX 6 (2005) 48
[5] Oliver Tennert: Die Schilde hoch, (research on Novell's AppArmor), iX 8 (2006) 70

Discussions

Discuss this article. | Permalink, Comments [0], Reply | del.icio.us

The master and the apprentice

Dirk Wetter, Dr. Wetter IT-Consulting

The market of Linux in the enterprise

Lab environment: installation

Lab environment: network scenario

Suse Linux Enterprise Server/Desktop 10

Juggling the packets

Happy meals do play dice

Slimmed

Safety measurements

Non-virtual hype

Feels good

Bottom line

Literature

Discussions

Extract

Software and prices

Testimony

Under the hood

Rag-rug

What lies ahead

Not just yet another graphical installer

How does it look like?

Live together in peace and harmony?

MCs rule the world

Bottom line