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.

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

Dag Wieërs has too, and being the kind guy he is, he’s posted a quick guide to undeleting an open file.

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.

Instead, here’s that other geek blog staple, an xkcd post: