A deeper look into (Open)Suse 10.1

Dirk Wetter, Dr. Wetter IT-Consulting

There was quite some research I did on Suse and other Linux distributions in the past, mostly for the German iX magazine ⁽¹⁾, also some as a system researcher for distributors. This time I thought to pass the report on (Open)Suse 10.1 to more people and make it publicly available in English. (Copyright info below). To be consistent with the nature of previous writings, I concentrate on technical topics and in-depth analysis.

The latest release of Suse Linux/Opensuse is more interesting than the usual because it was Novell's internal basis for developing SLES 10 (Suse Linux Enterprise Server) and SLED 10 (Suse Linux Enterprise Desktop), both aiming for business customers who want more than 2 years update support. The market of both the enterprise and community products is getting tougher: A few weeks after Suse 10.1 emerged, Ubuntu's version of Dapper Drake was launched which has 3 years desktop and 5 years server support.
After the release on May 11 Suse 10.1 was installed on a couple of systems – some being in production, some test systems. After two months where enough changes compared to the predecessor Opensuse 10.0 were experienced and technical research was done, this report was created.

Picture 1: GNOME desktop from Suse 10.1, including some Yast modules in action

Two different chameleons

There's a common misconception that from Opensuse 10.0 on there's only one Suse distribution. Opensuse 10.0 was the version distributed through opensuse.org and its mirrors, the one which could be purchased from the shelfs was named Suse Linux 10.0 like its predecessors. With 10.1 the distribution channels haven't changed but the name as of version 10.1 has: Both carry now the same: Suse (Linux) 10.1. The boxed version can be purchased from resellers for 59 Euros, it includes a printed manual (German version has 281 pages) and 90 days of limited installation support.
Suse/Novell contributed to that misunderstanding, not only because of the change of the name for the Internet version but also since their marketing wasn't quite clear that there's a boxed version having "some" technical differences. As far as the name conflict is concerned future will tell what exactly is going to happen. For Novell's own sake I wish they would be clearer on this in the future. What seems to happen is that the name of the Internet version 10.2 will change back to Opensuse. The name of the retail box is not clear yet.

Bits and missing pieces

Ok, so much for the names. Now to the technical differences. If you think you can live happily with the Internet edition you might be disappointed later on: There are several programs missing compared to the boxed version. Here is a somewhat longer sample:

