Rumours about RHEL6 GA end of October 2010

The latest unofficial rumors about the release date of RHEL6 are pointing to end of October 2010. This is a bit more precise than the official statement “later this year“.

There are multiple sources of this rumors, so it can be considered truthful but still not as a fact. Hopefully RHN Satellite 5.4 will be released end of September to prepare the infrastructure to be able to manage RHEL6.

Have fun!

RHN Satellite 5.4 release in sight

When analyzing recent Bugzilla-reports and mailing list posts, we can expect a RHN Satellite release quite soon. Why? The main reason for this is the lack of SHA256 support in sat530. Since RHEL6 packages having SHA256 checksums, the release of Satellite 5.4 is a prerequisite for releasing RHEL6. As always there will also be a large load of bugfixes included.

Expected new features

  • yum repository syncronising
  • Support for SHA256 checksums
  • Maybe support for SHA384 checksums
  • Support for Oracle 11g databases (on external servers)
  • Improved preformance
  • Orphaned profile elimination to prevent wasting entitlement
  • Runs on RHEL6 (and thus Tomcat6?)
  • Recording of the install-date of packages

Of course, this list can be wrong. Because lots of bugzilla entries are not open to the public this list also tends to be incomplete. Lets have a closer look to the new features that most probably will hit rhn satellite 5.4

yum repository syncronising
This feature allows to sync custom channels with an external yum repository. Lot of people are mirroring EPEL and IUS repositories with the help of wget and push the packages into the satellite with the help of rhnpush. In future there will be a command like spacewalk-repo-sync –channel you-name-it-custom-channel (maybe the command will be renamed to rhn-repo-sync). This new feature will not only safe some GB of disk space, it will also speedups the process of getting new packages from external repos.

In Spacewalk 1.1 there were a lot of improvements made on repo handling. Hopefully sat540 will have them too. Since I was not able to figure out which Spacewalk version is the upstream for sat540, I can only hope that it will be version 1.1.

Support for SHA256 checksums
RHEL6 packages are all coming with SHA256 checksums. Those are not supported with the current release 5.3 and older. This means version 5.4 needs to be released close to the GA of RHEL6, otherwise customers are not able to manage RHEL6 systems internally.

Support for Oracle 11g databases (on external servers)
Right now, only Oracle 10g databases are supported on external servers. This is annoying for customers that already ditched Oracle 10g and upgraded all Databases to 11g. This new feature allows to have a homogeneous database landscape in the datacenter.

Orphaned profile elimination to prevent wasting entitlement
Today when re-provisioning a system, the system gets registered and entitled twice, the old system-profile needs to get deleted manually. Often this gets forgotten and wastes entitlements. In RHN Satellite 5.4 there will be a function to detects those duplicate system registrations.

Runs on RHEL6
The upstream project Spacewalk runs fine on Tomcat6, which will be included in RHEL6. It is quite unlikely that the Sat distribution comes with an own Tomcat5.5 server, so it means that the support for Tomcat6 was backported from Spacewalk.

Recording of the install-date of packages
This small feature is quite important for a lot of users. In some industries there are regulations to know when a particular package was installed. Of course you can get this information out of the systems /var/log/yum.log, but now you will have this information handy on your Satellite server.

Open Questions
There is a Bugzilla tracking bug for RHN Satellite version 5.3.1. What is it good for? Will there be support for RHEL6? My guess is not having RHEL6 support and 5.3.1 will be ditched even before its got released.

Will RHN Satellite 5.4 will also run on RHEL5? Maybe the distribution comes with Tomcat6 packages for RHEL5? Maybe Sat540 will be able to run with Tomcat5.5? We will see…

Upgrade scenarios: Will it be easy to upgrade from 5.3? Is it needed to refresh the OS from RHEL5 to RHEL6? If it is that easy as upgrade from i.e. Spacewalk 1.0 to Spacewalk 1.1 then we all will be happy 🙂

Release Date
As always, Red Hat does neither publish a roadmap nor release dates. All we know for RHEL6 is “later this year” and thats also true for the release of RHN Satellite 5.4.

Conclusion
The gap between Spacewalk 1.1 and RHN Satellite 5.3 is quite huge. Lots of new and interesting features have been introduced, lots of bugs fixed, much better performance. With the upcoming release of version 5.4 this gap will be much smaller.

In contrary to the release of 5.3 which was quite buggy on GA, I do not expect the same for 5.4 because Spacewalk seems to be very stable at the moment. This makes me confident that 5.4 will be a very stable version from GA on.

Have fun!

Experiences with RHEL6 Beta 2.1

Like promised I’ll keep you updated on the RHEL6b2.1. The “official name” is not Beta2.1, it is “Beta 2 refresh”. Why not calling it Beta3? Anyway: The good news first: In contrary to the first release of Beta 2, it works fine again! The first release of Beta2 was quite crappy, it was not installable as a KVM guest. This was obviously due to severe bugs in some virtio drivers.

So, what are the news?

1. The bugs in the virtio drivers have been fixed, you can deploy RHEL6 in KVM environments again.
2. The vmware_ballooning driver has been backported.
3. A lot of minor bugs have been fixed, see the announcement.

Especially point two is cool, running RHEL6 in a VMware ESX environment does not necessarily need the vmware-tools installed anymore. RHEL6 now provides all three important vm-ware related drivers: The vmxnet3, vmware_ballooning and pvscsi. At the end of the day, this means one can dismiss the always-hated vmware-tools. A test of the behavior w/o vmware-tools by a ESX specialist is pending.

The alternative of vmware-tools are the open-vm-tools. This would add the benefit of controlled shutdown of the ESX guest with the vCenter tools. Since VMware does not provide (yet) RHEL 6 packages of the open-vm-tools I was unable to test it.

I made the same brief tests as I reported here. It seems that Red Hat is back on track, RHEL6b2.1 is reliable and not far away from being ready for production.

When can we expect a Beta3? Will there even be a next beta, or is Red Hat release a RC1 soon? There is still no published release schedule, all we know is “later this year”.

Anyway: Download Beta2.1 and test it, its a pretty cool release. If you find bugs, report them.

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.

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!