Everything is a Freaking DNS problem

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

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.

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 .

Over a year ago I asked Lazyweb: I wonder why nobody tried to rebuild SLES like RHEL...Yesterday .. Dag responded. It indeed seems that the community around Fedora and CentOS is much bigger than the community around openSUSE
The comment from Leo to his posting is confirming that. Luc makes an observation regarding the use of any Suse based product .. namely that people who are using it are stripping Yast from it .. sounds like something I could have said :)

So earlier today I was fighting with

bond1: error fetching interface information: Device not found

I had a machine with 4 nics that I wanted to bond 2 by to. I had no problem getting the bond0 device up witn any of the interfaces, however getting a bond1 up always resulted in the above error.

The friendly guys from #centos on freenode pointed me to the missing config.

options bonding mode=4 max_bonds=4

The important part being max_bonds
it seems that the default is 1 so adding one more fails.

So once in a while you get to take over the management of a machine someone installed with no documentation, with lots of playing around and no clue on how it should be reproducible. You're pretty sure that if you reboot the machine it won't come up with the right services, or in this case with the right Virtual machines up and running.

So I got this box with about 7 different xen configs in /etc/xen and none in /etc/xen/auto .. however different lvm volumes were created and 3 virtual machines were running. The different xen configs looked all the same.
web1, web, web.orig, web.working you know :(

So my challenge was to figure out the config of the running virtual machines
Luckily I bumped into some Redhat articles that tought me virsh dumpxml
Now I`m not really a fan of xml based config but it got me quite far.

Eg. on one of my own machines the output looks pretty good.

web.hs62.be
f7cb62b9d3aa8a07489604285fe3d842

linux
/boot/vmlinuz-2.6-xen
/boot/initrd-2.6-xen.img
/dev/sda1 rw
selinux=0 3

524288
1
destroy
restart
restart