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.

If you’re looking for a book to help you configure the excellent systems monitoring software Cacti, then Cacti 0.8 Network Monitoring is, at least as far as my brief searches on Amazon could reveal, your only choice. At just 116 pages it’s a relatively slender tome, but is it worth the purchase?

The book starts off reasonably – it gives a clear guide to installing Cacti on a Debian system, and also installing Cacti from source. With any book of this nature there’s always the problem that there are so many different forms of Linux/Unix on which the application can be run – Cacti supports Linux, BSD, MacOS, Solaris – that you could fill a whole book just detailing the differing installation steps.

The next few chapters, in fact the bulk of the book, concerns the basic configuration of Cacti – adding devices to be monitored, arranging the graphs and user management. Again, the explanations here are competent if not exceptional.
I think it would have been beneficial if the book had contained at least some basic details on how to enable SNMP on some common devices that are likely to be monitored – perhaps a couple of lines of Cisco config, some details on installing and configuring net-snmpd possibly. Unfortunately the book covers none of this.

For the more advanced user, the book has a reasonable high-level overview of the SNMP protocol, but is rather short on the details of writing your own Cacti plugins. The topic is covered, but includes little more information than the help text displayed on screen within Cacti itself. For me, this was the biggest disappointment with the book.

Overall, the book is a reasonable purchase for those unfamiliar with Cacti, particularly given the lack of alternatives. Those hoping to find a guide to more advanced topics will be disappointed however, with more comprehensive information available in the Cacti documentation on-line.

Simple change your check_https command definition (in the file /etc/nagios-plugins/config/http.cfg on Debian/Ubuntu) to the following:

define command{
command_name check_https
command_line /usr/lib/nagios/plugins/check_http --ssl -C 14 -H '$HOSTADDRESS$' -I '$HOSTADDRESS$'
}

The ‘14′ in the command line is the number of days prior to expiry Nagios should warn you to renew the certificate – change as appropriate.
Now Nagios will produce a warning when your SSL certificate is close to renewal time, and show status CRITICAL if you let it expire anyway.

Anyway, we wanted to integrate monitoring of Varnish into the existing Cacti setup we have, and so I wrote a little plugin to do this.  It’s loosely based on the code posted here but it’s more ‘inspired by’ rather than based upon.

It produces just one graph (above), which shows the number of requests/second, hits/second and misses/second.

Installation is pretty straightforward:

• Make the Varnish management daemon available to your Cacti machine (Make sure you lock down appropriately with iptables or similar, because there is no authentication for this interface)
• Copy get_varnish_stats.py to your cacti scripts directory (/usr/share/cacti/site/scripts in Debian/Ubuntu)
• Import the XML template via the Cacti interface

You can download the plugin here.

Most of this discussion revolves around the technical merits of Tornado; whether other platforms are quicker, or whether it’s too limited.  Whilst interesting, I think that many of these discussions are rather missing the point.

What I find interesting about FriendFeed is that it was built primarily because of the requirements of the way the FriendFeed site works.  To give an overview without getting too much into the technical details, the difference is in the way real-time data is updated.
The way pretty much every other website works with regards to updating data is to poll for updates at regular intervals.  FriendFeed works differently; they create a connection to the server, and sit there waiting for an update.  When an update does happen, it displays immediately, because there’s no need to wait for a polling update to run.
A website that works like this, with every user having a connection open waiting for an update, isn’t feasible to create when using a mainstream web server (Apache, Nginx, IIS), because they are designed with the older ‘open a connection, send the data, close the connection’ way of working in mind.

I expect that as desktop software dies out and everything moves to a web-based ’software-as-a-service’ approach it will become increasingly common that parts of the site will run on custom-written software.  The days of the dominance of Apache are over, not because another better webserver daemon has come along, but because with increasingly complex webapps one size no longer fits all.

For a while now I’ve been using the following in my SSH .config file to allow me to SSH ‘directly’ to such hosts:

Host ultimate-destination-name
  ProxyCommand ssh -q intermediary-host nc %h %p $*
  HostName ultimate-destination-host

Where ‘ultimate-destination-name’ is the friendly name for the remote host – this probably shouldn’t be a hostname to avoid confusion, ‘intermediary-host’ is the Internet-accessible host to connect via, and ‘ultimate-destination-host’ is the local hostname/IP for the destination machine, ie what you’d type after ssh once logged into the intermediary host.
You’ll need netcat installed on the intermediary host for this to work.

Apart from the obvious advantage of being able to just type ’ssh foo’ to get straight to host foo, this method also allows you to use your local ssh keys without any sort of trust arrangement.

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

First, find some general information on the environment:

Show the JVM system properties

jinfo [pid]

Show heap space usage

jmap -heap [pid]

Show object memory usage

jmap -histo [pid]

Next, find out some more specifics about what the app is actually doing:

Take a thread dump

pkill -3 java; sleep 5; pkill -3 java

We do the kill -3 twice to show if threads are stuck in a particular state – add more as required.  The thread dump is written to stdout for the java process.  This will be catalina.out for a Tomcat app, elsewhere for others, check the init script for clues.

Take a stack trace

jstack [pid]

For apps using JNI you can take a mixed-mode trace by doing

jstack -m [pid]

and piping the output through c++filt. On Solaris, c++filt can be obtained as part of Sun Studio Express

Hopefully by this point you should have enough data to at least give you some clues as to where the problems are occuring.