Booting BIOS-based PXE clients via SUSE Manager and its integrated “Cobbler” component is very easy and well-documented. But as more and more hardware vendors decide to switch to UEFI, how about PXE-booting these? Continue reading
I’ve come across a little nuisance, which took some days to become buggin’ enough to make me look up the solution. Since you’re reading this article, you’re probably facing the same problem:
During the progress of debugging a Cobbler AutoYaST profile template, I wanted to take a closer look at what profile Cobbler is actually delivering to the installed system, after all the template processing. There’ a nice command for this, “cobbler system getks –name <systemname>“. But that made the many profile lines fly by on the console, so I wanted to pipe the result to “more” and into “vi”. But unexpectedly, that call threw an error:
suma:~ # cobbler system getks --name mynewsystem|more
Traceback (most recent call last):
File "/usr/bin/cobbler", line 36, in <module>
File "/usr/lib/python2.7/site-packages/cobbler/cli.py", line 653, in main
rc = cli.run(sys.argv)
File "/usr/lib/python2.7/site-packages/cobbler/cli.py", line 280, in run
File "/usr/lib/python2.7/site-packages/cobbler/cli.py", line 396, in object_command
UnicodeEncodeError: 'ascii' codec can't encode characters in position 53590-53591: ordinal not in range(128)
Again, running the command without any piping works without error, so what’s up? And more important, what needs to be done to fix it? Continue reading
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? 🙂 Continue reading