SUSE Insider

In This Issue

• SUSE Linux Enterprise 12 Service Pack Migration
• Automated Deployment of a Highly Available OpenStack Cloud
• SUSE Spotlight on SUSE Software Certification Programs: An Interview with Steven Canova, Director of ISV Relations
• Certification Update

SUSE Linux Enterprise 12 Service Pack Migration

Introduction

SUSE releases new service packs for the SUSE Linux Enterprise family at regular intervals. To make it easy for customers to migrate to a new service-pack and minimize downtime, SUSE has made it possible to migrate online while the system is running. In the past, SUSE provided YaST2 wagon for this task, which led the administrator through the process. However, because YaST2 is a GUI tool, there was no real supported command line interface for this task. This was a problem if you needed to migrate a lot of machines. Also, YaST2 wagon could only migrate from one service pack to the next one; it was not possible to skip a service pack.

As a result, SUSE took the opportunity in SUSE Linux Enterprise 12 to introduce a new tool with the following requirements:

• Intuitive graphical interface
• Simple command line interface
• System always in a defined state until the first RPM is updated
• Cancelling is possible until the first RPM is updated
• Simple recovery, if there’s an error
• "Rollback" via system tools; no backup/restore needed
• Minimal chance that an error occurs
• Use of all active repositories
• The ability to skip a service pack

The outcomes are a new YaST2 module and a new option for Zypper:

• YaST2 migration
• Zypper migration

To migrate to a new service pack with these tools, all installed SUSE products must be registered against SUSE Customer Center (SCC) or a local proxy (that is, the System Management Tool or SMT). If for some reason this is not possible, you can still perform the migration manually. However, this requires a little more work than just calling "Zypper migration."

In cases where there are special needs or something is going wrong, SUSE offers standard tools, including the following:

• YaST2: If you like to work with a graphical front end, YaST2 is your tool of choice. The YaST2 control center lists all installed YaST2 modules, and you can start the one you need.
• Zypper is the SUSE tool for the command line. In addition to installing and de-installing RPMs, it is also used for managing repositories and more.
• SUSEConnect is the successor to SUSE Register. It handles communication with the SCC or SMT. With this tool, you can manage the registration of your system from the command line.
• A very helpful option for registration is "SUSEConnect--list-extensions." This command lists all available SUSE extensions and Modules and tells you how you can register and enable them.
• Another frequently used option is "SUSEConnect--status," which lists the status of all installed products. At a minimum, "SUSEConnect--de-register" will remove all registrations of the installed products on SCC, and "SUSEConnect--rollback" will try to fix a mismatch between what is installed and what SCC thinks is installed. The latter command is especially important if a system administrator plans to go back from one service pack level to an older one.
• Snapper is the SUSE command line tool for managing snapshots. If you have problems with a new service pack and want to revert it, you can use "snapper rollback" to go back to an older system snapshot, from before the migration was started.

Migration Workflow

The workflow for an online migration is always the same, independent of whether it is accomplished by using YaSt2, Zypper, or manual steps.

On the left side of the graphic, you can see the "Host," the machine to be upgraded from SUSE Linux Enterprise Server 12 to SUSE Linux Enterprise Server 12 Service Pack 2 (SP2). On the right side, you have the registration server, either SCC or SMT. Additionally, you have the storage for the RPMs for SUSE Linux Enterprise Server 12 SP2. This could be “updates.suse.com” or a local SMT proxy.

In the beginning, the system tells SCC/SMT which products are installed. The registration server responds with several migration targets. The example shown in the graphic displays the answer: SUSE Linux Enterprise Server 12 SP1 or SUSE Linux Enterprise Server 12 SP2. The administrator then chooses where to migrate and makes this choice known to the SCC/SMT. This is the first time that data will be changed. In this case, SCC/SMT will invalidate the authentication tokens for the current installed products and generate new ones for the products to be installed. The URLs of the new repositories and the authentication tokens are sent back to the host. If the migration is aborted at this point, this process needs to be reverted. It is important that this happens not only on the local host, but also on SCC/SMT; otherwise, the next Zypper call will go back to the new repositories. In a normal case, the SUSE tools will take care of this. If this fails, for whatever reason, "SUSEConnect--rollback" will fix it.

