Wandering Thoughts archives

My standard Gnome customizations

I don't use Gnome on my primary machine (it runs a peculiar, entirely custom environment), but I do use it on a number of secondary machines and I keep making more or less the same customizations each time. So I'm writing them down, if only for my own reference on the next machine.

• I disable gnome-terminal's blinking cursor.

• I turn CapsLock into an additional Ctrl. This is in the Keyboard preferences area, Layout tab, 'Layout options' button, and in the 'Ctrl key position' section. (It is not even cross-referenced in the 'CapsLock key behavior' section.)

• I add to the top panel widgets for gnome-terminal, locking the screen, and sshmenu, and then import my usual .sshmenu configuration file.

  On laptops, I also add the screen brightness applet and a custom launcher to run 'xset dpms force off', because various things have convinced me that this is the single best thing I can do to increase battery life.

  On desktops I usually add the weather applet, which feels vaguely lame but at least lets me be depressed at a glance most of the year.

• on desktops, I use gconf-editor to turn off the /apps/gnome-session/options/logout_prompt key, so that when I select 'log out' from the menu it actually logs me out on the spot without prompting me about things. I tend to leave it as-is on laptops so that I can easily select 'power down' or the like.

  (In the inimitable Gnome way, this used to be exposed as an actual preference but no longer is.)

