Advanced Patch Lifecycle Management with SUSE Manager

SUSE Manager delivers best-in-class Linux server management features like automated software management, system provisioning, and monitoring. It provides a unified Linux management infrastructure by standardizing and automating server patching and management. These tasks can be performed faster and with fewer errors, which improves IT staff productivity while reducing server downtime.

The Chameleon Corporation is the world’s largest reptile and amphibian pet store, and has its headquarters in Yemen. It has more than 1500 stores operating under the names LizardsRUs, UnVeiledInc and Chameleo-rama in five different countries.

The Chameleon Corporation has the following requirements for managing patch and security updates to their Linux hosts. Because of compliance constraints, their patch lifecycle (the timing and delivery) is based on their corporate security policies, the host environments/landscapes, and their future management needs.

Here is a high-level summary of the requirements:

In summary, these requirements highlight the need for two patch schedules, across three (or more) landscapes, in three SUSE Manager organizations, with a way to handle a storage location for patches that cannot be rolled out (exceptions), yet need to be tracked, re-mediated and reintroduced to ensure compliance.

SUSE Manager can handle these complexities very well and can be set up to allow flexible delivery of these requirements. Automation can even be applied to assist with some facets, and procedures can be developed to ensure the consistent delivery of patches that meet the published company policies.

This document describes how to set up and configure a SUSE Manager implementation to enable companies to deliver these often requested features:

Many of these features can be tuned to meet a change in requirements, like an increase in, or a reduction of, the number of landscapes (DEV and PROD or Sandbox, DEV, QA, UAT, PRE-PROD, PROD, etc.), or a more, or less frequent delivery calendar. Keep this in mind as you read. SUSE Manager is a very flexible product that has helped many customers create and deploy solid systems and patch management frameworks. Your requirements may differ from the ones described here, but the flexibility of SUSE Manager enables you to meet your ongoing and changing needs.

This guide is based on SUSE Manager 2.1, but can also be used with SUSE Manager 3.0. The document will not highlight any Salt minion specifics nor should this matter change how channel organizations and patch manipulation are handled here.

A fresh installation is not necessary, but some assumption is made that you have a working SUSE Manager environment, with some registered hosts, and a decent knowledge of the terms and capabilities. The SUSE Manager documentation at https://documentation.suse.com/suma/3.2/ is an excellent source of information that is often updated. Refer to the documentation for clarification of any process that seems confusing. Many of the implementation steps detailed in this document are enhanced examples based on procedures, capabilities, or step-by-step “how-tos” in our product documentation.

Note: Test Your Implementation

Some advanced features (like using the spacecmd or the XMLRPC API) will be explained in more detail, but these explanations may not be exhaustive. We will include some code examples in the Appendix that can be used as-is, or modified to suit your particular environments or needs. However, these come with no warranty, and should not be expected to be perfect for any implementation. Always test your particular implementation before any production usage.

The next section will describe the setup of SUSE Manager to meet the requirements defined in the Scenario section. We will start with a description of the architecture (and components) developed to meet the requirements, and then proceed with steps to create it yourself. Each component within this guide is used together with the others to deliver a comprehensive solution in the specific scenario described herein, but might be used individually to help you meet your own solution requirements.

Here is a high-level outline of the architecture and channels:

Note: Use of Prefixes

For any Base channel listed here–this can be a clone tree of the SUSE vendor channels–as such it would include a prefix- in the name. This can aid the handling of service pack migrations described in the channel creation sections that follow.

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 need 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 two crontab entries such as (cron syntax):

0 0 30 6,9 * /path/to/archive-create-script

00 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 SUSE Linux Enterprise Server version 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 “softwareChannel” methods 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.

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 roll out calendar as the reason for the exception is re-mediated. 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, however at any other given point in time, this might have occurred before the patch was released or it may be up to three 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 will not get a copy until the quarter is up.

Copying these emergency patches into place does not 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.

Further explanation can be found below in Section 2.4, “Exception and Escalation Channels”.

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 extensions.

