Posts Tagged ‘RHEL6’

I just got an email with the subject “Opportunity for Red Hat Certified Professionals to test new Red Hat software”.

Quoting the email:

" The new subscription management tools provide a very different user
experience than today’s Red Hat Network (RHN). We would like to get
your feedback on the software so that we can improve the tooling before
RHEL 6.1 is released. As part of this Beta Program, we will be offering
you a beta version Red Hat Enterprise Linux Personal Subscription. This
subscription will allow you to access the tooling that will be provided
as part of the RHEL 6.1 minor release."

In the same email Red Hat offers the audience to have up to 10 systems registered for free:

"Under the Personal Subscription provided via the Beta Program, users are able
to deploy the software on up to 10 personal systems. The Red Hat
Personal Subscriptions entitle you to access software and software
updates"

That are actually great news for us as Red Hat certified professionals. But it also opens new questions about the future of RHN, the RHN Satellite and the subscription model of Red Hat in general.

According to the documentation (You need to be at least RHCE and provide your RHCE number to get access to it), with RHEL6.1 registering systems to the RHN will completely change. No more rhn-register it is now the CLI command subscription-manager.

The most important thing that changed is that the username and password of RHN needs to be transmitted just once, afterwards you will get identified by a X509 client certificate.

The only drawback I’ve found was that the command to register a consumer needs to provide the password in clear text on the command line.

And for Satellite users?
As far as I can see, nothing changes, Satellite users can still provision the systems with activation keys, it is still channel based, not product based.

For enterprise users nothing is changing in the next time, the new entitlement and subscription method does only apply to does users NOT using a Satellite server, at least for now and for RHEL6.1.

The Readme also mentions RHN Satellte 5.5 which is not (yet) released. It is quite unclear what is expecting us with Satellite 5.5.

Reading some bugzilla entries, it is clear that there is still some time until RHN Satellite 5.5. will hit the road.

Please: A public Beta for RHN Satellite 5.5
Please Red Hat, provide a public, or at least a semi-public beta (like for RHEL6.1) release, to give your enterprise customers a chance to do the Q&A which was missing on the release of RHN Satellite 5.4.

Having fun? I do actually not care about RHN Network, I’m a Satellite user. Personally I’m having fun with my 10 personal RHEL6.1 subscriptions for free, it allows me to do lots of tests before putting RHEL6.1 into production.

Lines of code
Spacewalk has 2,908,841 lines of code, created in estimated 843 person years. This means 843 developers are needed to rewrite Spacewalk from scratch in one year! That’s amazing.

Number of bugs fixed
As stated in the post, the Spacewalk-team fixed 1012 bugs in the year 2010. Some 1061 bugs are still due to be solved, the Spacewalk-team will not running out of work in 2011. See RHN Satellite bugs and Spacewalk bugs.

Contributions from outside Red Hat
96% of the contributions are from Red Hat people. Looks like my small contribution to the German translation is just about 0.0000001% . Seriously: This should be improved. More people outside of Red Hat should contribute. How? A good way can be a better support for Debian based distributions as well as for SLES/OpenSUSE and other distributions. I think this would attracting more Red Hat outsiders.

Another important thing: Instead of mailing list posts, Fedora should release its advisories similar to Red Hat. This would enable people to have the errata in its Spacewalk servers. This would lead into more people interested in Spacewalk in the Fedora community.

Communications
The IRC communication stats can somehow be a bit problematic. Is it really needed to log all IRC traffic? Its was stated that 24.1% have been questions, the mail list post also disclosed which are the most aggressive persons and so on. Privacy? For myself: I’m probably going to change my real name nick to something else…

Missing numbers
It would be interesting how many people are subscribed to the spacewalk and spacewalk-devel mailing lists and the number of posts to these lists.

Major achievements in 2010
This is just my point of view…

- PostgreSQL support reached a point where it is ready for broad testing.
- spacewalk-repo-sync allows to directly sync with yum repos.
- Staging of content
- Support for eliminating duplicate system profiles
- Performance improvements (felt, not measured)

Did I had fun this year?
I had a lot of fun with Spacewalk, for sure. I did not challenged Spacewalk with all the stuff that I need @work with the RHN Satellite.

Will I have fun in 2011?
With Spacewalk of course, it is a cool project. If the Fedora project decides to publish Spacewalk-like erratas I’m pretty sure that France will have a problem to produce the amount of Champagne needed. If it comes down to the RHN Satellite: Due to severe bugs, I only can manage RHEL6 systems with some workarounds but I am confident that this will change soon.

RHEL6 was just released at 2010-11-10 20:09:50 CET. Quoting Red Hat press relase: Today, we delivered Red Hat Enterprise Linux 6 to the market. @Red Hat: you are so mean! Next time inform your fellows one day in advance to give your fellows the chance to fill the fridges with champagne!

I did not checked (yet) the differences between beta 2.1 and GA. I guess the differences are at a minimum.

The odd thing is: It seems not be available via satellite-sync yet (yes, sat540 is in place).

[update]You need to get a new certificate from Red Hat support to get access to the rhel6 channels, regardless if you got one a few days ago to install sat540.[/update]

First of all: Where is the Red Hat Press release? Nada, nothing, nichts (yet)….

History
As I wrote in my previous post, I’ll keep you posted with my latest findings.

In another post, I was speculating about the upstream version. Now, Sat540 seems to be based on Spacewalk 1.2 which is not yet released. I was quite puzzled about that fact. Usually upstream (Fedora) projects are ahead of its commercial counterparts, this time it seems to be the other way round.

Major Features
I was quite guessing right on the expected new features:

RHEL6 Support (SHA-256 Checksums on RPMs)

Support for importing and syncing of external yum repositories

Find duplicate entitlements of systems

Oracle 11g support

Recording of the install-date of packages

Additionally the following features have been added:

Symlink Support in the configuration management

SELinux in configuration management

Flex Guests enhancements

In contrary to my expectations:

For the moment, Sat540 runs only on RHEL5, thus meaning Tomcat5

Cobbler
The included version of Cobbler is 2.0.7. In EPEL5 it is 2.0.3, in EPEL5-test as well as in Fedora 14 beta it is 2.0.5. At least in sat540 it is the same version as in EPEL6-Beta, 2.0.7. The cobbler git repository mentions cobbler 2.1.0. At FUDCon in Zurich I was talking to some Red Hat guys. They told me: The cobbler guy left Red Hat. Hmmm… What is going on?

Real tests and improvements
I was not yet able to install sat540 yet, I’m waiting for the certificate… Nevertheless I made some tests with Spacewalk 1.1 which have been very promising.

At work
Today @work, I just prepared the staging/test satellite for being upgraded from 5.3 to 5.4. I’m still waiting for the new certificate from the Red Hat support. This brings me to another question: Why the heck is a new certificate needed? That’s boring…

As soon as I get the certificate from Red Hat, I’m going to upgrade the Staging/Test Satellite @work, so you can expect more detailed reports soon.

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.

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.

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”.

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

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.

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.

DRBDDRBD 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.