SUSE Insider Newsletter

The SUSE Insider is a quarterly posting with the latest tips and tricks, product advancements and industry insights only available to SUSE customer subscribers. If there is a specific topic you would like to have covered, please email

SUSE logo

SUSECon 2015 News—Schedule Your Sessions Now

The Session Scheduler for SUSECon2015—in Amsterdam on November 2-6—is now available. To make sure you can get your top choices, schedule the sessions you want to attend now. From this page you can register for the conference and access the Sessions Catalog to select the sessions you want. The Session Scheduler is available from the Sessions Catalog.

NOTE: Register now. The early bird special pricing for the conference ends September 20.

Alex Bergmann

By: Markus Feilner and Alexander Bergmann

Securing Your Systems: Hardening and Tweaking SUSE Linux Enterprise Server 12


  • Markus Feilner is a Linux specialist from Regensburg, Germany. He has worked with Linux as an author, trainer, consultant and journalist since 1994. The Conch diplomat, Minister of the Universal Life Church, and Jedi Knight today heads the documentation team at SUSE in Nuremberg, Germany.
  • Alexander Bergmann is a member of the SUSE Security team, taking care of software vulnerabilities and working on various parts of SUSE products and openSUSE. Following the Linux development since the late 1990s, he has collected and keeps up with a broad set of interests. He holds a Master's degree in Security and Forensic Computing from Dublin City University, Ireland.

The basic philosophy behind system hardening is quite simple: reducing a system’s attack surface. That's where the old Linux and UNIX dogma "Keep it simple" (KIS!) plays a crucial role: an administrator can reduce dangers to his or her system by simply installing less—only the absolutely necessary software—and uninstalling all redundant and superfluous packages. Apart from that, starting only the services that are really needed and controlling their ports and connections is a must. But the admin also has to prepare for a catastrophe and estimate the impact of a possible security breach and assess an aftermath.


The idea behind KIS! is obvious. If there are fewer packages installed, a critical vulnerability affecting the system is less probable. Needless to say, this is also true for special software features that should be disabled when they are not needed. Sometimes the default configuration offers a broad set of functionality with the aim to be most compatible—thereby opening doors or even backdoors for hackers. Reducing the attack surface always proves to be a balance between security and functionality.

A good starting point for hardening your systems is the SUSE® Linux Enterprise Server Security and Hardening Guide In its 75 pages you can find advice for making decisions and guidance on all security-related areas. This guide, however, does not yet cover the following tips and tricks to tweak the systems security, but they will be in future versions.

Hide and Seek

It has proven to be good practice to hide information that a possible attacker could use to compromise a system even further than he or she already has. A regular chroot process, for example, is still able to view the complete process list, which makes it possible for an attacker to gain inside information on running services, making them potential new targets for the next attack.

Next comes hidepid. This feature is an easy way to raise the bar of the proc filesystem. With hidepid only root and specially allowed non-root users or processes can view the process list outside their user id. Other (untrusted) users and processes will only see their own processes.

Switching on hidepid is a simple task. You can test it by simply remounting the /proc filesystem with the following option:

#> mount -o remount,hidepid=2 /proc

If you want to make this option permanent, even after a reboot, add the following line to /etc/fstab.

"none /proc proc hidepid=2 0 0"

A full description of available options can be found inside the Documentation/filesystems/proc.txt file from the kernel-source package.

Two Factor Authentication

A possible way for hardening remote access is two factor authentication.

The openssh version that is shipped with SUSE Linux Enterprise Server 12 allows public key authentication in combination with a regular user password, thereby making it hard for an attacker to test passwords for an account because the password prompt is shown only after the public key authentication has been accepted.

Consequently, even if someone got hold of your server password, that person would still be unable to log in. All that is needed is the following line inside /etc/ssh/sshd_config:

The cloud service provider side has been taking off like crazy. SUSE has a mature cloud service provider program with more than 40 cloud service partners around the world. Some of them are global providers; others are regional providers. Some are general purpose in scope, and some are very focused on a particular approach such as infrastructure as a service. As a result of all of this, our ecosystem of partners is expanding continuously.

