I’m about done with my computer shuffling which I started a month or so ago. I have a 300g drive at work and a 120g drive at home. The idea is to replicate stuff like the MP3 collection, photos, system backups, etc. in both places, to guard against losing data to a disk crash.

The next challenge is to set up an mp3act server at home that replicates the one at work. I’m going to try doing this with MySQL replication. The idea here is to replicate the mostly-static music library tables with work being the master and home being the slave. Then, each site would have its own copies of the dynamic tables like playlists and playlist history. This lets me use one-way replication and avoid setting up a dual master/slave configuration, which I don’t think would work well with the dynamic tables, particularly WRT simultaneous access etc.

Yesterday and this morning I took the first steps toward doing this, which involved locking down my MySQL server at home, then setting it up to allow remote TCP connections (comment out the bind_address option in my.cnf). Then I needed to create a slave user, which I did by doing

GRANT REPLICATION SLAVE ON *.* TO slave@homedsl IDENTIFIED BY 'password'

The grant command will create the user if it doesn’t already exist.

Then, I needed to edit /etc/mysql/my.cnf on both the master and the slave, to give each one a unique server ID. I gave the master an ID of 1 and the slave an ID of 2. This is accomplished in the [mysql] section of the config file, with a line like this:

server-id=1

Next, I followed the instructions in the documentation (see link above) to lock the tables on the master and create tar archives of each of the databases I wanted to replicate (on my Debian box, each database has its own directory under /var/lib/mysql). I then untarred the databases into /var/lib/mysql on the slave. For each database I was copying, I added a line like this to the slave’s config file:

replicate-do-db=database-name

I found that if I wasn’t replicating all the databases from the master, the replication would fail unless I explicitly listed the databases like this. The slave expects the tables it’s replicating to already be present — it does not “automagically” create tables as part of the replication process. I wasn’t really clear on this point after reading the documentation; it was only clear after I actually tried it.

With the tables copied over and the configurations tweaked accordingly, I followed the docs to record the master’s ‘state’ info, point the slave at the master, and start the replication threads on the slave. This all worked as expected. All in all, it wasn’t too hard to set up, so I’ll see how well it works going forward.

What a difference a video card makes…

A couple months back I tried getting a Dell 2007WFP working with X, using the Intel graphics controller built into my motherboard. I didn’t have much luck. Well, now I have a new video card, with an nVidia GeForce MX 4400 chipset. And, all I had to do was specify the card, driver and resolution (1680×1050) in my xorg.conf, and it worked right away. Great. Still more work than it was with my Mac (where I just plugged it in and it worked), but not bad at all, especially considering that this is X.

Still a few things to be resolved:

1. The new card is only working through the VGA port. Need to figure out what magic incantations I need to use DVI.
2. Apparently I can’t use the onboard graphics controller and the new (AGP) card at the same time. As soon as I plugged the new card in, it was like the onboard controller didn’t exist. So, I’m still stuck using the old Matrox PCI card for my other monitor. The Matrox only has 8mb video memory, which limits me to a 16 bit display depth. The MX 4400 apparently supports multiheading via the DVI port and VGA port, so I’ll have to see if I can do this with X.
3. The widescreen monitor is vertically smaller than my other standard-resolution flat panels. I’m getting a little squinty-eyed staring at it. I think I may make it the “secondary” display and use a physically larger screen as my “primary” display.

But all in all, I’m really happy to have the 1680×1050 working, and without much extra fiddling or hair-pulling.

On another note, I’ve restored sonata to a new drive (after its old drive crashed). I lost a few files before I backed the dying drive up. The system works fine, but fonts in some applications are screwy (screwy fonts in X is a relative term, of course…). So, I may end up reinstalling the machine anyhow…

Followup… looks like I may need to use nVidia’s driver (instead of the built-in nv driver) to get multihead support. I’ll try that out later this week.

Well, the hard drive in sonata, my desktop machine at work, is dying a slow death. I saw the writing on the wall a few months ago, and now it’s finally biting the big one. I’m typing on the box now, but it’s slowly getting wonkier and wonkier as it churns out ever more i/o errors, read errors etc.

