Reminder: Puppetcamp 2011

Just a reminder for all Puppet Lovers.

Puppetcamp 2011 is approaching and there are still some tickets available.

So when you are using Puppet or when you are interested in using it, join the crowed of Puppet Lovers over there in Amsterdam.

You can see on the attendees page, there are many people from well known companies, eventually it will be a good thing talk about your experiences with them, grab a drink and do some smalltalk.

My colleague, Felix, will also be there, and he did some work on some nifty puppet modules, so catch up with him and talk to him.

Remark: I'm not affiliated with Puppetlabs, but I'm a fan of Puppet :)

Well Done Unatty

I just updated my production workstation from Maverick to Natty.

And I was impressed with the smoothness.

Unity makes a good look even on a dual screen setup. Some glitches still, but hey, we are not final yet :)

So from me to the Unity/NUX/Integration/Foundation Team:

Well done Folks...good work as always.

Wrongly issued SSL Certificates of Comodo and the lost of trust

You all heard about the issue of wrongly aquired SSL Certs for several well known domainnames.
(References: etc.)

This is really terrible.

The response of Comodo which was published here,, doesn't give me enough informations about what happened.

Honestly, the result of this is, that I lost the trust into Comodo as Root CA and into their way of handling SSL Certificate requests.

As far as I can read from the Comodo announcement, the attacker already knew how to gain access to an account of a customer of Comodo.

That means, that someone could request a Cert for domains which are not belonging or which are not requested on behalf of a third party by a Comodo Reseller. There was no humanly triggered security or privacy check (e.g. Calling the requester and/or the domain owner who is requesting the Cert)  from an employee of Comodo.

But this is what I expect, even when Comodo is one of the cheapest SSL Cert Sales organisation.

It's not about a technical error, it's about "Trust" as in "Comodo, Creating Trust Online" (the Slogan on their Website). If you pay a company to verify that you are you, because you want your customers to trust that what they receive is coming from you (speaking about the Internet), then this company you pay needs to pay more attention and needs to invest into more human checks.

Having site accounts and just issuing a cert because the system thinks "Oh a known customer who is coming back" is not a good idea. You always should re-check if the requester (even with a valid account) is really the one who requested the cert (not the reseller)

Automation is good, automation helps to save money, but Trust is more valuable then saving money in this regard.

For me personally, I lost the trust, and I really would like to see that Comodo as Root CA will be dropped totally from the Browsers SSL Cert Store.

Why I'm always getting the impression....

...that Ubuntu Users are trying to be more Elite then other Users?

This is not the first time, but I'm tracking this behaviour since 2005...

Just a thought of an Anti-Elite

Facter of the Day: $is_chroot

If you run "Puppet" inside a chroot (like I do during an FAI Deployment run), it would be handy to not (re)start or stop services.

So, a couple of days before I asked the question "How to determine if you are running puppet inside a chroot".

The first answer was, thanks again to Daniel Pittman:

export FACTER_chroot=whatever 
chroot puppetd -vdt --waitforcert var/log/puppetrun.log

You can then question the facter "$chroot" inside your class or node recipe.

But there is another way, IMHO more elegant way:

initramfs-tools and udev are providing a dynamic way of how to determine if you are running in a chroot or not.

Just check /var/lib/dpkg/info and read e.g. initramfs-tools.preinst.
You find this shell function:

