Docs for all releases
View User Guide 3.26 or visit our current documentation home page.
This section describes shell tools required for the deployment management of the system. All these tools are part of the JeraSoft Billing distributive. In order to use the tools you will need either SSH or direct access to the server console. Some of the tools require root permissions to run.
Important!
Please use these tools only if you have a clear understanding of what you are doing. Misuse of the tools may cause improper functioning of the system.
Attention
Please note, for simplification we introduced <APP_PATH> variable that refers to the JeraSoft Billing application files location. This location may differ, but typically it is "/opt/jerasoft/vcs". So whenever you see an example with path like "<APP_PATH>/bin/system/cluster" it means "/opt/jerasoft/vcs/bin/system/cluster".
Requirements Checker
The tool is aimed to check minimal requirements of your server before installation.
<APP_PATH>/bin/system/setup-checker
The tool requires root permissions and takes no arguments. It should be executed before installation of the system in order to check minimal hardware and software requirements.
Attention
The tool checks only minimal requirements. Real hardware requirements highly depend on your traffic and deployment model.
Safety Checker
The tool is aimed to check configuration of the main server settings after installation.
<APP_PATH>/bin/system/security-checks
The tool takes no arguments. When executed it performs numerous checks for the correctness of the network and server configuration.
Services Manager
The tool is used for management of System Services. It allows to correctly start, stop and perform other actions over various JeraSoft Billing Services such as RADIUS Server, SIP Server, Calculator, etc.
<APP_PATH>/bin/system/service <ACTION> [<service-name>] [<options>]
The tool should be run under root or vcs user. The tool typically takes 2 arguments – action to perform and related system service. Actions prefixed with "all-*" do not require service name and operate over all services.
Action | Description |
---|---|
start | Start System Service Takes "--wait" option in order to wait and exit only when service finishes its execution. |
stop | Stop System Service |
restart | Stop and then start System Service |
reload | Send reload (HUP) signal to the System Service (forces reload of settings, connections, etc) |
status | Show current status of the System Service |
all-start | Start all required System Services (list of services varies depending on the role of current node in the cluster) |
all-stop | Stop all running System Services |
all-status | Show status of all System Services on the current node |
Usage Examples
<APP_PATH>/bin/system/service restart bbradiusd
<APP_PATH>/bin/system/service start files_downloader
<APP_PATH>/bin/system/service all-start
Cluster Manager
The tool is used to manage clusters. It allows to init the cluster, add and promote a slave to master, etc.
<VCS_PATH>/bin/cluster <command> [<options>]
The tool requires "root" permissions. Cluster Manager takes command as a mandatory argument and additional options. Some of the 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.
Init Master
The command is run on Master and used for Master to configure its parameters.
<VCS_PATH>/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 the master system | autodetect |
--vcs-path=<path> | Path to the JeraSoft Billing on Slave | <VCS_PATH> |
Master: Add new Slave
The command is run on the Master and used for:
- first-time initialization of the cluster;
- addition of the new slave node to the cluster;
- addition of the old master to work as a slave after failover.
<VCS_PATH>/bin/cluster init-slave --ip=<IP-of-slave> [<extra-options>]
This command encapsulates 4 sub-commands:
- configuration of the Master to ship replication logs (
init-master
) - configuration of the Master to accept connections from the Slave (
init-master-access
) - configuration of the Slave to receive replication logs (
init-slave
) - show status of the cluster (
status
).
Each of these 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 the slave system | same as master |
--vcs-path=<path> | Path to the JeraSoft Billing on Slave | <VCS_PATH> |
--role=<role> | Role of the secondary system. Could be [redundancy or reporting] | redundancy |
Slave: Promote to Master
The command is run on the Slave and used to promote the current Slave to Master.
<VCS_PATH>/bin/cluster promote
The command is used for failover. After you fix old Master, you may add it as a new Slave using "init" command.
Attention
In case when you have more than 2 nodes in the cluster, you need to re-init all other slaves from this new Master.
Slave: Sync Files
The command is run on the Slave and used to synchronize files from the Master. The command is mostly used in crontab for auto-sync.
<VCS_PATH>/bin/cluster sync-files
During initialization of the cluster, tool adds this command to the crontab (/etc/cron.d/vcs-cluster) at the Slave node.
Cluster Status
The command may be run on any node and used to get status of the cluster.
<VCS_PATH>/bin/cluster status
When the command is run on the Master, it shows the 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 the command is run on the Slave, it shows the type of the node and synchronization 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 normal behavior. 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 synchronization (NOT-in-sync) with the Master, you need to re-initialize.