Now the client has the new repositories for the new service pack and can start downloading and updating the system. At this point, it is no longer possible to abort the migration, because the system would then be in a broken state. Only a rollback from the bootloader or a restore will help.

Migration Target

A migration target defines a set of products to which the system can be migrated. It contains a set of products and extensions with a version number, which shows they are compatible. It could be that multiple migration targets are possible. Such a situation would look like this:

• SLES12 SP1 + SES2
• SLES12 SP1 + SES3
• SLES12 SP2 + SES4
• SLES12 SP3 + ...

In addition, migration targets are dynamic and can change every time SUSE releases a new version of a product or when an older version is scheduled to go out of support. What’s more, the content depends on the installed extensions. If there is no newer version of an extension at the time, it could be that no migration target is shown, even if there are new versions for the base product.

Because there could be multiple migration targets and because of the version numbers in the example, you can see another new feature: skipping service packs. With the new stack, you will be able to perform an online migration directly—for example, from SUSE Linux Enterprise Server 12 to SUSE Linux Enterprise Server 12 SP2, by skipping SUSE Linux Enterprise Server 12 SP1.

Prerequisites

SUSE Linux Enterprise 12 comes with a useful new feature: system snapshots and rollback. While this has advantages in error recovery, there is one drawback: it needs space. During migration, two snapshots will be created: one at the beginning (so that you can revert a migration to a new service pack if something is not working), and one directly after the migration finishes (so that you can revert later changes to a known working state). Consequently, you should ensure that you have enough free disk space for these snapshots. Due to the fact that with a Service Pack upgrade nearly all packages will be updated, the size of a snapshot can grow to the size of the installed system.

In the beginning, the system tells SCC/SMT which products are installed. The registration server responds with several migration targets. The example shown in the graphic displays the answer: SUSE Linux Enterprise Server 12 SP1 or SUSE Linux Enterprise Server 12 SP2. The administrator then chooses where to migrate and makes this choice known to the SCC/SMT. This is the first time that data will be changed. In this case, SCC/SMT will invalidate the authentication tokens for the current installed products and generate new ones for the products to be installed. The URLs of the new repositories and the authentication tokens are sent back to the host. If the migration is aborted at this point, this process needs to be reverted. It is important that this happens not only on the local host, but also on SCC/SMT; otherwise, the next Zypper call will go back to the new repositories. In a normal case, the SUSE tools will take care of this. If this fails, for whatever reason, "SUSEConnect--rollback" will fix it.

Additionally, you should have enough free space so that the tools can download all new RPMs first before applying them. This has the advantage that, if the connection breaks, the system does not end in a broken, unbootable state. And, of course, additional disk space is needed for the usual growth of RPMs because of new features.

After checking the free disk space, ensure that all installed products are upgradable. This is done with the tools for SUSE products. (This article doesn’t cover third-party products or software.)

Finally, don't forget a backup. If the update of the bootloader fails, even a system snapshot will not help.

Third-party Repositories

Until SUSE Linux Enterprise Server 11, all additional repositories were disabled during an online migration. While this ensures that the base operating system isn’t broken during the migration, it also prevents third-party software from being upgraded. In the worst case, this could be the reason that third-party software might be de-installed during migration. Because the system doesn't know what the new URLs are for third-party repositories, the administrator must adjust the URLs for the repositories.

If the migration is done with YaST2, this can be done with the GUI during the migration process. If Zypper or the command line is used, the administrator must do this up front. In this case, the administrator is also responsible for reverting these changes if he or she aborts the migration.

While the system knows that the migration targets are compatible, it doesn’t know what the customer has installed in addition. For this reason, it is possible that the package solver could notify the administrator at the end that a migration is not possible due to dependency conflicts. In this case, the dependency conflicts need to be solved manually, most likely by updating installed third-party software, adjusting the URLs of repositories to a newer version, or both.

Migration with YaST2

The YaST2 module for service pack migration was published only after the release of SUSE Linux Enterprise 12, so you need to install it first, using "zypper in yast2-migration." Afterwards, the tool can be started by calling "yast2 migration." The first screen shows the migration targets; you need to select one here. If there is no migration target, either all products are already updated to the latest version or the update for one of the installed products is not yet released.