nessus, arpwatch, john ⁽²⁾, snort (security)
tinyca, pwgen (x509 cert mgmt, random password generator)
eclipse, nvu, bluefish (development, html)
cacti, nagios (monitoring)
asterisk, sipset (VoIP)
OpenPBS (batch compute system)
pcp, pcpmon (SGI's performance copilot)
ebtables, ulogd*, vlan ("bridge-iptables", alternate netfilter logging target, VLAN tools)
vlan, xsupplicant, pam_radius (needed for VLANs, RADIUS server + RADIUS authentication)
drbd, heartbeat* (HA), nbd, ocfs2*
ez-ipupdate, courier-imap, cyrus-imapd, exim (system daemons)
cfengine, uucp/uudeview (system)
amanda, bacula, dump, xfsdump (backup)
clamav ⁽³⁾ (free anti virus solution)
ncftp, pdksh, bash-completion, ghostview, git, webalizer (user)
xfce, xplanet, scummvm (window manager and toys)
gnokii, gsmlib (mobile phone tools)
exif, exifprobe, exiftran, jhead (digicam exif)
pdftk (editing PDFs), scribus (DTP), mdbtools* (converting MS access files)
lots of perl and python modules
"suselinux manuals" in foreign languages (cs, de, es, fr, it, pt, ja, zh, ...)

I was kind of surprised about the fact that there are such tremendous differences. As it turned out – more see below – the Internet version is basically useless for myself (I don't normally use it for customers since 2 years update is not enough, but that's a different story). You have to make a decision for your own between the two Suse versions available, depended on your needs and time, ability and laziness to compile the missing pieces. For your help I've compiled a complete list of the differences.

Further Pieces

Compared to it's predecessor Suse 10.0 – I am talking about the boxed versions from now on – a few packets are not supported anymore, a few made its way into the distribution. In general the system is pretty much up to date with the recent versions (see key packages at the right hand side) with the exception of

GNOME version 2.12.2. 2.12 was 8 months old by the time Suse 10.1 hit the streets, actual is 2.14 which has a number of improvements, notably speed
and X.org. X11R6.9 and X11R7.0 were released simultaneously last year before Xmas. The only differences however is the modularized source code, so nothing a user worries about.

Completely gone is

the Mozilla suite, it was replaced by Mozilla's sunbird (which is not recommended for daily use yet),
AFS support: up to 10.0 there was a general, a client and a server RPM as well as a kernel module. If you want compile the user level stuff and thought you would get away by additionally "just" recompiling the AFS kernel module, note that you also have unset DEBUG_RODATA, otherwise you won't be able to use PAGs ⁽⁴⁾.
Say farewell to the easy integration of most non-GPL'ed kernel drivers, once a big purchasing argument for Linux newbies. Using Suse they had the best chances that their hardware is supported out of the box. In 10.1 somewhat half-hearted the policy for kernel drivers changed. There are a number of drivers missing like
- fritzcapi (ISDN) and ralink (WLAN),
- others however are included like the smartlink-softmodem and madwifi drivers (the latter one found its way into SLED 10 as well). Also the ndiswrapper is still included. Ndiswrapper is under GPL, however it permits to load Windows network drivers,
- the handy script fetchmsttfonts.sh which fetches and installs Microsoft TTFs (like Arial) is gone ⁽⁵⁾. Still you can just pull it from Suse 10.0 and run it if you want the TTFs from Redmond. Due to the lack of appropriate hardware I haven't checked whether the script fetchnvidia.sh which pulls and installs the proprietary NVIDIA driver works, too.
I haven't seen an official statement yet, but the policy of not including some proprietary drivers, omitting others and on the other hand including a variety of proprietary software like plan- and textmaker, Real- and Macromedia's flashplayer, Sun Java 1.4.2/1.5, and even Antivir deserves IMHO an explanation.
You might miss the possibility to import a so-called *.sel-file into the software package management during installation and afterwards (yast2 sw_single). People used it to specify a set of RPMs, either manually or for auto-installation. The need for latter one is gone, see below (XML-file).
You won't people hear loudly complaining about it: Finally gone is 3D support for Voodoo based graphics cards (libglide is gone, see Change-log for xorg-x11/Mesa). 3dfx cards are by today's hardware standards ancient, but were the best of breed before NVIDIA purchased 3dfx in late 2000.

Added was

yum: packet management made easy^TM. On the command line you can finally easily search, install, erase, upgrade, .... RPMs without worrying about dependencies, way better than with yast2 sw_single. Fedora Core had yum (Yellow dog Updater, Modified) since a long time, similar to Debian's apt-tools. rug does a similar thing, but unless you want to make use of extended ZLM functions you rather want to use yum,
Xgl, the animated desktop, similar to some effects of the Quartz Extreme desktop of Mac OS X. The good: Nice eye candy. The bad: Only a few graphics cards are supported. Besides cards w/ Intel chips you have to rely on proprietary drivers from ATI or NVIDIA. Most of the cards – except the ones for laptops – come with a fan which is not what I want. And: it breaks things things, especially if you're using KDE,
FUSE (File system in user space): As the name assumes it allows file system code to be not solely in kernel space anymore. A module fuse.ko is providing since official kernel 2.6.14. the kernel hook, the rest is task of the glue library libfuse.so and user space code. Implementations making use of it: GMailFS, ntfsmount, SSHFS and hopefully soon Solaris ZFS. As a user you just issue fusermount [options] mount-point. A side effect is that this allows file systems to write to and read from, which never would make it otherwise into the kernel because of license incompatabilites,
a thingy called NetworkManager applet. Especially for laptops using WLAN cards Novell recommends this. It's closer to the see-all-WLANs-by-SSID-and-pick-one method of Windows.

Added was also (small-and-nice-section)

the capability to write after the manual installation an XML-file (normally /root/autoinst.xml) which contains all settings done during the installation process. It eases auto-installations or on a lower level cloning of the system from scratch ⁽⁶⁾.
an /etc/auto.smb file, similar to /etc/auto.net. Similar to the latter one it allows to mount SMB shares, but it's restricted to those which can be anonymously mounted. You will see also shares in /smb/hostname which need a userid/password. The confusing thing that it looks like you can chdir to it but in fact you don't (see system log file). This is a newer feature of autofs, it's also in Fedora Core 5.
kerry, a KDE front-end for the desktop search based on beagle.
a tiny shell script called service which functions similar to its counterpart from Red Hat/Fedora: it's another way of issuing rcservicename start|stop|whatever or /etc/init.d/servicename start|stop|whatever. However in this script and on several other occasions Novell got the PATH variable wrong, see /usr/local and NFS.

Updated was

Xen to version 3.02. As opposed to 3.0 used in 10.0 it gives you the benefit of supporting natively x86_64 hosts as well as hardware virtualization with the help of Intel's Vanderpool and AMD's Pacifica (AMD-V) technology. As opposed to paravirtualizations the latter one enables you to run e.g. windows as a guest system. Suse 10.1 includes a nice and helpful yast GUI which auto-magically sets up the right kernel, installs necessary packages and does the (host part of the) configuration of the virtual machine,
the client side of package management framework. Now ZENworks Linux Management is the name of the game. See right hand side (column I am hungry) why it the client side is really disappointing at this point of time. As a part of this there's a new registration procedure for online updates. It generates a unique ID based on the hardware specs which will be transfered to Novell. If you worry about privacy, you don't have to do that,
KDE 3.4 to 3.5.1, OpenOffice 2 to OpenOffice 2.02, Firefox 1.07 to Firefox 1.5.0.1/4, Thunderbird 1.0.6 to Thunderbird 1.5/1.5.0.5,
MySQL to version 5, there are finally stored procedures and triggers. You should dump the tables before an upgrade,

Picture 2: Two new Yast modules

PHP 4, it was replaced by PHP 5,
Apache 2.0.5x was updated to 2.2.0, which has some new features. Important ones: Large file support (!), the configuration is more modular now. (Novell tried to modularize the configuration before already),
Samba to version 3.0.22, from 3.0.20b which besides offline authentication is mainly a security fixed update,
some Yast modules (see picture 2) were added: One which helps joining a Samba domain, and an iSCSI client module, the iSCSI server module is only in SLES,
Finally, after loudly complaining during my last reviews about it, there's a hint in the release notes about the fact that not all packages fitted on the CD-ROM, only the DVD gives you the whole nine yards.

Installation fun

So much for theory. Now I want to give you some reports what my experience was during a some rounds of installations on different systems.

But first a look at Suse's installer: Yast is amongst the best considering all the major Linux distributions. The graphical user interface was born at a time where competitors used a ncurses- – if any – GUI. It contributed significantly to Suse's reputation being a good distribution for Linux beginners. Some however might draw the wrong conclusion from this, which is that Suse is not good for the enterprise. This is not true [1,2].

Picture 3: Overview with Yast-installer

The Yast-installer gives you a good overview of the installation process and informs you of the progress and every step (see left had side in picture 3). Also: hardware detection is good and you will be prompted with reasonable choices. If you click "OK" you're most of the time fine with this default.

Compared to the predecessor however there is a remarkable change in the speed of the initial menu: To resolve software dependencies a dialog shows up ("checking dependencies" or "evaluating package selection") which takes sometimes up to a minute. In those cases it looked like it was due to the fact that the system was upgraded from a previous version and not a freshly installed one. My educated guess is that for this is rather the Red Hat Package Management to blame. The overview dialog would be more endurable if the delays would happen only during software selection. However it stresses your patience also if you just changed the partition layout or e.g. the time zone. Here is just the dependency on software dependencies wrong (got that?).

An somewhat old annoyance of the installer – specifically the software selection window: After clicking on Details you will be presented with different software categories. Depended on what kind of system you set up, you can install the appropriate software, down to the RPM level. The strange thing though is that you find packages in categories like apache "VoIP", bonnie/++, dbench, e3, emacs, g3utils as well as minicom, rzsz, rsync, smartmontools in the "Kernel Development" section. Another example: xorg-x11-libs, mysql*, qt3 and some TCL-stuff in "Simple Web Server with Apache2". The impression is that this might come due to RPM dependencies, it has certainly nothing to do with the context. The latter one is the criterion the user should be bothered with and not with the RPM dependencies which should be automatically resolved by the installer in the background.

Back to the good points: Apart from the possible automated installation with ( Autoyast) there are a variety of controls possible for the interactive installation: as usual from the console, and remote from a serial line, via SSH and via VNC. It's just a matter of the append option in linuxrc.

As for as normal interactive installations are concerned, Suse 10.1 works as expected. 10.1 installs by default with a reiserfs 3 partition. New in 10.1 is that automatically not only one root and a swap partition is suggested, the suggestion made includes also a /home partition which is the right thing to do on a desktop/laptop system.

As with other products I do QA for, professionally or for magazines, I am not only testing the "normal" features or procedures ⁽⁷⁾: they are always working. Well, at least thy should be. Since the development of Suse 10.x is "open" I thought I wouldn't find anything in the installation procedure. But I was wrong, there were two occasions where the installer hiccuped: There was an old hard-disk I had lying around, loaded with Windows 2000. The installer suggested to shrink the NTFS partition, but it failed later on to really do so (German message: Bei der folgenden Auswahl ist ein Fehler aufgetreten: /dev/hda4 wird auf 4.6 GB verkleinert: Systemfehlercode: -1021 (Update: This error was reproduced on SLED 10). Well, no big deal, except the fact that the installer left no choice to save any settings made for the installation, especially the software selection where I spend some time for. Unfortunately all this work was gone.

The second one hit me harder: I tried to upgrade my day-to-day used desktop system. I redefined the installation source for packman – the repository which I use mainly for multimedia apps like lame, xine, mplayer. As it turned out later, it was not the right thing to do: Somewhere in the middle of the 5 GB and 1400 packages to be upgraded, the installer wasn't able to find a package from packman. It complained about it, I hit the retry button and it segfaulted. It left behind a non-working installation. Suse's repair option wasn't able to fix the installation. Prospectively I did a backup before. Maybe including packman in the beginning was not the right thing to do, but an installer should never crash and leave a mess behind.

Another bigger point for criticism: Suse has since 9.3 by default an automatic login without password for the graphical display manager enabled. This is a somewhat high security risk and a large step backwards in time where people didn't have to provide credentials for accessing private data. More on this see automatic login on the right hand side.

The good, the bad and the ugly

Here are some reports about the experiences I had since the two months in production. Except maybe the fact that Xen was upgraded, the kernel was no real surprise. Changes nowadays are not anymore of a drastic nature. Reiserfs4 support in the kernel is gone – also in userspace. Still supported are the variety of other native Linux file systems like ext2/3, reiserfs3, XFS, JFS. OCFS2 is supported since Suse 10.0, whereas AFS as I mentioned above shares the same fate as reiser4. Suspend to RAM and suspend to disk on the three different x86 desktop systems still doesn't work. On an old Thinkpad wake up from suspend to disk now finally works. Suspend to RAM still leaves the TFT backlight lit (radeon graphics card) which makes Suspend to RAM useless. The Suse 10.1 kernel doesn't support suspend2, the one in the kernel has some restrictions but made some progress in the past (SMP and e.g. x86_64 support).

Speaking of the laptop: One annoyance is the fact that the serial ports – the wired one and the infrared – of the Thinkpad are useless after a ACPI-suspend-resume cycle. It's a known kernel bug since more than a year. The workaround affected: rmmod and modprobe the appropriate module after resume (8250 and serial_core). Unfortunately Suse's kernel needs to be recompiled, both are compiled into the kernel (CONFIG_SERIAL_8250=y and CONFIG_SERIAL_CORE=y). Alternatively: Use APM, you don't have this problem then.

On odd thing I noticed: If I copy DVD images on a particular server system equipped with HPT RAID controller from one partition to another, the new Suse kernel had the habit to slow down this box to a non-working status: the load was at 20 and beyond. hdparm /dev/hdx couldn't held its status of using DMA transfer mode. I am still investigating this (Kubuntu e.g. doesn't show this behavior). A mitigation on the high load could be achieved if I changed the default scheduler from cfq (Complete Fair Queuing Scheduler) to as (Anticipatory I/O Scheduler) or deadline by just echoing the appropriate name into /sys/block/<block device>/queue/scheduler. For some reasons Suse 10.1 chose cfq as a default IO scheduler.

