BOFH Hunter

RHEL 5.4 and XFS

There’s been quite a bit of interest in the XFS offerings included in the 5.4 release of RHEL, and unfortunately it hasn’t really lived up to the hype. There are a few things you’ll need to know if you want to use the included xfs support

• It’s not really included: The XFS kernel module is only in the x86_64 version of the kernel. If you’re using the x86 release, you get no XFS module.
• There aren’t any XFS tools included either: The xfsprogs package isn’t included in RHEL 5.4 Server (see RH’s own BZ #521173 about this). So basically mkfs.xfs isn’t included. That’s not very handy if you were hoping to actually USE xfs.
• Anaconda won’t let you use XFS either: If you’re doing a fresh install and you boot anaconda with the XFS option, you get all the nifty little XFS options you’d expect when you set up your partitioning scheme. The downside is that once anaconda has all the information and tries to actually format things like you told it to, it segfaults. Why? Because it can’t actually MAKE the XFS file system. The tools aren’t there, remember?

Now, many of you may be saying “But Red Hat TOLD me to use xfs in their release notes!” and yes, yes they did. Quoting the Release Notes from RHEL 5.4 we see this ->

Users of GFS2 that do not need high availability clustering are encouraged to look at migrating to other file systems like the ext3 or xfs offerings. The xfs file system is specifically targeted at very large file systems (16 TB and above).

I’d really like to see RH fix support for this, because XFS is an excellent file system, and has some excellent performance when paired with things like MySQL databases.

Red Hat: if you’re listening, please reverse the decision on https://bugzilla.redhat.com/show_bug.cgi?id=521173 and include the XFS toolkits. Your users will thank you for it.

dm-multipath and the ds4700

For around a year now, I’ve been wanting to move away from IBM’s (okay, LSI’s) rdac mpp drivers used for the ds4XXX  series disk chassis on RHEL and CentOS. When RHEL 5.3 came out boasting support dm-multipath support for the DS4XXX series, I was understandably overjoyed. The only problem was I couldn’t make it work. After several rounds of cursing, muttering and poking folks smarter than me to help out, the problem became immediately clear.

The example configs which work fine for the ’supported’ platforms have a text string mismatch when using the ‘unsupported’ ds4700. Basically you have to change a bit of text slightly because the hardware identifies itself slightly differently. Who’d have thunk it, right?

Below is the multipath.conf snippet I’ve been using now for the past month with some pretty good success.


defaults {
user_friendly_names yes
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^(hd|xvd|vd)[a-z]*"
wwid "*"
}
blacklist_exceptions {
wwid "3600XXXX"
}
devices {
device {
vendor "IBM"
product "1814 FAStT"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_rdac /dev/%n"
features "0"
hardware_handler "1 rdac"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
no_path_retry queue
rr_min_io 1000
path_checker rdac
}


Now clearly you’ll have to modify the wwid to suit your own environment, and you’ll also want to exclude the non-multipath device references (/dev/sdb for example) from lvm.conf if you’re using lvm.  This got things going for me, so hopefully it’ll help others out as well.

A thank you to the community

I’m sure by now everyone who reads this has heard the news about the goings on of the CentOS development team. Within a few hours following the release of the open letter, the story had been picked up, chewed on, misunderstood, panicked over, and copied to a few hundred other places and blogs too numerous to count. The mailing list, twitter, and the irc channels associated with the centos project were (and still are) hotbeds of advice, discussion, and controversy.

One thing has stood out from the anticipated frenzy surrounding this, and that’s been the overwhelming support of the CentOS community. The number of people stepping forward to volunteer hardware, time, advice, and cash (even though we’re currently asking folks to not do that) has been tremendous, and it’s incredibly refreshing to know that we have the backing of the community in what we’re doing.  I’d like to take a moment to personally say thank you to everyone who has been kind enough to offer their support or has made the effort to thank the developers following the announcement. This kind of support and outreach is what makes the project great, and what keeps people helping out.

Thank you.

Feedback!

There were loads of interesting comments and corrections about the security page on the CentOS wiki.  I’ve made a few updates regarding some missing sections, and some minor corrections. What I’m interested in now are the other security pages that the community might want. I’d like to turn this into a full blown wiki section for security, detailing basic web server security, mail server security, ssh protection, and more. What would the community (or at least those of you who read this) want to see first from a network application standpoint?

Hardening CentOS

This is something that I’ve griped about in the past, but without taking action, griping is basically just annoying other people in an arrogant fashion. Now while I’m very good at doing this, I’d much rather do something to help people provide proper security for their systems.

To this end, I’ve started a page on the CentOS wiki (Hardening CentOS)  that will very likely turn into its own section in the future. This page uses Steve Grubb’s RHEL hardening guide, as well as the NSA’s RHEL 5 security guide as the basis for locking down the operating system in a reasonably secure fashion. I do not claim it to be all-powerful, nor will everything there apply to everyone in all instances. Take from it what you need to. What is covered on the page is the basis for locking down a system with very minimal impact to distribution standards or package changes. I’ll continue to add to this page, and break out other pages to encompass securing the distribution provided httpd, mysqld, etc as I get time.

If you find this information useful, please let me know. Comments and suggestions are warmly welcomed, so long as it’s constructive. As usual, the OMG-U-SUCK comments won’t get approved unless they’re accompanied by facts and/or evidence to support the opinion.

Once again, you can see this page at http://wiki.centos.org/HowTos/OS_Protection