Writing trigger scripts for cobbler does not work at the moment

Cobbler Logo

At the moment, shell scripts as triggers wont work with cobbler. This is due to a bug. Unfortunately the developers wont fix it in the next few weeks or even months.

Triggers are a very welcome and powerful method to automate things before, during after installation of a system. At the moment it only works with python scripts. Since not every sysadmin knows python, but everyone knows to write bash scripts, this is a major drawback.

Cobbler is included in RHN Satellite 5.3 but in a quite old version. People tend to use a standalone cobbler install server installed from EPEL. Out of the box Cobbler is only usable on RHN Satellite servers with “deployment” entitlements which are quite expensive. Post-Install triggers can help admins to automate configuration management in RHEL and CentOS environments. For automating configuration with the RHN Satellite you need to have brought the “configuration management” entitlements too. With cobblers triggers you can partially replace the configuration management offered by RHN Satellite. Is this the reason why Red Hat developers are not very keen to solve the issue? I’m talking about ~USD 250 p.a/system.

I’ll keep you posted on the issue….

Ubuntu 10.04 LTS released

End of April 2010, Ubuntu 10.04 was released. As always it is based on Debian’s Testing-Release. Canonical “stabilizes” the testing tree of Debian and adds its own look.

This time, Ubuntu radically changed its look. From my point of view it looks ugly, very ugly. Strange colors, low contrasts in menus, orange icons in Nautilus… window buttons on the left side… At the end of the day an usability-horror.

Under the hood Ubuntu is a very stable distribution with recent software. Ubuntu 10.04 is a LTS (Long Term Support) version and is thus suited as a enterprise server. Support for the server variant of Ubuntu is five years. Ubuntu is – like Debian – capable to upgrade to a new major release w/o service interruption.


You “can” mirror Debian and Ubuntu repositories locally but it is difficult if you to not like to mirror all architectures available. Unfortunately there is (AFAIK) no software available such as Spacewalk/RHN Satellite to manage your servers.

The best method is to allow each single system installed to talk directly or via proxy to the mirror servers. This is a nightmare for firewall administrators.

To my knowledge there is no convenient way to install Ubuntu over the net. There are rumors that spacewalk and cobbler is going to get Debian/Ubuntu support at some time.


Debian and thus Ubuntu has an evidence to be reliable. This also  seems to be true for the current release 10.04. The software came from Debians testing repository but was stabilized during months. Canonical (The sponsor of Ubuntu) has a reputation for its quality management. To use Ubuntu as a server operating system is sane.


As a desktop operating system I’ll avoid Ubuntu, since the usability is focused on dummy-users and not professional Linux users. For server usage you need to ask yourself about your needs. If you are operating Oracle DB’s or other commercial applications you probably want install Red Hat Enterprise Linux (RHEL). For a web server Ununtu is very well suited, even better than RHEL. In two years there will be another LTS variant available and you are free to upgrade online. Reliability is very good, manageability is poor, especially when used in larger companies.

In short: Ubuntu for web servers, RHEL/CentOS for other servers.

As always: Feedback is welcome…

Have fun!

RHEL6 as a web server

New software versions

Today I’m writing about the changes and benefits of RHEL6 as a web server compared to RHEL5. Red Hat is well known for its stable API and ABI over the life-cycle of a major release. For some usage types this is a major problem. Sticking to old version of PHP, MySQL, Tomcat you-name-it-piece-of-software is problematic since web applications are rapidly changing its requirements.

  • Instead of PHP 5.1.6, RHEL6 ships almost up-to-date PHP 5.3.1. Which is good, since web applications such as TYPO3 require PHP 5.3 to be able to install security bug fixes.
  • The Apache httpd comes in Version 2.2.14 instead of 2.2.3. Since Apache is not very actively developed further,  it does not matter anyway.
  • MySQL is shipped with an almost-up-to-date version 5.1.42 vs. 5.0.77. No big deal.
  • Tomcat is being installed with version 6.0.20 instead of the very old 5.5 in RHEL5. This brings quite some benefits for Java web developers.
  • Nothing has changed since RHEL5.5 so far for PostgreSQL.  Since RHEL5.5 Red Hat ships version 8.4 in addition to 8.1.
  • Python got upgraded from 2.3 to 2.6 which probably allows to run more Python based web applications.
  • Unfortunately still no appearance of GraphicsMagick as a replacement for ImageMagick.
  • New: Ships with APC (Alternative PHP Cache). This is useful for LAMP servers with loads of traffic and helps to get response time below critical values.

Unlike other distributions, Red Hat’s default DocumentRoot is still in /var/www instead of /srv/www. From my point of view the /var should be used for libraries and similar stuff, but not for application data. This ends up in creating symlinks like it was before.

From the “I-dont-like-bloated-systems” Departement

Looks like Red Hat made a huge progress in making its system less bloated. In Versions up to RHEL5 you can experience strange package dependencies.

  • PHP and friends: While on RHEL5 a “yum install php” automatically selects PostgreSQL-libs and gmp to install, nothing like this happens on RHEL6.
  • Tomcats dependencies went down from 48 packages to only 15.


At the end of the day, Red Hat made a good job to enable RHEL as a web server again. The fundamental problem is still the same: In two years RHEL6 will be completely outdated and not useful for modern web application, like it is today with RHEL5. Of course you can compile the stuff by yourself, but then you’ll get a maintenance problem.

Red Hat should think about something similar like Debian’s “volatile” repository. It provides upgraded software which would otherwise be useless in a two years or older versions. I’m looking forward for a “Red Hat Volatile” Channel on our satellites.

Feedback is welcome…

Have fun!