openSUSE Leap 15 is here!

openSUSEopenSUSE Leap 15 is here! (download the iso) openSUSE has always been my favorite Linux distribution I’ve written extensively about the advantages that come from using zypper, the package manager that comes bundled into openSUSE and how to use it to install and update software on your system. Not only does openSUSE have the best package manager, they also have the best mascot. Geeko for the win!

I am really excited about  Leap 15, it is a major improvement over Leap 42, which is saying a lot since Leap 42 has been an absolutely phenomenal operating system. Leap 15 has some big shoes to fill here but I think it brings a lot to the table that should make it a worthy successor.

As far as open source desktop systems go I think openSUSE can give any of the other Linux contenders a run for their money. Linux desktop environments are in no short supply, and openSUSE is the only distribution I have used that works flawlessly whether you choose to use GNOME, KDE, Budgie, Cinnamon….the list goes on (sorry if I didn’t list your favorite). You can run any or all of these desktop environments on Leap 15 and each one feels as if it was made specifically for openSUSE.

One of the great strengths that openSUSE brings to the desktop is that it is great for both beginners and longtime Linux veterans. The graphical control center (YaST) makes Linux less intimidating to newcomers, and gives power users and administrators a great tool to fine tune their systems. There really isn’t anything else like it in the Linux ecosystem.  With YaST you can do everything from install software, create users and groups, set up a printer, create file shares, set up a web server, and a lot more. All from an easy to use graphical or terminal based interface that allows you to tweak nearly any aspect of your desktop or server.

For all that can be said for the openSUSE desktop, there are some great features built into this release for servers and that is what I would like to focus on.


In my mind letsencrypt is the best thing to happen to the world wide web since grumpy cat and it is now included in openSUSE Leap 15 directly from the official repositories. Letsencrypt is a free fully automated SSL certificate generation tool and signing authority sponsored by the Internet Security Research Group (ISRG).  Before letsencrypt, if you wanted an encrypted connection to your WordPress site (thus receiving that fancy green padlock in the address bar) you either had to pony up a couple hundred dollars to your hosting provider every now and then, or suffer through trust issues when your visitors received a warning from their browser explaining that your website was potentially malicious.

Having native support for letsencrypt in openSUSE is something that I’ve been looking forward to for a long time. I am grateful for all the work that has been put into this effort by Lukas Schauer (@lukas2511)and the rest of the developers who work on dehydrated.

I wrote a how-to blog for securing a website with letsencrypt here: I expect to be updating that post soon to include instructions for openSUSE Leap 15. Also, keep an eye out for Richard Brown to include a how-to on his blog 

Migrate to SLE

With the release of openSUSE Leap 15 you now have the ability to migrate your openSUSE systems to a fully supported SUSE Linux Enterprise (SLE) subscription. This is a huge advantage in the server market where you have to worry about things like long-term support, and hardware or software certifications. In order to accommodate this transition openSUSE Leap 15 and SLE 15 were built from common source material and share the underlying code base. Basically, if you are running Leap 15 you are running SLE 15.  “openSUSE Leap 15 brings plenty of community packages built on top of a core from SUSE Linux Enterprise (SLE) 15 sources, with the two major releases being built in parallel from the beginning for the first time.” (source) This is the first time that openSUSE and SUSE have shared the same core operating system and are fully interchangeable. This say’s a lot of good things for the long-term stability of openSUSE and signals a strong commitment to the community by SUSE.

To find out more about this feature I reached out to the openSUSE chairman Richard Brown (@sysrich on Twitter). Who, while busy getting prepared for the upcoming Leap 15 release, did confirm that there is”no need to redeploy a system” and that the migration path from openSUSE to SLE is fully supported.

If you want to learn a little more about the process of migrating an existing Leap 15 system to SLE 15 this document is a good place to start:


With Leap 15, openSUSE is moving away from its iptables based SuSEfirewall2 scripts to the widely used and powerful firewall management tool, firewalld. Firewalld has been around for awhile now is familiar to anyone who has been using Fedora, or CentOS 7, over the last few years. Firwalld uses the concept of zones to filter traffic to a Linux system and provides an intuitive command line interface (firewall-cmd) to create or modify rules in the running firewall configuration. As mentioned before YaST also provides a graphical interface to manage the firewall.

Having support for firewalld in Leap 15 will make it easier for administrators with training or experience using CentOS or Fedora to more easily transition onto openSUSE or SLE in the future.

Transactional Server Role

When you install Leap 15 you will be presented with the option to install the system with the transactional server role. “This system role features a new update system that applies updates atomically (as a single operation) and makes them easy to revert should that become necessary.” When you choose the transactional server role you will have a system that mounts the root file system as read-only, with only the /etc and /var filesystems being writable by users or system services.

The transactional server role is the product of the openSUSE Kubic project. Which is largely focused on developing a minimal system to host containers, without all the overhead that comes from traditional operating systems.

Lots of other new stuff too

Leap 15 comes with PHP 7, update-alternatives, and improvements to managing AppArmor profiles. This is a great update for openSUSE and I expect we will continue to see great work poor out of the project. For a complete list of features take a look at the official press release:

As always when experimenting with openSUSE, “Have a lot of fun…”

RPM package queries

This post is just a quick walk-through of some basic commands to help you find information about rpm packages. These commands will work for any rpm based distribution (Red Hat, Centos, Suse, Mageia) Debian based distributions like Ubuntu or Mint use dpkg instead of rpm and I’ll cover those in a different post.

Query the rpm database

You can query the rpm database to find a particular installed package using the -q option. With rpm -q you must also pass a package name. For example, to find out what version of the httpd server we have installed we can use rpm -q httpd

rpm -q httpd

List all installed packages

To get a quick list of every installed package on an rpm based Linux distribution you can use -qa. In this case you do not need to pass any specific package into the command. Often times you will use this to find a package when you are not sure of the exact name. For example, you might grep for “ruby” to find all the installed ruby libraries.

rpm -qa

Running rpm -qa | grep ruby will produce output similar to this on a Centos 7 server.

rpm -qa | grep ruby

Find associated files

Using rpm -ql and rpm -qc will help you to locate files associated with a particular package. This is a great tool to help you find your way around a newly installed application. For example, how could you find out that the configuration file for Apache can be found at “/etc/httpd/conf/httpd.conf”, without searching the interwebs?

rpm -qc <package name> will list all of the configuration files.

 rpm -qc httpd

Similarly running rpm -ql will give you a list not only of configuration files but also every file that was installed on your server with its location.

Identify vendors

In some cases, you may need more information about a package. Who is the vendor? When was it installed? etc… Getting this type of information with rpm packages is easy.

rpm -qi <package name>

rpm -qi httpd
Name        : httpd
Version     : 2.4.6
Release     : 45.el7.centos.4
Architecture: x86_64
Install Date: Mon 12 Jun 2017 09:37:04 PM UTC
Group       : System Environment/Daemons
Size        : 9823677
License     : ASL 2.0
Signature   : RSA/SHA256, Thu 13 Apr 2017 01:04:44 AM UTC, Key ID 24c6a8a7f4a80eb5
Source RPM  : httpd-2.4.6-45.el7.centos.4.src.rpm
Build Date  : Wed 12 Apr 2017 09:05:23 PM UTC
Build Host  :
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <>
Vendor      : CentOS
URL         :
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

Finding documentation

You can also quickly find where documentation for a package can be found on your system using rpm -qd

rpm -qd httpd

This documentation will include listing man pages that migt be available. As well as example configuration files. In this case you can see that “/usr/share/doc/httpd-2.4.6/httpd-vhosts.conf” is an example of a virtual host file…. Maybe something that would come in handy as a template for virtual hosts you might have to set up.

As you can see there is quite a lot of information that can be extracted from the rpm database. In my humble opinion, this is one of the big advanatages that rpm has over dpkg (though you can get this information from dpkg, it’s just not as straight forward), rpm makes it easy to query the database and quickly find the information you need.

All of this really only scratches the surface of what you can do as well. There are many ways to modify these commands to help you discover information about the packages you have installed on your system. I encourage you to read the full man page for rpm if you are interested in learning more in-depth capabilities for rpm packages.

OpenSUSE patch vs update

If you dig into the man pages for zypper, you will notice that zypper provides three distinct options for keeping your OpenSUSE system up-to-date; update (up), patch, and dist-upgrade (dup). If you aren’t familiar with zypper see my previous post managing packages with zypper for more information. In this post I will attempt to demonstrate the differences between each option and suggest when you may want to consider using each. In particular, I will try to explain the difference between a simple update and a patch, with emphasis on how to gather detailed information on particular patches.


According to the man page, using zypper update (or zypper up) will; “Update installed packages with newer versions, where possible.” As long as updating the package will not cause a change in vendor (see dist-upgrade), using  zypper up will update every installed package to the newest version that is available in the repositories that are enabled on your system. Zypper update is a safe and reliable way to update any OpenSUSE or SUSE Enterprise Linux system, without worrying about major version changes.
To see a list of all available updates use zypper lu

zypper lu
Loading repository data…
Reading installed packages…
S | Repository | Name | Current Version | Available Version | Arch
v | Main Update Repository | gimp | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | gimp-help-browser | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | gimp-lang | 2.8.18-1.4 | 2.8.18-2.3.1 | noarch
v | Main Update Repository | gimp-plugins-python | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | libgimp-2_0-0 | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64
v | Main Update Repository | libgimpui-2_0-0 | 2.8.18-1.4 | 2.8.18-2.3.1 | x86_64

For most users this is all you will probably ever need to know about keeping your OpenSUSE system updated.

If you are using OpenSUSE as your desktop OS you may notice that running “zypper up” will show more updates than you see through the GUI. This is because by default Yast Online Update (which is where the gui tools in gnome, and kde retrieve update information) only shows official software patches.


While patches in OpenSUSE are similar to updates in that they will install updated packages. Patches are meant for specific bug fixes and security fixes for software that comes packaged by OpenSUSE and is maintained in the Main Updates repository. A single patch might include several package updates to mitigate a specific security vulnerability or bug fix. In many cases installing patches will not fully update your system. A package with an updated version number that doesn’t match a “fix” for a bug or security flaw will not be included in a patch. Installing “Patches” rather than “Updates”, strictly speaking, is probably only necessary for production environments that can only handle minimal changes to installed packages, while still maintaining a secure system. However, if you want to ensure that you have a stable and undisturbed desktop experience, there is certainly nothing wrong with limiting your updates to patches.

One of the great things about working with patches is the vast amount of information that is available for them that can be accessed straight from the command line. For example, if we wanted to know which cve’s (Common Vulnerabilities and Exposures) are currently affecting our system we could find out by using the “list-patches (lp)” option with zypper like this.

zypper lp --cve

Issue | No. | Patch | Category | Severity | Interactive | Status | Summary
cve | CVE-2007-3126 | openSUSE-2017-462 | security | moderate | — | needed | Security update for gimp

This command gives us a lot of good information that can be useful for explaining the reasons that a patch is necessary. In this case, we see the cve number, the name of the patch (openSUSE-2017-462), its category (security), the severity (moderate), whether or not the patch is needed, and a quick summary (Security update for gimp).

We can take this a step further and pull down all the details of what packages will change if we patch this particular cve, by calling the info option with zypper and passing in the name of the patch we want to look at in this case “OpenSUSE-2017-462”

zypper info openSUSE-2017-462

You can also send this command more specifically (but with identical output) as.

zypper info --type patch openSUSE-2017-462

When I’m writing a script I would tend to use the more verbose method, just so that the next person looking at it (or me 6 months later) will have a better chance of understanding what I was doing. Either way you choose to run this command you will receive output similar to this:

Information for patch openSUSE-2017-462:
Repository : Main Update Repository
Name : openSUSE-2017-462
Version : 1
Arch : noarch
Vendor :
Status : needed
Category : security
Severity : moderate
Created On : Wed 12 Apr 2017 05:15:35 AM EDT
Interactive : —
Summary : Security update for gimp
Description :

This update for gimp fixes the following issues:

This security issue was fixed:

– CVE-2007-3126: Context-dependent attackers were able to cause a denial of service via an ICO file with an InfoHeader containing a Height of zero

These non-security issues were fixed:

– bsc#1025717: Prefer lcms2 over lcms1 if both are available
– bgo#593576: Preven crash in PDF Import filter when importing large image PDF or specifying high resolution
Provides : patch:openSUSE-2017-462 = 1
Conflicts : [36]
gimp.i586 < 2.8.18-2.3.1
gimp.src < 2.8.18-2.3.1
gimp-debuginfo.i586 < 2.8.18-2.3.1
gimp-debugsource.i586 < 2.8.18-2.3.1
gimp-devel.i586 < 2.8.18-2.3.1
gimp-devel-debuginfo.i586 < 2.8.18-2.3.1
gimp-help-browser.i586 < 2.8.18-2.3.1
gimp-help-browser-debuginfo.i586 < 2.8.18-2.3.1
gimp-lang.noarch < 2.8.18-2.3.1
gimp-plugin-aa.i586 < 2.8.18-2.3.1
gimp-plugin-aa-debuginfo.i586 < 2.8.18-2.3.1
gimp-plugins-python.i586 < 2.8.18-2.3.1
gimp-plugins-python-debuginfo.i586 < 2.8.18-2.3.1
libgimp-2_0-0.i586 < 2.8.18-2.3.1
libgimp-2_0-0-32bit.x86_64 < 2.8.18-2.3.1
libgimp-2_0-0-debuginfo.i586 < 2.8.18-2.3.1
libgimp-2_0-0-debuginfo-32bit.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0.i586 < 2.8.18-2.3.1
libgimpui-2_0-0-32bit.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0-debuginfo.i586 < 2.8.18-2.3.1
libgimpui-2_0-0-debuginfo-32bit.x86_64 < 2.8.18-2.3.1
gimp.x86_64 < 2.8.18-2.3.1
gimp-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-debugsource.x86_64 < 2.8.18-2.3.1
gimp-devel.x86_64 < 2.8.18-2.3.1
gimp-devel-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-help-browser.x86_64 < 2.8.18-2.3.1
gimp-help-browser-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-plugin-aa.x86_64 < 2.8.18-2.3.1
gimp-plugin-aa-debuginfo.x86_64 < 2.8.18-2.3.1
gimp-plugins-python.x86_64 < 2.8.18-2.3.1
gimp-plugins-python-debuginfo.x86_64 < 2.8.18-2.3.1
libgimp-2_0-0.x86_64 < 2.8.18-2.3.1
libgimp-2_0-0-debuginfo.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0.x86_64 < 2.8.18-2.3.1
libgimpui-2_0-0-debuginfo.x86_64 < 2.8.18-2.3.1

As you can see this particular command string gives us plenty of details about the patch. Everything from basic information about the repository it will be coming from, to the date it was implemented, and a more full description including how the vulnerability may affect you. We can see both the security issues and non-security issues that are fixed. One of the potential points of confusion in the output comes in the last section “Conflicts :”. The word “Conflicts” might seem to suggest that some of the currently installed packages conflict with updates that are needed to patch the vulnerability. This is not the way you should understand conflicts in this context. From the zypper man pages:”A released patch conflicts with the affected/vulnerable versions of a collection of packages. As long as any of these affected/vulnerable versions are installed, the conflict triggers and the patch is classified as needed, optional or as unwanted if the patch is locked.” In proper context the conflict is a trigger to let us and the system know that an updated package is available to fix the vulnerability. So, in fact the conflict section can be read as a list of packages that are going to be updated, in order to remove the conflict.

To install all available patches you can simply run

sudo zypper patch

or to install patches to resolve a specific cve

sudo zypper install patch:openSUSE-2017-462

You can also list all patches that are categorized as “security” fixes.

zypper lp --category security

There are other ways to find patches that are available by listing bugzilla reports and severity, but I will let you find those on your own after you do a little more reading, and have become familiar with the commands listed here.

Distribution Upgrade (dup)

A distribution upgrade, performed by running:  sudo zypper dup , will upgrade (or downgrade) all installed packages to the latest version listed in every enabled repository, and as such, it should be used with caution. The upgrade operation will be performed regardless of vendor or repository and is often used when you want to replace an official package with one from a 3rd party repository, such as packman.

On a production system or system that needs to be kept in a stable state you will not want to use the dist-upgrade option except in certain situations. Most likely one of these:

  1. Upgrading from one OpenSUSE stable release to another i.e. (Leap 42.1 to Leap 42.2)
  2. Switching packages from one vender repo to another i.e. (OpenSUSE to packman)
  3. You are using Tumbleweed and want to keep your system up-to-date.
    1. Ostensibly you could still use zypper up
    2. I have found some documentation that would suggest using zypper dup with special switches whenever you update under Tumbelweed ( sudo zypper dup --no-allow-vendor-change )

I very rarely use the dist-upgrade option on my own systems, though I hear it is more common with the rolling release (Tumbleweed).

I would highly recommend spending some time reading the zypper man pages if you are planning to do any serious work with zypper. As I’ve said before zypper is a great (probably the best) package manager that is available in any Linux distribution. It is a powerful tool that makes managing packages easier and faster than anything else that I’ve worked with.