chrooted() {
# borrowed from udev's postinst
if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then
# the devicenumber/inode pair of / is the same as that of
# /sbin/init's root, so we're not in a chroot and hence
# return false.
return 1
return 0

There you go.

Now...let's convert it into a puppet facter.
To do this, create a module e.g. chroot
$ mkdir -p /etc/puppet/modules/chroot/{manifests,lib,lib/facter}

Create a file named "ischroot.rb" with the following content:

require 'facter'

isChroot = %x{if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then echo "false" ; else echo "true" ; fi}.chomp.downcase

Facter.add("is_chroot") do
        setcode do

Save it. There you go. (Eventually restart your puppetmaster, when you are not running the puppetmaster under apache2 with mod_passenger)

Now, your puppet client will sync your plugin dir, and installs the ischroot.rb in /var/lib/puppet/lib/facter/ischroot.rb

When you need to know if you are inside a chroot or not, just ask in your class or node recipe:

case $is_chroot {
'true': {
# do whatever you need to do when you are in a chroot
'false': {
# do whatever you need to do when you are not in a chroot

Hope it helps you :)


Oh's not the first time, that I'm reading a really big flamewar...but this is...AWESOME!!

Not that we are only making a fool of ourselves, no, we are just giving everybody outside of our business a picture, that most of the OpenSource people are just kids in a sandpit.

I know, I know, commercial interests are coming first, but honestly, do we need to nitpick?

There is Mark, with a clear view of what he wants to achieve on the linux desktop, and prominent spokesman of Canonical and Ubuntu.
There is  GNOME, KDE, Jeff, Aaron, Jono, GregKH, Jef oh I'm too lazy to write down all the names involved.

Seriously, I'm a true believer, that the OpenSource Business as we know it, is not going to survive. We need to change things, as we did in the past, as we do now, and as we are going to do in the future. Community wise and especially in commercial business.

But what's going on here?

We're digging our own grave. Nobody will take us as serious business partner, when we will go on as we do right now. Not in the server market, not in the desktop market.

Really, OpenSource is about choice. If someone has a view of doing this like so, and others do have another view, let's fork it, change it, see if it works. Other projects or stakeholders or companies will take what they need, and leave the rest to the sharks.

Nobody, right now, is without a sin. Everyone involved has something to say, whysoever, someone is pissed personally, another one is pissed, because it's not what he or she expects to see from the other party. and so on and so on.

And then there are the fanboys and fangirls. They do have their own view, and they rattle, too (I include myself into this group, but I'm really a fan of Ubuntu, RH, SuSE so I could rattle a lot)

But really, right now, I see more destruction then cure. It's more "You poked my eye, I'll slice your nose". This is really not going to help here.

We are destroying ourselves, we are throwing away a good reputation.

Hopefully we can settle all this sh*t during a conference sitting around a table with some cool drinks and smoking a pipe of peace.

Anyways, what's amazing to see, that only pawns are fighting. Not the kings or queens. There is no Jane (Canonical) or Jim (RedHat) or Ronald (Novell)

I really would like to see, that we are going back to business. Let's get Unity rolling, let's improve Gnome-shell and Plasma, there is still so much to do and we all can participate and we could all have a win-win situation.

But please, let us stop this celebrity death match...there will be no winner.

My 2 Euro Cent

[Unity Idea] What about a Finder Menu?

Honestly, I was never a friend of Apples OS, but working for some time now with Unity I found myself in a bit of trouble.

The launcher panel is quite nice, but I don't want to have it in my way, and more worse, there is no task bar anymore. So, having a lot of applications running in one session, I need to find a simple way to get them back, very fast.

I mean, I minimize them when I don't need them, but I'm a bad guy with tabbing around the window list.

So, I was thinking then: I miss my applications, I want them in a menu in my panel...why don't we have such a thing like Apples Finder app? You know that's the menu entry in the main menu and the menu entries are showing all running apps. When clicking on one of the menu entries, it will bring the application to the foreground.

"But we do have that with the launcher in Unity" you will say, but I don't like to rely on icons. Icons are good, but sometimes I really like a textual representation.

So, I sat down now, for 15 minutes or so, and played around with python dbus and the python appindicator library and hacked something together.

It's just a proof of concept, and far from usable...but I think you get the idea.

The AppFinder would consist of two services:

  1. AppFinder-Service
    This is a dbus session service or dbus system service running in the backround and listening to dbus calls like "AddApp" or "AddAppDocument"
  2. AppFinderIndicator Service
    This service daemon runs in your desktop session (unity, plasma whatever) and does all the UI work.
So, having both running, and playing around with dbus-send:

$ dbus-send --session --print-reply --dest="com.sourcecode.AppFinder" /com/sourcecode/AppFinder com.sourcecode.AppFinder.AddApp string:"gnome-terminal" boolean:false

This call will add an menu entry for an application which is not document oriented. Gnome-Terminal in this example, doesn't have "real" documents (or you could see the open terminal tabs as documents, but I don't).
Sending this dbus call to the AppFinder Service will result in another dbus call (inside AppFinder Service) to the AppFinderIndicator service, which then results in something like this:

Now, let's imagine you open OpenOffice or LibreOffice or KWord, and those apps are mostly document oriented, which means, one app can have several documents opened.
So when one of the app starts, it could send this dbus call:

$ dbus-send --session --print-reply --dest="com.sourcecode.AppFinder" /com/sourcecode/AppFinder com.sourcecode.AppFinder.AddApp string:"OpenOffice Writer" boolean:true

Now it works just the like call as above, but indicates the AppFinder service and the AppFinderIndicator service, that we will have documents attached to this app.

It'll look like this:

Imagine further, OpenOffice opens up, and the first task it does is to create a new writer document. During this task it could send out a dbus call like this:

$ dbus-send --session --print-reply --dest="com.sourcecode.AppFinder" /com/sourcecode/AppFinder com.sourcecode.AppFinder.AddAppDocument string:"OpenOffice Writer" string:"New Document"

This will result UI wise in this:

Now, eventually when you click on one of the app entries, it will unminimize the app window and brings it to the foreground.

Anyways, I'm not an UI expert, and it looks like that I have a different workflow regarding my desktop as others, but I find this idea nifty.

If someone wants to take this idea to a production ready app, please do so.

And for others interested in the underlaying python code, here we go:

import gobject
from dbus.mainloop.glib import DBusGMainLoop
import dbus
import dbus.service

class AppFinder(dbus.service.Object):
def init(self):

@dbus.service.method(dbus_interface='com.sourcecode.AppFinder', in_signature="sb",out_signature="s")
def AddApp(self,app_name,has_documents=False):
return app_name
def AddAppDocument(self,app_name,document_name):
return (app_name,document_name)

if name=="main":


import gobject
import gtk
import appindicator
from dbus.mainloop.glib import DBusGMainLoop
import dbus
import dbus.service

class AppFinderClient(dbus.service.Object):
def init(self,menu):
def AddAppMenu(self,app_name,has_documents):
if not self.menu_items.has_key(app_name):
if not has_documents:
def AddAppDocumentMenu(self,app_name,document_name):
if self.menu_items.has_key(app_name):
if self.menu_items[app_name].has_key("document_menu"):
if not self.menu_items[app_name]["document_items"].has_key(document_name):

if name=="main":
ind=appindicator.Indicator("appfinder-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS)


Honestly, this is all a 20 minutes hack, and I know you can do it better, but just a mockup idea, not bad.

Oh and btw..;)

...some muppet calls Kubuntu...

Building Packages for CentOS 5 on Ubuntu/Debian

Normally, when you are using Debian or Ubuntu, you really don't need anything like RHEL or SLES.

But sometimes you will be forced to look over your plate and have to find ways how to make things just work on your chosen distribution.

As written before my colleague Felix and I are working on CentOS Deployment via FAI on Ubuntu. And while we succeeded the starting steps we went further. Means, integrating Puppet during the initial FAI run etc.

For this to happen, you need some software which are not available directly from the enterprise distribution RHEL (CentOS is an real OpenSource Fork of this commercial distribution). For this problem some good people from Fedora started the EPEL Project. The backport packages from Fedora (which is officially the upstream of RHEL) and compile them from source on RHEL 4/5/6.

Sadly, they don't claim officially to be fully compatible with CentOS, so what does a good admin do? Yes, he takes the sources and compiles them for the used distro, in our case CentOS.

But, we didn't want to do that on CentOS itself, we needed a way to do it on Ubuntu.

So, what possibilities do we have?


There are other possibilities but those two are the easiest ones.
First I tried "mach" on lucid, but this wasn't so successful. It didn't work and reading many sources on the internetworks, "mach" is somehow outdated and "mock" is the way to go.
"mock" is in the debian and ubuntu repositories, so it's just an "apt-get install mock" away from work.

But, "mock" in Debian and Ubuntu (unmodified sync from debian) doesn't have any support for CentOS.
Therefore, we needed to find some bits and pieces to get "mock" to work.

Here we go...this is the configuration for starting a "CentOS build system on Debian/Ubuntu".

config_opts['root'] = 'centos-5-x86_64'
config_opts['target_arch'] = 'x86_64'
config_opts['chroot_setup_cmd'] = 'install buildsys-build'
config_opts['dist'] = 'centos5' # only useful for --resultdir variable subst

config_opts['yum.conf'] = """
# grub/syslinux on x86_64 need glibc-devel.i386 which pulls in glibc.i386, need to exclude all
# .i?86 packages except these.
# exclude=[1-9A-Za-fh-z].i?86 g[0-9A-Za-km-z].i?86 gl[0-9A-Za-hj-z].i?86 gli[0-9A-Zac-z].i?86 glib[0-9A-Za-bd-z].i?86
.i?86 g[abcdefghijkmnopqrstuvwxyz].i?86 glib2.i?86 glib-.i?86 glib.i?86 -devel.i?86 ruby-libs*.i?86
# repos

baseurl=http://<hostname of your nearest centos mirror>/centos/5/os/x86_64/

baseurl=http://<hostname of your nearest centos mirror>/centos/5/updates/x86_64/




You save the file in /etc/mock and name it centos-5-x86_64.cfg.
After creating this file you need to edit the file "/etc/mock/site-defaults.cfg".
Find the line with the comment "# config_opts['plugin_conf']['ccache_enable'] = False"
Remove the "#" and change the value from "False" to "True".

Now you are able to rebuild source rpms from EPEL.

To do that just download from src.rpm from the EPEL repository and save it somewhere.
Now execute the following:

$ sudo mock -r "centos-5-x86_64" --arch="x86_64" <filename of src.rpm>

"mock" will now create something like a chroot and a package cache and a chroot tarball (you know that from sbuild or pbuilder) and will build your src.rpm inside a clean chroot.
No need to pollute your system with cruft. It needs some time for the first run, but after that it's quite speedy, just like pbuilder.
The resulting binary you will find in "/var/lib/mock/centos-5-x86_64/result/"
Be careful, it will clean that directory when you run another build, so catch the result before you do another build run.

Now, it could be that you build a package which is a build dependency of another package. To use this newly build package, you should think about creating your own yum repository.

This is also easily doable on Ubuntu or Debian. You just need an webserver and the "createrepo" tool.
"createrepo" is in the package "createrepo" (surprise, surprise), so "apt-get install createrepo" is your friend to success.

You create a directory e.g. "/srv/repositories/centos/5/mypkgs/x86_64/RPMS" and move the resulting binary packages for your x86_64 arch into this directory.
Now you just execute:
$ createrepo /srv/repositories/centos/5/mypkgs/x86_64/

and you are done with creating a yum repository.
You can now add this repository to the centos-5-x86_64.cfg file, and with the next call to mock all package caches will be updated and your src.rpm, which depends eventually on a package you just put in your own package repository, will build successfully with your packages inside your yum repository.

CentOS 5 deployment with Ubuntu + FAI

Thanks to the work of Michael Goetze, who worked on CentOS support in FAI, we are now able to deploy a standard install of CentOS 5 (5.5) in round about 143 seconds.

The default chroot tarball was created using the "rinse" tool by Steve Kemp.
That reminds me, that I still have some patches for this tool pending and as well some more fedora distro support files to push to Steve.

The important part about this is, that CentOS is not so different from RHEL, so if you have a working yum repository for RHEL, then you are able to install RHEL as well. But having a

And the time for a standard install (which means yumgroup core) of 143 seconds feels like we are much faster then kickstart or whatever you use today to automatically deploy your CentOS or RHEL distribution.

The default installation system is still an Ubuntu 10.04 with FAI 3.4.3, so when you already have a running FAI installation, you don't have to change much.

Last but not least, the CentOS work of Michael will be part of the upcoming FAI 4.0