SUSE Manager/NewFeatures2.1

From MicroFocusInternationalWiki
Revision as of 16:45, 18 June 2014 by SilvioMoioli (Talk | contribs) (Known Issues)

Jump to: navigation, search


Upgrade Instructions

Upgrade from SUSE Manager Server 2.1 Beta 3 to Beta 4

Stop spacewalk services

 $> spacewalk-service stop

Update already installed packages

 $> zypper ar -f manager-beta
 $> zypper dup --from manager-beta

Schema upgrade

 $> spacewalk-schema-upgrade

Start spacewalk services

 $> spacewalk-service start

Upgrade form SUSE Manager Server 1.7

When all requirements are met (system is registered with Novell Customer Center and latest updates are installed), you can use YaST Wagon to upgrade a SUSE Manager Sever 1.7 to SUSE Manager Server 2.1.

Stop spacewalk services

 $> spacewalk-service stop

Run /usr/sbin/wagon as root from the command line.

 # su
 # /usr/sbin/wagon

Confirm the Welcome dialog with Next.
If Wagon finds that the requirements are not met (required maintenance updates are available but not yet installed), it will do an automatic self-update, which may require a reboot. Follow the on-screen instructions.

Choose the update method in the following dialog. Select Customer Center to use the default setup (recommended).

Click Custom URL to manually choose the software channels used for the online migration. A list of channels will be displayed, providing the opportunity to manually enable, disable, add, or delete channels.


Click OK to return to the Update Method dialog.
If you want to review changes to the channel setup caused by the update process, select Check Automatic Repository Changes.
Proceed with Next.

The system will be re-registered. During this process the Pool and Updates channels will be added to the system. Confirm the addition of the channels.

New Features in SUSE Manager 2.1

This beta test comes with the latest upcoming features that will be included in SUSE Manager 2.1, which includes support for:

  • Unattended bare-metal system provisioning
  • First-time installation support in System Set Manager
  • Power Management
  • Action Chaining
  • Package Lock

Unattended bare-metal system provisioning


SUSE Manager can be configured so that unprovisioned ("bare-metal") systems capable of PXE booting are added to an organization. After that happens, those systems will appear in the Systems list, where regular provisioning via autoinstallation is possible in a completely unattended fashion.


  • a fully patched SUSE Manager 2.1 server (see above for migration instructions from SUSE Manager 1.7);
  • one or more unprovisioned systems capable of PXE booting. Only x86_64 systems with at least 1 GB of RAM are supported.

Note that the SUSE Manager server will use its integrated Cobbler instance and will act as TFTP server for this feature to work, so the network segment that connects it to target systems must be properly configured in this regard. In particular, a DHCP server must exist and have a next-server configuration parameter set to the SUSE Manager server IP address or hostname. See Cobbler Requirements for details.

Enabling bare-metal system management

Bare-metal system management can be enabled and disabled by SUSE Manager administrators by clicking on Admin -> SUSE Manager Configuration -> Bare-metal systems from the Web User Interface.

Note that new systems will be added to the organization of the administrator who enabled this feature. To change organization disable the feature, log in as an administrator of a different organization and enable it again.

Once enabled, any bare-metal system connected to the SUSE Manager server network will be automatically added to the organization when it powers on. The process typically takes a few minutes; when it finishes, the system will automatically shut down and then appear in the Systems list.

If this does not happen automatically, see the Troubleshooting section.

Inspecting bare-metal systems

Bare-metal systems will appear in the Systems list with a special icon. Clicking on a system's name shows some basic information about the system, more details can be obtained or added manually via the Properties, Notes and Hardware tabs.

Bare-metal systems can be migrated to another organization like regular systems by using the Migrate tab.

Provisioning is also similar and can be initiated by clicking on the Provisioning tab. In case of bare-metal systems, though, provisioning cannot be scheduled: it will happen automatically as soon as it is completely configured and the system is powered on. Details about provisioning and autoinstallation configuration are available in the Autoinstallation section; to power on a system from SUSE Manager see Power Management.

System Set Manager and bare-metal systems

It is possible to use System Set Manager with bare-metal systems, although in that case some features will not be available as those systems do not have an operating system installed. This limitation also applies to mixed sets with regular and bare-metal systems: full features will be enabled again once all bare-metal systems are removed from the set.