For example, a base set of channels within SUSE Manager for SUSE Linux Enterprise Server 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 SUSE Linux Enterprise Server 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, SUSE Linux Enterprise Server 11 SP3 Updates for x86_64.

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 SUSE Linux Enterprise Server 11 SP2, this will include the SUSE Linux Enterprise Server 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)

Because both SUSE Linux Enterprise Server SP1 and SP2 are in their LTSS 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 the LTSS Updates channel to receive further patches and support. Visit http://www.suse.com/lifecycle for more information.

Here is a graphic that illustrates the patch promotion process:

Figure 1: Patch Promotion Process #

  

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. Because of 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.

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 safekeeping, accounting, and reporting.

These channels can be created within the Archive base channel or within the cloned base channel for the version of SUSE Linux Enterprise Server 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 re-mediate any potential security issues or code flaws that the patch was created to fix.

Here is a list of things we will create to enable Advanced Patch Lifecycle Management using SUSE Manager 2.1:

As described in the architecture section above, 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 the exception patches. For each landscape a custom channel will be created to hold patches that have been promoted. These channels will contain more and more content over time as patches are promoted each cycle.

For example, during Quarter 1 (Q1) the archive channel contains 159 patches, and these are merged into the DEV updates channel for SUSE Linux Enterprise Server 11 SP4. As SUSE releases patches in an ongoing fashion, when the next quarter’s archive is created, Q2 for this example, it contains all of the Q1 patches and an additional 130 patches for a total of 289. The merge function will take the 130 new patches (and associated packages) and add them to the DEV updates channel during the next patch cycle.

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. When a patch is copied successfully into an exception channel, it can be removed from an updates channel or an archive.

2.6.1 Creating the Channels #

  

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, etc. Multiple archives matching the different versions of SUSE Linux Enterprise Server can exist in the base channel, but they will all be the same processor architecture.

Create the base archive channels:

For each processor architecture used by the hosts that SUSE Manager manages, create empty channels named “32-bit Archives Channel” and “64-bit Archives Channel”:

1. In the Web UI click “Channels” then the submenu “Manage Software Channels” and click “+Create Channel”.

2. The channel label must be kept in the format of “architecture-patch-archives-channel”, for example the 64-bit channel label should read “x86_64-patch-archives-channel”.

   

   Important: Label the Channels

   Failing to label these channels appropriately will cause the example archive script to not work properly (without modifications). SUSE Manager is very strict about channel “labels” consisting of lowercase letters, starting with a letter (not a number) and containing no spaces, etc.

   In this example of creating a label starting with “x86_64” it is assumed a 32-bit channel might be “i586” or similar.

3. These archive channels have “NO PARENT”, because they “ARE” parent channels.

4. Select the appropriate architecture for this channel: x86_64 for 64-bit, and IA-32 for 32-bit, etc..

5. Select the Public radio button for these channels to ensure their visibility to all organizations.

6. Repeat for each architecture type of SUSE Linux Enterprise Server you have deployed.

Create the cloned archive channels.

For each version of SUSE Linux Enterprise Server that is used, create cloned channels:

1. In the Web UI click “Channels” then the submenu “Manage Software Channels” and click “Clone Channel”.

2. Select the SUSE “Updates” channel of the SUSE Linux Enterprise Server version you want to create an archive of as the Source.

3. Make sure to select the radio button for all content/patches.

4. Name the channel appropriately with an indication of Time/Date and what the archive contains, for example, “Q3 - 09-30-2015 - Archive of SLES 11 SP3 for x86_64”.

5. Create a label using proper syntax, for example:

   q3-09-30-2015-archive-sles11sp3-x86_64

6. Important: select the appropriate base archive channel to contain the clone.

7. Include an appropriate description of the channel in the Summary and Description fields.

8. Click “Create Channel” when finished.

9. Scroll down and select the Public radio button and then click “Update Channel”.

10. Repeat for each SUSE Linux Enterprise Server version under each architecture.

Optional: Use spacewalk-clone-by-date to create archive channels from the past:

See the Appendix 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:

1. The utility is called with the following syntax:

   spacewalk-clone-by-date -c "config file"

2. Repeat this for each archive channel with a past date, modifying the configuration files to match the appropriate dates and channel source/target names.

2.6.1.1 Service Pack Migration Support with Update and Exception Channels #

  

There are a couple of generally accepted methods to manage a set of channels that allows consistent and expected behaviors when leveraging the service pack 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 service pack migration feature. When you select a given host to do a service pack migration, the UI proposes (dictates) a set of mandatory “child” channels that will be subscribed to for a migration action. These mandatory child channels (grayed-out in the UI) will normally include the SUSE provided update channels for a given version of SUSE Linux Enterprise Server.

See the following screenshot:

Figure 2: Service Pack Migration #

  

To allow usage of the patch lifecycle processes described here and to use the functionality of service pack migrations, it is best to create a full clone-set of the SUSE Linux Enterprise Server product versions in use at your company. This is sometimes called a clone-tree, and can be easily created using the spacecmd command of the same name, softwarechannel_clonetree.

A full clone-tree will include the base/parent channel (normally called a pool) and all child channels that currently exist underneath it. For example, using the SUSE Linux Enterprise Server 11 SP3 Pool x86_64 channel as a source, you provide your own prefix to the clone-tree 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.

See below for an image of the original SUSE Linux Enterprise Server 11 SP3 x86_64 channels and the cloned tree with prefix versions “Chameleon_Co-” next to it:

Figure 3: Full Software Channel List for Chameleon Corporation #

  

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.

Example:

spacecmd -u <SMadmin> -- softwarechannel_clonetree -s sles11-sp3-pool-x86_64 -p "my_company-"

Note: <SMadmin>

Make sure to replace <SMadmin> with your SUSE Manager webUI administrator user name!

This command creates a whole set of SUSE Linux Enterprise Server 11 SP3 x86_64 channels with a prefix of “my_company”.

Repeat this process for each version of SUSE Linux Enterprise Server, and then–when using the Service Pack migration feature–you can choose your company version of the target version of SUSE Linux Enterprise Server, and choose the child channels appropriate for the landscape the host is in (as 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 can do service pack migrations, but still retain your currently promoted patch set. Otherwise, SP migrations will always update to whatever are the latest packages in the “mandatory” updates child channel.

Consider the following screenshot that shows the Q3 patch archive for SUSE Linux Enterprise Server 11 SP4 with 227 packages, the SUSE Updates channel for SP4 with 234 packages, and the Chameleon Corporation version of SP4 Updates with 0 (zero) packages:

Figure 4: Partial View of Software Channel List for SUSE and Chameleon Corporation #

  

In the upcoming sections we will describe the creation of custom “current updates” channels and how to use a merge script. For service pack migrations using your own set of promoted patches, 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 always 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 a service pack 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 coming sections.

“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 version of SUSE Linux Enterprise Server and they will all be empty to begin with. Create a “new” channel and then optionally “clone” that one to reduce the amount of typing needed:

1. From the “Manage Software Channels” submenu, click “+Create Channel”.

2. Create the channel within one of the SUSE Linux Enterprise Pool Channels or, if you have your own clone set, within that pool.

3. Modify the channel to be Public.

4. Clone this new channel (without updates) into the remaining landscapes, each as a “Current Updates -” channel, and each with the appropriate landscape prefix (for example, “DEV - ”, “TEST - ”, “PROD - ”, etc.).

5. You should end up with a full set of landscapes for each SUSE Linux Enterprise Server version you are going to manage. Keep in mind for the SUSE Linux Enterprise Server 11 SP1 and SP2 channels this will result in a full set x2 (times 2)–or even x4 (times 4) with LTSS. However, SP1 and SP2 Update channels are not being updated any longer, so they could be subscribed as static channels now. (See the note about LTSS in chapter Section 2.3, “Patch Promotion Cycle”.)

Figure 5: Example Screenshot of “Current Updates” Channels #

  

“Exception” Channels:#

Now create the two exception channels for each version of SUSE Linux Enterprise Server being managed. While it may be possible to create a mixed channel that is unique to the 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 SUSE Linux Enterprise Server, it is more difficult to track, resolve, and then reintroduce these patches back into the patch workflow. It is much easier to place them into an exceptions channel specifically for the version of SUSE Linux Enterprise Server the patch came from. Create the “Patch Exception” and “Security ASAP Exception” channels as follows:

1. From the “Manage Software Channels” submenu, click “+Create Channel”.

2. Create the “Patch Exceptions - DO NOT SUBSCRIBE” channel within one of the SUSE Linux Enterprise Server 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.

5. For SUSE Linux Enterprise Server 11 SP1 and SP2 keep in mind: they reside in the same SP1 Pool base channel, so there will be exceptions and security exceptions channels for each service pack.

Figure 6: Example Screenshot of “Exceptions” Channels #

  

Typically you will have already created a set of Activation Keys assigned to a specific version of SUSE Linux Enterprise Server 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 can 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.

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. We will discuss promotion in the next section Section 2.8, “Scripts”.

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), for example 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 SUSE Linux Enterprise Server (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.).

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 SUSE Linux Enterprise Server and which architectures to create archives for. As previously described, the Archive channels are created as point-in-time clones of the various SUSE Linux Enterprise Server Updates channels.

