6.1 Services to check
PrivateServer runs a plethora of services, each one committed to its result. Some of them are strictly related and bounded to offer the secure voice connection. These are:
Equally important is the Tomcat service, which provides the web console and thus is responsable for the management the of Asterisk/VoIP via the graphical appliance. This means that Tomcat itself is not mandatory to run the Secure Call service itself, but is very important considering the service as a whole and so including its configuration and management as well.
The SSH service is mandatory to perform a deep service analysis, so it is a required resource to be checked first,
6.2 What should we check?
The checks are related to the services performances on the server, meaning that we are not going to measure the bandwidth usage or the external reachabilty for each service. Instead we are going to check that the PrivateServer is correctly running the application beside each service exposed.
6.3 How to perform checkings
Besides the NOC operations running, which might warn you about any service problem, we will explain how to perform a direct check-up of the single services. This means to get sure that each service is running and is bound to the expected NIC as a first step. Once assured about this, it means also to get sure that each service is properly responding. "Properly" means within an expected time and furnishing correct informations along with the way you configured it.
6.3.1 Web Console/Tomcat
First of all you make sure that the Web Console (meaning the Tomcat service) is reachable and running. Use your preferred browser and point it to the Login page, as you did in the First Access Paragraph. Just remember to use the actual IP address and login/password pair for administrator, if you changed any of the above.
If you reach the login page, then the Tomcat and its related application are most probably running fine. If not, then jump to the "6.3.2 SSH" paragraph and from the command line restart the service:
Wait 5/6 seconds to let the Tomcat set up itself completely and then try again to access the Web Console.
188.8.131.52 Preliminary service check
After you get in, please choose the "Application" menu entry from the left side menu (main menu), under the "Server Configuration" section. You get the "Edit Application" page, as shown in fig. 6.3.1-1.
fig. 6.3.1-1: Edit Applications page (just one NIC)
Make sure that each application is active on the expected interface. If not, please change the settings accordingly with your needs as described in Applications Settings paragraph (add link). After you're done, check if now the service you are testing is working fine.
If after such modification the service is still causing trouble or if you just want to perform deeper analysis, then go on reading.
Now you know for sure that the SSH service is running on the expected NIC, let's try to reach it. Open you SSH client and connect to the IP address you configured on the NIC you bonded the SSH service. We don't give you detail about ssh client setup as you are expected to know how to deal with it.
Login using the root user and its password (understand how we manage the root password?). Once you're in you get sure that the SSH service is running as expected.
MySQL provides the data base for the entire appliance. Thus if it's not working properly, or worse not running at all, the expected outcomes are that no other service is working. We need first to make sure MySQL is up.
184.108.40.206 Check if MySQL process deamon is running at all
Stay in the SSH console and make sure MySQL is running. First check if the mysql.pid file is present. This file is created at the MySQL service boot, so its presence is an evidence the service has been started:
Next step is to control that the spoken file is not empty and that it really contains the process id of the MySQL deamon:
Now we got such number, we can use it to perform a process search to ensure the process is still in running state:
If anything of the above steps went wrong, then we try to start the service once again manually and check if any problems arise during the process:
The Asterisk service is splitted into two different sub-services which are the SIP service for PrivateGSM Users and the SIP Trunk to perform end-to-site calls directed to a local PBX. First we assure that the main process is alive:
Then we try to connect to the Asterisk command line interface:
inside the console we raise the information level:
This would notice us as soon as any trouble arises. The particular troubleshooting about Asterisk can't be covered in this manual and we ask you to refer to the specific Asterisk documentation (http://www.asterisk.org).
If the status check returns an error such as:
Then you can try to run the Asterisk daemon manually, having particular attention to the console error messages if any:
If you want to exit the Asterisk CLI, just insert the "quit" command and press Enter button
6.3.5 Asterisk Trunk
The checks about Asterisk's trunk(s) have to be performed only in case of sip trunk configurations. Refer to 2.5 Sip Trunk(s) configuration.
If you have a Trunk configured, then you can go further. From the Asterisk CLI (refer to the previous paragraph) you can perform a check of the trunk registration:
In the case shown above we have a correct trunk registration. Else the output is empty, so you have to check your trunk settings.
Remember that sip Trunks are UDP and this can trigger firewall settings