So, I’m just filing my income taxes for this year. I had to file for not just one, not just two, but three separate U.S. states. Ah, the joys of moving around. At least I should be settled for a few years at Oregon State now. Home of great biophysics and Gentoo — what could be better? =)
I couldn’t agree more, Dave. Got a patch? =D
I’m in the process of setting up a read-only root filesystem on a cluster, so I’m looking for ways to track all attempts to write to disk. Tonight I ran across a nifty little utility by Robert Love called inotify-glib, which looks like it’ll do just the trick. I plan to start it just before chrooting into the NFS root.
I just upgraded the kernel on the Pegasos to 2.6.11-pegasos-r3 from 2.6.10-pegasos-r1 (Gentoo’s patched kernel sources for Pegasos) and enabled preemption on a whim.
My Xorg tinderbox checkout-and-build time rocketed down from nearly four hours to just over one hour. That’s right, a ~70% drop.
Simon, people don’t read. This is a well-known fact — ever read this stuff by Joel, of Joel on Software? They will complain about how difficult something is, yet not read the accompanying instructions on how to get through it.
To sum your guy’s complaint up, it’s “I don’t read. If I need to read something, clearly it requires a Ph.D. and someone who takes two years to decipher it.”
O’Reilly ran a fairly useful article on how upstream can do a good job of creating downstream-friendly programs.
The last cluster admin around here had a “diskless” cluster setup booting from floppy, using Etherboot to boot directly into a kernel.
For increased flexibility and ease of administration, I’ve modified that. First, instead of using http://rom-o-matic.net/ to create the floppies, I build them manually from Etherboot source. That allows me to have one floppy for all the different network cards in the cluster, rather than one floppy per card type.
Also, I’m booting from Etherboot to the PXELINUX bootloader, which allows me more flexibility in booting than shoving a kernel straight into the computer’s face. PXELINUX not only allows me to custom-select kernels, boot options etc as a standard bootloader would, but it also allows a separate configuration per MAC address, so I can customize on a per-node level.
What I’ve done is create a master PXELINUX config file with variables that get replaced on a per-type, then per-node level when I run a small shell script called propogate_pxelinux_changes. Each MAC symlinks to its type, and the types are derived from the master. That keeps administration simple by minimizing the files that change.
As for DNS and DHCP, dnsmasq worked like a charm! After some stupidity on my part with setting up the routing from my server at 192.168.0.1 to get to the nodes at 192.168.1.0/24, things are fantastic. It was far easier to configure than BIND and ISC DHCP would have been. I’m able to set the IP and hostname again based on the MAC address in one location rather than keeping separate records on each node somehow, or a pile of separate configuration files on the master.