SUSE Manager Best Practices

Transcription

SUSE Manager Best
Practices
Joseph Cayouette
Publication Date: April 18, 2016
Edited by Jeff Price, Michael Brookhuis, Torsten Hallman, and SUSE Manager Team
SUSE LLC
10 Canal Park Drive
Suite 200
Cambridge MA 02141
USA
https://www.suse.com/documentation
Contents
1
1.1
Introduction 1
Whats Covered in this Guide? 1
1.2
Prerequisites 1
1.3
Network Requirements 2
1.4
Hardware Recommendations 5
2
Managing Your Entitlements 8
2.1
Overview SUSE Customer Center (SCC) 8
2.2
Subscription Management Tool (SMT) and Disconnected Setup
(DMZ) 8
3
Configuration Management with Salt 12
3.1
Configuration Management Overview 12
3.2
State Data: Levels of Hierarchy 12
3.3
Salt States Storage Locations 13
3.4
SUSE Manager States 13
3.5
Pillar Data Exposed by SUSE Manager 14
Targeting Organizations and Groups with Custom States Using Pillars 14
4
Channel Management 15
4.1
Introduction 15
4.2
The Importance of Channel Design 15
Channel Terminology 15
iii
4.3
Channel Life-cycle Management 16
4.4
What is Channel Staging? 17
4.5
Channel Hierarchy: Base and Child Channels 17
4.6
Relationship Between Products and Channels 18
4.7
Organization Credentials 18
4.8
Adding Products 18
4.9
Channel Cloning 18
4.10
Cloning Channels by Date 18
4.11
Channel Security 19
4.12
Signed Third party packages 19
4.13
Signed Internal Packages 19
4.14
GPG key usage 19
5
Activation Key Management 20
5.1
What's Covered Here? 20
5.2
What are Activation Keys? 20
5.3
Provisioning and Configuration 20
5.4
Activation Keys Best Practices 21
Key Label Naming 22 • Channels to be Included 22
5.5
Combining Activation Keys 23
5.6
Using Activation Keys and Bootstrap with Traditional Clients (NonSalt) 26
5.7
Using Activation Keys when Registering salt-minions 26
Using an Activation Key and Custom Grains File 27 • Using an Activation Key in
the Minion Configuration File 27
6
6.1
iv
Contact Methods 29
Selecting a Contact Method 29
6.2
The rhnsd (Default) 29
Configuring SUSE Manager rhnsd Daemon 30 • Viewing rhnsd Daemon
Status 30
6.3
SSH Push 31
Configuring the Server for SSH Push 32 • Using sudo with SSH Push
32 • Client Registration 33 • API Support for SSH Push 34 • Proxy
Support with SSH Push 35
6.4
osad 36
Configuring and Enabling osad 37 • osad Configuration and Logging
Files 38
7
Advanced Patch Lifecycle Management 40
7.1
Whats Covered Here? 40
7.2
Assumptions 40
7.3
Patch Lifecycle Management Overview 41
Important Terminology 42
7.4
Example Scenario 42
7.5
Implementation 43
7.6
Base Channels and Architecture 45
7.7
Automation and Process Design 47
7.8
Patch Promotion Cycle 48
7.9
Exception and Escalation Channels 50
7.10
Components to be Created 51
7.11
Channels 51
Creating Archive Channels 52 • Service Pack Migration Support with Update
and Exception Channels 54 • Current-Updates Channels 57 • Exception
Channels 58
7.12
v
Activation Keys and Bootstrapping 60
7.13
Scripts 63
Patch/Package Merge Script 63 • Channel Archive Creation Script / Channel
Archive Sources List Config File 64
7.14
Crontab Entries and Automation 64
7.15
Use Cases and Workflows 65
Workflow 1: Patch Promotion Process 66 • Workflow 2: Patch Exception
Process 67 • Workflow 3: Security ASAP Exceptions Process 68
7.16
Sample Scripts 71
Sample Spacewalk-Clone-By-Date Configuration 71 • Sample Patch/Package
Merge Script Using Python 73 • Sample Crontab Entries for Automation
and Archive Channel Creation 75 • Sample Archive Channel Creation
Script 75 • Sample Archive Channel Sources List File 78
8
8.1
Introduction 80
8.2
Prerequisites 80
8.3
Setup the Target Machine 81
8.4
Performing the Migration 82
8.5
Speeding up the Migration 83
8.6
Packages on External Storage 83
8.7
Troubleshooting a Broken UI after Migration 84
8.8
Example Session 84
9
vi
SUSE Manager Migration from 2.1 to 3 80
Using a Custom SSL Certificate 91
9.1
Prerequisites 91
9.2
Using a Custom Certificate with SUSE Manager Proxy 3 92
1 Introduction
This document targets system administrators.
1.1 Whats Covered in this Guide?
This document describes SUSE recommended best practices for SUSE Manager. This information
has been collected from a large number of successful SUSE Manager real world implementations
and includes feedback provided by product management, sales and engineering.
This chapter will discuss the following topics:
Prerequisites
Network Requirements
Hardware Requirements
1.2 Prerequisites
Purchased Registration Keys. During initial setup SUSE Manager will request a product
Registration Key . This key will be provided to you after purchasing the product. You can find
your key located under your SUSE Customer Center account. Login with your SUSE Customer
Center credentials or register for a new account.
https://scc.suse.com
Evaluation Keys. If you wish to run a test system (non-production) a 60 day evaluation key may
be obtained. On the SUSE Manager product page click TRY SUSE MANAGER. The evaluation
key limits the number of systems that may be registered with SUSE Manager to 10.
https://www.suse.com/products/suse-manager/
SCC Organization Credentials. During setup you will also be asked to enter your SUSE Customer
Center Organization Credentials . Login to your SUSE Customer Center account and on the
Users and Passwords. During both the SUSE Linux Enterprise installation and setup of SUSE
Manager several users and passwords will be created:
1
Introduction
SUSE Manager 3
SUSE Linux Enterprise root user account
PostgreSQL database user and password
Certificate of Authority password
SUSE Manager administrator user and password
Tip: Safe Passwords
Maintain security by creating safe passwords. Store passwords within a secure location.
Use the following guidelines when creating your passwords.
At least 8 characters long
Should contain uppercase characters A B C
Should contain lowercase characters a b c
Should contain numbers 1 2 3
Should contain symbols ~ ! @ % $
Warning: Password Pitfalls
Avoid common password pitfalls by scanning the following list.
Stay away from confusing characters such as: 0 O
or 1 l
Ensure your password does not contain complete words or common terms such as:
SUSE johnsmith penguin
Do not use common data such as birthdates, age and pet names
1.3 Network Requirements
SUSE Manager and SUSE Manager Proxy both contact several external addresses in order
to maintain updates and entitlements. Which hostnames are utilized depends on if you are
using legacy Novell Customer Center or have migrated to SUSE Customer Center. It is highly
2
SUSE Manager 3
recommended that you migrate to SUSE Customer Center. The following lists provide the up-to-
date hostnames for each service requiring permission when used in combination with corporate
firewall and content filters.
SUSE CUSTOMER CENTER HOSTNAMES (RECOMMENDED)
https://scc.suse.com
https://updates.suse.com
NOVELL CUSTOMER CENTER HOSTNAMES (LEGACY)
https://secure-www.novell.com
https://nu.novell.com
For SUSE Manager to function properly it requires the following pre-configured components
within your network.
Networking Hardware. The following table provides networking hardware info. As SUSE
Manager will likely be managing a large number of systems quite possibly numbering in
hundreds or even thousands, networking hardware which increases bandwidth will become
increasingly more important.
100Mbits/s Link
Non-production test server
1Gb/s Link +
Production Server
Hardware
Recommended
DHCP Server. The purpose of the Dynamic Host Configuration Protocol (DHCP) is to assign
network settings centrally (from a server) rather than configuring them locally on each and
every workstation. A host configured to use DHCP does not have control over its own static
address. It is enabled to configure itself completely and automatically according to directions
from the server. A DHCP server supplies not only the IP address and the netmask, but also the
host name, domain name, gateway, and name server addresses for the client to use. For more
information on configuring DHCP see also:
https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dhcp.html
FQDN. DNS assists in assigning an IP address to one or more names and assigning a name to an
IP address. In Linux, this conversion is usually carried out by a special type of software known
3
SUSE Manager 3
as bind. The machine that takes care of this conversion is called a name server. The names make
up a hierarchical system in which each name component is separated by a period. The name
hierarchy is, however, independent of the IP address hierarchy described above. Consider a
complete name, such as jupiter.example.com, written in the format hostname.domain. A full
name, referred to as a fully qualified domain name (FQDN), consists of a host name and a domain
name (example.com). For more information on configuring a name server see also:
https://www.suse.com/documentation/sles-12/book_sle_admin/data/
sec_basicnet_nameres.html
DNS Server. DNS (domain name system) is required for resolving domain names and host names
into IP addresses. For example, the IP address 192.168.2.100 could be assigned to the host
name jupiter. In the case of SUSE Manager the DNS server must be resolvable both via DNS and
reverse lookup. For more information on configuring DNS see also:
https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html
Important: Microsoft NT Lan Manager Compatibility
Microsoft NT Lan Manager can be configured for use with basic authentication and will
work with SUSE Manager but authentication using native (NTLM) Microsoft protocols
is not supported.
Open Port List. During the setup process of SUSE Manager all required ports will be opened
automatically. The following tables provide you with an overview of ports which are used by
SUSE Manager.
TABLE 1.1: REQUIRED SERVER PORTS
Port
Description
67
Required when SUSE Manager is configured as a DHCP server for systems
69
Used when SUSE Manager is configured as a PXE server and allows installation
80
Used to contact SUSE Customer Center . All WebGUI, client, and proxy server
4
requesting IP addresses.
and re-installation of PXE-boot enabled systems.
requests travel via http or https.
SUSE Manager 3
Port
Description
443
All WebGUI, client, and proxy server requests via http or https and SUSE Manager
5222
When you wish to push actions to clients this port is required by the osad
5269
Needed if you push actions to or via a SUSE Manager Proxy.
4505
Required by the Salt-master for communication via TCP to minions .
4506
Required by the Salt-master for communication via TCP to minions.
uses this port for SUSE Customer Center inbound traffic.
daemon running on your client systems
Tip: Denying External Network Access
When your network requires denying external network access to and from SUSE Manager,
an SMT Server may be registered against SUSE Manager. The SMT server can then be
used to synchronize the necessary SUSE repositories. For more information on utilizing
an SMT Server see also: Subscription Management Tool for SUSE Linux Enterprise
1.4 Hardware Recommendations
This section provides field tested production recommendations for small to mid size networks
that will be managed by SUSE Manager.
Advised Number of CPUs. Review the following list for CPU recommendations.
Connecting 200 systems or less to SUSE Manager: 4 CPUs
Connecting 500 systems or less to SUSE Manager: 4-8 CPUs
When implementing RHEL channels: 8 CPUs
Advised Memory Sizes. See the following list for memory sizing requirements.
Less than 100 client systems: 8 GB or more
Less than 200 client systems: 12 GB or more
5
Hardware Recommendations
SUSE Manager 3
Above 200 client systems: 16 GB or more
When implementing RHEL channels: 16GB
Disk Space. SUSE Manager stores information in several directories. For these directories it
is strongly recommend that you create separate file-systems or use an NFS share. During
installation one VG will be created that contains all disks selected during installation. Therefore
the first disk should be large enough to contain the OS. Normally 20GB - 50GB is sufficient. A
50 GB partition would be the recommended size. The following directories should be created
on a separate file-system.
/var/spacewalk This directory will contain all rpm's. Each RPM will be stored only once.
The needed size will depend on the number of channels and type of channels that will
be downloaded. The general rule would be that per SUSE support pack (including SUSE
RedHat Expanded Support) around 50 Gb should be enough. An extra 50 Gb for non-SUSE
repositories should be added on top. If other non-enterprise distributions (eg OpenSUSE,
CentOS) will be added, also calculated 50 Gb per distribution. This directory could also
be stored on a NFS share.
/var/lib/pgsql This directory contains the PostgreSQL database. Recommended is to
create a file-system of 50Gb. This volume should be monitored, because a full file-system
where the database is running on can cause unexpected errors (and this even months after
it happened). If an external Oracle database is used, this directory is not needed.
/srv/tftpboot If PXE/cobbler is used, this directory will contain the images (initrd and
linux) for all created auto-installation profiles. Each image is around 50Mb. Depending
on the number of profiles a decision has to be made if it would be useful to move this
directory to a separate file-system.
/var/log As SUSE Manager is writing many many logs, it is recommended to create a
separate file-system for /var/log. The size should be around 20G. The challenge is that
currently there are still logs, that are not being rotated with logrotate.
/var/spacewalk/db_backup For
the backup of the PostgreSQL database, it is
recommended the create a separate directory. Later in this document it will be described
how a backup from the PostgreSQL database can be created. As this could get rather big,
it is advised to have a separate file-system. The size should be around twice the size as
for /var/lib/pqsql.
6
SUSE Manager 3
Supported Databases. SUSE Manager 3 no longer provides support for an external Oracle
database. The default database is an embedded PostgreSQL. During SUSE Manager setup the
database will be created and configured.
7
SUSE Manager 3
2 Managing Your Entitlements
There are two methods for managing your subscriptions and entitlements. Both methods access
SUSE Customer Center and provide specialized benefits.
Directly connecting to SUSE Customer Center is the recommended default way of
managing your SUSE Manager Server.
If you have special network security requirements which do not allow access from your
internal network to the internet then you may use a SUSE Linux Enterprise 12 SP1 Server
running the Subscription Management Tool (SMT) for maintaining your entitlements. This
tool will contact SUSE Customer Center from a system connected to the external network
and obtain updates for your clients which you may then mount on your internal SUSE
Manager Server. This is the preferred method for managing client systems within a highly
secure network infrastructure.
2.1
Overview SUSE Customer Center (SCC)
SUSE Customer Center (SCC) is the central place to manage your purchased SUSE subscriptions
and entitlements, helping you access your update channels and get in contact with SUSE experts.
The user-friendly interface gives you a centralized view of all your SUSE subscriptions, allowing
you to easily find all subscription information you need. The improved registration provides
faster access to your patches and updates. SUSE Customer Center is also designed to provide
a common platform for your support requests and feedback. Discover a new way of managing
your SUSE account and subscriptions via one interface—anytime, anywhere.
For more information on using SUSE Customer Center see: https://scc.suse.com/docs/
userguide
2.2 Subscription Management Tool (SMT) and
Disconnected Setup (DMZ)
If it is not possible to connect SUSE Manager directly or via a proxy to the Internet,
a disconnected setup in combination with Subscription Management Tool (SMT) is the
recommended solution. In this scenario, SMT stays in an “external” network with a connection to
8
Managing Your Entitlements
SUSE Manager 3
SUSE Customer Center and synchronizes the software channels and repositories on a removable
storage medium. Then you separate the storage medium from SMT, and mount it locally on
your SUSE Manager server to read the updated data.
The following procedure will guide you through using (SMT).
PROCEDURE 2.1: SMT: FETCHING REPOSITORY DATA FROM SUSE CUSTOMER CENTER
1. Configure SMT in the external network with SUSE Customer Center (SCC). For details
about configuring SMT with SUSE Linux Enterprise 12 SP1, see: https://www.suse.com/
documentation/sles-12/book_smt/data/book_smt.html
2. Using SMT, mirror all required repositories.
3. Create a "database replacement file" (e.g., /tmp/dbrepl.xml .
smt-sync --createdbreplacementfile /tmp/dbrepl.xml
4. Mount a removable storage medium such as an external hard disk or USB flash drive.
5. Export the data to the mounted medium:
smt-sync --todir /media/disk/
smt-mirror --dbreplfile /tmp/dbrepl.xml --directory /media/disk \
--fromlocalsmt -L /var/log/smt/smt-mirror-export.log
Note: Keeping A Disconnected Server Up-to-date
smt-sync also exports your subscription and entitlement data. To keep SUSE
Manager up-to-date with your subscriptions and entitlements, you must frequently
import and export this data.
6. Unmount the storage medium and carry it securely to your SUSE Manager 3 Server.
The next procedure will show you how to update your server from the (SMT) media.
PROCEDURE 2.2: UPDATING YOUR SUSE MANAGER SERVER FROM THE STORAGE MEDIUM
1. Mount the storage medium on your SUSE Manager server (e.g., at /media/disk).
2. Specify the local path on the SUSE Manager server in /etc/rhn/rhn.conf:
9
Subscription Management Tool (SMT) and Disconnected Setup (DMZ)
SUSE Manager 3
server.susemanager.fromdir = /media/disk
This setting is mandatory for SUSE Customer Center and mgr-sync
3. Restart Tomcat:
rctomcat6 restart
4. Before performing another operation on the server execute a full sync:
mgr-sync refresh
# SCC (fromdir in rhn.conf required!)
5. mgr-sync can now be executed normally:
mgr-sync list channels
mgr-sync add channel channel-label
Warning: Data Corruption
The disk must always be available at the same mount point. To avoid data
corruption, do not trigger a sync, if the storage medium is not mounted. If you
have already added a channel from a local repository path, you will not be able to
change its URL to point to a different path afterwards
Up-to-date data is now available on your SUSE Manager server and is ready for updating client
systems. According to your maintenance windows or update schedule refresh the data on the
storage medium with (SMT).
PROCEDURE 2.3: REFRESHING DATA ON THE STORAGE MEDIUM FROM (SMT)
1. On your SUSE Manager server, unmount the storage medium and carry it to your SMT.
2. On your (SMT) system, continue with Step 4.
Warning: Data Corruption
The storage medium must always be available at the same mount point. To avoid
data corruption, do not trigger a sync if the storage medium is not mounted.
10
SUSE Manager 3
This concludes using (SMT) with SUSE Manager3.
11
SUSE Manager 3
3 Configuration Management with Salt
3.1 Configuration Management Overview
Salt is capable of applying states by matching minions with relevant state data. This data comes
from SUSE Manager in the form of package and custom states.
3.2 State Data: Levels of Hierarchy
State data comes from SUSE Manager in the form of package and custom states and targets
minions at three specific levels of hierarchy. The state hierarchy is defined by the following
order or priority: Individual minions have priority on packages and custom states over groups.
Next a group has priority over the organization.
Minion Level
Systems Specific Minion States
Group Level
Systems System Groups
Organization Level
Systems Manage System Types: My Organization
For example:
Org1 requires that vim version 1 is installed
Group1 requires that vim version 2 is installed
Group2 requires any version installed
This would lead to the following order of hierarchy:
Minion1 part of [Org1, Group1] wants vim removed, vim is removed (Minion Level)
Minion2 part of [Org1, Group1] wants vim version 2 gets version 2 (Group Level)
12
Configuration Management with Salt
SUSE Manager 3
Minion3 part of [Org1, Group1] wants any version, gets version 2 (Org Level)
Minion4 part of[Org1, Group2] wants any version, gets vim version 1 (Org Level)
3.3 Salt States Storage Locations
The SUSE Manager salt-master reads its state data from three file root locations.
The directory /usr/share/susemanager/salt is used by SUSE Manager and comes from the
susemanager-sls. It is shipped and updated together with SUSE Manager and includes certificate
setup and common state logic to be applied to packages and channels.
The directory /srv/susemanager/salt is generated by SUSE Manager and based on assigned
channels and packages for minions, groups and organizations. This file will be overwritten
and regenerated. This could be thought of as the SUSE Manager database translated into salt
directives.
The third directory /srv/salt is for custom state data, modules etc. SUSE Manager does not
operate within or utilize this directory. However the state data placed here affects the Highstate
of minions and is merged with the total state result generated by SUSE Manager.
3.4 SUSE Manager States
All sls files created by users will be saved to disk on the salt-master server. These files will
be placed in /srv/susemanager/salt/ and each organization will be placed within its own
directory. Although these states are custom, these states are created using SUSE Manager. The
following provides an overview of directory structure:
├── manager_org_DEVEL
│
├── files
│
│
│
└── state.sls
... files needed by states (uploaded by users)...
... other sls files (created by users)...
E.g.:
├── manager_org_TESTING
│
├── files
│
│
│
│
13
└── motd
# user created
... other files needed by states ...
Salt States Storage Locations
SUSE Manager 3
│
└── motd.sls
# user created
... other sls files ...
3.5 Pillar Data Exposed by SUSE Manager
SUSE Manager exposes a small amount of internal data like group membership, organization
membership and file roots as pillars which can be used with custom sls states. These are managed
by SUSE Manager or by the user.
To avoid hard-coding organization id's within sls files, a pillar entry is added for each
organization:
org-files-dir: relative_path_to_files
This file will be available for all minions which belong to this organization.
The following represents a Pillar example located in /etc/motd/ :
file.managed:
- source: salt://{{ pillar['org-files-dir']}}/motd
- user: root
- group: root
- mode: 644
3.5.1 Targeting Organizations and Groups with Custom
States Using Pillars
14
Pillar Data Exposed by SUSE Manager
SUSE Manager 3
4 Channel Management
4.1 Introduction
This chapter discusses the critical topic of channel design within SUSE Manager and provides
an overview of channel management concepts. This includes naming, base and child channel
relationships, deployment and maintenance of vendor and custom channels for SUSE Manager
Server and SUSE Manager Proxy as well as the SUSE Manager channel life cycle and staging.
This chapter also provides information about repositories, cloning, and provides information
about the various security options available for channels. It is assumed that SUSE Manager is
connected to SUSE Customer Center and retrieving channel information.
4.2 The Importance of Channel Design
The design of your channels influence all other component interaction within SUSE Manager
and as such, channel design requires careful planning and a concrete understanding of channel
terminology. While re-working channels after initial setup is certainly possible, in large
environments this will become an increasingly difficult task. Therefore it is important to plan
your channel implementation with this consideration in mind, specifically when regarding large
production environments.
Channels in SUSE Manager represent the software sources for your clients. Like other media
types channels contain software packages, patches and updates for client systems. Channels also
provide an administrator with strict controls as to which packages may be installed on client
systems and make an organizations application life cycle easier to manage.
The following section briefly covers channel terms used both internally and externally by
our teams. These terms will provide you with the terminology necessary for planning and
implementing your life-cycle and staging design goals.
4.2.1
Channel Terminology
Channels and Repositories. A channel could also be called a repository manager within SUSE
Manager. A channel is a collection of RPMs and when present, errata data. Each base channel
15
Channel Management
SUSE Manager 3
also contains information specific to the product and architecture. A term often confused with
channels, is a repository . A repository is simply a storage location from which software
packages may be retrieved and installed. A repository contains a set of packages similar to a
channel. However, while a channel can contain several repositories, a repository only contains
package sets. SUSE Manager channels may include external repositories. One or more of these
repositories may be added to a base channel or assigned to multiple child channels.
Base Channels. Base channels are built on a specific architecture and SUSE Linux Enterprise
or RHEL release. A channel may contain one or more channels. These additional channels are
referred to as child channels. A client system may only be assigned to one base channel. If the
base channel is a clone (copy) of a SUSE channel it also contains the meta information required
to perform a SUSE Manager support pack migration.
Child channels. These channels belong to a single base channel and are from the same
architecture and SLES or RHEL release. A registered system may have one or more child
channels, but all children must belong to the same base channel.
Patches. Patches are a collection of packages which belong together and aid in solving
security issues, contain bug fixes or to simply provide an update. The data within a patch
is gathered together and termed errata . Regarding SUSE Manager, most actions performed
within software channels are executed using these patches.
Packages. Packages are RPMs that contain all necessary files: configuration, binaries, scripts,
as well as pre and post installation scripts.
Clones. A clone is a copy of a channel and will include exactly the same information as the
original channel from when the channel was created. If the original channel receives updates
after the clone has been created, these changes have to be updated (or cloned) to the cloned
channel. This is a manual process which can be automated with the standard SLES tools. Cloning
is especially useful in life-cycle management. More information on cloning can be found here.
See also :.
Staging. This will be described in the next sub-chapter about staging.
4.3 Channel Life-cycle Management
This section describes SUSE Manager Life-cycle best practices.
16
Channel Life-cycle Management
SUSE Manager 3
4.4 What is Channel Staging?
Staging is the next step in life-cycle management. Selecting the correct staging model based
on your organizational requirements is necessary to safeguard the stability of your production
systems. The following list identifies some of the recommended staging models.
Staging models available in SUSE Manager
Three tier model. Tiers may be reduced or extended depending on your requirements. See
also:
A clone model based on a date or period of time. See also:
A clone model based on specific projects. See also:
A combination of one or more of the above models
The following figure illustrates the three tier model in practice.
FIGURE 4.1: THREE TIER MODEL
4.5
Channel Hierarchy: Base and Child Channels
It is important to understand channel hierarchy when working with channels.
17
What is Channel Staging?
SUSE Manager 3
There are two types of channels in SUSE Manager:
base channel: A base channel consists of packages built for a specific architecture and a
SUSE Linux Enterprise Server or Red Hat Enterprise Linux release.
child channels: A child channel is a channel associated with a base channel and contains
extra packages to extend its base channel.
A client system must be assigned a base channel as this provides it's main media sources. A
client may only have one base channel assigned to it, but a base channel may be assigned
multiple child channels. A base channel could also be referred to as a parent channel to which all
child channels belong. A subscribed client system may only install or update packages available
through its assigned base and child channels.
4.6 Relationship Between Products and Channels
IN DEVELOPMENT
4.7 Organization Credentials
IN DEVELOPMENT
4.8 Adding Products
IN DEVELOPMENT
4.9 Channel Cloning
IN DEVELOPMENT
4.10 Cloning Channels by Date
IN DEVELOPMENT
18
Relationship Between Products and Channels
SUSE Manager 3
4.11 Channel Security
IN DEVELOPMENT
4.12 Signed Third party packages
IN DEVELOPMENT
4.13 Signed Internal Packages
IN DEVELOPMENT
4.14 GPG key usage
IN DEVELOPMENT
19
Channel Security
SUSE Manager 3
5 Activation Key Management
5.1 What's Covered Here?
5.2 What are Activation Keys?
An activation key in SUSE Manager is a group of configuration settings with a label. You
can apply all configuration settings associated with an activation key by adding its label as a
parameter to a bootstrap script. Under normal operating conditions best practices suggest using
an activation key label always in combination with a bootstrap script.
An activation key can specify:
Channel Assignment
System Types (Traditionally called Add-on Entitlements)
Contact Method
Configuration Files
Packages to be Installed
System Group Assignment
So what do activation keys do exactly? Activation keys alone do nothing. The are just a collection
of configuration settings which have been given a label name and then added to a bootstrap
script. When the bootstrap script is executed all configuration settings associated with the label
are applied to the system the script is run on.
5.3 Provisioning and Configuration
20
Activation Key Management
SUSE Manager 3
FIGURE 5.1: PROVISIONING AND CONFIGURATION OVERVIEW
5.4 Activation Keys Best Practices
There are a few important concepts which should be kept in mind when creating activation
keys. The following sections provide insight when creating and naming your activation keys.
21
Activation Keys Best Practices
SUSE Manager 3
5.4.1
Key Label Naming
One of the most important things to consider during activation key creation is label naming.
Creating simple names which are associated with your organization's infrastructure will make
it easier for you when performing more complex operations. When naming key labels keep the
following in mind:
OS naming(mandatory): Keys should always refer to the OS they provide settings for
Architecture naming(recommended): Unless your company is running on one architecture,
for example x86_64, then providing labels with an architecture type is a good idea.
Server type naming: What is, or what will this server be used for?
Location naming: Where is the server located? Room, building or department?
Date naming: Maintenance windows, quarter, etc.
Custom naming: What naming scheme suits your organizations needs?
Example activation key label names:
sles12-sp1-web_server-room_129-x86_64
sles12-sp2-test_packages-blg_502-room_21-i586
5.4.2
Channels to be Included
When creating activation keys you also need to keep in mind which channels (software sources)
will be associated with it. For example:
Important: Specific Base Channel Assignment
OS keys must have a specific base channel assigned to it for example: SLES12-SP1-Pool-
x86_64 If this is not the case SUSE Manager will be unable to assign specific stages. All
non-OS keys must have the SUSE Manager Default
as their base channel. Using the
SUSE Manager Default Base Channel is not recommended and may cause problems.
Channels to be included:
22
Key Label Naming
SUSE Manager 3
suse-manager-tools
Typical packages to be included:
osad(pushing tasks)
Installs python-jabberpy and pyxml as dependencies
rhncfg-actions (Remote Command, Configuration Managment)
Installs rhncfg and rhncfg-client as dependencies
5.5 Combining Activation Keys
You can combine activation keys when executing the bootstrap script on your clients. Combining
keys allows for more control on what is installed on your systems and reduces duplication of
keys for large complex environments.
23
Combining Activation Keys
SUSE Manager 3
FIGURE 5.2: COMBINING ACTIVATION KEYS
24
SUSE Manager 3
FIGURE 5.3: COMBINING ACTIVATION KEYS 2
25
SUSE Manager 3
5.6 Using Activation Keys and Bootstrap with
Traditional Clients (Non-Salt)
Create the initial bootstrap script template from the command line on the SUSE Manager server
with:
# mgr-bootstrap
This command will generate the bootstrap script and place them in /srv/www/htdocs/pub/
bootstrap .
Alternatively you may use the WebUI to create your bootstrap script template.
Create the activation keys you need from command line with:
Alternatively
use
the
WebUI
to
create
to:Overview Tasks Manage Activation Keys
your
keys.
From
the
WebUI
proceed
5.7 Using Activation Keys when Registering saltminions
With the addition of Salt to SUSE Manager 3 states should now be considered best practice
over the more traditional way of combining activation keys. Although states allow for more
configuration options you need to place the new system within the correct group so the desired
states will be applied to the system. Using an activation key on your minions will place the
system within the correct group automatically.
You should be aware of a few facts when working with Salt over traditional activation keys
Currently we do not support specifying an activation key on the minion on-boarding page.
Activation keys used with salt-minions are the same as those used with traditional systems
and may be shared.
The equivalent of specifying a key using the traditional bootstrap method is to place
the desired key in the grain of a minion. For more information on grains see: https://
docs.saltstack.com/en/latest/topics/targeting/grains.html
Using Activation Keys and Bootstrap with Traditional Clients (Non-Salt)
26
SUSE Manager
3
Once a minion has been accepted either from the Salt Onboarding page located in the
WebUI or from the command line, all configurations specified by the activation key placed
within a salt grain will be applied.
Currently you may only use one activation key when working with salt. You cannot
combine them, despite this, salt states allow for even more control.
5.7.1
Using an Activation Key and Custom Grains File
Create a custom grains file and place it on the minion here:
# etc/salt/grains
Then add the following lines to the grains file replacing 1-sles12-sp1 with your activation key
label:
susemanager:
activation_key: 1-sles12-sp1
Now restart the minion with:
# systemctl restart salt-minion
5.7.2
Using an Activation Key in the Minion Configuration File
You may also place the activation key grain within the minion configuration file located in:
# etc/salt/minion
Now add the following lines to the minion configuration file replacing 1-sles12-sp1 with your
activation key label:
grains:
susemanager:
activation_key: 1-sles12-sp1
27
Using an Activation Key and Custom Grains File
SUSE Manager 3
Reboot the minion with:
# systemctl restart salt-minion
28
Using an Activation Key in the Minion Configuration File
SUSE Manager 3
6 Contact Methods
6.1 Selecting a Contact Method
SUSE Manager provides several methods for communication between client and server. All
commands your SUSE Manager server sends its clients to do will be routed through one of
the following configured contact methods. Which one you select will be heavily dependant on
your network infrastructure. The following sections provide a good starting point for selecting
a method which best suits your network environment.
Note: Contact Methods and Salt
This chapter is only relevant for traditional clients as Salt clients (minions) utilize a salt
specific contact method.
6.2 The rhnsd (Default)
The SUSE Manager daemon (rhnsd) runs on client systems and periodically connects with SUSE
Manager to check for new updates and notifications. The daemon, which runs in the background,
is typically started by the rcrhnsd initialization script. By default it will check every 4 hours
for new actions, therefore it may take some time for your clients to begin updating after actions
have been scheduled for them.
To check for updates, rhnsd runs the external mgr_check program located in /usr/sbin/ .
This is a small application that establishes the network connection to SUSE Manager. The SUSE
Manager daemon does not listen on any network ports or talk to the network directly. All
network activity is done via the mgr_check utility.
Warning: Auto accepting (EULAs)
When new packages or updates are installed on the client via SUSE Manager, any licenses
(EULAs) requiring agreement before installation are automatically accepted.
This figure provides an overview of the default rhnsd process path. All items left of the Python
XMLRPC server block represent processes running on a SUSE Manager client.
29
Contact Methods
SUSE Manager 3
FIGURE 6.1: RHNSD CONTACT METHOD
6.2.1
Configuring SUSE Manager rhnsd Daemon
The SUSE Manager daemon can be configured by editing the following configuration file:
/etc/sysconfig/rhn/rhnsd
This is the configuration file the rhnsd initialization script uses. An important parameter for
the daemon is its check-in frequency. The default interval time is four hours (240 minutes). If
you modify the configuration file, you must as root restart the daemon with the command
rcrhnsd restart .
Important: Minimum Allowed Check-in Parameter
The minimum allowed time interval is one hour (60 minutes). If you set the interval
below one hour, it will default back to the default of 4 hours (240 minutes).
6.2.2
Viewing rhnsd Daemon Status
You can view the status of rhnsd by typing the command rcrhnsd status as root .
30
Configuring SUSE Manager rhnsd Daemon
SUSE Manager 3
6.3 SSH Push
SSH Server Push is intended to be used in environments where your clients cannot reach the
SUSE Manager server directly to regularly check in and, for example, fetch package updates.
In detail this feature enables a SUSE Manager located within an internal network to manage
clients located on a DMZ. Due to security reasons, no system on a DMZ is authorized to open a
connection to the internal network and therefore your SUSE Manager server. The solution is to
configure SSH Server Push which utilizes an encrypted tunnel from your SUSE Manager server
on the internal network to the clients located on the DMZ. After all actions/events are executed,
the tunnel is closed. The server will contact the clients in regular intervals (using SSH) to check
in and perform all actions and events.
Important: SSH Push Unsupported Actions
Certain actions are currently not supported on scheduled clients which are managed
via SSH push. This includes re-installation of systems using the provisioning module.
Additionally, image deployments using SUSE Studio will work only when the vhost is
permitted to directly connect to the SUSE Studio image store and download the required
images.
The following figure provides an overview of the ssh push process path. All items left of the
Taskomatic block represent processes running on a SUSE Manager client.
FIGURE 6.2: SSH PUSH CONTACT METHOD
31
SSH Push
SUSE Manager 3
6.3.1
Configuring the Server for SSH Push
For tunneling connections via SSH, two available port numbers are required, one for tunneling
HTTP and the second for tunneling via HTTPS (HTTP is only necessary during the registration
process). The port numbers used by default are 1232 and 1233. To overwrite these, add two
custom port numbers greater than 1024 to /etc/rhn/rhn.conf like this:
ssh_push_port_http = high port 1
ssh_push_port_https = high port 2
If you would like your clients to be contacted via their hostnames instead of an IP address, set
the following option:
ssh_push_use_hostname = true
It is also possible to adjust the number of threads to use for opening client connections in parallel.
By default two parallel threads are used. Set taskomatic.ssh_push_workers in /etc/rhn/
rhn.conf like this:
taskomatic.ssh_push_workers = number
6.3.2
Using sudo with SSH Push
For security reasons you may desire to use sudo and SSH into a system as a user other than root.
The following procedure will guide you through configuring sudo for use with ssh push.
Note: sudo Requirements
The packages spacewalk-taskomatic >= 2.1.165.19 and spacewalk-certs-tools
=> 2.1.6.7 are required for using sudo with SSH Push.
PROCEDURE 6.1: CONFIGURING SUDO
1. Set the following parameter on the server located in: /etc/rhn/rhn.conf
ssh_push_sudo_user = user
The server will now use sudo to ssh as the configured user.
32
Configuring the Server for SSH Push
SUSE Manager 3
2. You must now create the user specified in step 1 above on each of your clients and the
following parameters should be commented out within your clients /etc/sudoers file:
#Defaults targetpw
#ALL
ALL=(ALL) ALL
# ask for the password of the target user i.e. root
# WARNING! Only use this together with 'Defaults
targetpw'!
3. Now add the following line beneath the ## User privilege specification section
of each clients sudoers file:
user ALL=(ALL) NOPASSWD:/usr/sbin/mgr_check
4. On each client add the following two lines to the /home/user/.bashrc file.
PATH=$PATH:/usr/sbin
export PATH
6.3.3
Client Registration
As your clients cannot reach the server, you will need to register your clients from the server.
A tool for performing registration of clients from the server is included with SUSE Manager 3
called mgr-ssh-push-init This tool expects a client's hostname or IP address as well as the
path to a valid bootstrap script located in the servers filesystem for registration as parameters.
Important: Specifying Ports for Tunneling before Registering
Clients
The ports for tunneling need to be specified before the first client is registered. Clients
already registered before changing the port numbers, must be registered again, otherwise
the server will not be able to contact them anymore.
Note: mgr-ssh-push-init Disables rhnsd
The mgr-ssh-push-init disables the rhnsd daemon which normally checks clients for
updates every 4 hours. Your clients cannot reach the server without using ssh push contact
method therefore the rhnsd daemon is disabled.
33
Client Registration
SUSE Manager 3
For registration of systems which should be managed via the ssh push tunnel contact method, it
is required to use an activation key that is configured to use this method. Normal ssh push is
unable to reach the server. For managing activation keys see: Chapter 5, Activation Key Management
Run the following command as root on the server to register a client:
# mgr-ssh-push-init --client client --register /srv/www/htdocs/pub/bootstrap/
bootstrap_script --tunnel
To enable a client to be managed using Push via SSH (without tunneling), the same script may
be used. Registration is optional since it can also be done from within the client in this case.
Note that mgr-ssh-push-init will also automatically generate the necessary SSH key pair if
it does not yet exist on the server:
# mgr-ssh-push-init --client client --register bootstrap_script
When using the Push via SSH tunnel contact method, please note that the client is configured to
connect SUSE Manager via the high ports mentioned above (see /etc/sysconfig/rhn/up2date).
In other words, tools like rhn_check and zypper will need an active SSH session with the proper
port forwarding options in order to access the SUSE Manager API. To verify the Push via SSH
tunnel connection manually, you can run e.g. this on the SUSE Manager server:
# ssh -i /root/.ssh/id_susemanager -R high port: susemanager :443 client zypper ref
6.3.4
API Support for SSH Push
The contact method to be used for managing a server can also be modified via the API. The
following example code (python) shows how to set a system's contact method to 'ssh-push'.
Available valid values are:
'default' (pull)
'ssh-push'
'ssh-push-tunnel'
client = xmlrpclib.Server(SUMA_HOST + "/rpc/api", verbose=0)
key = client.auth.login(SUMA_LOGIN, SUMA_PASSWORD)
34
API Support for SSH Push
SUSE Manager 3
client.system.setDetails(key, 1000012345, {'contact_method' : 'ssh-push'})
Note: Migration and Management via SSH Push
When a system should be migrated and managed using SSH push, it requires setup using
the mgr-ssh-push-init script before the server can connect via SSH. This separate
command requires human interaction to install the server's SSH key onto the managed
client (root password). The following procedure illustrates how to migrate an already
registered system:
PROCEDURE 6.2: MIGRATE REGISTERED SYSTEMS
1. Setup the client using the mgr-ssh-push-init script (without --register)
2. Change the client's contact method to 'ssh-push' or 'ssh-push-tunnel' respectively (via API
or web UI)
Existing activation keys can also be edited via API to use the SSH push contact method for
clients registered with these keys:
client.activationkey.setDetails(key, '1-mykey', {'contact_method' : 'ssh-push'})
6.3.5
Proxy Support with SSH Push
It is possible to use SSH push to manage systems that are connected to the SUSE Manager server
via a proxy. To register a system, run mgr-ssh-push-init on the proxy system for each client
you wish to register. Update your proxy with the latest packages to ensure the registration tool
is available. It is necessary to copy the ssh key to your proxy. This can be achieved by executing
the following command from the server:
# mgr-ssh-push-init --client <proxy>
35
Proxy Support with SSH Push
SUSE Manager 3
6.4 osad
The default contact method between SUSE Manager and its clients is rhnsd . When using
the rhnsd daemon the server will check every 4 hours and then execute a scheduled action
on clients. Depending on your network environment rhnsd may not suit your requirements.
Alternatively you may configure osad for use with registered client systems enabling immediate
execution of scheduled actions. osad consists of three components:
osad. A client-side service that responds to pings and runs mgr_check when directed by the
osa-dispatcher running on SUSE Manager.
osa-dispatcher. A service running on SUSE Manager that checks the database to determine if a
client running osad needs to be pinged or is required to run mgr_check , then sends a message
telling the client to do so.
jabberd. A daemon that runs on SUSE Manager and uses the XMPP protocol. osad and osa-
dispatcher both connect to this daemon. jabberd also handles authentication when using
osad.
The following figure represents the osad contact method. All items left of the osa-dispatcher
block represent running processes on the client.
FIGURE 6.3: OSAD CONTACT METHOD
HOW IT WORKS
On SUSE Manager the osa-dispatcher periodically runs a query which checks to see if
there are any clients overdue for a ping.
36
osad
SUSE Manager 3
If an overdue client is found, a message is sent via jabberd to the osad instances running
on all clients registered with your SUSE Manager server. The osad instances respond to
the ping through the jabberd deamon running in the background on your SUSE Manager
Server. osa-dispatcher receives the response, and marks the client as 'online'.
If osa-dispatcher fails to receive a response from an osad instance in a certain amount
of time, the client is marked 'offline'.
osa-dispatcher also periodically executes a select on the database to check all SUSE
Manager clients which have actions that need to be executed. If an action is found, a
message is sent through jabberd to osad which then executes mgr_check on the client.
mgr_check then takes over performing the actual action.
6.4.1
Configuring and Enabling osad
The following procedure enables use of osad with SUSE Manager.
Important: Enabling SSL
For this communication method to work SSL is mandatory. If SSL certificates are not
available, the daemon on your client systems will fail to connect. Make sure your firewall
rules allow for the required ports. See: Table 1.1, “Required Server Ports”
PROCEDURE 6.3: ENABLING OSA-DISPATCHER ON SUSE MANAGER AND OSAD ON CLIENTS
1. On your SUSE Manager server use the following command as root to start the osadispatcher service:
rcosa-dispatcher start
2. Install the osad package on all client systems to allow communication to the osa-
dispatcher on SUSE Manager. The package can be found in the Tools child channel .
Warning: osad conflicts with osa-dispatcher
Do not install the osad client package on your SUSE Manager server. The osad
client service conflicts with osa-dispatcher server package.
37
Configuring and Enabling osad
SUSE Manager 3
3. Once osad has been installed, start the service on your client systems as root using the
command:
rcosad start
Like other services, rcosa-dispatcher and rcosad accept stop, restart, and status commands
as well.
This feature depends on the client systems recognizing the fully qualified domain name (FQDN)
of SUSE Manager. The client systems use this name and not the IP address of the server when
configuring the YaST Online Update.
Now when you schedule actions from SUSE Manager on any of the osad enabled systems, the
task will be carried out immediately rather than after a client checks in using rhnsd .
6.4.2
osad Configuration and Logging Files
Each component of osad is configured via local configuration files. Changing default parameters
is not recommended. For reference the configuration files and logs are found in the following
locations.
osa-dispatcher. osa-dispatcher is configured via the rhn.conf file located on the SUSE Manager
at:
/etc/rhn/rhn.conf
All parameters for configuring osa-dispatcher are located under the section heading:
# OSA configuration #.
osad. osad configuration files are located on all SUSE Manager clients at:
/etc/sysconfig/rhn/osad.conf
/etc/syseconfig/rhn/up2date
For troubleshooting osad the log file is located in:
/var/log/osad
38
SUSE Manager 3
The location of this log file is configurable via the osad.conf file.
jabberd. Configuration of jabberd goes beyond the scope of this document. The jabberd log file
is located at:
/var/log/messages
This concludes osad configuration and logging.
39
SUSE Manager 3
7 Advanced Patch Lifecycle Management
7.1 Whats Covered Here?
This chapter describes how to setup and configure a SUSE Manager testing implementation to
enable companies in the delivery of these often requested features:
Automatic creation and archive of patch sets by quarter (or any other time period)
Consistent method of patch promotion and delivery through numerous landscapes and
environments
Exception process for handling patches that need to be excluded from a patch cycle
Environment creation with historical patch sets
Minimal need for host channel subscription manipulation from cradle-to-grave
Support for service-pack migration using custom child channels
Provides a foundation for using multiple organizations to maintain systems.
7.2 Assumptions
This guide covers SUSE Manager 3. A fresh installation is not required but some assumptions
are made. You have a working SUSE Manager environment, with a few registered clients, and
a decent knowledge of SUSE Manager terms and capabilities. If you are unfamiliar with these
terms or do not have a current working setup, see the: ???
Note: spacecmd and XMLRPC Examples
Using advanced features such as spacecmd or XMLRPC API will be explained in some
detail, but will not be exhaustive. Code examples will be included at the end of this
chapter which may be modified or used as-is. These come with no WARRANTY and
should not be expected to run with every implementation. Always test before running
any examples in production.
40
Advanced Patch Lifecycle Management
SUSE Manager 3
7.3 Patch Lifecycle Management Overview
Keeping systems patched and secure remains one of the greatest ongoing challenges which
you will face as an administrator. Both proprietary and open-source companies are constantly
working to provide updates which fix flaws discovered within their software products.
Adding to these pressures are requirements imposed by compliance initiatives such as:
PCI-DSS (Payment Card Industry Data Security Standard)
SOX (Sarbanes-Oxley)
HIPAA (Health Insurance Portability and Accountability Act)
FIPS 140 (Federal Information Processing Standard)
Included in most of these standards are rules which dictate frequency and time frames required
for patching and often these schedules are modified due to the severity level of a specific patch.
Businesses depend upon a changing landscape of applications covering a wide range of compute
infrastructure. These may include physical and virtual hosts and have complicated application
stacks.
These applications may require the following:
A specific kernel version
Strict uptime requirements
Specific run-time environments, (like Java)
Specific Linux OS release
Specific configuration requirements
Hardening and platform requirements
Specific software versions
Additionally, many companies have created duplicate host environments such as:
Production (PROD)
Development (DEV)
41
Patch Lifecycle Management Overview
SUSE Manager 3
Quality Assurance (QA)
User-acceptance/Testing (UAT)
These landscapes mirror production environments and allow for testing or validation of applied
changes to a system or set of systems. This means that you are required to manage, patch and
report on at least one more complete set of hosts.
7.3.1
Important Terminology
The following paragraphs provide an explanation of important terms used throughout this
chapter.
Landscape. Describes one of several groups of Linux hosts. This is commonly used with
enterprise software deployments as a way to define the role/quality of a host. Examples
include, production (PROD), development (DEV), quality-assurance (QA), user-acceptance/
testing (UAT), etc.
Environment. Defined as a physical separation of Linux hosts, like Corporate (CORP), or Store
(STORE), or NPE (Non-production Environment).
Organizations. Defined as a separate management environment placed under the default
organization which is created during initial installation of a SUSE Manager Server. Organizations
in SUSE Manager will typically have separate credentials required to administer them via the
WebUI and any Linux hosts managed by SUSE Manager will be registered to a single organization
and only visible to this organization.
7.4 Example Scenario
The Chameleon Corporation. The world’s largest reptile and amphibian pet store whose
headquarters are located in Yemen. This corporation has more than 1500 stores operating
under the names LizardsRUs, UnVeiledInc and Chameleo-rama in five different countries. Due
to compliance constraints, their patch lifecycle (both timing and delivery) is based on their
corporate security policies, host environments, landscapes, and future management needs. The
Chameleon Corporation must maintain the following requirements for managing patch and
security updates to their Linux hosts:
42
Important Terminology
SUSE Manager 3
REQUIREMENT SUMMARY
The published Security Policy states: "All Linux systems need to be up-to-date with the
latest available updates, bug-fixes and enhancements on a quarterly basis."
Quarters are defined as:
Q1: January 1st through March 31st
Q2: April 1st through June 30th
Q3: July 1st through September 30th
Q4: October 1st through December 31st
The published Security Policy also states the need to patch all Linux systems with “critical”
security updates (CVSS score of 7 or greater) within 1 month of release of the patch. This
introduces a second schedule that may overlap any existing patch roll-out.
The company has 3 different host environments, Corporate, Store and NPE.These are
partitioned using SUSE Manager Organizations. Each SUSE Manager Organization has
visibility into the default SUSE Manager Organization’s software channels due to trusts,
yet the managed hosts are naturally grouped and managed by their environment.
There are at least 3 landscapes in each environment, PROD,DEV, and UAT.
A “patch exceptions" process exists, as there is often a need to account for the removal of
patches (e.g. kernel updates) from a roll-out. Some hosts may have hardware drivers or
third party software which depend upon specific kernel versions. This exception process
would be handled on a case-by-case basis.
7.5 Implementation
To review, you need to configure SUSE Manager, creating a set of procedures, processes and/
or tools (scripts) to help with your patch lifecycle management. This includes the creation (and
optimally an “automatic” creation) of patch archive channels from the SUSE provided “updates”
channels for the versions of SLES you use. These patch archives will be the sources for your
patch promotions, but can also be a source to setup testing environments based on a patch set
rolled out in the past. This could be used to troubleshoot an error condition for example, by
creating a lab full of hosts patched up to any previous patch set. You may also demonstrate and
visualize a clear view of compliance defined by a time-stamped set of patches.
43
Implementation
SUSE Manager 3
You also will create a set of software channels which will be updated when you need to roll them
out. Each landscape should receive these updates only from a previously “validated” landscape.
This means a landscape patch set will first get put into DEV, tested, then move to QA, undergo
tests and finally be moved into the PROD landscape. This process will begin anew each quarter,
and you will handle exceptions if/when they occur.
Every exception will be tracked by another established process with the constant goal of re-
mediating any exception and making sure the patch is reintroduced as quickly as possible in
order to ensure a clear view of compliance.
Other interruptions to a quarterly roll-out might be the release of a “critical” security patch that
needs to be deployed more rapidly than once-a-quarter. In order to handle this extra schedule,
you will need to create an addition channel for any critical patches to track them and their rollout. Critical patches should be considered any CVE that has a CVSS score of 7.1 or greater, or
otherwise be mandated by your corporate security organization.
For this implementation you will use two different SLES versions, SLES 11 SP3 and SLES 12.
You will plan to use SUSE Manager to assist with your service pack migrations, so setting up
to account for SLES 11 SP4 initially would be ideal. We also maintain both 32-bit and 64-bit
Intel/AMD architecture versions of SLES 11 SP3 so we will need to account for both of them.
There are 2 different environments we need to manage, Corporate (CORP) and Store (STORE).
We have created separate SUSE Manager Organizations to allow our systems administrators an
exclusive view of the hosts they are responsible for. Each SUSE Manager Organization has the
3 landscapes (DEV, QA and PROD) that they use for patch testing/promotion.
Activation keys and bootstraps should be created for each SUSE Manager Organization (each
environment) and each landscape so that hosts can be registered into their appropriate, and
most likely, permanent role. For example, a bootstrap script will register a SLES 11 SP3 (64bit)
DEV host into the correct organization and will add the appropriate base and child channels
that should never have to be manipulated again.
Automation is preferred. As mentioned, the use of scripts or scheduled jobs would greatly
enhance this solution and make it easier for support staff.
44
Implementation
SUSE Manager 3
7.6 Base Channels and Architecture
This represents a high-level outline of the architecture and channels:
Note: Tip: Base Channel Naming
Any Base channel listed can also be a clone tree of the SUSE vendor channels therefore
should include a prefix in the name. This can aid the handling of service pack migrations
described during channel creation. See: .
SUSE Manager Organization
Default(Main) - 1
32 Bit Archive Channels (Public)
Q2 - 06-30-2016 - SLES 11 SP3 Updates for i586
Q3 - 09-30-2016 - SLES 11 SP3 Updates for I586
64 Bit Archive Channels(Public)
Q2 - 06-30-2016 - SLES 11 SP3 Updates for x86_64
Q3 - 09-30-2016 - SLES 11 SP3 Updates for x86_64
Q2 - 06-30-2016 - SLES 12 Updates for x86_64
Q3 - 09-30-2016 - SLES 12 Updates for x86_64
Clone Sets or Child Channels within SUSE Base Channels:
Base : SLES 11 SP3 Pool for i586
DEV - Current Patch Set - SLES 11 SP3 Updates for i586
QA - Current Patch Set - SLES 11 SP3 Updates for i586
PROD - Current Patch Set - SLES 11 SP3 Updates for i586
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 11 SP3 i586
Security ASAP Exceptions - SLES 11 SP3 i586
Base : SLES 11 SP3 Pool for x86_64
45
Base Channels and Architecture
SUSE Manager 3
DEV - Current Patch Set - SLES 11 SP3 Updates for x86_64
QA - Current Patch Set - SLES 11 SP3 Updates for x86_64
PROD - Current Patch Set - SLES 12 Updates for x86_64
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 12 x86_64
Security ASAP Exceptions - SLES 12 x86_64
Base : SLES 12 Pool for x86_64
DEV - Current Patch Set - SLES 12 Updates for x86_64
QA - Current Patch Set - SLES 12 Updates for x86_64
PROD - Current Patch Set - SLES 12 Updates for x86_64
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 12 x86_64
Security ASAP Exceptions - SLES 12 x86_64
Patch Exceptions Channels (as above)
Per Base Channel - 1 channel for each “Updates” channel:
Examples:
Patch Exceptions (DO NOT SUBSCRIBE) - SLES 11 SP3 i586
Security ASAP Exceptions - SLES 11 SP3 i586
Corporate (CORP) - 2
Any public channel will be visible here
Private channels can be shared per-organization
Store (STORE) - 3
46
Base Channels and Architecture
SUSE Manager 3
Any public channel will be visible here
Private channels can be shared per-organization
7.7 Automation and Process Design
Automation will include automatic channel clone creation for the Archive channels. To best suit
a particular company’s use-cases and product usage, a combination of scripts (cron and bash)
and a configuration file will be used. The archive creation will be triggered by a custom cron job
as follows. Criteria for dates will determine the exact setup. For example, a quarterly schedule
could be implemented based on the first or last day of a given quarter. If the trigger time is the
END of a quarter, it would have to consider day 30 on the 3 rd and 9 th months of a calendar
(March and September), and day 31 on the 6 th and 12 th months (June and December). This
will require 2 crontab entries such as (cron syntax):
0 0 30 6,9 * /path/to/archive-create-script
0 0 31 3,12 * /path/to/archive-create-script
If the trigger for the quarter is going to happen on the 1 st of a month, then only one
crontab entry would be required, for example:
0 0 1 1,4,7,10 * /path/to/archive-create-script
The actual “archive-create-script” will also need logic in it to determine the quarter it was run
and formatting logic to provide the correct syntax for SUSE Manager channel cloning, etc. The
script should also loop through each architecture and SLES version in order to make a full set
of archives based on the company’s choices.
Processes for patch promotion will be created so that administrators can precisely and explicitly
define when a patch set is moved INTO a given landscape, and just as importantly - from WHERE.
The easiest method to do this is using a script that leverages the XMLRPC API exposed in SUSE
Manager. The API contains a softwareChannel method called mergePackages and mergeErrata.
These two methods can be called with a source channel and target channel to quickly take
content from one channel and merge the differences into another.
47
Automation and Process Design
SUSE Manager 3
The last process will define a workflow for removing a patch from the promotion process - and
making sure it is stored to be tracked. These patch exceptions can later be reintroduced to a
patch rollout calendar as the reason for the exception is remediated. In addition to the exception
process of REMOVING a patch, there is a similar process for ADDING a patch as an emergency
dictates.
Emergency patches will likely always be available in the current SUSE Updates channels, but
might not have been introduced into an Archive channel yet. As the quarterly archive channel
creation job is triggered, any available patches would be part of an archive set - but for a given
point in time, this might have occurred before the patch was released - or it may be up to 3
months until a new archive is created that contains this recent patch. A method for searching
and then copying a patch into a target channel will need to be created. This will handle those
times when a critical patch is released by SUSE but your archive channel won’t get a copy until
the quarter is up.
Copying these emergency patches into place doesn’t affect the normal deployments or creation
of archive channels. The next archive channel creation will also contain this patch, and the use
of an emergency patch channel with a duplicate patch (in the case of merging the same patch
later) will not cause any conflicts with a system that already has installed it.
For more information see also: Section 7.9, “Exception and Escalation Channels”
7.8 Patch Promotion Cycle
Understanding how patches (and the packages they include) are obtained from SUSE, where
they go after download, and how they are arranged within SUSE Manager is key to setting
up the Advanced Patch Lifecycle system. By default, SUSE Manager arranges its channel sets
by a particular version and architecture of SUSE Linux Enterprise Server and its add-ons or
extensions.
For example, a base set of channels within SUSE Manager for SLES 11 SP3 x86_64 includes the
parent or base channel called a “pool” channel. This channel contains packages that are the
functional equivalent of the installation DVD for SLES 11 SP3 64-bit. Under this pool channel
are all of the “child” channels which include a channel for the SUSE Manager Client packages,
called SUSE Manager Tools channel, and an updates channel called in this case, SLES 11 SP3
Updates for x86_64.
48
Patch Promotion Cycle
SUSE Manager 3
A normal set of channels that a managed host subscribes to will include at least a parent channel
(pool), a SUSE Manager Tools channel, and an Updates channel. In some cases like SLES 11 SP2
- this will include the SLES 11 SP1 Pool, the SP1 Updates channel, the SP2 Core channel, SP2
Updates, SP2 Extension Store and the SP2 SUSE Manager Tools channel.
Note: Long Term Service Pack Support (LTSS)
Due to SP1 and SP2 both being in their LTSS (Long Term Service and Support) phase,
there are no longer any non-LTSS updates being created from SUSE. This means that
any SP1 or SP2 hosts a company might have will need to purchase LTSS and use LTSS
Updates channels in order to receive further patches and support. For more information
see: www.suse.com/lifecycle
FIGURE 7.1: PATCH PROMOTION PROCESS
49
Patch Promotion Cycle
SUSE Manager 3
7.9 Exception and Escalation Channels
There might be several reasons to delay or remove a patch from a deployment cycle. A patch
could be causing issues with the stability of a system or systems, it might not have passed a
testing cycle from the current or previous landscape, or there could be some other reason not
to deploy it within a patch cycle.
On the other hand, there might be a reason to deploy a critical patch (one that patches a security
vulnerability or a debilitating bug) ahead of schedule. Due to the critical nature of the patch it
needs to go through testing and deployment as fast as possible - without waiting for the next
quarterly patch cycle.
In order to handle the periodic removal or addition of these exception patches, processes should
be created to track them appropriately. While these exceptions are being tracked, they will be
copied into their own channel containers for safe-keeping, accounting and reporting.
These channels can be created within the Archive base channel or within the cloned base channel
for the version of SLES that corresponds to the patch exception (recommended).
The process for excluding a patch will be to first copy the patch (and associated packages) into
the Exception Channel, and then to remove the patch (and associated packages) from the current
deployment landscape. Optionally it can be removed from the current quarter’s archive channel
but it is important to realize that the patch will be included in the following quarter’s archive
as well. It might be tempting to remove it from the SUSE Updates channel, but this can often
lead to a mishandling or misreporting of compliance. It is much better to track and resolve the
reasons for the exception in the first place. This way, the patch can be reintroduced to the patch
deployment workflow and remediate any potential security issues or code flaws that the patch
was created to fix.
Security Escalation Channel and Process. The process for adding a security patch is similar to
the process of excluding one. The key difference is that the patch needs to be copied into the
Security Exception Channel from either the SUSE Updates channel or the latest archive if it has
been created but not used for a promotion cycle yet. Assuming that this new critical security
patch has been released in the middle of a rollout phase (you have already been promoting the
current quarter’s patches and this new one comes out), it is likely that this new patch has not
yet appeared in an archive.
Another assumption is the need to test this new patch by promoting it through the landscapes
as any normal patch set, but if necessary it can be copied directly to any stage. Simply copy
this security patch into the initial landscape (e.g. DEV - Current) and follow the normal deploy-
50
Exception and Escalation Channels
SUSE Manager 3
test-promote cycles to get it into production. Depending on the critical nature of the patch, the
normal schedule for testing could be accelerated or in rare cases bypassed altogether assuming
acceptable risk.
7.10 Components to be Created
The following list provides an overview on what you will be creating to enable Advanced Patch
Lifecycle Management:
CHANNELS
Archive channels
Current updates channels
Exception channels (patch exclusions or security-ASAP)
Optional SP-Migration clone set
ACTIVATION KEYS AND BOOTSTRAP SCRIPTS
Per-Organization, Per-SLES version activation keys
SCRIPTS
Archive creation script
Archive sources list control file
Merge Tool python script
CRONTAB ENTRIES AND AUTOMATION
Quarterly (or any other frequency) archive creation call
7.11 Channels
Several custom channels will be created to support the patch promotion process. These channels
will store the archives (created as clones of the SUSE Updates channels) and they will also store
exception patches. For each landscape a custom channel will be created to hold patches which
have been promoted. These channels will grow in size over time as patches are promoted each
cycle.
51
Components to be Created
SUSE Manager 3
Each new patch cycle updates the available patches in a given landscape’s “current updates”
channel. In this way each subsequent patch promotion adds the new updates and these can be
applied to any hosts subscribed to the channel.
The exception channels will be populated by managing individual patches, copying them from
one of the landscape updates channels or from one of the archive channels. Once a patch is
copied successfully into an exception channel, it can be removed from an updates channel or
an archive.
7.11.1
Creating Archive Channels
Custom channels are created in SUSE Manager as “new”, blank and empty channels, or “clones”.
Technically, cloned channels can also be created as empty, but in this case we will create the
archive channels with content sourced from the SUSE Updates channel, the patches and the
packages they reference.
Each archive channel will reside within an empty base channel. Base channels will be created
for each processor architecture managed by SUSE Manager, for example:
IA-32
x86_64
s390x
PPC
Multiple archives matching the different versions of SLES may exist in the base channel, but
they will all be of the same processor architecture.
Important: Channel Naming
Failing to label the following channels appropriately will cause the example archive script
to fail unless modified.
Note: Note on Base/Parent Channels
The archive channels you are creating have no parent because they are parent/base
channels.
52
SUSE Manager 3
PROCEDURE 7.1: CREATE THE BASE ARCHIVE CHANNELS
1. For each processor architecture used by hosts which are managed by SUSE Manager, create
empty channels named: 32 Bit Archives Channel and 64 Bit Archives Channel
2. In the Web UI click Channels Manage Software Channels then click the + Create Channel
button.
3. The channel label must be in the format of architecture-patch-archives-channel ,
for example the 64-bit channel label should be:
x86_64-patch-archives-channel
4. Select the appropriate architecture for this channel - x86_64 for 64-bit, and IA-32 for 32-
bit, etc.
5. Under the Channel Access Control heading select the radio button with the description:
This channel is public and may be accessed by any of the trusted organizations trusted
by this organization.
6. Repeat this procedure for each architecture type of SLES you need deployed
The following procedure will guide you through creating clone channels for each version of
SUSE Linux Enterprise being used.
PROCEDURE 7.2: CREATING THE CLONED ARCHIVED CHANNELS
1. From the WebUI click Channels Manage Software Channels then click the Clone Channel
button.
2. Select the SUSE vendor channel of the SLES version you need to create and use for your
update archive source.
3. Select the radio button for all content/patches
4. Name the channel appropriately with an indication of Time/Date and what the archive
contains e.g. Q3 - 09-30-2015 - Archive of SLES 11 SP3 for x86_64
5. Create a label using proper syntax - e.g. “q3-09-30-2015-archive-sles11sp3-x86_64”
6. Include an appropriate description of the channel in the Summary and Description fields
53
SUSE Manager 3
7. Click the Create Channel button when finished
8. Scroll down and select the Public radio button and then click the Update Channel button.
Repeat this process for each version of SLES within architecture.
Note: spacewalk-clone-by-date
You can Use spacewalk-clone-by-date to create archive channels from the past. See: for
an example source file that can be used with the spacewalk-clone-by-date utility. This
configuration file can be used to create a clone channel with a certain date range as a
filter for the content in the channel:
The utility is called with the following syntax: spacewalk-clone-by-date -c <config
file>
Repeat for each archive channel with a past date modifying the configuration files
to match the appropriate dates and channel source/target names.
7.11.2 Service Pack Migration Support with Update and
Exception Channels
There are a couple of generally accepted methods to managing a set of channels that allows
consistent and expected behaviors when leveraging the SP Migration feature. You can find this
feature in the Software tab of a particular host - it allows you to update the service pack of a
particular host in a one-click fashion.
When using the patch lifecycle methods described in this document, some challenges arise when
using the SP Migration feature. When you select a given host to do an SP Migration, the UI
proposes (dictates) a set of mandatory “child” channels that will be subscribed to for a migration
action. These mandatory child channels (greyed-out in the UI) will normally include the SUSE
provided Updates channel for a given SLES version. See the following image
54
Service Pack Migration Support with Update and Exception Channels
SUSE Manager 3
FIGURE 7.2: SERVICE PACK MIGRATION SUPPORT WITH UPDATE AND EXCEPTION CHANNELS
In order to allow usage of the patch lifecycle processes described here AND to use the
functionality of SP Migrations, it is best to create a full clone-set of the SUSE Linux Enterprise
product versions in use at your company. This is sometimes called a clone-tree, and can be easily
created using the spacecmd command, softwarechannel_clonetree .
A full clonetree will include the base/parent channel (normally called a pool) and all child
channels that currently exist beneath it. For example, using the SLES 11 SP3 Pool x86_64
channel as a source, you provide your own prefix to the clonetree command and it will make
a copy of the pool and all children adding the prefix to the beginning of all the channel names
and labels.
The following figure provides an example of the SUSE Linux Enterprise 11 SP3 x86_64 channels
and the cloned tree with prefix Chameleon_Co .
55
SUSE Manager 3
FIGURE 7.3: EXAMPLE CHAMELEON_CO CHANNELS
The command spacecmd softwarechannel_clonetree can be called directly by providing the
source and prefix information directly or interactively by calling the command from within the
spacecmd shell itself:
spacecmd -u SMadmin -- softwarechannel_clonetree sles11-sp3-pool-x86_64 -p
“my_company-“
This will create a set of SLES 11 SP3 x86_64 channels with a prefix (my_company).
Repeat this process for each SLES version and then when using the Service Pack migration
feature you may select your company version of the target SLES version and choose the child
channels appropriate for the landscape the host is in (described below).
You can then modify the cloned Updates channel by removing all patches/packages - then use
the merge script process to merge your “Current Patch Set” into the mandatory updates channel.
This way you are able to do Service Pack Migrations and still retain your currently promoted
patch set. Otherwise, SP Migrations will always update to whatever is the latest packages in the
“mandatory” Updates child channel.
56
SUSE Manager 3
Consider the following Image that shows the Q3 Patch Archive for SLES 11 SP4 with 227
packages, the SUSE Updates channel for SP4 with 234 packages, and the Chameleon_Co version
of SP4 Updates with 0 (zero) packages:
FIGURE 7.4: PATCH ARCHIVE AND UPDATE CHANNELS
In the following sections we will describe the creation of custom Current Updates channels
and how to use a Merge script (also detailed below). For SP migrations using your own set
of promoted patches, you would merge a Current Patch Archive from a Production channel
into the Updates channel so it will be used for migration efforts or simply leave the Updates
channel permanantly empty and add your Current Updates channel to the Optional Child Channels
selection.
With an empty Updates channel and a populated “Current Updates”, you can be assured of an
SP Migration working as expected and not patching the machine to a version of packages more
current than whatever is deemed “production.” The custom “updates” channels and the merge
script process will be described in detail in the following sections.
7.11.3
Current-Updates Channels
Now create the current updates channels that managed hosts will subscribe to depending on their
landscape, for example, DEV - Current Updates for SLES 11 SP3 x86_64, or PROD - Current Updates
- for SLES 12 x86_64. There will be a full set of landscape channels for each SLES version and
they will all be empty to begin with so we will create a “new” and then optionally “clone” that
one to reduce the amount of typing needed:
PROCEDURE 7.3: CREATING THE CURRENT UPDATES CHANNELS
1. From the Channels Manage Software Channels click +Create Channel.
57
Current-Updates Channels
SUSE Manager 3
2. Create the channel within one of the SLES Pool Channels or within your own clone set
pool.
3. Modify the channel to be Public.
4. Clone this new channel (without updates) into the remaining Landscapes. Each channel
as a Current Updates channel, and each with the appropriate landscape prefix (e.g. DEV,
TEST, PROD , etc.)
FIGURE 7.5: UPDATES CHANNELS
This procedure guided you through creating a full set of landscapes for each SLES version to be
managed. Keep in mind for the SLES 11 SP1 and SP2 channels this will result in a full set 2x
or even 4x with LTSS. However, SP1 and SP2 Update channels are no longer updated so these
could be subscribed as static channels.
7.11.4
Exception Channels
Now create the 2 exception channels for each SLES version being managed. While it may be
possible to create a mixed channel that is unique to architecture (like the archive channel base),
tracking which distribution a patch exception has come from can get cumbersome. If you mix
patches/packages from different versions of SLES, it is more difficult to track, resolve and then
58
Exception Channels
SUSE Manager 3
reintroduce these patches back into the patch workflow. It is much easier to place them into an
exceptions channel specifically for the version of SLES the patch came from. Create the Patch
Exception and Security ASAP Exception channels as follows:
Note: Exceptions Channel Subscription
It is recommended to add the text DO NOT SUBSCRIBE to the Patch Exceptions Channel
Name field during creation. Keep in mind that this channel is used only as a bucket to
track patches/packages that will not be installed on a system. If systems subscribe to
this channel they will see available content and therefore potentially apply it during a
patch installation. The DO NOT SUBSCRIBE text acts as a visual reminder when creating
activation keys or manipulating a hosts channel subscriptions preventing you from adding
it to a hosts active channels.
PROCEDURE 7.4: CREATING EXCEPTION CHANNELS
1. From the Channels Manage Software Channels click +Create Channel.
2. Create the “Patch Exceptions - DO NOT SUBSCRIBE” channel within one of the SLES Pool
Channels or if you have your own clone set within that pool. This channel will reside next
to your Landscape channels.
3. Modify the channel to be Public.
4. Create the Security ASAP Exception channel as above - it too will reside next to your
Landscape and Patch Exceptions channels.
Keep in mind for SLES 11 SP1 and SP2 - they reside in the same SP1 Pool base channel, so there
will be Exceptions and Security Exceptions Channels for each Service Pack.
59
Exception Channels
SUSE Manager 3
FIGURE 7.6: EXCEPTION CHANNELS
7.12 Activation Keys and Bootstrapping
Normally you should create a set of Activation Keys each assigned to a specific version of SLES
that your hosts are installed with. There may be other characteristics assigned in your keys
like System Groups, assorted Child Channels, Software Packages, etc. You may also choose
to modify your existing Activation Keys and reuse them, or you can create new keys for this
implementation. This example assumes a new key.
PROCEDURE 7.5: ACTIVATION KEY SETUP
1. From the Systems Activation Keys click +Create Key.
2. Create the Activation Key within this Organization (remember to log into other
Organizations to create keys there if needed). Assign the appropriate Entitlements and
Software Packages and Configuration Channels as appropriate.
3. Name the Activation Key according to the Landscape host will register to with this key.
For example:
60
Activation Keys and Bootstrapping
SUSE Manager 3
FIGURE 7.7: CREATE ACTIVATION KEY
4. Click on the Child Channels Tab and assign the appropriate Current Updates channel to
the Landscape this key will be used for:
61
SUSE Manager 3
62
SUSE Manager 3
5. Select the appropriate SUSE Manager Tools channel as well as the other needed channels
to fill out the requirements for the version of SLES in question.
Note: Security ASAP Exceptions
The Security ASAP Exceptions channel is selected as an active child channel, and the
Patch Exceptions (DO NOT SUBSCRIBE) channel is NOT selected. This is important as any
patch/package copied into the Patch Exceptions channel should remain invisible to hosts
while patches/packages copied to the Security ASAP Exceptions channel should always
be immediately visible to a host.
The Activation Key is called by a bootstrap script, often there is a one-to-one relationship
between a registration bootstrap script and an activation key. Whether new activation keys
were created or existing ones were modified to point to the landscape specific “current updates”
channels, there should be a bootstrap script that calls that activation key.
All new hosts will use these bootstraps to register and become managed by SUSE Manager. One
of the key benefits is that they should never need to change their channel assignments as the
host will now be assigned to its proper landscape update channels and will receive new updates
as they are promoted each patch cycle.
7.13 Scripts
7.13.1
Patch/Package Merge Script
The Patch/Package Merge Script is used to Promote patches (and relevant packages) from one
channel to another. It is used at first to merge content from an Archive channel into the first
stage (landscape) e.g. DEV. It is then used to promote content from one stage to the next until
the content reaches the final stage. This process is then repeated for each version of SLES (like
11 SP1, SP2, etc.) and each corporate environment (like STORE, CORP, etc.).
Finally, the entire process is repeated for each patch calendar cycle (quarterly/monthly/etc.).
63
Scripts
SUSE Manager 3
7.13.2 Channel Archive Creation Script / Channel Archive
Sources List Config File
This script and its associated “sources list” configuration file are called either manually or by
a crontab entry. The script uses the sources list file to determine which versions of SLES and
which architectures to create archives for. As previously described, the Archive Channels are
created as point-in-time clones of the various SLES Updates channels.
To have the correct archive channels created, add lines to the sources file. Each line has 3 fields,
the first being the architecture, the second is the source channel, and the third is target channel
text. The script parses the source list and constructs the target parent channel for the archives
by architecture, and then constructs the target channel and label, etc.
The
script
calls
the
spacecmd
functions
softwarechannel_clone
and
softwarechannel_setorgaccess for each entry in the sources list. It then calculates the
current calendar quarter, creates the archives and makes these archives publicly visible. See the
Appendix for the entire script.
7.14 Crontab Entries and Automation
A decision needs to be made whether a calendar quarter is going to be created (looking
backwards) at the end of a particular month, or at the beginning of a month (one day past
the final day of a quarter). Since the Archive Channels are being created by cloning the SUSE
Updates channels of a particular SLES version, the decision can affect the content.
Either way is fine as it will be consistent from quarter to quarter. For the purposes of explaining
the cron syntax, we will opt to show the more difficult of the two how to call the archive script
at the end of the quarter. This is more difficult because it requires two cron entries to handle
both the 30th of the month (for June and September), and the 31st of the month (for March
and December).
The crontab entries will point to the archive creation script and execute in months 3, 6, 9 and
12. Here are what the cron entries look like:
0 0 30 6,9 * /path_to/the/archive/script
The path will point to the actual archive-channel-create-script.sh (or similar). This could be
placed in /usr/sbin/ and must be made executable chmod +x
Channel Archive Creation Script / Channel Archive Sources List Config File
64
SUSE
Manager 3
Also it is very important to note that this script in calling spacecmd commands from within
a bash shell script. Spacecmd is itself a python-based shell that can be invoked - allowing the
use of an extensive set of commands within the shell, or from outside the shell as a mediated
command interpreter.
The invocation of spacecmd stores a .spacecmd directory in the users home directory. Within
the .spacecmd directory is a config file which can store credential sets that can be leveraged in
order to keep from being prompted at spacecmd execution. This can be used to store credentials
so the cron job will execute and not pause waiting for authentication credentials to be passed.
Edit the /root/.spacecmd/ config file and add the appropriate credentials:
[spacecmd]
server=localhost
username=admin
password=suse1234
nossl=0
Storing these credentials will allow spacecmd operations from the SUSE Manager’s root user to
be executed without the need to pass a username or password allowing the cron job for archive
creation to run without failure at the appropriate time.
7.15 Use Cases and Workflows
This section describes an approach to patch lifecycle management that leverages SUSE Manager
to allow deliverance of the following benefits:
Automated creation of Patch Archive Channels
These channels can be created on a quarterly (or more frequent) basis and allows
an organization to create test environments based on a historical set of patches (i.e.
creation of a lab using available patches from 2 calendar quarters ago.)
Leverage a static set of “current” update channels so host subscriptions don’t have to
change
65
Use Cases and Workflows
SUSE Manager 3
Using the API/scripts, updates can be merged from a patch “archive” into a
subscribed host channel removing the need to constantly clone and re-clone channels
and modify host subscriptions
Multi-Landscape environments can use a promotion process to merge updates
through each phase during testing/validation of patch sets
Exception handling for patches that need to be excluded from a patch roll-out
Creation of a “patch exceptions” channel and a process for copying patches/packages
into that channel (and then removing them from an updates channel) allows for
tracking of patch exception. This channel should be excluded from any hosts
channel subscriptions, thereby keeping all patch/package content from being visible/
available for installation.
Patch exceptions “processes” must be developed in order to track remediation of all
exceptions in order to avoid future complications from managing an ever-growing
bucket of patches.
Security ASAP Exceptions handling for patches that need to roll out with a higher priority
The security ASAP exception channel should always be subscribed to (unlike the
“patch exceptions channel). Subscription to this channel allows a host to obtain
patches/packages added in an ad-hoc manner, for example a security patch deemed
important enough to deploy outside of a normal patch schedule. This could be copied
from a new archive or directly from one of the SUSE (vendor) updates channels.
7.15.1
Workflow 1: Patch Promotion Process
The following sections provide some example workflows for the patch promotion and exception
processes. Keep in mind that these can be modified to fit more closely to a particular operational
group’s existing set of processes.
Review the Patch Promotion Process in the following table.
66
Workflow 1: Patch Promotion Process
SUSE Manager 3
FIGURE 7.9: WORKFLOW 1: PATCH PROMOTION PROCESS
7.15.2
Workflow 2: Patch Exception Process
Reveiwed the Patch Exception Process in the following table. Again, keep in mind that these can
be modified to fit more closely with your particular operational group’s existing set of processes.
67
Workflow 2: Patch Exception Process
SUSE Manager 3
FIGURE 7.10: WORKFLOW 2: PATCH EXCEPTION PROCESS
7.15.3
Workflow 3: Security ASAP Exceptions Process
The Security exception process differs from the previous patch exception process in that a patch
is now being added into a patch rollout cycle, likely in the middle of a current (in-progress)
rollout. A process table is included here as well as some images from the SUSE Manager WebUI
to provide clarity.
68
SUSE Manager 3
FIGURE 7.11: WORKFLOW 3: SECURITY PATCH ASAP PROCESS
69
SUSE Manager 3
The following image provides and overview of adding a patch to the Security ASAP Exceptions
Channel, specifically the SLES 11 SP1 x86_64 version:
FIGURE 7.12: SECURITY ASAP EXCEPTIONS
The following image provides a view of the List/Remove function of a specific channel (in this
case, DEV - Current - SLES11-SP1-LTSS-Updates for x86_64 and is the interface where a
patch would be removed from a channel to keep it from being visible and potentially deployed
as part of an exception process.
70
SUSE Manager 3
FIGURE 7.13: PATCHES LIST/REMOVE
7.16 Sample Scripts
This section contains scripts which will be useful for Advanced Patch Lifecycle Management.
7.16.1
Sample Spacewalk-Clone-By-Date Configuration
This sample is stored as a text-file. It is used with the spacewalk-clone-by-date utility by using
the -c flag to indicate an input config file:
spacewalk-clone-by-date -c Q3-2015-sles11sp3-x86_64-archive.conf
71
Sample Scripts
SUSE Manager 3
This sample, below is using the SUSE Manager administrator account name of SMadmin but can
be changed to meet the requirements of your installation. The config file is using an end-date
of 9/30/2015 and a source of the SLES 11 SP3 Updates for x86_64 and creating a clone inside
the cc_patch_archives_channel_64bit base channel. The end result is a 3 Quarter patch archive
that filters all available patches for SLES 11 SP3 64-bit, up to the date of 9/30/2015.
Note: Base Channel Source/Target Channel/ Directive
This specifies the following:
Base channel source: sles11-sp3-pool-x86_64
The target base channel: cc_patch_archives_channel_64bit
Uses directive: existing-parent-do-not- modify
true
This tells the utility that a child channel from one base will be cloned into a completely
different base channel. Your channel names may differ therefore this example may need
modifications to work in your tests.
The following is an example from the Q3-2015-sles11sp3-x86_64-archive.conf .
{
"username":"SMadmin",
"to_date": "2015-09-30",
"skip_depsolve":false,
"security_only":false,
"use_update_date":false,
"no_errata_sync":false,
"dry_run":false,
"channels":[
{
"sles11-sp3-pool-x86_64": {
"label": "cc_patch_archives_channel_64bit",
"existing-parent-do-not-modify": true
},
"sles11-sp3-updates-x86_64": {
"label": "09_30_2015_q3_archive-sles11-sp3-updates-x86_64",
72
Sample Spacewalk-Clone-By-Date Configuration
SUSE Manager 3
"name": "Q3-2015 Patch Archive - 09-30-2015 - SLES11-SP3-Updates for
x86_64",
"summary": "Q3 - 2015 - Patch Archive Set (9-30-2015) - SUSE Linux
Enterprise
Server 11 SP3 x86_64",
"description": "Q3 - 2015 - Patch Archive Set (9-30-2015) - SUSE Linux
Enterprise
Server 11 SP3 x86_64"
}
}
]
}
Important: spacewalk-clone-by-date Utility Post Checks
When using the spacewalk-clone-by-date utility please review the channel patch
content after creation to ensure that the channel contains the patches for the appropriate
end-date. Sometimes extra patches are included in the channel that are in the wrong
time-period and these may be deleted manually.
7.16.2
Sample Patch/Package Merge Script Using Python
This script has a defined SUSE Manager server URL set in the “MANAGER_URL” variable. The
script prompts for a SUSE Manager Administrator ID and password. It then asks for a source
and target channel. The script will then confirm the channels and ask if it should continue. An
affirmative response (Y) will then allow the script to merge the patches and packages from the
source channel into the target channel.
#!/usr/bin/python
import xmlrpclib
import sys
import getpass
MANAGER_URL = "https://suma01.chameleoncorp.com/rpc/api"
MANAGER_LOGIN = raw_input("Please Enter the SUSE Manager Login Name: ")
MANAGER_PASSWORD = getpass.getpass("Please Enter the Password: ")
73
SUSE Manager 3
MERGE_SOURCE = raw_input("Enter the SOURCE channel label to Merge FROM: ")
MERGE_TARGET = raw_input("Enter the TARGET channel label to Merge INTO: ")
print("This tool is going to take all packages and errata from the SOURCE")
print("Channel : " + MERGE_SOURCE)
print("and merge it into the TARGET ")
print("Channel : " + MERGE_TARGET)
def query_yes_no(question, default="yes"):
"""Ask a yes/no question via raw_input() and return their answer.
"question" is a string that is presented to the user.
"default" is the presumed answer if the user just hits (Enter).
It must be "yes" (the default), "no" or None (meaning
an answer is required of the user).
The "answer" return value is True for "yes" or False for "no".
"""
valid = {"yes": True, "y": True, "ye": True,
"no": False, "n": False}
if default is None:
prompt = " [y/n] "
elif default == "yes":
prompt = " [Y/n] "
elif default == "no":
prompt = " [y/N] "
else:
raise ValueError("invalid default answer: '%s'" % default)
while True:
sys.stdout.write(question + prompt)
choice = raw_input().lower()
if default is not None and choice == '':
return valid[default]
elif choice in valid:
return valid[choice]
else:
74
SUSE Manager 3
sys.stdout.write("Please respond with 'yes' or 'no' "
"(or 'y' or 'n').\n")
query_yes_no("Is this information correct?")
client = xmlrpclib.Server(MANAGER_URL, verbose=0)
key = client.auth.login(MANAGER_LOGIN, MANAGER_PASSWORD)
client.channel.software.mergePackages(key, MERGE_SOURCE, MERGE_TARGET)
client.channel.software.mergeErrata(key, MERGE_SOURCE, MERGE_TARGET)
client.auth.logout(key)
7.16.3 Sample Crontab Entries for Automation and Archive
Channel Creation
Below are some sample cron entries that can be used to run the Archive Channel Creation Script
resulting in channel creation for each quarter. This example has two entries in order to clone
all patches received up until the end of a quarter. A single entry could be used to create it at
the beginning of a quarter, but care must be taken to modify the calculations in the Archive
Script to account for that. Currently the example Archive Channel Creation Script below figures
out what quarter it is by looking at the current date. Running the script in the 4 th quarter will
name the archive created as a 4 th quarter archive.
Cron entries for end-of-quarter (e.g. 30th of months June and Sept. and 31st of months March
and December):
7.16.4
Sample Archive Channel Creation Script
The script below works with the Archive Channel Sources file (next appendix item) to create
quarterly archives of the SUSE Updates channels. This example script is written in BASH but
calls spacecmd to accomplish the cloning and setting the new archive to be public (accessible
to other organizations).
75
Sample Crontab Entries for Automation and Archive Channel Creation
SUSE Manager 3
The script takes some time to run - as the clone command finishes quickly, but the actual cloned
channel still takes some time to settle down before the org-access command can access/finish.
So if you want to test this manually - you must be patient. A normal cron-type run of the script
will finish in due-time.
#!/bin/bash
####################################################################
#
#
#
SUMa Archive Channel Creation Script - Called from Cron
#
#
#
####################################################################
#
#
#
This script creates quarterly archives of SUSE Manager
#
#
channels from SUSE Updates channels. It takes a list
#
#
of source channels from the archive-sources.lst file
#
#
that should be located in the same directory as this
#
#
script. Each entry in that file will be used as a
#
#
source channel to create an archive for patches/updates
#
#
in the appropriate archive channel.
#
#
#
#
REQUIRES:
#
#
1. cron entries for each quarter:
#
#
eg. 30th of months June and Sept. and 31st of months
#
#
March and December:
#
#
0 0 30 6,9 * /path/to/this/script
#
#
0 0 31 3,12 * /path/to/this/script
#
#
#
#
2. archive-sources.lst:
#
#
A list of the architecture, the source updates channel
#
#
for each distro and the suffix of the target channel
#
#
version and architecture (1 per line - no line-feed at EOF)
#
#
EXAMPLE:
#
#
S390x,sles11-sp3-updates-s390x,SLES11-SP3-Updates for s390x
#
#
ppc64,sles11-sp4-updates-ppc64,SLES11-SP4-Updates for PPC
#
#
x86_64,sles11-sp3-updates-x86_64,SLES11-SP3-Updates for x86_64
#
76
SUSE Manager 3
#
#
####################################################################
#
#
#
Created by - Jeff Price, SUSE Consulting - 2015
#
#
#
####################################################################
## date strings
month=`date +%m`
year=`date +%Y`
fdate=`date +%m-%d-%Y`
## set quarter
if [ $month -le 3 ]
then
quar=1
elif [ $month -gt 3 ] && [ $month -lt 7 ]
then
quar=2
elif [ $month -gt 6 ] && [ $month -lt 10 ]
then
quar=3
elif [ $month -gt 9 ]
then
quar=4
fi
## Create archives using source list
while read line
do
arch=ècho "$line" | awk -F, '{print $1}'`
src_ch=ècho "$line" | awk -F, '{print $2}'`
trg_ch=ècho "$line" | awk -F, '{print $3}'`
## set archive channel
77
SUSE Manager 3
target_parent=$arch"-patch-archives-channel"
source_channel=$src_ch
target_channel_name="Q"$quar" "$year" - "$fdate" - Archive of "$trg_ch
target_summary="Q"$quar"-"$year" Archive Set "$trg_ch
target_channel_label="q"$quar"-"$year"-archive-"$src_ch
## Debug Output
echo "Architecture: " $arch
echo "Source Channel: "$src_ch
echo "Target Channel Archive Suffix: "$trg_ch
echo "Target Archive Parent Channel: "$target_parent
echo "Source Channel (again): "$source_channel
echo "Target Channel Name: "$target_channel_name
lctn=ècho $target_channel_name|tr '[:upper:]' '[:lower:]'`
echo "lowercase target name: "$lctn
echo "Target Channel Label: "$target_channel_label
echo "Target Channel Summary and Description: "$target_summary
/usr/bin/spacecmd -d -- softwarechannel_clone -s “‘$src_ch’” -n
“‘$target_channel_name’” -l “‘$target_channel_label’” -p “‘$target_parent’” -g
/usr/bin/spacecmd -d -- softwarechannel_setorgaccess
“‘$target_channel_label’” -e
done < ./archive-sources.lst
7.16.5
Sample Archive Channel Sources List File
This file is called/used by the Archive Channel Creation Script located above in the previous
section. Since the function “readline” is used, there should only be lines with data in the file.
Any blank lines will be sourced as data and will cause errors with the Archive Channel Creation
script above.
The fields are:
78
SUSE Manager 3
Architecture - which defines the source parent archive channel. This is where the new
archive will be placed as a child channel.
Source Channel Label - This defines Where patches/packages are coming from.
Target channel Naming - the text that makes up the channel name and part of the channel
summary/description fields.
s390x, sles11-sp3-updates-s390x,SLES11-SP3-Updates
x86_64, sles11-sp4-updates-x86_64,SLES11-SP4-Updates
i586, sles11-sp3-updates-x86_64,SLES11-SP3-Updates
This concludes the Advanced Patch Lifecycle Managment chapter of this guide.
79
SUSE Manager 3
8 SUSE Manager Migration from 2.1 to 3
8.1 Introduction
The migration from SUSE Manager 2.1 to SUSE Manager 3 works quite the same as a migration
from Red Hat Satellite to SUSE Manager. There is NO in-place migration! The migration happens
from the original machine to a new one. While this has the drawback that you temporarily need
two machines, it also has the advantage that the original machine will remain fully functional
in case something goes wrong. The whole process may be tricky, so it is strongly advised that
the migration is done by an experienced consultant. Given the complexity of the product, the
migration is an "all-or-nothing", this means if something goes wrong you will need to start all
over. Error handling is very limited. Nevertheless it should work more or less out of the box
if all the steps are carefully executed as documented. Please note that the migration involves
dumping the whole database on the source machine and restoring it on the target machine. This
is a very time-consuming process! Also all of the channels and packages need to be copied to
the new machine, so expect the whole migration to take several hours!
8.2 Prerequisites
Warning: Latest Updates
The source machine needs to run SUSE Manager 2.1 with all the latest updates applied!
Before trying to migrate, please make sure that the machine is up to date and all updates
have been installed !
Only machines running with the embedded postgresql database may be migrated. For the
migration of an Oracle based installation, a two-step migration is required: First the installation
needs to get migrated from Oracle to postgresql (by means of a separate tool) and afterwards
the migration to SUSE Manager 3 can be performed as documented here. As SUSE Manager 3
does no longer support NCC but only SCC, you can migrate a machine only after it has been
switched to SCC. The migration script will check if the installation has already been switched to
SCC and will terminate if this is not the case. Switch to SCC on the source machine and repeat
the migration. During migration the database from the source machine needs to get dumped
80
SUSE Manager Migration from 2.1 to 3
SUSE Manager 3
and this dump needs to be temporarily stored on the target system. The dump gets compressed
with gzip using the default compression options (maximum compression only yields about 10%
of space savings but costs a lot of runtime); so check the disk usage of the database with:
du -sch /var/lib/pgsql/data
This will ensure that you have at least 30% of this value available in /var/spacewalk/tmp .
These values from a test migration should aid in illustrating space requirements:
f204:/var/lib/pgsql # du -sch data
1,8G
data
1,8G
total
f204:/var/spacewalk/packages # l -h /tmp/susemanager.dmp.gz
-rw-r--r-- 1 root root 506M Jan 12 14:58 /tmp/susemanager.dmp.gz
This is a small test installation; for bigger installations the ratio might be better (space required
for the database dump might be less than 30%). The dump will be written to the directory /
var/spacewalk/tmp , the directory will be created if it does not exist yet. If you want the dump
to be stored somewhere else, change the definition of the variable $TMPDIR on the beginning
of the script to suit your needs.
8.3 Setup the Target Machine
PROCEDURE 8.1: SETUP TARGET MACHINE
1. After the target system has been installed with SLE12SP1 including the add-on product
"SUSE Manager", run yast2 susemanager_setup as you would normally do for an
installation of SUSE Manager.
2. On the first installation screen, ensure that Migrate a SUSE Manager compatible server is
marked instead of Set up SUSE Manager from scratch.
3. On the second screen, enter the name of the source system as Hostname of source SUSE
Manager Server as well as the domain name. Also enter the database credentials of the
source system.
81
Setup the Target Machine
SUSE Manager 3
4. On the next screen, you will need to specify the IP address of the target system. Normally
this value should be pre-set to the correct value and you only should need to press ENTER.
Only in the case of multiple IP addresses you might need to specify the one that should
be used during migration.
Important: Faking the Host Name
During the migration process, the target system will fake its host name to be the
same as the source system, this is necessary as the host name of a SUSE Manager
installation is vital and should not be changed once set. Therefore do not be
confused when logging in to your systems during migration; they both will present
you with the same hostname!
5. Continue by following the normal installation steps: Specify the database parameters
using the same database parameters as the source system is recommended. Enter your SCC
credentials. After all the data has been gathered, YaST2 will terminate.
Important: Migration Must be Manually Triggered
The actual migration will NOT start automatically but needs to be triggered
manually!
8.4 Performing the Migration
The actual migration is performed by giving the command /usr/lib/susemanager/bin/mgr-
setup -m . This will read the data gathered in the previous step, set up SUSE Manager on the
new machine and transfer all of the data from the source machine. As it needs to perform several
operations on the source machine via ssh, you will be prompted once for the root password of
the source machine. A temporary ssh key named migration-key is created and installed on the
source machine, so you need to give the root password only once. Of course the temporary ssh
key will be deleted after successful migration. Ideally, this is all you will need to do. Depending
on the size of the installation, the actual migration will take up to several hours. Once finished,
you will be prompted to shutdown the source machine, re-configure the network of the target
machine to use the same IP address and host name as the original machine and restart it. It
should now be a fully functional replacement for your previous 2.1 installation. The following
numbers illustrate the runtime for dumping and importing the database:
82
Performing the Migration
SUSE Manager 3
14:53:37
Dumping remote database to /var/spacewalk/tmp/susemanager.dmp.gz on
target system. Please wait...
14:58:14
Database successfully dumped. Size is: 506M
14:58:29
Importing database dump. Please wait...
15:05:11
Database dump successfully imported.
Dumping the database takes about five minutes to complete. The next step, importing the dump
onto the target system takes an additional seven minutes. For big installations this may take
up to several hours. Additionally you will need to account for the time it takes to copy all the
package data to the new machine. Depending on your network infrastructure and hardware,
this can also take a significant amount of time.
8.5 Speeding up the Migration
Since a lot of data needs to be copied the whole migration can consume a lot of time. The
actual migration time can be decreased by executing the most time consuming task prior to
performing the migration: The copying of all the channels, packages, auto-install images and
so on. So the following approach is recommended: Once you gathered all the data via YaST2,
run the following command: mgr-setup -r
This will copy the largest share of the data from the old server to the new one. This command
can be run at any time; during which the current server remains fully functional. Once the
actual migration has started, only the data changed since running above command needs to
be transferred which will significantly reduce downtime. On huge installations, the transfer of
the database (which involves dumping of the database on the source machine and importing
the dump on the target system) may still take quite some time. This is unavoidable as you can
only dump the entire database. During this time no write operations may happen, therefore the
migration script needs to shutdown SUSE Manager services running on the source machine.
8.6 Packages on External Storage
Some installations might store the package data on external storage (eg. NFS mount on /var/
spacewalk/packages ). In such a case it is of course pointless to have all this data copied to the
new machine. Edit the script locatd in /usr/lib/susemanager/bin/mgr-setup and remove
83
Speeding up the Migration
SUSE Manager 3
the respective rsync command (located around line 345). Ensure the storage is mounted on
the new machine before starting the system for the first time. Analogue handling for /srv/
www/htdocs/pub if appropriate .
8.7 Troubleshooting a Broken UI after Migration
Chances are you will notice a broken user interface after migration. This is not a bug, but a
browser caching issue. The new machine has the same hostname and the same IP address as
the old machine which can confuse some web browsers. If you experience this issue, perform
a forced reload of the page (in Firefox this is accomplished by pressing the key combination
CTRL
– F5 this should resume normal functionality.
8.8 Example Session
This is the output of a typical migration:
e50:~ # /usr/lib/susemanager/bin/mgr-setup -m
Filesystem type for /var/spacewalk is ext4 - ok.
Open needed firewall ports...
Migration needs to execute several commands on the remote machine.
Please enter the root password of the remote machine.
Password:
Remote machine is SUSE Manager
Remote system is already migrated to SCC. Good.
Shutting down remote spacewalk services...
Shutting down spacewalk services...
Stopping Taskomatic...
Stopped Taskomatic.
Stopping cobbler daemon: ..done
Stopping rhn-search...
Stopped rhn-search.
Stopping MonitoringScout ...
[ OK ]
Stopping Monitoring ...
84
Troubleshooting a Broken UI after Migration
SUSE Manager 3
[ OK ]
Shutting down osa-dispatcher: ..done
Shutting down httpd2 (waiting for all children to terminate) ..done
Shutting down Tomcat (/usr/share/tomcat6)
..done
Terminating jabberd processes...
Stopping router ..done
Stopping sm ..done
Stopping c2s ..done
Stopping s2s ..done
Done.
CREATE ROLE
* Loading answer file: /root/spacewalk-answers.
** Database: Setting up database connection for PostgreSQL backend.
** Database: Populating database.
** Database: Skipping database population.
* Configuring tomcat.
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
* Performing initial configuration.
* Configuring apache SSL virtual host.
** /etc/apache2/vhosts.d/vhost-ssl.conf has been backed up to vhost-ssl.confswsave
* Configuring jabberd.
* Creating SSL certificates.
** Skipping SSL certificate generation.
* Deploying configuration files.
* Setting up Cobbler..
* Setting up Salt Master.
11:26:47
Dumping remote database. Please wait...
11:26:50
Database successfully dumped.
Copy remote database dump to local machine...
Delete remote database dump...
85
11:26:50
Importing database dump. Please wait...
11:28:55
Database dump successfully imported.
Example Session
SUSE Manager 3
Schema upgrade: [susemanager-schema-2.1.50.14-3.2.devel21] -> [susemanagerschema-3.0.5-5.1.develHead]
Searching for upgrade path to: [susemanager-schema-3.0.5-5.1]
Searching for upgrade path to: [susemanager-schema-3.0.5]
Searching for upgrade path to: [susemanager-schema-3.0]
Searching for start path:
[susemanager-schema-2.1.50.14-3.2]
Searching for start path:
[susemanager-schema-2.1.50.14]
The path: [susemanager-schema-2.1.50.14] -> [susemanager-schema-2.1.50.15] ->
[susemanager-schema-2.1.51] -> [susemanager-schema-3.0]
Planning to run schema upgrade with dir '/var/log/spacewalk/schema-upgrade/schemafrom-20160112-112856'
Executing spacewalk-sql, the log is in [/var/log/spacewalk/schema-upgrade/schemafrom-20160112-112856-to-susemanager-schema-3.0.log].
(248/248) apply upgrade [schema-from-20160112-112856/99_9999-upgrade-end.sql]
e-suse-channels-to-public-channel-family.sql.postgresql]
The database schema was upgraded to version [susemanagerschema-3.0.5-5.1.develHead].
Copy files from old SUSE Manager...
receiving incremental file list
./
packages/
sent 18 bytes
received 66 bytes
total size is 0
168.00 bytes/sec
speedup is 0.00
./
RHN-ORG-TRUSTED-SSL-CERT
res.key
rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
suse-307E3D54.key
suse-39DB7C82.key
suse-9C800ACA.key
bootstrap/
bootstrap/bootstrap.sh
bootstrap/client-config-overrides.txt
bootstrap/sm-client-tools.rpm
86
Example Session
SUSE Manager 3
sent 189 bytes
received 66,701 bytes
total size is 72,427
44,593.33 bytes/sec
speedup is 1.08
./
.mtime
lock
web.ss
config/
config/distros.d/
config/images.d/
config/profiles.d/
config/repos.d/
config/systems.d/
kickstarts/
kickstarts/autoyast_sample.xml
loaders/
snippets/
triggers/
triggers/add/
triggers/add/distro/
triggers/add/distro/post/
triggers/add/distro/pre/
triggers/add/profile/
triggers/add/profile/post/
triggers/add/profile/pre/
triggers/add/repo/
triggers/add/repo/post/
triggers/add/repo/pre/
triggers/add/system/
triggers/add/system/post/
triggers/add/system/pre/
triggers/change/
triggers/delete/
triggers/delete/distro/
triggers/delete/distro/post/
87
Example Session
SUSE Manager 3
triggers/delete/distro/pre/
triggers/delete/profile/
triggers/delete/profile/post/
triggers/delete/profile/pre/
triggers/delete/repo/
triggers/delete/repo/post/
triggers/delete/repo/pre/
triggers/delete/system/
triggers/delete/system/post/
triggers/delete/system/pre/
triggers/install/
triggers/install/post/
triggers/install/pre/
triggers/sync/
triggers/sync/post/
triggers/sync/pre/
sent 262 bytes
7,416.00 bytes/sec
speedup is 19.08
kickstarts/
kickstarts/snippets/
kickstarts/snippets/default_motd
kickstarts/snippets/keep_system_id
kickstarts/snippets/post_delete_system
kickstarts/snippets/post_reactivation_key
kickstarts/snippets/redhat_register
kickstarts/snippets/sles_no_signature_checks
kickstarts/snippets/sles_register
kickstarts/snippets/sles_register_script
kickstarts/snippets/wait_for_networkmanager_script
kickstarts/upload/
kickstarts/wizard/
sent 324 bytes
88
2,774.00 bytes/sec
speedup is 8.75
Example Session
SUSE Manager 3
ssl-build/
ssl-build/RHN-ORG-PRIVATE-SSL-KEY
ssl-build/RHN-ORG-TRUSTED-SSL-CERT
ssl-build/index.txt
ssl-build/index.txt.attr
ssl-build/latest.txt
ssl-build/rhn-ca-openssl.cnf
ssl-build/rhn-ca-openssl.cnf.1
ssl-build/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
ssl-build/rhn-org-trusted-ssl-cert-1.0-1.src.rpm
ssl-build/serial
ssl-build/d248/
ssl-build/d248/latest.txt
ssl-build/d248/rhn-org-httpd-ssl-archive-d248-1.0-1.tar
ssl-build/d248/rhn-org-httpd-ssl-key-pair-d248-1.0-1.noarch.rpm
ssl-build/d248/rhn-org-httpd-ssl-key-pair-d248-1.0-1.src.rpm
ssl-build/d248/rhn-server-openssl.cnf
ssl-build/d248/server.crt
ssl-build/d248/server.csr
ssl-build/d248/server.key
ssl-build/d248/server.pem
sent 380 bytes
101,514.00 bytes/sec
speedup is 1.77
SUSE Manager Database Control. Version 1.5.2
Copyright (c) 2012 by SUSE Linux Products GmbH
INFO: Database configuration has been changed.
INFO: Wrote new general configuration. Backup as /var/lib/pgsql/data/
postgresql.2016-01-12-11-29-42.conf
INFO: Wrote new client auth configuration. Backup as /var/lib/pgsql/data/
pg_hba.2016-01-12-11-29-42.conf
INFO: New configuration has been applied.
Database is online
System check finished
89
Example Session
SUSE Manager 3
e50:~ #
============================================================================
Migration complete.
Please shut down the old SUSE Manager server now.
Reboot the new server and make sure it uses the same IP address and hostname
as the old SUSE Manager server!
============================================================================
90
Example Session
SUSE Manager 3
9 Using a Custom SSL Certificate
The following section will guide you through using a custom certificate with SUSE Manager 3
and SUSE Manager Proxy 3.
9.1 Prerequisites
A Certificate Authority SSL public certificate file
A Web server SSL private key file
A Web server SSL public certificate file
Key and Certificate files must be in PEM format
Warning: Hostname and SSL Keys
The hostname of the web server's SSL keys and relevant certificate files must match the
hostname of the machine which they will be deployed on.
After
guide;
completing
See:
the
yast
firstboot
procedures
found
in
the
installation
https://www.suse.com/documentation/suse_manager/book_susemanager_install/
data/sec_manager_inst_installation.html, it will be necessary to export the environment variables
and point them to the correct SSL files to be imported. It is important to note, running these
commands will obsolete the default certificate during yast2 susemanager_setup
1. Export the environment variables and point to the SSL files to be imported:
export CA_CERT= path to CA certificate file
export SERVER_KEY= path to web server key
export SERVER_CERT= path to web server certificate
2. Execute SUSE Manager setup with yast2 susemanager_setup . Proceed with the default
setup. Upon reaching the Certificate Setup window during yast installation, fill in random
values, as these will be overridden by the commands executed in step 1.
91
Using a Custom SSL Certificate
SUSE Manager 3
Note: Shell Requirements
Execute this command from within the same shell the environment variables were
exported from in step 1.
9.2 Using a Custom Certificate with SUSE
Manager Proxy 3
After
guide;
completing
See:
the
yast
firstboot
procedures
found
in
the
installation
https://www.suse.com/documentation/suse_manager/book_susemanager_install/
data/sec_manager_inst_installation.html Continue with the following procedure.
PROCEDURE 9.1: 1. Execute configure-proxy.sh .
2. When prompted with:
Do you want to import existing certificates?
Answer using:
y
.
3. Continue by following the script prompts.
92
Using a Custom Certificate with SUSE Manager Proxy 3
SUSE Manager 3

SUSE Manager Best Practices

Transcription

Similar documents

Calzedonia Group

Calzedonia Group

bachmaster unit 2 patches

Engineering with SUSE Linux Enterprise Server

Appriss

Patient Instructions: Nitro-Dur Patches