A new drive is forthcoming, but in the meantime, I’ve managed to back up what’s left of the old drive, so I can restore it onto the new one. And, I’ve found that when it comes to archiving drives with errors, cpio beats tar hands down. I started out doing

cd /filesystem
tar cvplf - . |
ssh other-box "cd /backup/disk; tar xpf -"

But, it dies as soon as it hits a bad spot.

I ended up doing

cd /filesystem
find . -xdev -depth -print |
cpio -o --verbose -H newc |
ssh other-box "cd /backup/disk; cpio -id -H newc"

The -H option is needed to back up files with inode numbers greater than 65535.

Cpio is even more obfuscated than tar WRT command line options, etc., but it seems to do a better job at disaster recovery.

Fun fun…

I’m beginning to think I need to set up a Wiki for this stuff.. but later.

Trying to get the sshdfilter stuff up and running on my new Debian box, and of course I didn’t document the process when I did it on 3 previous machines awhile back, so here goes.

1. Install sshdfilter script in /usr/local/sbin
2. Edit /etc/init.d/ssh. Look for two lines that look something like
   

   start-stop-daemon --start [...] /usr/sbin/sshd -- $SSHD_OPTS

   Replace them with

   start-stop-daemon --start --quiet --exec /usr/local/sbin/sshdfilter -- $SSHD_OPTS &

   Don’t forget the trailing ampersand!

3. Create an executable file /usr/local/etc/iptables.sh:
   

   
#!/bin/sh
modprobe ip_tables
iptables -N SSHD
iptables -A INPUT -p tcp -m tcp --dport 22 -j SSHD
exit 0


4. Modify /etc/network/interfaces. Under interface eth0, add the following line:
   

   pre-up /usr/local/etc/iptables.sh

And that should do it.

OK. Documenting this here for the next time I have to do this.

I’m working on setting up a computer that dual-boots into Linux and XP.

Rule 1: Always put Windows on the first primary partition on the drive. Linux can go pretty much anywhere else.

Rule 2: Always install Windows first, then Linux, so the boot loader will get set up properly. I knew this, but chose to do things the other way around anyhow (yep, I’m stupid that way). And of course, the XP install hosed the Linux boot loader, so I had to manually restore it, which was a big pain.

Here’s how I reinstalled the boot loader, for the next time I ignore my own advice…

1. Boot into the Debian netinst CD, or Knoppix, or Tom’s Root Boot, or whatever flavor of standalone Linux you prefer.

   With netinst, you’ll need to walk through the install process until it gets to the disk partitioning part (this ensures that the disk devices are loaded). Then, hit ALT-F2 to get a shell.

2. Create a mount point, say /disk, and mount your root filesystem there. Example: mount /dev/hda5 /disk
3. chroot /disk
4. Mount any additional filesystems you might need, like /boot, etc.
5. grub-install /dev/hda

That’s all I needed to do, but it took several unsuccessful attempts to arrive at this.

References: here and here.

I just wasted an entire day trying to get a new Dell 2007WFP working with my 3-year-old Dell GX270 desktop, which runs Debian. The result: total failure. It works at 1280×1024 (and looks all stretched out), but flatly refuses to work at the monitor’s optimal resolution of 1680×1050.

In the xorg.config file, first I tried just adding a new “Screen” resolution for 1680×1050. This failed with “no such mode” or somesuch. After much head scratching and googling around, I learned that I needed to patch my video BIOS (Intel 810 series) to add the new mode. I did this via a utility called 915resolution. This seems to work.

With 1680×1050 programmed into the BIOS, I then tried several different ModeLine entries in the config file, with varying different modes of failure. At certain settings, X would refuse to use the mode, complaining about “vrefresh out of range” or something. At other settings, when I started X, the monitor would go into power-save mode as if it wasn’t receiving a signal. At other settings, the monitor would display a message stating that the signal was out of range and it couldn’t use it. I fiddled with turning DDC on and off, to no effect. Everything I tried resulted in one of these three failure modes. I’m pretty sure I’ve got good ModeLine numbers, as they match what’s reported by DDC in the X.org log.

I’m pretty much at my wit’s end here, so I’ve given up for now and am back to using my old dual-monitor xinerama setup. Needless to say, I’m not too high on the whole Linux/X desktop scene right now. I’m ready to punt the thing and go to a Mac.