Small issues

If you install via SSH or VNC (see above) you have to manually set the runlevel to 5. But also if you do so during the installation, yast won't ask you to configure X. You have to run sax2 manually afterwards. It looks somehow if you install remotely, the installer assumes you don't want to run X. Update: Reproduced on SLED/SLES 10.
Though amarok is still version 1.3.8 – as in 10.0 – it doesn't crash if I use it on my mp3 collection. This was a known issue caused by broken title tags. Unfortunately amarok version 1.4 was probably too late (May 19) to make it into the ISO-image. 1.4 has better iPod/iRiver support and a lot was done regarding audio format tagging.
digikam just crashes if the partition where the photos from the camera are copied to is full. As opposed to Suse 10.0 I have no timeouts anymore experienced using a Canon EOS 350 D.
A new cronjob appeared (/etc/cron.daily/01-rkhunter) which looks for rootkits with rkhunter. Generally of course this is appreciated. However cron reports false positives: Please inspect this machine, because it can be infected. On the command line there was no error reported, only a warning regarding the system files /dev/.udev, /etc/.login /etc/.cshrc which are definitely "kosher" and should be whitelisted in /etc/rkhunter.conf. Probably the exit value of rkhunter was only checked, not the reason why it returned not zero.
Another cronjob, /etc/cron.daily/suse.de-clean-core, had a strange complaint which is funny enough to be included in "fortune": Found core file older than 7 days: /usr/share/man/man5/core.5.gz
Somehow during the update process the installer managed to sneak mc (midnight commander, a norton commander clone) on my system. mc is more for newbies, unfortunately some mistype mv sometimes as mc. In a similar but more irritating category is the bug that GTK applications segfaulted after the upgrade. This is due to the fact that the gtk-qt-engine was reinstalled. It conflicts with baghira, a KDE-style which imitates Mac OS X. I didn't ask for installing additional software.

