JeraSoft Documentation Portal
Docs for all releases
This section describes shell tools required for management of the system at the very system level. All these tools are shipped with the VCS distributive. You need to use SSH or direct access to the server in order to run any of these tools. Please notice that most of given tools require "root" access and show inline help when run without arguments.
Important!
Please use these tools only if you have a clear understanding of what you are doing. Misuse of the tools may cause an improper functioning of the system.
The tool is aimed to check minimal requirements and security recommendations at your server before and after installation.
/usr/local/vcs/bin/setup-checker
The tool should be run under "root" permissions without any arguments. When the tool is run it will perform a list of checks and show results for each of them. Use it:
Please Note!
The tool checks only minimal requirements. Real hardware requirements highly depend on your traffic and deployment model.
The tool is used for managing the VCS Services. It allows to correctly start, stop, get status of the VCS Services as RADIUS Server, SIP Server, Calculator, etc.
/usr/local/vcs/bin/service <service-name> <action> [<options>]
The tool should be run under "root" or "vcs" user. Service manager takes 2 arguments:
Argument | Description |
---|---|
<service-name> | Short name of the service. Run the tool without arguments to get list of the services at your system. |
<action> | Action to perform, one of the following:
|
Additionally you may pass next options:
Option | Description |
---|---|
--path=<path> | Specify the VCS location. Only if different from /usr/local/vcs. |
--user=<user> | Specify user the VCS runs under. Only if different from "vcs". |
For your convenience there are some examples below:
/usr/local/vcs/bin/service bbradiusd restart
/usr/local/vcs/bin/service files_downloader start
/usr/local/vcs/bin/service bbsipd status
The tool also complies with LSB Init Scripts standard. It allows to analyse exit code of each action in case of automated usage.
The tool is used to manage cluster. It allows to init the cluster, add and promote slave to master, etc.
/usr/local/vcs/bin/cluster <command> [<options>]
The tool requires "root" permissions. Cluster Manager takes command as mandatory argument and additional options. Some of commands may be run only on Master and others only on Slave. There are two available types of Slave: redundancy and reporting. All extra options for the commands are explained below in the corresponding subsection.
The command is run on Master and used for Master to configure its parameters.
/usr/local/vcs/bin/cluster init-master --ip=<IP-of-master> [<extra-options>]
This command may require additional options:
Option | Description | Default |
---|---|---|
--ip=<ip> | IP Address of the Master server | none |
--ssh-port=<port> | SSH Port at the master server | 22 |
--data=<path> | PostgreSQL data path on master system | autodetect |
--vcs-path=<path> | Path to the VCS on Slave | /usr/local/vcs |
The command is run on the Master and used for:
/usr/local/vcs/bin/cluster init-slave --ip=<IP-of-slave> [<extra-options>]
This command encapsulates 4 sub-commands:
init-master
)init-master-access
)init-slave
)status
).Each of this commands may be performed separately if you know exactly what you need.
This command may require additional options:
Option | Description | Default |
---|---|---|
--ip=<ip> | IP Address of the Slave server | none |
--ssh-port=<port> | SSH Port at the slave server | 22 |
--username=<login> | Login to the slave server | jerasupport |
--data=<path> | PostgreSQL data path on slave system | same as master |
--vcs-path=<path> | Path to the VCS on Slave | /usr/local/vcs |
--role=<role> | Role of the secondary system. Could be [redundancy or reporting] | redundancy |
The command is run on the Slave and used to promote current Slave to Master.
/usr/local/vcs/bin/cluster promote
The command is used for failover. After you fix old Master you may add it as new Slave using "init" command.
In case when you have more than 2 nodes in cluster, you need to re-init all other slaves from this new Master.
The command is run on the Slave and used to synchronise files from the Master. The command is mostly used in crontab for auto-sync.
/usr/local/vcs/bin/cluster sync-files
During initialisation of the cluster tool adds this command to the crontab (/etc/cron.d/vcs-cluster) at the Slave node.
The command may be run on any node and used to get status of the cluster.
/usr/local/vcs/bin/cluster status
When command is run on the Master it shows type of the node and attached Slaves, that are up to date:
[ NOTICE ] Cluster Status ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}' Master (master ip): ACTIVE Redundancy (slave ip): ACTIVE
When command is run on the Slave it shows type of the node and synchronisation delay.
[ NOTICE ] Cluster Status ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}' Master (master ip): NOT AVAILABLE | Activity delay: -00:00:58.393423 Redundancy (slave ip): ACTIVE
Please don't worry if you see the following:
the row: Master (master ip): NOT AVAILABLE
It's a normal behaviour. Instead, please pay attention to "Activity delay" parameter − it shows large values if replication is broken and servers are not in sync.
In case when the Slave is not in synchronisation (NOT-in-sync) with the Master you need to re-initialise.