Maintenance

This morning we got nets to set up B047 on the switch. Some time after that 3 machines lost the ability to get a DHCP address - I have no idea if there is a causal relationship between these things.

After much mucking about, it *looks* like it might have been a communication problem between the DHCP server and the machines.
Even forcibly releasing the DHCP lease didn't make any difference.

In the end, I booted the machine with a LiveCD and fiddled with enabling/disabling the network (in the network manger). I got a proper IP and rebooted in the installed OS. That seemed to break it out of the loop.

A bit perplexing and aggravating because I don't actually know what the problem was...

All current Tomcat-based projects have now been moved to Peach, with the help of RE, who has re-pointed all the relevant domains. The IALLTJournal project has been retired, since it's no longer in use, as has the old version of Francotoile, which was built on eXist 1.4. This was a fairly slow and careful migration over a couple of days, and we expect no problems, but Pear will continue to run for a little while just in case.

Tomcat has now been configured so that a slash not followed by a filename is handled by the webapp, not trapped as an error by Tomcat itself. I've also uploaded and tested the new Moses app on Peach, confirming that while the eXist dashboard and eXide fail under Tomcat 6, they work under Tomcat 7.

After a system update, rsync stopped working over ssh on Rutabaga. We eventually discovered that users rsyncing over ssh require the ssh service to be turned on (Control panel/Terminal/SSH service). This was apparently not necessary in previous builds, or perhaps it was turned off by the update for some reason.

teijenkins found itself unable to complete an update because it was out of disk space. This was initially surprising, but I discovered that it was actually the small boot partition that was out of space, because of the accumulation of old kernels. This command:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

cribbed from this page cleaned out the old kernels and solved the problem.

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:

• Search and replace with regex on the dir trees in Oxygen:

  ([\t ]*alert\('Your browser may not be able to handle this page.'\);)
  //$1
  

• rsync of the HTML files to the site -- e.g.:

  rsync --verbose --progress --stats --recursive --include '*/' --include '*.htm' --exclude '*' arabic/ lancenrd@unix.uvic.ca:/u/lancenrd/www/arabic/
  

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>

GN and I repurposed Plum to replace the temporarily-suspended teijenkins machine, while licensing issues with VMWare are sorted out. This functioned as a fresh test of the Jenkins build script, which went great with two little hiccups (TEI packages have changed, and zip is no longer installed on Ubuntu Server by default). Those changes have been added to the build script in SVN. The new machine is running (but very slow to build, due to its Arm processor).

This is my documentation of recent changes to the way the TEI Jenkins Continuous Integration Server VMs are configured.

The new VM whose machine name is teijenkins1204 is now running Jenkins on port 8080, and also Apache proxying Jenkins on port 80. JA (sysadmin) has pointed the DNS entry for teijenkins.hcmc.uvic.ca at this machine, so the Jenkins instance is accessible on port 80 and 8080 there. The dual access allows for normal access to Jenkins on port 80 (convenient), but also for a situation in which we might want to put up a temporary warning page on port 80 while solving a problem with Jenkins accessed through 8080, then restore the proxy setup. I followed these instructions to set up proxying.

That machine is also running denyhosts.

The old machine hostname has been changed to teijenkinsdev, and JA has pointed teijenkinsdev.hcmc.uvic.ca at it. The Jenkins service has been disabled on this machine using sysv-rc-conf. When I ran that tool, it showed X characters for the jenkins service on run levels 2, 3, 4 and 5. I removed all of them; to re-enable the service, run it again and replace them. In the meantime, you can run Jenkins manually using sudo /etc/init.d/jenkins start. The plan is to reprovision that machine with more RAM and disk space, and then build it up with Ubuntu 12.10 to test and tweak the build script; doing this for every Ubuntu release will make it less messy to migrate to the next LTS when it comes out.

Spent some time with GN trying to get builds working on Plum. We found a couple of bugs in the code, which were reported and fixed, and I also added some new false positives to the log-parse file. Now we're back to apparently-working builds (although with warnings) for three out of the four builds OK, and the last one in process. I need to start testing recent builds with MoEML next week if I have a chance. We've commented out the svn module because that was causing problems.