TortoiseSVN with kerberos authentication

I'm a big fan of TortoiseSVN (TSVN, short) on Windows. Working with multiple SVN servers and different authentication methods has its pitfalls, however.
I just found out how to make the current TSVN (1.7.11 as of this writing) work with Kerberos authentication on a Linux server that uses krb5 as I previously described here.

Introducing django and mysql

I wanted to do some rapid prototyping with web applications, and decided to give python and django a go. There are various tutorials out there, but none of them seem to focus on using existing database structures and views.

So this is primarily to document my own findings. If someone else finds it useful: be my guest. ;-)

Oracle OMS Agent migration

I've recently migrated a few Oracle databases to Enterprise Manager 12c. While this is worth a few posts on it's own, here's just a quick hint of how to update the IP/hostname of an agent after it's been registered at OEM.

First, verify that the agent is responding to requests, by navigating to the new IP/host with your browser:

https://my.new_server.lan:3872/emd/main/

Then log on to the OEM repository DB as sysman. The table MGMT_TARGETS holds all the juicy agent details. Just update the column EMD_URL with the new value, and everything is fine.
For instance

update mgmt_targets set emd_url=replace(emd_url,'my.server.lan','my.new_server.lan')  where target_name like '%my.server.lan%';

Verify your changes in the view MGMT$TARGET.
Finally the agent should be available in Setup - Agents at once. I then resync'd the agent from EMS, and secured the agent. All targets were up and running without issues then.

trac-0.12.3 and HTML notifications and commit_updater

As I've written before, trac-0.12.3 still doesn't HTML notifications. Maurice found out how to work around a limitation with the commit_updater plugin here.

XenServer and "The VDI is not available"

I've been happily running XenServer for a few years now. Last week I encountered a weird issue with seemingly corrupted VDIs, which turned out to be fine after a server reboot.
In the aftermath I had a corrupted storage repository, that manifested like this:

• Unable to scan the SR:

Error code: SR_BACKEND_FAILURE_46
Error parameters: , The VDI is not available [opterr=Error scanning VDI <uuid> ]

• Unable to copy VDIs from or to the SR
  This was nasty, because this meant it wasn't possible to backup virtual disks.

After reading comments on the XenServer forums for many hours I found a working solution. First of all check the file /var/log/SMlog on the pool master server and then trigger a rescan of the bad SR. In my case I had a VDI with an invalid footer.
The log looks like this:

***** VHD scan error: vhd=VHD-<uuid> scan-error=-22 error-message='invalid footer'
*** vhd-scan error: <uuid>
Raising exception [46, The VDI is not available [opterr=Error scanning VDI <uuid>]]

I verified this by running

/usr/sbin/vhd-util scan -f -m "VHD-*" -l VG_XenStorage-<storage-reporitory-uuid> -p

Which, amongst others, gave me this line:

vhd=VHD-<uuid> scan-error=-22 error-message='invalid footer'

 Now many people recommended running vdi-forget to get rid of this VDI. I tried that, but that didn't fix anything. Others recommended running vdi-destroy. After I ran vdi-forget I wasn't able to run vdi-destroy anymore. So I had to work it out using lvremove like this:

lvremove /dev/VG_XenStorage-<storage-repository-uuid>/VHD-<uuid>

This gave me a few warnings like "open failed: Read-only file system" but in the end it did the trick. I re-scanned the storage repository and it finally worked. A few orphaned VDIs showed up which I promptly removed. Subsequent rescans of my SR coalesced VDIs without problems.

I found these links to be helpful: CTX122001 and Thread: Issue with reclaiming disk space in xenserver 6.0.

For the record, I'm running XenServer 5.6 SP2.