A trap ;-)

A pitfall is also that – if despite its lifetime you run Suse 10.1 as a server distribution – another update/change of snmpd/snmptrapd took place. Some time ago the change was converting from ucd-snmp to net-snmp. man snmptrapd.conf reveals (you won't find it in snmptrapd(8)):

Previously, snmptrapd would accept all incoming notifications, 
and log them automatically (even if no explicit configuration 
was provided). Starting with release 5.3, access control checks 
will be applied to incoming notifications. If snmptrapd is run 
without a suitable configuration file (or equivalent access 
control settings), then such traps WILL NOT be processed. See 
the section ACCESS CONTROL for more details.

The previous snmptrapd version was from NET-SNMP 5.2.1, now it's version 5.3.0.1. If you want to ignore the idea of the change – thus being less secure – add the following line to /etc/snmp/snmptrapd.conf:

disableAuthorization yes

By the way, if you're looking for a proper startup file, do the following:

mine: ~# cp /usr/share/doc/packages/net-snmp/rc.snmptrapd /etc/init.d/snmptrapd
mine: ~# ln -s /etc/init.d/snmptrapd /usr/sbin/rcsnmptrapd
mine: ~# rcsnmptrapd start
mine: ~# chkconfig snmptrapd 35

Instead of the first step you can also take this rc-file and the appropriate /etc/sysconfig/snmptrapd config file so that you have a separate place for the options of snmptrapd. Don't forget to chown 0:0 and chmod 750 both files.

Listening daemon created

The update also magically spawned a new daemon, and this also has a somewhat diabolic part: Suse 10.1 comes with hddtemp which monitors the hard drive temperature. It supports drives which support SMART (Self-Monitoring Analysis and Reporting Technology). The supported bus technology is (P)ATA, SATA or SCSI. So far, so good. The downside is that it's started by default and a TCP listening port is created. Everybody from the network can connect to this port. Ok, you might throw in that there's no crucial info or "so what, I am running a firewall". You're somewhat right, but it's still providing potential attack vector and some people just don't run a host- or network-based firewall. The daemon is even running as root, though the port used is above 1024:

mine:~# ps -ef | egrep -w "UID|hddtemp"
UID        PID  PPID  C STIME TTY          TIME CMD
root     16043     1  0 14:15 ?        00:00:00 /usr/sbin/hddtemp -d -f /etc/hddtemp.db -p 7634 /dev/hda /dev/hdb /dev/hdf
root     16353  6128  0 14:21 pts/6    00:00:00 /bin/grep -E (PID|hdd)
mine:~#

You can query the temperature either from localhost or remotely by just connecting to the port:

mine2:/tmp # netcat mine 7634
|/dev/hda|ST3160023A|44|C||/dev/hdb|ST3160023A|46|C||/dev/hdf|Maxtor 6Y120L0|SLP|*|

As you can see the drive temperature on this host is ok, though the heat in the bin where the system has it's home is currently heavily influenced by the rare German whether conditions (read: hot). Bottom line: Nice feature, however Suse should have given more info on this and not started after the update the daemon per default.

Bottom line

Suse has a good approach for their distributions. Yast eases management for the beginners. Also for experienced users it's lowering bar for new system administration fields, e.g. if you're not quite familiar yet setting up Xen, in Suse 10.1 you don't really have too much to think about it, supposed you don't want anything special.
Another bonus of Suse is that it comes with a host-based firewall – per default switched on – which is for the scenarios the distribution is meant for, good enough. It provides good logging rules which others don't (ok, this is more a minus for the others than a plus of Suse).

As far as this issue of Suse is concerned: Not quite comprehensible is for me the quality of the renewed package management, ZLM, as well as the fact that it took two months to get the first fix. You have to take into account that that because of ZLM the release of Suse 10.1 and as a consequence the enterprise products SLES 10/SLES 10 were delayed for approximately two months. Still as of today, there are issues like the not really userfriendly GUI and the fact that you have to pull complete RPMs instead of the ones which in the past provided the changes only. Fortunately you can switch ZLM completely off. Then there were the one and a half glitches during the installation. An installer is not supposed to segfault and leave a non-working installation behind.

What's the good part? Novell certainly managed to stay in the first line with the current hype topic Xen, the desktop search kerry is useful and the animated desktop Xgl – for those who have the right graphics card – is a nice thing. AppArmor including an easy to use GUI showed up the first time in Suse 10.0, which from the security perspective narrows the gap to Fedora Core. Fedora Core is using SELinux for mandatory access control since FC2. SELinux is tighter compared to AppArmor, whose main weakness is the fact that it is working with file paths [5]. On the other side SELinux is way more difficult to set up if you want more than the factory defaults provided by Red Hat. Fedora Core uses a number of further security measures, namely fstack-protector (aka stack smash protection/canaries), fpie, NX/XD-Bit and gcc FORTIFY_SOURCE. As well as the latter one is concerned, Suse 10.1 makes also use of it: Apparently everything is compiled with -D_FORTIFY_SOURCE=2, as retrieved from the OPTFLAG: rpm -qa --queryformat '%{NAME}-%{VERSION}\t%{VENDOR}: %{OPTFLAGS}\n' |grep SUSE. According to Novell some [4] binaries of SLES are compiled with similar hardening measures as Fedora Core. I'll investigate and verify whether this applies also for the non-enterprise product.

Despite the issues version 10.1 has, Novell/Suse still provides a good distribution. If you're not a long time Suse-user I would rather take it as a bad coincidence that the research you are reading is not giving grade A/B to the latest community product from Novell. Not that I am superstitious, but may be ".1" is a kind of a bad augury: 9.1 had quality problems, too. 9.2, 9.3 and 10.0 were not only in my humble opinion overall very good distributions.

Finally it would be great if Novell could be more clear about the names for their Internet edition and the distribution sold. If it is really policy not to provide a variety of important packages in the downloadable edition, the different distributions should have different names to distinguish them.

The development of Suse 10.2 started already, we'll see how good that one will be.

Dirk Wetter

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

Literature

[1] Dirk Wetter: Green Light, report about SLES 9, published in iX international 2004, p. 24
[2] Dirk Wetter: Nominiertenrunde (German), Comparison Enterprise Linux distributions: RHEL 4, SLES 9, UCS 1.2, Mandriva CS 3 (extract), iX 6 (2005) 48
[3] Dirk Wetter: Grüner Bock im roten Kleid (Review Suse 9.1), iX 6 (2004) 68
[4] Dirk Wetter: [title not clear yet], Comparison SLES 10, Xandros Business Server, to be published in late summer 2006 in iX magazine (German)
[5] Oliver Tennert: Die Schilde hoch, (research on Novell's AppArmor), iX 8 (2006) 70

Conclusion

Suse 10.1 is the basis of the enterprise products SLES 10 and SLED 10.

There are major differences between the boxed and the Internet version of Suse 10.1. The boxed product contains more packages. Mostly experienced users will miss them.

The packet and update management changed completely. For two months after GA there were problems using it and as far as the functionality and effectiveness on the client side is concerned, the ZENworks Linux Management ZLM is still technically behind its predecessor you.

During this research on two occasions the installer bailed out. During an upgrade it left a non-working installation behind.

Some non-GPL'ed kernel drivers are not in version 10.1 anymore.

Outstanding features: Xen 3.0.2 including an easy to use Yast module, yum, Xgl, MySQL 5, desktop search.

Key packages

Kernel 2.6.16.16 with Suse patches, Xen 3.0.2
X.org 6.9, KDE 3.5.1, GNOME 2.12.2
gcc 4.1.0 (with Suse patches), glibc 2.4
Firefox 1.5.0.3, Thunderbird 1.5, OpenOffice 2.0.2
CUPS 1.1.2
Samba 3.0.22, OpenLDAP 2.2.27
Apache 2.2.0, PHP 5.1.2
MySQL 5.0.18, PostgreSQL 8.1.3

(Those are the released versions, for some of them – e.g. Kernel, Thunderbird, Firefox – online updates were provided which upgraded them to later versions)

I am hungry: zmd.exe

One of the changes in 10.1 compared to its predecessor 10.0 is that the architecture for the higher level package management and online update changed completely.
Being used is a suite called ZENworks Linux Management which is basically the client part of a client-server architecture. It is supposed to ease management of systems, specifically if you're having large installations. If you have had contact with Ximian Linux and rug and their Red Carpet Daemon rcd you might know the already client side a bit.
Providing this is in general a good idea, since Novell had nothing really to offer to centrally manage Linux systems before ZMD and was as far as this is concerned a little bit behind their competitors like Red Hat (provisioning module) and e.g. Sun (N1 System Manager and Service Provisioning System).
According to some news from Suse the ZLM client – i.e. the tools around the ZENworks Agent zmd, aka ZENworks Management Daemon – was one of the reasons why the GA of Suse 10.1 and as a consequence the enterprise products were delayed for some months. That wouldn't be a problem if the result would be good. But Novell's new framework of Software updates writing Suse 10.1 is very politely speaking not a piece of usability. And not a resource effective piece of software either.

During first contact the process zmd.exe and all it's DLLs (during runtime you'll see 42 DLLs linked against it) made me think "What is that?". Since I am using – i.e. pen testing – MS Windows myself, so in general I am considering myself to be open minded. ;-) The naming scheme of the Mono/C# framework is kind of strange in the Unix world and I never a really became a friend of. But if that would have been it, I wouldn't have written this.

The very first time you want to check the update status by clicking on the zen-updater icon in the KDE kicker tray (again a process ending with this ..cough.. syllable "exe" (zen-updater --desktop /usr/lib/zen-updater/ZenUpdater.exe) you have to add a user to the whole thing. "Why is that" I thought? Without having any privilege beyond my user account susewatcher – that was the name of the game up to Suse 10.0 – presented me with the packages to be updated. I was only prompted with a kdesu-dialog-box if I really wanted to update software, not to query the status.
Ok, so I added an user. It crashed, great! But wait: it was getting worse.
As I realized, adding a user was not done the Unix way: E.g. I didn't see an additional entry in /etc/group. Very transparent, thank you, I thought first. Ok, later on I realized that if I change my mind I have to use rug, e.g. rug user-delete does a task of removal.
This user-ID I added is more mighty than I wanted him to be: It's not only that this user ID can update software without any further questions, he can also remove/add install repositories. Great, so is this user basically is able to provide a repository where for example he put an RPM containing a /etc/shadow of his choice? I haven't checked yet whether this is possible.
It's damned resource-hungry!zmd.exe eats even more memory than the X-server (80 MB average). A few moments after logging in there were two processes spawned: First parse-metadata, then after a few minutes one called update-status. The latter one swallows up to 180 MB on top of zmd.exe. What the heck is Novell doing, I thought. A knockout criterion for running Suse 10.1 on old energy efficient systems w/ 256 MB, if you want to start zmd. (Some people tend to recycle those a dedicated servers for e.g. Squid, DNS, printer, firewall.) Worse: the load on my 2,8 GHz P4 when the sequence parse-metadata and update-status run, is between 1.2 and 2.5. Conclusion: A nearly 3 GHz system, 256 MB dedicated for ZMD and 5 minutes patience may be not enough.
If I want to configure ZMD and right-click then – i.e. immediately after logging in and the dust of update-status has settled so to speak – on the zen-updater-icon in the kicker tray, it took approximately 5 minutes (2,8 GHz Pentium 4, 6 Mbit ADSL) to get the configuration window filled with content. It's beyond my understanding why the tabs services/catalog/preferences - which only contain settings - take so long to draw. What actually happens is that the online update – are you sitting well in your chair? update-status – is started again. Did I request that?? No words.
Alternatively after logging in – update-status ate at this point of time already the resources for five minutes – I moved the mouse over the zen-updater icon and it is telling me that a certain number of updates are available. But if you left-click on it, update-status and parse-metadata again eat some CPU and memory for a few minutes. "WTF" I thought. (This time it took less, in my case around 3 minutes. Maybe something was – a little bit – cached... somewhere.)
You can repeat that game whenever you want: Wait for a while, then click on the icon and your CPU and memory will be happy that they are not idling around.
There are tons of leftovers of in /var/tmp:
```
mine:~% ls -ld /var/tmp/Tmp* |wc -l
3048
mine:~%
```
The number is getting worse day by day. Did somebody forgot to do housekeeping here?
The GUI is broken, too: zen-updater displays the details in a too small window, that part of the window is not resizeable. And: If I install software it only says .. guess what?.. "Installing Software". Why does this piece don't want to tell me what it is downloading, what patch/delta-RPM ⁽⁸⁾ it is currently applying? I don't know what the GUI designer drank that evening. Maybe they had a party with the software developers. ;-)
Speaking of it (i.e. patch/delta-RPMs): Seems that Suse is providing them, looking at the update directories in the Internet. However the client – as well as if you run yast2 online_update manually doesn't request them. There was a bug in Beta4 ⁽⁸⁾) which is still (~three months after Beta4) not fixed. Which makes Suse 10.1 compared to it's predecessor almost impossible to use having only a small bandwidth uplink connection to the Internet.

