Archives

The error you are seeing in the Asterisk CLI is due to an app not properly handling concurrent use of the AstDB (SQLite 3 database). When synchronizing the AstDB HAAst will briefly lock the database (with a SQL lock), at which point apps should queue their commands until the lock is released.

Most properly designed apps respect concurrency by checking for the lock, then either blocking or retrying for a period of time, to acquire the lock. An overly simplistic application might not check for a lock, and simply report an error (“database is locked”) following an attempt to write. We have seen this error before with FreePBX and a couple of open source Asterisk add ons.

Although the proper solution involves asking the app developer to correct their code, we realize that some developers have no interest in doing so (or become hostile if you suggest anything is wrong with their code). So until the developer in question fixes their code, we do offer a workaround.

Create an Asterisk pre-start event handler (/usr/local/haast/events/asterisk.start.pre) in HAAst containing the following code:


#!/bin/bash
sqlite3 /var/lib/asterisk/astdb.sqlite3 “PRAGMA journal_mode=wal”;


This will enable the “WAL” feature of SQLite3 – which effectively prevents reader and writer processes from locking each other out of the database. You can also issue this command from any bash prompt and you should see the response “wal”. If you don’t see this respnose, repeat the command every 10 seconds until “wal” is returned. (The command can fail if the database is already locked).

A summary of common exit codes and their causes:

• 255 – Likely a connection problem to the remote host. You should be able to resolve this by checking the IP address / fqdn of the remote host.
• 107 – Protocol error or unexpected response. You may have to work with Telium support to trace the cause (if this is intermittent then diagnosing can require many steps)
• 23 – Error during transfer. You should be able to resolve this by checking the file/directory being synced really exists on the source.
• 10 – RSync server unreachable. You should check the ensure the RSync service is running on the remote host, and that the remote host is reachable.
• 5 – RSync file permissions error. You should check to ensure rsync config files holding passwords are mode 600.

The HAAst installation guide provides guidance on how to enable debugging to capture more information. The specific settings, and location of log files, varies by HAAst version. If you need further help capturing and understanding debug information please contact Telium support (you will need an active maintenance agreement for the support team to assist you)

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 HAAst 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.haast.secret file has the wrong permissions. Please modify the permissions of this file as follows:

Quote:
chmod 600 /etc/ rsync.haast.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@telium.io for further details.

Asterisk 16 has numerous architectural changes that impact connected products. Our development team has implemented Asterisk 16 compatibility, but will not release thr code until Asterisk 16 has stabilized, and we see companies implementing Asterisk 16 in production.

As of March 2019 Asterisk 16 is not widely placed into production yet, and so we advise you to NOT upgrade to Asterisk 16 at this time. Since you are a registered HAAst user you are welcome to download a pre-release version of HAAst which supports Asterisk 16.

Asterisk 16 has undergone some significant changes since initial release, and until the product has stabilized we do not recommend placing Asterisk 16 in production.[/i][/color]

HAAst depends on Asterisk to report the number of calls in progress. From the Asterisk CLI issue the command “core show calls” and you will see how call are calculated/reported.

If you are running a configuration generator (eg: PIAF, FreePBX) then you will discover that the configuration generator triggers automatic internal (local) calls every X seconds to handle time variable updates and other checks. (Not a good design as they are loading up your PBX with background “calls”). There have been an number of discussions about this topic (on various websites) and causing a lot of frustration with users who are seeing their PBX being loaded up with CPU/disk activity to do little more than update a variable. Since some product vendors only have PHP development experience they must solve every problem using PHP scripts, call files, etc. Other vendors are quite sophisticated (eg: code in C++/C) and their products (eg: XCally) use minimal system resources.

If you are running only Asterisk then check for channels not being released. (There are some documented bugs in Asterisk – depending on the version you are running).

HAAst is correctly NOT failing over because your PBX is operational and in-progress calls remain up. From HAAst’s perspective your PBX has reached capacity (but is still operational).

First of all, be careful you don’t try to solve a security problem with an HA solution. Even if HAAst fails over to the other node, then that other node will subsequently be subject to those same DoS attacks and it will fail back, etc. So HA failover is not a solution. If you want HAAst to failover once your number of RTP ports in use reach a threshold you set, you can setup a HAAst sensor to monitor the number of RTP ports in use and factor this into each node’s health score. Then, HAAst will failover once the threshold you set for that sensor has been reached.

Second, a more appropriate solution is to block the DoS attacked. Have a look at our Security for Asterisk product (http://www.telium.io/?secast) which is designed to block DoS attacks (and a lot more).

We would be happy to SSH into your hosts to help with configuration.

Our support machines have pre-installed VPN clients for the most popular protocols: Microsoft Windows protocols (PPTP/L2TP/IPSec/IKEv2), and shared Cisco VPN protocols.

If you chose not to use one of these protocols, or you require that we install a VPN client that is locked to your VPN concentrator address, then we must build a virtual machine for our support techs to use when connecting to your system. Our support techs cannot (and may not) install any software on their machines, in order to protect our computing environment.

If you cannot use one of the pre-installed VPN protocols above, and you cannot port forward SSH from your public IP to your nodes, then we will have to charge you an additional 2 hours of support time to build and maintain a support VM dedicated to your environment. We will also archive this VM (while your maintenance agreement is active) to ensure we can continue to support you going forward.

See FAQ 10042 for additional information: https://telium.io/faq1042

We would be happy to SSH into your hosts to help with configuration.

Our support machines have pre-installed VPN clients for the most popular protocols: Microsoft Windows protocols (PPTP/L2TP/IPSec/IKEv2), and Cisco VPN protocols (IPSec, PPTP/MPPE, L2TP/IPSec).

If you chose not to use one of these protocols, or you require that we install a VPN client that is locked to your VPN concentrator / host, then we must build a virtual machine for our support techs to use when connecting to your system. Our support techs cannot (and may not) install any other software on their machines, in order to protect our computing environment.

If you cannot use one of the pre-installed VPN protocols above, and you cannot port forward SSH from your public IP to your nodes, then we will have to charge you an additional 2 hours of support time to build and maintain a support VM dedicated to your environment. We will also archive this VM (while your maintenance agreement is active) to ensure we can continue to support you going forward.

See FAQ 10042 for additional information: https://telium.io/faq1042