Archives

Telium software uses “activation” to turn on the features you have paid for, and to prevent software theft (or pirating). In order to offer the greatest possible flexibility to customers, and minimize inconvenience, Telium offers four different activation types:

• Hardware Fingerprint: This type of activation is used by Microsoft Windows and is now the industry stadard. Telium’s software computes a fingerprint of your computer at the time of licensing, and that fingerprint is used to uniquely identify your computer. If someone copies the software and tries to run it on another computer then it will fail to start (since the fingerprints won’t match). This type of activation does not require any special hardware or access to the internet, and is suitable to emergency / public safety phone service operators, PBX’s on secure networks, stand alone physical servers, etc. Note that if your computer is not fingerprintable (eg: if you run the software inside a container or virtual machine) then this type of activation is not available to you. However, if you are running the Telium software in a commercial hosting environment (eg: AWS, Azure) then this option works perfectly (even though the cloud provider uses virtualization), and this option is ideal as Telium has worked with major hosting providers to ensure fingerprint consistency as your instance moves from host to host.
• USB Dongle: This type of activation uses a USB device (known as a “dongle”) which we courier to you after completing your purchase. Telium’s software will recognize the dongle plugged into a USB port and then start normally. If someone copies the software and tries to run it on another computer without the USB dongle present then it will fail to start. This type of activation is suitable to computing environments where hardware is not fingerprintable (eg: if your run the software inside a container or virtual machine), or where hardware changes frequently. You can still move your VM guest across different hosts by sharing your USB dongle over the network (eg: using usbip) – you do not need to plug the dongle into a particular host, but you can.

  A USB Dongle looks similar to this:
  

• Cloud:This type of activation does not have any dependence on computing hardware or USB devices. Upon start the software will contact Telium’s servers in the cloud to request permission to run. So long as you are running only the number of licensed copies you have purchased then Telium’s servers will give permission to the software to start. This type of activation is suitable to computing environments where hardware is not fingerprintable (eg: if you run the software inside a container or virtual machine), or where hardware changes frequently. This type of activation is not suitable to emergency / public safety phone service operators since such environments are not permitted to depend on the internet/cloud in order to operate.
• Volume License Server: This type of activation does not have any dependence on computing hardware, USB devices, or the cloud. Upon start the software it will contact a Volume License Server (VLS) running in your data center to request permission to run. So long as you are running only the number of licensed copies you have purchased then the VLS will give permission to the software to start. This type of activation is best suited to customers running a large number of Telium products, such as Internet Telephone Service Providers (ITSP). Note that a Telium VLS must be purchased and installed separately.

Telium licenses are perpetual; in other words, they never expire. As a result you cannot change activation types after we have issued your license. (If we were to issue a second license with a different activation type then the second license could be used to run a second copy of the software.) Please be sure to select the right activation type when you initially request your license.

If you lose or damage the USB Dongle then you would have to purchase an entirely new license at full price. Be sure that software loss is included in your office fire/damage/theft insurance policy, so that you can replace your software in case of loss. The USB key contains a CPU with hacking detection (EAL 5+) and will lock itself after repeated hack attempts. A USB dongle which has been locked due to hacking is considered damaged and can only be replaced through purchase of an entirely new license at full price.

There are products which allow a Linux OS to connect to a USB dongle over a network/internet. Although such products (e.g. http://usbip.sourceforge.net/, https://www.eltima.com/share-usb-dongle-over-network.html) are not officially support by Telium, we have been told these work with our USB dongles.

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

It sounds like you want the local HAAst node to monitor the health of an external device. The way to accomplish this is with a HAAst health sensor.

At the simplest level I would suggest you create a sensor to monitor whether or not the device is responding to pings. For example, pasted the following code to /etc/xdg/telium/haast.conf.d/mydevice.sensors.conf


; Test if mydevice is reachable and responsive
network-connection/description=Ensure mydevice is reachable and responsive
network-connection/type=ping
network-connection/input=received
network-connection/parameters=count:3 | interface:ens1 | host:1.2.3.4
network-connection/scoring= =3:0 | =2:30 | =1:50 | :70
network-connection/warningscore=30
network-connection/errorscore=70
network-connection/resetcumulativescore=0
network-connection/interval=10


Restart HAAst and the sensor will become live. You should now see the local peer health score change based on the result of the above sensor.

I’ll explain the example more:

• The sensors pings the device 3 times through interface ens1.
• If 3 responses are received, then the health score for this sensor is 0; if 2 are received the health score is 30; if 1 is received the health score is 50; if none are received the health score is 70.
• If there is a warning from the ping (eg: no route) then a score of 30 is used. If there is a error (eg: ping cant run) then a score of 70 is used.
• The sensor runs every 10 seconds. (Since the ping command runs for 3-4 seconds that would be a 40% duty cycle).
• If the score ever returns 0, then the cumulative score for this sensor is reset to 0. Remember that each sensor’s score is cumulative, so it grows over time if the sensor keeps failing.

To make the above work, you also have to adjust your sensors settings in haast.conf If this is the only sensor in use then it is quite simple, but you may wish to create many such sensors to monitor other critical devices. In this case you could set your haast.conf settings as follows:

• criticallevel=70
• criticalresetlevel=40
• failurelevel=100

Note that the level settings in haast.conf check totals cores (across all sensors), and that individual sensor scores are cumulative. So in the example above missing 1 ping out of 3 each time the sensor runs will cause the sensor’s cumulative score to go 0 -> 30 -> 60 -> 90 -> 120. When it reaches 70 a critical alert can be sent (an event handler can run), and when it reaches 100 the local peer will declare failure and initiate a fail over.

As scoring tends to be more difficult to understand, here another example. The following graph shows the health score of the sensor over time (seconds). You can see from the blue boxes when a sensor starts (every 10 seconds), and when it ends (approx 4 seconds later). Based on the result of the ping responses (pongs), the number of packets received will cause a score to be calculated. The cumulative health score (in yellow) grows over time as the sensors detects missed pongs.

You can see at time 34s that all pongs where received and the cumulative score returns to 0. At time 64s the cumulative score has reached the critical level (70) and the critical event handler is trigger. At time 74s the cumulative score has reached the failure level and the node triggers the fail over process to the peer. Once the other node is active the local health score returns to 0 around time 84s.

This example is a simple ping test, but if your device offers health information through a REST API, telnet interface, etc. then you could create an even more sophisticated sensor.

I would suggest you experiment with disabling the ens1 NIC on your host, and watch the health score increase and then failover in HAAst. (Through the HAAst GUI or through the HAAst telnet interface). Once it works perfectly you could create similar sensors for HAAst on the other peer.

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

Telium wrote HAAst from top to bottom in C++, and we agree with your Linux admins that the open source packages are not well suited to application level HA. The open source packages are great if you want to create a HA print server, file server, etc. However, they have no understanding of, or visibility into, the PBX, the environment, trunks, etc. The open source packages work at the OS level, not the application level and as such don’t create an HA PBX which can survive real world failures. For example, a route becoming unavailable at the ITSP, the PBX running out of file handles, a data center router going down, etc. would all trigger a failover with HAAst, but open source packages would likely leave you with a non-functional PBX.

Aside from HAAst, every other HA solution for PBX’s is based on essentially the same open source packages. HAAst does not use open source packages for any detection, heartbeat, failover control, etc. But, you are welcome to use open sources packages with HAAst if you like. (There are some things open source does well and we don’t want to reinvent the wheel). Although the HAAst product tabs do a good job explaining the differences between HAAst and the open source / commercial products but here are a few highlights:

Heartbeat & Health: The open source heartbeat/health package does not take into account the health of Asterisk, status of trunk & route availability, available file handles, available memory, etc. latency between devices, calls successfully bridging, etc. Open source packages do dead/alive detection of the box/process (and are not Asterisk operations aware). HAAst has its own proprietary heartbeat and health detection, written exclusively to monitor and detect Asterisk PBX’s and their environments. By default HAAst detects 18 different factors which degrade node health (including talking directly to Asterisk through the AMI to assess health), and can also use an unlimited number of customizable sensors.

Synchronization: Open source packages like DRBD (or other shared disk solutions like NFS/Samba/iSCSI/Corosync/Rsync/etc.) put your data at risk since file corruption by one failing peer immediately corrupts files of the other peer. With those open source solutions a failing process on one peer may destroy your entire cluster. As well, network loss during data sharing may leave your files corrupt and SQL databases in invalid states (the database might not start with corrupt tables, and Asterisk might not start with corrupt config files). HAAst synchronizes data between peers, but only if the peers are healthy. HAAst synchronizes databases (MySQL/PostgreSQL/SQLite) at the SQL transaction level, so you are never left with corrupt tables (and a PBX that won’t start). And to top it off, HAAst can maintain snapshots of healthy critical files, stepping backwards through previous snapshots to find a system state that allows the PBX to start after failure.

Security: HAAst has an encrypted link between peers so there is no risk of Man In The Middle attack, and no risk of hackers gaining control of the PBX. Open source products have well published and unencrypted protocols that are easy to tap into, and a novice/script kiddie can bring down the cluster using this information.

Other: There are lots of other functional differences as well – have a look at the features tab of the HAAst web pages for an overview of what HAAst does, and then look at the comparison tab to see what generic tools can’t do.

Performance: The bottom line is: how do these HA solutions perform in real life. There’s a reason that emergency service gateways, hospitals, airline call centers, etc. choose HAAst. From complete detection, to avoiding false positive failovers, to speed of failover, to moving resources, etc. nothing comes close to HAAst.

All of the open source packages are wonderful products in their own right, each with a specific purpose. If you spend enough time adding your own code on top of these then you can start to add application level HA functionality – but its up to you to code it. After 10 years of continuous development we have created a very sophisticated product which can detect and recover gracefully from an enormous number of failure scenarios, building our own heartbeat/synchronization/health detection/etc tailored to telephony environments.

So unlike some other HA ‘solutions’, HAAst is not a collection of open source packages relabeled as an application level HA product. Check out the HAAst web page tabs to see why HAAst is the only solution for hospitals, police/fire/911 call centers, mission critical call centers,etc. So your Linux admins are right – open source packages are NOT suitable for application level HA (as would be the case with a PBX), and that’s why HAAst is the choice of large call centers/fire departments/emergency service gateways/etc.

You can have HAAst issue SNMP traps using HAAst’s built-in event handler system. The event handlers are simply executable files (binary / BASH / etc) or symlinks placed in the directory:
/usr/local/haast/events

The event handlers are named to reflect when they are triggered. The files you most likely want to create are:

• asterisk.start.pre
• asterisk.stop.post

The event handler (files) are launched automatically by HAAst – there is nothing you need to do to execute them. For example, the “asterisk.start.pre” is launched by HAAst before Asterisk is started upon node promotion. If you wanted the event handler to run immediately after Asterisk is started, create a file called “asterisk.start.post”.

In your case create these two files with 550 permissions in the above folder. The content of the file would be similar to:


#!/bin/bash
# Issue SNMP v3 trap
snmptrap -v -e -u -a -A -x -X
logger “SNMP trap issued for demotion of local peer”

There are also numerous environment variables set by HAAst before executing the event handlers; so if you want information related to the peer/failover/etc you can use these environment variables in your BASH script. (See the installation guide for more information on the environment variables, or use the set command in an event handler to redirect all environment variables to a temporary file for further examination).

The snmptrap commands may require a change to system configuration files, but that would be specific to your setup. If you have configured other traps then this is likely already done.

Please note that use of SNMP is an advanced topic, and its configuration requires advanced Linux admin skills.

For example, if you copy the text below and place it into the file /etc/xdg/telium/haast.conf.d/network_cable.sensors.conf then you can test the sensors graph on the GUI. This sensors checks if the network connection on ‘eth1’ is down. If the connection is down the health score increases by 5 points. If the connection is up the health score remains unchanged for that cycle. (i.e. 0 health points).

If HAAst can’t read the NIC, then an error score of 20 is used. If HAAst can talk to the NIC but not extract a state then the warning score of 10 is used. If the sensors reports 0, then the cumulative score for this sensors is reset to 0. This sensor runs every 5 seconds.

So restart HAAst with this sensor in place and open up the graph on the HAAst GUI. Unlpug the network cable and watch your score, then replug the cable and see it reset to 0. If you leave the cable unplugged long enough and the health score reaches the critical level, then your cluster will fail-over to the peer.


; Test to ensure a network cable is plugged into the NIC, and that the cable is live (i.e. other end is plugged in)
network-cable/description=Cable plugged in
network-cable/type=nic
network-cable/input=state
network-cable/parameters=state:ethernet | interface:eth1
network-cable/scoring= =up:0 | :5
network-cable/warningscore=10
network-cable/errorscore=20
network-cable/resetcumulativescore=0
network-cable/interval=5
network-cable/debug=false


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

You most likely moved or deleted the password file associated with your GUI. Or you might have applied a HAAst update which (until the version released March 2018) would mistakenly remove that file during the automated update (install_updates.sh)

You can recreate the .htpasswd file as described in section 3.4.5 of the installation guide (Secure the Web Interface). I’ll repeat the Linux command here to save you from digging out the manual:


htpasswd -c /usr/local/haast/web_interface/.htpasswd user1

The above line will create username ‘user1’ and then prompt for a password to be associated with the username. To reset the password just repeat the process. Note that the “-c” parameter creates a new file, so it removes other username/password combinations from this directory. If you want multiple usernames for this directory please check the man page of htpasswd for help.

(After March 2018 if you run install_updates.sh to update your version, then your .htpasswd file will be preserved)

Yes. First, ensure that the ‘managemanual’ setting in the [banip] stanza of your secast.conf file is set to true.

Next, from the telnet interface to SecAst manually add the IP address to the ban list. For example:


SecAst>banip add 1.2.3.4
Issued request to add IP 1.2.3.4. Check event log for errors, or use ‘banip list’ to confirm add
SecAst>

After that SecAst will leave the address in your blocked IP list, and never expire the ban.

I recommend using the updatefiles.sh script file found in the haast-2.X.X-x86_64-XXX/install_files directory of the HAAst package you downloaded. This script will update all files to the latest version of HAAst. Just restart the HAAst service once complete. For example:


[root@pbx2:/usr/src/haast-2.3.13-x86_64-rh7/install_files] $ ./updatefiles.sh
HAAst file copier/updater version 1.5

We don’t sell the LED lights directly, but we have partnered with a company called Cleware to provide them. You can purchase their LED lights here: http://www.cleware-shop.de/USB-Ampel-EN

We fully support the Cleware product, and can assist you in making the LED’s change color with our product state, etc. For example:

• HAAst: Red=Standby, Yellow=Transitioning, Green=Active peer
• SecAst: Red=Threat level high, Yellow=Threat level medium, Green=Threat level low
• LoDi: Red=>90% load, Yellow=>80% load, Green=

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

You are welcome to download the Free Edition of any of our products to experiment with the functionality, capabilities, etc., and to create a demonstration system. You can also post questions on these support forums for assistance (we respond on a best effort basis, at least once per week). All for free.

If you would like a trial license (which enables all features) and support during your installation process you would need to purchase 4 hours of support (as a fixed price package). In return we will help you get a complete functional demo up and running. As well, since there is no difference in the code base between the Free and Commercial Editions, your client can simply add a license file and turn the demonstration system into a production system.

Note: Trial licenses impose limitations to prevent the software from running indefinitely.

You are welcome to download the Free Edition of any of our products to experiment with the functionality, capabilities, etc., and to create a demonstration system. You can also post questions on these support forums for assistance (we respond on a best effort basis, at least once per week). All for free.

If you would like a trial license (which enables all features) and support during your installation process you would need to purchase a trial edition (priced at 50% of the Commercial Unlimited edition). In return we will help you get a complete functional demo up and running. As well, since there is no difference in the code base between the Free and Commercial Editions, your client can simply add a license file and turn the demonstration system into a production system. Will will also credit this amount towards the final sale if you decide to purchase the Commercial Unlimited edition.

Note: Trial licenses impose limitations to prevent the software from running indefinitely.

We do not offer a prepackaged SUSE(TM) distribution of HAAst due to lower market share of SUSE. As you can see (https://en.wikipedia.org/wiki/List_of_Linux_distributions), there are hundreds of different Linux distributions and we could not possibly create packages (or installation instructions) for them all.

We do however offer a custom build service included with the Commercial Unlimited edition of HAAst. So if you purchase multiple HAAst Commercial Unlimited licenses we will create a build for SUSE LES 12 SP3 (the most current as of this date) or whichever variation you require. If you just want to experiment with the free edition of HAAst but aren’t familiar with other Linux distributions, you may wish to create a VM with CentOS + our software.

It sounds like your document root (set by PHP) is not pointing to the right place – but that’s ok. (We’ll try to recreate your problem on a future release so we can properly detect and override the document root for your distro.) A simple workaround is to create a symlink for settings.php to the correct document; for example:



ln -s /usr/local/secast/web_interface/settings.php /var/www/html/settings.php

The GUI is useful for analysis of historical data, sources of attack, graphs, etc. but is not necessary for the operation of SecAst. Most of the reporting in the GUI is based on the MySQL database feature (which is not included in the free edition).

However, SecAst will still detect and block attackers in the Free Edition. All attack data is kept in an internal database (not MySQL) so it operates with all editions of SecAst.

There are several possible causes, all network configuration related. However, the most common cause has to do with the default route on your PBX causing an asymmetric network path.

In other words, packets come in ethernet1 and (try to) go out ethernet2. For security reasons some Linux versions prohibit this, and some routers/gateways can’t handle this. The first thing to do is ensure that your Linux configuration allows this type of asymmetrical path. Type the following from a Bash prompt:



echo “0” > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo “0” > /proc/sys/net/ipv4/conf/eth1/rp_filter

and replace eth0 and eth1 with the names of your network interfaces. This should take effect immediately (no restart required).

For more details of what the above commands do (and what problem they address) please visit https://access.redhat.com/solutions/53031 . Note that allowing asymmetric routes is sometimes the best solution, but other times it’s best to adjust your routing tables to cause symmetry in packet flow.