To have the correct Archive channels created, simply add lines to the sources file. Each line has three fields, the first being the architecture, the second being the source channel, and the third being 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 calculates the current calendar quarter, creates the archives and makes these archives publicly visible. See the Appendix for the entire script.

A decision needs to be made whether a calendar quarter is going to get created (looking backward) 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 getting 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 simply because it requires two cron entries to handle both the 30^th of the month (for June and September) and the 31^st 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

0 0 31 3,12 * /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).

Also it is very important to note that this script is 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 invoking user`s home directory. Within the .spacecmd directory is a configuration file that can store credential sets that can be leveraged to avoid 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.

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:

[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 user name or password–allowing the cron job for archive creation to run without failure at the appropriate time.

Here are some suggested 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.

The patch promotion process follows the following sample steps.

The patch exception process follows the following sample steps. Again, keep in mind that these can be modified to fit more closely to a particular operational group’s existing set of processes.

Consider the following table:

The security exception process differs from the previous patch exception process in that a patch is now being added to a patch roll out cycle–likely in the middle of a current (inprogress) roll out. Another process table and some screenshots from the SUSE Manager interface are included here to provide further clarity.

Review the following table:

This screenshot shows the function of adding a patch to the Security ASAP Exceptions Channel–specifically the SLES 11 SP1 x86_64 version:

Figure 9: Adding a patch to the Security ASAP Exceptions Channel #

  

This screenshot 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 would be the interface where a patch would be removed from a channel and keep it from being visible and potentially deployed as part of an exception process.

Figure 10: Adding a patch to the Security ASAP Exceptions Channel #

  

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 configuration file:

spacewalk-clone-by-date -c Q3-2015-sles11sp3-x86_64-archive.conf

Note that it specifies the base channel source sles11-sp3-pool-x86_64 and the target base channel (destination) cc_patch_archives_channel_64bit and uses the directive of 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. Note that your channel names might be different; this means this example may need modifications to work in your case. Example: Q3-2015-sles11sp3-x86_64-archive.conf contents below.

{
 "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",
            "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"
         }
        }
       ]
}

Note: Review Channel Patch Content

When using the spacewalk-clone-by-date utility, 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 can be deleted manually.

This script has a defined SUSE Manager server URL set in the MANAGER_URL. 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: ")

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:
                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)

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 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: (for example 30^th of months June and September and 31^st of months March and December):

0 0 30 6,9 * /path/to/the/archive/script

0 0 31 3,12 * /path/to/the/archive/script

The script below works with the Archive Channel Sources file (see Section 4.6, “Sample Archive Channel Sources List File”) to create quarterly archives of the SUSE Updates channels. This example script is written in Bash but calls spacecmd to accomplish the cloning and to set the new archive to be public (accessible to other organizations).

The script takes some time to run. The clone command finishes quickly, but the actual cloned channel still takes some time to settle down before the org-access command can access and finish. If you want to test this manually you must be patient. A normal crontab-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 :                #
        #     e.g. 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  #
        #         etc.                                                     #
        #                                                                  #
        ####################################################################
        #                                                                  #
        #       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=`echo "$line" | awk -F, '{print $1}'`
        src_ch=`echo "$line" | awk -F, '{print $2}'`
        trg_ch=`echo "$line" | awk -F, '{print $3}'`
## set archive channel

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=`echo $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

