Telium Support Group

Some additional exit codes and their causes:

255 – Likely a connection problem to the remote host. Check the IP address / fqdn of the remote host
23 – Error during transfer. Check the file/directory being synced really exists on the source.

The first error means that the rsync process is not running. Please ensure rsync is installed, running, enabled, and configured as per the PBXSync detailed installation guide.

I suspect that you actually solved the first error, since the second error means that rsync is running! But, the second error means that the rsync.pbxsync.secret file has the wrong permissions. Please modify the permissions of this file as follows:

Quote:
chmod 600 /etc/ rsync.pbxsync.secret

After that your sync should work.

At this time HAAst does not have this capability, but a feature request has already been submitted. However, if you are concerned about connectivity between the HAAst node and your SMTP server, or SMTP credentials, then we can help you diagnose this.

From the HAAst node perform the following steps:

1. From a command prompt type “telnet hostname 25”. This connects telnet to port 25 on the server with the name or IP ‘hostname’. Replace ‘hostname’ with the name of the SMTP host you specified in your haast.conf file, and replace 25 with the port you specified in your haast.conf (in the [smtp] stanza)
2. If the TCP connection fails, then you have confirmed a network/routing problem
3. If the TCP connection is established, telnet responds with the message “Connected to SERVERNAME and Escape character is’ ^]’.”
4. Now you can send an e-mail via SMTP protocol. You must use a recipient address for which the connected mail server is responsible (or the message will be refused/discarded)
   
   EHLO test.example.com
   MAIL FROM:
   RCPT TO:
   DATA
   Subject: Testmessage from haast node 1
   (Blank line, press Enter again)
   This is an alert!
   (Blank line, press Enter again)
   .
   QUIT

5. The SMTP server should respond that your message has been accepted. Now wait at the receiving end for your message to appear.

The above assumes that the SMTP server does not require encrypted authentication. If you need help with encrypted SMTP authentication (or session) please contact support@autocommander.aws2.ocg.ca for further details.

License requests go into the general support queue, which means response time for your license will match our general support response times. Our typical response time is 20 minutes, but during times of high demand it may extend as far as 4 hours. (By hour 4 engineering staff are being moved to support desks – so this doesn’t happen often).

If you are a Telium certified OEM/VAR partner then your requests will move to the head of the support queue. If you need USB Dongles sent in advance we recommend you provide at least 2 weeks notice.

The problem most likely was created by changing the FreePBX database username/password on one node and not the other. Changing the FreePBX database username/password does two things: 1. it updates the /etc/freepbx.conf file, and 2. it updates the ‘users’ table in the MySQL ‘mysql’ database.

So although you may be syncing the ‘freepbx’ database between nodes, you are not syncing the ‘mysql’ database between nodes. And you should not try to synchronize the MySQL ‘mysql’ database (which holds the schema as well as user info), unless you are a DBA and really understand what you are doing!

The solution to this problem is very simple:

• Copy the full MySQL database from the working node to the problem node; or,
• Reset the FreePBX user password on the problem node to match the working node; or,
• Don’t sync the freepbx.conf file and set the two nodes to have different passwords

To avoid this in the future either:

• set the FreePBX MySQL user password identically on both systems; or
• leave the default password; or
• don’t synchronize the freepbx.conf file; or,
• sync the ‘mysql’ database (but you have to be sure you understand the implications before doing so) – we don’t recommend this

So the cause and solution to this problem reside completely within FreePBX (HAAst has not malfunctioned in any way).

First of all, AWS Lightsail has hidden access to some features that you will need to make this work, so you will instead need to setup a couple of EC2 instances. Since you want to share a VoIP NIC (shared IP) between nodes, your two nodes must reside in the same region but can reside in different Availability Zones (AZ’s).

Since (in most configurations) each node will have two IP addresses, and each address cannot be in the same subnet as the other (basic routing limitation), you must create 2 subnets within your VPC. If you want your two nodes to reside in separate AZ’s, then you will have to create 2 subnets per AZ (since subnets cannot span AZ’s). You might have to manually ad private IP(s) to NIC(s) in Linux depending on your design. You must then setup a security group encompassing both nodes, which allows SSH traffic into the management IP, and VoIP traffic in/out of the VoIP IP.

And finally you have some choices around how many NIC’s and public addresses your want in your setup. The more you want, the more complex the setup. We have created four basic designs you can chose from (but there are more):

1. Dual NIC, Dual public IP
2. Single NIC, Dual public IP
3. Dual NIC, Dual Private IP, Single public IP
4. Single NIC, Single Private IP, Single public IP.

The first option is the one we normally implement as it is easy to manage, separates traffic across NIC based on traffic type, avoid loss of management connection in case of VoIP IP issues, etc. But this is also the hardest to implement for AWS EC2 novices. As well, setting up routing rules can be a challenge for someone who doesn’t do network management as part of their job. We also prefer only a single VoIP IP (not dual public VoIP IP’s).

The fourth option is by far the simplest (almost trivial) to setup and you won’t have to worry about routing rules, but you will NOT have external access to the management IP’s of your nodes. To work around this you would either have to create a VPN into your VPC, or setup a third host whose sole purpose is to allow SSH relay to the internal hosts (management IP’s). We can also swap public IP’s between nodes if this makes life easier – to ensure continued direct external access to both nodes (but this is painful to use during setup).

Here’s an overview of the four designs:

1. Dual NIC, Dual public IP

2. Single NIC, Dual public IP

3. Dual NIC, Dual Private IP, Single public IP

4. Single NIC, Single Private IP, Single public IP

• This reply was modified 4 years, 9 months ago by WebMaster.
• This reply was modified 4 years, 9 months ago by WebMaster.
• This reply was modified 4 years, 9 months ago by WebMaster.

Once you have received the USB dongle(s) containing your license,

1. Plug each dongle into the appropriate physical machine. (The dongle will have a tag attached showing the machine name, in case you have multiple dongles).

2. From the VMware console edit the virtual machine, and add a new USB device:

3. Select the device name which should be something similar to “Phillips Elite”, and click save. (On some occasions you have to shut down and restart the VM for the hardware to be added).

4. From the VM’s command line, confirm in Linux that the USB dongle is present using the “lsusb” command. Notice the Phillips (NXP) device is present – that is the USB dongle.

5. Telnet to the local PBXSync instance and issue the “license usbdongle” command and follow the steps presented on screen.

• This reply was modified 4 years, 9 months ago by WebMaster.

PBXSync fully supports Asterisk 16.