I sadly had to miss out on the FOSDEM event. The entire weekend was filled with me being apathetic, feverish and overall zombie-like. Yes, sickness can be cruel. It wasn't until today that I had the energy back to fire up my laptop.
Sorry for the crew that I promised to meet at FOSDEM. I'll make it up, somehow.more ...
While still working on a few other projects, one of the time consumers of the past half year (haven't you noticed? my blog was quite silent) has come to an end: the SELinux System Administration - Second Edition book is now available. With almost double the amount of pages and a serious update of the content, the book can now be bought either through Packt Publishing itself, or the various online bookstores such as Amazon.
With the holidays now approaching, I hope to be able to execute a few tasks within the Gentoo community (and of the Gentoo Foundation) and get back on track. Luckily, my absence was not jeopardizing the state of SELinux in Gentoo thanks to the efforts of Jason Zaman.more ...
After updating my workstation, I noticed that keychain reported that it could not load one of the GnuPG keys I passed it on.
* keychain 2.8.1 ~ http://www.funtoo.org * Found existing ssh-agent: 2167 * Found existing gpg-agent: 2194 * Warning: can't find 0xB7BD4B0DE76AC6A4; skipping * Known ssh key: /home/swift/.ssh/id_dsa * Known ssh key: /home/swift/.ssh/id_ed25519 * Known gpg key: 0x22899E947878B0CE
I did not modify my key store at all, so what happened?more ...
A few days ago a vulnerability was reported in the SELinux sandbox user space
utility. The utility is part of the
policycoreutils package. Luckily, Gentoo's
sys-apps/policycoreutils package is not vulnerable - and not because we were
clairvoyant about this issue, but because we don't ship this utility.
While working on the second edition of my first book, SELinux System Administration - Second Edition I had to test out a few commands on different Linux distributions to make sure that I don't create instructions that only work on Gentoo Linux. After all, as awesome as Gentoo might be, the Linux world is a bit bigger. So I downloaded a few live systems to run in Qemu/KVM.
Some of these systems however use cloud-init which, while interesting to use, is not set up on my system yet. And without support for cloud-init, how can I get access to the system?more ...
At my work, I have the pleasure of being involved in a big data project that uses Hadoop as the primary platform for several services. As an architect, I try to get to know the platform's capabilities, its potential use cases, its surrounding ecosystem, etc. And although the implementation at work is not in its final form (yay agile infrastructure releases) I do start to get a grasp of where we might be going.
For many analysts and architects, this Hadoop platform is a new kid on the block so I have some work explaining what it is and what it is capable of. Not for the fun of it, but to help the company make the right decisions, to support management and operations, to lift the fear of new environments. One thing I've once said is that "Hadoop is the poor man's mainframe", because I notice some high-level similarities between the two.more ...
After reorganizing my salt configuration, I received the following error:
[ERROR ] Template was specified incorrectly: False
Enabling some debugging on the command gave me a slight pointer why this occurred:
[DEBUG ] Could not find file from saltenv 'testing', u'salt://top.sls' [DEBUG ] No contents loaded for env: testing [DEBUG ] compile template: False [ERROR ] Template was specified incorrectly: False
I was using a single top file as recommended by Salt, but apparently it was still looking for top files in the other environments.
Yet, if I split the top files across the environments, I got the following warning:
[WARNING ] Top file merge strategy set to 'merge' and multiple top files found. Top file merging order is undefined; for better results use 'same' option
So what's all this about?more ...
Part of a system's security is to reduce the attack surface. Following this principle,
I want to see if I can switch from using regular salt minions for a saltstack managed
system set towards
salt-ssh. This would allow to do some system management over SSH
instead of ZeroMQ.
I'm not confident yet that this is a solid approach to take (as performance is also
important, which is greatly reduced with
salt-ssh), and the security exposure of the
salt minions over ZeroMQ is also not that insecure (especially not when a local firewall
ensures that only connections from the salt master are allowed). But playing doesn't hurt.