Everything is a Freaking DNS problem

and with that almost a full week of side events.
For those who don't know FOSDEM, (where have you been hiding for the past 13 years ? ) Fosdem is the annual Free and Open Source Developers European meeting. If you are into open source , you just can't mis this event where thousands of likeminded people will meet.

And if 2 days of FOSDEM madness isn't enough people organise events around it.

Last year I organised PuppetCamp in Gent, the days before Fosdem and a MonitoringLove Hackfest in our office the 2 days after FOSDEM This year another marathon is planned.

On Friday (31/1/2014) the CentOs community is hosting a Dojo in Brussels at the IBM Forum. (Free, but registration required by the venue)

After the success of PuppetCamp in Gent last year we decided to open up the discussion and get more Infrastructure as Code people involved in a CfgMgmtCamp.eu

The keynotes for CfgMgmtCamp will include the leaders of the 3 most popular tools around , both Mark Burgess, Luke Kanies and Adam Jacob will present at the event which will take place in Gent right after Fosdem. We expect people from all the major communities including, but not limited to , Ansible, Salt, Chef, Puppet, CFengine, Rudder, Foreman and Juju (Free but registration required for catering)

And because 3 events in one week isn't enough the RedHat Community is hosting their Infrastructure.next conference after CfgMgmtCamp at the same venue. (Free but registration required for catering)

cya in Belgium next year..

It's a typical situation, the developers develop on their own boxen, they only start to integrate their code on on the production platform 3 hours before the deadline. And then the problems start, the typical "But it works on my system" , "its your problem now" is something nobody really likes to hear .

So how do you tackle this problem ? As Christian already mentions Talking is the first step of the solution,

But one of the most satisfying approaches to solve this problem is to provide your development teams with a standard platform that you support, and a platform they can play with , if you can't provide them with a fully defined platform, give them a set of guide lines on what they can expect. Things like library versions, database types , memory availability and storage availability are key components of such guidelines.

My platform of choice for this kind of projects today is to for an Enterprise Level distro, a distro that stays stable for a longer period, not one that is bleeding edge and changes every other week. So a CentOS or a Debian based distro is probably going to be the platform of choice. But a stable standard platform also means that all the latest nice features a developer wants to have from the bleeding edge libraries he is using aren't going to be available .

Sometimes your devs really need those features, sometimes its just a nice to have. On the other hand you as an ops guy don't want to be packaging and configurating every single tool they dream off. As usual in a Devops environment the key can be found in communication ... Talking with the devs will teach you what features they really need and how they might solve things in a different, more standardized way

We've learned that by giving them a default platform and keeping an open conversation helps, some developers take longer to understand the process others jump in right away .. but in the long term you really need to talk to your devs as soon as possible when they think of implementing a new project that has to run on your platorms.

Lets you sleep at night ..

So John wrote down his experiences on deploying Drupal sites with Puppet .

It's not a secret that I've been thinking about similar stuff and how I could get to the best possible setup.

John starts of with using Puppet to download Drush... while I want to use rpm for that ...

