I got myself a bunch of Raspberry Pi 3s a short while ago:
...the idea being that I can use those to run a few experiments on.
After the experiment, I would need to be able to somehow remove the
stuff that I put on them again. The most obvious way to do that is to
reimage them after every experiment; but the one downside of the
multi-pi
cases
that I've put them in is that removing the micro-SD cards from the Pis
without removing them from the case, while possible, is somewhat fiddly.
That, plus the fact that I cared more about price than about speed when
I got the micro-SD cards makes "image all the cards of these Raspberry
Pis" something I don't want to do
every day.
So I needed a different way to reset them to a clean state, and I decided to
use ansible to get it done. It required a bit of experimentation, but
eventually I came up with this:
---
- name: install package-list fact
hosts: all
remote_user: root
tasks:
- name: install libjson-perl
apt:
pkg: libjson-perl
state: latest
- name: create ansible directory
file:
path: /etc/ansible
state: directory
- name: create facts directory
file:
path: /etc/ansible/facts.d
state: directory
- name: copy fact into ansible facts directory
copy:
dest: /etc/ansible/facts.d/allowclean.fact
src: allowclean.fact
mode: 0755
- name: remove extra stuff
hosts: pis
remote_user: root
tasks:
- apt: pkg= item state=absent purge=yes
with_items: " ansible_local.allowclean.cleanable_packages "
- name: remove package facts
hosts: pis
remote_user: root
tasks:
- file:
path: /etc/ansible/facts.d
state: absent
- apt:
pkg: libjson-perl
state: absent
autoremove: yes
purge: yes
This ansible playbook has three plays. The first play installs a custom
ansible fact (written in perl) that emits a json file which defines
cleanable_packages as a list of packages to remove. The second uses
that fact to actually remove those packages; and the third removes the
fact (and the libjson-perl library we used to produce the JSON).
Which means, really, that all the hard work is done inside the
allowclean.fact file. That looks like this:
#!/usr/bin/perl
use strict;
use warnings;
use JSON;
open PACKAGES, "dpkg -l ";
my @packages;
my %whitelist = (
...
);
while(<PACKAGES>)
next unless /^ii\s+(\S+)/;
my $pack = $1;
next if(exists($whitelist $pack ));
if($pack =~ /(.*):armhf/)
$pack = $1;
push @packages, $1;
my %hash;
$hash cleanable_packages = \@packages;
print to_json(\%hash);
Basically, we create a whitelist, and compare the output of
dpkg -l
against that whitelist. If a certain package is in the whitelist, then
we don't add it to our "packages" list; if it isn't, we do.
The whitelist is just a list of
package => 1 tuples. We just need the
hash keys and don't care about the data, really; I could equally well
have made it
package => undef, I suppose, but whatever.
Creating the whitelist is not that hard. I did it by setting up one
raspberry pi to the minimum that I wanted, running
dpkg -l awk '/^ii/ print "\t\""$2"\" => 1," ' > packagelist
and then adding the contents of that
packagelist file in place of the
... in the above perl script.
Now whenever we apply the ansible playbook above,
all packages (except
for those in the whitelist) are removed from the system.
Doing the same for things like users and files is left as an exercise to
the reader.
Side note:
... is a valid perl construct. You can write it, and the
compiler won't complain. You can't run it, though.
So last weekend I attended Devconf.cz in Brno and together with Dennis Gilmore gave a talk about Reproducible Builds and Fedora (Slides) which was fun and - I think - pretty well received.
Then on the following Tuesday, so three days ago, after using Debian as the primary OS on my primary computer for more than two decades, I finally made the long anticipated switch and I must say, so far I'm really happy with my new environment, even though I'm not yet again using a tiled window manager (but instead Xfce), cannot yet do all the things I could do before and even have to reconfigure a VM twice and restart another to get back wireless network after suspend and resume
So what have I done? Nothing too dramatic: I've switched to Qubes OS and now I'm running Debian jessie and stretch and Fedora and Whonix on my primary computer, just not as my primary OS 
IOW: hardware is basically software and while I want the red pill, who knows what's really inside the box?
If you have no idea what I'm talking about, this intro about Qubes OS might be helpful. Or you dive directly into this six year old post, where Joanna Rutkowska described how she partitioned her digital life using Qubes.
I'm not sure where this journey will lead me to, but I'm confident this is the right direction. And in case you wondered, I'll keep working on Debian, as far as I know now 
Scratch is a 
Yes, You Should Not discard cached ssh host keys without looking. An unexpected change of an ssh host key is always a
reason to step back from the keyboard and think. However, there are situations when you know that a
systems ssh host key has changed, for example when the system reachable under this host name has been redeployed,
which happens
increasingly often proportionally to the devopsness of your environment, or for example in test environments.
Later versions of ssh offer you the ssh-keygen -R command line to paste from the error message, so that you can abort
the connection attempt, paste the command and reconnect again. This will still ask for confirmation of the new host key
though.
Almost every sysadmin has an alias or wrapper to make handling of this situation easier. Solutions range from using
StrictHostKeyChecking no and/or UserKnownHostsFile /dev/null , turning off this layer of
securit altogether either globally or usually too broadly, to more-or-less sophisticated solutions that involve turning
off know-host file hashing, parsing client output and/or grep-sed-awk magic. grml even comes with an insecssh script
that is rather neat and that I used until I developed my own.
Later ssh versions (not including the 6.7 in Debian jessie, but the 7.4 in debian sid) do offer a -G command line
option which will give access to configuration options after the complete client configurtion was processed. This will
allow you to neatly get access to the actual hostname the ssh client will connect to. This can, in turn be used to
obtain the IP address so that all traces of the host and its IP addresses can be removed from the known_hosts file
before the actual connection is done.
The following script is the insecssh that I currently use. It only uses documented interfaces to the ssh client which
I consider rather neat.
A major new update of the 
On Wednesday, I spent the entire day in court in Follo Tingrett
representing 
I am boarding my flight to Brussels to attend 
It's that time of the year :-) And FOSDEM is fun. But this year I won't be
going; there was a scheduling conflict, and I didn't really have anything
new to present (although I probably could have shifted around priorities
to get something).
But FOSDEM 2017 also means there's a year since FOSDEM 2016, where I
presented 
What probably pissed me is the condensing note in the comment, how does he know what pressures an another individual might be in. It s almost like saying You are refugee because you made a wrong life choice or something to that effect which again is stupid.
I actually feel/felt embarrassed to bring this up as I truly am 
Debian LTS
November marked the 21st month I contributed to 
The past few days I've been doing more arduino-work. In between dying of sleep-exhaustion.
One thing that always annoyed me was that I had to hard-code my WiFi credentials in my projects, with code like this: