New GPG key

Since my old key expired, I created a new one following the amazing instructions of kargig.

Transition statement

Date: 2014-02-18

For a number of reasons I've recently set up a new OpenPGP key,
and will be transitioning away from my old one.

The old key will continue to be valid for some time, but I prefer all
future correspondence to come to the new one.  I would also like this
new key to be re-integrated into the web of trust.  This message is
signed by both keys to certify the transition.

The old key was:

pub   1024D/57DC0078 2008-12-03 [expired: 2013-12-03]
      Key fingerprint = 9FF9 17C7 6563 CC6F 486F  19E1 8C37 6831 57DC 0078

And the new key is:

pub   4096R/29485B97 2014-02-18
      Key fingerprint = 7B66 9D4E 34C3 DE6C 928A  317B 9640 E4FA 2948 5B97

To fetch the full key from a public key server, you can simply do:

  gpg --keyserver --recv-key 0x9640E4FA29485B97

If you already know my old key, you can now verify that the new key is
signed by the old one:

  gpg --check-sigs 0x9640E4FA29485B97

If you don't already know my old key, or you just want to be double
extra paranoid, you can check the fingerprint against the one above:

  gpg --fingerprint 0x9640E4FA29485B97

Theodoros Chatzimichos

You can find the above text here, signed by my old key and my new key.

SUSE Hack Week 9 report

So, Hack Week 9 is over! It has been a great experience organizing it, and a very productive week for me. I didn’t manage to work on the Puppet idea as originally planned, as I couldn’t find anyone to work with me. Collaboration is a keyword for such events, thus I chose to work on the kiwi_spec idea with a bunch of colleagues. Bellow is a short summary of what we achieved:

  • kiwi_spec is now open source, the code is under openSUSE organization (link)
  • Another library was created, rstuk, that contains common functions between kiwi_spec and studio_spec.
  • A lot of duplication between those tools is now avoided
  • Functionality of studio_spec is easily inherited to kiwi_spec
  • We plan to open source studio_spec at some point as well, rstuk will make that faster since it is already done progressively
  • kiwi_spec got a better output formatter, that lies in rstuk
  • Configuration files have moved to cfg/, as it is done in studio_spec
  • Better packaging for development machines.
  • There is a gem for rstuk that is already published to rubygems. A gem for kiwi_spec is also planned
  • kiwi_spec supports more archs than x86 and x86_64, such as ppc64 and s390
  • Optional usage of pigz is possible for more speed
  • Added support for building and testdriving ISO images
  • Improved testdrive, cleanup images when the test run is green
  • Various small bugfixes

The project is not complete though. We still need to extract lots of code from studio_spec, especially the parts that deal with automated deployment of images, since of those procedures are similar between kiwi_spec and studio_spec.

A lot of other interesting projects came from this week as well, in various fields like Desktop (KlyDE), ARM, Cloud, Kernel, Virtualization etc. In the Hack Week webpage you can find the winners of the awards (congratulations guys!) plus all of the projects that took place.

Looking forward for Hack Week 10!

I’m going to oSC13

I’ll be there! This is a very special event for me, as I’ve been one of the major organizers of oSC12 in Prague, plus I’ve done some remote tasks for oSC13 as well. I’m going to be helping during the event for sure as volunteer. But it is also very special for me because this year it is taking place in my country, in my favorite Greek city (Thessaloniki!!) and is completely organized by close friends of mine!

oSC is mainly organized by the community this year and it is the first year this is happening. I suppose for SUSE, that has been organizing all the past oSC events, it is a bet, but so far I believe it is going great. This is the first year the event is going away from a city that has a SUSE office. As I said in the past though, oSC12 was also organized by the community in its largest part as well. Personally, I’ve been working on this only during my free time, and I got approval to work on it during my regular work time only the last two weeks before the event (and still haven’t been completely relieved from my regular job). So we did the first step already, thus (as I mentioned last year during the live openSUSE Project meeting) I strongly believe that the event is ready to be community driven completely.

I’m also going to give a workshop and a talk, both regarding Puppet. The workshop is going to be pretty much the same I did last year with Alec Warner during the co-hosted Gentoo Miniconf, where we presented the basics of Puppet through 12 examples. The presentation is going to be around the so-called “Lego Pattern”, where I’m going to explain how to organize the Puppet modules in order to get reusable blocks, easy and quick refactoring, good tests, and clean/documented code, in an early stage of a set of best practices that the PuppetLabs guys are trying to enforce us.

