Maintenance

After numerous tries with various approaches, I finally managed to end up with a 40 Gig virtual machine to host Windows.
The procedure that worked for me was to
- clone the existing hard drive using the function in the GUI of Virtual Box (and not the command line). VB created a new folder and put the new virtual machine file into that folder.
- go into the command line and make the virtual file 40 gigs in size
sudo VBoxManage modifyhd newVirtualMachine.vdi --resize 40960
- start up virtual box
- select the new virtual machine
- click on settings, click on disk, right click, choose "Remove"
- still on settings, right
- in Windows, start Windows Computer Management
- go to Disk/Storage management
- right click on existing small partition, select "extend"
- click OK in dialog box

When I tried using the command line to clone the virtual drive, I got the file, but the GUI in Virtual Box didn't see it.
I tried a couple of other partition managers before stumbling on the Windows Computer Management and either I couldn't get them to install properly or I couldn't get them to extend the smaller partition to a bigger one.

The most helpful website I found was
http://tips.kaali.co.uk/2012/03/16/expand-or-increase-the-size-of-virtual-box-vdi-dis/ though I did not create the hard drive and then clone the existing drive to the new drive as that page says, rather I cloned the existing drive and then resized it to 40G.

Finally, when I started windows in the new virtual machine, I got a "this copy of windows may not be authentic" warning. I followed the link on the warning and that "authenticated" my copy.

Looking at the Jenkins interface this morning, I realized that I'd forgotten to give the anonymous user read access to jobs, so I've done that. I also tracked down the issue with the stylesheets to (I think) a permissions problem with the oXygen installation; it was installed via sudo, so all the files ended up owned by root, whereas the job is running under a different user. I've chowned everything to hcmc:hcmc, and we'll see if that solves it, but it might have to be chowned to whatever user Jenkins runs under. Running a stylesheet build now to see if it works.

EDIT: But it doesn't. The same error shows up even when java is world r-x. Posted on the oXygen forum for a possible solution, and also heard from SR that he remembers this but doesn't remember how he fixed it.

Update from Stewart 20120622: the dbadmin says that the originating request is supposed to go through helpdesk@uvic.ca, who forwards it on to dbadmin@uvic.ca.

• Your affiliation with UVic (Faculty/Staff, etc)
• Your department
• Which netlink Id is associated with this database
• The database name (must be of the form netlink_whatever)
• Whether or not you will be using drupal for this instance.

As per my correspondence with sysadmin@uvic.ca, all MySQL-related support requests/questions should be sent to dbadmin@uvic.ca rather than sysadmin@uvic.ca:

Hi Jamie,
The unix sysadmin no longer handles MySQL requests, these should be set
to dbadmin@uvic.ca, if you resend this email to that address it will
find it's way into the correct queue of our ticketing systems


Thanks
Hendrik

Not sure whether he actually means only MySQL, or whether PostgreSQL falls under this new support email as well.

Found some excellent Bash tutorials here:
http://wiki.bash-hackers.org/scripting/tutoriallist

The list points to two of the best - which I've found to be very good:
http://steve-parker.org/sh/first.shtml
http://mywiki.wooledge.org/BashGuide

I had to find a file that had changed recently in order to track down a configuration file location.
The code is straightforward, but impossible to remember.

Run this:

find . -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort | grep '2010-09-23 11:09'

and it will return something like this:
2010-09-23 11:09:24.6718347970 ./.cache/ubuntuone/log/syncdaemon.log
2010-09-23 11:09:43.0224589250 ./.cache/google-chrome/Media Cache/data_1

The Jar Bundler application includes an executable file JavaApplicationStub. The versions I have of Jar Bundler created a version of that file that either was PPC-only, or supposedly binary but defaulted to PPC. Problem is that in current release of Mac OS 10.6.2 the default is to disable "Rosetta" the code that allows ppc-apps to run on the intel chipset. User sees a "this application requires Rosetta to run, do you want me to enable Rosetta" message. I found a page on the web that explained how to replace the version of the JavaApplicationStub created by my version of Jar Bundler with another version of that file and it would default to the intel chipset and failing that use PPC. Tested it and it works. http://neosmart.net/blog/2009/make-old-java-applications-fully-snow-leopard-compatible/ Did most of this work out-of-office but posting here in case something similar comes up with university work.

When doing a dump in PHPMyAdmin, I've discovered that by clicking the "Use delayed inserts" checkbox in the Data fieldset you get an insert that starts like this: "INSERT DELAYED INTO `TABLENAME` ... " which seems to end the trouble I was having importing multi-MB dump-files.

Booting up this morning, Lab B 19 went into CheckDisk. It eventually completed the bootup successfully, but this may be a sign of a dying HD. Station 21 booted up at 800 x 600, and when I logged in to change it to 1024 x 768, it seemed to lose all communication with the monitor for a couple of minutes before coming back with a wobbly picture, then settling down. Watch this one in case the monitor is on the way out.

Had to help one of the ESL folks with video in Lab C, and discovered that the instructions on top of the VCR no longer match the setup. The system seems to have been set up so that the TV, VCR and speakers are hooked up together, with no feed to the teacher's console. This is fine -- in fact, it's nice and simple -- but the instructions assume the audio is going through the teacher station and the video will be shown on the projector. If we've given up on hosting video tape materials through the main system, we should remove those old instructions.

Lab B appears to be the same.

Every time I install VMWare (of any type - workstation, server, player) I need to edit some source code in order to get the network module functional. I've done it so often I figured I should document it.

1) Run the installer. It will try to build a network module (vmmon) and it will fail. The problem is that the Ubuntu kernels are a target that moves too fast for VMWare to keep on top of.
2) When it fails, head over to /usr/lib/vmware/modules/source/ (this path will be different if you are installing the server or player versions) and
3) Unpack the vmmon source code thusly: sudo tar xvf vmmon.tar
4) Go into the resulting vmmon-only/include directory and sudo gedit compat_kernel.h
5) Edit the compat_kernel.h file to include the text in bold (below).

/*
* compat_exit() provides an access to the exit() function. It must
* be named compat_exit(), as exit() (with different signature) is
* provided by x86-64, arm and other (but not by i386).
*/
#define __NR_compat_exit __NR_exit
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
static inline _syscall1(int, compat_exit, int, exit_code);
#endif

6) Just to be safe, go up the tree and backup the old vmmon.tar: sudo mv vmmon.tar vmmon.orig.tar
7) Repack the edited module: sudo tar cvf vmmon.tar vmmon-only
8) Run the config again: sudo vmware-config.pl

*** an effective alternative is the use the any-any patch from here: http://platan.vc.cvut.cz/ftp/pub/vmware/
Look for the file that starts with "vmware-any-any-update"