How to put the SUSE Linux Enterprise Server Eval to the Test: Grand Prize Winning Essay

Editor’s Note:  We recently held an essay contest to gather insights from the most experienced power users of SUSE Linux Enterprise Server in the world.  We wanted to know what they would tell people who were brand-new to SLES, and just in the process of evaluating it, to make their experience easier. 

This entry was selected for the Grand Prize by a panel of premium support engineers.  

Judges’ Comments:

 It covers some ‘gotchas’, and will help people have a smoother experience evaluating SLES,  It contains specific advice such as being careful of which configuration files you modify.  It touches on some pretty common problems, such as possible conflicts when you both manually edit and use YaST to modify the configuration of a component.

By: Paul Borowicz

I installed in SLES 12 using VMware Workstation. This is a great way to try out a new OS, unfortunately, VMware “helpfully” made some assumptions about my installation. I was never prompted for customizations. I’m not sure how this really saves any time and I recommend avoiding it by creating the vm without specifying the OS.

If you’re coming from a non SuSE distribution, you might underestimate how deep the integration is between SLES and Yast. I found there are places you might be accustomed to editing files, where you can edit the file directly without making the change you desire. You need to make the changes in Yast, or look for the appropriate SuSE location to make the change.

For example, in Red Hat you simply edit resolv.conf to change DNS entries. In SLES you need to edit /etc/sysconfig/network/config to make the changes. This large file is read when the network starts and it seems to supersede the resolv.conf settings. Hey, guess what? You can edit sysconfig through Yast as well. There is a dedicated sysconfig module. It has built-in help for a lot of what you’re doing.

Yast is great, but it does get in the way of custom configurations and things you might be accustomed to scripting when building a standard server. It has gotten better about stomping on manual changes. It usually it backs up the necessary configuration files before it makes any changes. If you accidentally open a Yast module that manages something you have edited by hand, check for a backup file. It’s appended with an extension, but it should have the same name.

Another recommendation, from personal experience. SLES integrates many components in Yast very nicely. You can edit the firewall by hand, but each module has its own checkbox to open the firewall. You don’t need to open vnc, then open the firewall, when you can just check that box while you configuring vnc. The same is true for almost every network service.

If your system is going into a Windows environment, and you want to authenticate against an Active Directory Domain, SLES makes it easy. Actually it makes it too easy, too easy to pick the wrong thing! SLES 12 still contains the helpfully titled “Windows Domain Membership” module. Of course you want to click this. It makes it pretty easy to join an AD Domain. Don’t do it man, don’t do it.

The “Windows Domain Membership” module is depreciated. It uses winbind, which, for a whole heap of reasons, is not the best way to join a Domain. The best current convention is to use SSSD to join a domain. This is available via Yast, and still pretty simple. It’s under the “Authentication Client” module. The “authentication client” yast module is the correct way to join a domain with minimal regret. Hopefully in future releases, the depreciated winbind module will be removed.

If you plan to do multiple installs, or you want some control over the software versions you are installing, you will need to create your own repository. I like to grab all the rpm files from the installation media and put it into a local or network reachable directory. Once you’ve collected them all in one folder, you can run createrepo to turn that folder into a zypper repository. Just add an entry to /etc/zypp/repos.d and your repo will be in business. It can be local file, but I prefer to setup an http repo. That way other servers can use it and I can do a more minimal install with more packages quickly available.

Finally, if you’re going to get the most out of SLES, you should make yourself familiar with the OpenSUSE website. Not only does opensuse provide a great home/hobby build, they provide extensive repositories for packages you won’t find in the standard SLES repositories. The latest 42.1 build is more similar to SLES, and has long-term support.

For a long time, when people asked me for a Cent OS equivalent for SLES, I was forced to say there is none. OpenSUSE required rolling upgrades every six months in previous iterations. Now I can tell people to stick with the 42.1 branch of OpenSUSE to build a pretty nice test environment or get comfortable with SUSE on your own home equipment. This is something that fans of SUSE have been waiting for, for a long time. If you’re new to SuSE, congratulations. You don’t have to wait.

So, to recap. Get comfortable with Yast, it’s the best way to poke around SuSE, but don’t be afraid to get your hands dirty with straight config files. Just be sure you are editing the right one. Get comfortable with zypper as well. It’s the latest package management system, and they learned a lot from yum and apt-get.