This year the FUDCon (Fedora User and Developer Conference) will be held in my home town.
There are quite a lot of interesting talks on the agenda and two social events in the evening. I’ll not missing it.
The conference is sponsored by Red Hat and it is free of charge.
See you there…
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
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!
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!
In short: It was a non-experience because the RHEL 6 Beta 2 distribution is not installable…
[Update]It is not a anaconda bug, but a bug in a paravirt driver. On ESX installation runs smooth, expect a more detailed report in the next few days[/update]
While downloading the ISO, I was very curious about it and my nerves were all on edge, like a little boy waiting for Christmas.
Afterwards I tried to install it as a KVM guest on my Systems, on OpenSUSE 11.2 and Fedora 13. On both the installation failed. Depending on the size of the RAM is was failing before the actual installation begun (1GB), or it was hanging while the packages are being installed (2GB RAM).
Connected bugs: #610510, #610261, #610255
Because of the non-installation, I only have seen one progress since beta 1: The critical security hole in anaconda have been closed. In beta 1, during the installation there was a sshd running and everyone was able to login as root without authentication.
I hope Red Hat will release a corrected ISO in the next few days to allow us testing the beta2.
As announced on the mailing list rhelv5-announce@redhat.com, Red Hat released beta2 of it upcoming RHEL6 enterprise product.
I’m actually disappointed by Red Hat, I was thinking that RHEL6 will be released GA on the summit a few days ago. It was not released. And instead of communicating a date, even a approximate date, the only message was “later this year”.
I do not understand Red Hat. Beta 1 is a rock solid Linux Distribution, with very few grave bugs detected. Of course, I do not like “banana products” where customers are the beta testers, but on this case, Red Hat behaves the other extreme way: GA of RHEL6 needs to be perfect.
I’m currently downloading RHEL6b2, and I’ll test it. Please wait a few hours for my test and its report.
Have fun!
Cheers,
Luc
As I wrote different times before, RHEL6 is going to have a Kernel based on upstreams 2.6.32 Kernel. Meanwhile Linus Torvalds and his fellows released 2.6.34. Since then – from a System Engineers Point of view – there have some “minor” changes which are affecting the daily work in enterprise environments.
I think that Red Hat is aware that RHEL6 is one of its most important releases made so far. RHEL6 Beta-Testers have acknowledged that this is one of the best Linux distributions made so far.
So lets have a look to http://bit.ly/98yNsk (https://bugzilla.redhat.com search for RHEL6 select all states, sort by Bug-ID and having RFE (Request For Enhancement) in Summary).
Unrar
I requested to add “unrar” to RHEL, unfortunatly they refused because of the strange license of unrar. This is really not understandable, because *ALL* major Linux distros such as SLES, Debian, Ubuntu are providing a package for it. Red Hat think (and they are right) it is a “unfree” license. From my point of view it does not hurt because nobody is forced to use its libs in own software. Unfortunately SAP distributes a lot of software components in RAR-compressed files, this is a problem.
virtio net/vhost net speed enhancements from upstream kernel
This was reported as bug #593158 and later appeared as #595287. Since Red Hat is keen to improve virtualization things, I think this is going to GA.
DRBD
DRBD was getting into upstream Kernel 2.6.33. DRBD (Distributed Replicated Block Device) is some kind of RAID-1 over TCP/IP and is rock solid since years. From my point of view it is the best invention since sliced bread when it comes to cluster technologies. It is widely used, also on RHEL. Have a look to Florians Haas’ comment about support, and further to Alan Robertson’s comment. While Florian is working at Linbit (the developer company of DRBD) points to support problems existing on current releases on RHEL, Alan is a “Urgestein” (sorry, cant find a English word for it, it is meant in a very positive manner) of Linux clustering likes too to have DRBD in RHEL6. Quite a lot of people are included in the bugs CC list (as I’m writing 37 people). This brings quite some preasure on Red Hat to include DRBD in RHEL6. @Red Hat: Do it! include DRBD! If not as a “supported” product, deliver it and find a way with Linbit for the support.
Getting rid of the crappy VMware-tools
For people urged to use VMWares ESX stuff as virtalization technology, there is another important thing that changed: In 2.6.34 upstream Kernel, Linus Torvalds accepted VMWares ballooning driver (vmmemctl). In 2.6.33 Linus accepted VMWares vmxnet3 and pvscsci drivers which have been already backported to RH’s Kernel 2.6.32-EL. So, also backporting vmmemctl is *THE* chance to get rid of those crappy VMWare Tools. For companies relying on ESX this would be a *VERY* important feature. I’ll made a service request (SR 2021028) @Red Hat and will file a RFE-Bug at bugzilla ASAP. Please vote for it!
Other stuff
There are other RFE’s pending. Most of them are not really important for enterprise computing (my point of view). Mostly this RFE’s are about virtualization and bound to libvirt. Most of these RFE’s seems to be trivial and are on status “ON_QA” which means they are most probably included in RHEL6.
What is your favorit RFE-Bug? Please let me know…
Have fun!
Luc
A couple of days there have been some reports that Red Hat will release a commercialized version of deltacloud, an abstraction layer for different kinds of virtualization technologies and clouds such as VMware, RHEV, Amazon EC2 etc.
Red Hat puts a lot of resources on virtualization, they maintain and/or sponsor multiple projects in parallel. The most important from my point of view is libvirt which is as well an abstraction layer for different virtulization technologies such as VMware, KVM, Xen and others. Libvirt and deltacloud are partially redundant.
It is not the only redundancy created by Red Hat. There is also O-virt “competing” with RHEV. Both are not tightly bound to RHN satellite or Spacewalk.
RHEV works with system templates similar to those at VMware. On the other hand: Koan, together with cobbler is a deployment software for virtual hosts and was recently bundled with RHN satellite.
Not all of those Red Hat virtualization projects are working well together. So the question arises: What is the strategy of having such redundancies of projects? Why not integrating all of this projects and glue them together?
Lots of questions…
Have fun!
On 2010-05-20 Google released the SDK version 2.2 of its Android Linux OS for Mobile devices. It will take some time before the software will be available for the phones.
Main features enhancements is performance improvements due to the Dalvik JIT. Performance will be up by factor 2 to 5. This brings me to the question: Was is intentionally that slow before? Just to be able to announce a major breakthrough later on? Anyway: Good to know that the speed has improved.
The major new feature for me is the ability to install apps on SD-storage. Myself I’m using the CyanogenMod version 5.0.6 and already got this feature on my Nexus One. The tricky thing is to partition the SD Card. To be able to install apps on SD, there must be a partition with ext2, ext3 or ext4 filesystem. Search the internet for howto’s.
I’m also looking forward to test the better exchange support or if Touchdown pro is still needed to get it working.
Finally you can automatically update apps, plus the ability to update all application with a single tap without 3rd party software such as aTrackDog.
Have fun!
I was criticizing that software in RHEL is too outdated for web servers quite soon after release, see my blog post http://blog.delouw.ch/2010/05/02/rhel6-as-a-web-server/. While this is true for a system fully supported by Red Hat, I learned an alternative from a comment on the post. This alternative is the so called IUS community repository.
About the IUS Community Project
The project was launched in September 2009. In spite of being a young project, it has a history. At Rackspace, a large hosting company which is operating thousands of production (web) servers, it was an internal project since 2006. They decided to build up a community around it, like Fedora is for RHEL, Quote: “IUS is The Fedora of Rackspace RPMS”
Support
Like for other community repositories out there, you cannot expect a “official” support neither from Red Hat nor from IUS or Rackspace. Of course there are the usual support sources for communities such as forums, IRC, bugtracker etc.
The difference to other repositories
While most community repositories such as EPEL, rpmforge etc. are focused on providing missing software, IUS focuses on providing upgrades for web server related software which is included in RHEL. This includes PHP, Python, MySQL and others.
Package conflicts with the stock distribution
One may think replace stock software with newer version is tricky and create conflicts. There is one way to find out: Lets give it a try…
The test
The server is a basic install of the yesterday released Centos 5.5. The following installation turns this machine in a lightweight LAMP server:
yum install httpd php-mysql php php-cli php-common php-pgsql php-dba php-pdo php-gd mysql-server perl-DBD-MySQL.
Now we have the situation like it exists in many companies: An outdated webserver. Now we want to upgrade PHP to 5.3.x. Lets see what happens.
[root@centos5 ~]# rpm -i http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/ius-release-1-4.ius.el5.noarch.rpm
warning: /var/tmp/rpm-xfer.o6JH6k: Header V3 DSA signature: NOKEY, key ID 9cd4953f
[root@centos5 ~]# rpm -i http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/epel-release-1-1.ius.el5.noarch.rpm
warning: /var/tmp/rpm-xfer.MRnuo8: Header V3 DSA signature: NOKEY, key ID 9cd4953f
package epel-release-5-3.noarch (which is newer than epel-release-1-1.ius.el5.noarch) is already installed
[root@centos5 ~]#
Hmm… no GPG key…
The second output is confusing me. Is the package just a clone of epel-release-5-3.noarch? Lets go forward to see if it is working.
“yum clean-all && yum check-update” did not show any pending updates, so far so good. Now lets try to upgrade php.
root@centos5 ~]# yum install php53
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: mirror.netcologne.de
* base: mirror.netcologne.de
* epel: mirror.andreas-mueller.com
* extras: mirror.netcologne.de
* ius: ftp.astral.ro
* updates: mirror.netcologne.de
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php53.x86_64 0:5.3.2-3.ius.el5 set to be updated
--> Processing Dependency: php53-common = 5.3.2-3.ius.el5 for package: php53
--> Processing Dependency: php53-cli = 5.3.2-3.ius.el5 for package: php53
--> Processing Dependency: php53-pear >= 1:1.8 for package: php53
[omitted output]
--> Processing Conflict: php53 conflicts php < 5.3
--> Finished Dependency Resolution
php53-5.3.2-3.ius.el5.x86_64 from ius has depsolving problems
--> php53 conflicts with php
Error: php53 conflicts with php
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
The program package-cleanup is found in the yum-utils package.
Correct behaviour, since it is a replacement package. After removing php (and only php) yum was complaining about more conflicts. After removing all php related packages installed to prepare for the test, needed to be removed. So the dependencies has been proper solved. Also the installation of related stock distribution packages such as “php-pgsql” has been successfully prevented.
Conclusion
The IUS community repositories are working as expected. With such a basic test I cannot promise if there are not hidden conflicts with packages between stock RHEL/CentOS packages and those from IUS. The experience on the long term will bring more clarity. I think is is sane to do some real-life tests with servers that are in an early project phase.
Further readings:
http://iuscommunity.org/
http://wiki.iuscommunity.org/
http://saferepo.iuscommunity.org/specification/
Have fun!
On May 15, the CentOS project released version 5.5 of its enterprise Linux. It is based on the sources of RHEL5.5 which was released on March, 31.
Unfortunately they – like always – removed the rhn-client-tools and friends from upstream. This is a pity, since it takes more efforts to manage CentOS-installation in Spacewalk.
For the full release notes have a look at http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.5
Have fun!