As mentioned in a previous message (which many people on the list probably didn't get) I've just moved the LUV server to a VM in Germany courtesy of Paul Menzel who pays the rent on the physical hardware. We had a few problems along the way with DNS records not updating when I wanted them to and with the wrong IP address being used for outbound mail - which caused some servers to correctly reject mail on the basis of bad SPF. DNS is now correct and has been correct for long enough that I expect most systems won't have old addresses cached any more (Google DNS has had the new values for a while). Andrew has started the process of gaining control over the DNS (which is registered in the names of people who haven't been committee members for a long time). We need to get that done before VPAC turns things off. My current plan is to use 2 servers that I run for LUV DNS secondaries. I've been a LUV member for 20 years and both the servers in question have been running for that long (one of them hasn't even changed it's IP address). I think that will give some assurance that things will keep working. As an aside if anyone knows how to contact the people running russell.linux.org.au and the creativecontingencies.com DNS servers about changing the entries for LUV then please let me know off-list. When running at VPAC the watchdog table in the Drupal database took up 20G of disk space and as it was in the ibdata1 file there was no good option for freeing the space even after deleting most rows. As part of the migration to the new server I dumped all MySQL databases and imported them. That solved the disk space problem and as I now have MySQL configured for a file per InnoDB table I will always be able to OPTIMIZE TABLE if I have that happen again. echo "delete from watchdog where timestamp < unix_timestamp() - 604800;" | mysql luv_drupal The above command is in a cron job to delete the old entries from the watchdog table. It would be good if we could fix the Drupal problem that's causing those entries (but I don't know how to do it or have time to learn). It would also be good if we could configure Drupal to not store millions of rows in that table (it's supposed to automatically delete old rows but doesn't). Assistance from Drupal experts is welcome. One thing I want to do is to convert the server to BTRFS. BTRFS snapshots is the best way of backing things up. Going forward I want to have much better backups of the server. The fact that I can't visit the server room any more makes them much more important as does the fact that data is crossing jurisdictions. I will resend this message tomorrow to make sure everyone gets it. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/