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.
Mic reported that email occassionally took significantly longer than normal to send. I made a tentative conclusion that we were running out of spamd processes. There is also a chance we were running out of connections to the database, so I up'd the maximum number of connections from 100 to 256, and the number of buffers accordingly.
Present: Dan, Skylar, CharlieP
* Error trapping in new backup script (Skylar)
* Create image plugin with offset from convert (Skylar)
* lm_sensors on image (Dan)
Thanks to a tip from Hassan, I discovered that nodump acutually is not doing quite what we want it to do.
The basic story is that dump by default only honors nodump on incremental dumps rather than full dumps. I've added a "-h 0" flag to all the dumps in backup.pl to solve this problem.
To make this easier to spot in the future, I'm also working on a complete re-write of the backup.pl script to do proper error checking and urgent email notification of the admins. I'm trying to modularize it as much as possible to make future changes as easy as possible.
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 upgraded SpamAssassin on quark to 3.0.0 to take advantage of the latest and greatest spam definitions, I also configured it to use the Postgres backend for more flexibility in upgrading in the future.
To do the upgrade, I performed these steps:
1. Created a Postgres user "sa-user" owning the database "sa".
2. Populated the database with schemas from the sql directory in the source tree.
3. Added these lines to /usr/local/etc/mail/spamassassin/local.cf:
# SQL config
bayes_store_module Mail::SpamAssassin::BayesStore::SQL
bayes_sql_dsn DBI:Pg:dbname=sa;host=localhost
bayes_sql_username sa-user
bayes_sql_password xxxxxx
user_scores_dsn DBI:Pg:dbname=sa;host=localhost
user_scores_sql_username sa-user
user_scores_sql_password xxxxxx
4. Built p5-Mail-SpamAssassin-3.0.0 from ports, with the SQL tests enabled.
5. Stopped spamd, and started it with "spamd -c -D" to make sure that it was connecting to the database properly.
6. Restarted spamd with the new script, /usr/local/etc/rc.d/sa-spamd.sh.
Present: Skylar, Dan, Charlie
* Modify no_dump.sh to add .mozilla cache and *.iso (Skylar)
* Continue working on sensors (Dan)
* Trim weather-cam (Skylar)
* Use Ethereal to track down RT problem on image (Skylar)
* Write script to send mail to top n disk hogs (Dan)
* Check for image plugin for MT auth (Skylar)
* Work on hopperprime (Skylar)
Once again, RT has bested me.
I tried to move RT to image. Everything is ready to go. IP alias worked out. Apache set up. Perl modules installed. Except when I move it, it refuses to authenticate. I have the DatabaseHost in RT_SiteConfig.pm set to quark.cs.earlham.edu, but it never finds it. Nothing gets logged in /opt/rt3/var/log/rt.log. Ideas?
I've finally gotten a test-bed TWiki installation running on quark. Right now, I've got a Sysadmin web, with key schedule and server information topics. I've still got to get a better authentication scheme working though.
Present: Dan, Charlie, Skylar
* lm_sensors on some machine in 4th-floor closet (Dan)
* Backup script rewrite (Skylar)
* Tape drive addressable as one unit (Skylar)
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.