Bottom line: If you can do without the status of the icon just switch the whole "thing" off:

mine:~# /etc/init.d/novell-zmd stop
mine:~# chkconfig novell-zmd off

For online updates or a status check you have to manually use yast2 online_update. If you found a way to automatically check for updates ⁽⁹⁾, please let me know. rug list-updates does it (slowly), but therefore you need zmd running.

Update (July 18,2006):

Suse released an update for its zmd-framework on the client side: Amongst all the 9 (!) update RPMs one can find an update to the agent zmd and to libzypp-zmd-backend which addresses some of the issues. Notably the resource consumption is lower: load never exceeds 1.8 and the processes eat way less memory, especially as far as update-status is concerned: It seems to cut off at 80 megs. Still, the other issues are not addressed yet.

Update (September 19,2006):

Another two months later another major fix: Suse released a patch which brings back the delta/patch RPM feature, fixes the /var/tmp/TmpFile.xxxxx issue and makes it possible to run fetchmsttfonts.sh via online-update. From the info file:

This update contains the following new features: 
  * support for patch/delta RPMs in YUM sources (#168844)
This update includes fixes for the following bugs: 
  * various performance enhancements 
  * 190163 -kmp-dependencies match multiple kernel packages 
  * 195567 - 100 /var/tmp/TmpFile.xxxxx in 3 Days 
  [..]
  * 191676 - zen installer/updater cannot add an FTP YUM repository 
  [..]
  * 192535 - test fetchmsttfonts script does not get run

/usr/local and NFS

/sbin/service has this line with a hard-coded PATH containing /usr/local:

PATH=/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

Similar applies to the root-environment:

PATH=/sbin:/usr/sbin:/usr/local/sbin:/opt/gnome/sbin:/root/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin

Both ⁽¹⁰⁾ has reliability and security implications in an NFS environment where /usr/local is shared:
Suse/Novell as well as lots of other vendors put for not comprehensible reasons – this PATH is empty – /usr/local in their root-environment or even (like in /sbin/service) in system scripts. Imagine /usr/local resides on NFS, and

the NFS server is down — depended on the mount option the script which you issued as root to fix something just hangs. If /usr/local is in profile scripts or in the root $PATH you're lucky if you managed to log in, even on the console.
the NFS server is compromised. You could easily execute a trojan on your NFS client. In both the PATH above even ls or ssh is overridden. With a simple shell script it's possible to record passphrases and user account information.

Bottom line: A /usr/local/ PATH has no place in system scripts or in the root environment. Period. There's no need for it. Suse 10 is not the only distributions to blame. I discovered it in my research of SLES 9/10, RHEL 4, Mandriva CS3 and others (see [2, 4]). People writing these kind of system scripts or set up the system wide profile files probably never set foot in a data center and are not really far-seeing for security or NFS related problems. Don't want to start political discussions here, but Solaris does that better.

Automatic login

A security flaw by design is the by default enabled/suggested autologin feature of the display manager (fortunately not for the enterprise products):

Picture 4: potentially fatal xdm login feature

While finishing the installation and hopefully adding a user you will be presented with a dialog box (see picture 4). The point is that in this box the button for a graphical autologin is enabled by default. So a user which doesn't understand the implications at this point and is clicking "Next", is ending up with a system which has no access control on the graphical console. Switch it on or reboot it: enjoy, it's all yours.
I know that I don't want to have this under no circumstances enabled, you might, too. But what about the Linux or Computer newbie, does he know what the risks involved are? Why does Novell makes the wrong decision for them, especially since the distribution has a strength for this type of unexperienced user?
If you don't understand what I mean, here are some examples: I don't want a curious neighbor e.g. taking care of my plants while I am away have immediate access to all my data. All he would have to do is switching on the computer, – maybe the initial intention is just getting access the Internet – and after 2 minutes he is served will all my personal data on a silver platter. With desktop search based on beagle it's even more easier to find out may be what bank one is using, where the text file of the diary is located, what love letters somebody sent to his girlfriend. Beagle-searching for the name also brings up e-mails and instant messages to her. I don't even dare to think about if the careless user has set firefox/thunderbird to remember passwords but not protect it with a master passphrase. Note: These are scenarios for home users, the consequences might be more severe for office desktops or even laptops.
In the same window (see picture 4) the installer asked for a password – per default there are even simplicity checks and it's strongly encrypted with the blowfish algorithm. The set default button for autologin nearly of rendered this question for the password useless, supposed the system cannot be accessed from the network.
Dear Novell: Please don't enable automatic login by default. If you feel the need for providing such a thing at all, change to a safer default. This way you'll not potentially punishing the unaware. Only the people who intentionally checked this button have to live with their own decision.

What you have to do if you want to clean up that manually is to set DISPLAYMANAGER_AUTOLOGIN="" in /etc/sysconfig/displaymanager, and run SuSEconfig --module xdm. Alternatively you can directly edit the appropriate config files (for KDE): /etc/opt/kde3/share/config/kdm/kdmrc="" the AutoLoginUser and set AutoLoginEnable to false if the latter variable contains anything else.

Footnotes

¹) Basically there was a continuous row of technically deep technical reviews from Suse 8.1 to Suse 9.3. Also the Suse Linux Enterprise Servers 8 through 10 found the way in my lab, as well as their counterparts from Red Hat (RHEL 3 and 4) and a couple of other interesting distributions.

