Over the past year the department has improved backups with respect to:

• Accessibility, but having on-line backups to large capacity backup servers;
• Diversity, locating one of two backup remotely, to reduce site-risk;
• Security, with end-to-end encryption so that the remote server does not have the data nor keys;
• Correctness, by making sure the data is in a consistent state throughout the backup.

The problem of backup is more nuanced that it first seems. While most users want from a backup the restoration of a deleted file, the aim of a backup is to restore a machine to the state it was in at a certain point in time. These time points are, for instance, nightly for the past week, weekly for the past month or so, and then several monthly or semi-monthly going back for whatever number of years desired. That this might include the ability to restore a user file is somewhat coincidental.

In default of a separate backup mechanism more appropriate for user files, the response is to segregate user data from system data, and to make sure the periodic backup system has appropriate spacing, retention and technology independence for the purposes of user data.

The accessibility, diversity and security requirements are met using a remote machine, with a standard dump piped first though openssl encryption and then through ssh to the remote machine.

Correctness requires consideration of the particular services. Using filesystem snapshots, dump can now have a consistent view of the filesystem frozen at a point in time. FreeBSD supports snapshots natively in UFS, and Linux supports it universally using LVM. A mysql database can be correctly backed-up using mysqlhotcopy to properly duplicate the files that contain the database, properly locked and flushed to insure consistency. Subversion has svnadmin hotcopy that does the same for subversion.

While this should settle the matter for filesystems and subversion, it does seem possible that an improperly programmed database application might split a transaction, and the hotcopy might occur at the split.

To move a wordpress to a new server requires that three objects get moved:

1. The wordpress application;
2. The database of user content;
3. and the HTTP configuration.

On a fresh Red Hat derived Linux, the required yum installs are: mysql-server, mysql, httpd, php, php-mysql. WordPress is installed via tar, as a php application there is no build required. To move the wordpress installation tar this and untar it at the destination. Change owner and group to apache. If this is from a fresh install of wordpress, first untar the distribution then overlay wp-config.php and the entire directory wp-content.

To move the database, use mysqlhotcopy to make a copy of the files in, say, /var/lib/mysql/_database_name_ into a suitable location. say /opt/backup/mysql/_database_name_.

bash> mysqlhotcopy -u root -p PASS --allowold wildpages /opt/backup/mysql

Note that you probably want to delete all unapproved comments (spam) before doing the backup, as they can total the largest amount of data in your database. This can be done by mysql as:

mysql> DELETE FROM wp_4_comments WHERE comment_approved = '0';

The cloned directory can be tar’ed and moved, careful to stop the mysql server during the untar. Finally the new owner has to be introduced to the mysql system by:

mysql> GRANT ALL PRIVILEGES ON _database_name_s.* to "_database_name_"@"localhost" \
identified by "mypassword";
mysql> flush privileges;


Modify the apache config, copying in the old config.

Bragg is now up and running, thanks to Irina, Bragg is a Dell R510 running a single Intel E5620 2.4 Ghz, 24G 1333MHz dual ranked RDIMM’s; a PERC H700 Raid, and 600 GB/2 TB mirrored SAS.

It will be taking on the responsibilities of Davis.

We have moved to CentOS, because UM is not longer purchasing a site license with Red Hat, and Fedora, Red Hat’s free release, rev’s very quickly. That keeps us too busy chasing rev’s.

Welcome our newest server, hill.physics.miami.edu (CNAME hill.cs.miami.edu). The R510 Dell is located in the physics department server room, and runs Ubuntu. It’s purpose is to hold backups of other cs machines, offsite in case of a room-wide emergency. Running Ubuntu 10.04.4 LTS we are good to go until April 2015. (We missed 12.04 LTS by a day! Else we wouldn’t need a major upgrade until April 2017).

P.S. Mysqld is crashing on blog.cs.miami.edu on the cloud. Looks like out of memory. Perhaps a micro edition just isn’t enough.

In preparation to update meade, the services svn.cs.miami.edu, blog.cs.miami.edu, and aigames.cs.miami.edu have been moved to instances on AWS. Only web.cs.miami.edu remains on meade. web.cs.miami.edu/aigames will have a permanent redirect to aigames.cs.miami.edu.

www.cs.miami.edu/~[username] is now supplemented with www.cs.miami.edu/home/[username].

This change allows [username]‘s homepages to be addressed by both style URL’s.

Your account was created with a symbolic self-link “public_html->.” in you public_html directory. This self-link means that the new URL scheme will work along side the old URL scheme without any change to your homepages.

If one or the other URL is not working, it is easy enough to fix.

WordPress for the department is moving to a new computer. Using the new “Network Admin” possibilities of WordPress 3.0. It is a big improvement.

Some tricks for wordpress users:

To move a site, it helps to change the url’s in the database:

mysql> update wp_options set option_value='http://jackson.cs.miami.edu/burt' where option_name='siteurl';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> update wp_options set option_value='http://jackson.cs.miami.edu/burt' where option_name='home';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0


If you don’t do this, you get some pages to work, but then it will jump to the URL as described by these values. This worked pretty good on the old WordPress, and might work on WordPress 3.0 without Network Admin enabled. I couldn’t migrate the URL of a 3.0 with Network Admin and ended up dropping the entire database and starting again.

In general, it is hard to change the URL of a wordpress site. When migrating a site there just has to be downtime – export the data and shut down the old site; fix the DNS and install at the new machine on the desired URL.

To set the password, find a working user_pass from another blog, with known password:

mysql> update wp_users set user_pass='$P$BV3q/rYU98poi/Zv/ARuStuPi.Wvad.' where user_login='admin';
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0


The subversion server has been moved to a new machine. The CNAME svn.cs.miami.edu will lead you to it. It’s actual name is meade-vma.

Changed is the network service style. Previously the repositories were accessed using webDAV and Apache, and the repository URL used http:// as the prefix.

Now svnserve is being used, and the URL should be svn://svn.cs.miami.edu/[path-name].

Route 53 went live as of June 26. There are now two infrastructures for the department’s DNS servers for forward resolution (that is, from name to IP address). We maintain the classic BIND named’s, housed in the department with on-campus secondaries to cover short term outage and maintenance; and a parallel cloud DNS service that can withstand wide spread catastrophe.

We are testing using Route53, a cloud-provisioned DNS service from Amazon, for a secondary DNS system.