• I add some Firefox extensions that I really can't live without any more: NoScript and usually All-in-One Gestures. Sometimes I apply my usual Firefox settings; it depends on how much I'm going to use the machine.

  (I am addicted to AiOG if I have a mouse, but on laptops it sometimes feels like it doesn't make all that much sense.)

Further laptop customizations:

• I turn off the X server's bell by adding an entry to the Startup Programs list (in the Sessions preferences area) that runs a script that runs 'xset b off'. I loath my laptop making noises in things like meetings just because one of many programs has decided to print a ^G to get my attention.

• I set the screen saver to activate as fast as possible and turn the display off as fast as possible when the laptop is on battery power. I usually use one or two minutes of idleness for the screen saver and one minute (the Gnome minimum) for screen blanking.

• on 'narrow' screens (which these days is anything less than 1280 pixels across), I take the personal information applet out of the top panel because it just wastes valuable space.

I do not set laptops to dim the display when they go on to battery power; I can do that myself if I need to, and I otherwise want the screen to stay at whatever brightness I find most readable.

Sidebar: my sshmenu dream

I find sshmenu reasonably handy, but as it is it has one little irritation; you have to add hosts to its menu. What I hoped for when I installed it was some sort of text widget that lived right in the top panel that you could type hostnames into and it would start ssh sessions to (in terminal windows).

This is probably a dream peculiar to sysadmins, since I wind up ssh'ing off to far too many machines to put into a menu structure. As it is I just put the most common machines into sshmenu's menu, and fall back to gnome-terminal and explicit ssh'ing for the others (which takes just enough extra work to be irritating, but not enough extra work to get me to find out how to write Gnome applets in Python or Ruby).

Why I would still like MC/S in Linux

I recently ran across MC/S vs MPIO, which is about why iSCSI's 'multiple connections per session' feature is apparently considered a bad idea and is not likely to be implemented in Linux, the short summary being that it is an iSCSI specific duplication of generic multipathing functionality. Unfortunately, I sort of disagree with this in practice.

In theory I don't care about how my multipathing is done, I just want something that makes general iSCSI multipathing work right. In practice, right now generic multipathing doesn't seem to be up to the job.

The starting bad sign for me is that the Linux iSCSI target developers will generally give you reasonably scary warnings about using multipathing for anything but failover. There's specific reasons, but I think that they can be generalized to something simple: you have to trust the initiator to get all of this generic multipathing stuff right, and it may not. (And I know that there are some initiators that do not get it fully right, because we use one.)

(Also, you have to trust the target to get all of the necessary supporting SCSI infrastructure correct, even the picky bits. It's possible that some targets are known to be incomplete there.)

The great attraction of MC/S for me is that it is conceptually quite simple and does exactly and specifically what I want, partly because all sides know just what is going on. Full generic multipathing is much more indirect and complex, and its very generality means that it necessarily has more chances to go terribly wrong.

(iSCSI being iSCSI, I'm entirely willing to believe that MC/S is actually a baroque pile of complexity once you read the actual specification. I haven't, so all I can go from is outside appearances.)

A Gnome irritation

Here is one of my periodic irritations, posed as a question:

How do you revert a modern Gnome application's settings back to completely stock values?

In the traditional Unix world, programs wrote their settings to dotfiles (sometimes dot-directories). If you wanted to reset a program back to its starting state, you removed the program's dotfile or dotdir, and you were done. In the modern Gnome world, not so much, because dotfiles are old fashioned now.

(Oh, some programs still have dotfiles or dotdirs, and you'd better remove them too. This is part of the irritation.)

These days Gnome applications store most or all of their settings in gconf, which is one of those great big magic databases like the Windows Registry. And just like what happens with the Windows Registry, your gconf database will accrete all sorts of cruft over time as applications dump settings in there and they never get cleaned up. Maybe the application got removed; maybe you stopped using it; maybe the application changed the keys it uses and didn't clean up the old ones for various reasons.

So the answer to my question is 'you have to remove the application's keys from your gconf database somehow'. I am sure that there is a magic incantation of some utility that will do it, but I don't know what it is and it is not exactly documented. Apparently reverting settings is something that's supposed to be left up to applications, or just not considered important.

(One might innocently think that removing files from ~/.gconf would do it. Not so fast; you probably have a running gconfd process which is holding everything in memory too, and if you try this it will helpfully rewrite those files you removed when you, say, log out.)

How I went wrong in thinking about /boot mirroring

I've always seen how a mirrored /boot could work if the disks were absolutely identical up to the end of the /boot partition; if they were identical, the absolute block positions of everything that the boot blocks wanted to load would be identical, so nothing would care about which disk it was talking to. My concern was always what happened if the disks weren't quite so utterly identical, because back in the day it seemed to me like that required quite a lot of magic.

(I'm going to neglect here the magic necessary to see through the software RAID to get the block positions on the real physical devices.)

But how much magic it requires depends on how much you want out of mirroring /boot and a mirror-aware bootloader. The simple version is that /boot is just replicated and your boot blocks on each disk will only boot from that disk's copy of /boot; this lets you survive a total disk failure but not something that destroys the primary copy of /boot (well, not without turning it into a total disk failure). The most elaborate version is that if your boot block(s) and any version of /boot survive, the system will still boot.

(In the days that I started thinking about this, I did set up LILO by hand so that it would in theory do the full version. Mind you, in the LILO days this was more of a potential concern, since there were somewhat more ways to destroy the bootability of /boot.)

My impression is that GRUB's mirror awareness is limited to the first version. This is conceptually straightforward; each disk's boot blocks only have to know about the absolute block position of things on that disk, and the setup program just has to be aware of how to work that out. Alternatively, it has to be completely oblivious to mirroring and only work with the low-level 'below of the mirror' view of the partitions. (I believe that the latter is what GRUB does, since you tell it what hard disk partition to look at when installing things.)

Setting up the full version would be much more complex and challenging. In the extreme case (where the /boot mirrors have different partition numbers), the boot block would have to be able to probe the disk, find the right partition, and then load things from there. Given the severe space limitations that boot blocks operate under, I suspect that no one does this.

(The full version is feasible if you assume that the absolute block positions are identical across all drives; then you can just try to load things from each drive in the system in turn until you either find one with a valid signature or you give up.)

An interesting hardware mystery

As I've written about, I have a problem machine. I have recently had the opportunity to stop using it as my office workstation and thus do some systematic testing on it, which has turned up some interesting yet mysterious results.

(It's remarkable but perhaps not surprising how much my mood has improved from getting a stable primary workstations and setting up these tests.)

The short summary is that the machine reliably crashes if I do significant disk activity and I am not running something that burns up CPU. (To be technical, I have only tested running the distributed.net client.)

The machine survives a whole bunch of tests; so far I have tried memtest86+, simply leaving it sitting idle, the distributed.net client ('dnetc'), dnetc plus continuous full speed bidirectional network traffic, dnetc plus lots of NFS activity, and dnetc plus repeatedly running bonnie++ and compiling the kernel. However, running just bonnie++ (with or without compiling the kernel) will kill the machine in short order. The most striking test I have done is to start dnetc, start bonnie++ and the kernel compile cycle, and then after a while kill the dnetc processes; the machine consistently panics within minutes.

(Since I normally run the distributed.net client on my machine but stopped after the Fedora 10 upgrade, this means that I may have had the hardware problem for quite some time without realizing it.)

All of this adds up to a puzzle: what bit of hardware is broken and needs to be replaced? If the failure mode was simpler there would probably be a clear likely suspect, but as it is I'm left scratching my head.

Sidebar: hardware details

The machine has an Asus M2N4-SLI, 2 GB of RAM, and I believe an AMD X2 4600+. It currently has a single SATA drive, but had two earlier (and the two drives are fine; they are running in my current office workstation). The graphics card is likely to be irrelevant, since this has happened with both an ATI X300 and now an nVidia of some description (running the open source drivers).