Winter Break

Whew, end of the fall semester. It seemed to fly by rather quickly. So anyways, I’m finally at home and able to do some full-time KDE hacking. I originally came home wednesday night, and found that Kuiper (my firewall box) had bit the dust some time ago. It’s fedora core 3 (hey, remember that one?) install seemed to have eaten its root partition alive somehow, as fsck couldn’t recover it, complaining about missing superblocks and such. I didn’t really want to spend a lot of time on a fancy recovery process, so I opted to install m0n0wall on it. I eventually got that accomplished. It took a while (I’ll explain it later this week), but it more or less works now. I need to add more memory to Kuiper’s case, as 64Mb isn’t cutting the mustard for the latest beta. I’m using the beta for the IPv6 support, which is really cool by the way. Yay modernization.

My internet on campus for my last few weeks on campus wasn’t cooperating (in short, I no longer trust UA’s network with /anything/), combined with finals kept me from pouring a lot of effort into KDE into KDE/Glovebox/Pointything. I haven’t been entirely out of the loop though, as I’ve managed to keep up with the commit mail and KDE mailing lists.

I’m not entirely done settling in yet though. I’ve got a few important things to do I didn’t get done last summer:

  • Rebuild my music collection server
  • Figure out how to remove the dependency on LDAP for my network-wide logins
  • Detatch Neptune from my network and bring it to Akron next semester
  • An IPv6 tunnel
  • Dynamic DNS

I already knocked one thing off my list with my install of m0n0wall: figure out port forwarding. Right now wm161.kicks-ass.net should have my home network’s IP address, and port 80 redirects to Saturn, while ssh goes to Jupiter. Both of those machines are down right now, as Jupiter is being stubborn and not turning on. Without Jupiter’s LDAP, saturn is clueless. I’m thinking its getting close to retire Jupiter from constant service anyways, now that Kuiper is capable of supporting an IPv6 tunnel and dynamic DNS updates to permit remote access to my network.

Comments »

Keeping your mythbackend alive

For my network, I’ve got two Mythtv machines. One is Saturn, the main recording backend. The other is Neptune, the supercharged media workhorse who has a frontend in addition to running my distributed DVD ripping, being part of a compile farm, holding all my music, and mysql databases.

Neither of the two are on a battery backup because I’m cheap, so when things go down, they don’t always come right back up. And sometimes Saturn’s mythbackend crashes. It happens.

So to prevent this, I added my mythtv-frontend user account to Saturn’s sudo list. Then I generated a ssh key and put it into the authorized_hosts file. Since all my accounts are managed with LDAP and /home is mounted over NFS, its really easy to syncronize both machines.

The final step is to change the ‘WOLBackendCommand’ setting in the database. The only sudo command mythtv-frontend can execute on Saturn is /etc/init.d/mythbackend restart. So I changed that setting to ssh saturn sudo /etc/init.d/mythbackend restart;sleep 5. The extra sleep allows for startup lag.

Now, if both machines go down, there isn’t a race condition between saturn waiting for neptune’s database to start before starting mythbackend. Once Neptune’s mythfrontend starts up it notices there isn’t a backend connection available. So it ssh’s into saturn, (re)starts the backend (It might be hanging, so thats why it restarts it), and waits politely for it to start.

Comments »