cant_connect

This is only for connections that is already set up before and suddenly recently stopped working. Remember that we have had customers call to say that a particular connection suddenly can't connect, only to discover much later on that this connection never worked, or that the last time they used this was over 6 months ago.

Steps to do when user can't connect:

Find out what company they are from, what release, and how they connect.

1. If they use a browser to connect to Control, they are on release 14 or 15. They are using guacamole.
2. If they have a shortcut on their desktop, they are using a VNC client.

At this point we need to remotely connect to their computer to verify what they are seeing. For windows computers, we would use ultraviewer. macs would need teamviewer. If we cannot connect to their computer with any of the above tools, then they need to check their internet connection.

Once connected to their computer (this confirms their internet is at least working):

1. Verify how they connect. If guacamole, try to login to their URL (ask the customer to show you how they connect on their browser) from your browser. Use guacadmin on your browser and try to pick their session. (guacadmin password is either "a secret" or "gu4c4dm1n")
2. For users of VNC client or if guacamole in step 1 above did not connect, check if you can connect to their session from sam:

   vncview <servername> <session_number>

   If the shared keys are not yet set up, vncview will ask for the root password a few times, just type the root password.

Where <servername> would be their server and <session_number> is the vnc session number or session name. If you cannot connect, we need to restart their session:

release 13 and below (as root):

• init Q

  release 14 and above:

  initctl restart turbo VNC=<session_number>

  If you get an error about Unknown job: turbo try

  initctl restart turbovnc VNC=<session_number>

  This will restart the VNC server and should fix the problem.
• If you can connect from sam, but not from the client PC, they must have a VPN. Try to disconnect and reconnect their VPN. It should either be native windows VPN or OpenVPN. There should only be one installed. If the VPN fails to connect, ask the customer to restart the whole PC. This should sort out most VPN related problems.

On some computers, we have a utility called "resetsess". This would kill all the processess owned by a certain linux user. The syntax is:

resetsess <session number>

or

resetsess <session_name>

This is an alternative to working out which command to use in step 2 above.