After selecting a migration target, you will get a "Migration Summary" overview. This will tell you exactly which product is changed to which version. For all Modules, there will be a "stays unchanged." This is correct because Modules are on a different lifecycle than SUSE Linux Enterprise Server 12 and will not be updated in the form of service packs.

Selecting the "Manually Adjust the Repositories for Migration" checkbox will allow you to enable/disable repositories and adjust the URL of third-party repositories.

After adding the new repositories for the new product versions and removing the old ones, YaST2 will ask if the update should happen with all of the already-released updates included or only the "GA" version. Normally, there is no reason not to use all updates for migration; this will save a lot of time and bandwidth.

At the end, you will get a "Migration Proposal." If the old installation source is still enabled, you will get a red warning to disable it. In this case, you will most likely also see a lot of package conflicts. Disabling the old installation source will, in most cases, resolve this conflict.

Afterwards, there is nothing else to do; just start the update and reboot the machine to activate the new kernel.

Migration with Zypper

If you migrate using the command line interface, install the Zypper plugin first, using the "zypper in zypper-migration-plugin."

Calling "zypper migration--no-recommends" will start the migration process on the command line. If you want to do this fully automatically, the "--non-interactive" option (or, in short, "-n") can be added; Zypper will use the defaults and continue, as long as no unresolvable conflicts occur.

The workflow will be the same as for the YaST2 module, except that you cannot modify repositories during the workflow. Repositories must be adjusted beforehand.

SMT

Doing the migration against SMT requires SMT to be configured to use SCC, not NCC, and at least the following minimal versions:

• SUSE Linux Enterprise Server 11: smt >= 2.0.16
• SUSE Linux Enterprise Server 12: smt >= 3.0.8

Ensure that your SMT server really runs the latest update; otherwise, it can cause errors during the migration process.

In addition, the clients need to be registered against the SMT server; there is no difference here between "yast2 migration" and "zypper migration."

Common Mistakes

The most common reason a migration fails is that the installed products are either not all registered or not in sync with the SCC. All installed products need to be registered, and all removed products need to be de-registered on the SCC. If installed products are not registered, ensure that you do that first. Another good way to bring the installed products in sync with SCC is to call "SUSEConnect--rollback." While originally implemented for the case of a system rollback, this command is also able to fix most common "out of sync" issues.

Migration with Plain Zypper

If, for some reason, you can’t use "yast2 migration" or "zypper migration," you can migrate with the standard system tool. While the old SUSE Linux Enterprise 12 repositories are still active, update the stack. This can be done using "zypper patch--updatestack-only." You must perform this step with the old installation and update the repositories—after the switch to the new service pack repositories, it is too late.

If the system is registered, it needs to be de-registered at first, using "SUSEConnect--de-register." Afterwards, you must remove the old installation sources and repositories and adjust the third-party repositories.

Next, add the new installation sources. These can be local or network sources (add them with "zypper addrepo <repository>"), or they can come via SCC or SMT. In this case, you need to register the new version even if it is not yet installed. The command for SUSE Linux Enterprise Server 12 SP1 on x86-64 is "SUSEConnect -p SLES/12.1/x86_64 <options>".

To finalize the migration, only two Zypper calls are needed: "zypper ref -f -s," which will update all services and repositories, and "zypper dup--no-allow-vendor-change--no-recommends." Here, the last two options are important: "--no-allow-vendor-change" ensures that third-party RPMs will not overwrite RPMs from the base system, and "--no-recommends" ensures that packages deselected during initial installation will not be added again.

Rollback to a Snapshot

The main advantage of creating snapshots and rolling back a service pack is that they change the system back to the same starting state it was in before the migration. However, this leads to a problem: the SCC and SMT don't know that the migration was reverted, and the system does not know that it has already been migrated in the past. For this reason, the next Zypper refresh will update the repositories again and use the new service pack packages. This means the migration to the new service pack is performed again.

To prevent this, you need to tell SCC and SMT that you made a rollback. If the rollback was done with btrfs and Snapper, this is not a problem. A special marker will be set, and at the first boot SCC or SMT is informed that this machine made a rollback, that the new repositories must be invalidated, and that access to the old repositories must be granted again.

