Home close (×)
Attention:   The information you find below is outdated

The master and the apprentice

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)
Yast's Xen 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 initiator (client in iSCSI terminology) (Open-iSCSI) and as a target implementation ("iSCSI server") 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 SLES 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 SLE 10

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. On the other hand: It's a pity that OpenAFS kernel module and applications are missing in SLES. Also – this has been critizied already in SLES 9: OpenOffice (and some other desktop applications) are only in SLED, but not in SLES. It disqualifies somewhat the server to act as a terminal server for thin clients.
 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. Though supported a Sun QFE 4-port 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.

Bottom line Xandros Server

For a data center environment Xandros Business Server needs more time to mature. Also if a server normally runs one distribution, a minus is certainly the point that the Xandros server configures swap on all partitions with ID 0x82. The update issue or the long time span until availabity of updates needs an explanation from the vendor. The problems which can be categorized as those for bigger servers like interrupts and SYSRQ are not that important for a SME product. In this category belongs also the sometimes confusing fact that for a data center administrator a graphical console seems to be needed too often.
 Nevertheless: If you keep in mind that this is Xandros' first shot in the server league and it is more targeted at SMEs, the product is standing out, especially with respect to other products in the same league which went through the hands of the author. xMC is conceptually thought-out and has a similar good GUI – giving a good overview – like the installer. This is remarkable for a newbie in the server market if you compare it with Debian, Ubuntu and also Red Hat.

Dirk Wetter, 9/20/2006


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

 


Discuss this article. « Back | del.icio.us

Discussions

Dirk Wetter wrote (12/1/2006, 2:30 PM):
slessrv:~ # dmesg | grep eth
eth0: SiS 900 PCI Fast Ethernet at 0xa000, IRQ 177, 00:e0:18:8d:1c:6d.
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
eth1 renamed to eth15
eth2 renamed to eth14
eth0: Media Link On 100mbps full-duplex
slessrv:~ # ifconfig -a | grep ^eth
eth0      Link encap:Ethernet  HWaddr 00:E0:18:8D:1C:6D
eth14     Link encap:Ethernet  HWaddr 00:11:0A:72:4A:BF
eth15     Link encap:Ethernet  HWaddr 00:11:0A:72:4A:BE
slessrv:~ # 
Update: The thing with the numbering of network interfaces somehow "hit" me again: After pulling out the QFE card the system now has a dual Gigabit NIC and the GE interfaces are named eth14 and eth15: Very strange! At least this time eth14/5 survived a reboot.

Permalink, Comments [0], Reply

















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

Testimony

SLES/SLED 10:

+  iSCSI server/client and Xen, both with Yast modules

+  AppArmor

+  WBEM/CIM

-  ZMD half-baked


Xandros Server 1.0:

+  xMC: Xandros' management console

+  Install GUI

-  suceeded local root exploit

-  Swap space


What lies ahead

Technically Xandros Desktop and – surprise, surprise – also the Xandros Business Server is based on Debian Linux, with lots of packages from the unstable tree. Spiced up are Xandros distributions with a modified KDE GUI which on the first glance makes it difficult to realize that it is still the K Desktop Environment . Needless to say that this change is a matter controversial discussions amongst KDE developers. Red Hat made a similar experience with respect to their Bluecurve look & feel of KDE a longer while back. In addition to the user's GUI Xandros put some programming effort for a (proprietary) management GUI, named xMC. (see lead picture 2). But more on that later.

As far as the installation process is concerned, the server from Canada doesn't behave much different than the desktop which shouldn't be much of a surprise. Of course setting up a server requires more thinking from the system administrator than sending four times the command from the brain to click the mouse button. A network based installation is not supported, however Xandros plans in the future the server to support xDMS which according to Xandros is providing a means for automated network installations, too.

According to the software selection dialog the installer preselected every software which was on the CD, which was about 219 MB. An LDAP server was not amongst the software packages. However there was BRU – a commercial backup solution – and the Open-Xchange competitor Scalix which is a descendant of HP's OpenMail e-mail and groupware server.

Xandros 64 Bit edition had to make itself comfortable on the Opteron server, in addition to SLES 10. As / a reiser4 partition was chosen, for swap the installer was instructed to use a separate partition.

Not just yet another graphical installer

