Bug or feature? Change in behaviour in CFEngine templates

CFEngineAgentToday I stumbled upon an unexpected behaviour change in CFEngine templates when upgrading from version 3.4 to 3.6. The change is not documented anywhere in the Changelog, so I am really not sure if it’s a bug or a feature. In any case, it is something to be aware of.

Take this template:

Normally, each line expands to an insert lines promise, which means that
duplicated lines may not be printed more than once. That behavior has
changed with CFEngine versions.
[%CFEngine cfengine_3_4:: %]
In this version of CFEngine, $(sys.cf_version), duplicates are printed once
In this version of CFEngine, $(sys.cf_version), duplicates are printed once
In this version of CFEngine, $(sys.cf_version), duplicates are printed once


that holds for blank lines, too

[%CFEngine cfengine_3_6:: %]
In this version of CFEngine, $(sys.cf_version), duplicates are preserved
In this version of CFEngine, $(sys.cf_version), duplicates are preserved
In this version of CFEngine, $(sys.cf_version), duplicates are preserved


[%CFEngine any:: %]
End of the story!

and this policy:

bundle agent test_example_cf3_template
{
  vars:
    cfengine_3_4::
      "templatedir" string => execresult("/bin/pwd","noshell") ;
      "testfile"    string => "/tmp/cf_34.txt" ;


    cfengine_3_6::
      "templatedir" string => "$(this.promise_dirname)" ;
      "testfile"    string => "/tmp/cf_36.txt" ;

  files:
      "$(testfile)"
	  create => "yes",
	  edit_template => "$(templatedir)/example_cf3_template.tmpl";

  reports:
    cfengine_3::
      "Check output in $(testfile)" ;
}

Now run the policy in both CFEngine 3.4 and 3.6. You’d expect to get two identical files: /tmp/cf_34.txt and /tmp/cf_36.txt. But they’re not.

Continue reading

hENC now on github

github-logo hENC is a radically simple external node classificator for CFEngine that I developed as part of my work in Opera starting from 2013. To my surprise and despite its simplicity, it was so much appreciated by the community that I was encouraged to present it at FOSDEM and Configuration Management Camp in 2014, which I did with much to my satisfaction.

This year I presented an updated version of the same talk at the Software conference in Oslo and I was asked if the code was open source and available. It wasn’t yet, and the main reason was that I knew it would take an effort to generalize it, to abstract it from our environment and make it suitable to be used anywhere. And it did: if you look at the history it took 16 days and 24 commits before I was happy enough with the result to publish it. But I finally did and it’s now available on githubNow it’s your turn.

You can do a lot to help these contribution coming. Give them a chance. If they seem to solve your problem, try them; if they actually help you, contribute to them if you have a chance; if you don’t have a chance to contribute you can at least promote them.

The CFEngine community is rather small and doesn’t have the large ecosystem of tools that other CM communities can boast about. Despite that, pearls like EvolveThinking’s EFL, Delta Reporting and Delta Hardening or Normation’s NCF (to name only a very few!) are there: help them grow, help more tools come, support developers to keep up the good work, share and encourage sharing, contribute back if you can. More than anything else, please let’s stop reinventing the wheel every time and become good at sharing.

If you do, everybody wins: you win because you get more tools, and we win because we see that our contributions are useful and appreciated.

Thanks in advance
-- bronto

Photos from Config Management Camp 2015

Report from Config Management Camp 2015

cfgmgmtcamp-logoThe Config Management Camp 2015 is gone leaving its trail of inspiring presentations, interesting discussions, pleasant meetings with great people and, hopefully, satisfaction for how each of us has played his/her part to make this edition a success.

A big thank for the brave people that attended my seminar and to those who asked questions. The questions gave me a couple of ideas to further expand the seminar, and more may come if you’re so kind to let me know your opinion on the talk: what you liked, what you didn’t, what could be improved in both the talk and the speaker’s style. Thanks in advance. As for the code of the tools, I promise to publish it on GitHub as soon as I get “clearance” (this week, possibly!).

For those who weren’t at the seminar, I presented how we evolved our git repository structure to support more than one project, each one with its own needs, but at the same time being able to share the relevant common libraries and tools and to make the deployment of the policies easy, manageable and maintainable, whatever the number of hubs and projects involved. The questions dove nose down to how we manage access to the hubs so that a person working on project A can’t accidentally deploy his policies on the hubs supporting project B, how we manage access rights to files in separate projects and to branches, and how easy or hard is to extend the deployment tool with new functionality.

The slides of the presentation are on SpeakerDeck (or further down the post if you don’t bother go to SpeakerDeck 😉 The good guys at Normation also filmed the seminar, so it’s just a matter of time that a video of the seminar will be available. Then you’ll also be able to hear my appeal to support cancer research, talking of which you can check another blog post of mine.

Regarding the talks I attended and the “hallway track”, Jez Humble’s keynote was definitely a mind blowing experience. Leaving aside the things that I am doing wrong, that we are doing wrong in my work environment, and that a broad set of people in our profession is f***ing up completely, I understood that there is a category that definitely needs to be more present at events like this: bosses. Because we can do a good job as professionals, follow the best practices, use the brightest and shiniest tools of today and some of the tools of tomorrow, but that’s definitely not enough to establish a culture of cross-area collaboration. That’s not going to happen without the direct involvement of the bosses and their mandate.

Continue reading

Bet against me, bet against cancer

WCD_LOGO_RGBI’ve written this post on the plane on February 4th while going back from Gent to Oslo.

It’s some time that February 4th has a special meaning for me. No, it’s not my birthday, nor my wife’s, nor anyone I know’s birthday. February 4th is the World Cancer day and yes, you should care, too.

It’s not necessary to get the illness to understand the importance of cancer research. I’m not ill, but my father died of cancer in 2012, aged 69; or maybe I should say that cancer ate him, bite by bite, breath by breath, literally. And while I’m grateful for what he was able to do for us, his family, during his illness, it hurts. It hurts that the only way to save him was to catch the disease very early and attentively follow-up, not give a chance, because if the disease manages to spread a bit, you’re screwed. And that’s because there were only three different medicines for his type of cancer, and none could save his life. Research has gone only that far.

There is only one thing that I can do to give one more chance to the people I love, my wife, my son, or even myself: help cancer research to advance before cancer takes a chance on one of them. That means donations to cancer research foundations in your country or, as we discussed at the Configuration Management Camp (yes, there, it’s not a mistake), do what we can do with our expertise to facilitate cancer research. While we get going with a plan for a good initiative that tech people can help with, I bet you. I want you to bet against me and against cancer.

Last year I ran two 10km races in Oslo, both on a pace of 6’40″/km (slooooooooowww!!!). I plan to run more 10k races this year, the problem is that I’m not in a good form because I had to reduce the training to focus a bit more on my running technique. As of today, I don’t even have “the distance in my legs”, so to say, and the pace is even slower than 6’40”. That’s a good context for a bet.

I bet that I’ll run the Sentrumsløpet on April 25th at a pace better than 6’40”, and I want you to bet against me. If I make it, then you make a donation to one of your country’s associations that support cancer research. If I lose, then I’ll donate 1000 NOK to Kreftforeningen (but please feel free to make a donation anyway 😉

Who’s in? Let me know by commenting this post.

Safer package installations with APT and CFEngine

CFEngineAgentPackage installation can be tricky sometimes when using configuration management tools, as the order in which package operations are performed can have an impact on the final result, sometimes a disastrous impact. Months ago I had been looking for a way to make apt-get a bit less proactive when trying to solve dependencies and removing packages and came up with the following package method that we now have in our library.

To use it, just put it in your policies and use apt_get_safe in your policies instead of apt_get wherever you want a more prudential approach to package installations.

I’m putting it here in the hope that it may be useful for everyone. I have used it successfully in Debian 5, 6, 7, 8 and on CFEngine 3.4.4 (where I borrowed parts of the masterfiles from 3.5 and 3.6 like, e.g., the debian_knowledge bundle) and 3.6.x. Enjoy!

Continue reading

My round of conferences in February

cfgmgmtcamp-logoThe first half of February is going to be quite busy to me with two conferences just a few weeks away now.

On February 2nd and 3rd I’ll be at the Configuration Management Camp in Ghent, Belgium, where I’ll hold the seminar “Many projects, one code” on the 3rd. A little more than a week later, the 12th of February, I’ll then be at Software 2015 in Oslo, where I’ll hold the seminar “The classification problem: challenges and solutions” in the Continuous delivery and DevOps track. And yes, the slides will be available on my SpeakerDeck account as soon as a seminar is done.

Continue reading

A small leap for a clock, a giant leap for mankind

TurnBackTimeIt’s going to happen again: IERS’ Bulletin C was published yesterday announcing that we’ll have a leap second at the end of June this year. It’s time to get ready, but we this time we are luckier than in 2012: leapocalypse’s scars were deep and still hurt, and only inexperienced sysadmins or experienced idiots will deny the need of preparing a strategy to mitigate the unavoidable bugs that will be triggered by the leap second insertion. Or even by the leap second announcement, like it happened in 2012.

Which bugs? Nobody knows. We have six months left during which you could review the source code of your OS’ and software. Or maybe not, but you can at least test what happens on your systems when the leap second is announced and when it is inserted.

Like in 2012, I’ll soon start testing the behavior of both ntpd and Linux. The test framework will be the same as last time, but with the added wisdom gained fighting against leapocalypse. This is what I plan to add to the picture:

  • more than one NTP test server: either three or four, to measure the convergence speed more accurately;
  • test under heavy load;
  • test on at least some of the software that we run;
  • test with the kernel discipline disabled to compensate for kernel bugs;
  • test on both stock ntpd and the recently released 4.2.8;
  • test on Debian Jessie, since it will be surely released before the leap second takes place;
  • prepare CFEngine policies to handle the leap second and test those as well.

Like last time I’ll share my results. If you’ll be doing similar tests in your environment, I’ll be more than glad to see your findings. This is going to affect us all, the more information we share, the more chances we have to overcome the bugs.

Image from http://writing.wikinut.com/img/3bguk3_7i7al8s9b/If-We-Could-Turn-Back-Time

On systemd

ReligiousWarsUNIX init systems are not a topic people discusses a lot about, usually. There is some buzz when a new one is out, some more buzz when it is adopted in other shops than those where it was born, then most OS keep on with their old solution (usually the System V init system, or sysvinit) and everything falls back to radio silence. Other times, I assume, things cut short from some buzz and directly into the radio silence phase. I’ve been into the Upstart buzz, before that I’ve been into the Solaris SMF buzz and even played with it until our friend OpenSolaris was mercilessly killed by their new father. But, honestly, the heated arguments about systemd took my by surprise.

I really don’t know how I had not heard about systemd before. Maybe I was just looking in another direction, or maybe the fact that it was so controversial suggested systemd’s detractors not to talk about it in the hope that it would be yet another of those attempts that cut short from their offspring to radio silence. I don’t know. Anyway, it didn’t go that way. To me, it’s like systemd flew steadily under the radar and kept growing until the Debian project decided to adopt it as their init system. My brain just filtered the news as yet another thing I could safely ignore for the moment and I’ll have to learn about when it comes. And then the sky fell down.

What happened after that announcement was kind of the burst of a religious war, with people debating harshly, insulting each other, death threats spewed here and there, people resigning from their role in important organizations. Then came the Devuan fork of Debian. For now.

A bit too much for “just another init system”, right?

What follows is the outcome of my Christmastime readings about systemd and my own considerations about what I’ve read. I hope it will help you make up your own opinion on whether or not systemd is a good thing or a bad thing. As an extra, you can read my own opinion (for what is worth).

Continue reading