If this fails, or if the system was reverted in another way (by using LVM snapshots, with KVM or VMWare tools, or restoring a backup), you need to tell SCC and SMT that a service pack rollback had been made. The command for this is "SUSEConnect--rollback."

The migration between service packs is a complex task, especially if you want to keep track of your use of SUSE subscriptions. Make sure that you use the right repositories to keep your systems up to date after the migration and make sure of the compatibility of installed products after the migration.

After reading this article, you should be familiar with the migration process between service packs of SUSE Linux Enterprise Server 12, know what tools SUSE provides, and be able to choose the tools that are the best fit for you.

Automated Deployment of a Highly Available OpenStack Cloud

By: Abel Navarro and Vincent Untz

Abel is a Software Engineer working with the SUSE Cloud team. He is helping with the HA development for the SUSE OpenStack Cloud product. Abel has more than 10 years experience as software engineer for networking solutions as well as over 3 years experience developing SDN products.

Vincent Untz is an active Free Software enthusiast, with over ten years experience involved in high-profile projects such as OpenStack, openSUSE and GNOME. His interests range from technical topics to organizational areas of the communities. He has held several leadership positions throughout the years: GNOME Foundation director (2006-2010) and Chairman (2009-2010), GNOME Release Manager (2008-2011), as well as Chairman of the openSUSE Board (2012-2014). Vincent is currently working at SUSE as senior project manager for SUSE OpenStack Cloud.

Why automate deployment of OpenStack?

OpenStack has become the de facto standard for Infrastructure as a Service (IaaS) in recent years. Plenty of players have joined the project and contributed to create a plethora of components that conform to the OpenStack ecosystem. While this has provided great flexibility, allowing multiple configurations and customizations comes at the cost of increased complexity in integrating all of the components. With over 50 OpenStack projects currently active [1], it is a time-consuming task to keep an OpenStack deployment fully operative and up to date.

Vanilla OpenStack clouds are clouds built directly from the OpenStack source code. Although it is possible to run a vanilla cloud, this usually requires a team of skilled engineers who spend months dealing with problems integrating and configuring the components—and these engineers must also provide support if bugs are found. Moreover, upgrading those clouds can be a real challenge; many developers just prefer to start from scratch on every OpenStack version. Unless a tailored deployment is required, it is wiser not to spend time on problems that have already been solved with solutions that are proven to work.

SUSE OpenStack Cloud simplifies deploying and running OpenStack clouds in a reliable and reproducible manner. With its deployment framework, Crowbar, a cloud operator can discover new hardware that has no operating system yet, install the operating system on those servers (often called nodes), and then deploy OpenStack services to them—all with a user friendly web interface. The discovered nodes simply appear in the list of new nodes after they have been turned on and have booted from the network; deploying the services is only a matter of dragging and dropping the nodes to a role in the web interface. The complexity of the automated configuration is hidden behind the simple interface. The automation also ensures that the configuration is coherent and consistent.

Of course, automating the deployment does not solve everything, and it is critical that developers have a basic understanding and knowledge of OpenStack. The key is that the automation enables the cloud operator to focus on more important areas.

Why High Availability (HA) for OpenStack?

When a cloud goes into production, users will quickly start relying on it, and any disruption from downtime becomes a serious problem. Unfortunately, OpenStack does not offer any native high availability for most of its services. Some services do offer some form of high availability, though, such as the Distributed Virtual Router (DVR) feature in the network service (Neutron) or distributed storage with Ceph. But by default, the control plane of the services might still run on single nodes, leading to Single Point of Failure (SPoF) architectures. Several of those services are critical for operating the cloud, such as Keystone (authentication service), Nova (compute service), or Neutron (network service). A failure in any of those services will take the cloud down, and it is unrealistic to provide a good service level agreement (SLA) with such a setup. For this very reason, the OpenStack project provides a High Availability guide [2] that proposes an implementation leveraging the Pacemaker software, which is the standard solution for providing High Availability (HA).

By implementing HA in this way, services and nodes are continuously monitored. This makes it possible to promptly react and restart the services and to isolate them from failing nodes (a term referred to as fencing in HA jargon). Failed services are then automatically restarted on a different node. In some cases, services are run simultaneously on all nodes of the HA cluster (as clones), so there is no need to even move the service. Because of the architecture of OpenStack, nearly all critical services in OpenStack can run as clones.

This architecture also provides load balancing in front of the services that run clones simultaneously on all nodes of a cluster. The load balancing helps with HA by filtering out failed nodes and forwarding the requests to active nodes only. It also improves the performance of the cloud by increasing the number of requests per second that the services can serve. In small clouds, this might not be important, but the bigger the cloud is, the easier it is to find a bottleneck. For example, the Keystone authentication service is called for almost any transaction that the other services are involved in. By load balancing the services, it is also easy to scale up and adapt to increased demand, since this can be achieved by simply adding a new node to the cluster.

SUSE OpenStack Cloud implements this HA architecture; it has also supported Compute HA since the release of SUSE OpenStack Cloud 6. This is a feature that can automatically resurrect instances—which are Virtual Machines (VMs)—from failed compute nodes on working compute nodes. The term resurrection is used to differentiate from live migration.

In a live migration, the instance is moved to another node with almost no disruption in the service. This is because all of the states associated with it are also migrated.

In a resurrection, the instance might not be cleanly shut down, so it will be spawned again, with the option to re-use the ephemeral storage of the instance if shared storage is available for the compute nodes.

Compute HA does not perfectly fit the usual cloud model—where it should be assumed that any instance might disappear without any warning. However, customer feedback indicates that people want to run instances with a guarantee that it will be running and available as much as possible. This is generally useful when migrating old workflows that were not initially developed and architected for the cloud.

With all of the benefits from HA, it might be expected that everyone will deploy OpenStack in this way. However, because of the difficulty of properly setting up HA, this is not the case.

Automating deployment of High Availability for OpenStack

Configuring HA is not an easy task. In addition to configuring how to run the services in an HA cluster, you must also configure how the fencing operations are realized. And, the default setup of Pacemaker often needs to be tuned to work as desired. In addition to this general HA complexity is the complexity related to the size of OpenStack. When deploying HA for OpenStack, it is not unusual to end up with a setup of around 50 resources, each representing a service. And this is not the end of it! Because the services are interconnected, the complexity increases since additional constraints must be expressed to provide a fully working configuration, such as dependencies for the order to be used when starting services and rules governing where services are allowed to run. All of this can, of course, be configured manually, but this requires a lot of HA knowledge and is very tedious and error-prone.

Fortunately, all of this work happens behind the scenes on SUSE OpenStack Cloud. With the help of the Crowbar tool, the cloud operator can drag and drop nodes to form an HA cluster. Each cluster is formed with at least two nodes, although a minimum of three is highly recommended. The cloud operator can then assign OpenStack roles to clusters in the same easy drag-and-drop way as he would assign the roles to nodes. And that's it, really!

This might look too simple to be true but, as we have mentioned, the complexity is hidden. This is thanks to the SUSE OpenStack Cloud team, which has built on years of HA experience and OpenStack deployment experience to provide a solution that is proven to work.

References:
[1] https://governance.openstack.org/​reference/projects/
[2] http://docs.openstack.org/ha-guide/

SUSE Spotlight on SUSE Software Certification Programs: An Interview with Steven Canova, Director of ISV Relations

Let me provide a bit of context first. SUSE—through the ISV (independent software vendor) team—is committed to productively engaging with the ISV community. Our goal is to ensure that our customers have the software applications they need to run their business and that support is in place from ISVs so our customers can get the help they require.

With this goal in mind, SUSE offers two main software certification programs: the SUSE SolidDriver Program for certifying that drivers from hardware system and peripheral vendors are compatible with SUSE Linux Enterprise at the kernel level, and “Ready for SUSE Linux Enterprise” (or “Ready” for short), our user-space application certification program.

The SolidDriver Program provides tools, specifications, and processes for testing hardware device drivers to ensure that they are easy to deploy, compatible with SUSE Linux Enterprise at the kernel level, and supported by SUSE as well as the ISV. Once a driver is certified, if it is open source, the ISV can make it available to the upstream Linux kernel, and it can be included in SUSE Linux Enterprise Server. If the driver is proprietary, certification ensures that the SUSE support team will recognize it as working with SUSE Linux Enterprise.

