Later this year, SUSE will release the long awaited SUSE Linux Enterprise Server 12, the first major release in five years. As I write, we’re deep into the beta process, and it’s shaping up well, but of course this article is based on beta software and things may change before the final release. So, caveat lector!
SLES has matured nicely since version 9, with each subsequent release bringing incremental improvements in stability, scalability and usability. There have been some huge improvements, like the introduction of the zypper software manager in SLES 11, but in general there have been no fundamental changes.
Well, that’s about to change with the release of version 12. For this release, we will have a new default filesystem, a new system initialisation manager and a new bootloader to name but a few. We’ll take a look at these features later in this article, and deeper dives in future issues, but let’s take a look at what’s driven this change.
The SLES 12 release is based around four guiding principles:
- Best managed Linux operating system
- Continuously running systems
- Most interoperable OS
- Made for Cloud
So, what does each of these mean?
Best managed
Systems management is usually thought of in two respects – local system tools, and system/network wide tools. There is a huge amount of work going on in both areas for SLES 12, but you’re going to have to wait for the next edition to find out about some of the new features! For this article I’m going to concentrate on our beloved YAST. YAST is already known to be the best Linux configuration management tool, so can it be improved? My initial impression is a resounding yes!
The first thing that you’ll notice is the new look and feel as soon as you fire up the installer. It feels sharper and fresher, much more in line with current trends for interface design. But, there’s far more to it than a makeover of course.
If you’re familiar with installing SLES then you’ll be used to the workflow of doing basic filesystem and software configuration, rebooting, configuring the network, applying patches, rebooting and then configuring services (see figure 1). Well, the new workflow is somewhat different. The first stage of the installer is now network configuration. This gives you access to online repositories, patch channels etc all the way through the installation.
The next step is registering the system with the all new SUSE Customer Center, or a local registration server such as SMT. Successful registration will give the installer access to the update channels even before the software selection stage, so every package that is installed will be at the latest possible patch level to ensure system stability and security.
After that, it’s down to the usual system configuration; software, disks, services etc, and then a reboot after the software has been installs. That’s it – the server is up and running. So, an individual install is much slicker, and of course AutoYaST is still there for automated installs.
Once installed, the look and feel of YaST is carried through to the running system – the concept of a single installation/administration tool is very much in evidence here. One the face of it, YaST has received a number of smaller updates, but under the hood, much has changed. SuSEconfig is no more, the YaST modules now do all of the work themselves.
The real change in YaST is the language used to create YaST modules. YCP is no more, the modules are now written in Ruby. SUSE developed an automated tool to convert the code from YCP to Ruby without any change in stability or functionality. Individual modules will be refactored over time, and new code will be written natively in Ruby. This will significantly increase the maintainability of YaST in years to come, and means that you can now easily extend YaST by writing your own modules!
Another under-the-hood change is the move to a new network management layer. Here, Wicked steps in to simplify the myriad of different possible network configurations and scripts. Wicked is a DBus complaint service that controls the runtime configuration of your interfaces, including features like DHCP and WPA supplicant for WiFi networks. It provides drop in replacements for ifup, ifdown and uses the same format ifcfg configuration files (for now!), so you really shouldn’t notice any difference.
One place where you will notice a difference is the move away from the traditional SysV init daemon to the more modern and function systemd. OpenSUSE has been using systemd since 12.1, so it’s really only new to SLES.
You may have heard a lot of things about systemd, such as it’s only there to speed up the boot times of desktop distributions. Well, it certainly does that, but that’s only a tiny part of its purpose. If I had to pick a killer feature, well, I’d actually have to pick two – service monitoring/restarts on failure and drop-in unit file overrides.
To ease the transition to systemd, SUSE have re-engineered the traditional tools to make systemd calls, so shutdown, service rcwhatever will still work. That doesn’t mean that you should continue to use them! systemd offers so much new functionality that you really should take some time to get to grips with it and I’ll be covering this in a future article.
Managing your subscriptions is an important part of the SLES lifecycle. SUSE have introduced the new SUSE Customer Center (SCC) portal. SCC will be the online portal for managing all of your SUSE subscriptions, licenses, systems and administrative users. Lessons have been learned from the Novell Customer Center, and SCC promised to be much more flexible and easier to use.
Last but by no means least, SUSE announced at SUSEcon last year that they are committed to a 10 year general support lifecycle going forward. SLES 11 gains this with SP4, whereas SLES 12 has it from day one. SLES 12 also allows you to stick with any release, including GA, for an extended period of time through the Long Term Service Pack Support (LTSS) program. This allows you to purchase extended support for a particular release rather than having to move to a new service pack when it’s released, giving you more breathing room.
Continuously running systems
The focus of the second principle, is quite simply to ensure that the server is up and running for a greater percentage of its time. SLES 12 builds on the stability and performance of SLES 11 but aims to further reduce downtime by adding a major feature to the initial release and planning for more improvements during the lifetime of SLES 12.
These future improvements are two-fold. Firstly, with appropriate hardware support, the SLES kernel will be able to detect unreliable memory and CPUs, and move processes away from these to more reliable components.
Secondly, there is work going on in the upstream codebase to allow the kernel to be patched without rebooting the system! This new technology is known as kGraft and is currently under heavy development in SUSE Labs. Both of these features will appear in future versions of SLES 12.
The new feature that makes this release is something that we have been asking for for years – patch rollback. Implementing this feature requires a bold step on SUSE’s part; the adoption of Btrfs as the new default (and recommended) root filesystem.
You may have heard of Btrfs, it’s actually been in SLES 11 for the last two service packs, but you probably haven’t used it. Changing filesystems is always a scary prospect but there’s a compelling reason to do so. Btrfs is a Copy-On-Write (COW) filesystem rather than a journalled filesystem. There isn’t time in this article to go into what this means, but the biggest benefit is the ability to take snapshots within the filesystem.
SUSE provide the snapper tool and libraries for doing just this, and the system is built to enable them. These snapshots are created through various mechanisms; periodic, time based snapshots give point in time recovery potential, but more importantly, both YAST and zypper are snapper aware and will take pre and post snapshots whenever you perform an admin take of software installation.
These snapshots are the basis for the system rollback functionality. The updated bootloader software, GRUB2, is fully aware of these snapshots, and adds an entry to the boot menu that gives a list of them all. All you have to do is pick the one that you want and boot from it! At this point, it’s mounted read-only, but you’ll be able to see if the system boots.
If you’re happy with the snapshot, all you need to do is to commit the rollback and you’re up and running. There’s a lot of detail behind the scenes on this feature, so expect a deeper dive article later in the year.
Made for Cloud
Whether you’re looking at public or private cloud solutions, SLES 12 is going to be part of the solution.
From a guest OS point of view, SLES 12 builds on the perfect guest idea that has been around since SLES 11 launched. There are updated drivers for all the major hypervisors, and a major step forward is the inclusion of the Open Virtual Machine Tools project. This is an open source implementation of the VMware tools that provides much of the functionality of the proprietary tools, but it’s shipped with the OS and updated via the normal update scheme.
On the host side, both XEN and KVM see some significant performance improvements, particularly with Microsoft Windows guests. There’s also the inclusion of the Open vSwitch technology.
This software defined networking stack has been brought over from the SUSE Cloud product, so it’s definitely ready for prime time. It will provide significantly richer network configuration options for your own virtualisation hosts.
Most Interoperable Operating System
The final area of focus for the SLES 12 release is interoperability with the rest of your estate. There’s improved IPv6 support for those of you heading down that path, but the thrust of the interop improvements come in Microsoft Windows compatibility.
SLES 12 utilises the Samba 4 codebase which opens up authentication options for later versions of Windows and Active Directory. It also brings along with it the ability to negotiate the SMB 3.0 protocol for much improved network throughput. Samba 4 also gives much better DFS support than previous versions, further improving the filesharing experience.
There are additional benefits to be had by combining the new Samba version with the new filesystem – Btrfs. Microsoft has introduced a feature called File Server Remote VSS Protocol (FSRVP) which allows file versioning at the server side, and clients can retrieve these older versions. Using SLES 12 as a file server will support FSRVP and behave properly from a client point of view.
To further reduce network bandwidth, Samba 4 also implements server side copy functionality – rather than copying the file to the client and back again, the client instructs the server to make the copy.
This is already a huge step forward in terms of speed, but SLES 12 further improved matters if you’re using Btrfs as the underlying filesystem. It exploits the copy on write functionality to avoid actually copying the file, and only modifies the extents that are changed, leading to significantly reduced copy times for large files.
Conclusion
SLES 12 has been in the works for a long time, but it looks like SUSE have made it worth the wait! There are so many new features in there that it’s hard to get to the bottom of them all. I would definitely recommend getting your hands on the public beta when it becomes available, and there’s plenty of new training material in the works to support the release, including the upcoming First Class course before it actually launches.
As SUSE always say: Have a lot of fun!