Do the S100 and S300 Software RAID controllers in my Dell PowerEdge Server work with Red Hat Enterprise Linux?

To paraphrase, the solution is to take the RAID card out the server and throw it in the bin. The S300 isn’t a real RAID card, it’s a fakeraid. You’re better off just using Linux software RAID.

Unfortunately, the cabling in the server doesn’t allow for connecting to the on-board SATA ports, or rather for powering them. Speaking to Dell support, they initially suggested that just disabling the card in the BIOS would be sufficient; they later admitted it isn’t, and offered to send out suitable cables.

I seem to remember Dell making a big deal of their entire server line offering full Linux support some time ago, so I’m surprised to see them making this retrograde step – particularly as Linux represents a large percentage of the server market. In Dell’s defence they do make it reasonably clear that the S300 card isn’t supported under Linux at the ordering stage.

Red Hat Enterprise releases have been traditionally 18-24 months apart, and on that basis one might have expected RHEL6 to have been released sometime between October 2008 and March 2009, as RHEL5 was released in March of 2007. So what’s taking Red Hat so long, and when can we expect RHEL6?

There are a number of reasons for the delay, but the biggest is related to the Fedora Project, who create Fedora, on which Red Hat Enterprise is based.
For Fedora releases up to version 6, on which RHEL5 was based, the Fedora Project was run very much as an in-house Red Hat project, with contributions from the wider Open Source community. Post FC6, the Fedora Project was much more run by the Open Source community, with Red Hat contributors. This seems to have led to a shift in focus from fixing bugs to implementing new features. This isn’t necessarily a bad thing – Fedora exists to be the ‘bleeding edge’ of development, pushing at the boundaries in a way Red Hat are obviously unable to do with an enterprise focussed product like RHEL. Unfortunately, Fedora 9, on which RHEL6 was to be based, released with a large number of critical bugs and stability issues. Red Hat made the decision that they therefore couldn’t base RHEL6 on this release, and instead poured man-power into the Fedora Project, fixing bugs and generally improving stability as much as possible.

The evidence is that RHEL6 will now be based on Fedora 12, which was released in November of last year. The was a gap of just under a year between Fedora 6 and RHEL5, so this would point to a release in Autumn of this year.

The other issue that has caused delays to RHEL is that of virtualisation. RHEL4/RHEL5 utilised the Xen hypervisor for their virtualisation. In September 2008 Red Hat purchased Qumranet, whose staff included the leaders of the KVM project, an alternate virtualisation technology. KVM is very much seen as the future for Linux virtualisation, and Red Hat immediately made it clear that this was the direction they would be pursuing. RHEL 5.4 included KVM as a ‘technology preview’, so clearly much progress has been made integrating it into the main Red Hat release. It’s therefore likely that this is no longer holding up RHEL6.

I expect the final release date for RHEL6 to be announced at the Red Hat summit at the end of June. There have been some suggestions that RHEL6 itself will be released at the summit. Unless Red Hat release a beta within the next couple of weeks, I’d say this looks distinctly unlikely.

 “A report published by the European Commission’s Open Source Observatory provides some details from a recent presentation given by Gendarmerie Lieutenant-Colonel Xavier Guimard, who says that the Gendarmerie has been able to reduced its annual IT budget by 70 percent without having to reduce its capabilities.”

Read the full story over at Ars Technica.

These figures from  http://mjg59.livejournal.com/103511.html:

• Idle power draw of Fedora 10: 100W
• Idle power draw of Opensolaris 2008-11: 135W

It’s interestingly entitled ‘Torvalds Family Blog’, although Linus being Linus I’m sure we’ll see some excellent highly controversial non-family posts, just like his mailing list postings.

This issue should be fixed in RHEL/CentOS 5.3, but until then, if you’re experiencing slowness I’d advise installing this – after appropriate testing on staging/UAT servers of course.

There is a parallel Fedora announcement, and although it seems that Fedora wasn’t affected they are issuing new package signing keys as a precaution.  Red Hat use a hardware device for signing their packages, so they can make sure no further compromised packages can be created without having to re-distribute new signing keys.

