Everything is a Freaking DNS problem

When you pull out a disk from your Raid setup it shows a warning in syslog

Jan 27 10:18:22 EL860 kernel: 3w-9xxx: scsi0: AEN: WARNING (0x04:0x0019): Drive 
removed:port=1.
Jan 27 10:18:22 EL860 kernel: 3w-9xxx: scsi0: AEN: ERROR (0x04:0x0002): Degraded
 unit:unit=0, port=1.

However if no one is looking at syslog that won't really be helpfull.

3Ware provides a tool from their site called tw_cli which can be used to manage
the raid setup from the command line.

[EL860-root@EL860 admin]# tw_cli /c0 show 
 
Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-1    REBUILDING     41%     -       -       232.82    RiW    ON     
 
VPort Status         Unit Size      Type  Phy Encl-Slot    Model
------------------------------------------------------------------------------
p0    OK             u0   232.88 GB SATA  0   -            ST3250310NS         
p1    DEGRADED       u0   232.88 GB SATA  1   -            ST3250310NS         

I'd figure I'd either have to write wrapper script around that or find some other way of integrating it.
Asking the question on ##infra-talk on irc.freenode.net gave me the following link to a check script on github

koollman: sdog: something like http://github.com/stanaka/check_tw should work.

With that in your snmpd.conf you can get the info via snmp

[root snmp]#  snmpwalk  localhost   -v 2c  -c public  .1.3.6.1.4.1.2
021   | grep ext 
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: TW_RAID
UCD-SNMP-MIB::extCommand.1 = STRING: /usr/local/sbin/check_tw
UCD-SNMP-MIB::extResult.1 = INTEGER: 2
UCD-SNMP-MIB::extOutput.1 = STRING: CRITICAL: Unit: u0, Type: RAID-1, Status: RE
BUILDING
UCD-SNMP-MIB::extErrFix.1 = INTEGER: 0
UCD-SNMP-MIB::extErrFixCmd.1 = STRING: 
UCD-SNMP-MIB::ssSysContext.0 = INTEGER: 2073
UCD-SNMP-MIB::ssRawContexts.0 = Counter32: 11781783
UCD-DLMOD-MIB::dlmodNextIndex.0 = INTEGER: 1

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 

Fosdem is coming up again .. It's going to be the 10th edition already So it's going to be 2 days and nights of fun, tech and geek stuff

Lenz already posted the announcement , but allow me to recapitulate.

The MySQL & Friends meetup is on saturday evening , we'll meet around 1900 in front of the under the big tree in front of the AW building...

As with the Devops Meetup you can once again vote for your preferred food

The crowd voted and Favoured an Italian place , so I've made reservations for a 15+ persons group at Sogno d'Italia which is walking distance from the conference location, so there'wont be any hassle with cars and transport

The schedule for the Devroom is also already available

See u there :)

The Devops crowd does not have it's own devroom at Fosdem but will be meeting on Friday evening for food in a location close to the BeerEvent.

If you want to join us please let us know by voting on your favourite choice of Food. Using this doodle.

There's already about 15 people that are voting for the food selection ....

Plan is to meet outside of the BeerEvent around 2000 and
then move to a preferred food location.

Apparently the crowd wants plain Belgian food, so I've made reservations at Le Falstaff which is walking distance from the BeerEvent.
We should be there around 20:15

Don't hesitate to join us if you like DevOps talk

So when you setup an aggregator there's this one thing you miss from a regular planet ...the list of blogs with their individual Feeds.

I wanted to use this for planet.loadays.org again and realized I don't know where I got this snippet from or if I wrote it myselve or whatever .. but I do realize that unless I document it here I won't be able to point other people to it again :) So just create a block like this one :

<?php
 
 
 $subscriptions = db_query('SELECT title,link,url FROM {aggregator_feed} ORDER BY title');
 while ($list = db_fetch_object($subscriptions)) {
      print "<a href=\"$list->link\">$list->title</a> (<a href=\"$list->url\">feed</a>)<br>\n";
 
      }
 
?>

So a couple of weeks ago I blogged about DNS Knife late last year I ran into an even better tool.

Enter IntoDNS

Apparently IntoDNS.com finds more issues like the zone file listing different nameservers from the ones you defined ...etc..

So change your bookmarks, browse that page :)

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

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 .