...

This section describes shell tools required for the deployment management of the system. All these tools are shipped with part of the JeraSoft Billing distributive. You In order to use the tools you will need either SSH or direct access to the server in order to use them. Please notice that most console. Some of the given tools require root  access and show inline help when running without argumentspermissions to run.

...

Requirements Checker

The tool is aimed to check minimal requirements and security recommendations at of your server before and after installation. 

<VCS<APP_PATH>/bin/system/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:

...

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.

...

...

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 managing the JeraSoft Billing management of System Services. It allows to correctly start, stop , get status of the and perform other actions over various JeraSoft Billing Services such as RADIUS Server, SIP Server, Calculator, etc.

<VCS<APP_PATH>/bin/system/service <COMMAND> [<service-name>] <action> [<options>]

The tool should be run under root or vcs user.  Service manager takes 2 arguments:

...

<service-name>

...

<action>

...

Action to perform, one of the following:

• start - start the service
• stop - stop the service
• restart - stop and then start the service
• reload - force config re-read without restart
• status - return current status of the tool

Additionally, you may pass the next options:

...

--path=<path>

...

--user=<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.

start

stop

restart

reload

status

all-start

all-stop

all-status

Usage Examples

...

Code Block
language bash title Restart RADIUS Server
<VCS<APP_PATH>/bin/system/service restart bbradiusd restart

Code Block
language bash title Start Files Downloader
<VCS<APP_PATH>/bin/system/service start files_downloader start

Code Block
language bash title Get status of SIP Server Start all required System Services
<APP<VCS_PATH>/bin/system/service bbsipd status

Panel
borderColor #ffffb3 bgColor #ffffb3 borderWidth 2px
Attention The tool also complies with LSB Init Scripts standard. It allows analyzing exit code of each action in case of automated usage.

all-start

Cluster Manager

The tool is used to manage clustersnodes in the cluster deployment. It allows to init initialize the cluster, add and promote a slave a new node, promote redundancy to master, etc. 

<VCS<APP_PATH>/bin/system/cluster <command><COMMAND> [<options>]

The tool requires "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 permissions. The list of arguments and other requirements depend on the command used. Please refer to the below table for a summary and respective sections for details.

status

init-master

init-slave

promote

sync-files

remove-node

Cluster Status

The command shows Cluster Status, including all nodes with their roles, IP addresses, current lag to Master, and overall status.

<APP_PATH>/bin/system/cluster status

The command can be executed on the Master in order to get the most detailed information about the cluster:

Image Added

Alternatively, the command can be executed at any other node - in this case, only the status of the connection between this particular node and the Master will be shown.

If any node failed and has been disconnected from the cluster it will be shown like this:

Image Added

In this case, you have to re-check failed node, fix it and then return to the cluster using the "init-slave" command.

Init Master

The command is run on Master and used for Master to configure its parametersthe initial configuration of the Master Node.

<VCS<APP_PATH>/bin/system/cluster init-master --ip=<IP-of-master>ADDRESS> [<extra-options>]<options>]

Command has to be executed on the Master node and requires root permissions. The following options are supportedThis command may require additional options:

<IP-

ADDRESS>

--ssh-port=<port>

22

--pg-data=<path>

autodetect

--vcs-path=<path>

<VCS_PATH>

...

Init Slave

The command is run on the Master and used for:is used to add a node to the cluster. There are different contexts when it is required:

• First-time deployment of the cluster
• Addition of a new slave node to the cluster
• Addition of the
• 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 after failover.

<VCS<APP_PATH>/bin/system/cluster init-slave --ip=<IP-of-slave>ADDRESS> [<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:

<options>]

Command has to be executed on the Master node and requires root permissions. The following options are supported:

<IP-ADDRESS>

--role=<role>

redundancy

--

--ip=<ip>

none

ssh-port=<port>

22

--ssh-

user=

<user>

jerasupport

--pg-data=<path>

--vcs-path=<path>

<VCS_PATH>

--role=<role>

redundancy

...

autodetect

Promote  to Master

The command is run on the Slave and used to promote the current Slave Redundancy node to Master. 

<VCS<APP_PATH>/bin/system/cluster promote

Command has to be executed on the Redundancy node and requires root permissions. Reporting node can be used as a last resort if there are no Redundancy node alive. There are no options required.

After the promotion is performed, all required System Services will be started on the current node (new master)The command is used for failover. After you fix the old Master, you may add it as a new Slave using the "init-slave" command.

...

Sync Files

The command is run on the Slave and used to synchronize files sync data and application files from the Master. The command is mostly used in crontab for auto-sync.

<VCS<APP_PATH>/bin/system/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

Command has to be executed on the Redundancy node and by default, it is added to the crontab for automatic synchronization.

Remove Node

The command may be run on any node and used to get status of the cluster. The command is used to remove a node from the cluster.

<VCS<APP_PATH>/bin/system/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. 

...

remove-node <IP-ADDRESS>

Command has to be executed on the Master node. The node in question shouldn't have any active database replication. The following options are supported:

<IP-ADDRESS>