Got the colonist machine sorted out, at least to the point that they have the most recent data on the VM and have a backup scheme working. That is, this appears to work.
Next step is to make sure that the backup is working, how long it takes, and whether the backup is like rsync or not.
The Colonist crew needed a reliable backup.
I've got TSM installed in their VM and configured to only back up their stuff.
For future reference
1) The opt file that you get from the helpdesk is intended to provide complete backup for an entire machine. We only wanted to back up a single user's directory. I edited the opt file to accommodate this requirement.
2) If TSM is installed by an admin, but the backup application is going to be run by a non-admin, the app will complain that the non-admin user cannot write to the error log, and the app won't run unless the error log is writeable. So, move the error log.
3) Some files cannot be backed up while the user is logged in. Fortunately we don't care about backing up such things as NTUSER and so forth. Remove them.
Note: includes and excludes can be managed in the preferences editor in TSM. You can also edit the dsm.opt file directly (it's in the 'baclient' folder of TSM's install directory.
I removed all of the end user settings provided by the helpdesk's file and replaced it with this:
* ==== END USER SETTINGS ============================================
ERRORLOGNAME "C:\Documents and Settings\All Users\Documents\tsmerror.log"
INCLUDE "C:\Documents and Settings\WorkerBee\...\*"
Exclude "C:\Documents and Settings\WorkerBee\NTUSER.DAT"
Exclude "C:\Documents and Settings\WorkerBee\NTUSER.DAT.LOG"
Exclude.Dir "C:\Documents and Settings\WorkerBee\Local Settings\Application Data\Microsoft"
The edits should be self-explanatory.
Putting this on the blog because I keep forgetting it:
Type Control+Shift+U, then release and type the hex of the character, then return.
When I launched a browser (Firefox, Safari) I was immediately presented with the YubiKey authentication panel. I wanted instead to manually launch the login and authentication process.
To prevent that automatic login (i.e. to manually choose to login to lastpass and then provide authentication):
LastPass_Icon/Preferences/Advanced/Open Login Dialog When Start Browser = unchecked
LastPass_Icon/Preferences/Account Settings/YubiKeys/Permit Offline Access = disallow
The default setting for the first is checked and for the second is allow. The first item launches the login dialog, the second allows lastpass to grab the master password from the local cache, and opens the Yubikey dialog. My first attempt was to set the first item to unchecked and leave the second at allow, but that had no apparent effect. Took a couple of emails with their tech support to figure it out.
UPDATE: When I restart the computer and browser launches, I still get the Yubikey authentication box. Firefox and Safari are obviously getting my lastpass master password from somewhere, but the remember password settings in the browsers are disabled and I can't find anything in the OSX keychain, so I'm at a loss.
As Martin notes, we met with RE about the near future of several servers.
a) The new machine, aka Peach, will replace Pear and Grape as soon as it's configured. RE is setting it up with a single Tomcat install, but we're going to try running multiple instances of it instead of having an installed codebase for each instance like we've had in the past. Once we're ready to test it, we'll get Grape's webapps and Pear's webapps on to it and test it for a week or so. When we're happy that things are working we'll bring down Grape and Pear.
b) when Grape comes down, it will be rebuilt as an additional node in our webcluster - this should happen by Christmas.
c) when Pear comes down it will become a BCP (bulk-copy) machine for Peach and Mango (the DB server), providing us with a rapid-recovery scheme. This build should be done by the end of February.
d) Once the CFI machine is purchased it will be replacing arugula as the NFS/disk box, and arugula will be added to the cluster. Timeline ASAP.
e) Lettuce will wait until we have a chance to put time in to the MoEML map refresh. We expect to begin in the new year. When Lettuce is no longer required for MoEML we'll add it to the cluster.
f) RE will look in to Cress and let us know what he thinks we should do with it.
Got a call from sysadmin this morning about the ise machine filling its fs with ehcache.data. It has been addressed in cocoon.xconf (see here) but we aren't sure how long it's been since last dealing with the problem.
So, sysadmin has noted it in the machine's config log(?) and I'm noting it here that tomcat was restarted this morning in order to remove the ehcache.data file, which had filled the filesysytem (the file was about 4GB).
GN will blog the outcomes. Posting time.
A change in the user agent string for Firefox 17 has triggered an error message in HotPot and Quandary exercises. An update to the applications will be required, which we'll do at home, but in the meantime all the existing exercises we provide to departments needed to be updated, including Greek, Latin, Spanish, XSLT (DHSI), Hulquminum and Arabic. Those have all now been updated.
This is basically what I did:
([\t ]*alert\('Your browser may not be able to handle this page.'\);) //$1
rsync --verbose --progress --stats --recursive --include '*/' --include '*.htm' --exclude '*' arabic/ email@example.com:/u/lancenrd/www/arabic/
I'm setting up a TSM node for the Colonist project and am working on getting it running under an XP virtual machine.
The node is set up, with Martin and Stewart as co-admins.
The software is installed, but I can't get it to send any data to backup.uvic.ca for some reason.
Forgot to post this when it happened, but beet's SSD died last week, and I have been unable to recover any data. Unfortunately, there was some data loss for one project. Not unrecoverable, but an annoyance nonetheless.
While waiting for a replacement drive I put a old-school drive in beet and got it up and running. The replacement SSD has arrived and I'm now waiting for an opportunity to put the new drive in to beet.
This blog is the location for all work involving software and hardware maintenance, updates, installs, etc., both routine and urgent, in the server room, the labs and the R&D rooms.
|<< <||> >>|