The second program, Ready for SUSE Linux Enterprise, is for user-space application vendors and is a self-certification program. Unlike the SolidDriver Program, Ready for SUSE has no specific protocols for certifying applications on Linux. ISVs know best how their products should work on the operating systems they support, so we rely on them to perform the level of testing that gives them the satisfaction that their application functions and performs as it should. This is consistent with how application certification is performed with other Linux providers.

The program process works like this: once an ISV team decides to certify its products on SUSE Linux, the company joins the Partner Portal, uses our partner program, and engages with us for assistance and access to a SUSE Linux Enterprise subscription. Then they initiate their own test and quality assurance cycle until they are confident that their products work as they should on SUSE Linux. At that point, the ISV would declare, or “certify” that they offer commercial support for their products running on SUSE Linux. That means when a customer picks up the phone and calls the ISV, there’s someone ready and able to help them in the ISV’s support organization. At this point, the SUSE ISV team helps the ISV get a listing in the SUSE Partner Software Catalog, so that the product is visible to our customers and partner community. The listing in our catalog is an assurance to the customer that the ISV product is available and supported on SUSE Linux. This would also typically be reflected on the ISV’s website and be associated with the SUSE Ready logo.

SUSE’s certification programs are just one component of an enhanced global ISV program whose goal is to work more closely with the vendor community, providing them with more value and making it easier for them to make their products available on SUSE Linux. We also want to help vendors support other SUSE products: SUSE OpenStack Cloud, SUSE Enterprise Storage, and SUSE Manager.

As part of this enhanced effort, the SUSE ISV team has been enlarged, so we can now work with these ISV partners to better understand their situations, how they build software, and how we can help them improve their ROI. Specifically, we give assistance to ISVs and help them exploit capabilities in SUSE Linux Enterprise Server so they can bring more value to their applications. And, we help them with joint marketing and go-to-market initiatives to promote joint solutions in the marketplace, often in new areas. We also have improved our partnering infrastructure—one example is our partner subscription site—to make what they need more visible so they can work with us more easily and get access to the partner benefits that are available.

Both. We want to facilitate certification for vendors who want to support SUSE Linux and see the marketing opportunity that this represents for them. Many ISVs are in this group and come to us.

The SUSE ISV team also actively seeks relationships and certifications among all ISVs whose applications we believe have potential for our customers or that our customers tell us are important to them. We know that certain classes of applications, such as those that support data center infrastructure, are important to a lot of customers. We proactively reach out to those vendors. Many of them are big players in the business—the companies that also sell servers and physical infrastructure for data centers. I’m referring to IBM, HPE, Dell, and the other companies that are also our hardware Alliance partners. They’re also our largest and most customer-critical software vendors. We maintain both business-level and technical-level relationships with them. We keep them updated on what we are doing from business and product development standpoints. During their testing and QA process, we are there to offer assistance if needed.

Customers can ask ISVs for an application to be certified. We encourage them to do this by communicating their requests to their sales representatives or support contacts at SUSE. These individuals will kick off an internal process that leads to our lSV team contacting the ISV to initiate a discussion about certifying and jointly pursuing a market opportunity with SUSE.

Customer requests are important to us. Reacting to customer requests helps us fill in the gaps in our ISV ecosystem of products that our customers need. This is an important part of our customer commitment.

Customers want to run their data centers in a way that best supports their business. They want their applications on a stable, reliable, scalable, and manageable OS that offers a whole breadth of capabilities. SUSE Linux lives up to these expectations, so enterprises want their key applications supported on SUSE Linux Enterprise Server. We’re here to make sure that happens for them with the applications that best fit their needs. “Certification” is a key word for customers. It implies that the applications work on SUSE Linux and means that an ISV has pledged to provide support.

Certification Update

YES Certified Hardware

From February 1, 2016, to April 28, 2016, SUSE certified 436 hardware devices—369 network servers and 67 workstations.

Certifications during the three-month period here demonstrate the breadth of compatible hardware choices SUSE provides to customers through its partner ecosystem:

• Although just under third of the certified servers (101) were from Lenovo, 21 other companies received YES Certifications as well.
• Several less well-known vendors submitted devices during this period, including Unis Huashan Technologies, Inspur, H3C and Beijing New Cloud Oriental System Technology—from China; Quanta Computer—from Taiwan; Business IT AG—from Switzerland; and Positivo Informatica—from Brazil. Other companies with certified products were Atos, Cisco, Dell, Fujitsu, HP, Hewlett-Packard Enterprise, Hitachi Data Systems, Huawei, IBM, Intel, Microsoft and Unisys.
• This hardware was certified on a number of versions of SUSE Linux Enterprise operating systems.
  • For workstations, 45 were certified on SUSE Linux Enterprise Desktop 12 SP1, 4 on SUSE Linux Enterprise Server Desktop 12, 6 on SUSE Linux Server Desktop 11 SP4 and 12 on SUSE Linux Server Enterprise Desktop 11 SP3.
  • For servers, certifications on SUSE Linux Enterprise Server 12 SP1 (128) and SUSE Linux Enterprise Server 11 SP4 (126) were almost equal. The largest number of certifications, however, were on SUSE Linux Enterprise Server 12 (207). Yet SUSE Linux Enterprise Server 11 SP3 made an appearance—on 15 servers.

You can search all YES CERTIFIED Bulletins to see if the system(s) you are interested are compatible with SUSE operating systems at www.suse.com/yessearch/

SUSE Partner Software Certifications

The software listings in our SUSE Partner Software Catalog (PSC) are constantly being updated by partners as they release new SUSE support statements and add new product features. The catalog now contains more than 7,000 software product listings in the catalog now. You can see summary highlights for a product and then drill down to the level of detail you need for a specific product version with a specific SUSE version and hardware architecture. Our program, which ISVs work with to populate the catalog, is the Ready for SUSE Linux program at https://www.partnernetprogram.com/program/suse-ready/. If you have an ISV solution that you want to see advertised on SUSE Linux, please refer your ISV to our site. We are happy to work with them.

Some recent updates to the SUSE PSC are:

• Oracle Database 12c R1 (12.1.0.2.0). Now certified on SUSE Linux Enterprise 12 Service Pack 1 Oracle Database 12c delivers industry leading performance, scalability, security and reliability on a choice of clustered or single-servers running Windows, Linux, and UNIX. It provides comprehensive features to easily manage the most demanding transaction processing, business intelligence, and content management applications.
• Fujitsu Enabling Software Technology: Open Service Catalog Manager 2015-11 Open Service Catalog Manager is a free, open source software which is based on FUJITSU Software Systemwalker Service Catalog Manager. It provides a self-service platform for enterprises and service providers to deliver their software, infrastructure, or platform services to service consumers. It also has linkage plugins that seamlessly connect to each type of cloud as well as other features, including functions for calculating usage fees based on actual usage and for generating reports. By using Open Service Catalog Manager, users are able to raise the operational efficiency of their cloud environments and enhance the convenience of cloud services.
• Balabit: syslog-ng Premium Edition The syslog-ng Premium Edition log server tool allows system administrators and security experts to build a trusted, centralized logging infrastructure for reviewing and auditing the log messages of over 50 platforms. The syslog-ng solution incorporates the functions of clients, relays, and servers into a trusted, multi-platform logging infrastructure. It collects and classifies the log messages of operating systems and applications and transfers them to the high-performance log server in an encrypted and reliable channel where the messages can be processed further and stored in secure, encrypted files or databases. Supporting reliable transport protocols, message buffering, and client-side failover, syslog-ng minimizes the risk of message loss, thus suiting compliance requirements, such as PCI-DSS.
• Cendio AB: ThinLinc 4.5.0 ThinLinc provides several industry-leading technologies and innovations that improve performance, increase security and drive down the cost of delivering Linux and Windows-based applications at the same desktop. It is the only solution that integrates such a comprehensive set of features, enabling it to become a strategic part of your application delivery Infrastructure. ThinLinc is a fast and versatile remote desktop solution. It is based on open source software such as TigerVNC, SSH, and PulseAudio. The ThinLinc server software can be used to publish Linux/Unix desktops and applications to thin clients. The system also supports Windows Remote Desktop Services. ThinLinc supports redirection of sound, serial ports, disk drives, local printers, and Smart Card readers. Clients are available for a wide variety of platforms. When used with the VirtualGL software, ThinLinc can deliver high performance graphics with OpenGL applications, in a thin client environment.