If a bare-metal system is not automatically added, please do the following:

  • check that the pxe-default-image package is installed;
  • check configured file paths and parameters. In particular, check that the vmlinuz0 and initrd0.img files provided by pxe-default-image are in locations specified by rhn.conf, as per the following sample file:
   cobbler.bootstrap.kernel = /srv/pxe-default-image/vmlinuz0
   cobbler.bootstrap.initrd = /srv/pxe-default-image/initrd0.img
   cobbler.bootstrap.breed = suse
   cobbler.bootstrap.arch = x86_64
   cobbler.bootstrap.extra_kernel_options = ROOTFS_FSCK=0
  • check that network equipment connecting the system and the SUSE Manager server works correctly;
  • check that those bare-metal systems have PXE booting enabled in their boot sequence, and that no operating system gets booted;
  • check that the DHCP server responds to the DHCP request from the system during boot. In particular:
    • check that it assigns the expected IP address. Typically this address is displayed among PXE boot messages;
    • check that it assigns the SUSE Manager server IP address as next-server for booting. This IP address should also be abe displayed among PXE boot messages;
  • check that the SUSE Manager server IP address is actually reachable from the server;
  • check that the SUSE Manager server has Cobbler running and the discovery feature is enabled;
  • if you see a Cobbler blue menu shortly after booting, discovery has actually started. If it does not complete succesfully, it is possible to disable automatic shutdown for diagnosis purposes. In order to accomplish that, press the arrow keys to select "pxe-default-profile" in the Cobbler menu and press the Tab key before the 30 second timer expires. Then add the kernel boot parameter spacewalk-finally=running using the integrated editor and press Enter to continue booting. Then enter login root and password linux to get to a shell.

Known Issues

  • Due to a technical limitation it is not possible to reliably distinguish a new bare-metal system from a system that has been discovered for the second time, it is thus recommended not to power on bare-metal systems multiple times. In case that happens, you can remove duplicate profiles by using the Duplicate systems page.
  • Current documentation has to be reworded since with the introduction of this feature AutoYAST/Kickstart can also be used as first-time installation features, not just for reinstallations.

First-time installation support in System Set Manager


In SUSE Manager 1.7, the System Set Manager Autoinstallation tab could be used to re-install a system using an Autoinstallation profile. With SUSE Manager 2.1, the same tab can be used to create Cobbler system records to install an OS to a machine even if it didn't have one.

This replicates functionality provided by the Create Cobbler System Record button in Manager 1.7 for multiple systems.

Notes for Documentation Team:

  • the "Create Cobbler System Record" button is currently not documented: see bug entry;
  • the "Autoinstallable Type" mechanism is currently not documented: see bug entry;
  • the button has been reamed from "Create Cobbler System Record" to "Create PXE installation configuration" from SUSE Manager 1.7 to 2.1.

Power Management


SUSE Manager allows you to power on, off and reboot systems (either physical or bare-metal) via the IPMI protocol.


  • a fully patched SUSE Manager 2.1 server (see above for migration instructions from SUSE Manager 1.7);
  • one or more IPMI-enabled systems.

Configure power management

In order to use any power management functionality, IPMI configuration details must be added to SUSE Manager. To do that first select the target system on the Systems list, then select Provisioning -> Power Management. From the configuration page that is produced, edit all required fields (marked with a red asterisk) and click on Save.

Using power management

Systems can be powered on, off or rebooted from the configuration page via corresponding buttons. Note that any configuration change is also saved in the process.

The "Save and Get Status" button can also be used to query for the system's power state. If configuration details are correct, a row is displayed with the current power status ("on" or "off").

If a power management operation succeeds on a system, it will also be noted in its Event History tab.

System Set Manager support

SUSE Manager's power management functionalities can also be used from the System Set Manager to operate on multiple systems at the same time. Specifically, you can change power management configuration parameters or apply operations (power on, off, reboot) to multiple systems at once.

In order to do that, add systems to the System Set Manager as described in the System Set Manager chapter.

Then, click on Manage -> Provisioning -> Power Management Configuration to change one or more configuration parameters for all systems in the set. Note that any field left blank will not alter the configuration parameter in selected systems.

Once all configuration parameters are set correctly, click on Manage -> Provisioning -> Power Management Operations to power on, off or reboot systems from the set. Note that the Provisioning entitlement is required for non-bare metal systems.

In order to check that a power operation was executed correctly, click on System Set Manager -> Status from the left side menu, then click on the proper line in the list. This will display a new list with systems to which the operation was applied. In the event of errors which prevent correct execution, a brief message with an explanation will be displayed in the Note column.

Known Issues

  • This feature uses Cobbler power management, thus a Cobbler system record is automatically created at the first use if it does not exist already. In that case, the automatically created system record will not be bootable from the network and will reference a dummy image. This is needed because Cobbler does not currently support system records whithout profiles nor images.
  • the current implementation of Cobbler power management uses the fence-agent tools to support multiple protocols besides IPMI. Those are not supported by SUSE Manager but can be used by adding the fence agent names as a comma-separated list to the java.power_management.types configuration parameter.

