Docs for all releases
Page History
...
This section describes shell tools required for management of the system at the very system level. All these tools are shipped with the VCS JeraSoft Billing 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 the given tools require root access and show inline help when run running without arguments.
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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. |
...
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
To free our clients from confusion while trying to indicate a path to VCS JeraSoft Billing system, we introduce the <VCS_PATH> variable that differs depending on VCS the JeraSoft Billing version:
The example is as follows: |
Requirements Checker
The tool is aimed to check minimal requirements and security recommendations at your server before and after installation.
...
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:
- Before installation of the VCS JeraSoft Billing to check minimal hardware and software requirements. At this stage, you may download the tool separately from the VCSJeraSoft Billing.
- After installation of the VCS JeraSoft Billing to check security recommendations. Usually, you need to tune your firewall settings according to the VCS JeraSoft Billing First Steps.
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
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 JeraSoft Billing Services. It allows to correctly start, stop, get status of the VCS JeraSoft Billing Services as RADIUS Server, SIP Server, Calculator, etc.
...
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 a list of the services at your system. |
<action> | Action to perform, one of the following:
|
Additionally, you may pass the next options:
| Option | Description |
|---|---|
--path=<path> | Specify the |
| JeraSoft Billing location. Only if different from <VCS_PATH> | |
--user=<user> | Specify user the |
| JeraSoft Billing runs under. Only if different from "vcs". |
...
For your convenience there are some examples below:
...
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
The tool also complies with LSB Init Scripts standard. It allows to analyse analyzing exit code of each action in case of automated usage. |
...
The tool is used to manage clusterclusters. It allows to init the cluster, add and promote a slave to master, etc.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<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.
...
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 initialisationinitialization of the cluster;
- addition of the new slave node to the cluster;
- addition of the old master to work as a slave after failover.
| Code Block | ||
|---|---|---|
| ||
<VCS_PATH>/bin/cluster init-slave --ip=<IP-of-slave> [<extra-options>] |
...
- 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 this 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.
| Code Block | ||
|---|---|---|
| ||
<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.
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
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 synchronise files synchronize files from the Master. The command is mostly used in crontab for auto-sync.
| Code Block | ||
|---|---|---|
| ||
<VCS_PATH>/bin/cluster sync-files |
During initialisation of initialization of the cluster, the 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.
| Code Block | ||
|---|---|---|
| ||
<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:
| Code Block |
|---|
[ 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 synchronisation delaysynchronization delay.
| Code Block |
|---|
[ 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 |
...
| Code Block |
|---|
the row: Master (master ip): NOT AVAILABLE |
It's a normal behaviourbehavior. 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 synchronization (NOT-in-sync) with the Master, you need to re-initialiseinitialize.
Overview
Content Tools