The master and the apprentice

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 set with reasonable defaults and you have the choice of changing the following options: partitioning, add-on products, software

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

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 IBM hot keys Fn-F3, Fn-F4, Fn-F12 (suspend to disk) were out of the box properly doing what thy are supposed to do. Lid closing was assigned to suspend-to-ram. But since it the ACPI implementation doesn't support this properly yet, Novell as a consequence correctly didn't configure suspend-to-ram. But in this case it means that nothing happens if you close the lid. If you want to change this you have manually edit /etc/sysconfig/powersave/events or use Yast.
 The internal bluetooth device of the Thinkpad was automatically detected and accordingly some bluetooth 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 on the test lab environment. 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.