"AuthenticationMethods publickey,keyboard-interactive"

More details on the AuthenticationMethods option can be found inside the sshd_config(5) manual page.

New Toolbox

Hardening and securing sometimes touch areas where users rarely would expect it, such as using the right set of tools. Most system administrators and Linux engineers are using the traditional UNIX standard tools to check the systems network state. This includes tools such as ifconfig, route, arp and netstat as part of the net-tools package.

While this package is still maintained and receives security updates and bug fixes, most of the tools are deprecated by the iproute2 utils collection.

Figure 2: List of old and new tools*

Program Obsoleted by
arp ip neigh
ifconfig ip addr
ipmaddr ip maddr
Iptunnel ip tunnel
route ip route
nameif ifrename
mii-tool ethtool

*Linux Foundation.

So why is this important? The problem with the traditional command line tools is that they do not show all network information that is available. This is simply because the development of the Linux kernel network stack overran the capabilities of those tools, and it was easier to start a new tool set instead of updating the old one.

A simple example is the source-based routing capabilities of the kernel. It is possible to define not only routing entries for network and host targets, but also rules, depending on the source address. This can be handy especially on virtualization hosts with many guest machines. In this case the good old “route” tool is simply not smart enough to show those entries, because it cannot access the needed information. This led to iproute2 and its variety of tools such as ip (Figure 2).

Although choosing the right tool is not really part of hardening a system, it is part of understanding the system’s behavior. The network stack is a crucial layer of the system security and, therefore, the capability to extract as much relevant information as possible might become a security issue.

Final Remarks

Transparency and knowledge are the crucial factors for hardening a system, also on an organizational layer. Knowing which services are running where and which update needs to be installed immediately on which system gives you a huge advantage, enabling you to react fast to newly disclosed vulnerabilities.

Don Vasburg

By: Don Vosburg

SUSE Manager Troubleshooting and Tech Tips


Don Vosburg has been a Sales Engineer for SUSE for more than 11 years. Based in Indianapolis, IN, USA, he speaks often on the topic of SUSE Manager.

SUSE Manager can be a great tool for managing Linux in your organization. Let’s take a look at ways to troubleshoot and some important tips that will help you make the most of your installation.

Most SUSE Manager administrators experiencing trouble wrestle with three important functions: channel syncing with Customer Center, the centralized scheduler on the SUSE Manager server and client system registration/communication.

Understand the Channel Sync Process

  1. Validate rpm metadata from the repository URL.
  2. Compare the upstream content to existing rpm’s, and download the missing rpm’s
  3. Inject the new rpm metadata into the database.
  4. Validate the patch metadata from the repository URL.
  5. Compare the upstream content to existing patches, and download the missing patches.
  6. Inject the new patch metadata into the database.
  7. Build new channel metadata on the server for subscribed clients to consume

Until this process is completed for a channel, your managed clients will not be able to properly use them. For example, if a sync is still in progress, you might find that a package appears in the web interface but does not seem to be available on your client—even if it is registered to use that channel. A quick way to check is on the summary of the channel in the web UI.

You can see if any sync processes are running by searching the processes as follows:

ps aux | grep repo-sync

Then follow the log file for that channel to see its progress:

tailf /var/log/rhn/reposync/channelname.log

Internet speed is helpful, but is not the only variable. Much metadata has to be processed, requiring multiple database operations that take time to complete.

You can temporarily force the channel to use pre-downloaded yum repos from the Subscription Management Tool (SMT) or other locations if needed.

spacewalk-repo-sync -c res6-x86_64 -u file:///location/of/smtrepo

Refer to the documentation on how to perform broader offline synchronizations. Expect errors in initial channel sync—NCC/SCC issues and metadata change might occur, especially when the task takes hours to complete, as might be the case.


“No more mirrors to try” 

“Errata skipped because of missing package”

Schedule a sync again until everything is clean. Be patient, and drink coffee as needed.

Important SUSE Manager File Locations


Log files from many SUSE Manager operations


Where the client repository information is stored


Many important settings for server operation


