Maintenance

To create a visualization with gource (on Linux), first install gource (it's in the Ubuntu repo), then:

cd [the SVN directory you want to work on]

svn log -r 11019:11452 --xml --verbose --quiet > svnlog.xml
[Choose the revision numbers you want.]

gource -1280x720 -o - svnlog.xml | ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset ultrafast -crf 1 -threads 0 -bf 0 video.mp4

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 ============================================
SKIPNTSECURITYCRC YES
SKIPNTPERMISSIONS YES
ERRORLOGNAME "C:\Documents and Settings\All Users\Documents\tsmerror.log"
EXCLUDE "*:\...\*"
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.

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.

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.

We've been having spontaneous reboots on several machines in the last two months or so.
We've had an electrician double-check the power we're getting and all is well.
Looking in to potential computer-based issues I discover that many people experience this kind of thing with SSDs on Sabayon, Debian, Ubuntu, CentOS, and likely other distros. There do not seem to be any real solutions, but suggestions include the usual:
1) Get the latest firmware for the drive. Right now we have at least 2 different model of SSD in our machines (haven't checked Martin's yet): OCZ Vertex (96GB running f/w v1.6) and Vertex2 (115GB running f/w v1.29 or 1.33). Firmware and general info on OCZ drives can be found here. Firmware is here
2) Adjust fstab and /etc/rc.local like this

I'll come back to this next week.

<egg_on_face>
Figured it out. The problem was I stupidly changed the security update config to reboot after a security update gets done. It explains everything. The file has been edited, the package updated. Now I wait with my fingers crossed...
</egg_on_face>

Some notes on how to configure Gnome 3, in preparation for trying to roll it out to the lab machines:

• Install gnome-tweak-tool.
• Get buttons on window title bars: gnome-tweak-tool / Shell / Arrangement of buttons in the title bar / All.
• My installed extensions:

  advanced-settings-in-usermenu@nuware.ru              places-menu@gnome-shell-extensions.gcampax.github.com
  apps-menu@gnome-shell-extensions.gcampax.github.com  RecentItems@bananenfisch.net
  force-quit@xtranophilist                             Shut_Down_Menu@rmy.pobox.com
  nohotcorner@azuri.free.fr                            panel-docklet@quina.at
  workspace-indicator@gnome-shell-extensions.gcampax.github.com
  

  These are in ~.local/share/gnome-shell/extensions.
• Settings also seem to be stored in ~/.gconf.
• Showing date on Gnome 3 panel:

  gsettings set org.gnome.shell.clock show-date true

Having built the Macs from a 32bit image I find that they are running in 32 bit mode. No surprise, but it *is* reversible. Run this in the terminal sudo nvram boot-args="arch=x86_64" and reboot. The machine should run in 64 bit mode from now on.

Just blogging something I keep having to look up. This is how to switch your SVN repo from the old tapor URL to hcmc:

svn switch --relocate https://revision.tapor.uvic.ca/svn/[reponame] https://revision.hcmc.uvic.ca/svn/[reponame]