In the following sections, we will describe how to cope with problems where the ThinLinc client is reporting an error.
This error is caused by failure to connect to the SSH daemon on the ThinLinc server (the server running the VSM server). This could be caused by the fact that the SSH daemon is simply not running, or that it is not letting the user in for some reason.
Another possible reason is that there is a firewall between the user and the ThinLinc server, that forbids communication.
This error is very often caused simply by the user entering an incorrect password. Begin by verifying that the user is actually entering the correct username and password.
If the username and password are correct and this is the first time the user tries to login, check the SSH logs of the server. If SSH says that the user is invalid, that means that something is incorrect in the user's user information database entry. For example, this may happen if a user stored in eDirectory has two cn attributes, one of them different than the other.
The getent command can be a valuable tool to dissect problems of this type. If the output of getent passwd <username> doesn't produce any output, that is a sign that the user is in fact invalid.
Usernames beginning with numbers (for example 96aabbcc are parsed as numeric uids by getent, rendering getent rather useless for debugging purposes in environments with username schemes beginning with numbers.
If usernames with numbers in the beginning are in use, the following python code can be used to verify a username
python-thinlinc -c 'import pwd, sys; print pwd.getpwnam(sys.argv[1])' <username>
This error is most often caused by the fact that the VSM server is not running on the server. Start the VSM server and try again.
A user entering the wrong hostname, for example the hostname of one of the VSM agents, would also get this error message. Check that the user has entered the correct hostname. In very rare cases, this could also be caused by incorrect DNS data.
This error is reported if there were no working VSM agents available according to the load balance information in the VSM server.
In a system with few VSM agent servers, restoring a VSM agent that has been down for some reason doesn't take effect immediately - the load balance information is only updated once every 40 seconds by default. Either wait for the load balance cycle to complete, or restart the VSM server. In a small cluster it might be a good idea to lower the load balance cycle, by setting the parameter /vsmserver/load_balance_cycle.
The load balance information can be inspected in the ThinLinc Web Administration, see Chapter 17, Administration of ThinLinc using the Web Administration Interface .
When this error occurs, the user was valid on the VSM server, but for some reason, the session couldn't be created on the VSM agent.
One very common reason for this problem is that the VSM agent has lost its connection to the user database backend (LDAP, Windows domain or other database), so the user exists on the VSM server, but not on the VSM agent. If this is the case, the VSM agent log on the selected server will clearly state that the user doesn't exist on the system.
Another very common reason is home directory trouble on the VSM agent. Verify that the home directory exists on the selected server, and that it is owned by the correct uidNumber/gidNumber. Of course, the user must have write permissions on his/her home directory.
To verify that the home directory works, the following command can be used:
ssh <username>@<agenthost> touch .
If the home directory is correctly mounted and writable by the user, the above command will not produce any output except the password question.
This error is caused by failure to connect to the SSH daemon on the selected VSM agent. This could be caused by the fact that the SSH daemon is simply not running, or that it is not letting the user in for some reason.
Another possible reason is that there is a firewall between the user and the selected VSM agent that disallows communication.
In this section we will discuss some problems that can occur after the successful login, that is, after the ThinLinc login window has closed. In this phase, a number of session startup problems can occur
If the ThinLinc login window closes, and the session starts up but then immediately shuts down, inspect xinit.log found in /var/opt/thinlinc/sessions/<username>/last/on the selected VSM agent. Some of the commands run during session startup will probably have written an error message that will be stored in that file.
It may also be of value to inspect the VSM agent log on the selected server.
If a previous session still exists and is faulty, for example because of desktop environment failures, the user is reconnected to the same session when logging in. Disconnect from the session, enable the "End existing session" checkbox and log in again. That will terminate the current session and start a new one.
When using the ThinLinc Desktop Customizer, as documented in Chapter 18, Building Custom Linux Desktops with the ThinLinc Desktop Customizer , the KDE or Gnome menu and the entries on the desktop are customized at each login. If this fails, quota problems are very often the problem. Check the quota of the user in question.