To reduce dependency issues, I've turned off NFS and NIS on backup. Root ssh logins are enabled, and I also set the password for the operator user to the insecure password, so either can be used for remote logins.
I've made significant headway in amanda, and need to generate a tapetype. I'm using the amtapetype utility, but that requires reading and writing to the tape drive for potentially many hours. I've disabled the daily cron job that writes dumps to tape to avoid interfering with this. I'll run the backup script manually when amtapetype is done.
I've setup a cron job on backup that will email us whenever it's time for a monthly backup. I also have written a short Perl script (/root/scripts/monthly_backup.pl) that will automate the procedure when following these instructions.
I've made some feature extensions and optimizations to the backup script.
* I've changed the function that gets the day. Instead of a big switch statement, I now use regular expression matching to get to all-lowercase.
* I've added indexing functionality, so that it's easier to know which dump a particular file is on. The indexes are stored on backup, in /var/log/indexes. The next directory levels contain respectively the year, month, and numerical day of the month. The last one contains the actual filesystem indexes.
The FreeBSD Security team reported today a vulernability with the procfs filesystem. This affects both 4-RELEASE and 5-RELEASE. I have successfully patched quarkprime and backup, and quark awaits a good time to reboot to get it patched.
Finally, I've gotten backup's new backup script working, with nice clean code and good error checking.
I started out using die embedded in an eval, but I ended up switching to testing $? (the exit status) after the eval. This proves a lot more flexible, and will allow us to react to different errors in a different ways.
After rewriting backup's script, I rewrote the dump script on quark, reusing as much code from backup's script as possible. quark's script is much simpler, because it doesn't have to worry about what tape/magazine it's on. Let's see how this works.
While working on the RAID setup, I noticed that backup couldn't be accessed from off the 159.28.230.0/24 subnet.
After some testing, I traced this down to backup's subnet mask being set to /16 rather than /24. This resulted in packets going off the local network being routed improperly. Changing the mask to /24 fixed the problem.
I've changed backup's RAID from RAID-1 (mirror) to RAID-0 (stripe).
This involved the following steps:
1. Made a backup of /backup in /usr/tmp on quark.
2. Rebooted backup into single-user mode.
3. Changed /etc/vinum.conf to look like this:
drive a0 device /dev/da1e
drive a1 device /dev/da2e
volume backup
plex org striped 275k
sd length 0m drive a0
sd length 0m drive a1
4. Did a "vinum resetconfig" followed by a "vinum create -f /etc/vinum.conf".
5. Did a "newfs /dev/vinum/backup"
6. Rebooted backup and restored /backup.
I've moved image's Ultra3 SCSI card into quark, to accomdate our plan (hope? dream?) of having our tape backup gear hook directly up to quark. All appears to be good. Kudos to Matt Hogan in helping me get quark in and out of the rack.
I installed OpenSSH 3.8p1 from ports, and symlinked all the binaries from /usr/local to /usr. I then changed the rc script to point to /usr/local, and symlinked /etc/ssh to /usr/local/etc.
I've install OpenSSL 0.9.7d on backup. People should link against this rather than the base install when compiling stuff.
Lots of stuff to update about backup. It is now running FreeBSD 5.2.1-RELEASE, and working better than under Red Hat Linux 8 Psycho.
More stuff:
1. To work the magazine, use the following procedure:
mt -f /dev/sa0 offline # Unload the current tape
chio move slot n drive 0 # Where n is the tape you want to load
2. Vinum's been a little tricky to set up. Here's the configuration file I'm using for mirroring:
drive a0 device /dev/da1e
drive a1 device /dev/da2e
volume backup
plex org concat
sd drive a0 size 0
plex org concat
sd drive a1 size 0
The concat plexes are just used as a placeholder; it's just one device on each of them getting the same data.
So far, it's pretty simple, but I ran into trouble with the second plex being flagged as faulty. Here's how to solve it:
init -v -w backup.p0 # Initialize the first plex
init -v -w backup.p1 # Initialize the second plex
start backup
start backup.p1.s0
I've upgraded image, backup, and proto to kernel 2.4.25. No problems detected thus far.