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.
- If they use a browser to connect to Control, they are on release 14 or 15. They are using guacamole.
- 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):
- 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")
if you do not know what is the url its most likely http://companycode.creativecomputing.com.au:8080/guacamole/
if customer connect from http://companycode.creativecomputing.com.au and its not connecting , but it connect to the above url that mean their http was not running , need to run serivce httpd restart, need to investigate top and see if malware stopped it.
- if they complain connection is slow, it can be with their router, ask them to restart the router. first.
- you can do ultra viewer and run tracert on their command line to see exactly which hop is slow.
- 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. Example:vncview xtreme.crecom.com.au x2xwyn
vncview will give you the server name and the session number (you have to subtract 5900 from the number displayed) it connected to.
If you cannot connect, we need to restart their session. Connect to <their_server>:5 using vnc
release 13 and below (as root): init Q
this will only restart sessions that are not running.
release 14 and above:initctl restart turbo VNC=<session_number>
If you get an error about Unknown job: turbo tryinitctl 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.
if vpn cannot connect, and if they use ppdpt vpn window's native vpn then i maybe too many time login fail , look at fail2ban Diagnosing_issues_with_fail2ban and PPTP_VPN
- can run to stop the blocking
service fail2ban stop
On some computers, we have a utility called "resetsess". This would kill all the processess owned by a certain linux user. The syntax is:
run resetsess on a new pormpt under ccc , this will always give you the right resetsess , need to know root password before head
resetsess <session number>
or
resetsess <session_name>
This is an alternative to working out which command to use in step 2 above.
if resetsess do not restart the section, then need to check for the lock file in /tmp/.X(vncnumber) , after removing it then resetsess should be able to restarte the secssion.
10, what if cannot vncview to our customer server.
first need to use their ultra viewer which connect to their session and open a terminal with root access.
we use pppd to connect to sam from customer server.
and sometime the pppd on our customer server was not connecting to sam.
the script used to connect ppp to sam is in /etc/ppp/connect-crecom
in the script it specify the command to run e.g. /usr/sbin/pppd call crecom.
run the command directly with extra argument /usr/sbin/pppd call crecom nodetatch debug
and look for error on the screen most likely it will be remote host no reachable, and that was will mean the DNS was not working so need to add the free google dns to /etc/resolve.conf
to check dns run dig "url" on sam and see if can be resolved. if dig return 0 time to leave, that mean domain name expired.
For TJMNQ server:
If TJMNQ complain that the server is so slow it is unusable or cannot connect, check run "top" to check.
If it is not a Control program, it is most likely TJ Micro's backup or monitoring software.
Note that these have to be run as root.
to restart the backup software:
initctl restart spx
to restart the monitoring software:
service ltechagent restart
If you have performed any of the above procedures, make a note of date and time and let Rod know.
olbis server latest way to restart
1, systemctl to check is service is up, red mean down
2, systemctl restart vncserver@:20.service