Forum Replies Created
-
AuthorPosts
-
in reply to: Warning on sync completion #6618
The solution is to enable debug for the sync id which is generating the warning, then examine the /tmp/haast.sync.XXX.debuglog file for details of the warning. If the warning is correct or acceptable then no further action is required. If you wish to eliminate the warning completely you can edit the pre or post-sync script file to remove reference to the data (or correct the file to match your implementation).
in reply to: Logs not rotating #6617The 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 permissionsThe solution is to uncomment the line in the /etc/logrotate.d/haast file to allow rotating regardless of permission:
su root rootin reply to: Log entries out of order in web GUI #6616HAAst performance data written to the database is recorded using the timetamp of the source system, and they are displayed in the order they arrived. If entries from different servers appear out of order, that means that the clocks on the two servers are out of sync.
The solution is to install the network time service (NTP) on both peers and ensure they synchronize from the same source.
in reply to: License file rejected #6615Something significant has changed in regards to the computer’s hardware profile. If you are attempting to move your license to a new hardware platform please contact support@telium.io for assistance.
If you are not moving your license to another hardware platform and have not changed the hardware in any way then something else has gone wrong and we’re here to help. This symptom has been reported with HAAst installed in a virtual machine and the VM has undergone a virtual hardware revision upgrade. Similarly, if you have modified various BIOS settings your system might report hardware differently.
As a workaround restart the HAAst service, or restart the virtual machine guest. Please generate a new license request and send it, along with a haast log file showing your failed restart attempt (including the license rejection messages), and we will generate a new key for you and help you figure out what changed (so long as the system still has a maintenance agreement in place).
Please note that physical and virtual machines do not just change their configurations on their own – so be careful you don’t invalidate your license by experimenting with hardware or VM settings. Activate your license only after you have finished configuring your hardware.
in reply to: Peerlink disconnects on occasion #6614You are experiencing a network/routing issue somewhere on your network. It could be an ARP table is corrupt somewhere, or a device is simply not routing packets out the interface it should. This type of problem is common with multihoming (this is not a HAAst issue, it’s a network issue).
A complete solution is beyond the scope of this document. In fact, understanding and diagnosing ARP cache and routing problems is complex – don’t expect a simple answer. If you want to ensure that your Asterisk server is sending packets out the right interface on a multihomed system, you can set an iproute policy as follows:
1. edit the /etc/iproute2/rt_tables file and add the following line:
200 haastrt
2. add the following two lines to your asterisk.start.pre file (assuming the device you are dynamically creating is called eth0.haast):
ip rule add dev eth0.haast table haastrt
ip route add default dev eth0.haast table haastrt
3. Reboot your system and retry the ping test mentioned above.If the problem remains then the most likely cause if your router.
The snooze times for promote/demote for one or both peers is too short.
For each peer, time how long the peer requires to fully promote and fully demote (include pre/post scripts). Then add 5 seconds to each (or more depending on variability of the system performance) and set the promote and demote snooze times accordingly.
Restart HAAst and retry manual failover again. If dual active/standby contention continues then increase the snooze times in steps of 5 seconds and repeat.
in reply to: Web GUI can’t connect to socket #6612The HAAst socket file is not accessible by the web server process. (Assuming HAAst is in fact running)
Check permissions of the socket file and the directory containing the file. As of HAAst version 2.2 the socket file is stored in the /run directory. In previous
versions of HAAst the socket file was stored in the /tmp directory.in reply to: Dialplan errors reported by Asterisk #6611Although unusual, this suggests that your FreePBX AstDB is corrupt or incomplete, and FreePBX is missing database entries needed by the dialplan. This can occur if you have installed a buggy FreePBX update, or FreePBX has crashed, etc.
There are four possible ways to correct the Asterisk database.
- Restore the node from a backup
- Request that FreePBX regenerate the Asterisk database using this BASH command (after stopping Asterisk). Note that some versions of FreePBX don’t support this command:
curl https://SERVER/freepbx/admin/config.php?type=setup&display=devices&action=resetall - Recreate the Asterisk DB manually.
- Stop FreePBX
- Delete the /var/lib/asterisk/astdb.sqlite3
- Start FreePBX
- Edit & Submit each user
- Click apply
- Stop FreePBX on both peers and copy the file /var/lib/asterisk/astdb.sqlite3 from the working peer to the malfunctioning peer. (Be sure Asterisk is stopped on both systems before trying this).
Once corrected, be sure to resolve the underlying FreePBX/configuration/etc issue. As well, ensure that you have set the Asterisk database to synchronize in HAAst’s configuration file.
in reply to: Some calls not recovered on failover #6610After looking at your system we can see that you mistakenly updated the PBX connection information in the problematic phone sets. The Call Continuity module sits between Asterisk and the phone sets transparently (it uses the same IP and Port that Asterisk did, so phones should not see a difference). In your case you changed some phones sets to connect to the cluster’s SIP on port 15060 (the Asterisk SIP port), but they should be connecting to port 5060 (the HAast CC module SIP port).
In the following diagram, you can see how you are moving from the top topology, to the bottom topology. This is *transparent* to phone sets – do not change their SIP configuration information. Only Asterisk SIP settings have changed (to route SIP traffic through the HAast CC module).
in reply to: MySQL table synchronization warning meaning #6609Error code 5 reflects a non-descript exit condition and is harmless.
In versions of HAAst prior to 2017 a warning with exit code 2 (in the case of MySQL database/table synchronization) means that differences were found between the source and destination tables but they were successfully synchronized. Other exit codes in this context are 0 (success, no differences), 1 (error condition), and 3 (combination of 1 and 2)
In version of HAAst from Jan 2017 onwards exit code 0 always means success (even if differences were found and then synced successfully).
No action is required; this is a normal exit code and indicates synchronization is working. We have notified the author of the library we use in the hope of a more appropriate exit code.
in reply to: FreePBX failover every night #6608FreePBX includes a backup script which causes high CPU and IO latency when it runs. During this time the entire system becomes unresponsive, and call quality may suffer. HAAst will accurately detect that the server has become unresponsive and initiate a failover.
Customers don’t usually realize the system degradation caused by the FreePBX backup script as the script normally runs late at night. However, if the CPU and/or IO latency become severe, processes may hang/crash/use 100% CPU.
The solution is to start by dealing with the root cause: disable the FreePBX backup script. This script is known to cause a variety of other system related issues. Instead use a high quality backup program (free or commercial). If that is not an option, Telium can assist you in modifying your setup to allow the script to run better behaved.
Next, consider only backing up the standby peer (letting your backup program determine which is active). Finally, you can increase the priority of the HAAst process by increasing the [common] processpriority value by 2 (or higher if that is not sufficient).
in reply to: GLIBC error #6606The wrong HAAst package has been installed. HAAst is looking for libraries that are more modern (recent) or old than those offered by your Linux distribution.
If you are sure you downloaded the right HAAst package then try a system wide update using your package manager (eg: “yum update”). Otherwise, return to the Telium web site and download a more suitable HAAst package.
If you don’t see a HAAst package that exactly matches your Linux distribution, try downloading the package for the oldest Linux distribution. The LTS (Long Term Support) versions of versions of Red Hat (eg: v6) and Ubuntu (eg: v12) are usually the best packages to try.
in reply to: Untarring error #6605The library you downloaded is incomplete and/or corrupt. Try again to download the file. Before expanding the archive, check the md5sum
value of the downloaded file and compare it to the value shown on the Telium website for that file.Some users find that their browser cannot reliably download files – in which case we recommend using FTP instead to get the file.
in reply to: Web GUI access says error 500 #6604This problem can occur upon initial installation, or after an upgrades (if you deleted the contents of your /usr/local/haast/web_interface directory), and you have configured Apache to require a password when browsing the (virtual) directory. The problem is that your password file was not created (or was deleted during your upgrade). Please review section for 3.4.5 for details, but in summary you can create the
missing password file as follows:htpasswd -c /usr/local/haast/web_interface/.htpasswd user1
which will also prompt you for a password for the newly created user account named ‘user1’.
There is a known bug (in Ubuntu/Debian) relating to constantly changing MAC addresses for bonded interfaces. Further information can be found here: http://blog.widodh.nl/2015/09/ubuntu-and-the-changing-mac-address-withbonding/ or found on the Ubuntu bug tracker as bug 1288196.
The solution is that you must adopt one of the workarounds identified in the above article to avoid problems with HAAst functionality. Telium’s recommendation is to fix the MAC address for the bonded interface as follows (as recommended in the article):
auto bond0
iface bond0 inet manual
hwaddress fe:80:12:04:6d:6f
bond-slaves none
bond-mode 4
bond-miimon 100
bond-updelay 5
bond-downdelay 5and if your distro permits, re-use a MAC address for the bondX interface which matches one of the underlying physical MAC addresses.
-
AuthorPosts
