Archive for May, 2010

Apache HTTP server and its further development

Monday, May 3rd, 2010

The Apache httpd is one of the most stable software pieces which is still in use. The latest huge step forward was with the release of 2.0. Quo vadis Apache httpd? The most current release is 2.2.15. During the 2.2.x release cycle, there have basically been only bug-fix releases (Okay, response header rewrite starting on 2.2.9  is a nice feature). This brings me to the question: What is going on with 2.4?

The answer is quite simple: As you can read on http://httpd.apache.org/docs/trunk/new_features_2_4.html, not much. Why is the Apache httpd developing so slow? From my point of view the answer is quite simple: Apache httpd is finished. It is stable, reliable and has (almost) all features people wish. @Apache httpd developers: Great job! Thanks a lot!

Additionally there are tons of external modules to enhance the capabilities of this really great piece of software.

Honestly I can not publish my wish-list for the Apache httpd because there are no open wishes for me. Can someone have such a wish list? Please let us know and write a comment.

Have fun…

Spacewalk 1.0 released

Sunday, May 2nd, 2010

spacewalk-1-0-release

Spacewalk 1.0 has been released

Spacewalk is the upstream project for Red Hat’s RHN Satellite software, one of the best systems management software available for Linux Systems.

In the past few weeks one could see a lot of git commits on the source repository of spacewalk. There is no changelog available yet. The road map mentioned compatibility with Apache Tomcat 6.0.x to be able to install spacewalk on Fedora12 and RHEL6.

There should have also been several enhancements in the phyton API and long awaited feature enhancements such as host-renaming (confirmed). Further repository synchronization should be much faster now (Announced in a earlier feature note).

Sorry folks, a lot of “should”, “maybe” etc. I just have been reading the git commit logs and the announcement of the 1.0 release. As long as there is not official changelog available we only can speculate on the precise enhancements.

I’ll install this on my test system soon. If something really uncommon happens or an astonishing new feature appeared, I’ll let you know,

Have fun!

Writing trigger scripts for cobbler does not work at the moment

Sunday, May 2nd, 2010

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

Sunday, May 2nd, 2010

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.

Managebility

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.

Reliability

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.

Conclusion

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

Sunday, May 2nd, 2010

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.

Conclusion

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!