I’ve just devoured Cory Doctorow’s “Unauthorized Bread” (pun intended), and basically it puts a very good story to the same message that is brought to us in the preface of “The Linux Commandline“… which is, rule your devices, don’t let them rule you.
In related news, i just got this cartoon off the heise forum:
So the other day I got an advanced discontinuation warning for openSUSE Leap 15.0 which reaches EOL on November 30, and today I took that Leap (fun intended) and used my trusted little leapup script to upgrade my systems to 15.1… and what can I say, so far I’ve done my laptop and my desktop which could have been a bit tricky because there’s so much stuff installed, and one of my cloud servers – and except for some little bits of LVM juggling because / ran full on my desktop all went without a hitch.
That’s pretty much all I have to report about it.
Edit: Finished the second cloud server, no problems at all.
Finale grande: all systems upgraded without major problems. That’s how that is supposed to work.
So I’ve used my trusted little leapup script for an upgrade from 42.3 to 15.0, and in three out of three cases it was not fun…
On my two cloud servers all I had was some glitchiness with the firewall, and I have to figure out how to rebuilt the latest version ot the xtables addons on Leap 15.
On my desktop I guess I’ve screwed up during the first stage of the upgrade, and missed one dependency quirk or someting, but … that left me dead in the water on that machine. Actually had to do a standard upgrade from DVD on that one.
I am not looking forward to upgrading the main firewall. Guess that’ll wait until my laptop comes back from repairs so I can use that one as a second testbed.
That being said, I found a few typos in my leapup script that bit me in the *** too.
Lately I’ve been experimenting with ansible a lot.
Dealing with linux hosts is straightforward enough, and you’ll be able to find all sorts of information with google, but ansible can also deal with windows hosts, and that’s where it gets a bit more interesting.
To be able to manage a windows host with ansible, you have to:
create a user account on the machine (or in the windows domain) who has to be a member of the administrators group
make sure you use the right ansible modules, if there are special modules for windows for any given purpose they will start with win_, for example instead of copy: for a windows host you’d use win_copy. Some modules simply do not exist as a win_ version, but the generic unix version does not work on windows, for example the telegram notification module, but that you can safely delegate_to: localhost when you want to use it (unless your management host does not have internet access).
set up a group in your inventory for your windows hosts, and add the variables for winrm access as group_vars for that group
Here’s an example for a simple playbook that installs all the latest updates, and reboots the target host if necessary:
You’ll notice that the handler: that reboots the target has a when: condition that uses a variable I haven’t mentioned yet. It’s easy enough: two of the windows hosts I am managing have dual boot setups, by default they reboot to linux. I’m dealing with that by creating TWO host entries in my inventory, the regular one, and one with a different name, and two host_vars: