{"id":13,"date":"2011-08-12T16:35:00","date_gmt":"2011-08-12T16:35:00","guid":{"rendered":"http:\/\/cazenave.co.uk\/wp\/?p=13"},"modified":"2014-04-24T22:06:14","modified_gmt":"2014-04-24T22:06:14","slug":"unison-vs-dropbox","status":"publish","type":"post","link":"https:\/\/cazenave.co.uk\/unison-vs-dropbox\/","title":{"rendered":"Unison vs. Dropbox"},"content":{"rendered":"
A mature project by the name of Unison<\/a> purports to synchronise directories between a number of computers. It’s cross-platform (at least Windows, Mac and Linux) so it seemed suitable for a test run. Given my adventures with Dropbox<\/a>, then SpiderOak<\/a>, this looked promising.<\/p>\n Unison differs in some important respects from both SpiderOak<\/a> and Dropbox<\/a>. Firstly, there’s no remote backup (a.k.a. storage in the “cloud”): you can synchronise directories across many machines but you have to have at least some form of access to them (usually SSH). Secondly, Unison doesn’t run as a daemon like SpiderOak and Dropbox do. Those two launch transfers based on input\/output (I\/O) activity (i.e. you’ve added or removed a file in the synced directories); Unison doesn’t do this on its own. Thirdly, Unison doesn’t do versioning, so you can’t view the changes to a file over a given time. In SpiderOak’s case, this versioning goes back forever whilst Dropbox does so only for the last thirty days. These limitations can be overcome through the use of additional tools (see here<\/a> for more info), notably file monitoring tools.<\/p>\n Instead of this approach, however, I decided a more straightforward approach would suffice. I have essentially three machines on which I would like to synchronise a directory (and its contents). I decided that a star topology<\/a> would work best, which is to say one of the machines would act as the master copy and the two other clients would connect to it to upload and download files. The advantage of this approach is that I need only run an SSH server on one machine; the clients need only have SSH clients on them. Since one of these machines is a laptop and the other is behind a corporate firewall, this made set up a lot easier.<\/p>\n The first thing to note is that in order for this to act as Dropbox-like as possible, key-based SSH logins are necessary. Once I’d successfully set up key-based logins for each client machine to the master, then setting up Unison was pretty straightforwards. Their documentation <\/a>is actually pretty good, and I was able to set up the profiles on the Laptop and the Desktop machine with little hassle.<\/p>\n One point worth making is that Unison versions on the clients in the star network must be close to (or exactly the same as) that on the master in the network. Apparently there’s some differences in the way Unison checks for new files between versions. I’ve used versions 2.40.63 (Linux), 2.40.61 (Mac and Windows), and I haven’t received any error messages about conflicts. On the Windows machine, it was easiest to use the Cygwin version of Unison with Cygwin’s version of OpenSSH too. I didn’t have much luck with the GUI tool on any architecture. In fact, it was much easier to use the command-line and text files.<\/p>\n To set up a profile, Unison expected a .prf file in $HOME\/.unison<\/span> with the following format:<\/p>\n # Some comments, if you want As you can see, the syntax is pretty simple. Note the \/\/<\/span> after the remote-master.com<\/span> which specifies the SSH port number. Omit the :2222<\/span> if using the default (22). This will synchronise the contents of C:UsersslacksetUnison<\/span> on a Windows machine with a target of \/home\/slackset\/Unison<\/span> on the master. The process is the same on a Mac, but the .prf files live in $HOME\/Library\/Application Data\/Unison. You can create as many profiles as you want, something more akin to functionality in SpiderOak, but missing in Dropbox (which can synchronise only one directory).<\/p>\n There’s a number of options for the command-line invocation of Unison to run this in a daemon-like manner:<\/p>\n \/usr\/bin\/unison ProfileName -contactquietly -batch -repeat 180 -times -ui text -logfile \/tmp\/unison-“$(date +%Y-%m-%d).log”<\/p><\/blockquote>\n The important flags are -batch<\/span> and -repeat <\/span>n<\/i> which forces the syncronisation to occur without prompts and which will repeat every n<\/i> seconds (in my case, 180, or three minutes). If you omit -logfile<\/span> with some target, a unison.log<\/span> will be left in your home directory (which is annoying). I put this in the crontab with the @reboot<\/a> keyword (see man 5 crontab) on the Windows (through Cygwin) and Mac so every three minutes my files are synchronised. That’s not quite instantaneous, but if I’m feeling impatient, I created an alias to run that command without the -repeat 180<\/span>:<\/p>\n alias syncme=’\/usr\/bin\/unison ProfileName -contactquietly -batch -times -ui text -logfile \/tmp\/unison-“$(date +%Y-%m-%d).log”‘<\/p><\/blockquote>\n
root = C:UsersslacksetUnison
root = ssh:\/\/user@remote-master.com:2222\/\/home\/slackset\/Unison
sshargs = -C<\/p><\/blockquote>\n