Testing Chef cookbooks on travis-ci / drone.io with chef-zero

If you are using your own Chef cookbooks you certainly have some sort of tests for them. Likely running test-kitchen with docker or vagrant driver. That setup works perfectly fine locally or on a self-hosted Jenkins server. However building them on public CI platforms like travis-ci or drone.io is not possible like that. Caused by their virtualization technology, we cant use test-kitchen with docker or vagrant driver there.

What people usually do to solve this: Use a cloud driver like EC2, Cloudstack, Rackspace so travis-ci will spin up a VM there. However I found this very clunky. This require additional accounts and costs with a Cloud provider.

So what I did is mimicing how the chef-zero provisioner for test-kitchen works as seen here https://github.com/test-kitchen/test-kitchen/blob/master/lib/kitchen/provisioner/chef_zero.rb
It basically boils down to installing Chef, copying all dependency cookbooks in place along with some configs and then running chef-client with chef-zero.

Read more

Spacewalk Remote Command Execution with Ubuntu / Debian clients

In my last article I’ve shown you how to get OSAD working for Ubuntu clients. Which comes in handy for my new article about remote command execution. With the help of OSAD the commands will be executed immediately and you dont need to wait for clients to check-in and pick them up.

Read on after the jump…

Read more

Enabling Spacewalks OSAD for Ubuntu clients

What is OSAD?

Spacewalk clients are checking in with Spacewalk every 240 minutes by default. You can change this in /etc/rhn/rhnsd but it will still be polling for scheduled actions and not receiving them instantly.
OSAD solves this problem. Its based on Jabber and runs a osa-dispatcher on the Spacewalk server which tells clients to please check-in immediately when there are actions scheduled for them.
You can read more on it here https://fedorahosted.org/spacewalk/wiki/OsadHowTo

Do I really need it?

That depends on your individual setup and what you are using Spacewalk for. For most people its probably ok to have scheduled actions be performed with a delay. For some it might not.
Especially if you want to use the “Command Execution” capability of Spacewalk, you certainly want them to be executed asap. I’ll be showing you how to get that working with Ubuntu clients in my next article.

So read on after the jump how to get OSAD running.

Read more

Chef Cookbook for Spacewalk server and clients

I wrote two cookbooks to work with Spacewalk and submitted them to Chefs supermarket.

Read on after the jump how to use these cookbooks. I promise its really simple tho

Read more

Kickstarting and Provisioning Ubuntu systems with Spacewalk

In the comments of my last article someone asked about provisioning Ubuntu clients with Spacewalk. As I never tried this it got me curious.So I played around with it. It was a bit tricky but in the end I got it working pretty well.

First of all you need a Ubuntu repository and channel in your Spacewalk like describes in this article.

Now for some prerequisites

yum install cobbler-loaders
# SELinux should be disabled in general for Spacewalk to avoid several problems
setenforce 0

Read more

Finding obsolete and unused Roles in Chef

If your Chef environment has grown and its time for a cleanup, here is an easy way to find unused and obsolete Roles.
This works as long as the roles/*.rb files are named exactly like the roles.

# in roles/ directory do
for f in *.rb; do echo $f; done | cut -d'.' -f1 | tr '\n' '\0'|xargs -0 -L1 -I '$' sh -c "echo '$:';knife search node 'role:$'|grep Node" > result.txt
# then
for f in *.rb; do echo $f; done | cut -d'.' -f1 | tr '\n' '\0'|xargs -0 -L1 -I '$' sh -c "echo '$:';knife search node 'roles:$'|grep Node" > result2.txt

This will output role name and the hosts using it. Roles not having nodes in both result files are unused and can be removed.

Sample output

Node Name:   auth-app2.prod1.example.lan
Node Name:   auth-app3.prod1.example.lan
Node Name:   auth-app1.prod2.example.lan
Node Name:   ch-esearch3.prod1.example.lan
Node Name:   ch-esearch2.prod2.example.lan

Reason why you need to run it twice is first command searches for nodes having exactly that role and second one searching in expanded run lists.

Configuring Errata for Ubuntu with Spacewalk

In my last article I have shown you how to get Ubuntu servers registered and integrated with Spacewalk.

However something important is still missing: Getting Errata into Spacewalk for Ubuntu systems. Errata are security, bugfix, enhancement advisories published by distribution vendors like Debian, CentOS, RHEL, Ubuntu. These Errata can be imported to Spacewalk and show/email which systems/packages are affected along with information like CVE numbers. You can then “apply” the Errata to these systems, triggering a remote update. That way you will always know if your systems lack critical updates.

Unfortunately, there is no general source or feed getting these Errata into Spacewalk. A good source are the security mailing lists of the vendors but you still need to parse them and import via API. For CentOS / RHEL there exist a few scripts:

However for Ubuntu there didnt exist such a script so I had to do one myself. Read on where to get and how to integrate it ! Read more

Registering Ubuntu and Debian Servers with Spacewalk

You probably have heard of Spacewalk, the systems management solution for RHEL / CentOS and other RedHat-based systems.
It provides and manages content / package updates for all your servers along with some other features like kickstarting / bootstrapping nodes, audits and some simple config management if you dont run Chef or Puppet or similar.

However, did you know that you can meanwhile also (fully) manage your Debian/Ubuntu systems with Spacewalk ? Documentation on this is still sparse and you have to figure out certain things on your own.
Read on after the jump how to completly setup and configure Spacewalk 2.2 to work with Ubuntu clients. Including Errata !

Read more

GPG signing RPMs with Sigul Signing Server & Koji integration

When you are building your own RPMs and distributing them either on your own infrastructure or to the public, you should consider signing them with a GPG key. That way the client machines that install your RPMs can verify the integrity and authenticity of what they are installing.

GPG signing can either be done manually, which is fairly easy but unhandy or you can use a way more automated and solid way, using the Sigul Signing Server by Fedora.

Sigul keeps the private keys used for signing on its server and they arent accesible by the clients who want to sign RPMs. All requests by Sigul Clients to Sigul Server are sent over the Sigul Bridge which relays them. This allows signing RPMs from various machines, without having access to actual keys being used. So you never communicate directly with the Server which can and should be isolated from the rest of the world and only allow connections from/to the Bridge in the Firwall.

Read more

Getting RPM built by Koji into YUM-able repo

By following my article series about Fedoras RPM build system Koji, you should by now have a fully working setup that even builds RPMs from Git.
However, by design, the built RPMs cant be directly used as a yum repo. They need to be transformed first. Therefore the tool “mash” exists.
Luckily setting up mash is easy compared to Koji itself.

yum install mash
# create a storage path, this can also be a network mount
mkdir -p /mnt/custom-repo/{mash,rpm}
ln -s /mnt/custom-repo/mash/centos6-release/ /mnt/custom-repo/rpm/centos6

Read more