Alfresco Desktop Sync on Linux

First off a disclaimer: Not only is the Alfresco Desktop Sync a preview release at present, there isn’t an official Linux version available, so all this is very, very unsupported!!!

To get the Alfresco Desktop Sync working in Linux you basically need to get the java code extracted from one of the other clients and install the Linux version of jnotify-lib. That all sounds simple, and it isn’t as complex as you may expect.

First off the easiest way to get hold of the java code is to extract it from the Windows exe (I did take a look at the dmg, but had little success with the later versions of the Desktop Sync). You can download the Windows version of the file from here:

http://sourceforge.net/projects/alfrescodesktop/files/

Open the .exe file up in Archive Manager and drag the following files into a suitable directory (I created /scripts/alfrescosync/ for the purpose):

Desktop Sync.jar
Desktop Sync.vmoptions
OfflineLogo.png
OnlineLogo.png

The next job is to get the JNotify code for Linux. This can be downloaded from here:

http://sourceforge.net/projects/jnotify/files/

Extract the zip file into the same directory as the previous files, which should create a sub directory (in my case jnotify-lib-0.94). Now you are ready to run the .jar file with the appropriate parameters to tell it where JNotify is. I did this by creating a bash script called desktopsync:

#! /bin/bash
java -Djava.library.path=~/scripts/alfresco/jnotify-lib-0.94/64-bit\ Linux/ -jar Desktop\ Sync.jar

Remember to make it executable and you should now be able to run it with:

./desktopsync

On my Ubuntu 12.10 installation this created an icon on the panel and downloaded the files from my Alfresco installation (once configured of course).

desktopsync-panel

One thing to note is the URL, this should be along the lines of:

http://192.168.10.61:8080/alfresco/api

the /api at the end is the key, before that you just have the standard server URL, port and /alfresco

desktopsync-login
For reference I’ve worked with jnotify-lib-0.94.zip and DesktopSync_windows_0_9_6.exe.

A few things I’ve noted with this setup are:

  • On testing this I’ve found new files are successfully downloaded, although changes are not uploaded (I’m not sure if this is what the app is supposed to do or not, I haven’t explored further yet).
  • It also appears that, at least on my test system (a 64 bit install of Ubuntu 12.10) there is actually no need to install the JNotify library as this works out of the box). This means you can run the code with java -jar Desktop\ Sync.jar
  • I’ve noticed also that, if you set it to Auto login (you cannot set it to Run on computer start) it will always fail to connect first time and you have to do it manually.

desktopsync-settings

Finding VirtualBox IP addresses

I have been running some server instances in VirtualBox recently and as I move between networks it is a pain to have to log in and get the IP address from ipconfig before being able to access the test web sites I have running in them. I also prefer to SSH to them rather than use the VirtualBox instance (it gives better character screen size, although I could reconfigure things; I also tab my terminals).

Anyway, in order to make things easier I put together two scripts, one that handles getting the IP address of the Virtualbox instance, and the other that handles connecting via SSH just by telling it the instance name. In order to do this you need to install the VirtualBox Guest Additions. This package is generally used in connection with video drivers for GUI based guests, but it also has some extensions that present extra information about the guest to the host machine.

Installing on Ubuntu is quite easy. My setup is using Ubuntu 12.10 on the desktop (host) and Ubuntu 12.04 LTS on the server (guest). To start with there is a package with the Guest Additions ISO in, so start by installing it with:

sudo aptitude install virtualbox-guest-additions-iso

Next you need to mount the ISO in the guest OS. To do this choose the Install Guest Additions option from the Devices menu. Since this is a CLI server OS it won’t automatically mount the ISO, so you will have to do this manually with:

sudo mount /dev/cdrom /media/cdrom

guestadditions1

Once you have done this you need to install dkms and then run the install script with:

sudo aptitude install dkms
sudo /media/cdrom/VBoxLinuxAdditions.run

It will complain about not having found X to install the graphics drivers, but this isn’t a problem.

Once you have done this you can use the command:

VBoxManage guestproperty enumerate <vname>

where <vname> is the name of your guest. This will list out all of the available information that can now be accessed.

Using this command in a little bit of bash I created the two scripts. Firstly to get the IP address of a named guest:

#! /bin/bash
VIP=`VBoxManage guestproperty get $1 "/VirtualBox/GuestInfo/Net/0/V4/IP" | awk '{print $2}'`
echo $VIP

Secondly, to SSH to a named guest:

#! /bin/bash
VIP=`VBoxManage guestproperty get $1 "/VirtualBox/GuestInfo/Net/0/V4/IP" | awk '{print $2}'`
ssh-keygen -f "/home/paul/.ssh/known_hosts" -R $VIP
ssh $VIP

This second one is a little more involved because it first deletes the entry from the known_host file (remember to change the location). I’ve done this to stop an error coming up if the IP address has already been used, which isn’t uncommon with DHCP leases (you often get the same one, but not always!). You will have to confirm the authenticity of the host each time you connect, but since this is scripted and the IP has been automatically obtained locally to the machine this shouldn’t present a security risk.

Update: an improved version of the above script that simply ignores the information in the known_hosts file is (thanks popey I should have remembered that one!):

#! /bin/bash
VIP=`VBoxManage guestproperty get $1 "/VirtualBox/GuestInfo/Net/0/V4/IP" | awk '{print $2}'`
ssh -o StrictHostKeyChecking=no $VIP

Each of these scripts takes the guest name as a parameter, eg:

vbip Alfresco

or

vssh Alfresco

Lastly, to make these new scripts easy to use I created a .bash_aliases file in my home directory with the following:

## custom aliases
alias vssh='~/scripts/vssh'
alias vbip='~/scripts/vbip'

You will need to adjust for whever you have put these scripts, I tend to have a scripts directory in my home directory for this purpose.

Auto naming terminal tabs

I use Ubuntu on the whole for my desktops and servers and the more recent versions have Byobu which customises Screen rather nicely. I am still running 8.04 LTS on one server at the moment which is too old to have Byobu in the standard repositories (yes it is on my todo list to upgrade!), but one of the most useful features is quite easy to implement without Byobu.

When I have multiple terminal tabs open with various local and remote (via SSH) command lines running it is nice to know which is which. Byobu thoughtfully changes the title as you log in, but Screen does not (I have both configured to automatically launch when I log in). One line added to my .bash_profile does the trick though:


printf "\033]0;${USER}@$(hostname) - screen\007"
screen -xRR

The first printf line is the one that does the trick and tells me who I’ve logged in as and to what machine, as well as reminding me I’m in Screen. The second screen line simply starts Screen if it is not already running, or connects to the existing instance if it is.

Ubuntu ATI driver

A couple of weekends ago I was at OggCamp and the first talk on the Sunday was a good one by LornaJane Mitchell. For one it was a timely reminder of how my IT career started. It was also a virtual kick up the backside to get a bit more use out of my blog. I tend to think in completed articles, but I do have a precedent for short technical comment entries, so here goes more…

I’ve just upgraded my desktop machine, it isn’t exactly state of the art, the new one is only a 3.2GHz P4 and is my first 64 bit desktop, but that’s beside the point. The point is I dropped the old SATA HD into a new box and let Ubuntu get on with the job of sorting out the hardware changes (as an aside Windows 7 put on a bit of a show and then gave up in a huff!).

