B.2.  Troubleshooting Specific Problems

B.2.1.  Problems Where the Client Reports an Error

In the following sections, we will describe how to cope with problems where the ThinLinc client is reporting an error.

B.2.1.1.  Couldn't set up secure tunnel to ThinLinc server. (Couldn't establish SSH tunnel, SSH terminated.)

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.

B.2.1.2.  "Login Failed! Wrong username or password."

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.

Note

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>

B.2.1.3.  The SSH connection succeeded, but the ThinLinc server connection failed.Perhaps this server doesn't run a ThinLinc server?

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.

B.2.1.4.  ThinLinc login failed. (No agent server was available)

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 .

B.2.1.5.  ThinLinc login failed. (Couldn't create your session)

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.

B.2.1.6.  Couldn't set up secure tunnel to VNC! (Couldn't establish SSH tunnel, SSH terminated.)

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.

B.2.2.  Problems that Occur After Session Start

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

B.2.2.1.  Session starts, but closes down immediately

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.

B.2.2.2.  At login, user is reconnected to previous, faulty, session

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.

B.2.2.3.  Login Succeeds, but the ThinLinc Desktop Configuration fails

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.

B.2.2.4.  Login Succeeds, but KDE Fails to Start

If KDE fails to start, complaining about being unable to create symlinks and similiar, quota problems are very often the real problem. Check the quota of the user in question.