The Hand of FuManChu

In an attempt to automate our backups (my PFY was doing manual DVD burning every day), we bought a Dell Poweredge SC420 with a pair of 250G SATA drives and no OS. It'll go either to our disaster hotsite, or a colo. The only thing the box will be doing is rsync over ssh. Our various nix and Windows servers (via cwrsync) will connect on a schedule and back up various top-level directories. Testing on a different server over the 'Net showed typical backup times of 5 to 10 minutes for one such directory, depending on how much had changed overnight. We expect to have backup traffic for about 1 hour each night, up to a max of 4 hours (rarely). Email will, of course, be the killer. We may go back to CD's/DVD's for that.

At any rate, here are the steps I went through to set up the Dell server:

• Setup (F2): make box power on when power lost and restored.
• Configure SATA by hitting Ctrl-A at boot, no RAID.
• Insert sarge debian-installer CD and boot from it. I can't praise the Debian team enough--the debian-installer is fantastic! Thanks to Greg Folkert for recommending it!
• At FIRST prompt (F1 for help or enter to boot), type "linux26", hit Enter (this selects the 2.6 kernel).
• SATA drives should be auto-recognized. Partition them ext3 and mount to /data1, /data2.
• Finish install normally.
• CD ejects and box reboots. When Real Time Clock freezes (twice) during boot, hit Ctrl-C to kill the hung process and continue boot. This is an ACPI problem, which we'll fix in a minute.
• Continue setting up Debian as prompted. linux.csua.berkeley.edu is a nice http mirror for me. Oh, and run the ssh server in protocol 2 only.
• apt-get remove exim4, which won't work. But it's fun to try. Anyone know why it isn't removed (still shows up in ps after removal/reboot)?
• Turn ACPI off, or the Real Time Clock will freeze on every boot:

    vi /etc/grub/menu.lst
    Change the lines starting with "kernel": append the text " acpi=off".

• Mount the SATA drives:

    cd /
    mkdir /data1
    mkdir /data2
    vi /etc/fstab

    add the lines:
       /dev/sda1 /data1 ext3 defaults,errors=remount-ro 0 2
       /dev/sdb1 /data2 ext3 defaults,errors=remount-ro 0 2

• Change the order in which discover and checkfs are called:

    cd /etc/rcS.d
    mv S36discover S29discover

• Setup rsync

    apt-get install rsync
    vi /etc/default/rsync (set RSYNC_ENABLE=true)
    vi /etc/rsyncd.conf (see online docs)
    /etc/init.d/rsync start

• Setup ssh

    vi /etc/ssh/sshd_config
     PermitRootLogin no
     RSAAuthentication no

• make an rsync user

Another Scott on IWETHEY asked me to expand on why I chose b2evolution for the blog software here, especially in relation to this post. I'm awfully bad at recording my decision-making processes, but I'll try.

Lots of blogs I examined failed one of our requirements outright, or at least offended my sensibilities :

• Wordpress: Multiple blogs aren't built into the core. There's a separate Wordpress-mu project, but it seems to be still in serious beta, with only one developer actively working on it.
• Blosxom: Perl. Bleah. If I used it every day, maybe. But the blog is something I want to work on (writing plugins, etc.) once or twice a year. PHP is something I can pick up quickly; in fact, I wrote my first working plugin for b2evolution in an hour, never having even looked at PHP code before in my life. By the end of the afternoon, I had a patch ready (against CVS-HEAD) for applying plugins to comments (not just posts), with enough confidence to mail it off to the project leads.
• Serendipity: no multiblog as far as I could see. By "multiblog", I mean multiple authors on one install, each with their own blog (each with their own feed(s)). We have 40 people on staff at Amor, each with their own financial supporters with whom they wish to communicate. Those who support me don't necessarily have any interest in reading what my co-workers are writing (but if they want to read what everyone at Amor is writing, b2evolution gives them that opportunity out of the box, as well).
• Textpattern: editing is done with Textile, and the whole editing process is very HTML-centric. If I were the only author, it might fly. But I have a wide range of authors, from complete Luddites to, well, me. HTML is something to hide from many of them. For b2evolution, on the other hand, I quickly found and applied a plugin to use Markdown. Users can also choose GreyMatter, BB code (a la phpBB ), Textile, or Texturize, all included in the default install.
• Nucleus. Same parent as b2evolution. I honestly can't remember why I chose b2evolution over nucleus, except for a vague feeling that nucleus was written by developers for developers, instead of for users. Oh, yeah, and the thumbnails didn't work, at least not quickly and easily enough. The whole "media library" idiom is nice for developers, but some of my users would never be able to add a picture to a post, a task they will desire to do quite often.

Meh. That's enough for now. b2evo has had its own quirks, but the problems have been surmountable with a minimum of effort. I think it will serve us well enough.