Distributed Monitoring

This page documents the steps required to monitor multiple asterisk servers from one instance of FOP2. This paper will discuss how to configure the FOP2 server on 192.168.0.7(server1) to monitor asterisk on both 192.168.0.7 (server1) and 192.168.0.11(server2), both of which are Far South Networks Com.X devices.

First server1 should be configured with the necessary log in credentials to access asterisk on server2, and then server2 should be configured to allow asterisk access to server1.

On Server2: Edit /etc/asterisk/manager.d/cop2-ami.conf to permit connections from server 1. The file should look something like below:

In the above, the default to permit access from the localhost has been edited to allow access only from the central Fop2 server (server1). Take note of the “secret” field as server1 will need to be configured to access server2 using this string.

On Server 1: On the fop2 server, we need to add the distributed servers to the list of asterisk servers to monitor. To do this, edit /etc/fop2/fop2.cfg to include a definition for the asterisk ami on server2. The file should look something like below:

Note that the localhost definition remains, as FOP2 is monitoring asterisk on server1 (localhost) and server2(192.168.0.11).

The above configures sever1 to access and monitor asterisk on server2, which has been configured to allow monitoring abilities to server1. Now FOP2 itself needs to be configured, so as to allow users on all monitored Com.X systems to access the operator panel, and also to display buttons for the extensions on all monitored systems.

FOP2 Buttons

On server1 there is a file called fop2_comma_buttons.cfg located at /etc/fop2/ . This file defines which extensions, trunks and destinations are displayed on the FOP2 GUI. It is generated automatically by the Com.X GUI, to contain all configured extensions, trunks and destinations (assuming a full license has been purchased. If not, it will contain only the first 15 destinations configured).

A similar file is generated on server2. This file needs to be edited slightly, and renamed before being saved in the same location on server1.

For the purpose of this a script has been developed a script that automatically reads through the /etc/fop2/fop2_comma_users.cfg and /etc/fop2/fop2_comma_buttons.cfg, renames the files using the hostname of the unit in place of “comma” and adds a tag of the hostname to each extension/trunk in the buttons file, so as to display the associated extensions, trunks and destinations of each Com.X in a separate section.

The script then copies both files to the /etc/fop2/ folder on the central server.

As an example configuration, each extension or destination in the buttons files on the central server should look something like below:

Notice the group field that has been added by the fop2_handler.sh script, everything else was present in the file before processing by the script.

FOP2 Users

Much like the buttons file, each Com.X automatically generates a /etc/fop2/fop2_comma_users.cfg file. This file defines which users will be allowed access to FOP2 and which features they will be authorized to access.

The fop2 handler.sh script also edits this script, to contain the host name of the system, before copying this file to the /etc/fop2/ folder on the central FOP2 server (server1).

The fop2 users file defines an associated buttons file, this too is edited by the fop2handler.sh script to replace the “comma” in fop2_comma_buttons.cfg with the hostname of the system.

A sample of this file, as it should appear on the central Fop2 server is shown below:

The above shows access for user 7000 only, using the password “2222” to log in.

Remote Server Public Keys

In order to copy their Fop2 buttons and users configuration files on to the central server (server1) each distributed server needs to have a public key generated and added to the authorized_keys file for root access on the central server.

First, public keys need to be generated on the remote server systems. To do this, access the terminal of server2 and issue the command: “ssh-keygen -trsa”. This will generate the file /home/comma/.shh/id_rsa.pub.

Less or cat this file, and copy it's contents.

Then, open a terminal session on server1. Log in as the root user “sudo su”, and navigate to the /home/root/.ssh/ folder. Create a file named authorized_keys or edit the same file if it already exists. Using nano (rather not jed, since jed struggles with line breaks) copy the contents of the id_rsa.pub file on server2 to a new line in /home/root/.ssh/authorized_keys.

It may then be necessary to restart ssh. Once the central server has the public key of the distributed server stored in authorzied_keys, the remote server should be able to copy files to the central server without the central server requesting a password.

Fop2handler.sh

The fop2handler.sh script needs editing only to insert the correct ip address of the central server.

It can be stored and run from any convenient location on the distributed Com.X system (server2). The script should be run as the comma user. This script should be run manually after making any configuration changes on the distributed systems, particularly the adding and removing of trunks, extensions and destinations.

In order to run the script, copy it to the appropriate location and make it executable by “chmod +x fop2handler.sh”. The file can then be run from the same location using “./fop2handler.sh” or in the same manner but explicitly stating the file path.

Fop2.cfg

Finally, on the central server (server1) the new configuration files of all the distributed servers need to be included in Fop2.To do this, simply include the users file of each distributed system in /etc/fop2/fop2.cfg