Starting synergy automatically

 

You can configure synergy to start automatically when the computer starts or when you log in. The steps to do that are different on each platform. Note that changing these configurations doesn’t actually start or stop synergy. The changes take effect the next time you start your computer or log in.

 

Windows

 

Start synergy and click the Configure… button by the text Automatic Startup. The Auto Start dialog will pop up. If an error occurs then correct the problem and click Configure again.

On the Auto Start dialog you’ll configure synergy to start or not start automatically when the computer starts or when you log in. You need Administrator access rights to start synergy automatically when the computer starts. The dialog will let you know if you have sufficient permission.

If synergy is already configured to automatically start then there will be two Uninstall buttons, at most one of which is enabled. Click the enabled button, if any, to tell synergy to not start automatically.

If synergy is not configured to start automatically then there will be two Install buttons. If you have sufficient permission to have synergy start automatically when the computer does then the Install button in the When Computer Starts box will be enabled. Click it to have synergy start for all users when the computer starts. In this case, synergy will be available during the login screen. Otherwise, click the Install button in the When You Log In box to have synergy automatically start when you log in.

 

Unix

 

Synergy requires an X server. That means a server must be running and synergy must be authorized to connect to that server. It’s best to have the display manager start synergy. You’ll need the necessary (probably root) permission to modify the display manager configuration files. If you don’t have that permission you can start synergy after logging in via the .xsession file.

Typically, you need to edit three script files. The first file will start synergy before a user logs in, the second will kill that copy of synergy, and the third will start it again after the user logs in.

The contents of the scripts varies greatly between systems so there’s no one definite place where you should insert your edits. However, these scripts often exit before reaching the bottom so put the edits near the top of the script.

The location and names of these files depend on the operating system and display manager you’re using. A good guess for the location is /etc/X11. If you use kdm then try looking in /etc/kde3 or /usr/kde/version/share/config. Typical file names are:

 

		xdm		kdm		gdm
1		xdm/Xsetup		kdm/Xsetup		gdm/Init/Default (*)
2		xdm/Xstartup		kdm/Xstartup		gdm/PostLogin/Default (*)
3		xdm/Xsession		kdm/Xsession		gdm/Sessions/Default (*, **)

 

*) The Default file is used if no other suitable file is found. gdm will try displayname (e.g. :0) and hostname (e.g. somehost), in that order, before and instead of Default.
**) gdm may use gdm/Xsession, xdm/Xsession or dm/Xsession if gdm/Sessions/Default doesn’t exist.

For a synergy client, add the following to the first file: /usr/bin/killall synergyc sleep 1 /usr/bin/synergyc [<options>] synergy-server-hostname Of course, the path to synergyc depends on where you installed it so adjust as necessary.

Add to the second file: /usr/bin/killall synergyc sleep 1

And to the third file: /usr/bin/killall synergyc sleep 1 /usr/bin/synergyc [<options>] synergy-server-hostname Note that <options> must not include -f or –no-daemon or the script will never exit and you won’t be able to log in.

The changes are the same for the synergy server except replace synergyc with synergys and use the appropriate synergys command line options. Note that the first script is run as root so synergys will look for the configuration file in root’s home directory then in /etc. Make sure it exists in one of those places or use the –config config-pathname option to specify its location.

Note that some display managers (xdm and kdm, but not gdm) grab the keyboard and do not release it until the user logs in for security reasons. This prevents a synergy server from sharing the mouse and keyboard until the user logs in. It doesn’t prevent a synergy client from synthesizing mouse and keyboard input, though.

If you’re configuring synergy to start only after you log in then edit your .xsession file. Add just what you would add to the third file above.

 

Mac OS X

 

[By Tor Slettnes]

There are three different ways to automatically start Synergy (client or server) on Mac OS X:

 

1. The first method involves creating a StartupItem at the system level, which is executed when the machine starts up or shuts down. This script will run in the background, and relaunch synergy as needed. 

   Pros:

   Synergy is persistent, so this allows for a multi-user setup and interactive logins.

   Cons:

   The synergy process does not have access to the clipboard of the logged-in user.

 

 

1. The second method will launch Synergy from the LoginWindow application, once a particular user has logged in. 

   Pros:

   The synergy process inherits the $SECURITYSESSIONID environment variable, and therefore copy/paste works.

   Cons:

   Once the user logs out, synergy dies, and no remote control is possible.

 

 