Anyway, I am sure that it is going to be a great event, and I’m really looking forward to it. See you there!


Logo “the Greeko”:

PS: For more artwork, the full schedule, and various other information regarding the conference, visit the oSC13 webpage, and be sure to frequently check the openSUSE News

We’ve got green smoke!

openSUSE 12.3 is out! It’s fast, open, awesome, green and sexy, go grab it like there’s no tomorrow!

SUSE Hack Week 9 and openSUSE 12.3 Release Party

Hack Week is a special week for the SUSE engineers. For one full week once or twice per year we are allowed to work on anything we want, even if it is completely irrelevant to our regular job. We’re highly encouraged to work on something openSUSE related though of course. Hack Week 9 is going to take place at April 8. My plan is to work either on providing better openSUSE support on third party Puppet modules, or on open-sourcing one internal RSpec test suite for KIWI.

This is my second participation in Hack Week, and is very special for me as I’ve been also asked to be part of the organizing committee, where I gladly accepted! It’s been so far a very nice experience, so probably I’m going to participate as organizer for the next one as well.

We’re going to have a kickoff meeting at the Prague office, along with openSUSE 12.3 Release Party, on 28th of March, at 16:00, where everyone is welcome to join us!

More info at the Hack Week web site and the announcement at openSUSE News.

Featured quote at SUSE LinkedIn profile

A few days ago the SUSE HR department asked me to send them a quote about my work in SUSE, in order to boost the company presence in social media. My quote is now featured at the LinkedIn profile of SUSE! It’s an honor for me to be there. And don’t forget, we’re hiring, there are 43 open positions currently available!

Puppet Portage module version 2.0

After a few months of a lot of hard work, I’m thrilled to announce the availability of the Portage Puppet module version 2.0!


This module was initally developed by Lance Albertson and some other guys from OSUOSL. Adrien Thebo, who by the way works for PuppetLabs, stepped in after some time and did some cleanup in the native types/providers that were included in there, and later he took over completely. Judging from the commit log though, the module was not getting the love it deserved :-)

Meanwhile, we, the Gentoo Infrastructure team, decided to migrate from Cfengine 2 to Puppet. So I started digging around to check about Gentoo support in Puppet. Given the complexity of the package management in Gentoo, I didn’t have high expectations, and I wasn’t wrong. The internal Puppet Portage provider has pretty basic support, so I had to get my hands dirty and write something decent. Then I stumbled upon Adrien’s puppet-portage repo, which made me felt like I hit the jackpot. I started testing it to understand the functionality it covers, and meanwhile I spent some time reading books and experimenting with Puppet and Ruby, as both of them were pretty new to me.

Right after the Gentoo Miniconf I finally contacted Adrien and expressed my interest in developing more functionality to the module. In 3 – 4 months of hard work we managed to have all the functionality I had in mind, which is impressive. It was a great journey, as I had the chance to do quite some stuff in a technology that was completely unknown to me. Adrien was very helpful in giving me correct directions, and I even managed to write a native type and provider from scratch! Thanks a lot Adrien!

Special thanks also to Zac Medico, main Portage developer, for all his valuable input.


Let’s see all the functionality this module provides. Most of the info below is stolen from the README file.

1) /etc/portage/package.*/*

There is a set of native providers that add support of handling entries for
/etc/portage/package.keywords, /etc/portage/package.use, /etc/portage/package.mask, /etc/portage/package.unmask. Examples:

package_use { 'app-admin/puppet':
  use     => ['flag1', 'flag2'],
  target  => 'puppet-flags',
  version => '>=3.0.1',
  ensure  => present,

“$use” can be either a string or an array of strings.

package_keywords { 'app-admin/puppet':
  keywords => ['~x86', '-hppa'],
  target   => 'puppet',
  version  => '>=3.0.1',
  ensure   => present,

“$keywords” can be either a string or an array of strings.

package_unmask { 'app-admin/puppet':
  target  => 'puppet',
  version => '>=3.0.1',
  ensure  => present,
package_mask { 'app-admin/puppet':
  target  => 'tree',
  version => '>=3.0.1',
  ensure  => present,

A few issues for the above providers (all the issues are reported in the repo’s Github tracker, but we decided to leave them for the next milestone)

for target in keywords use mask unmask; do
    if [[ -f /etc/portage/package.$target ]]; then
        mv /etc/portage/package.$target /etc/portage/package.${target}_bak
        mkdir /etc/portage/package.$target
        mv /etc/portage/package.${target}_bak /etc/portage/package.$target/old

2) make.conf

NOTE: Be aware that make.conf has changed location, from /etc/make.conf to /etc/portage/make.conf. Make sure to update your systems as well. Its new location makes much more sense. The Portage module uses the new location by default.

The Portage module provides a custom class to handle your entries in make.conf. Example:

portage::makeconf { 'use':
  content => 'flag1 flag2 flag3'

This entry will also trigger rebuild of the affected packages.

portage::makeconf { 'gentoo_mirrors':
  content => 'url1 url2'

As stated in issue #56, in a later milestone we will convert this class to a native type/provider, in order to make it more powerful.

3) portage::package

This is another custom class, which acts as a wrapper to the native package resource of Puppet. The following example sums up pretty much all of its functionality:

portage::package { 'app-admin/puppet':
  use              => ['-minimal', 'augeas'],
  use_version      => '>=3.0.1',
  keywords         => ['~amd64', '~x86'],
  keywords_version => '>=3.0.1',
  mask             => '<=2.3.17',
  unmask           => '>=3.0.1',
  target           => 'puppet',
  target_keywords  => 'puppet-keywords',
  ensure           => '3.0.1',
  • If no $target_{keywords,use,mask,unmask} is specified, then the value of $target is being used.
  • The variables keywords, mask and unmask also accept the special value ‘all’, that will create versionless entries. (This applies only to portage::package, if you want versionless entries in any of the above package_* types, you can just omit the version attribute.)
  • Any change in portage::package will also trigger the appropriate re-emerge to the affected package.

This class was my ultimate functionality request for Portage support in Puppet generally, thus it’s the part I’ve spent most of my time on.

4) Facts

All make.conf variables and most of the eselect modules are shown by facter:

eselect_profile => hardened/linux/amd64
eselect_python => python3.2
eselect_ruby => ruby19
portage_portage_tmpdir => /var/tmp
portage_portdir => /usr/portage
portage_python_single_target => python2_7
portage_python_targets => python2_7 python3_2
portage_ruby_targets => ruby19
portage_sync => rsync://

Keep in mind though that some of the eselect modules are not being shown as facts on purpose. The reason is that either they are not useful, or they produce too complex output that needs further investigation on how to implement. The blacklisted eselect modules are ‘help’, ‘usage’, ‘version’, ‘bashcomp’, ‘env’, ‘fontconfig’, ‘modules’, ‘news’ and ‘rc’.

5) eselect

The eselect type/provider checks for the current state of an eselect module by reading the variable of the equivalent fact. Examples:

eselect { 'ruby':
  set => 'ruby19',

For eselect modules that have submodules (eg php):

eselect { 'php_apache2':
  set => 'php5.3',

This pretty much covers everything. I hope it will be useful for the community. Feel free to submit bugs, patches or ideas at the repo’s Github issue tracker.

InstallFest 2013 in Prague

This weekend 2 and 3 of March 2013 an annual FOSS event is going to take place in Prague, called InstallFest. This is a Czech event, organized by Petr Hodač, who was also co-organizing the LinuxDays, the Czech event that was collocated with the Gentoo Miniconf and the openSUSE Conference. InstallFest is consists of some presentations, but the main goal is to have workshops and hacking activities. All the presentations are in Czech, so I’ll be sitting alone somewhere pretending to understand the topic. Michal is going to give a talk about Puppet on Saturday morning at , and Tomáš is hosting a full Gentoo day activity on Saturday. The official website (Czech only) has the full schedule along with the full history of the event. Looking forward to it!

Key Signing Party report

The Key Signing Party in SUSE Prague office had around 20 attendees, not bad I would say for a quickly organized/announced event with no serious promotion! There have been a bunch of non-SUSE guys there, thanks to everyone that attended. We’re definitely going to organize another one to enhance our circle of trust. Special thanks to the CAcert assurers as well, that gave me enough points so I can issue CAcert certificates now as well :)

The openSUSE beer was around as well, pretending to be a “KEY”.

Key Signing Party in SUSE Prague office

Tomorrow 15th of November we’re going to host a PGP Key Singing Party at SUSE Prague office. Make sure you bring your paper slips, and at least one goverment issued ID. As a bonus, we’re going to have CAcert assurance party as well! Don’t forget to check the Facebook and Google+ events. See you there!