The following section provides SUSE Manager Proxy requirements.

Supported Client Systems. For supported clients and their requirements, see Book “Getting Started”, Chapter 1 “Introduction”, Section 1.2 “Prerequisites for Installation”, Section 1.2.5 “Supported Client Systems”.

Hardware Requirements. Hardware requirements highly depend on your usage scenario. When planning proxy environments, consider the amount of data you want to cache on your proxy. If your proxy should be a 1:1 mirror of your SUSE Manager, the same amount of disk space is required. For specific hardware requirements, see the following table.

Tip: Storage for Proxy Data

SUSE recommends storing the squid proxy caching data on a separate disk formatted with the XFS file system.

SSL Certificate Password. For installing the proxy, you need the SSL certificate password entered during the initial installation of SUSE Manager.

Network Requirements. For additional network requirements, see Book “Getting Started”, Chapter 1 “Introduction”, Section 1.2 “Prerequisites for Installation”, Section 1.2.4 “Network Requirements”.

SUSE Customer Center. For using SUSE Manager Proxy, you need an account at SUSE Customer Center (SCC) where your purchased products and product subscriptions are registered. Make sure you have the following subscriptions:

Network Time Protocol (NTP). The connection to the Web server via Secure Sockets Layer (SSL) requires correct time settings on the server, proxy and clients. For this reason, all systems must use NTP. For more information, see https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_netz_xntp.html.

Virtual Environments. The following virtual environments are supported:

For running SUSE Manager Proxy in virtual environments, use the following settings for the virtual machine (VM):

The following section will guide you through the installation and setup procedure.

SUSE Manager Proxy systems are registered as traditional clients or as Salt clients using a bootstrap script. Migrating a traditionally registered Proxy system to a Salt Proxy system is not possible. Re-install the Proxy if you want to switch to Salt.

Important: Downloading Channels

Before you can select the correct child channels while creating the activation key, ensure you have completely downloaded the channels for SUSE Linux Enterprise 12 SP4.

Figure 2.4: Proxy Channels #

A few more steps are still needed:

You will then be able to register your clients against the proxy using the Web UI or a bootstrap script as if it were a SUSE Manager server. For more information, see Section 2.2.6, “Registering Salt Clients via SUSE Manager Proxy”.

On the server select the patterns-suma_proxy package for installation, or make sure the suma_proxy pattern is installed using the following command on the proxy as root:

zypper in -t pattern suma_proxy

The new salt-broker service will be automatically started at the end of the package installation. This service forwards the Salt interactions to the SUSE Manager server.

Note: Proxy Chains

It is possible to arrange Salt proxies in a chain. In such a case, the upstream proxy is named “parent”.

Make sure the proxie’s TCP ports 4505 and 4506 are open and that the proxy can reach the SUSE Manager server (or another upstream proxy) on these ports.

The proxy will share some SSL information with the SUSE Manager server, so the next step is to copy the certificate and its key from the SUSE Manager server or the upstream proxy.

As root, enter the following commands on the proxy using your SUSE Manager server or chained proxy named PARENT:

mkdir /root/ssl-build
cd /root/ssl-build
scp root@PARENT:/root/ssl-build/RHN-ORG-PRIVATE-SSL-KEY .
scp root@PARENT:/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT .
scp root@PARENT:/root/ssl-build/rhn-ca-openssl.cnf .

Note: Known Limitation

The SUSE Manager Proxy functionality is only supported if the SSL certificate was signed by the same CA as the SUSE Manager Server certificate. Using certificates signed by different CAs for Proxies and Server is not supported.

The configure-proxy.sh script will finalize the setup of your SUSE Manager Proxy.

Now execute the interactive configure-proxy.sh script. Pressing Enter without further input will make the script use the default values provided between brackets []. Here is some information about the requested settings:

If parts are missing, such as CA key and public certificate, the script prints commands that you must execute to integrate the needed files. When the mandatory files are copied, re-run configure-proxy.sh. Also restart the script if a HTTP error was met during script execution.

configure-proxy.sh activates services required by SUSE Manager Proxy, such as squid, apache2, salt-broker, and jabberd.

To check the status of the proxy system and its clients, click the proxy system’s details page on the Web UI (Main Menu › Systems › Proxy, then the system name). Connection and Proxy subtabs display the respective status information.

Proxy servers may now act as a broker and package cache for Salt minions. These minions can be registered with a bootstrap script like the traditional clients, or from the Web UI, or the command line.

Registering Salt clients via SUSE Manager Proxy from the Web UI is done almost the same way as registering clients directly with the SUSE Manager server. The difference is that you specify the name of the proxy in the Proxy drop-box on the Main Menu › Systems › Bootstrapping page.

Figure 2.5: Bootstrapping a Salt Client With a Proxy #

Registering clients (either traditional or Salt) via SUSE Manager Proxy with a script is done almost the same way as registering clients directly with the SUSE Manager server. The difference is that you create the bootstrap script on the SUSE Manager Proxy with a command-line tool. The bootstrap script then deploys all necessary information to the clients. The bootstrap script refers some parameters (such as activation keys or GPG keys) that depend on your specific setup.

The clients are registered with the SUSE Manager Proxy specified in the bootstrap script.

Within the Web UI, standard proxy pages will show information about client, no matter whether minions or traditional clients.

A list of clients connected to a proxy can be located under Systems › ] <proxy name › menu:Details[Proxy.

A list of chained proxies for a minion can be located under Systems › ] <minion name › menu:Details[Connection

If you decide to move any of your clients between proxies or the server you will need to repeat the registration process from scratch.

To enable PXE boot via a proxy server, additional software must be installed and configured on both the SUSE Manager server and the SUSE Manager Proxy server.

SUSE Manager is using Cobbler to provide provisioning. PXE (tftp) is installed and activated by default. To enable systems to find the PXE boot on the SUSE Manager Proxy server add the following to the DHCP configuration for the zone containing the systems to be provisioned:

next-server: <IP_Address_of_SUSE_Manager_Proxy_Server>
filename: "pxelinux.0"

A SUSE Manager Proxy is dumb in the sense that it does not contain any information about the clients which are connected to it. A SUSE Manager Proxy can therefore be replaced by a new one. Naturally, the replacement proxy must have the same name and IP address as its predecessor.

In order to replace a SUSE Manager Proxy and keeping the clients registered to the proxy leave the old proxy in SUSE Manager. Create a reactivation key for this system and then register the new proxy using the reactivation key. If you do not use the reactivation key, you will need to re-registered all the clients against the new proxy.

Important: Proxy Installation and Client Connections

During the installation of the proxy, clients will not be able to reach the SUSE Manager server. After a SUSE Manager Proxy system has been deleted from the systems list, all clients connected to this proxy will be (incorrectly) listed as directly connected to the SUSE Manager server. After the first successful operation on a client such as execution of a remote command or installation of a package or patch this information will automatically be corrected. This may take a few hours.

In most situations upgrading the proxy will be your preferred solution as this retains all cached packages. Selecting this route saves time especially regarding proxies connected to SUSE Manager server via low-bandwith links. This upgrade is similar to a standard client migration.

Warning: Synchronizing Target Channels

Before successfully initializing the product migration, you first must make sure that the migration target channels are completely mirrored. To upgrade to SUSE Manager 3.2 Proxy, you will require at least the SUSE Linux Enterprise Server 12 SP4 base channel with the SUSE Manager Proxy 3.2 child channel for your architecture.

Check the System Status on the System Details › Overview when the migration is done.

Finally consider scheduling a reboot.

To sign repository metadata a custom GPG key is required. Create a new GPG key as root via the following steps.

$> gpg --gen-key

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: company sign key
Email address: company@example.com
Comment:
You selected this USER-ID:
    "company sign key <company@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

gpg: key 607FABDB marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/607FABDB 2018-07-09
      Key fingerprint = ACF5 4698 EC70 FD6A F8C9  942B A7A1 9301 607F ABDB
uid       [ultimate] company sign key <company@example.com>
sub   2048R/A812FA62 2018-07-09

There are two configuration files which needs to be changed to enable signing of metadata.

Example for /etc/rhn/signing.conf:

KEYID="607FABDB"

GPGPASS="MySecretPassword"

To enable signing of metadata please add the following in /etc/rhn/rhn.conf:

sign_metadata = 1

All spacewalk services must be restarted after modifying 'rhn.conf'.

After enabling signing metadata, all metadata needs to be re-generated. This can be done with a small SQL script:

$> spacewalk-sql -i
psql (9.6.9)
Type "help" for help.

susemanager=# insert into rhnRepoRegenQueue (id, CHANNEL_LABEL, REASON, FORCE)
susemanager-# (select sequence_nextval('rhn_repo_regen_queue_id_seq'), C.label, 'changed signing of metadata', 'Y' from rhnChannel C);
INSERT 0 40
susemanager=# \q
$>

When this feature is enabled, all clients have to trust the new GPG key. If the new GPG key is not imported on the client, installation or updating of packages is not possible.

We recommend that the repositories and the database for SUSE Manager be stored on a virtual storage device. This best practice will avoid data loss in cases where the SUSE Manager instance may need to be terminated. These steps must be performed prior to running the YaST SUSE Manager setup procedure.

The MaxClients setting determines the number of Apache httpd processes, and thus limits the number of client connections that can be made at the same time (SUSE Manager uses the pre-fork MultiProcessing Modules). The default value for MaxClients in SUSE Manager is 150. If you need to set the MaxClients value greater than 150, Apache httpd’s ServerLimit setting and Tomcat’s maxThreads must also be increased accordingly (see below).

Warning

The Apache httpd MaxClients parameter must always be less or equal than Tomcat’s maxThreads parameter!

If the MaxClients value is reached while the software is running, new client connections will be queued and forced to wait, this may result in timeouts. You can check the Apache httpd’s error.log for details:

[error] Server reached MaxClients setting, consider increasing the MaxClients setting

The default MaxClients parameter can be overridden on SUSE Manager by editing the server-tuning.conf file located at /etc/apache2/. For example server-tuning.conf file:

# prefork MPM
   <IfModule prefork.c>
           # number of server processes to start
           # http://httpd.apache.org/docs/2.2/mod/mpm_common.html#startservers
           StartServers         5
           # minimum number of server processes which are kept spare
           # http://httpd.apache.org/docs/2.2/mod/prefork.html#minspareservers
           MinSpareServers      5
           # maximum number of server processes which are kept spare
           # http://httpd.apache.org/docs/2.2/mod/prefork.html#maxspareservers
           MaxSpareServers     10
           # highest possible MaxClients setting for the lifetime of the Apache process.
           # http://httpd.apache.org/docs/2.2/mod/mpm_common.html#serverlimit
           ServerLimit        150
           # maximum number of server processes allowed to start
           # http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
           MaxClients         150
           # maximum number of requests a server process serves
           # http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequestsperchild
           MaxRequestsPerChild  10000
   </IfModule>

Warning

Whenever the Apache httpd MaxClients parameter is changed, the ServerLimit must also be updated to the same value, or the change will have no effect.

Tomcat’s maxThreads represents the maximum number of request processing threads that it will create. This value determines the maximum number of simultaneous requests that it is able to handle. All HTTP requests to the SUSE Manager server (from clients, browsers, XMLRPC API scripts, etc.) are handled by Apache httpd, and some of them are routed to Tomcat for further processing. It is thus important that Tomcat is able to serve the same amount of simultaneous requests that Apache httpd is able to serve in the worst case. The default value for SUSE Manager is 200 and should always be equal or greater than Apache httpd’s MaxClients. The maxThreads value is located within the server.xml file located at /etc/tomcat/.

Example relevant lines in server.xml:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" address="127.0.0.1" maxThreads="200" connectionTimeout="20000"/>
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" address="::1" maxThreads="200" connectionTimeout="20000"/>

Note: Tuning Notes

When configuring Apache httpd’s MaxClients and Tomcat’s maxThreads parameters you should also take into consideration that each HTTP connection will need one or more database connections. If the RDBMS is not able to serve an adequate amount of connections, issues will arise. See the following equation for a rough calculation of the needed amount of database connections:

((3 * java_max) +  apache_max + 60)

Where:

• 3 is the number of Java processes the server runs with pooled connections (Tomcat, Taskomatic and Search)

• java_max is the maximum number of connections per Java pool (20 by default, changeable in /etc/rhn/rhn.conf via the hibernate.c3p0.max_size parameter)

• apache_max is Apache httpd’s MaxClients

• 60 is the maximum expected number of extra connections for local processes and other uses

SUSE recommends the following in a big scale SUSE Manager deployment:

Tip: Start Small and Scale Up

Always start small and scale up gradually. Keep the server monitored in order to identify possible issues early.

SUSE proposes the following tuning settings in a big scale SUSE Manager deployment:

Note that increasing the number of PostgreSQL connections will require more RAM, make sure the SUSE Manager server is monitored and swap is never used.

Also note the above settings should be regarded as guidelines-they have been tested to be safe but care should be exercised when changing them, and consulting support is highly recommended.

salt-ssh supports both password and key authentication. SUSE Manager uses both methods:

The user for salt-ssh calls made by SUSE Manager is taken from the ssh_push_sudo_user setting. The default value of this is root.

If the value of ssh_push_sudo_user is not root then the --sudo options of salt-ssh are used.

In order to redirect the ssh connection through the proxies the ssh ProxyCommand option is used. This options invokes an arbitrary command that is expected to connect to the ssh port on the target host. The standard input and output of the command is used by the invoking ssh process to talk to the remote ssh daemon.

The ProxyCommand basically replaces the TCP/IP connection. It doesn’t do any authorization, encryption, etc. Its role is simply to create a byte stream to the remote ssh daemon’s port.

E.g. connecting to a server behind a gateway:

Note

In this example netcat (nc) is used to pipe port 22 of the target host into the ssh std i/o.

To add a new host to Icinga create a host.cfg file for each host in /etc/icinga/conf.d/. For example susemanager.cfg:

define host {
  host_name           susemanager
  alias               SUSE Manager
  address             192.168.1.1
  check_period        24x7
  check_interval      1
  retry_interval      1
  max_check_attempts  10
  check_command       check-host-alive
}

Note

Place the host IP address you want to add to Icinga on the Address line.

After adding a new host restart Icinga as root to load the new configuation:

systemctl restart icinga

To add services for monitoring on a specific host define them by adding a service definition to your host.cfg file located in /etc/icinga/conf.d. For example you can monitor if a systems SSH service is running with the following service definition.

define service {
  host_name           susemanager
  use                 generic-service
  service_description SSH
  check_command       check_ssh
  check_interval      60
}

After adding any new services restart Icinga as root to load the new configuration:

systemctl restart icinga

You can create hostgroups to simplify and visualize hosts logically. Create a hostgroups.cfg file located in /etc/icinga/conf.d/ and add the following lines:

define hostgroup {
  hostgroup_name  ssh_group
  alias           ssh group
  members         susemanager,mars,jupiter,pluto,examplehost4
}

The members variable should contain the host_name from within each host.cfg file you created to represent your hosts. Every time you add an additional host by creating a host.cfg ensure you add the host_name to the members list of included hosts if you want it to be included within a logical hostgroup.

After adding several hosts to a hostgroup restart Icinga as root to load the new configuration:

systemctl restart icinga

You can create logical groupings of services as well. For example if you would like to create a group of essential SUSE Manager services which are running define them within a servicegroups.cfg file placed in /etc/icinga/conf.d/:

#Servicegroup 1
define servicegroup {
  servicegroup_name     SUSE Manager Essential Services
  alias                 Essential Services
}

#Servicegroup 2
define servicegroup {
  servicegroup_name     Client Patch Status
  alias                 SUSE Manager 3 Client Patch Status
}

Within each host’s host.cfg file add a service to a servicegroup with the following variable:

define service {
  use                 generic-service
  service_description SSH
  check_command       check_ssh
  check_interval      60
  servicegroups       SUSE Manager Essential Services
}

All services that include the servicegroups variable and the name of the servicegroup will be added to the specified servicegroup. After adding services to a servicegroup restart Icinga as root to load the new configuation:

systemctl restart icinga

The containers feature is available for Salt minions running SUSE Linux Enterprise Server 12 or later. Before you begin, ensure your environment meets these requirements:

To build images with SUSE Manager, you will need to create and configure a build host. Container build hosts are Salt minions running SUSE Linux Enterprise 12 or later. This section guides you though the initial configuration for a build host.

From the SUSE Manager Web UI perform these steps to configure a build host.

8.2.2.1 Define Container Build Channels with an Activation Key #

Create an activation key associated with the channel that your images will use.

Note: Relationship Between Activation Keys and Image Profiles

To build containers, you will need an activation key that is associated with a channel other than "SUSE Manager Default".

1. Select Main Menu › Systems › Activation Keys.

2. Click Create Key.

3. Enter a Description and a Key name. Use the drop-down menu to select the Base Channel to associate with this key.

4. Confirm with Create Activation Key.

For more information, see Book “Best Practices”, Chapter 7 “Activation Key Management”.

Define a location to store all of your images by creating an Image Store.

Manage Image Profiles from the Image Profile page.

https://github.com/USER/project.git#branchname:folder

https://github.com/ORG/project.git#branchname:folder

If your git repository is private and not publicly accessible, you need to modify the profile’s git URL to include authentication. Use this URL format to authenticate with a Github token:

https://USER:<AUTHENTICATION_TOKEN>@github.com/USER/project.git#master:/container/

https://gitlab.example.com/USER/project.git#master:/container/

https://gitlab.example.com/GROUP/project.git#master:/container/

https://gitlab-ci-token:<AUTHENTICATION_TOKEN>@gitlab.example.com/USER/project.git#master:/container/

Important: Specifying a Github or Gitlab Branch

If a branch is not specified, the master branch will be used by default. If a folder is not specified the image sources (Dockerfile sources) are expected to be in the root directory of the Github or Gitlab checkout.

This section contains an example Dockerfile. You specify a Dockerfile that will be used during image building when creating an image profile. A Dockerfile and any associated scripts should be stored within an internal or external Github or Gitlab repository:

Important: Required Dockerfile Lines

The Dockerfile provides access to a specific repository version served by SUSE Manager. This example Dockerfile is used by SUSE Manager to trigger a build job on a build host minion. The ARG parameters ensure that the image that is built is associated with the desired repository version served by SUSE Manager. The ARG parameters also allow you to build image versions of SUSE Linux Enterprise Server which may differ from the version of SUSE Linux Enterprise Server used by the build host itself.

For example: The ARG repo parameter and the echo command pointing to the repository file, creates and then injects the correct path into the repository file for the desired channel version.

The repository version is determined by the activation key that you assigned to your image profile.

FROM registry.example.com/sles12sp2
MAINTAINER Tux Administrator "tux@example.com"

### Begin: These lines Required for use with {productname}

ARG repo
ARG cert

# Add the correct certificate
RUN echo "$cert" > /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT.pem

# Update certificate trust store
RUN update-ca-certificates

# Add the repository path to the image
RUN echo "$repo" > /etc/zypp/repos.d/susemanager:dockerbuild.repo

### End: These lines required for use with {productname}

# Add the package script
ADD add_packages.sh /root/add_packages.sh

# Run the package script
RUN /root/add_packages.sh

# After building remove the repository path from image
RUN rm -f /etc/zypp/repos.d/susemanager:dockerbuild.repo

This is an example add_packages.sh script for use with your Dockerfile:

#!/bin/bash
set -e

zypper --non-interactive --gpg-auto-import-keys ref

zypper --non-interactive in python python-xml aaa_base aaa_base-extras net-tools timezone vim less sudo tar

Note: Packages Required for Inspecting Your Images

To inspect images and provide the package and product list of a container to the SUSE Manager Web UI you will need to install python and python-xml within the container. If these packages remain uninstalled, your images will still build, but the package and product list will be unavailable from the Web UI.

There are two ways to build an image. You can select Images › Build from the left navigation bar, or click the build icon in the Images › Profiles list.

You can import and inspect arbitrary images. Select Images › Images from the left navigation bar. Complete the text boxes of the Import dialog. Once it has processed, the imported image will be listed on the Images page.

The entry for the image is created in the database, and an Inspect Image action on SUSE Manager is scheduled.

Once it has been processed, you can find the imported image in the Images list. It has a different icon in the Build column, to indicate that the image is imported (see screenshot). The status icon for the imported image can also be seen on the Overview tab for the image.

These are some known problems that you might encounter when working with images:

OS image building is disabled by default. You can enable it in /etc/rhn/rhn.conf by setting:

java.kiwi_os_image_building_enabled = true

Restart the Spacewalk service to pick up the changes:

spacewalk-service restart

The Kiwi image building feature is available for Salt minions running SUSE Linux Enterprise Server 12. It is currently not supported to build SUSE Linux Enterprise 15 images.

Kiwi image configuration files and configuration scripts must be accessible in one of these locations:

Example scripts are provided in the following sections.

Note: Hardware Requirements for Hosts Running OS Images

Hosts running OS images built with Kiwi need at least 1 GB of RAM. Disk space depends on the actual size of the image. For more information, see the documentation of the underlying system.

To build all kinds of images with SUSE Manager, create and configure a build host. OS image build hosts are Salt minions running SUSE Linux Enterprise Server 12 (SP3 or later). This procedure will guide you though the initial configuration for a build host.

From the SUSE Manager Web UI perform these steps to configure a build host:

SUSE Manager Web Server Public Certificate RPM. Build host provisioning copies the SUSE Manager certificate RPM to the build host. This certificate is used for accessing repositories provided by SUSE Manager.

The certificate is packaged in RPM by the mgr-package-rpm-certificate-osimage package script. The package script is called automatically during a new SUSE Manager installation.

When you upgrade the spacewalk-certs-tools package, the upgrade scenario will call the package script using the default values. However if the certificate path was changed or unavailable, you will need to call the package script manually using --ca-cert-full-path <path_to_certificate> after the upgrade procedure has finished.

Package script call example. 

/usr/sbin/mgr-package-rpm-certificate-osimage --ca-cert-full-path /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT

The RPM package with the certificate is stored in a salt-accessible directory such as /usr/share/susemanager/salt/images/rhn-org-trusted-ssl-cert-osimage-1.0-1.noarch.rpm.

The RPM package with the certificate is provided in the local build host repository /var/lib/Kiwi/repo.

Important: The RPM Package with the SUSE Manager Certificate Must Be Specified in the Build Source

Make sure your build source Kiwi configuration contains rhn-org-trusted-ssl-cert-osimage as a required package in the bootstrap section.

config.xml. 

...
  <packages type="bootstrap">
    ...
    <package name="rhn-org-trusted-ssl-cert-osimage" bootinclude="true"/>
  </packages>
...

8.3.3.1 Define Kiwi Build Channels with an Activation Key #

Create an activation key associated with the channel that your images will use. Activation keys are mandatory for OS Image building.

Note: Relationship Between Activation Keys and Image Profiles

To build OS Images, you will need an activation key that is associated with a channel other than "SUSE Manager Default".

1. In the Web UI, select Main Menu › Systems › Activation Keys.

2. Click Create Key.

3. Enter a Description, a Key name, and use the drop-down box to select a Base Channel to associate with the key.

4. Confirm with Create Activation Key.

For more information, see Book “Best Practices”, Chapter 7 “Activation Key Management”.

OS images can require a significant amount of storage space. Therefore, we recommended that the OS image store is located on a partition of its own or on a btrfs subvolume, separate from the root partition. By default, the image store will be located at /srv/www/os-images.

Note: Image stores for Kiwi build type

Image stores for Kiwi build type, used to build system, virtual and other images, are not supported yet.

Images are always stored in /srv/www/os-images/<organization id> and are accessible via HTTP/HTTPS https://<susemanager_host>/os-images/<organization id>

Manage Image Profiles using the Web UI.

Kiwi sources consist at least of config.xml. Usually config.sh and images.sh are present as well. Sources can also contain files to be installed in the final image under the root subdirectory.

For information about the Kiwi build system, see the Kiwi documentation.

SUSE provides examples of fully functional image sources at the SUSE/manager-build-profiles public GitHub repository.

Example of JeOS config.xml. 

<?xml version="1.0" encoding="utf-8"?>

<image schemaversion="6.1" name="POS_Image_JeOS6">
    <description type="system">
        <author>Admin User</author>
        <contact>noemail@example.com</contact>
        <specification>SUSE Linux Enterprise 12 SP3 JeOS</specification>
    </description>
    <preferences>
        <version>6.0.0</version>
        <packagemanager>zypper</packagemanager>
        <bootsplash-theme>SLE</bootsplash-theme>
        <bootloader-theme>SLE</bootloader-theme>

        <locale>en_US</locale>
        <keytable>us.map.gz</keytable>
        <timezone>Europe/Berlin</timezone>
        <hwclock>utc</hwclock>

        <rpm-excludedocs>true</rpm-excludedocs>
        <type boot="saltboot/suse-SLES12" bootloader="grub2" checkprebuilt="true" compressed="false" filesystem="ext3" fsmountoptions="acl" fsnocheck="true" image="pxe" kernelcmdline="quiet"></type>
    </preferences>
    <!--    CUSTOM REPOSITORY
    <repository type="rpm-dir">
      <source path="this://repo"/>
    </repository>
    -->
    <packages type="image">
        <package name="patterns-sles-Minimal"/>
        <package name="aaa_base-extras"/> <!-- wouldn't be SUSE without that ;-) -->
        <package name="kernel-default"/>
        <package name="salt-minion"/>
        ...
    </packages>
    <packages type="bootstrap">
        ...
        <package name="sles-release"/>
        <!-- this certificate package is required to access {productname} repositories
             and is provided by {productname} automatically -->
        <package name="rhn-org-trusted-ssl-cert-osimage" bootinclude="true"/>

    </packages>
    <packages type="delete">
        <package name="mtools"/>
        <package name="initviocons"/>
        ...
    </packages>
</image>

There are two ways to build an image using the Web UI. Either select Main Menu › Images › Build, or click the build icon in the Main Menu › Images › Profiles list.

After the image is successfully built, the inspection phase begins. During the inspection phase SUSE Manager collects information about the image:

Note

If the built image type is PXE, a Salt pillar will also be generated. Image pillars are stored in the /srv/susemanager/pillar_data/images/ directory and the Salt subsystem can access details about the generated image. Details include where the pillar is located and provided, image checksums, information needed for network boot, and more.

The generated pillar is available to all connected minions.

Building an image requires of several dependent steps. When the build fails, investigation of salt states results can help you to identify the source of the failure. Usual checks when the build fails:

The section contains some known issues when working with images.

Cobbler configuration is primarily managed using the /etc/cobbler/settings file. Cobbler will run with the default settings unchanged. All configurable settings are explained in detail in the /etc/cobbler/settings file, including information on each setting, and recommendations.

Note: Supported Languages

If SUSE Manager complains that language en was not found within the list of supported languages available at /usr/share/YaST2/data/languages, remove the lang parameter in the /etc/cobbler/settings file, or add a valid parameter such as en_US.

For more on this topic, see https://www.suse.com/support/kb/doc?id=7018334.

Cobbler uses DHCP to automate bare metal installations from a PXE boot server. You must have administrative access to the network’s DHCP server, or be able to configure DHCP directly on the the Cobbler server.

allow booting;
allow bootp; 1
class "PXE" 2
{match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; 3
next-server 192.168.2.1; 4
filename "pxelinux.0";} 5

<network>
  <name>default</name>
  <uuid>1da84185-31b5-4c8b-9ee2-a7f5ba39a7ee</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:29:59:18'/>
  <domain name='default'/>
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254'/>
      <bootp file='/pxelinux.0' server='192.168.100.153'/> 1
</dhcp>
  </ip>
</network>

SUSE Manager uses the atftpd daemon, but it can also use TFTP. The atftpd daemon is the recommended method for PXE serviices, and is installed by default. Usually, you do not have to change its configuration, but if you have to, use the YaST Services Manager.

Before TFTP can serve the pxelinux.0 boot image, you must start the tftp service. Start YaST and use System › Services Manager to configure the tftpd daemon.

It is possible to synchronize Cobbler-generated TFTP contents to SUSE Manager proxies to perform PXE booting using proxies.

zypper install susemanager-tftpsync

zypper install susemanager-tftpsync-recv

10.2.4.3 Configuring SUSE Manager Server #

As the root user, execute configure-tftpsync.sh on SUSE Manager Server:

configure-tftpsync.sh proxy1.example.com proxy2.example.com

Execute cobbler sync to initially push the files to the proxy systems. This will succeed if all listed proxies are properly configured.

Note: Changing the List of Proxy Systems

You can call configure-tftpsync.sh to change the list of proxy systems. You must always provide the full list of proxy systems.

Note: Reinstalling a Configured Proxy

If you reinstall an already configured proxy and want to push all the files again you must remove the cache file at /var/lib/cobbler/pxe_cache.json before you can call cobbler sync again.

Before starting the Cobbler service, run a check to make sure that all the prerequisites are configured according to your requirements using the cobbler check command.

If configuration is correct, start the SUSE Manager server with this command:

/usr/sbin/spacewalk-service start

Warning

Do not start or stop the cobblerd service independent of the SUSE Manager service. Doing so may cause errors and other issues.

Always use /usr/sbin/spacewalk-service to start or stop SUSE Manager.

Kickstart templates can have static values for certain common items such as PXE image file names, subnet addresses, and common paths such as /etc/sysconfig/network-scripts/. However, templates differ from standard Kickstart files in their use of variables.

For example, a standard Kickstart file may have a networking section similar to this:

network --device=eth0 --bootproto=static --ip=192.168.100.24 \
  --netmask=255.255.255.0 --gateway=192.168.100.1 --nameserver=192.168.100.2

In a Kickstart template file, the networking section would look like this instead:

network --device=$net_dev --bootproto=static --ip=$ip_addr \
  --netmask=255.255.255.0 --gateway=$my_gateway --nameserver=$my_nameserver

These variables are substituted with the values set in your Kickstart profile variables or in your system detail variables. If the same variable is defined in both the profile and the system detail, then the system detail variable takes precedence.

Note

The template for the autoinstallation has syntax rules which relies on punctuation symbols. To avoid clashes, they need to be properly treated.

In case the autoinstallation scenario contains any shell script using variables like $(example), its content should be escaped by using the backslash symbol: \$(example).

If the variable named example is defined in the autoinstallation snippet, the templating engine will evaluate $example with its content. If there is no such variable, the content will be left unchanged. Escaping the $ symbol will prevent the templating engine from evaluating the symbol as an internal variable. Long scripts or strings can be escaped by wrapping them with the \#raw and \#end raw directives. For example:

#raw
#!/bin/bash
for i in {0..2}; do
 echo "$i - Hello World!"
done
#end raw

Also, pay attention to scenarios like this:

#start some section (this is a comment)
echo "Hello, world"
#end some section (this is a comment)

Any line with a # symbol followed by a whitespace is treated as a comment and is therefore not evaluated.

For more information about Kickstart templates, refer to the Cobbler project page at:

https://fedorahosted.org/cobbler/wiki/KickstartTemplating

If you have common configurations across all Kickstart templates and profiles, you can use the Snippets feature of Cobbler to take advantage of code reuse.

Kickstart snippets are sections of Kickstart code that can be called by a $SNIPPET() function that will be parsed by Cobbler and substituted with the contents of the snippet.

For example, you might have a common hard drive partition configuration for all servers, such as:

clearpart --all
part /boot --fstype ext3 --size=150 --asprimary
part / --fstype ext3 --size=40000 --asprimary
part swap --recommended

part pv.00 --size=1 --grow

volgroup vg00 pv.00
logvol /var --name=var vgname=vg00 --fstype ext3 --size=5000

Save this snippet of the configuration to a file like my_partition and place the file in /var/lib/cobbler/snippets/, where Cobbler can access it.

Use the snippet by calling the $SNIPPET() function in your Kickstart templates. For example:

$SNIPPET('my_partition')

Wherever you invoke that function, the Cheetah parser will substitute the function with the snippet of code contained in the my_partition file.

If you have created a virtual machine profile as documented in Section 10.4, “Adding a Profile to Cobbler”, you can use koan to initiate the installation of a virtual guest on a system. For example, create a Cobbler profile with the following command:

cobbler add profile --name=virtualfileserver \
  --distro=sles12-x86_64-server --virt-file-size=20 --virt-ram=1000

This profile is for a fileserver running SUSE Linux Enterprise Server 12 with a 20 GB guest image size and allocated 1 GB of system RAM. To find the name of the virtual guest system profile, use the koan command:

koan --server=hostname --list-profiles

This command lists all the available profiles created with cobbler profile add.

Create the image file, and begin installation of the virtual guest system:

koan --virt --server=cobbler-server.example.com \
  --profile=virtualfileserver --virtname=marketingfileserver

This command specifies that a virtual guest system be created from the Cobbler server (hostname cobbler-server.example.com) using the virtualfileserver profile. The virtname option specifies a label for the virtual guest, which by default is the system’s MAC address.

Once the installation of the virtual guest is complete, it can be used as any other virtual guest system.

koan can replace a still running system with a new installation from the available Cobbler profiles by executing the following command on the system to be reinstalled:

koan --replace-self --server=hostname --profile=name

This command, running on the system to be replaced, will start the provisioning process and replace the system with the profile in --profile=name on the Cobbler server specified in --server=hostname.

To successfully provision a bare metal system, you will require a fully patched SUSE Manager server, version 2.1 or higher.

The system to be provisioned must have x86_64 architecture, with at least 1 GB RAM, and be capable of PXE booting.

The server uses TFTP to provision the bare metal client, so the appropriate port and networks must be configured correctly in order for provisioning to be successful. In particular, ensure that you have a DHCP server, and have set the next-server parameter to the SUSE Manager server IP address or hostname.

Bare metal systems management can be enabled or disabled in the Web UI by clicking Admin › SUSE Manager Configuration › Bare-metal systems.

Note

New systems are added to the organization of the administrator who enabled the bare metal systems management feature. To change the organization, log in as an Administrator of the required organization, and re-enable the feature.

Once the feature has been enabled, any bare metal system connected to the server network will be automatically added to the organization when it is powered on. The process can take a few minutes, and the system will automatically shut down once it is complete. After the reboot, the system will appear in the Systems list. Click on the name of the system to see basic information, or go to the Properties, Notes, and Hardware tabs for more details. You can migrate bare metal systems to other organizations if required, using the Migrate tab.

Provisioning bare metal systems is similar to provisioning other systems, and can be done using the Provisioning tab. However, you will not be able to schedule provisioning, it will happen automatically as soon as the system is configured and powered on.

Note: Bare Metal and System Set Manager

System Set Manager can be used with bare metal systems, although not all features will be available, because bare metal systems do not have an operating system installed. This limitation also applies to mixed sets that contain bare metal systems; all features will be re-enabled if the bare metal systems are removed from the set.

If a bare metal system on the network is not automatically added to the Systems list, check these things first:

If you see a blue Cobbler menu shortly after booting, discovery has started. If it does not complete successfully, temporarily disable automatic shutdown in order to help diagnose the problem. To disable automatic shutdown:

Important: Duplicate profiles

Due to a technical limitation, it is not possible to reliably distinguish a new bare metal system from a system that has previously been discovered. Therefore, we recommended that you do not power on bare metal systems multiple times, as this will result in duplicate profiles.

Setting up and managing VM Guest s with SUSE Manager does not require special configuration options. However, you need to provide activation keys for the VM Host Server and the VM Guest s, an autoinstallable distribution and an autoinstallation profile. To automatically register VM Guest s with SUSE Manager , a bootstrap script is needed.

11.1.1.2 Setting up an Autoinstallable Distribution #

To autoinstall clients from SUSE Manager , you need to provide an “autoinstallable distribution” , also referred to as autoinstallable tree or installation source. This installation source needs to be made available through the file system of the SUSE Manager host. It can for example be a mounted local or remote directory or a “loop-mounted” ISO image. It must match the following requirements:

• Kernel and initrd location:

RedHat / Generic RPM #

• images/pxeboot/vmlinuz

• images/pxeboot/initrd.img

SUSE #

• boot/arch/loader/initrd

• boot/arch/loader/linux

  • The Base Channel needs to match the autoinstallable distribution.

Important: Autoinstallation package sources

There is a fundamental difference between RedHat and SUSE systems regarding the package sources for autoinstallation. The packages for a RedHat installation are being fetched from the Base Channel . Packages for installing SUSE systems are being fetched from the autoinstallable distribution.

As a consequence, the autoinstallable distribution for a SUSE system has to be a complete installation source (same as for a regular installation).

Procedure: Creating Autoinstallable Distribution #

1. Make sure an installation source is available from a local directory. The data source can be any kind of network resource, a local directory or an ISO image (which has to be “loop-mounted” ). Files and directories must be world readable.

2. Log in to the SUSE Manager Web UI} and navigate to Systems › Autoinstallation › Distributions › Create Distribution .

