XMarks replacement

Sad news: XMarks is shutting down soon, which is a spew, since I found it really handy to sync my bookmarks across several computers and my iPhone.

Fortunately, Firefox Sync will sync my bookmarks (and history) across several computers all using Firefox. And the neato Firefox Home will enable me to access the bookmarks on my iPhone. So I'm happy-ish again.

Still a pity that XMarks is going away, though.

Set DRAC network config remotely

So I had a DRAC at a remote site that refused to play nicey-nice - I was pretty sure the default gateway was set wrong so it was unable to get out to anything beyond its LAN. I was able to SSH to a Unix host on the same network, and from there I could ssh to the DRAC in question, and do the following magical incantation:


racadm setniccfg -s 192.168.0.120 255.255.255.0 192.168.0.3


Those three sets of numbers are IP address, netmask and default gateway - setting the last one correctly... wait 10 seconds or so, and hey presto, DRAC plays nicey-nice with the network again.

A neat trick for when you can't get to the web UI.

Getting the track listing for a K3B project

This was harder than I expected. However...

Get your .k3b file, which is really a zip file:

$ unzip -l can-u-pick-em.k3b
Archive: can-u-pick-em.k3b
Length Date Time Name
--------- ---------- ----- ----
17 2106-02-07 17:28 mimetype
10623 2106-02-07 17:28 maindata.xml
--------- -------
10640 2 files

and extract the only useful part:

unzip -p can-u-pick-em.k3b maindata.xml > tmp.xml

That's an XML file that contains the project data. Then we feed it through an XSLT processor, using this stylesheet:


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml">

<xsl:output method="text" encoding="UTF-8"/>

<xsl:template match="/k3b_audio_project">
<xsl:apply-templates select="contents">
</xsl:apply-templates>
</xsl:template>


<xsl:template match="contents">
<xsl:apply-templates select="track">
</xsl:apply-templates>
</xsl:template>

<xsl:template match="track">
<xsl:value-of select="cd-text/artist"/>
<xsl:text> - </xsl:text>
<xsl:value-of select="cd-text/title"/>
<xsl:text>
</xsl:text>
</xsl:template>

</xsl:stylesheet>


like this:

$ xsltproc stylesheet.xslt tmp.xml
Eleni Mandell - Pauline
Neko Case - Star Witness

etc

EDIT!
Another option which I tried initially was using dcop to interrogate K3B while it has the project open - there are tons of suggestions out there to do this, but I could never get it to work. It turns out that dcop doesn't work in KDE4, and has been replaced with DBUS. Ah, so here's some examples using DBUS to talk to amarok - so maybe this will work... though this suggests otherwise


WSUS, GPO and OU, oh my

I've been wrestling with WSUS - for testing, I only want to apply auto updates to a couple of test victims... err, I mean systems. So I thought I'd create an OU for WSUS, and a sub-OU called test, then create in that a security group, add a couple of test computers to that group. Then apply a GPO to the test OU and hey presto, it would all work. Not so! But along the way I discovered some handy tools to find out why not:

gpupdate /force - force the group policy to update from the DC right now
gpresult - show the set of policies that apply to this computer (and user)

I finally ended up moving the computer's account to a new OU (where the GPO is applied) and it all came good. Annoying, but do-able. Now, to get it detected by the WSUS server:

wuauclt.exe wuauclt /ResetAuthorization /DetectNow - forces the Windows Update agent to trot off to the update server right away. Of course, it doesn't then show up until you manually refresh the view on the WSUS admin console - took me a while to realise that.

Upgrading KnowledgeTree - just kill me now

I hope the title doesn't give it away too much, but I'm not having the greatest of luck with upgrading our KnowledgeTree 3.5.2b (to evade this bug).

Even when I took the drastic step of reading the documentation, I haven't had much luck.

To get a 3.5.2b test server up and running, I did the following:

1. Set up a VM and install Ubuntu server 8.04 on it
2. download ktdms-oss-3.5.2b-linux-installer.bin from here and install it
3. run ktree and make sure I can log in as default admin/admin
   
