The master and the apprentice

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 4-port 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 naming scheme changed sometimes during boot or/and an interface named eth2xx was showing up. That vanished as one of the NICs was removed.

Slimmed

Novell said goodbye to a number of software packets: Sadly, 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.

Security measures

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 (one) and on the other hand more or less almighty users (zero). Even Microsoft has implemented in Vista a variety of measures, similar to a Mandatory Access Control (MAC) model, they call it Mandantory Integrity Control. But even Windows 2003 and e.g. its IIS 6.0 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.

Picture 8: Yast's Xen module

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.
  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).

Extract

• After SLES 8 and 9, SLE 10 is the 3rd generation of Novell's Linux enterprise product
• Xandros' Server has recently joined the arena of the Linux distributions.
• Increasingly graphical tools are available to help system administrators to perform their work.

Under the hood

• 2×Dual Core Opteron 270 @ 2 GHz
• Tyan Mainboard S2891,1×PCI-X 133 or 1×PCI-E x16
• 8 GByte (4×2 GByte) ECC RAM, DDR 400
• 1×250 GByte SATA Maxtor, 4 disks possible, slimline DVD-ROM reader
• 2× onboard Broadcom Gigabit Ethernet

Software and prices

• Kernel 2.6.16.21 incl. vendor specific extensions,
• glibc 2.4
• gcc 4.1.0 + extensions
• X.org X11R6.9, KDE 3.5.1, Gnome 2.12.2
• Xen 3.0.2^*,
• Open-iSCSI client and iSCSI Enterprise Target^*,
• Apache 2.2.0, PHP 5.1.2^*,
• Samba 3.0.22^*.                             (^* SLES only)

• Kernel 2.6.15 incl. suspend2,
• glibc 2.3.2,
• X.org X11R6.9
• gcc 3.3.5,
• Samba 3.0.21b incl. Xandros extensions,
• KDE 3.4.2 incl. Xandros extensions,
• Apache 2.0.54, PHP 4.3.10,
• Scalix Xandros Edition Groupware (32 bit), BRU Backup Server, both incl. 5 user licences.

Rag-rug

Novell has remade the update respectively the high level package management, which was the reason for delaying the "father" (Open)Suse 10.1 and consequently also the "child", i.e. SLE 10. To be quite frank: the implementation of the new framework is not something Novell can be proud of. In addition to the delay of (Open)Suse 10.1 it took another two months until ZMD, the ZENworks Management Daemon, was usable on a (Open)suse 10.1 desktop installation. Before that users had to live with a zmd.exe process eating up to 256 MB of memory and CPU cycles in the minute range. This waste of resources is fortunately spared SLE costumers, since the changes which provided a relief for (Open)Suse 10.1 are integrated into the final version of SLE 10.

Now, six months later, ZMD is still not through with the teething troubles: In SLED the status icon in the tray (ZenUpdater.exe) is querying way too often the update server. The results are not cached or cached only for a very limited time as opposed to the old mechanism in OpenSuse 10.0. Also: the ZMD backend is quite verbose regarding its log messages: 10 MB per day is not something unusual. As opposed to previous Novell/Suse products there are still no delta or patch RPMs available, which only supplied differences to the original RPMs and thus saved bandwidth and storage. Ok, that might be not a big problem for the enterprise. The button "Remove Source Packages after Update" in YOU, the Yast Online Update, has no effect: under no circumstances the (full) RPMs will be stored on disk. rug, the command line frontend for ZMD, utters sometimes quite strange messages: rug install ABC returns: ERROR: 'ABC' is not available, or is fully up-to-date. That info doesn't apear very decisive yum, included in (Open)Suse 10.0/10.1 and SLED 10, but missing in SLES 10 is more precise in its messages. In SLE it's not obligatory (yet?) to use ZMD for updates. You might as well switch the daemon off by chkconfig novell-zmd off; service novell-zmd off. The drawback of that: package updates have to be manually performed by using the old method yast2 online_update and a plain check for new packets like the old online_update -k is not possible. But in an enterprise environment you don't go manually around apply the recent patches, don't you?

Good things last: The connection to the update server was "upgraded" from HTTP to HTTPS, which prevents in principal e.g. ARP or DNS spoofing of the update server. HTTPS means also that the account data of the portal is not any longer transmitted in clear text. SP3 of SLES 9 introduced this feature, too – without the use of ZMD.