3. Fill out the form Create Autoinstallable Distribution as follows:

   Distribution Label

   Choose a unique name for the distribution. Only letters, numbers, hyphens, periods, and underscores are allowed; the minimum length is 4 characters. This field is mandatory.

   Tree Path

   Absolute local disk path to installation source. This field is mandatory.

   Base Channel

   Channel matching the installation source. This channel is the package source for non-SUSE installations. This field is mandatory.

   Installer Generation

   Operating system version matching the installation source. This field is mandatory.

   Kernel Options

   Options passed to the kernel when booting for the installation. There is no need to specify the install= parameter since it will automatically be added. Moreover, the parameters self_update=0 pt.options=self_update are added automatically to prevent AutoYaST from updating itself during the system installation. This field is optional.

   Post Kernel Options

   Options passed to the kernel when booting the installed system for the first time. This field is optional.

4. Save your settings by clicking Create Autoinstallable Distribution .

To edit an existing Autoinstallable Distribution › ] , go to menu:Systems[Autoinstallation › Distributions and click on a Label › ] . Make the desired changes and save your settings by clicking menu:Update Autoinstallable Distribution[ .

11.1.1.4 SUSE Linux Enterprise 15 Systems #

You need the installation media to setup the distribution. Starting with version 15, there is only one installation media. You will use the same one for SLES, SLED, and all the other SUSE Linux Enterprise 15 based products.

In the AutoYaST profile specify which product is to be installed. For installing SUSE Linux Enterprise Server use the following snippet in autoyast.xml:

<products config:type="list">
  <listentry>SLES</listentry>
</products>

Then then specify all the required modules as add-on in autoyast.xml. This is a minimal SLE-Product-SLES15-Pool selection that will result in a working installation and can be managed by SUSE Manager:

• SLE-Manager-Tools15-Pool

• SLE-Manager-Tools15-Updates

• SLE-Module-Basesystem15-Pool

• SLE-Module-Basesystem15-Updates

• SLE-Product-SLES15-Updates

It is also recommended to add the following modules:

• SLE-Module-Server-Applications15-Pool

• SLE-Module-Server-Applications15-Updates

11.1.1.4.1 Uploading an Autoinstallation Profile #

1. Log in to the SUSE Manager Web interface and open Systems › Autoinstallation › Profiles › Upload New Kickstart/AutoYaST File .

2. Choose a unique name for the profile. Only letters, numbers, hyphens, periods, and underscores are allowed; the minimum length is 6 characters. This field is mandatory.

3. Choose an Autoinstallable Tree › ] from the drop-down menu. If no menu:Autoinstallable Tree[ is available, you need to add an Autoinstallable Distribution. Refer to Section 11.1.1.2, “Setting up an Autoinstallable Distribution” for instructions.

4. Choose a Virtualization Type › ] from the drop-down menu. KVM and Xen (para-virtualized and fully-virtualized) are available. Do not choose menu:Xen Virtualized Host[ here.

5. Scroll down to the File to Upload › ] dialog › click menu:Browse[ to select it, then click Upload File .

6. The uploaded file will be displayed in the File Contents section, where you can edit it.

7. Click Create to store the profile.

To edit an existing profile, go to Systems › Autoinstallation › Profiles and click on a Label › ] . Make the desired changes and save your settings by clicking menu:Create[ .

Note: Editing existing {kickstart}profiles

If you are changing the Virtualization Type › ] of an existing {kickstart} profile › it may also modify the bootloader and partition options › potentially overwriting any user customizations. Be sure to review the menu:Partitioning[ tab to verify these settings when changing the Virtualization Type .

11.1.1.4.2 Creating a Kickstart Profile #

Note

Currently it is only possible to create autoinstallation profiles for RHEL systems. If installing a SUSE Linux Enterprise Server system, you need to upload an existing AutoYaST profile as described in Section 11.1.1.4.1, “Uploading an Autoinstallation Profile”.

1. Log in to the SUSE Manager Web interface and go to Systems › Autoinstallation › Profiles › Create New Kickstart File .

2. Choose a unique name for the profile. The minimum length is 6 characters. This field is mandatory.

3. Choose a Base Channel › ] . This channel is the package source for non-SUSE installations and must match the menu:Autoinstallable Tree[ . This field is mandatory.

4. Choose an Autoinstallable Tree › ] from the drop-down menu. If no menu:Autoinstallable Tree[ is available, you need to add an Autoinstallable Distribution. Refer to Section 11.1.1.2, “Setting up an Autoinstallable Distribution” for instructions.

5. Choose a Virtualization Type › ] from the drop-down menu. KVM and Xen (para-virtualized and fully-virtualized) are available. Do not choose menu:Xen Virtualized Host[ here.

6. Click the Next button.

7. Select the location of the distribution files for the installation of your VM Guest s. There should already be a Default Download Location › ] filled out and selected for you on this screen. Click the menu:Next[ button.

8. Choose a root password for the VM Guest s. Click the Finish button to generate the profile.

   This completes {kickstart} profile creation. After generating a profile, you are taken to the newly-created {kickstart} profile. You may browse through the various tabs of the profile and modify the settings as you see fit, but this is not necessary as the default settings should work well for the majority of cases.

11.1.1.4.3 Adding a Registration Script to the Autoinstallation Profile #

A VM Guest that is autoinstalled does not get automatically registered. Adding a section to the autoinstallation profile that invokes a bootstrap script for registration will fix this. The following procedure describes adding a corresponding section to an AutoYaST profile. Refer to your RedHat Enterprise Linux documentation for instructions on adding scripts to a {kickstart} file.

1. First, provide a bootstrap script on the SUSE Manager :

   • Create a bootstrap script for VM Guest s on the SUSE Manager as described in Book “Getting Started”, Chapter 5 “Registering Clients”, Section 5.4 “Registering Traditional Clients”, Section 5.4.1 “Generating a Bootstrap Script”.

   • Log in as root to the konsole of SUSE Manager and go to /srv/www/htdocs/pub/bootstrap . Copy bootstrap.sh (the bootstrap script created in the previous step) to e.g. bootstrap_vm_guests.sh in the same directory.

   • Edit the newly created file according to your needs. The minimal requirement is to include the activation key for the VM Guest s (see Section 11.1.1.1, “Activation Keys” for details). We strongly recommend to also include one or more GPG keys (for example, your organization key and package signing keys).

2. Log in to the SUSE Manager Web interface and go to Systems › Autoinstallation › Profiles . Click on the profile that is to be used for autoinstalling the VM Guest s to open it for editing.

   Scroll down to the File Contents section where you can edit the AutoYaST XML file. Add the following snippet at the end of the XML file right before the closing </profile> tag and replace the given IP address with the address of the SUSE Manager server. See Appendix B, Minimalist AutoYaST Profile for Automated Installations and Useful Enhancementsfor an example script.

   <scripts>
     <init-scripts config:type="list">
       <script>
         <interpreter>shell </interpreter>
         <location>
           http://`192.168.1.1`/pub/bootstrap/bootstrap_vm_guests.sh
         </location>
       </script>
     </init-scripts>
   </scripts>

   

   Important: Only one <scripts> section allowed

   If your AutoYaST profile already contains a <scripts> section, do not add a second one, but rather place the <script> part above within the existing <scripts> section!

3. Click Update to save the changes.

A VM Host Server system serving as a target for autoinstalling VM Guest s from SUSE Manager must be capable of running guest operating systems. This requires either KVM or Xen being properly set up. For installation instructions for SUSE Linux Enterprise Server systems refer to the SLES Virtualization Guide available from https://www.suse.com/documentation/sles-12/book_virt/data/book_virt.html. For instructions on setting up a RedHat VM Host Server refer to your RedHat Enterprise Linux documentation.

Since SUSE Manager uses libvirt for VM Guest installation and management, the libvirtd needs to run on the VM Host Server . The default libvirt configuration is sufficient to install and manage VM Guest s from SUSE Manager . However, in case you want to access the VNC console of a VM Guest as a non-root user, you need to configure libvirt appropriately. Configuration instructions for libvirt on SUSE Linux Enterprise Server are available in the SLES Virtualization Guide available from https://www.suse.com/documentation/sles-12/book_virt/data/book_virt.html available from http://www.suse.com/documentation/sles11/. For instructions for a RedHat VM Host Server refer to your RedHat Enterprise Linux documentation.

Apart from being able to serve as a host for KVM or Xen guests, which are managed by libvirt , a VM Host Server must be registered with SUSE Manager .

11.1.2.2 VM Host Server setup on Traditional clients #

When the registration process is finished and all packages have been installed, enable the osad (Open Source Architecture Daemon). On SUSE Linux Enterprise Server 12 systems and later, it can be achieved by running the following commands as user root:

service rhnsd stop
service rhnsd disable

service osad enable
service osad start

Important: osadTogether with rhnsd

rhnsd daemon checks for scheduled actions every four hours, so it can take up to four hours before a scheduled action is carried out. If many clients are registered with SUSE Manager, this long interval ensures a certain level of load balancing since not all clients act on a scheduled action at the same time.

For setting the time interval, see <<[[bp.systems.management>>.

However, when managing VM Guests, you usually want actions like rebooting a VM Guest to be carried out immediately, which can be done by adding osad. The osad daemon receives commands over the jabber protocol from SUSE Manager and commands are instantly executed. Alternatively you may schedule actions to be carried out at a fixed time in the future (whereas with rhnsd you can only schedule for a time in the future plus up to four hours).

When all requirements on the SUSE Manager and the VM Host Server are met, you can start to autoinstall VM Guests on the host. Note that VM Guests will not be automatically registered with SUSE Manager, therefore we strongly recommend to modify the autoinstallation profile as described in Section 11.1.1.4.3, “Adding a Registration Script to the Autoinstallation Profile”. VM Guests need to be registered to manage them with SUSE Manager. Proceed as follows to autoinstall a VM Guest:

Important: No parallel Autoinstallations on VM Host Server

It is not possible to install more than one VM Guest at a time on a single VM Host Server. When scheduling more than one autoinstallation with SUSE Manager make sure to choose a timing, that starts the next installation after the previous one has finished. If a guest installation starts while another one is still running, the running installation will be cancelled.

Note: Checking the Installation Log

To view the installation log, click Events › History on the Session Status › ] page. On the menu:System History Event[ page you can click a Summary entry to view a detailed log.

In case an installation has failed, you can Reschedule it from this page once you have corrected the problem. You do not have to configure the installation again.

If the event log does not contain enough information to locate a problem, log in to the VM Host Server console and read the log file /var/log/up2date. If you are using rhnsd, you may alternatively immediately trigger any scheduled actions by calling rhn_ckeck on the VM Host Server. Increase the command’s verbosity by using the options -v, -vv, or -vvv, respectively.

Click the name of a VM Guest on the VM Host Server 's Virtualization page to open its profile page with detailed information about this guest. For details, refer to Book “Reference Manual”, Chapter 7 “Systems”.

A profile page for a virtual system does not differ from a regular system’s profile page. You can perform the same actions (e.g. installing software or changing its configuration).

To start, stop, restart, suspend, or resume a VM Guest , navigate to the VM Host Server 's Virtualization › ] page. Check one or more menu:Guests[ listed in the table and scroll down to the bottom of the page. Choose an action from the drop-down list and click Apply Action › ] . menu:Confirm[ the action on the next page.

Note: Automatically restarting a VM Guest

Automatically restarting a VM Guest when the VM Host Server reboots is not enabled by default on VM Guest s and cannot be configured from SUSE Manager . Refer to your KVM or Xen documentation. Alternatively, you may use libvirt to enable automatic reboots.

To change the CPU or RAM allocation of a VM Guest navigate to the VM Host Server 's Virtualization › ] page. Check one or more menu:Guests[ from the table and scroll down to the bottom of the page. Choose an action from the Set › ] drop-down list and provide a new value. Confirm with menu:Apply Changes[ followed by Confirm .

The memory allocation can be changed on the fly, provided the memory ballooning driver is installed on the VM Guest . If this is not the case, or if you want to change the CPU allocation, you need to shutdown the guest first. Refer to Section 11.2.2, “Starting, Stopping, Suspending and Resuming a VM Guest” for details.

To delete a VM Guest you must first shut it down as described in Section 11.2.2, “Starting, Stopping, Suspending and Resuming a VM Guest”. Wait at least two minutes to allow the shutdown to finish and then choose Delete Systems › ] followed by menu:Apply Action[ and Confirm .

There is a manpage available, as for most command line tools. First, decide which scheduled actions should be enabled for use by system administrators. The following options enable the various scheduled action modes:

Once a mode is set, your system is ready for configuration management through SUSE Manager. A common option is mgr-actions-control --enable-all.

To list the configuration files for the machine and the labels of the config channels containing them, issue the command:

mgrcfg-client list

The output resembles the following list ("DoFoS" is a shortcut for "D or F or S", which means "Directory", "File", or "Something else"(?)):

DoFoS   Config Channel      File
F      config-channel-17   /etc/example-config.txt
F      config-channel-17   /var/spool/aalib.rpm
F      config-channel-14   /etc/rhn/rhn.conf

These configuration files apply to your system. However, there may be duplicate files present in other channels. For example, issue the following command:

mgrcfg-manager list config-channel-14

and observe the following output:

Files in config channel 'config-channel-14'
/etc/example-config.txt /etc/rhn/rhn.conf

You may wonder why the second version of /etc/example-config.txt in config-channel-14 does not apply to the client system. The rank of the /etc/example-config.txt file in config-channel-17 was higher than that of the same file in config-channel-14. As a result, the version of the configuration file in config-channel-14 is not deployed for this system, therefore mgrcfg-client command does not list the file.

To download the most relevant configuration file for the machine, issue the command:

mgrcfg-client get /etc/example-config.txt

You should see output resembling:

Deploying /etc/example-config.txt

View the contents of the file with less or another pager. Note that the file is selected as the most relevant based on the rank of the config channel containing it. This is accomplished within the Configuration tab of the System Details page.

Refer to Section "System Details" (Chapter 4, Systems, User Guide) for instructions.

To view the labels and names of the config channels that apply to the system, issue the command:

mgrcfg-client channels

You should see output resembling:

Config channels:
Label                   Name
-----                   ----
config-channel-17       config chan 2
config-channel-14       config chan 1

The list of options available for mgrcfg-client get:

To view the differences between the config files deployed on the system and those stored by SUSE Manager, issue the command:

mgrcfg-client diff

The output resembles the following:

rhncfg-client diff
--- /etc/test
+++ /etc/test 2013-08-28 00:14:49.405152824 +1000
@@ -1 +1,2 @@
This is the first line
+This is the second line added

In addition, you can include the --topdir option to compare config files with those located in an arbitrary (and unused) location on the client system, like this:

# mgrcfg-client diff --topdir /home/test/blah/
/usr/bin/diff: /home/test/blah/etc/example-config.txt: No such file or directory
/usr/bin/diff: /home/test/blah/var/spool/aalib.rpm: No such file or directory

To quickly determine if client configuration files are different from those associated with it via SUSE Manager, issue the command:

mgrcfg-client verify

The output resembles the following:

modified /etc/example-config.txt /var/spool/aalib.rpm

The file example-config.txt is locally modified, while aalib.rpm is not.

The list of the options available for mgrcfg-client verify:

To create a config channel for your organization, issue the command:

mgrcfg-manager create-channel channel-label

If prompted for your SUSE Manager username and password, provide them. Once you have created a config channel, use the remaining modes listed above to populate and maintain that channel.

To add a file to a config channel, specify the channel label and the local file to be uploaded:

mgrcfg-manager add --channel=channel-label /path/to/file

In addition to the required channel label and the path to the file, you can use the available options for modifying the file during its addition. For instance, you can alter the path and file name by including the --dest-file option in the command:

mgrcfg-manager add --channel=channel-label \
  --dest-file=/new/path/to/file.txt/path/to/file

The output resembles the following:

Pushing to channel example-channel
Local file >/path/to/file -> remote file /new/path/to/file.txt

The list of options available for mgrcfg-manager add:

Tip: Max File size

By default, the maximum file size for configuration files is 128KB. If you need to change that value, find or create the following line in the /etc/rhn/rhn.conf file:

web.maximum_config_file_size=128

Change the value from 128 to whatever limit you need in kilobytes.

To view the differences between the config files on disk and the latest revisions in a channel, issue the command:

mgrcfg-manager diff --channel=channel-label --dest-file=/path/to/file.txt \
/local/path/to/file

You should see output resembling:

--- /tmp/dest_path/example-config.txt config_channel: example-channel revision: 1
+++ /home/test/blah/hello_world.txt 2003-12-14 19:08:59.000000000 -0500
@@ -1 +1 @@
-foo
+hello, world

The list of options available for mgrcfg-manager diff:

To compare different versions of a file across channels and revisions, use the -r flag to indicate which revision of the file should be compared and the -n flag to identify the two channels to be checked. Specify only one file name here since you are comparing the file against another version of itself. For example:

mgrcfg-manager diff-revisions -n=channel-label1 -r=1 \
  -n=channel-label2 -r=1 \
  /path/to/file.txt

The output resembles the following:

--- /tmp/dest_path/example-config.txt 2004-01-13 14:36:41 \
config channel: example-channel2 revision: 1
--- /tmp/dest_path/example-config.txt 2004-01-13 14:42:42 \
config channel: example-channel3 revision: 1
@@ -1 +1,20 @@
-foo
+blah
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.0.6 (GNU/Linux)
+Comment: For info see http://www.gnupg.org
+
+iD8DBQA9ZY6vse4XmfJPGwgRAsHcAJ9ud9dabUcdscdcqB8AZP7e0Fua0NmKsdhQCeOWHX
+VsDTfen2NWdwwPaTM+S+Cow=
+=Ltp2
+-----END PGP SIGNATURE-----

The list of options available for mgrcfg-manager diff-revisions:

To download all the files in a channel to disk, create a directory and issue the following command:

mgrcfg-manager download-channel channel-label --topdir .

The output resembles the following:

Copying /tmp/dest_path/example-config.txt -> \
blah2/tmp/dest_path/example-config.txt

The list of options available for mgrcfg-manager download-channel: