Maintenance

Following a procedure I'd already tested on my home computer, I upgraded VirtualBox like this:

• Checked that the existing version and the target version were both available in the Synaptic Package Manager.
• Shut down all VMs, took snapshots, and backed them up. This includes backing up the contents of ~/.VirtualBox, which is on the root drive (while the VMs are on the second drive).
• Using Synaptic, removed the old version, and then installed the new version.
• Started VBox and tested the VMs.

We have long struggled with the issue of how to provide easy access to data on the TAPoR servers for students and researchers working on projects. The ideal, especially for XML markup projects, is to have a TAPoR share mounted as a network drive; this enables oXygen to provide an easy project editing interface through "Link to external folders", and files can be opened and saved transparently on the server in this way. On Linux this is (naturally) easy. This is what I have learned from trying to do this for CC on her Mac and Windows laptops over the last two days:

• In our labs, we use taporshare.tapor.uvic.ca, which provides an SMB connection. However, this is problematic for laptops and remote locations, because SMB is insecure, and it's also blocked by default on the UVicDefault wireless network.
• Macs do not support SFTP connections out of the box.
• Oxygen promises to support opening and saving of files over SFTP, but it seems to work only for one file at a time, which makes validation difficult, and it's difficult to set it up so you can browse the folder tree on the server. After a restart, oXygen also seemed to lose the logon credentials and be unable to ask for them again, causing "Auth fail" errors. Hopeless.
• MacFuse and MacFusion (search the web) worked well for me on Snow Leopard from home, connecting to Lettuce, but were hopeless on Leopard; we had endless authentication issues, and were unable to save files to the server.
• On Windows, you can use Dokan SSHFS (search the web) to mount a share (e.g. Lettuce, or nfs.tapor.uvic.ca) over SSH. This works OK, except that the GID setting is not respected when creating new files; they end up as user:user instead of user:project. Still, it's better than nothing.
• On the Mac, the only solution we could find was to use Transmit, which costs money, but which will allow you to open a remote files over an SFTP connection. The only issue here was the problem with validation; the relative link to the schema did not work, of course, because the file was opened in oXygen from a temp folder. We were able to work around it by placing copies of schemas in the temp folder, in the right relationship (fortuitously) to the place where Transmit stashes its temporary files when you open a file from the server.

All in all, very unsatisfactory. This precludes people working remotely on our project data unless they're relatively sophisticated and can use something like subversion, can be relied upon to use a client such as WinSCP or Cyberduck correctly, or are using Linux.

There are a couple of CANJAS lectures scheduled while I'm gone, and Dr. Iles will be handling the hardware. He asked me to write up a brief outline of what to do:

Placement.
In the boardroom, the optimal location is at the window end of the room; the curtains are not sufficient to stop glare on the screen.
I generally need to get in to the room a bit ahead of schedule to move the table and chairs around to fit the VC equipment in to the space.

Network.
The boardroom is already sorted out, network wise, and should just work. That said, the network port is at the opposite end of the room from the best location for the VC equipment. There is a long network cable for this (the end of which is sticking out of a blue-grommeted hole in the bottom left side of the cart). I run it under the tables to keep it out of the way.
*** Networking note: If another node is dialing (cascade call from UofA or similar) in you'll need to know your IP address beforehand and give it to the dialer. If you dial out (make your own call to another node) your IP doesn't matter.

