Forum Replies Created
-
AuthorPosts
-
HAast has changed considerably since version 2.1. Did you remember to copy over the sync job definitions (probably from /etc/xdf/telium/haast.conf.d ) As for the event handlers (probably post-sync), we recommend that you use nodeprep to ensure data is properly updated and reconciled once it reaches the other node. Most event handlers are a single line of code: e.g. “nodeprep -a 1200”
If you don’t have nodeprep installed (if you pieced together a cluster from old and new software), please email us and we will provide you with the missing software and sample event handlers.
in reply to: Change nodeprep settings after setup #17247If you make changes to any products’ continuity.conf file, you need to tell nodeprep to reconfigure (re-read the continuity.conf file).
So to do this for haast run:
nodeprep -c -haast
nodeprep -c +haastThe first line will remove the haast configuration from nodeprep. The second line will cause nodeprep to re-read all configuration data and update the nodeprep database.
in reply to: Migrating to NodePrep #17245The alignment is only a small part of NodePrep does…but don’t worry, you can still customize the sync event handlers however you want.
i.e. we aren’t deprecating the syntax or event handler files.
NodePrep combines a lot of Call Continuity module functionality that would benefit the non-OEM editions, so we are slowly moving that functionality into the Flex and Unlimited editions.
in reply to: Rebuilding queues after failover on OEM edition #17208The “call continuity” module is responsible for rebuilding the queues on the standby server (as it promotes to primary). The queues are rebuilt in the order of which the calls arrived at the PBX. If a call was first answered by a user (or some other service) and then transferred to the queue, it is possible that the order of arrival at the PBX does not match the order of entry to the queue. Realistically, those few calls might be only slightly out of position.
At this time we do have any workaround for this situation. However, this should affect very few calls (<1%) and the impact should be minimal (minor change in order for those few calls). In a future version of the call continuity module we may use call queue entry times for queue reconstruction. Because of some Asterisk limitations this is not as easy as it sounds.
If this issues is a problem for your customers we recommend announcing estimated wait time instead of queue position.
in reply to: Corrupt AstDB file #17193First of all, make sure that HAast isn’t warning you of a real problem. Does your standby node have latency problems? Sever network/cpu/disk latency could easily cause a sync to fail. And if that’s a rare occurrence then that’s ok. But if it’s happening regularly then first check for hardware (or virtualization) issues.
Next, as you may already be aware, FreePBX is known to destroy the AstDB file for no good reason on rare occasions (i.e. it’s a bug that occurs rarely). See https://community.freepbx.org/t/corrupted-astdb-how-to-rebuild/4809 This problem has existed for many years customers have commented that Sangoma appears unable/unwilling/uninterested to resolve this. The nature of the problem is that Astdb file remains valid and whole (i.e. a valid SQLite 3 file), but critical information is missing or invalid in the database. Since HAast will try to apply changes to the AstDB upon sync, the sync may fail if the contents violate SQL relationship rules or other integrity constraints.
To pinpoint the cause, please enabled debug in the syncjob on the standby computer; for example, the file /etc/xdg/telium/haast.conf.d/asterisk.syncjob.conf might contain a syncjob called asterisk-db. Add the following line to that job:
asterisk-db/debug=on
And then restart HAast on the standby node. This will cause a detailed bug file to be created in the /var/tmp/haast directory. After a few automatic (or manual) starts of the asterisk-db sync job, please send that file to the support team and we will have more insight on what is going wrong.
In summary, the most likely cause is OUTSIDE of HAast. Experience has show that HAast will detect these errors and report them, but it doesn’t mean you have a HAast problem. If you are sure the hardware, Linux, and resources of the nodes are ok then starting debugging in HAast as described above.
in reply to: Withstanding penetration testing #17191If your cluster needs to withstand penetration testing (or the equivalent of exposing the management ports to the internet), then there are a number of steps you must take to harden your cluster.
1. Ensure you set complex id and passwords for the Asterisk management interface.
2. Set the Asterisk management interface to listen to localhost only.
3. Ensure you set complex credentials for HAast peerlink.
4. Protect the HAast GUI (https) interface with the htpasswd utility
5. Ensure you set complex credentials for rsync.
6. Ensure you set complex credentials for database(s) in use.
7. Limit database port access to localhost and the remote peer.
8. Set iptables rules to further limit interface/port combinations of the above to the peer and any trusted management workstations.
9. Set iptables connection rate rules to the max necessary for your cluster to operate.The HAast GUI and ReST interface can be disabled altogether if you do not need that functionality. Note that the GUI and ReST interfaces do not use ANY 3rd party libraries; it is all hand coded in PHP and tested for stability and security. However, it is possible to overload or find a weakness in Apache HTTPD; in which case disabling the GUI and ReST interface is recommended.
If you do not need direct access to the HAast telnet interface, then you should set the HAast telnet interface to listen to the localhost address only. Once that change is made, you must SSH to the node first and then telnet to HAast in order to access the interface.
HAast is designed to support even the most heavily loaded systems. However, HAast on it’s own is not designed to withstand loads/connection attempts beyond what can be found in a normal production environment. In other words, HAast is not meant to withstand the challenges of penetration testing or open internet access without first hardening the cluster. The above hardening recommendations do add additional load to the cluster nodes, so in general we do not recommend implementing the above unless you have a real need to harden your cluster.
in reply to: What to do after maintenance renewal #17189Thank you for renewing your maintenance. Once we have received payment we update our system to show the new term (duration) of your maintenance agreement. This allows our support team to continue providing you with support, generate replacement files if needed, etc.
If you wish we can also send you an updated license file (which shows the new maintenance term) to install on your system. However, this is optional. Most customers do not want to interrupt software operations just to show a new date, so you can safely skip this stop. However, if you chose to upgrade your software during the maintenance period we recommend that you request a new license file at that time.
Note: Your software will continue to operate just fine without installing the new license file. (Our licensing system shows the new expiry date)
in reply to: Call continuity / survival on failover #17087If you need to create a highly available SIP switch but you are not locked into Asterisk, then we recommend you look at our HAfs product. High Availability for FreeSWITCH (HAfs) offers call continuity in the Unlimited edition; unlike an OEM edition, this edition has no minimum volume requirements. You can use our HAfs product and get full call continuity, with no down time.
You can learn more about HAfs at https://autocommander.aws2.ocg.ca/hafs
in reply to: MySQL server has gone away #17050This error means that the connection to the database server has closed unexpectedly. HAast will immediately try to reopen the connection to recover, which is why you see data still being written to the database. However, the database operation that triggered the error has failed and it’s data will not be recorded (if it operation was trying to add data).
The root cause is that your MySQL/MariaDB server is configured to automatically close the connection after a period of inactivity, and that period is too short. To solve the problem, edit the MySQL configuration file (usually /etc/mysql/my.conf and add the following:
[mysqld]
wait_timeout = 31536000
interactive_timeout = 31536000in reply to: Where is the installation manual #17022We include the installation manual in the download package. Untar the HAast package you just downloaded and look in the /docs folder. You will see a file called detailed_installation_guide.pdf
The installation guide is over 100 pages in length, and takes you through all of the steps required to get HAast up and running.
in reply to: How to activate / request a license #17020If you have chosen USB Dongle activation, then there a few more steps required to pair your new dongle with your license. Once your dongle arrives plug it into the computer and restart the HAast service. Reconnect to the product’s telnet interface and issue the “license usbdongle” command. For example:
[root@pbx_qa_17:/usr/local/haast] $ telnet 172.31.224.14 3001
Trying 172.31.224.14…
Connected to 172.31.254.14.
Escape character is ‘^]’.
HAast telnet interface on ‘PBX QA 17’
HAast>license usbdongle
Your USB dongle has been detected but is not yet paired with your license.
To pair your USB dongle with your license send the following dongle ID to
support@autocommander.aws2.ocg.ca to receive a pairing code :
5010-5473-C839-94B9
Copy the pairing code and paste it into an email to support@autocommander.aws2.ocg.ca and include your license number. We will reply with an activation code that you must enter. For example:
When ready enter the pairing code below (or . to abort)
activation code>46A9-9907-43DB-4F06
Your activation code has been accepted. Please restart the HAast service to use the activated license.
Now exit the telnet session and restart the HAast service. HAast will restart fully licensed and you are ready to use your licensed product. You can also verify the license by repeating the “license usbdongle” command, and it should indicate that the dongle has been paired to your license. For example
[root@pbxqa17:/usr/local/haast] $ telnet 172.31.224.14 3001
Trying 172.31.224.14…
Connected to 172.31.224.14.
Escape character is ‘^]’.
HAast telnet interface on ‘PBX QA 17’
HAast>license usbdongle
Serial number: 3040504215618650775
Paired: yes, on Tue Jun 14 17:52:40 2022 EDT
Locked out: no
HAast>
in reply to: Running inside a container #17019Yes. HAast fully supports containers. Normally HAast will run inside the container with Asterisk; however, we have seen deployments where HAast runs on the host and starts a container (containing Asterisk) on demand.
If this is you first exposure to HAast we recommend installing HAast inside the container with Asterisk (and optionally a GUI).
in reply to: Do you support IPv6 #16972All of the libraries and components used by HAast are IPv6 capable, and HAast is designed to accept IPv6 settings. However, due to lack of customer demand IPv6 functionality is not currently tested or certified.
You are welcome to try IPv6 settings with HAast and everything may work. However, we do not officially support IPv6 yet. As of May 2022 we have not had any customer need IPv6 (though a few customers have inquired).
If IPv6 is essential for your implementation Telium would undertake a (for fee) project to certify HAast (only the platform and architecture of HAast you are using). There is not enough overall demand to justify doubling the entire QA process indefinitely for IPv6.
If you are an OEM or volume license customer please contact your account manager to discuss your needs.
in reply to: Move license between AWS servers #16835You have described two very different needs in your question, so I’ll try to answer them separately. If you choose Hardware Fingerprint activation on AWS, then your license is tied to your instance ID and MAC address. So you can safely move the instance between hosts (i.e. hypervisors, not guest VM’s), change instance size, etc. The license will remain activated (tied to that instance). You can safely start/stop the instance, just don’t ever delete it or delete the NIC as that will invalidate your license.
If you plan to have multiple AWS instances ready to start but will only use one at a time, then you should choose Cloud activation. Cloud activation is not tied to any (virtual/physical) hardware so whichever instance is running is the one that will use the license. However, do not start more than one instance at a time (i.e. don’t try to use a single license on multiple instances simultaneously) or that will invalidate your license.
I should point out that we use a third party license product, and they have no obligation to issue a new license once an existing one has been invalidated. In other words, if you invalidate your license you will most likely have to buy an entirely new license (full price). So plan your deployment carefully to avoid wasting a license. We have no ability to “un-invalidate” a license – we are at the mercy of the license vendor, and we understand their need to prevent license fraud as that’s the only way they can stay in business.
in reply to: Encryption of config file passwords #16546There are a couple of ways to address your problem.
First, you can limit access to the HAAst config files (or even entire /etc/xdg/telium directory) so that only the root user can read them. Using the chmod command will allow you to set these files to readonly (r – -) for root:
chmod 400 haast.confSecond, you can also encrypt the password before placing it into the config file. For example, using md5sum we can generate a hash of your obvious password:
[root@qa14 dev]# echo "MyObviousPassword" | md5sum 7f1e7328e9c668dbc73485eecd91b7ba -Then you would use 7f1e7328e9c668dbc73485eecd91b7ba as your password entered into the haast.conf file on both nodes.
-
AuthorPosts
