Using BMC Server Automation to patch or update SuSE Service Packs
Updating from one SuSE Service Pack level to another requires using the zypper tool to perform a number of sequential steps. As of BMC Server Automation version 8.6 there is no native support for zypper. While applying updates to a Service Pack works well using the native BMC Server Automation method (yum) the Service Pack upgrade process is more involved and requires use of zypper.
The following procedure explains how to set up zypper repositories with BMC Server Automation catalogs and run the zypper dup using a Deploy Job. Note that SuSE only supports migrating from n to n+1 so it's not possible to jump service packs, for example to update directly from SP1 to SP3.
This topic includes the following sections:
Create Zypper Repositories
Create online or offline catalogs, one catalog per channel. For example SLES11-SP3-Pool and SLES11-SP3-Updates
- After running the Catalog Update Job, you must pull additional files from SuSE.
- From the Updates repo get: updateinfo.xml.gz, products.xml
- From the Pool (Core for SP2) get: products.xml
An example command to download these files is wget --username=mirrorUser --password=mirrorpass 'https://nu.novell.com/repo/$RCE/<channelName>/sle-11-<arch>/repodata/<fileName>'
For the updateinfo.xml.gz in the SP3 Pool channel that would be wget --username=mirrorUser --password=mirrorpass 'https://nu.novell.com/repo/$RCE/SLES11-SP3-Updates/sle-11-x86_64/repodata/updateinfo.xml.gz' - These files should go in the repodata folder in their respective channel directory in the patch download location
In each repodata/repomd.xml file, add a section for the downloaded files. The checksum is the checksum of the compressed file (if compressed), the open-checksum is the checksum of the uncompressed file. You can also obtain the xml bits by downloading the repomd.xml from SuSE and copy/pasting the sections into your local repomd.xml.
<data type="updateinfo">
<location href="repodata/updateinfo.xml.gz"/>
<checksum type="sha">d43ebb1c2b9cfbfa2bf759d8e2b2b029c64ee439</checksum>
<timestamp>1392201684</timestamp>
<open-checksum type="sha">e343a4e331572e4095f9cd0bf2160a8e4ecba767</open-checksum>
</data>
<data type="products">
<location href="repodata/products.xml"/>
<checksum type="sha">61a3d4acb8a92ba6136531cbbdfff2e04916ee8f</checksum>
<timestamp>1374073843</timestamp>
<open-checksum type="sha">61a3d4acb8a92ba6136531cbbdfff2e04916ee8f</open-checksum>
</data>- Using gpg, generate a signing key: gpg -q --gen-key
- Make a detached signature for each repodata/repomd.xml (gpg -a --detach-sign repomd.xml).
- Export the public key to repodata/repomd.xml.key (gpg -a --export <key name> > repomd.xml.key).
- Expose the directories containing the repositories via http or https
Create a BLPackage with the Upgrade Commands
Create some zypper repo definition files. Use the following format and specify the appropriate URL:
[SLES11_SP2_Updates]
name=SLES11 SP2 Updates
enabled=1
autorefresh=1
baseurl=http://blprov01-82.demodrive.com/patch2/sles11-sp2-updates-x86_64- Create a BLPackage to deploy these files (SPn-Updates, SPn-Pool, SPn+1 Updates, SPn+1 Pool) into /etc/zypp/repos.d directory on the target server(s).
Add an external command to the BLPackage that runs the following commands. Use the repository names that you specified in your repo files. Replace <n> and <n+1> with the actual Service Pack numbers you are using.
# disable the latest version repos until they are needed.
zypper mr --disable "SLES11-SP<n+1>-Pool" "SLES11-SP<n+1>-Updates"
zypper -n --gpg-auto-import-keys ref -s
zypper -n update -t patch
zypper -n update -t patch
zypper -n in -t product SUSE_SLES-SP<n+1>-migration
zypper -n mr --enable SLES11-SP<n+1>-Core SLES11-SP<n+1>-Updates
zypper -n --gpg-auto-import-keys dup -l --from "SLES11-SP<n+1>-Pool" --from "SLES11-SP<n+1>-Updates"
zypper -n update -t patch
# only for SP3 and higher
zypper -n mr --disable SLES11-SP<n>-Pool SLES11-SP<n>-Updates
Run the Service Pack Upgrade
Deploy the BLPackage and a Deploy Job to execute the Deployment