Write barriers have gotten some discussion in the Linux world recently which is a good thing due to a lack of documentation about what write barriers are and when they should be used. Let's first start with the assumption that a user wants file system integrity over performance. This often means turning off write caching on all disks. The reason is that file systems rely on the disks not reordering write requests in order to maintain the integrity of the file system. Of course, turning off write caching harms write performance substantially so another option was invented: write barriers.

I recently tried the reniced package only to find that it isn’t a daemon at all as is indicated by its name ending in “d”. It’s too bad because if it was it could be useful. It could always be called frequently from cron in order to have a system that continuously adjusts the niceness of running processes. The config file is pretty nice as it’s just a list of a nice level pair with a regular expression to match against the list of processes. This can be useful to change the niceness of processes launched without any other mechanism for controlling the nice level. I found that running firefox and kvm with a niceness of 10 can keep either from making the rest of the system too unresponsive.

I haven't written about this issue yet but felt I should say something as it took most of my last week in resolving. I've read a lot about people dealing with this problem and yet very few seem to truly understand the implications. The bottom line as far as I'm concerned is that all Debian and Ubuntu systems built with the vulnerable package should be considered compromised. And that means a lot more work is needed to secure the systems than just regenerating ssh keys and ssl certificates. Now, I realize that rebuilding all machines might be too much work for many sysadmins. My plan is to rebuild all my host machines and simply consider my virtualized guests to be compromised. Whether that is a wise idea remains to be seen. At a minimum people should not only update all of their keys and certificates but also reset all passwords on the system. At that point one can just hope that no one compromised their machines during the extended period of vulnerability.

A year or so ago I migrated from cfengine to puppet. Lately I've been less than pleased with puppet. It has issues with using too much memory (especially when recursing directories with many files), it recently broke on any directory string ending in a slash, and version 0.24.4 clients are not compatible with servers before 0.24.4. I took a look around but the landscape hasn't changed much. I suspect bcfg2 might use less resources but I really dislike the idea of using XML configuration files. I'm not sure puppet's syntax is the best either but at least it's relatively concise and powerful. And I'm not going back to cfengine. So I guess puppet remains the best option, but that may not be saying much.

I setup a virtual server for a client to host a Rails application on an Ubuntu 7.10 system. Here I have documented the steps to install all the necessary pieces of software. This is a MySQL5.0/Rails2.0/Mongrel1.1/Apache2.2 setup with Subversion for source code management. I realize that Apache is not the most popular frontend but for this client security and maturity are important. I also realize that their are alternatives to Mongrel, MySQL, and Subversion as well that are well worth considering. So rather than this being THE Rails stack I think of it as A Rails stack suited for a particular customer.

I've been looking for a program that would be a top-like program (ie would display a screen of information and refresh every couple seconds or so) but would give an overview of an entire system. In particular I've wanted something that could quickly narrow down the question: "Why is this server sluggish?" Traditionally I've had to use many tools to check whether the problem was CPU, Load, IO, Network, etc. So while doing a completely unrelated search (using `apt-cache search` for programs dealing with swap) I came across saidar and it seems to fit the bill nicely. It displays information about processes, memory, disks, and networking in an easy to read and digest format. It's not perfect and I might offer some suggestions to the developers but it's the best thing I've found so far for the purpose I have.

I’m becoming increasingly convinced that PAM is far more important than it is usually treated. It seems like more reading on how to leverage PAM to increase security would be wise for any GNU/Linux system administrator. I came across Been Cracked? Just Put PAM On It! and found it to be a good guide.

I was just going through the CD’s in my toolkit and thought I’d share the useful CD’s I carry around these days.

• Ubuntu - Desktop/Server/Kubuntu i386/amd64 (6 CD’s)
• Debian - multi-architecture net install CD
• SystemRescueCd
• Ultimate Boot CD
• Knoppix
• OpenDisc