All went well apart from the graphics, which meant I couldn’t even get the login prompt (I knew I should have stuck with a console and typing startx!! To cut to the chase the solution that worked for me was to boot into the recovery mode kernel and do a one off boot into a safe graphics mode. From here I used the Additional Drivers tool to remove the proprietary ATI driver. This allowed me to reboot into the standard desktop and confirm thins were working, but sadly I couldn’t get above 1024×768 which restricted screen space somewhat.

As it happens I doubt the above was needed because my next action was to boot once more into recovery mode and restore the proprietary driver and reboot. This time when the screen went blank and complained about being ‘out of timing’ I used ALT-F2 to bring up a CLI login and from there used:

sudo aticonfig --initial

This created /etc/X11/xorg.conf, although unfortunately this didn’t make any difference, but it did prepare the ground for:

sudo aticonfig --resolution=0,1280x1024,1024x768

which persuaded the driver to use a more sensible set of parameters that worked with the monitor.

The most notable difference I’ve spotted in the logs so far is that when not working I had the line:

(II) fglrx(0): Setting screen physical size to 423 x 317

whereas when working it is:

(II) fglrx(0): Setting screen physical size to 338 x 270

I’ve not explored whether there is anything else, or what that actually means!

Ubuntu, Dovecot and Sieve

Finally upgraded my main on site Ubuntu server to the latest LTS release (10.04). It was a small jump since I was running on the release immediately prior (9.10) and not the previous LTS release (8.04). I was doing this because the previous LTS release lacked a particular package version that I needed to use (which I can’t remember details of as I type this), and the LTS release wasn’t far off – although too far to wait given my need to install onto my new hardware (an Atom 330 based board which is handling the load very nicely with low power consumption).

Anyway, the upgrade was largely uneventful, which is always nice, I do like a boring life for some things 😉 The only two items of note were:

  • For some reason Upstart didn’t automatically start nmbd on boot – I’m not sure whether this was a one off, but I’m now following a bug on Launchpad and will have to find a suitable time to do another reboot and see what happens.
  • There was a minor problem with the Dovecot configuration (and this is what started me towards this blog post!) – the sieve plugin has changed.

I’ll elaborate on that one a bit.

Recently I migrated my mail system from a combination of Exim, Procmail and Dovecot to Exim and Dovecot with Sieve. I’ll get round to blogging about that process at some point, but for now suffice it to say that instead of receiving may with Exim and passing it to Procmail to filter into the various mailboxes and then using Dovecot to access it via IMAP, Exim now passes the mail direct to Dovecot which then uses built in Sieve support to filter the mail into the various mailboxes. This has two advantages, firstly Dovecot can index the mail as it comes in, which has a minor performance boost when first accessing new mail from the client, and secondly the Sieve syntax is much easier to follow than Procmail (well I find it is anyway!).

Getting right down to the issue at hand, on this upgrade I found things stopped working, and after a very brief look around the config file and Dovecot plugins directory identified that in the dovecot.conf file the line:

mail_plugins = cmusieve

needed to be changed to:

mail_plugins = sieve

This did get me thinking that it may be nice to manage a do-release-upgrade process in stages rather than hitting all services at once, but having said that the number of dependencies being upgraded at the same time in this process would likely make that impractical to manage – and to be honest I’ve not found a major problem yet 🙂

Empathy MSN bug

Yesterday I noticed that one of my two MSN accounts wasn’t logging in but instead was returning the error message “No Reason Specified”, which isn’t all that helpful really. I wasn’t overly worried because to be honest I don’t really use MSN, it just idles when ever my machine is on, much like my Yahoo and AIM accounts. I use Google Talk and Facebook Chat on the whole, with the odd venture into Skype.

Anyway, today the second account started giving the same error, so I decided something must be wrong, and I should take a look. If nothing else I wanted to find out whether it was me or something that needed raising as a bug. It looks as though this is a general problems and there should be a bug fix to the python-papyon package on the way, but to summarise the details from Ubuntu bug #664570:

Find the file

/usr/share/pyshared/papyon/service/description/SingleSignOn/RequestMultipleSecurityTokens.py

and edit the line

CONTACTS = ("contacts.msn.com", "?fs=1&id=24000&kv=7&rn=93S9SWWw&tw=0&ver=2.1.6000.1")

and replace it with

CONTACTS = ("contacts.msn.com", "MBI")

Personally I always leave the original line there as a comment for reference or backout purposes 🙂

Then restart Empathy and you should be fine.

BIOS fun

Isn’t playing with a computer BIOS fun? No? Of course it is!

I’m rebuilding my main desktop system at the moment. It isn’t anything spectacularly new, in fact it is based on a Athlon XP 2800+, but it runs Linux (Ubuntu 9.10 currently) with ample performance for my day to day tasks. Windows XP runs on it adequately, when it actually works (I clearly use it too little because it sulks and ‘blue screens’ every few months, requiring a repair or reinstall).

Anyway, as part of this rebuild I decided that it made sense to get everything bang up to date, including the BIOS. The board is obsolete now, so the BIOS was a few years old and should be stable enough – wrong! The board is a Gigabyte GA-7S748-L (GA-7S748 with on board LAN), and was running the F5 revision. Updating was simple enough, just boot of my DOS USB key (yes, I have a USB key with DOS installed!) and run the utility. This brought things up to revision F9, which was the latest, and is where things started to go wrong.

The first thing I noticed was that my Windows 7 installation couldn’t see the HD, so I reached for a driver (Vista was the most up to date) to add during the install process. This didn’t work, and further investigation showed that the BIOS of the PATA PCI card the drives were connected to wasn’t active. It turned out that enabling USB legacy support disabled the card BIOS. Unfortunately, in order to configure the card BIOS you needed a keyboard, and since mine was a USB one, USB legacy support was required to use it – catch 22!! After trying a PCI SATA card instead I found that this was clearly a motherboard issue and not specific to one card or chipset.

So the next thing to do was to back off to the previous BIOS (F8 in this case) to see if the bug had been introduced in the latest BIOS upgrade. Unfortunately it seems that the F8 BIOS was completely bug ridden (so it is a shame it is still available for download). After installing it the computer wouldn’t boot at all, although it would allow use of the BIOS itself. This board has a facility to flash the BIOS from a BIOS based utility (Q-Flash), which sounds pretty handy in this case. Sadly it didn’t work, although thankfully, the failure didn’t damage the installed BIOS any further. After a bit of research with Google, I found that if you disable USB support completely you can boot to a floppy and re-flash the BIOS using a DOS based utility (will DOS ever die?!).

So, with this information I managed to get back to the F5 BIOS and all was working again. Out of curiosity I then tried the F6 BIOS and found that the USB legacy support clash with the PATA card BIOS was introduced there, so presumably exists in F7 too. Back to square one again then, with the original F5 BIOS and a working PC!

Microsoft to provide default Ubuntu search?

A while back I noted from Popey’s blog that Canonical are changing the default search engine in the next version of Ubuntu to Yahoo!. I don’t think I’ve been particularly impressed with the Yahoo! search since the 90’s sometime, when I switched to Google because it provided much easier access to the search results I wanted. This was largely because it was at that time unencumbered by advertising results being engineered into high listing placements. Sadly that isn’t the case today, and I have the same annoyance with Google providing endless ‘search noise’ in the form of links to price comparison sites, or links into a site search for the terms you’ve used on Google, generally with results that are totally irrelevant. That is beside the point for this post though.

I note from recent news that Microsoft and Yahoo! have been given the go ahead for their search deal, which means that Microsoft Bing should be providing the search results for Yahoo! by the end of the year.

Interesting times, since that would appear to indicate that the average new user of Ubuntu will be using a Microsoft search engine, and one that may not be as good for searching for information on Linux and Open Source software – although it has to be said I’ve not experimented with this myself.