Maintenance

After an update to DSM 4.2 rutabaga no longer allowed rsync backups, failing with:

sh: rsync: not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: remote command not found (code 127) at io.c(605) [Receiver=3.0.9]

After much wailing and gnashing of teeth we discovered that non-interactive users do not have /usr/syno/bin in their path (it *is* in their path if they shell in to the NAS, so they can run rsync *from* the NAS when shell'd in).

So, that's an easy fix, says us: add a symlink to /usr/syno/bin/rsync in a logical spot that *is* in a non-interactive path, like /usr/bin.

Problem: admin user cannot su root (error message = su: must be suid to work properly), so cannot create symlink.

Answer: TURN ON TELNET AND LOG IN AS ROOT USING THE WORST POSSIBLE METHOD!!! Then, you make the symlink and turn off telnet - quick!

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.

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.

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>