Web server data for bootstrap, bootstrap repositories, GPG keys


Where your downloaded/synched rpm files are located

There are MANY other files on the SUSE Manager system—but do not change them unless you are SURE.

The SUSE Manager Taskomatic Scheduler

The file /etc/rhn/rhn.conf has the option to add memory to the taskomatic daemon. The 1GB default allocation is an absolute minimum. If you are using repositories for Red Hat-based systems, they will grow to be very large and overrun the taskomatic daemon if you do not reserve 3-4 GB or more. You can start/stop the taskomatic service independently of the rest of the SUSE Manager services by using the service command as follows:

service taskomatic stop/start/restart/status

Then add this to the bottom of the /etc/rhn/rhn.conf file:

# Set max taskomatic mem


Restart the taskomatic service, and the memory will now be there for the scheduler.

The scheduler is responsible for launching:

  • Administrative scheduled tasks—listed in the web interface under Admin, Task Schedules
  • Channel synchronization—including building client repository metadata
  • Scheduling all client tasks—package actions, configuration file actions, profile updates

If something is not occurring when it should, chances are taskomatic is having issues. Make sure the service is running, then check the log:


Client Registration

In order for clients to properly register with SUSE Manager, keep in mind that these things must be in place. The errors you might encounter during registration can most often be avoided by making sure you have the following:

  • Properly synced channels—including SUSE Manager Tools
  • Activation keys that point to the proper parent and child channels
  • Availability of SUMA client software
    • Pre-installed on the client
    • Available to be installed from a bootstrap repository
  • Dependency resolution ASSUMES base media access at the time of registration
  • Proper bootstrap script
  • Bootstrap repository for SUSE distros can be built with

If the bootstrap script does not finish, review the client registration requirements above.

Uninstalled packages warnings usually mean you do not have either a populated bootstrap repository and/or access to base media.

Make sure all relevant GPG keys are referenced in the bootstrap script for Red Hat-based distributions in comma-delimited form and copied to /srv/www/htdocs/pub. This is not needed for SUSE clients, since the GPG keys are installed by default with rpm’s. If the system registers, but you see no base channel, ensure that your bootstrap script/activation key matches the distribution and architecture of your client system.

Best Practice Tips

  • Update your SUMA server(s) regularly—running ‘zypper up’ from the server command line. Many issues are resolved by the updates, so check often.
  • Do not cheat on memory allocation; give it more than the minimum recommendations to ensure better performance.
  • Attach disk space to /var/spacewalk; since rpm downloads are stored there, it will expand to be quite large. This is especially true as you expand the number of distributions and architectures that you manage.
  • Choose your client contact method carefully:
    • Pull: rhnsd or osad
    • Push via ssh—preferred for large environment, single key exchange
  • Stagger scheduled events that might overload taskomatic:
    • Action chains that are long
    • Remote commands—minimize length
  • Schedule your channel syncs and system actions with minimum overlap.

Resources and Links

Troubleshooting chapter – Installation manual

SUSE Manager Documentation

SUSE Manager Public Wiki

To learn more, attend SUSE Manager sessions at SUSECon 2015 in Amsterdam, November 2-6.

Richard Brown

By: Richard Brown

SUSE Spotlight: SUSE and openSUSE—A Conversation with Richard Brown, SUSE QA Engineer and Chairman, openSUSE Project


Richard Brown is from England but currently lives in Nuremberg in Germany, and is employed as a QA Engineer by SUSE. Involved in openSUSE and SUSE since 2003, Richard has contributed to various aspects of the project, including supporting users on IRC, testing/bug reporting, packaging, marketing, ambassadors and artwork, before becoming Chairman of the Project in 2014.

What is openSUSE and what is the relationship between openSUSE and SUSE?

openSUSE is an independent open source project. We’re a separate organization, with our own governance organization, but we are primarily sponsored by SUSE. SUSE contributes extensive financial as well as logistical support. Most of the hardware infrastructure is hosted by SUSE. And many code contributions come from SUSE employees acting as volunteers.

This relationship is collaborative and unique. With Fedora and Red Hat, or with Ubuntu and Canonical, the corporate backer has significant levels of control over the activities of their project—whereas SUSE definitely embraces the true open source model. SUSE doesn’t directly control what we develop. And the community is always free to embrace, extend or adapt what SUSE volunteers contribute.

openSUSE functions on pure, open source, meritocratic principles—with self-organized teams around whatever contributors are doing. There’s no hierarchy. The only formal governance body is the board, which has five members plus the chairman. The chairman, who is appointed by SUSE, is the only officially imposed SUSE employee on the project. The rest of the board is elected by a group of people recognized as long-term contributors. However, no organization can employ more than half the board members, not even SUSE.

The board’s purpose is to act as a central point of contact, a conflict resolution body and a decision maker of last resort. For example, often for significant technical changes, some contributors want to take one action and other contributors a different action. The role of the board is to hash things out and come up with a resolution. The board doesn’t take a leadership role in telling people what to do.

What is your role as the openSUSE chairman?

My main purpose as chairman is to be part of the board, to keep everything running smoothly, and everyone talking to each other, and to make the decisions that we need to make. The chairman is also responsible for representing the community’s interests to SUSE. Whenever there are discussions within SUSE where the community’s perspective is needed, I get asked to chime in and also vice versa. I’m the conduit from SUSE to openSUSE to explain what’s going on at SUSE: such as the merger with Micro Focus or the development of SUSE Linux Enterprise 12: what does it mean, why SUSE is doing it, what the benefits are.

What are the goals of openSUSE?

The official stated purpose of the project for the last 10 years has been to promote the use of Linux. However, we realized that we were trying to focus on everyone everywhere, which made it hard for us to establish an identity. We wanted to have greater market appeal to become the first choice of open source community participants. So the board recently identified our project strengths—where openSUSE’s appeal lies. We realized that one of our strengths is that we have lots of tools for developers and packages for system admins that are integrated into our distributions, so we offer a huge selection of choices. So our goal is to be the maker’s choice—the Linux distribution that really appeals to developers, system administrators and typical users who aspire to be sys admins. We give them everything they need to use Linux in a productive way, develop on it—and have fun.

What is your job at SUSE and how do you manage being both a SUSE employee and the openSUSE chairman?

I’m a Quality Assurance (QA) Engineer. I mainly work on SUSE Linux Enterprise, heavily using Open QA, an automated testing tool that was built originally as an openSUSE project for testing Tumbleweed. We can test all of the time, so we’re much more aware of the quality of the service pack. That’s my day job. Then as chairman of openSUSE appointed by SUSE, I also have a number of hours allocated a week for openSUSE work. SUSE makes it easy for me.

What is your background in open source? How did you get involved with openSUSE?

I’ve always worked in IT since university. My first interest in open source was casual: a SUSE precursor called “Slackware.” When Novell purchased SUSE in 2003, I purchased SUSE Linux 9.2. I got more serious about Linux. At that time it was hard to contribute, for example, bug fixes to it. Then in 2005, openSUSE was created to make contributing easy. That’s when I really started actively contributing, making bug fixes. Over time, I did advocacy work at events, helped with packaging the GNOME desktop and—as I still do today—maintained the branding package, the one with all the wallpaper, color choices, etc.

I started working for SUSE in September 2013. I was a customer before then. At the time, I was already an elected openSUSE board member, but I was hired purely as a QA engineer. Six months after I started, the current chairman stepped down and SUSE picked me. It was very nice of them.

Kay Tate

By: Kay Tate

Certification Update


  • Kay Tate is the ISV Programs Manager at SUSE, driving the support of SUSE platforms by ISVs and across key verticals and categories. She has worked with and designed programs for UNIX and Linux ISVs for fifteen years at IBM and, since 2009, at SUSE. Her responsibilities include managing the SUSE Partner Software Catalog, Sales-requested application recruitment, shaping partner initiatives, and streamlining SUSE and PartnerNet processes for ISVs.
  • Marjorie Westerman is a Marketing Writer at SUSE. She edits The SUSE Insider and SUSE News.