Audio.
in the boardroom, you should be able to get away with a single microphone, but if you have a full house you might want to use two. I run the cable (sticking out of the same hole as the network cable) down the middle of the table (on the floor, running it up to the mic's location). Remember that the mic displays a green light when broadcasting and a red one when turned off. They can be manually turned on and off with the switch on each mic, or through the remote mute function.
*** Audio note: the mic cables plug in to the mic only one way. It's a bit like an S-Video cable in that it requires a delicate touch to attach. Take a close look at the cable end and the mic before trying to connect them.

Video.
The VC equipment is plugged in to the S-Video plug on the TV (which displays as "AV1" on the TV screen). Use the "Source" button on the TV remote to adjust the input.

The bigger VC box (on the right) has a power (toggle) switch that should already be on. When you plug in the cart and turn on the power on the VC remote (silver one) the camera should turn around a bit and settle in a forward position (away from the TV). If the TV is on the right input you should see a view of the room on the TV screen.

If the blue Sony IPELA screen is displaying on the TV, you'll notice in the lower middle section of the screen some info about the network connection. It should display an IP address here - if it doesn't, you don't have a connection. Fix this first!

To dial in to a node, use the IPELA remote and choose "Phone Book" in the top right of the main screen. When you click it, you get a new screen with about 6 big, cryptically titled, icons (Sony, Clare@UofA etc.). Look at the bottom left of the screen and you'll see the IP address that will get dialed if you choose one of the icons. (***Remember, if UofA is going to do a cascade call (dials you) you need to know your IP address and make sure the outside caller knows what it is.)

If you need a separate monitor for a Powerpoint presentation, you need to make sure that it's working ahead of time. I normally dial up UofA and ask to do a test to make sure everything is functional.
To connect things, put the small LCD monitor where you want it and connect the VGA extension cable to the one already on the monitor. The extension cable is already attached to the SONY box; you'll find the cable inside the cart.

My RC will start timing out next week, so I'm building a new VM for Win7/64, to do testing and QT builds on. Quicker and easier than any Windows installer from the past.

Took Greg's new build of XEP and integrated it into the ACH project, as ported to the new Cocoon/eXist build by MJ. It works as expected. This is what I had to do:

• Take the XEP configuration data, which includes the docs, examples, fonts, hyphenation data, images, lib and crucially the xep.xml file which configures usage of fonts etc., and put that in the [cocoon]/resources directory. Much of this (docs, examples, etc.) could be discarded, but it's not a bad thing to have the docs and examples available for anyone who needs to maintain the project in the future.
• Put the three XEP jars that form the Cocoon connector into [cocoon]/WEB-INF/lib (xep.jar, XEPSerializer.jar, and xt.jar).
• Added the serializer data to the sitemap:

  <map:serializer mime-type="application/pdf" name="fo2pdf"
            src="com.renderx.xepx.cocoon.Serializer">
            <parameter name="com.renderx.xep.CONFIG" type="string" value="/home/mholmes/apps/apache-tomcat-6.0.20/webapps/ach/resources/xep/xep.xml"
            />
  
            </map:serializer>
             <map:serializer mime-type="application/postscript" name="fo2ps"
             src="com.renderx.xepx.cocoon.Serializer">
             <parameter name="com.renderx.xep.CONFIG" type="string" value="/home/mholmes/apps/apache-tomcat-6.0.20/webapps/ach/resources/xep/xep.xml"
             />
             </map:serializer>  
  

  This obviously uses full paths on the local drive, which would need to be updated when moving the project; I'm now going to see if I can figure out how to make these paths relative, using Cocoon protocols.

Update: no way to avoid literal paths

It seems that there is no way to get around the requirement for literal paths in the sitemap. In view of that, I've relocated the xep folder so that it's a child of /site/. This reduces the changes we need to make to the root Cocoon to a minimum; now all that needs to happen is that the jars get dropped into the WEB-INF/lib directory. That's perhaps the best we can do for the moment. Eventually we hope to move to FOP, which is intelligent enough to read its configuration from a relative path.

ETCL user had a problem connecting through a physical port (which appears as "Down" in the nets web admin tool). Submitted Homer for it.

I installed Karmic on my iMac with relatively few problems, but audio was a bit of a hassle.
Turns out, I needed to edit the /etc/modprobe.d/alsa-base.conf file to include the following line:
options snd-hda-intel model=mbp3

I originally tried to add the option model=mbp3 to the existing options line, but it didn't take. When I added another options line with the model, it worked. (note: mbp3 means MacBookPro version 3)

Other choices that I tried were model=imac24 and model=auto. They didn't work, but I didn't try to add them on their own line.

Another option that I came across was 3stack-6ch, which apparently gives superior audio. No idea if it works.

I also have two mice: one Kensington Expert Mouse and one Apple Mighty Mouse. I want the Expert Mouse to be my main mouse. It must also be left-handed. After lots of searching I found that I should be able to create an FDI file that sorts it all out, but I swear it doesn't work. Here's what *did* work:

running "xinput list --short" got this back:
"Virtual core pointer" id=0 [XPointer]
"Virtual core keyboard" id=1 [XKeyboard]
"Kensington Kensington Expert Mouse" id=2 [XExtensionPointer]
"Built-in iSight" id=3 [XExtensionKeyboard]
"Microsoft Natural® Ergonomic Keyboard 4000" id=4 [XExtensionKeyboard]
"Sleep Button" id=5 [XExtensionKeyboard]
"Power Button" id=6 [XExtensionKeyboard]
"Video Bus" id=7 [XExtensionKeyboard]
"Microsoft Natural® Ergonomic Keyboard 4000" id=8 [XExtensionKeyboard]
"Power Button" id=9 [XExtensionKeyboard]
"Macintosh mouse button emulation" id=10 [XExtensionPointer]
"Mitsumi Electric Apple Optical USB Mouse" id=11 [XExtensionPointer]

I then ran this:
xinput set-button-map "Kensington Kensington Expert Mouse" 3 2 1 5 4 6 7 8
which *only* adjusts the buttons on the Expert Mouse, leaving the Apple Mouse alone.
Broken down, the 3 2 1 part swaps buttons 3 and 1 (bottom-left and bottom-right), while the 5 4 business reverses the scroll movement. I left the 6 7 8 bit alone, but as far as I can tell, there is no button that identifies itself as 6 or 7. Button 2 is the (physical)top-left button, and Button 8 is the (physical)top-right button. The current functionality of button 2 is to operate as the middle-click, which is fine with me.

Once happy with the arrangement I went to "Preferences->Startup Applications and added the xinput set-button-map bit (above) as a command (name it what you like) to run on Gnome startup. I'm not sure if this behaviour is available at the GDM...

NOTE: the string identifying my Expert Mouse contains 6 spaces, but this textarea doesn't want to display it.

Set up Griffin Powermate:
1) sudo aptitude install gizmod

2) Create input group and set up udev rule

sudo groupadd -f input
sudo gpasswd -a <username> input
sudo gedit /etc/udev/rules.d/99-input.rules
paste:
KERNEL=="event*", NAME="input/%k", MODE="660", GROUP="input"
KERNEL=="js*", NAME="input/%k", MODE="664", GROUP="input"

3)Autostart Gizomd for session

sudo gedit /etc/xdg/autostart/gizmo.desktop

paste:
[Desktop Entry]
Encoding=UTF-8
Name=Gizmo Daemon
Comment=Input mapping daemon
Icon=keyboard
Exec=gizmod
Terminal=false
Type=Application
Categories=
OnlyShowIn=GNOME;XFCE;

4)restart machine

Got the final XSLT issue that we know about cleared up, and tested the site. Everything seems to be good, although we can't yet test the PDF generation. Greg and I looked at the previous XEP setup and he downloaded the latest update to our licensed XEP; it now has a servlet component, which we may be able to call, or we may go with the same system we're currently using. Either way, I should be able to test the functionality locally over the next few days, while we wait for the new server to be deployed. I don't really want to try to deploy the ACH into apache-dev on Lettuce right now, because it's already pushed a bit hard by memory limitations, so we'll probably deploy it directly to the new server.