Red Hat Network wasn’t compromised, so although the signed packages were created, there is no risk to those whose only means of obtaining packages is via RHN (ie, most Red Hat users).

Whilst there certainly isn’t any need to panic, this is sure to cause concern amongst those running Red Hat.

Given that I’ll probably be accused of bias anyway, I better declare mine: the server that is serving you this page runs Ubuntu, as does the one running the main Bashton site. Many of our internal-facing servers run CentOS. My desktop runs Ubuntu, and my laptop runs Debian. Other staff have their own bias of course (particularly those who are Debian developers..), but as it was just me writing the article I don’t see that as relevant.

Please make your comments here and hopefully we can start some form of a useful debate, rather than the ‘distro X is the best’ discussions these things usually descend into.

You have a website you need to move to a new web server on a new IP address. You intend to keep the domain and all URLs the same.

By utilising the Apache module mod_proxy we can make sure that all requests are sent to the correct server, despite any cached DNS entries which are pointing to the old IP. Whilst this isn’t too much of a problem for static web-sites, for modern, database driven sites it is vital that all data is written to the correct location. One particular benefit feature of this approach is that you can move just a single VirtualHost, where other approaches expect you to be moving everything hosted on that server.

Pre-requisites:

• Apache and mod_proxy on the server you are moving from
• Access to the Apache configuration files on the server you are moving from
• Control over the DNS for your domain

The Science Bit

Essentially, what we’re going to do is make the old server into a ‘reverse proxy’, so it will forward all requests on to the new server, then return the reply to the client. One thing to watch out for is scripts that do checking based on the remote IP address, as this will be seen as the old server’s IP for proxied connections.

The Procedure

Testing on the new server

First, I’d recommend taking a copy of your website and putting it up on the new server to test that everything is OK. You can view the website on the new server by making an entry in your ‘hosts’ file on your local machine(/etc/hosts on Linux/Mac OS X, c:\windows\system32\drivers\etc on Windows). An example entry is below:

  # Temporary entry for www.example.com on the new server

  192.168.0.5   www.example.com

Once you’ve ascertained that everything is working correctly on the new server, we can begin the process of moving the website.

Disable updates

Firstly, we need to stop any modifications to the site/database, so you might want to put up an ‘under maintenance’ page. Many applications (Wordpress comes to mind) already include this feature, so it could be as simple as ticking a box and hitting save. An important thing to remember here is that just putting up a page on the front of your site isn’t going to be enough – people will be following deep links and/or already using the site.

Copy the site across

Take a copy of the site, move it to the new server and disable the ‘under maintenance’ page on the server you’re moving to. You might want to double-check everything is OK on the new server at this point, as pretty soon we’re going to hit the point of no (easy) return.

Edit the hosts file on the server

Next, add the hosts entry you made on your local machine to the hosts file on the server you’re moving from. You need this because we’re going to be proxying to the new server by hostname – if the old server still thinks it’s hosting the domain, we’re going to get ourselves in an infinite loop.

Alter the Apache Config

Now here’s where the actual proxying part comes in. In the VirtualHost declaration for the website you want to move, replace the existing config with the following:

  ServerName www.example.com  ProxyRequests Off

<Proxy *>

    Order deny,allow

    Allow from all

  </Proxy>

ProxyPass / http://www.example.com/

  ProxyPassReverse / http://www.example.com/

It’s also probably a good idea to leave your log statements intact – this way you can see how many hits to the old IP you’re getting.

Now run a config check (apachectl configtest), and reload the Apache configuration.

Remove the entry you made in your local hosts file earlier, and verify that the proxy is indeed working. If all is well, you should see an entry in your Apache log on your old server, and an entry in the Apache log on the new server showing the IP of the old server a
s the client.

Move DNS

Now the proxying is set up and we’ve verified it all as working, it’s time to switch the DNS across to the new IP address. From now on you’ll gradually get more and more connections directly to the new server.

After a week or two it should be safe to remove the configuration from the old server – I’d suggest checking the logs to ascertain when the last connection was received to the previous server. If it’s been more than a week, you’re probably safe.