I want my core infrastructure to be fully packaged... not downloaded and untarred. I want to be able to reproduce my platform in a couple of months , with the exact same versions I`m using now .. not with the version that happens to be on ftp.drupal.org at that point in time, or with ftp.drupal.org being down.

Now the next question off course is what's the core infrastructure.
Where does the infrastructure end and does the application start. There's little discussion about having a puppet created vhost , an apache conf.d file, a matching .htaccess file if wanted , and the appropriate settings.php for a multisite drupal config.

There's also little doubt to me on using drush to run the updates, manage the drupal site etc . Reading John's article made me think some further about what and when I want things packaged.

John's post lead to a discussion on #infra-talk on getting all drupal modules packaged for Centos with Karan and some others

In a development environment I probably want to have periodic drush updates getting the latest modules from the interwebs and potentially breaking my devs code. But making sure that when you put a site in production it will be on a fairly up to date platform, and not on the platform you started developing on 24 months ago.

In a production environment however you only want tested updates of your modules as indeed they will break code.

It's probably going to be a mix and match setup having a local rpm/deb repo with packaged modules that have been tested and validated in your setup and using drush to enable or configure them for that production setup.

But also having a CI environment wher Drush will get the new modules from the interwebs when needed. and package them for you.

To me that sounds beter than getting all the available Drupal modules and packaging them, even automated, and preparing a repository of those modules of which only a small percentage will actually be used by people.

But I need to think about it some more :)

Dear Drupal Community,

If any of you are interrested in getting a packaged version of Drupal 6 into Fedora's EPEL repository (Extra Packages for Enterprise Linux) and therefore usable in RHEL and Centos,
please comment on the Bug I filed to get it's introduction started.

Any pitfalls, benefits etc are welcome ..

thnx in advance !

After all the politics involved in getting a package in a distro, or not it was time for a nice small and clean package of a fresh and promising open source project. Djagios was an easy choice.

I've uploade the rpm and Source RPM to repo.inuits.be and getting the SPEC file in the upstream repo was 10 minutes work.

Next step is to get it into Fedora , and EPEL :)

Some of you might have noticed that Fedora 11 and up already have an up to date Drupal6 version, but EPEL , which is what a lot of people are using on their CentOS or RHEL builds only has a Drupal5. I asked Jon Ciesla, who is maintaing the Drupal packages in Fedora why :

Because when Drupal was initially built for EL-5 and EL-5, the 5.x
branch was the current release. It's up to date, 5.20 is the most
recent release, and is still supported upstream in terms of security
fixes. 6 is out, and has been for awhile, but we have the following:

http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies

Since 5.x isn't broken or insecure, it'll be a tough sell to move to
6.x. Once upstream drops support, this may change.

It's a correct answer from a Distribution point of view, but the fact is it is widening the gap between the Ops and the Devs. If the ops want to keep their platform clean we need to have our software packaged on the platform we want to use, which is most often an Enterprise Linux distro, on the other there is understandably no hair on a dev's head that he will be building a new site on a Drupal 5 platform.

So until the Drupal community doesn't declare Drupal 5 dead, RHEL and CentOS users will have to use 3rd party Drupal6 RPMS , or rebuild the F12 rpm from Source again .

I have a confession to make, I`m a Fedora user, have been since before it existed , I remember running RedHat 4.2 on my Multia and I`m pretty sur that wasn't my first RedHat install

I`m running Fedora on my laptop and corporate desktop for the simple reason that it will provide me with a preview of what CentOS might look like in the future.

So when my inbox started to show invites of a Fedora 12 release party at walking distance from my home , I replied I'd join the party afer I had put the kids to bed.

Saturday came and I realized that given the short distance to the events place it might be a good idea to get the good old RedHat bike from the garage and check it's tires. Just after I had put Margot to bed the crowd already wondered where I stayed.

I grabbed my Fedora and jumped on my bike, only to realize it's lights weren't working :( The only remaining option was to drive by car. A full 3 minutes later I was at the venue.

.Apparently nobody in the audience had seen a real Fedora before as Bert promplty stopped his presentation.

After the presentation we tried to create an OpenSpace and started introducing ourselves, we used the Fedora as a talking stick, on a regular day my Big Tux wears the Fedora, but apparently our cats had been playing with it a bit too much ... :)

More reports from Vincent, Tosh and Bert

Oh, and I`m a Debian, Ubuntu, and CentOS user too :)

You must have noticed the fuzz around CentOS, the open Letter , and luckily Lance showing up again ..

I've been a long time CentOS user , so this kind of events are pretty close to my heart, I never really worried about the future of the project , the CentOS community is was standing behind their message as one group. If Lance wouldn't have shown up again quoting Arrfab:
"The worst would be to switch to another domain name .. but you already know that everything is a fscking DNS problem"

In this case it would actually be more of a mareketing problem :)

Fact is that sometimes an active community standing up against a lesser active project lead has it's results, however this time there probably won't be any other DNS entries to be added , but I hope one day the logo will become better :)

My yesterday post about RiverMuse only being available on Fedora Core 9 wasn't even cold yet and today Rivermuse already announced the availability of their RHEL5 binaries.

Awesome Open Source !

There is a really easy way to figure out ...

Look at the size of of the devrooms , if at all , a project gets at Fosdem
It's really interresting to see the Embedded room move to a 500 seat room which it really needed when the first openMoko talk was held there in a previous edition.

The FDO , Drupal, Mozilla, Centos/Fedora and Suse rooms stay in similar size rooms as last year.. But it seems lik the BSD and PostgreSQL room which was pretty crowded moved to a bigger location.

The Ruby room also seems to move to a bigger room. Fosdem has a couple of new rooms too it seems this freed up room for new groups such as the MySQL Crowd

Obviously these sizes aren't a real match to the size of a community, as the new rooms might need (and probably will need) a reshuffle for next year ;)

Different schedules for the devrooms are online .. you'll probably find me in the Debian , Fedora+CentOS, MySQL or Drupal rooms :)

Did I mention that :

and I`ll actually be speaking there again about Monitoring MySQL