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.

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

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

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.

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.

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.

Snapshots with Btrfs

In the release notes, SUSE conscientiously points out that SLE differs from its predecessor in several fundamental ways: the filesystem is the first. SLE comes with Btrfs as the default for the root filesystem, making SLE the first major Linux distribution to rely on Btrfs.

SUSE makes it clear that its support for Btrfs is not a PR stunt. SUSE has deployed some development resources in recent years to meaningfully integrate Btrfs with SLE. This effort gave rise to tools such as Snapper [5], a smart tool used to create snapshots across the entire filesystem. (Btrfs's built-in support for snapshots makes it an ideal option for an enterprise Linux filesystem.)

Snapper gives admins the ability to create snapshots of files, folders, or the entire filesystem at will, but also to delete these snapshots or dump them in a different location as a backup. This feature can save admins much work; for example, you can easily create a snapshot of the entire filesystem via Snapper before updating the SLE 12 system. If the update proceeds without problems, admins are happy – and if the update goes wrong, they may not be happy, but at least they are not worried: Thanks to the Btrfs snapshot, you can restore the state of the system before the update at any time. Only the /boot directory is not covered by this snapshot mechanism. Currently, it is still impossible to boot from a Btrfs partition. Therefore, /boot is always on a separate partition and uses a different filesystem, which means that, to undo a full system upgrade, you might need to manually remove the installed kernel.

Welcome to Systemd!

Under the SLE-12 hood, you will find several changes that you will probably not notice at first glance. For example, the ancient System V init is no longer present. SUSE instead uses systemd – a bone of contention in the Linux world. SUSE developers wistfully refer to System V as old and venerable in the 12 changelog, but whether admins will mourn the old dog is doubtful. SLE 12 boots much faster compared to the previous version, because it can perform various operations in parallel.

Not Broken: the Wicked Network Manager

In the wake of the systemd change, SLE introduces 12 additional innovations; one example is the new Wicked network manager [6] (Figures 7 and 8).

Wicked is an in-house development, which was initially tested in openSUSE, and which SUSE now considers mature enough for production work in the enterprise. On the surface, everything is the same: as in older versions, you still configure the network with YaST, and you can continue to use your existing configuration files from older SUSE systems without any restriction. However, if you want to look into the network configuration beyond YaST, you need to rethink. Wicked is deeply integrated with the D-Bus messaging system and comes with its own command-line tool.

The question is whether SUSE is doing itself a favor with Wicked – hardcore admins don't typically appreciate new tools that perform provide basic tasks with a higher-than-necessary level of complexity.

SLES and SLED

SUSE maintains the core SLE 12 distro and then adds components that convert the platform into the SLES server or SLED desktop. Both flavors come with a few very interesting new features.

SLED 12: Hello Gnome?

SLED 12 comes with a big surprise: The desktop is Gnome 3. The new Gnome is a surprising choice because SUSE is closely linked with KDE in the minds of many users. For many years, KDE was the default SUSE desktop. In SLED 11, users had to choose between Gnome 2.4 and KDE 4.1. Both desktops were on an equal footing in SLED 11.

SLED 12 comes with Gnome 3, along with the matching shell, as the default environment. Packages for KDE are nowhere to be seen. In other words, SUSE is committing SLED users to Gnome 3 without an alternative. Bearing in mind the fact that Gnome 3 is about as popular as systemd with half of Linux world, this is a very dramatic decision that certainly remains a mystery.

Of course, enterprise systems are only viable if the vendor can keep the support costs low. Given that European users are more accustomed to KDE, and SUSE still has a far greater market share in Europe than in the Red Hat-dominated US, SUSE's reasons for ditching KDE remain a mystery.

SLES 12 for Virtualization

The changes in SLES are more subtle, but clearly SLES 12 is a redesigned product. One area that has undergone significant change is virtualization.

Of course, SLES already had support for standard virtualization tools such as KVM, but the latest version does a significantly better job with integrating containers. This happens in SLES 12 on the basis of the LXC container interface tool, which is seamlessly integrated with libvirt and the system's virtualization management. The ubiquitous Docker is also in place and available as a technology preview; you can try out the Docker software, but for now, SUSE will not provide support.

Those who use MySQL on SLES need to rethink in version 12: MariaDB is now the default, and it is fully covered by the framework of support contracts. No need for database admins to worry, however, because MariaDB bills itself as a "drop-in replacement" for MySQL.

In SLES 12, even the library packages go by the name of libmysql and can only be identified as MariaDB based on their version number (10.0). In other words, although this change is technically quite significant, it is unlikely to affect the admin's everyday life.

Desktop or Server?

How closely SLE, SLED, and SLES are intertwined becomes clear when you look at the "Workstation Extension for SLES 12." This extension is basically just an additional repository that adds to SLES the SLED packages that are missing from the box. A real SLED license is required to use the workstation extension.

SUSE itself explains what this extension is good for: if you need the SLES features, but you would like to use the machine as a workstation, you can add all the necessary features with the SLES extension. Figure 9 shows the SLES 12 screen saver at work.

High Availability and Geo HA

SLES 12 offers add-ons for (geo) HA and public clouds. The HA plugin is an old acquaintance that already saw heavy use in SLES 11. The plugin includes components that admins need for high-availability clusters: Pacemaker and Corosync, as well as the glue that holds these components together.

SUSE has a traditionally close relationship to the HA stack: After all, Andrew Beekhof, the main Pacemaker developer, was with Chameleon services for several years before the Red Hats recruited him.

The HA extension is what admins are familiar with from SLES 11; the only new feature is a small tool designed to help set up a Pacemaker cluster, which should help to speed up deployment.

The more interesting feature is an add-on for the HA add-on that enables Geographic (geo) HA on SLES. Geographic high availability differs from legacy, local HA in several respects.

Key factors, such as replication, which are easy to handle on local networks, are real challenges on the WAN. When the network includes multiple datacenters, complicated questions arise. For example, which datacenter do you want to be the active component if two datacenters in an HA configuration lose eye contact? Who decides which dataset and which end is up to date?

Pacemaker itself does not include all the necessary functions to answer these kinds of questions, but SUSE delivers these features in the HA geo add-on: Booth [7] is a Pacemaker add-on that logically maps several data centers in the cluster and manages them accordingly. Booth works with internal tickets and uses the functionality provided by Pacemaker. A site can only operate a service if it has received a corresponding ticket from Booth (Pacemaker refers to this as a "location constraint").

The validity of tickets is limited; Booth has to regularly renew the ticket. If the site that had the current ticket goes down, Pacemaker automatically realizes that the service is no longer running and issues the remaining site a new ticket. For this principle to work, Booth has to run at a third location, which looks at both sites independently.

Although the entire process sounds complicated, much kudos goes to SUSE for Booth – geo-clustering with Linux is probably not implemented better anywhere than in SLES 12.

Conclusion

In SLE 12, SUSE has come up with a platform that is likely to please both SLED 12 and SLES 12 users. Apart from the aforementioned bugs in YaST, the system proved very robust in our lab. With regard to the YaST rewrite, I just need to reiterate that our editorial team only had a prerelease version SLE 12, not the finished product.

Anyway, SUSE seems to have learned from the feedback for SLES 11, and it is now putting SLES 12 through significantly more testing.

SLES 12 impresses as a product: The distribution scores points with meaningful and useful features. The Wicked network tool left our test team puzzled in some cases, although it does look ready to be usefully deployed and meaningfully controlled on the whole. The available add-ons, such as (geo) HA and the SLES Workstation Extension, contribute towards making SLES a solid computing platform.

The vote on SLED, which is also based on the SLE 12 platform, was less clear. A later test will reveal what is really hiding behind the SLED facade.

One thing is clear: The approach of building an enterprise desktop on a modified Gnome 3 is risky for SUSE, because its target audience has mostly used KDE in the past. We don't know yet whether this decision will prove good or bad, but it is certainly bold.