![]() ![]() ![]() # directory on host b (this is the remote host) You can include other project files with the include statement as shown here: # directory on host a (this is where Unison will be executed) Because I have more than one target I prefer to split the configuration into several files. There exists one default target which is configured in the file default.prf. You can configure more than one synchronization target by choosing a meaningful name. The files are located in the ~/.unison directory. Like in the long UNIX tradition, Unison is configured using text files. Now you should be able to connect to host B without any interaction needed. Make the file accessible by the user only with: ~ $ chmod 600 ~/.ssh/authorized_keys If you already have some public keys on host B, make sure you append the new key and not overwrite the file by the above command. Now copy the public key to host B: ~ $ scp ~/.ssh/id_rsa.pub host_B.ssh/authorized_keys The command creates the private key in ~/.ssh/id_rsa and the public key in ~/.ssh/id_rsa.pub. When you are asked for a password just hit Enter twice. Create a new public/private key pair with the following command: ~ $ ssh-keygen -t rsa If you are in doubt, use the normal password approach or even better create a public/private key pair with a password. Although this is much more easier to use, it should be only used on hosts which are trusted. The following creates public/private keys without a password. But for a little bit more comfort I suggest to create a public/private key pair for the authentication. In the default setup you can just use ssh. As I always prefer/demand encrypted communication this is a big plus of course. One advantage of Unison over Rsync is that you can use different communication channels for the file transfers. Setting up public/private key authentication for ssh At least on Linux and Mac OS X it is relatively easy to compile Unison from the sources. To prevent surprises and unnecessary trouble it might be a good idea to make sure that every involved system use the same version of Unison. Alternatively you could download a binary version for Mac OS X or Windows here. Most modern Linux distributions include Unison in their package manage system. So here comes the second post in the ToolTips series, which covers an easy and portable way for file synchronization. Luckily there is a solution for all the problems mentioned which is called Unison. That is not always the case (especially when you leave the office at 11:00 p.m.) and it also doesn’t cover files which aren’t handled by a version control system. But this means you always need a more or less stable variant of your code, so that other developer can, at least compile, or much better use it. On host A you check it in and on host B you check it out afterwards. Another approach is to check-in changed source files into a version control system, like CVS. Unfortunately Rsync synchronize only in one direction, it doesn’t work very well when more than two hosts are involved (and it isn’t really comfortable to set up on Windows) and can’t use a secure communication channel. On UNIX/Linux the preferred tool for such a task is Rsync. The problem getting bigger when you work in addition on different operation systems or use more than two hosts. ![]() You need to get changed files from host A to host B and vice versa. When you work with at least two computers on the same project on a daily basis you might have a problem. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |