Archives

You have a number of issues:

1. The following error in your event log indicates that HAAst is unable to successfully start Asterisk (and/or FreePBX services).


Fri Aug 10 06:47:42 2018, 00000721, E, System Command, Failed to start Asterisk (start) wrapper. Run result 3; exitcode 0


What have you set your ‘distribution’ key to in the [asterisk] stanza of your haast.conf file? Are you running the fully open source version of FreePBX or proprietary (FreePBX ‘distro’)? If open source, on what Linux distro and architecture?
This error indicates Asterisk is not being started (properly), and also explains why you aren’t getting an AMI connection error. (Error 0 means HAAst could not establish a connection to the AMI)

2. The follow errors in your event log suggest your PeerLinkServer is listening on the same IP that you are using for the dynamic HAAst created interface:


Fri Aug 10 06:46:56 2018, 00001901, I, Peer Link Server, PeerLinkServer listening on 12.34.56.78:3002
Fri Aug 10 06:47:10 2018, 00010106, I, NIC, IP address ‘12.34.56.78’ added to physical NIC device ‘eth0’ as new virtual NIC device ‘eth0:haast’


Have you obfuscated the IP addresses in your posting? If not you will need to fix your IP addresses (which may also prevent Asterisk from Starting depending on the FreePBX settings).

3. The reason you see snoozing messages relates to the promotesnoozetime and demotesnoozetime keys in the [cluster] stanza of haast.conf. This has nothing to do with your problem – in fact I suggest you leave those settings at default until you understand HAAst a little better. As background, these settings prevent the cluster from flipping back and forth in the event that it takes Asterisk some time to stabilize. (See https://telium.io/topic/manual-failover-leads-to-brief-dual-active-contention/ for more info).

4. HAAst does not interact with firewalld or iptables, so that symptom isn’t directly related to HAAst. However, beware that Songoma calls fail2ban a ‘security system’ – when in fact it’s not. Actually Digium warns companies NOT to use fail2ban as a security system (see https://telium.io/topic/i-use-fail2ban-why-do-i-need-secast/ for more info). I suspect FreePBX is trying to start fail2ban and that is giving you the error messages. If you are anything but a small/SOHO business have a look at the SecAst pages on this site to understand the different between SecAst and fail2ban.

With more info we can provide more suggestions but hopefully that clarifies the meaning of the messages. I suspect all of the above relate to starting FreePBX.

• This reply was modified 5 years, 3 months ago by WebMaster.

First you must enable insecure updates on your Windows DNS server as follows:

1. Click Start, point to Administrative Tools, and then click DNS.
2. Under DNS, double-click the applicable DNS server, double-click Forward Lookup Zones
3. Right-click the applicable zone.
4. Click Properties.
5. In the Dynamic updates box, click to allow insecure updates
6. Repeat the above for the associated reverse lookup zone
7. Click OK.

Next, you need to add some code to your Asterisk pre-start event handler to update the DNS entries:


#!/bin/bash
# Update DNS server with this IP 192.x.x.x address
HOST=pbx.mydomain.local
IP=$(ip addr | grep 192 | awk ‘{print $2}’ | cut -f 1 -d/)
TTL=600
SERVER1=192.168.0.2
SERVER2=192.168.1.2
#—————————————————————————-
NSU=/tmp/nsupdate.data
echo “server ${SERVER1}” > ${NSU}
echo “update delete $HOST A” >> ${NSU}
echo “update add $HOST ${TTL} A ${IP}” >> ${NSU}
echo “update delete $HOST PTR” >> ${NSU}
echo “update add $HOST ${TTL} PTR ${IP}” >> ${NSU}
echo “send” >> ${NSU}
logger “asterisk.start.pre updating DNS for host ${HOST} to IP ${IP} on server ${SERVER1}”
nsupdate -v ${NSU}
echo “server ${SERVER2}” > ${NSU}
echo “update delete $HOST A” >> ${NSU}
echo “update add $HOST ${TTL} A ${IP}” >> ${NSU}
echo “update delete $HOST PTR” >> ${NSU}
echo “update add $HOST ${TTL} PTR ${IP}” >> ${NSU}
echo “send” >> ${NSU}
logger “asterisk.start.pre updating DNS for host ${HOST} to IP ${IP} on server ${SERVER2}”
nsupdate -v ${NSU}
rm -f ${NSU}


Some versions of FreePBX may contain tables with invalid/problematic schemas (possibly not even valid SQL but MySQL allows it).

HAAst is complaining that it can’t sync a table without a unique index. (Although this is likely an unimportant table as Sangoma may be cleaning up their tables slowly). The best solution is to wait for an update to FreePBX which fixes the table.

If you need an immediate fix please contact Telium technical support for further assistance and workarounds. When Telium performs the installation for the customer, we might modify the MySQL table, modify PHP code, or modify MySQL tools for synchronization. Customers who perform their own installation need to thoroughly test synchronization for moving to production.

Before you perform any changes to resolve this problem ensure you have a bare metal backup, and perform testing on a staging system.

HAAst fully supports what you are trying to do, and there are many ways to accomplish this. We have many customers that have split their cluster(s) between on-premise and in-cloud.

On the AWS side it’s easy. AWS is certified compatible with Telium’s products, so nothing has to be done to allow the instance to move between hosts, regions, etc. You can use ‘hardware fingerprint’ activation and that will tie into your AWS instance identification.

On the data center side you have several options (see http://www.telium.io/activation). The easiest option is to use the cloud license option and you’re set. We understand that some users don’t want to use the cloud for activation or any external service, so then you could use the USB dongle with USB over ethernet software (see https://telium.io/topic/usb-license-on-hyper-v-guest/ for examples) and the dongle is always accessible to all of your VM hosts. You could also use our VLS product but that’s overkill for just 3 PBX’s.

• This reply was modified 5 years, 3 months ago by WebMaster.

HAAst performs all NIC control using the Linux system API; it does not use network configuration scripts (such as ifcfg-ethX, ifup, ifdown, etc). These scripts you are referring to are Linux distribution specific, and are ignored by HAAst. All configuration of a shared VoIP NIC is accomplished in the [voipnic] stanza of the haast.conf file.

In order to perform other actions on the PBX at the time of promotion/demotion (i.e. becoming the active or becoming the standby node), you need to use the HAAst event handler system. For example, if you wanted to change the default route of the PBX when it is promoted, you could create a file called /usr/local/haast/events/asterisk.start.pre which contains:


#!/bin/bash
# Delete old default route
ip route del default via 172.31.254.1 2>&1
# Add new default route
ip route add default via 172.31.253.1 2>&1


And if you wanted to switch the default route back when the PBX is demoted, you could create a file called /usr/local/haast/events/asterisk.stop.post which reverses these statements. You can place any code you like in the event handler, but it should complete quickly (ideally < 5 seconds), so if you need to start long-running executables from the event handler be sure to fork them in the event handler code. For example, if you wanted to deleted all temporary files (which can run for several minutes) when the node becomes standby, your event handler file would contain (notice the ampersand which forks the command):

#!/bin/bash
rm -rf /tmp &


If you want to open/close ports in a firewall, control virtual machine functions, etc. then the event handler system is the right way to accomplish this. Just be sure to fork each command, or fork a single bash script which serializes those commands if any of these commands can run for an extended period of time.

Please note that event handlers are only available in the Commercial Unlimited edition of HAAst. See the EDITIONS tab of the HAAst web page to see what functionality is available in each HAAst edition.

We can definitely help.

Although we don’t list Asterisk beta’s as officially certified, our engineering group is regularly testing and certifying newer Asterisk versions. (Probably not Beta’s however)

If you can provide SSH access to your system our engineering group will ensure HAAst is working with your specific code. Since you are already running commercial editions of HAAst, we will ensure HAAst works with your Beta at no charge.

The root cause of your problem is a regression (bug) in your Linux distro. There have been similar Linux regressions noted by Digium in the past (eg: https://issues.asterisk.org/jira/browse/ASTERISK-15603)

The solution is to use the HAAst event handler to create the missing directory for Asterisk, before Asterisk even starts.

Create the file /usr/local/haast/events/asterisk.start.pre with the following contents:


#!/bin/bash
If [ ! -d /var/run/asterisk ] ; then
mkdir /var/run/asterisk
chown asterisk:asterisk /var/run/asterisk
fi

and set the permissions on /usr/local/haast/events/asterisk.start.pre to 550:


chmod 550 /usr/local/haast/events/asterisk.start.pre

Note: The event handler system (including use of the asterisk.start.pre file) is restricted to the Commercial Unlimited edition of HAAst only.

Please note that in mid-2018 Telium is launching an updated license option, which no longer requires activation or ties your installation to your hardware. You will have several license options available at the time of generating your license request.

See http://telium.io/activation for activation options.

I should also point out that during the past 10 years three other companies have released HA products for Asterisk. The products didn’t work well, and once their customers realized all of the conditions / use cases which their HA software could not handle (and the resulting outages) they switched to HAAst. All three of those companies are now out of business / disappeared, or their HA products have been discontinued.

You’ll see new HA products pop up on occasion, because you can add ‘HA’ type open source packages in just a matter of hours. But there are no open source packages for application level HA (that’s up to the application developer). Adding HA level code at the application level (or trying to add it to file level HA packages) is a massive undertaking (measured in person-years of development, not hours).

HAAst has been on the market since 2005 and has been growing in capabilities ever since!

Some Linux distributions allow you to configure routing information along with the NIC (in the same NIC configuration file); however, this is misleading – in fact, newer Linux distros no longer allow this practice. Routing information has nothing to do with the NIC. Routing information (eg: default gateway / subnet gateway) is added to the routing table not the NIC.

If you would like to add a route to the routing table from a terminal window then enter a command like:


route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.1


If you would like this route to persist between reboots you would have to enter this information into a config file/script. If you are using the Commercial Unlimited edition of HAAst then you can add the above line to the pre-start event handler /usr/local/haast/events/asterisk.start.pre This event handler will run before the vNIC is brought up so the route will be present when needed. If you like you can also delete this route by adding a line to the the post-stop event handler /usr/local/haast/events/asterisk.stop.post

If you are not using the Commercial Unlimited Edition of HAAst, then you will need to find the most suitable place for these routing rules (which varies considerably between Linux distributions). In your case I suspect you are using a RedHat flavour of Linux, so you could create a file called /etc/sysconfig/network-scripts/route-eth0 with:


default 192.168.0.1 dev eth0
10.10.0.0/24 via 10.10.0.1 dev eth0
172.16.1.0/24 via 192.168.0.1 dev eth0


but you should check the guides for your Linux distro to confirm the best place to place ‘persistent routes’. If you are looking for routes to be added/deleted based on HAAst events then you should use the HAAst event handler instead.