More information on Cobbler power management can be found on the Cobbler Wiki.

Action Chaining


SUSE Manager can group a number of operations in a sequence, called an Action Chain, so that they are all scheduled at once and performed in a particular order. Using Action Chains can be useful when dealing with some administrative tasks, for example rebooting a systems after deploying a patch.


Currently SUSE Manager supports Action Chaining on:

  • package installation;
  • package update;
  • package removal;
  • package verification;
  • patch application;
  • execution of a remote command;
  • configuration file deployment;
  • reboot.

An Action is one of the supported operations above, applied to one or more systems.

An Action Chain is an ordered sequence of Actions.

The execution of an Action is the execution of the corresponding operation to all the systems it applies to.

The execution of an Action Chain is the execution of all its Actions, provided that:

  • if more than one Action applies to a same system, corresponding supported operations will be executed sequentially in Action Chain order.
  • if a supported operation fails on a system, no further supported operations will be executed on that system.

Note: SUSE Manager does not enforce ordering across different systems.


  • a fully patched SUSE Manager 2.1 server (see above for migration instructions from SUSE Manager 1.7);
  • at least one registered client.

Adding Actions to a Chain

First, create the first Action of the Chain following instructions specific to that Action, for example installing a package on a single system or running a remote command through the System Set Manager.

Instead of scheduling the Action for a certain date, select the "Add To Action Chain" radio button. Use the combo-box on the right to enter a new Action Chain label name.

Add to action chain.png

After clicking on "Schedule", you should get a confirmation message and the Action Chain is created.

Added successfully to action chain.png

You can add more Actions to the Chain by repeating the process and selecting the same label from the Action Chain combobox.

Editing a Chain

Action Chains can be edited by clicking on their labels from the Schedule -> Action Chains page.

Edit action chain.png

From this page you can:

  • change the Actions ordering by drag-and-drop;
  • delete Actions from the Chain by clicking on "delete action" links;
  • inspect the list of systems on which an Action is run by clicking on the "+" sign;
  • delete a single system from an Action by clicking on "delete system" links;
  • delete the whole Chain with the "delete action chain" link on the top-left corner;
  • change the Action Chain label by clicking on it;
  • schedule the Action Chain for execution not before a certain date by clicking on the "Save and Schedule" button.

Note that leaving the page without clicking on either "Save" or "Save and Schedule" will destroy any unsaved changes - a confirmation dialog will appear in that case.

After scheduling an Chain

Once a Chain is scheduled, the actions it contains will be displayed in the Schedule -> Pending Actions, Failed Actions and Completed Actions pages depending on their statuses. In particular, if an Action fails on a system no other Actions from the same Chain will be executed on that systems.


The application programming interface for the Action Chain feature is available over the XML-RPC protocol and are accessible from any programming language that supports such protocol.

In order to access the API from Python code, one must create remote XML-RPC connection, login to obtain session token and use Action Chain API. As an example:

import xmlrpclib

# Prepare the connection
conn = xmlrpclib.Server("", verbose = 0)
token = conn.auth.login("myusername", "mypassword")

# Collect required data from appropriate API calls
server_id = 10000010000
chain_name = "Server Maintenance"
packages = [111, 222, 333]

# Schedule Action Chains
conn.actionchain.addPackageInstall(token, server_id, packages)
conn.actionchain.addSystemReboot(token, server_id, chain_name)

To find your host ID (server_id), you should use corresponding methods from other sections in the set of SUSE Manager APIs, for example search the systems by name. The same applies is about the "packages" variable, which is a list of package IDs.

In order to know full list of currently supported XML-RPC APIs, please refer to the documentation, available on your installed SUSE Manager.

Known Issues

  • Due to technical limitations it is not possible to reuse Action Chains;
  • Currently you cannot add an Action to an Action Chain from the Edit page.

Further reading

Developer information is also available on this Wiki.

Package Lock


The "Package Lock" feature allows users prevent installation or upgrades of the software on the machine they need.

Please note that this feature does not operate in a real time, but performs via scheduling requests to lock or unlock particular packages with some little time gap. This time can be even more increased by selecting date/time on the locking page.


One or more client machines:

  • using zypper as a Package Manager (Red Hat Enterprise Linux clients are currently not supported);
  • with zypp-plugin-spacewalk package installed, version 0.9.6 or greater.

Locking a package

In order to lock a package, do the following steps:

  1. Navigate to the managed system
  2. Follow "Software/Packages/Lock" tabs.

On this page will appear the list of all the packages that can be installed on the system. Packages which are already locked have a small lock icon beside their name.

Select the packages you want to lock and then press the "Request Lock" button. In case locking should happen later or another date, please request the appropriate date/time above the "Request Lock" button.

Unlocking a package

In order to unlock a package, please do the following:

  1. Navigate to the managed system
  2. Follow the "Software/Packages/Lock" tabs.

On this page will appear the list of all the packages that can be installed on the system. Packages which are already locked have a small lock icon beside their name.

Select the packages you want to unlock and then press the "Request Unlock" button. In case unlocking should happen later or another date, please request the appropriate date/time above the "Request Unlock" button.


Q: What happens on an attempt installing locked package?

A: An attempt installing locked package using SUSE Manager will not be successful. Such attempt will be marked as failed event by SUSE Manager, and an explanation of the error will be available as event details.

Please note that the installing locked package manually, i.e. directly on the client machine, will also fail. Installing packages manually directly on the client machine is highly discouraged and should be considered as bad practice.

Q: How locked package gets upgraded?

A: Any locked package cannot be upgraded or removed. Beware Zypper bug that ignores locked package removal, therefore make sure your client machine has latest Zypper available to the current OS installed.

Q: What happens if some locked package is a dependency of an unlocked package I am trying to install?

A: Since any package can be installed only by satisfaction its dependencies, in this case an unlocked package is indirectly locked by the dependency package, and therefore will not be installed.

Q: What happens if some locked package is a dependency of an unlocked package I am trying to install, and the locked dependency is already installed on my system?

A: If the locked dependency satisfies the conditions of new package, i.e. requiring no upgrade, then the package will be installed successfully. However, if the locked dependency also needs to be upgraded, then the package will not be installed.

Setup Wizard


Setting up SUSE Manager typically requires some extra steps after installation for common configuration tasks. This feature makes it straightforward to get to a working state by streamlining those tasks.


  • a fully patched SUSE Manager 2.1 server (see above for migration instructions from SUSE Manager 1.7).

How to use the Setup Wizard

A Setup Wizard link is displayed when the SUSE Manager web interface is used for the fist time, and can be accessed later at any time by clicking on Admin -> Setup Wizard.

HTTP Proxy: configure a proxy server that SUSE Manager will use to access NCC and other remote servers here. Use 'hostname:port' syntax in the Hostname field if the proxy port is not 80. Clearing the fields disables proxy.

Mirror Credentials: add username and password pairs to access NCC here by clicking the "Add a New Credential" button. Upon saving, a new credential card will be displayed. Buttons below the credential card allow the following:

Mirror credential card example.png

  • see the credential validation status (green tick or red cross icon). You can re-check the credential with NCC by clicking on the icon;
  • set the primary credentials for Inter-server sync (yellow star iscon);
  • list the subscriptions related to a certain credential (list icon);
  • list the subscriptions related to a certain credential (list icon);
  • edit the credential (pencil icon);
  • delete the credential (trash can icon).

SUSE Products: add product-specific channels you are entitled to from this page, equivalently to the `mgr-ncc-sync --add-product` command. This page will display a list of all products that are available given your mirror credentials; you can add those to SUSE Manager by selecting corresponding checkboxes and clicking the "Add product" button at the page bottom.


You can as well click the individual products "Add this product" button to add it immediately.

Once you add a product, you should see it as in progress and you will be able now to select addons that require the product you added.

Note that after addition channel synchronization will take place and it could take up to several hours before corresponding channels are actually usable in SUSE Manager.


Once the product is downloaded and ready to be used, you will see a "Finished" label next to it:


Add-on products are shown when you select the corresponding base product or when you click the plus sign.

SUSE products tab.png

If you click on the channel list icon, SUSE Manager will show you the channels required by the product.


Known Issues

  • More settings will be configurable from the Wizard in future versions.
  • Due to a bug in beta 3 only the primary mirror credentials that were configured with the Wizard can be used with the mgr-ncc-sync command. Any additional credentials that were configured with the Wizard will not be considered when using mgr-ncc-sync. This will be fixed with beta 4.

Further reading

Developer information is also available on this Wiki.

Autoinstallation templates

Automatic escaping of the $ symbol from the autoinstallation templates has been discontinued in SUSE Manager 2.1.

The autoinstallation template has syntax rules, using 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:

 This is an \$(example) content.

If 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 to perform its evaluation as an internal variable.

Long scripts or strings can be escaped by wrapping them with the #raw and #end raw directives. For example:

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

An additional attention needs to be paid to the similar scenarios:

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

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

Package End User License Agreements

Since SUSE Manager 2.1, you can review package EULAs from package detail pages.

Package details EULA.png

Please note that SUSE Manager 2.1 will always automatically accept any EULA for all packages that you install through the Web interface, API, as part of updates, system rollbacks, dependencies and so on.