Everything is a Freaking DNS problem

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 :)

Technorati Tags: apt-get centos devops drupal puppet rpm yum

Over at the OPenARK blog Shlomi Noach argues that using apt-get or yum to install your MySQL instance will one day most likeley break your MySQL setup. Depdendencies, distros not shipping the MySQL version you want to use and on some distro's indeed the mysql vs MySQL issue, agreed, it all makes things less trivial.

However why give up a clean packaged system if there are other ways out ?

First of all by claiming that such an installation can break a working production environment looks to me like admitting you don't have a split development, production environment and that rather than testing stuff upfront indeed you just hack a long in production.

So rather than using a tarball for the MySQL instance an --force to satisfy the missing dependencies (hence also cluttering your system) , a much cleaner and less error prone setup is to only deploy from your own , self controlled repository , in which you only allow tested packages, most probably not the distro based package , hence packages that won't break your setups ;) But still you will be using apt or yum and deploying rpm's and debs , perfectly satisfying dependency needs.

Apart from that .. watch out for Banquise .. :) Coming to your favourite distro soon..

Technorati Tags: apt apt-get banquise deb mysql rpm yum

Fresh laptop arrived, obviously the first thing to do is to install the latest fedora. then do a full yum update.

However that failed with the following failed dependency

mesa-libGL-7.7-2.fc12.i686 from updates has depsolving problems
  --> Missing Dependency: libdrm >= 2.4.17-1 is needed by package mesa-libGL-7.7-2.fc12.i686 (updates)
Error: Missing Dependency: libdrm >= 2.4.17-1 is needed by package mesa-libGL-7.7-2.fc12.i686 (updates)
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

[root@stillmine ~]# yum remove  mesa-libGL 

Technorati Tags: compiz f12 fedora mesa rpm

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 !

Technorati Tags: centos drupal drupal6 epel fedora package rpm

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 :)

Technorati Tags: centos djagios epel fedora nagios packaging rhel rpm

A couple of weeks ago I was once again manually installing Drush as there were no packages for CentOS / EPEL or whatever, apart from the needed patch to get it running on a 5.1.X RHEL php

I had found this thread on Drupal.org mentioning that a package already exists
however David had not answered the exact location yet
So I created a drush package with a with the above mentionned patch and sent it to Jon Ciesla again he gave some suprising feedback ;)

Drush itself might need to be modified in Fedora. It seems
like one of the major functions of drush is to install and update
modules. That's great for modules we don't ship as rpms, but we can't
allow drush to modify modules that we ship.

This feedback pretty much leaves me with 3 options.

The first one is the easiest one, I just forget about packaging drush for Fedora.

The second one would require me to patch Drush so that for all existing drupal modules that have been packaged for Fedora, Drush will call yum to install them. This obviously would create a lot of work maintaining this excludelist.

The third one would be to disable the download functionality for Drush in a Fedora/Rhel enviornment, Jon suggested that this would probably be the saftest path.

(Jon also suggested a fourth option, namely removing all drupal modules from fedora and add a prohibition to package them in the Packaging Guidelines, which he immediately called ridiculous.)

I once again understand the problem of the Distribution maintainer, but on the other hand if I were the upstream Drush developer I wouldn't want to see my software severely disabled in a distribution.

So what do you folks think, disable the functionality or not ?

PS. Yes I've contacted upstream , but I haven't gotten a reply yet.

Technorati Tags: drupal drush epel fedora rhel rpm

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 .

Technorati Tags: centos drupal epel guidelines politics rhel rpm

Peter notes that you indeed can find pretty recent Enterprise level MySQL rebuilds over at the CentOSPlus repository.

Good things come to those who wait :)

Technorati Tags: centos centosplus mysql rpm

I have to admit .. I prefer being called a good soul over other things :)

Technorati Tags: centos rpm t-dose xen xensource

So Russel is wondering how to figure out what platform you are on by adding a script or so that will tell you you are on a RPM based machine when trying to run dpkg or tell you you need to use rpm.

Imvho that system is broken .. as everybody with some brains uses apt, even on an rpm based system.

Technorati Tags: apt rpm yum