The installation – at the graphics console – proceeded without problems and was giving the tester a good overview what is going on, similar to Yast. As opposed to Yast a few details like network configuration or root password are asked before installing the packets. Speaking of it: Also Xandros checks here for the quality of the password. It seemed to be more strict than SLE's, it refuses to accept root passwords with less than 8 characters, unless you uncheck a checkbox.
 You then have the option to decide for a "Primary Management Server". At this point you're confronted with the Xandros concept. However if you're not familiar with this you will wonder about this terminology and what the consequence of your decision will be, also if you look in the installation manual. If you say "yes" at this point the primary management server requires a "managed community name". Also this appeared to be somehow vague, and it's not clear whether this represents a real domain name or a samba workgroup, which will make problems with the rest of your network, or whether it's just a Xandros feature used for administrating the server.

After summarizing the settings and nod this through, the system was deployed within 10 minutes on the disks of the Opteron. After automatically ejecting the CD, reboot and a mandantrory xdm login as root – a thing which the author does not do voluntarily – the installer started a "First Run Wizard" to complete the install, first with the language settings. However there was only a choice between British und US English, which might impose a problem for a SME admin outside an English speaking country. Well, to be quite frank: internationalization seems not to have a high priority under Linux as under Windows or even Solaris. Thus the author prefers a single language (English) instead of a mix of 10% German and 90% English which most Linux distributions are presenting.
  The installer was continuing with time zone configuration, then it asked for punching in a 25 character activation code.

How does it look like?

At first the author was curious about the security of the system. As it turned out the Xandros Server could do better: Not needed ports were open: the portmapper is listening, so is PostgreSQL and CUPS. The latter ones were both not configured at this point. Also there was a samba and OpenLDAP server waiting for requests. Similar to the Debian root of Xandros, there no host-based firewall switched on, though the Xandros Server has a reasonably good one, see below. The worst thing: the author was able to perform successful privilege escalation to root via a PRCTL core dump exploit. That was two weeks after Novell released their late patch and without really trying hard. Another issue: Without digging too deep the PHP version 4.3.10 seemed to be dangerously out of date. Until editorial deadline it was not quite clear whether the access to the updates was working. In any case: by using apt-get as well as the GUI XandrosNetworks, slightly reminding on konqueror, no updates were found.
 In other aspects Xandros Server seemed to be secure, maybe a little bit too secure: Per factory default there was no way of accessing the system over the network. The first step after installing the rackmounted server with keyboard, video and mouse was to switch on SSH and put the Opteron system in a rack. The ssh daemon was strict in it's configuration: root access was forbidden at all and keys were only generated for protocol version 2 which is a good measure.

Live together in peace and harmony?

There's a whole zoo of filesystems which Xandros supports. Besides the ones the installer offered – ext2, ext3, reiser3 and reiser4 – JFS as well as XFS supported. The support of the latter one was appreciated because the filesystems from SLES could be mounted.
 The deeper the author looked the more problems he spotted: The second swap partition, dedicated to SLES, took Xandros, despite the fact that during installation the server was told not to it. Under some circumstances this is dangerous: there could be a suspend image from another installation. Worse: Solaris x86 had until recently the same partition ID which means that Solaris x86 would have been wiped out. Also every interrupt was handled by CPU0 and the kernel doesn't support SYSRQs. A minor point for a server: The author was missing his zsh.

MCs rule the world

If the admin would like to avoid the command line, that might be not rarely the case for a SME product – the Xandros Management Console xMC (see lead picture 2) is in command for taking orders from the system administrator, the binary is named xmc. xMC is a proprietary client application with KDE look and feel. Similar to Microsoft's MMC or Sun's SMC it's possible to manage not only one computer, but a group of machines. That's not all: xMC's intelligence includes managing almost all services which are included in Xandros Server, one can look at log files, generate reports and it also has a firewall based on shorewall. That helps SME admins to avoiding a too intimate contact with netfilter/iptables. Also, logging per default is supported fortunately, every filter rule has somewhere a log target. xMC has more built-in intelligence: if you e.g. switch on NTP or SSH it prompts you whether it should also open the according port in shorewall. During the relatively short test in the lab however xMC made a small blooper: manually it was not possible to add a rule for incoming connections. Independent on what was clicked, the GUI was always adding one for outbound traffic.


© 2006 Dr. Wetter IT-Consulting and iX magazine, copying longer parts of the text requires the written consent of the author and the magazine.