Because SUSE is so open, we’re ideally positioned to partner with a wide range of different companies. Our goal is to give our customers enterprise-grade platforms such as our Linux distribution, our OpenStack distribution or our Ceph-based storage solution, and partner with major hardware and software vendors to provide a breadth of choice as well as best-of-breed selection of technologies.

YES Certified Hardware

From May 19, 2015 to July 31, 2015, SUSE published Yes Certification bulletins for 369 hardware devices, including servers, workstations and SAN devices. These products come from a variety of high-tech companies worldwide, including Acer, Cisco, Dell computing, Ericsson, Fujitsu, H3C Technologies, Hewlett-Packard, Hitachi, Huaweii Technologies, IBM, Intel, Lenovo, Oracle, SGI, Sugon/Dawining Information Industries, Positivo Informatica, Wincor Nixdorf and Unisys.

To research certified systems, go to the Certified Hardware Partners' Product Catalog, search the system name and type and click on the bulletin number to see the exact configuration that has been certified.


Among YES Certifications completed in the period mentioned above, the newest releases—SUSE Linux Server 12, SUSE Linux Enterprise Desktop 12 and SUSE Linux Enterprise Server 11 Service Pack 4 (SP4)—are definitely in the majority. However, there is still interest in previous releases from SUSE Linux Enterprise Server SP3 and going back to SUSE Linux Enterprise Server 10 SP4 for a few SAN devices.

  • Out of a total of 297 network servers certified, 95 were on SUSE Linux Enterprise Server 11 Service Pack SP3, 94 were on the recently released SUSE Linux Enterprise Server 11 SP4, and 108 were on SUSE Linux Enterprise Server 12.
  • There were 28 SAN devices, consisting of 4 Hitachi Virtualization Storage Platforms on SUSE Linux Enterprise Server 11 SP3 and 24 Fijitsu ETERNUS SANs, 12 on SUSE Linux Enterprise Server 10 SP4, and 12 on SUSE Linux Enterprise Server 11 SP3.
  • SUSE certified 47 workstations during this period: 1 Wincor Nixdorf BEETLE and 3 Positivo Informatica Positivo Master on SUSE Linux Enterprise Desktop 11 SP3; 1 Intel NUC5i3MYHE and 1 Fujitsu LIFEBOOK on SUSE Linux Enterprise Desktop 12; and 41 HP 7649 workstations, 10 on SUSE Linux Enterprise Server 12 and 25 on SUSE Linux Enterprise Desktop 12.

Do you know that there is a series of blogs on SUSE Conversions to help you understand what the various categories in each YES bulletin mean? Here’s a list, from the first to the most recent:

SUSE Partner Software

SUSE is expanding its business and strategic technical relations with ISVs to support SUSE market in order to give our customers a choice of best-of-breed solutions to meet a wide range of IT and business needs. To research software certified to run on SUSE products, visit the Partner Software Catalog.


The following applications from key SUSE partners, recently certified as interoperable with SUSE Linux Enterprise Server 12. They provide capabilities essential to a wide range of businesses and are enhanced to deal with modern computing trends, including software-defined storage, cloud computing and big data.

  • EMC Documentum 7.2 The enterprise-class Documentum standard provides a robust, scalable, fault-tolerant, and extensible architecture to manage and control all your information content. It is the fastest and most secure Documentum release to date. This includes top secret-level encryption (AES-256) for content in transit and at rest, as well as new storage certifications, which allow for storage management optimization within the software-defined data center.
  • Symantec NetBackup Platform 7.7 The NetBackup Platform is a holistic backup and recovery solution that is optimized for virtually any workload, whether physical, virtual, arrays, or big data. It delivers truly flexible target storage options, whether tape, third party-disk, appliances, (including the NetBackup Deduplication Appliances and Integrated Backup Appliances), or cloud. Among its new capabilities, it includes features that greatly expand the effectiveness of backup and recovery operations that utilize cloud storage services, adding support for new cloud providers and increasing performance by up to thirty times.

The platform includes NetBackup Enterprise Server 7.7 and NetBackup Enterprise Server Client 7.7 Sign up to take user tests, and earn Amazon gift cards