Windows to Linux file synchronization over ssh: Unison solution

The aim: Portable and simple solution (no administrative right required on both sides) to synchronize files from Windows to Linux machine over insecure network (trough ssh) using Unison (ie. using only freeware software).
The problems: There is no ssh command line client in Windows.

Here are the important details:
I have used Unison (version 2.32.52), runtime GTK+ 2.14.7a environment from the Pidgin project (as described on the unison's page), plink.exe (version 0.60) and small script to point unison's sshcmd to plink.exe.

1) Create a new folder and unpack the two executable from Unison ("Unison" in my case).

2) As user install GTK somewhere.
- add the c:\somewhere\GTK\2.0\bin to the PATH variable in the system settings.

- or copy all files from \GTK\2.0\bin to the Unison folder. Then copy the whole (not the content) "etc", "lib" and "share" folders as well in the same folder.

3) Download and copy plink.exe in the "Unison" folder.

4) In notepad copy paste the following line

@c:\pathtoputty\plink.exe -ssh -P 22 -pw [mypassword] -l [myusername] -load [myputtysavedsession] "unison -server -auto"

change to fit your configuration and save it as "plinker.bat" in the "Unison" folder.

If you use pagent from the PuTTY then you can omit the username and password and use ssh-keys as usual (then also your password will be safe)

5) On the linux computer download or install unison. It will be good if you match the version on the Windows machine or vice versa. If you download the static binary, put it somewhere in your $PATH.

6) Start the Unison Gui version and configure your profile. This will fail, because ssh is not specified. Go to C:\Documents and Settings\yourprofile\.unison and add this line to the profile you have created.

sshcmd = plinker.bat

This and the GTK assumes that you have started Unison from its folder.

6) Start again - this time it should work. Enjoy.

Note: In point 4 you might need to provide the full path to the unison binary on the Linux machine.
Note: Since the configuration for the server address is actually specified in "plinker.bat" (it actually overrides the address specified in unison) you will need another script to connect to another server.

The original idea for the plinker.bat script is taken from here.

GlobalSat BU-353 gps receiver

Product details on the vendor's web page.

Well, this is my first experience with GPS receivers, so I am not in a position to compare performance with any other receiver. The general opinion, from the countless reviews in the Net, is that is very sensitive and fast to fix the position.

My intention is to use the receiver with my Eee PC 901 in the rare occasions when I need a GPS navigator or rather as a small home project.

First impressions: smaller than what I was expecting from the pictures, reasonable length of the cable (1.5 m), time to fix from cold start 15~20 minutes from inside the room in my apartment and about 4~5 minutes in a car.

Under Windows XP the initial setup is quite simple. There is a small standard tool provided on the installation disk "GPS Info" that can connect to the virtual serial COM port and communicate with the receiver - excellent to check on the status of the module.

Under Linux, most probably you will need "gpsd" to communicate with the device. I have installed "GPSDrive" from synaptic that has also pulled all the necessary dependencies including gpsd.

WARNING:(read this before you experiment yourself). I have used EeeBuntu 2.0 that has the necessary modules but for one or another reason does not starts the gpsd daemon when you insert the USB. This is not a serious problem, since as user one can easily start the program with: gpsd -bnN -D 2 /dev/ttyUSB0 . DO NOT forget the "-b" OPTION!!! From the gpsd man page

-b

Broken-device-safety, otherwise known as read-only mode. Some popular bluetooth and USB receivers lock up or become totally inaccessible when probed or reconfigured. This switch prevents gpsd from writing to a receiver. This means that gpsd cannot configure the receiver for optimal performance, but it also means that gpsd cannot break the receiver. A better solution would be for bluetooth to not be so fragile. A platform independent method to identify serial-over-bluetooth devices would also be nice.

And this is the whole story... I have managed to lock my device the very first time I have tested it under Linux (didn't use the "-b" option). It became almost inaccessible. "GPS Info" was showing garbled output while the led remained off. I have almost accepted the damage since 5 minutes without power did not help. A suggestion on the net says that it needs 72 hours to drain completely and reset. The better solution: Under Linux, start gsmd with the "-b" option. Then connect to the the daemon by "telnet localhost 2947" and then type "n=0" to set the sirf-III chip or firmware to output NMEA strings only. Here is the original post of the solution.

The common tools, to get some info from the GPS receiver under Linux are:

xgps: simple test client for gpsd with an X interface. It displays current GPS position/time/velocity information and (for GPSes that support the feature) the locations of accessible satellites.

cgps: client resembling xgps, but without the pictorial satellite display and able to run on a serial terminal or terminal emulator.

as well as xgpsspeed, gpxlogger, cgpxlogger etc.