²) john the (password) ripper was provided later on via online update. Novell might have realized that their cronjob checking for strong passwords might not work otherwise.

³) clamav was basically replaced by several antivir-RPMs, a package known from the windows world. The drawback is that antivir's license is shareware: The included evaluation license expired on June 30th, it's use is only allowed for private purposes after registration. There's also an on-access version included, you need to install another package for the binary only kernel module. At this point I am really scratching my head about the contradicting policy of Novell regarding proprietary software.

⁴) PAGs, process authentication groups are a part of the security concept of AFS. If they cannot be used AFS falls back to using Unix UIDs. That means e.g. root on every host can su your Unix ID, using your AFS token to access your directories which you protected by AFS ACLs, see AFS FAQ.

⁵) It's useful if you want to get a 1:1 layout of documents imported from the Windows world. PDFs might have those embedded, doc-files certainly have not. You then rely on substitute fonts. However it's planned to provide later on the script: The MS TrueType Corefonts fetch script is not yet available, but is planned to be provided. It might take some days due to testing. Also zen-updater would currently install it everytime time, this bug needs to be fixed first.

⁶) Actually this is similar to what Red Hat is doing. Their kickstart file can also be found at the same location. If I remember correctly this came in RHEL 3.

⁷) A known example: A while back e.g. I discovered probably as the first one that Suse 9.1 had problems installing/upgrading systems with XFS [3]

⁸) Quote from the Most_Annoying_Bugs: Patch and Delta RPMs are not supported currently. This means the update will always download the full RPMs. This regression from previous releases will be fixed once the other more critical update problems have been worked out.

⁹) Up to Suse 10.0 this was possible by using a statement like online_update -kV -s -l de_DE >/tmp/you.$$; grep -q ^'No updates available' /tmp/you.$$ && rm /tmp/you.$$ || cat /tmp/you.$$

¹⁰) Besides: what has /opt/gnome/{sbin,bin}, /usr/games, /opt/kde3/bin and /usr/lib/mit/{bin,sbin} to do in $PATH from root?? (The value showed was from an interactive remote login shell.)