QuickSynergy Server Troubles

Synergy allows one computer to control the keyboard and mouse of one or more other computers seamlessly, even if the computers are all running different operating systems. I am using my Mac laptop to drive my Mac and a Windows 7 laptop. When it is working it is a pretty sweet setup, but the configuration can be a little touchy.

Sometimes the Mac OS X server refuses to start. When it fails I see this message in /var/log/system.log on my Mac:

Oct  6 13:37:06 eagle [0x0-0xe4be4b].com.cordeiro.QuickSynergy[36223]: INFO: Synergy server 1.3.1 on Darwin 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:09:02 PDT 2011; root:xnu-1699.22.81~1/RELEASE_I386 i386
Oct  6 13:37:06 eagle [0x0-0xe4be4b].com.cordeiro.QuickSynergy[36223]: FATAL: unknown screen name `eagle.local'

It appears that QuickSynergy cannot resolve the name of my Mac for some reason, though I can ping it both locally and from another computer on the same subnet.

My Mac has both a wireless and a wired 1 Gbps link, by default, routes over the wired network.  When I disconnect and reconnect the wired network, the error from QuickSynergy goes away and netstat shows that Synergy is listening on the wireless network.  Since the client that connects does so through an ssh tunnel to localhost, it does not really matter.  It just seems strange that Synergy would be able to listen on the wireless network and not the wired network.

This problem requires more debugging, but for now I can make it work, so I’ll get back to what I wanted to do and figure it out later.


Automatically Start ssh-agent on Mac OS X

Mac OS X does not automatically start ssh-agent for you when it creates a new login session.  I suppose this makes sense for much of the Mac target audience that will never use ssh, but it is annoying for those of us who use it regularly.

I added the following to my .profile automatically start ssh-agent when I open my first terminal window:

if [ "x" == "x`ps -x -u ${USER} | egrep [s]sh-agent`" ] ; then
	ssh-agent | sed -e "/^echo/d" > ${HOME}/bin/agent-env
source ${HOME}/bin/agent-env

Terminal.app starts a new login shell, which calls .profile every time you create a new window.  The ‘if’ statement check so see if ssh-agent is already running, if not, it starts a new ssh-agent and writes the output to ${HOME}/bin/agent-env.

This file sets the environment variables ssh needs to find the ssh-agent.  The ‘source’ command after the if statement runs agent-env in the current process, which allows the environment variables to take effect in the current process.

You will still have to run ssh-add to add your keys, but at least you do not have to start the ssh-agent.

Installing MacPorts on Lion with Xcode 4 from the App Store

Installing MacPorts on Lion requires first installing Xcode 4.1.  Apple makes Xcode available as a download to developers who have subscribed as Mac developers for $99 per year, or for free through the Mac App store.  Unfortunately, the Xcode installer that the App Store downloads does not install the “Unix Development” or “System Tools” components required by MacPorts.

After much fiddling, I found a way to install Xcode 4.1 from the Mac App Store and get the “Unix Development” and “System Tools” components.  Here is what I did:

  1. Install Xcode 4 through the App Store
  2. Go to the /Applications folder
  3. The “Install Xcode” application is the installer that the App Store used to install Xcode (without the components you want).  Right click on “Install Xcode” and select “Show Package Contents”.
  4. Open Contents/Resources and double click on Xcode.mpkg

Double clicking the mpkg installer will give the option to install Xcode in a custom location and to customize which components are installed, including “Unix Development” and “System Tools”.

The install process took my laptop about 30 minutes to complete.  It might be possible to cancel the initial install after “Install Xcode” has been fully downloaded, then proceed to the mpkg install, but I have not tested that.

Google Docs for Document Collaboration

Escent is comparing Google Docs, Sharepoint, and a few other tools to handle document sharing within Escent.  I had previously played a little with Google Docs for writing shared documents, but not tried anything serious with it.  This post describes my initial impressions.

The Good

Being able to have multiple people edit the same document at the same time on different computers is really cool. The old way is to send the document back and forth via email or some medium (like email, a FLASH drive, network share, or Dropbox).  With two people, this process is not so bad.  The Track Changes feature in MS Word makes it easy to figure out what changes from revision to revision, as long as everyone remembers to turn it on.  However, with more than two people, either someone ends up having to manually merge changes from several editors or editors have to take turns editing passing around the file — not an efficient use of time.

The next biggest features of Google Docs are easy availability and version history.  Google Docs saves all the uploaded and saved versions of your documents so you can revert to old versions if something goes wrong.  As with any cloud storage, the docs are always available online for download or direct editing.  For Windows users, Google Cloud Connect, lets you access documents from Microsoft Office.  Office has a few more features than the online Google Docs tools, but more importantly, gives you a way to work on documents when network access is not available.  Documents get uploaded every time MS Office saves them, so the latest version is always online, assuming you have a network connection.

Google Docs makes all these features available for free for up to 10 GB.  That is enough space to really try out Google Docs and see if it will work for you.  Other cloud solutions typically will give 15 day free trial.  After the trial period, you either have to pay or lose access.   Being able to grow into the system over a period of time and only pay when it becomes necessary lowers the barrier to entry for Google Docs.  The additional cost to go beyond 10 GB on Google Docs is quite reasonable and should not be an issue for many businesses.

The Bad

I pretty quickly ran into several big limitations with Google Docs.  The first was the upload size limitations.  Google Docs will not upload a Microsoft Word document bigger than 1 MB through the web interface.  According to the documentation, it does not matter whether you pay for extra storage or not, if the document is too long, then it just will not upload.

In this day and age, 1 MB is terribly small.  I have very few Microsoft Word documents under 1 MB.  The reason is that Microsoft Word does not work very well with vector graphic formats, so pictures end up getting included in documents as images.  Line art needs to have a resolution of 600 dpi or higher to look respectable when printed.  Once a document has two or three 600 dpi, full page width images, it exceeds the 1 MB limit.

The other major problem with Google Docs is figure formatting.  The first real document I uploaded is a Microsoft Word description of some tests Escent will run.  The document is about 2.6 MB with thirteen pages of text including three floating figures and several inline tables.  It took several minutes to view the document with the document viewer.  Google Docs flowed the text and tables behind the figures making them hard to read.  When I tried to edit the document, Google Docs failed to convert it to editable format because it was more than 1 MB.


If our entire document life cycle stayed within Google Docs, I would spend more time looking at it and probably eventually use it.  The collaborative mode is a really step up in document sharing, and the low barrier of entry is great.  However, we already have a lot of documents that we would like to move to whatever solution we end up using.  Not being able to handle files bigger than 1 MB is a real deal killer.  These days 1 MB is just tiny for a document with an figures in it.  Most of our documents end up with at least one figure, so Google Docs will not work for us.

If we stayed entirely in MS Office and only used Cloud Connect to sync documents through Google Docs, it still might be worthwhile.  Unfortunately, Cloud Connect does not work for the Mac.  We would have to manually upload and download documents to use them on a Mac.

My next task is to see if Sharepoint is any better.  Being a Microsoft product, I am sure it can be made to play nice with MS Office.  At first glance the Sharepoint integration with Office appears to be comparable to Google Cloud Connect.  The real problem with Sharepoint is configuration.  It is general enough to do anything, but with that flexibility comes the hard work of making it do the specific things we want.  A good set of defaults would be helpful.  Unfortunately, our install does not seem to have any useful defaults.