1. The third method is to launch a startup script from the “Startup Items” tab under System Preferences -> Accounts. 

   Pros:

   Does not require root (Administrator) access

   Cons:

   Once the user logs out, synergy dies, and no remote control is possible.

 

The text below describes how to implement a Synergy client using the first two methods simultaneously. This way, Synergy is always running, and the clipboard is available when someone is logged in. A Mac OS X Synergy server setup will be quite similar.

1. Create a System Level Startup Item

 

• Open a Terminal window, and become root: $ sudo su –
• Create a folder for this item: # mkdir -p /Library/StartupItems/Synergy
• In this folder, create a new script file by the same name as the directory itself, Synergy. This script should contain the following text:#!/bin/sh . /etc/rc.common   run=(/usr/local/bin/synergyc -n $(hostname -s) -1 -f synergy-server)   KeepAlive () { proc=${1##*/}   while [ -x “$1” ] do if ! ps axco command | grep -q “^${proc}\$” then “$@” fi   sleep 3 done }   StartService () { ConsoleMessage “Starting Synergy” KeepAlive “${run[@]}” & }   StopService () { return 0 }   RestartService () { return 0 }   RunService “$1”

  However, replace synergy-server with the actual name or IP address of your Synergy server.

  Note that this scripts takes care not to start Synergy if another instance is currently running. This allows it to run in the background even when synergy is also started independently, e.g. from the LoginWindow application as described below.

• Make this script executable: # chmod 755 /Library/StartupItems/Synergy/Synergy
• In the same folder, create a file named StartupParameters.plist containing:{ Description = “Synergy Client”; Provides = (“Synergy”); Requires = (“Network”); OrderPreference = “None”; }

 

That’s it! If you want to test this setup, you can run the startup script as follows:

# /Library/StartupItems/Synergy/Synergy start

Any errors, as well as output from Synergy, will be shown in your terminal window.

Next time you reboot, Synergy should start automatically.

2. Run Synergy When a User Logs In

Each time a user successfully logs in via the console, the LoginWindow application creates a unique session cookie and stores it in the environment variable $SECURITYSESSIONID. For copy and paste operations to work, Synergy needs access to this environment variable. In other words, Synergy needs to be launched (directly or indirectly) via the LoginWindow application.

However, in order to kill any synergy processes started at the system level (as described above), we need root access. Thus, launching Synergy within the User’s environment (e.g. via the Startup Items tab in System Preferences -> Accounts) is not an option that work in conjunction with the method above.

Fortunately, the LoginWindow application provides a “hook” for running a custom program (as root, with the username provided as the first and only argument) once a user has authenticated, but before the user is logged in.

Unfortunately, only one such hook is available. If you have already installed a Login Hook, you may need to add the text from below to your existing script, rather than creating a new one.

 

• Launch a Terminal window, and become root: $ sudo su –

 

 

• Find out if a LoginHook already exists: # defaults read com.apple.loginwindow LoginHook This will either show the full path to a script or executable file, or the text: The domain/default pair of (com.apple.loginwindow, LoginHook) does not exist In the former case, you need to modify your existing script, and/or create a “superscript” which in turn calls your existing script plus the one we will create here.The rest of this text assumes that this item did not already exist, and that we will create a new script.
• Create a folder in which we will store our custom startup script: # mkdir -p /Library/LoginWindow
• In this folder, create a new script file (let’s name it LoginHook.sh), containing the following text:#!/bin/sh prog=(/usr/local/bin/synergyc -n $(hostname -s) ip-address-of-server)   ### Stop any currently running Synergy client killall ${prog[0]##*/}   ### Start the new client exec “${prog[@]}”
• Make this script executable: # chmod 755 /Library/LoginWindow/LoginHook.sh
• Create a login hook to call the script you just created: # defaults write com.apple.loginwindow LoginHook /Library/LoginWindow/LoginHook.sh

 

More information on setting up login hooks can be found at Apple.

When running the Synergy client, you may need to use the IP address of the Synergy server rather than its host name. Specifically, unless you have listed the server in your local /etc/hosts file or in your local NetInfo database, name services (i.e. DNS) may not yet be available by the time you log in after power-up.synergyc will quit if it cannot resolve the server name.

(This is not an issue with the previous method, because the StartupParameters.plist file specifies that this script should not be run until “network” is available).

3. Good Luck!

Remember to look in your system log on both your server and your client(s) for clues to any problems you may have (/var/log/system.log on your OS X box, typically /var/log/syslog on Linux boxes).