The script below works with the Archive Channel Sources file (see Section 4.6, “Sample Archive Channel Sources List File”) to create quarterly archives of the SUSE Updates channels. This example script is written in Bash but calls spacecmd to accomplish the cloning and to set the new archive to be public (accessible to other organizations).

The script takes some time to run. The clone command finishes quickly, but the actual cloned channel still takes some time to settle down before the org-access command can access and finish. If you want to test this manually you must be patient. A normal crontab-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 :                #
        #     e.g. 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  #
        #         etc.                                                     #
        #                                                                  #
        ####################################################################
        #                                                                  #
        #       Created by - Jeff Price, SUSE Consulting - 2015            #
        #       Updated for SUMA 3.1 & 3.2 - Levin Forrest,            #
        #       Lenovo Consulting - 2018                                   #
        #                                                                  #
        ####################################################################

## 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=`echo "$line" | awk -F, '{print $1}'`
        src_ch=`echo "$line" | awk -F, '{print $2}'`
        trg_ch=`echo "$line" | awk -F, '{print $3}'`
## set archive channel
## Note the target_parent requires this EXACT channel already created
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=`echo $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

## removed double quotes from $src_ch to allow spacecmd to parse correctly
## removed single quotes from $target_channel_label and $target_parent to allow spacecmd to parse correctly
## only $target_channel_name should have single quotes as this variable contains spaces
/usr/bin/spacecmd -d -- softwarechannel_clone -s $src_ch -n "'$target_channel_name'" -l "$target_channel_label" -p "$target_parent" -g
## removed double quotes from $target_channel_label to allow spacecmd to parse correctly
/usr/bin/spacecmd -d -- softwarechannel_setorgaccess $target_channel_label -e
## added full directory structure to archive-sources location to allow call from crontab
done < /usr/sbin/archive-sources.lst

This file is called and used by the Archive Channel Creation script located above in the previous section (see Section 4.4, “Sample Archive Channel Creation Script for SUSE Manager 2.1 and 3.0”). 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 first field is architecture, which defines the source parent archive channel. This is where the new archive will be placed as a child channel. The second field is the source channel label, which is where the patches/packages are coming FROM. The last field is used for target channel naming. This field will be part of the text that makes up the channel name and part of the channel summary/description fields.

s390x,sles11-sp3-updates-s390x,SLES11-SP3-Updates for s390x
x86_64,sles11-sp4-updates-x86_64,SLES11-SP4-Updates for x86_64
i586,sles11-sp3-updates-x86_64,SLES11-SP3-Updates for x86_64

The archive script example here is written in Bash and calls the spacecmd shell. Normal operation of spacecmd and the SUSE Manager XMLRPC api requires authentication credentials. In order for the archive script to run successfully from cron, it would require some way of passing appropriate user credentials when required. Luckily there is a way to store user credential pairs.

Upon the first invocation of the spacecmd utility/shell, a directory is created in the home directory of the user who calls spacecmd. The directory is called .spacecmd (for example /root/.spacecmd/). Within this directory is a file called “config”, and within this file you can store parameters that will be used when the user subsequently calls spacecmd. The parameters are as follows (substitute your user name and password):

[spacecmd]
server=localhost
username=admin
password=susemgr
nossl=0

When those credentials are stored, you should be able to invoke the spacecmd shell or call spacecmd commands from the command line without being prompted for a user name or password.