New Chameleon

At the end of September, a very exclusive green USB stick with the SUSE logo reached the ADMIN magazine editorial office. The stick contained an image with the current pre-release version of SUSE Enterprise Linux Server (SLES) 12 [1], including the plugins for high availability. The test team had the chance for a first look at what SUSE has been up to, and we discovered they want to keep enterprise customers in a good mood for the next few years.

The universal truth for all long-lasting enterprise distributions applies equally to SUSE: What is broken in the new version of SLES to the extent that it cannot be fixed with an update will regularly come back to haunt the support team – and admins – during the next few years. Nonetheless, SLES 12 does come with some major changes. Among other things, the default filesystem will be Btrfs in the future – you can't say the SLES developers lack courage.

Linux 3.12.26 is no longer the latest kernel, but it is an LTS version and thus the logical choice for SUSE. As expected, all major server programs are available in sufficiently recent versions for enterprise systems.

We took a tour of SLE 12 pre-release USB stick that arrived in our office just in time for this issue to go to press. The good news is, as of October 27, anyone can now gain an impression of the full SLE 12 release, which means some of the bugs uncovered in our journey might already be fixed.

In the Beginning

In the preliminary release notes for SLES 12, SUSE makes it clear that the installer has undergone significant modifications. If you have ever installed SLES 11, you wouldn't need a note to see the change: Compared with the previous versions, the SLES 12 installer is rather drab, keeping to a very dark color scheme (Figures 1 and 2). We were not able to clarify whether this background is just for the pre-release version, or whether this is actually the new design for the SLES installer.

Figure 1: The new SLES Installer, which is very dark for some unknown reason, is more suited to users who prefer subdued lighting.

Figure 2: The boot loader, which allows the choice between a normal boot and a rescue system, appears after the installation.

From a technical point of view, the installer runs fine: It routinely goes about its job and installs a basic system on your hard drive; you then run YaST to install the packages that transform it into your preferred SUSE flavor. The installer also lets you enter the credentials sent to you by SUSE during the install and thus register the system (Figure 3).

Figure 3: Entering the registration code lets you unlock features of the add-on modules in YaST.

A list of all available add-ons automatically appears in the installer, and you can integrate them in the same way. At the end of the process, you have a SLES system that already is fueled up with all the available security updates and that uses the package sources you have access to via your SUSE access codes (Figure 4).

Figure 4: Gone are the days in which you had to enter repositories in YaST by hand. The registration server takes care of configuring repositories.

New and Fast YaST with Ruby

The first boot into the new system after installing SLES takes you to a tidy Gnome desktop. Because we only tested SLE-based SLES extensions, the workstation components and all other graphical gimmicks were missing. Admins will tend to access the system via SSH, but the SLES 12 desktop is more than adequate (Figure 5). If you want to enable SSH access on SLES 12, you will probably do so through the YaST configuration tool. If you use the graphical version of YaST, prepare to be amazed: The tool is totally unrecognizable compared with SLE 11.

Figure 5: The SLES desktop is reduced to the bare essentials: The developers know that the UI is less important on servers.

The reason for this change is something that attentive openSUSE users might already know: SUSE decided to completely rewrite YaST in 2013. The old version was written in a proprietary language, YCP (YaST Control or Programming language), that aggravated many YaST developers [4].

The decision was to rewrite YaST in a standard language: The new YaST uses Ruby, and it is clearly much faster than its predecessor. However, our test team preferred the clarity of the legacy YaST interface. The new YaST interface is reminiscent of the KDE control center or the Xfce configuration dialog (Figure 6). If you have many tiles for individual modules, the window quickly becomes cluttered.

Figure 6: YaST resembles the control centers of other popular desktop environments after a rewrite in Ruby.

Too Many Unexplained YaST Crashes

The new YaST in our preview copy crashed several times performing actions that are quite commonplace. When we attempted to enable the geo part of the HA add-on, YaST complained, for example, that it could not reach the requested URL and then just disappeared. A similar mishap occurred when we attempted to launch an online update. YaST complained that no update repositories were enabled before it once again showed us the dialog for registering the system with SUSE – and then it crashed.

Although we were able to work around the problem via the YaST module for package installation, we sincerely hope that SUSE finishes off the troubleshooting work between this version and the final release of product. After all, a rewrite in Ruby is very welcome, and it would be a pity if admins were disappointed by a lack of quality from the new YaST.