Archives

Exit code 158 means that HAAst is unable to find the service/executable file needed to control Asterisk. Since you installed Asterisk from source, I assume you are not using any configuration generator (eg: Elastix) as well. If that’s the case then the ‘distribution’ setting in the [asterisk] stanza of the haast.conf file should be set to 2 (Digium Asterisk). Confirm that setting – then proceed to the steps below if the error remains.

Next ensure that you installed an Asterisk service file appropriate for your Linux distribution. Most recent Linux distributions have switched to systemd, which requires you use an asterisk.service file. If you are using an older Linux distribution then you require a SysV / initd style service file.

While Asterisk includes a sample SysV style service file for Asterisk, it might not include a systemd style service file just yet (as of Dec 2016). You can find one by searching the Digium support forums, but here’s an example you can use:


[Unit]
Description=Asterisk PBX and telephony daemon
Documentation=man:asterisk(8)
Wants=network.target
After=network.target
 
[Service]
Type=simple
User=asterisk
Group=asterisk
ExecStart=/usr/bin/asterisk -f -C /etc/asterisk/asterisk.conf
ExecStop=/usr/bin/asterisk -rx ‘core stop now’
ExecReload=/usr/bin/asterisk -rx ‘core reload’
 
[Install]
WantedBy=multi-user.target


Save the above as ‘asterisk.service’ and place it in /etc/systemd/system/ and set file permissions to 755. Don’t add restart directives (like you might find on the internet) since HAAst should be responsible for restarting Asterisk when necessary. You will also have to tell Linux about the new service file with the ‘systemctl daemon-reload’ command (or similar depending on your Linux distro).

If you want to use the SysV / initd style service file that’s ok too, but you’ll need to tell HAAst which style of service file you are using. To do so contact Telium support and we will provide you with details specific to your Linux distribution. (But in general if your Linux distro uses systemd, stick with systemd service files).

You have discovered a problem in FreePBX! When creating the SecAst AMI user account and selecting ‘all’ for permissions in the FreePBX GUI, FreePBX does not actually add the ‘all’ permission. Instead FreePBX adds individual permissions and omits the ‘security’ permission.

Until this is fixed in FreePBX please do NOT create your AMI user account through the FreePBX GUI. Instead modify the manager_custom.conf file to manually insert the credentials. For example, your manager_custom.conf might look like this:


[teliumuser]
secret = teliumpassword!
deny=0.0.0.0/0.0.0.0
permit=172.31.0.0/255.255.0.0
permit=127.0.0.1/255.255.255.0
read = all
write = all
 


Where the username (in [] brackets) and the password (secret) match the values you set in the secast.conf file. If you need further assistance with this workaround please contact support.

Yes – we are able to offer a significantly more accurate GeoIP database; but this is not standard within SecAst. As of March 2016 this option costs $1000 USD, and we would provide you with a much larger GeoIP database and a code which causes SecAst to use this new database instead. This database is certified down to a higher level of accuracy within the city level.

Please contact Telium support if you would like to purchase this option. This option is not listed for sale on our website as this is not commonly purchased. We are also available to help you design alternative security measures using SecAst in case this is not the right approach for you.

UPDATE: Based on feedback this change helped some users, but hurt others. So we’ve created a SUPPORTCODE which you can add to your haast.conf file which will force HAAst to use initd, even if your Linux distribution uses systemd.

Just send an email to support requesting the code, and then HAAst will operate as it did before. Note that you must be running HAAst version 2.3.2.2 or later for the SUPPORTCODE to work.

Given the growing popularity of SystemD (most new Linux distros use it), as of version 2.3.1.15 HAAst changed how it interacts with system services. HAAst now uses SystemD as the default.

More specifically, if HAAst detects that a PBX’s Linux uses SystemD, then it will start and stop services using systemctl. If the PBX’s Linux does not uses SystemD, then HAAst will start and stop services using initd scripts.

If you find that this change broke your system, then the simplest solution is to create a SystemD service file for Asterisk on your system, and remove/rename the initd script for Asterisk (after disabling the Asterisk initd service). Have a look at this topic https://telium.io/search/Can%5C%27t+start+Asterisk+exit+code+158/ for an example asterisk.service file.

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

The problem you are experiencing is most likely due to a PHP caching/optimization program installed in your server. For example, the APC (alternative PHP caching module) has some bugs that will cache an included file and they try to include it again (resulting in a PHP redefinition error, require_once error, etc). For details of the APC bug and possible solutions check out this link: https://pantheon.io/docs/alternative-php-cache/

There are caching modules from other vendors (eg: Zend) with some similar issues. So you may also wish to disable caching of SecAst files since they don’t create much load on a server (relatively static, low volume). This is not a SecAst bug, but future versions of SecAst will try to detect the caching software and work around the issue.

Most Linux distributions are starting to include Qt version 5.7 (as of December 2016) so check available repos (including testing repos) first to ensure it’s not there. If you can find Qt version 5.5 or later as a package it’s best to install from your package manager. Otherwise continue on below.

If you are running Ubuntu you can check this link for a step-by-step guide to installing Qt 5.x: http://sourcedigit.com/19858-how-to-install-qt-5-6-1-on-ubuntu-16-04/

If your system runs headless (i.e. no graphical shell) then you can also modify the Qt installer to run without its GUI as described here:
http://stackoverflow.com/questions/25105269/silent-install-qt-run-installer-on-ubuntu-server

If the above suggestions don’t work, then we recommend you download ‘Qt Creator’ directly from http://www.qt.io This package is overkill, but it does an excellent job of installing everything you need (and more) relating to Qt.

After that you should have Qt 5.7 or later installed, including other Qt dependencies listed in the installation guide.

Instead of relying on FreePBX to recreate the AstDB, you should let HAAst synchronize it. (This is the standard HAAst configuration as of Jan 2016). To have HAAst synchronize the AstDB add an entry like this to the haast configuration:


asteriskdb/description=Asterisk internal database
asteriskdb/type=astdb
asteriskdb/interval=300
asteriskdb/debug=off
asteriskdb/postsynccondition=never
asteriskdb/postsyncruntime=60

If you use the sample Asterisk sync file (sample_files/synchronizations/asteriskconfig.sync.conf) then this will be setup for you automatically.

Warning: Do not try to synchronize this file using ‘file’ type. HAAst must read and write this file using SQL commands or you risk corrupting the file. As well, do not put this file on a DRBD partition, nor put it on a network share if there is any chance of the peer reading/writing this file at the same time.

HAAst also has the ability replicated all keys from the AstDB, or generate new values for keys which must be unique, or leave each node with original values. Please contact Telium support for details on how to configure HAAst to control these keys during replication.

The best way to communicate programmatically with HAAst is through the socket interface. When haast is running it creates a socket in the directory /var/run. This socket looks and acts just like a regular file; you can write to the file and read from the file to command HAAst and gather status information.

To retrieve the status of the cluster via the socket interface, use the ‘getstatus’ command. The pseudocode to do so is as follows:


Open file /var/run/haast.sock as read+write
Read ‘ready>’ prompt from file
Optionally write command ID and newline to file, e.g. ‘id: 123n’
Write get status command and newline to file, e.g. ‘command:getstatus\n\n’
Read response from file
Close file
Parse response


The ID sent can be any string (to uniquely identify the response) but is optional. In general we recommend sending an auto-incremented counter. Once all required parameters (of this command) have been sent, send a second newline (i.e. 2 sequential newline characters) to tell HAAst the command is complete and ready for processing.

The following is the actual output (read) in red color, and input (written) in blue color, from the above pseudo code:

haast socket interface v1.1
ready>id: 123
command:getstatus

id: 123
result: ok
cluster name: Telium
cluster start time: 1459816998033
cluster start time formatted: Mon Apr 4 20:43:18 2016
cluster run duration: 12404571
cluster run duration formatted: 71 days, 13 hours, 42 minutes, 51 seconds
cluster fail over count: 79
local peer name: PBX1 in Waterloo data center wall
local haast state: 4
local haast state formatted: Active
local peer health state: 1
local peer health state formatted: Normal
local asterisk state: 2
local asterisk state formatted: Started
local asterisk connection state: 7
local asterisk connection state formatted: Logged in
local start time: 1464643147663
local start time formatted: Mon May 30 17:19:07 2016
local haast run duration: 2740022
local haast run duration formatted: 15 days, 17 hours, 7 minutes, 2 seconds
local fail over count: 11
local previous fail over timestamp: 1465102805740
local previous fail over timestamp formatted: Sun Jun 5 01:00:05 2016
local previous fail over cause: 2
local previous fail over cause formatted: Dual standby peer contention detected
local previous haast state: 3
local previous haast state formatted: Standby
local to remote peerlink connection state: 7
local to remote peerlink connection state formatted: Up
remote data available: 1
remote peer name: PBX2 VM in Mississauga data center
remote haast state: 3
remote haast state formatted: Standby
remote peer health state: 1
remote peer health state formatted: Normal
remote asterisk state: 4
remote asterisk state formatted: Stopped
remote asterisk connection state: 4
remote asterisk connection state formatted: Connect failed
remote start time: 1464643407951
remote start time formatted: Mon May 30 17:23:27 2016
remote haast run duration: 2739761
remote haast run duration formatted: 15 days, 17 hours, 2 minutes, 41 seconds
remote fail over count: 8
remote previous fail over timestamp: 1465102804675
remote previous fail over timestamp formatted: Sun Jun 5 01:00:04 2016
remote previous fail over cause: 23
remote previous fail over cause formatted: Local peer automatic demotion request
remote previous haast state: 4
remote previous haast state formatted: Active
remote to local peerlink connection state: 7
remote to local peerlink connection state formatted: Up
ready>

To learn how to use the HAAst socket interface you can use the ‘socat’ command to interact with the HAAst socket from a Bash command line. (You may need to add the socat command / package to your particular Linux installation). The exact syntax for the socat command is as follows:


socat – UNIX-CONNECT:/var/run/haast.sock


You can then send any invalid command (eg: XXXX) and HAAst will respond with a list of valid commands.

If you are using the Commercial Unlimited edition of SecAst, then you can check how an IP address scores on the SecData service using the telnet interface to SecAst. Connect to your local SecAst server by telnet and issue the ‘hackerdb check’ command. For example:

$ telnet 172.1.1.1 3000
Trying 172.1.1.1…
Connected to 172.1.1.1.
Escape character is ‘^]’.
SecAst telnet interface on ‘PBX1 on Waterloo data center wall’
SecAst>hackerdb check 1.2.3.4
Action: checking Telium hacker database
Database match: exact IP
IP address: 1.2.3.4
Score: 25
SecAst>[/color]

Alternatively, if you subscribe to the SecData service directly then you can check how an IP address scores from a browser by entering the query into the address bar; for example:
https://XXX.telium.io/check-ipaddress?key=YYY&ip=1.2.3.4&format=p
(you will need to substitute the hostname and key with those assigned to your account.)

Please note that manual queries of the SecData service through SecAst are throttled, so if you issue too many queries too quickly you will receive a warning to try again later.

The attacker is providing a fake IP address (your server) as the source IP address in the SIP header, and this confuses Asterisk and results in the above error. SecAst is able to detect this type of attack and block the attacker at the network edge.

Digium is aware of the underlying issue and has resolved it in Asterisk version 10 and later, but older Asterisk versions will not receive updated code. (Some users have posted changes to the Asterisk C code but this is beyond most users to apply). In versions of Asterisk 10 through 12, you can enable the Asterisk security log as described here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Security+Event+Logger) to view more accurate error messages; and you can tell SecAst to use the security log you specified (as described in the detailed installation guide).

However, there are still dangers remaining from this type of attack. In version 13 and later of Asterisk you should not be using a security log file, and instead set SecAst to use the AMI for notification of events. Setting SecAst to use the AMI not only increases the speed and accuracy of blocking attackers, it allows SecAst access to detailed caller behavior which can be used to identify fraud and hacking before any damage has been done.

If SecAst communicates with Asterisk through the AMI then numerous other protective measures are also enabled, including detection of stolen credentials, suspicious dialing patterns, etc.

The SecAst log file or its parent directory has world write permissions, and newer versions of logrotate do not allow this to rotate. Manually running logrotate shows the results below:

$logrotate -d -v secast
reading config file secast
Handling 1 logs
rotating pattern: /var/log/secast after 1 days (7 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/secast
error: skipping “/var/log/secast” because parent directory has insecure permissions

The solution is to uncomment the line in the /etc/logrotate.d/secast file to allow rotating regardless of permission:

su root root

The HAAst log file or its parent directory has world write permissions, and newer versions of logrotate do not allow this to rotate. Manually running logrotate shows the results below:

$logrotate -d -v haast
reading config file haast
Handling 1 logs
rotating pattern: /var/log/haast after 1 days (7 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/haast
error: skipping “/var/log/haast” because parent directory has insecure permissions

The solution is to uncomment the line in the /etc/logrotate.d/haast file to allow rotating regardless of permission:

su root root