BT Call Server Scripted Install

Solution Integration > PBXs > BT Call Server > Installation > Standard Server

BT Call Server Scripted Install

Important_icon

Standard Server Scripted Installs are only supported from version 4.1.x or later.

The system MUST have full internet access before running the install script.

It will use the OS package manager (DNF) to pull in all the required software packages.

The script WILL FAIL without internet access.

If a proxy is required for internet access, please see: Web Proxy Configuration

Once you have a new clean staged Linux OS created.

Download the latest package file from the BT Extranet (eg. BTCallServer-Package-Build-xx.zip), then extract the zip file.

Copy the “BTCallServer-4.x.x.tar.gz” and “install.sh” files to the newly deployed and staged Linux OS.


		Any method you are comfortable with can be used to copy the files onto the Linux OS.

One method we use is a tool called WinSCP (https://winscp.net/eng/download.php)

Download the latest version of WinSCP and install it.

Open WinSCP once installed and provide connection details to the Linux OS (Use the “iptadmin” user)

Scripted_install_01

Browse your local PC on the left and select both the supplied files (as seen below)

Then click on “Upload” and Select “OK” (Confirm the upload path is /home/iptadmin )

Scripted_install_02

Once the files have been copied to the system, you can disconnect and close WinSCP.

The files should now be in the “iptadmin” user home directory /home/iptadmin

Using any terminal connection application (eg PuTTY), connect to the Linux OS using the “iptadmin” user to connect.

You will be in the /home/iptadmin directory by default once connected.

Now make the “install.sh” script executable and ensure it is converted to unix format

(Unix format is only done as a precaution, the file is usually already in the correct format)

chmod +x install.sh

dos2unix install.sh

Scripted_install_03

Important_icon

If you are able to take a snapshot of the VM before running the scripted install, it is a good idea to do so now.
This will allow you to revert back to a clean VM snapshot if something goes wrong during the install.

However, please note that ALL snapshots MUST BE REMOVED once fully deployed.
Snapshots are generally intended as a short-term safety net, not something to leave on production VMs long term,
as they can have a detrimental impact on VM performance over time.

The install script expects 2 additional arguments:

Usage: install.sh [azure|vm] [‘redundancy user password’]

Use “azure” for any install in Azure and for any other install the choice should be “vm” for the first argument.

The second argument expects a complex password. Provided between single quotes (to preserve the password given literally).

This password is used for Redundancy setup between two systems.


		The password provided MUST be the same for any two systems that will be deployed and require redundancy setup between them.

The password is never used interactively by any user, but rather in the backend system.

Once you are ready to kick off the deployment, run the following:

sudo ./install.sh vm ‘PASSWORD’

(For SUDO prompt, provide the password for the “iptadmin” account)

Scripted_install_04

This will start the full installation of the BT Call Server with all the required packages and will build the included Asterisk package from source.

This process can take some time to complete.

Once the deployment is complete you should see the below at the end.

There is also an “Install-Log-[date|time].log” generated when the script is run. (The log file is output to the same path as the script file)

If there are any problems with the deployment you can check the log for possible reasons.

Scripted_install_05

Once the BT Call Server deployment is complete, reboot the system with the below command.

sudo reboot

The scripted install is now complete.

The same CLI configuration scripts used during the VA First Launch are available on the system once the scripted install is complete.

Important_icon

Network configuration behaviour varies depending on your environment.
In some cloud-hosted environments, IP addresses that appear as DHCP within the OS are actually managed externally
For example, Azure static IPs are assigned through the Azure portal and will show as DHCP inside the OS.
Modifying the network configuration in these environments may cause connectivity issues.

If you are running a standard VM on a local hypervisor and need to change the IP address,
it is safe to use the network configuration tool directly. Covered in: VA First Launch

Continue with the remaining system setup via the Web-UI