4. stop ktree, and untar our existing backup over it (contain s a DB backup, documents, config.ini and plugins
5. start just mysql (dmsctl.sh start mysql)
6. cd /opt/ktdms/mysql/bin
7. ./mysqladmin --socket=../tmp/mysql.sock -udmsadmin -p drop dms
8. ./mysqladmin --socket=../tmp/mysql.sock -u dmsadmin -p create dms
9. ./mysql -u dmsadmin -p dms < ../backup/backup.mysqldump
10. chown nobody:root /opt/ktdms/Documents/
11. /opt/ktdms/dmsctl.sh restart

So far, so good! I test and I can login using my LDAP credentials. Documents are there, I can get to the admin pages, it all looks okay.

Now, to upgrade to 3.5.3:

1. Run ./ktdms-oss-3.5.3-linux-upgrade-installer.bin
2. Once that's complete, browse to http://server-name/setup/upgrade.php - this wants us to log in as an administrative user before it will complete the DB upgrade - which makes sense... BUT none of the admin logins work. Every single one gets the "Could not authenticate administrative user" error message. LDAP user accounts, builtin admin account.. even when I did an echo -n 'password' | md5sum and poked that into the DB manually - nada! Soooo.....
3. Edit /opt/ktdms/knowledgeTree/setup/upgrade.php and comment out lines 298 - 303:

if (!$authenticated)
{
session_unset();
loginFailed(_kt('Could not authenticate administrative user'));
return;
}

And hey presto, I can upgrade it! Then after the DB upgrade has finished, it goes to re-scan our plugins, POW! The wheels fall off once again:

Fatal error: Class 'KTFolderAction' not found in /opt/ktdms/knowledgeTree/plugins/WemagTreeBrowsePlugin/WemagTreeBrowsePlugin.php on line 34

Well colour me impressed. OK then...
rm -rf /opt/ktdms/knowledgeTree/plugins/WemagTreeBrowsePlugin/

And... now...

Fatal error: Call to undefined method PEAR_Error::getAuthenticator() in /opt/ktdms/knowledgeTree/lib/authentication/authenticationutil.inc.php on line 67

Arg. OK, maybe a restart:

/opt/ktdms/dmsctl.sh restart

Nope, after doing the setup/upgrade.php again, it started complaining about another Wemag plugin, so...

rm -rf /opt/ktdms/knowledgeTree/plugins/WemagSidebarManagement/

Do the dance again... and this time I can get to the login screen. The documents are there, so that's nice. Of course, the Wemag tree browse plugin is gone, which is okay, since I had to remove it.

But before we get too excited, when I log on as me, I initially get my usual "Philip Yarra" account... but once I try to manage anything I get the built-in Administrator account... and when I go to "DMS Administration" get I get "Permission denied" and "If you feel that this is incorrect, please report both the action and your username to a system administrator". I do feel that this is incorrect - hell yes, I'll call the sysadmin and... oh yeah, I am the System Administrator.

If I log in as the built in admin account, same deal - cannot administer ktree.

Overall, I'd call this a failure of an upgrade.

Solaris mounting Linux NFS shares: nfs mount: mount: /mount_point: Not owner

In a supreme example of why programmers can sometimes write error messages that make prefect sense to them, but are absolute gibberish to everyone else, and don't really help isolate the problem, I present today's bafflement:


bash-3.00# mount -F nfs 192.168.2.248:/c/prc /Backup_PRC/
nfs mount: mount: /Backup_PRC: Not owner
bash-3.00# ls -ld /Backup_PRC/
drwxr-xr-x 2 root root 512 Aug 3 10:10 /Backup_PRC/


Well, yes, I am the owner, thanks for asking. The real cause? Solaris 10 NFS defaults to using NFSv4, and Linux doesn't support it properly (or so the story goes). The solution is real simple: use NFSv3:


bash-3.00# mount -F nfs -o vers=3 192.168.2.248:/c/prc /Backup_PRC/
bash-3.00# mount | grep Back
/Backup_PRC on 192.168.2.248:/c/prc remote/read/write/setuid/devices/vers=3/soft/bg/xattr/dev=4a80006 on Tue Aug 3 10:14:35 2010


Determining citrix client versions

So we need to know what Citrix client versions are connecting to our apps. Turns out to be quite do-able:

In Citrix Access Management Console, I select the "Servers" node in our farm, and change the view to "Users". Then select "Choose Columns" and select to display "Client Build Number" - here's one I prepared earlier:



You can them use this handy chart to determine which actual version (9, 10, whatever) these numbers represent. What could be simpler?