You likely already know this, but let me state it anyhow: SUSE Manager is an awesome tool to manage your SUSE and Redhat server environment. At least it is since the update to version 3 – I wouldn’t start arguing if version 2 users wouldn’t come to the same conclusion.
SUSE has put a great deal of effort in making admins’ life easier when you’re dealing with SLES and RHES servers – but what about i. e. OpenSUSE hosts? Well, that’s not officially supported, for obvious reasons, but you’ll still get much from SuMa3 even for such non-supported distros.
One area that lags most is the creation of “bootstrap repositories”. That’s what you need to provide, so that a bare-metal (or “empty VM” or “blank instance”) install not only gets the base OS installed from media, but will be able to access all those small and large packages needed to get the new instance “on board” for i. e. Salt management via SuMa3. For SLES and RHES, there’s a program called “mgr-create-bootstrap-repository”: It knows what RPMs are needed for which of the supported distros and will fetch the latest and greatest version from it’s stash (in other words, from its mirror of the product repositories). It actually is configurable in its list (it’s in /usr/share/susemanager/mgr_bootstrap_data.py), but it is linked to the SuMa3 database in a way that will only fetch from actual product repositories. (The reason behind this is, that it needs to know which “channels” to check for which product – and i. e. OpenSUSE is none of SUSE’s products, hence your OpenSUSE channels are not identifiable as such in the database.)
The beauty of “mgr-create-bootstrap-repository” is that you can run it over and over again, for example per “cron”, to re-create the bootstrap repository when you’ve received updated packages in your channels. Of course you could write your own mechanism to retrieve those required RPMs and put them into a repository, but wouldn’t it be nice if you could make “mgr-create-bootstrap-repository” do that four you? 🙂
It’s a bit trickier than at first glimpse…
Of course this article came into existence because we did just that. But before we get to the required alterations, let’s have a look at why this is a bit more difficult that grabbing some RPMs.
With distributions aiming at a wider range of users than enterprise solutions, you quickly get into seeing quicker changes, and spread, and a need to cherry-pick and to look at a broader range of sources. After all, the great advantage of enterprise distros is that you have someone doing exactly that for you, and bundling the results in a well-defined set of product repositories.
One side-effect is that you cannot use the latest Salt client (as included in OpenSUSE) to connect to the SUSE Manager 3.1 server, but will have to use an earlier version (which is included with OpenSUSE, too). Which does lead to a need to be able to specify not only which package to put into a bootstrap repository, but also which version of if. And while we’re at it, let me also point out that not all packages required to successfully board an OpenSUSE client to SuMa, do come with the OpenSUSE distribution. So it’s not sufficient to specify the RPM’s “channel” per “product”, but actually per RPM. (SUSE can handle this differently for its product channels: these all carry the information which product they are for – so you can i. e. ask the SuMa3 for the latest version of a specific package name from “all SLES 12 SP3 channels”.)
In the end, the configuration information for non-product bootstrap repositories ended up to be significantly different from that from the product bootstrap repositories:
PKGLISTLEAP = [
{ "NAME": "salt", "VERSION": "2017.7.2", "RELEASE": 14.1 },
{ "NAME": "salt-minion", "VERSION": "2017.7.2", "RELEASE": 14.1 },
"python",
"python-certifi",
"libzmq5",
"libpgm-5_2-0",
"libsodium18",
"python-backports",
{ "NAME": "rhnlib", "CHANNEL": "spacewalk_27-opensuse_leap_42.3" },
]
DATA = {
'Leap-42-3-x86_64' : {
'CHANNEL' : "opensuse-leap-42.3", 'PKGLIST' : PKGLISTLEAP,
'DEST' : '/srv/www/htdocs/pub/repositories/unknown/42.3/0/bootstrap/'
},
}
Where originally, only an RPM’s package name was given, you can now (optionally) specify the version / release information (either both or none) and the SuMa3 channel label from which to fetch that RPM. If you only specify the name, the channel label is taken from the “product” definition and the latest RPM version will be used.
The product definition differs from the SUSE-used one in that it does not provide a product id, but instead states which channel (by its label) to use per default when looking for RPMs. So when you have your bootstrap-required RPMs spread across multiple channels, you’ll have to name one label in the according DATA section and include at least the other labels with the individual RPM definition in the according package list.
Of course, as with the original format, you can create multiple package lists and even add them up, so you could define a base set and include delta lists for different follow-up versions – on the other hand it’s pretty likely you’ll use different channels for different distro versions, so once you include at least specific channel labels per RPM, that mechanism will not work out as nicely as with SUSE’s product approach.
The customized “mgr-create-bootstrap-repository”
I had originally created a completely separate version of the “create-bootstrap-repository” program – but I wouldn’t want to make that publicly available, for it contains great deals of original SUSE code. So in preparation of this article I decided to create a merged version, enabling you to with to “custom” mode via a newly introduced flag:
suma:~ # /usr/sbin/mgr-create-bootstrap-repo -h Usage: mgr-create-bootstrap-repo [options] [additional_pkg1 additional_pkg2 ...] Options: -h, --help show this help message and exit [...] --custom UNSUPPORTED: Create a custom (non-SLES) bootstrap repository (using datamodule mgr_bootstrap_data_custom by default) suma:~ #
By adding the “–custom” parameter, you activate the code to turn on the new, unsupported functionality and make it read the new configuration file. So if you put above configuration (but updating the channel labels to match your setup) into some directory on your Python path (or place it in “/usr/share/susemanger/mgr_bootstrap_data_custom.py), you’d see the following:
suma:~ # /usr/sbin/mgr-create-bootstrap-repo --custom -l 1. Leap-42-3-x86_64 suma:~ # /usr/sbin/mgr-create-bootstrap-repo --custom 1. Leap-42-3-x86_64 Enter a number of a product label: 1 Creating bootstrap repo for Leap-42-3-x86_64 copy 'salt-2017.7.2-14.1.x86_64' copy 'salt-minion-2017.7.2-14.1.x86_64' copy 'python-2.7.13-26.1.x86_64' copy 'python-certifi-2015.9.6.2-4.1.x86_64' copy 'libzmq5-4.2.2-1.1.x86_64' copy 'libpgm-5_2-0-5.2.122-6.11.x86_64' copy 'libsodium18-1.0.12-1.1.x86_64' copy 'python-backports-3.5.0-7.1.noarch' copy 'rhnlib-2.7.5-3.1.noarch' Spawning worker 0 with 17 pkgs Spawning worker 1 with 17 pkgs Spawning worker 2 with 17 pkgs Spawning worker 3 with 16 pkgs Workers Finished Saving Primary metadata Saving file lists metadata Saving other metadata suma:~ #
In order to “board” your Leap 42.3 clients, you now could proceed the same way as with the supported SLES clients: Generate a current “bootstrap.sh” file, copy it and modify that copy to at least reference the activation key you chose to set up for those clients, and call that script from your new client.
The actual patch
The patch to create the customized version can be found here. Please let me remind you that mgr-create-bootstrap-repo is likely work under copyright of SUSE (although the file itself bears no copyright statement whatsoever) and providing the patch does not imply that you nor I have any copyright on either the original nor the resulting program. But on the other hand, while I allow you to freely download and apply the patches that are linked from this page, the patches by themselves are copyrighted work from me. I ask you to redirect to this page instead of redistributing the patch file and especially not to distribute the resulting customized version of the program.
Running the customized version of the program is by no means covered by any support contract you may have with SUSE or related companies. The patches are by neither authorized nor endorsed by SUSE, Micro Focus or any other company but the author, and are especially not a work of SUSE. By downloading or applying the patch or by using a thus customized version of the original program you acknowledge that you are on your own and fully in charge of any positive or negative results of your action. And you explicitly acknowledge that the author of the patches can not be made responsible for any damage that might occur to you.
Other than that, I hope that my efforts will help you with your work!