Forum Replies Created
-
AuthorPosts
-
in reply to: Why does VLS reboot on its own #20761
The VLS server may reboot itself following internal housekeeping activities. This is not normally a problem, since the VLS saves all state (activations in progress) and restores them on startup.
If the hardware is causing a reboot (e.g. bad power, hardware interrupt error, overheat, etc) or operating system (Linux crash) this too won’t cause a problem since the VLS will automatically recover it’s last known good state.
If you would like Telium to investigate further, please preserve the core dump file so that we can determine the root cause. But in general you can ignore an occasional reboot.
in reply to: USB dongles with Microsoft Hyper-V #20537Based on user feedback, the USB passthrough support of non-storage devices was removed from the enhanced session capabilities of Hyper-V. At this time (August 2024) Telium recommends a USB over IP solution (either hardware or software based) as described here https://telium.io/en/topic/usb-license-on-hyper-v-guest/
For larger deployments where local activation is required (but hardware fingerprint is not viable), Telium recommends a Volume License Server. For smaller deployments, Telium recommends a hardware based USB over IP solution. Please note that unless you have purchased one of these products from Telium, or you have engaged Telium to install the USB over IP product for you, Telium cannot offer any assistance with these third party solutions.
in reply to: Internal server error #17584There are many causes for a 500 (internal serve) error. The cause will likely not show up in your apache logs because of how PHP is setup. The default PHP configuration is designed to maximize speed (and therefor less logging). If you change your PHP configuration slightly the root cause will show in the apache error log. Please follow these steps:
Locate your php.ini file:
el@apollo:~$ locate php.ini
/etc/php5/apache2/php.iniEdit that file as root:
sudo vi /etc/php5/apache2/php.ini
Find this line in php.ini:
display_errors = Off
Change the above line to this:
display_errors = On
Lower down in the file you’ll see this:
; display_startup_errors
; Default Value: Off
; Development Value: On
; Production Value: Off;error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATEDThe semicolons are comments, that means the lines don’t take effect. Change those lines so they look like this:
display_startup_errors = On
; Default Value: Off
; Development Value: On
; Production Value: Offerror_reporting = E_ALL
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATEDWhat this communicates to PHP is that we want to log all these errors. Warning, there will be a large performance hit, so you don’t want this enabled on production because logging takes work and work takes time, time costs money.
Restarting PHP and Apache should apply the change.Next, do what you did to cause the 500 Internal Server error again, and check the log:
tail -f /var/log/apache2/error.log
You should see the 500 error at the end, something like this:
[Wed Dec 11 01:00:40 2024] [error] [client 192.168.11.11] PHP Fatal error:
Call to undefined function Foobar\\byob\\penguin\\alert() in /yourproject/
your_src/symfony/Controller/MessedUpController.php on line 249The cause should then be obvious – or email us the relevant log excerpts and we’ll help you figure it out. If you run a different Linux OS or different version, then the settings may differ slightly but the same basic instructions apply.
in reply to: OEM edition not recovering calls in one queue #17562You actually did very well setting up your system (without any help from Telium). In fact, if it weren’t for a typo in your NIGHTSERVICE queue recovery parameters everything would have worked.
Look at the NIGHTSERVICE/queue/rebuildmode key. You have “orderofarival”. Notice the missing ‘r’. It should be “orderofarrival”. Fix the typo and that queue will work too.
in reply to: Automatic update to Geofencing database #17542This can be accomplished with a simple bash (or python, perl, etc) script. At a high level the steps are:
- Change to the /usr/local/secast directory
- Use ‘wget’ to pull down the latest GeoIP database from the telium file server
- Restart the SECast service (don’t worry, all state is saved)
We normally make GeoIP database updates available with program updates; however, if you require more frequent updates (or access to a higher accuracy database) please contact your account rep for additional information.
in reply to: USB dongles with Microsoft Hyper-V #17520You’re in luck! Microsoft is slowly catching up with VMware and has experimentally added the ability to pass through USB devices. You will need a recent version of Hyper-V, and be warned that it’s not as polished as VMware’s offering.
You need to enable “Enhanced Session Mode” on your HAast virtual machine. Once you have done so then you can pass through some USB devices. If you would like some step-by-step instruction on how to enable this mode, here is a good post: https://www.nakivo.com/blog/install-ubuntu-20-04-on-hyper-v-with-enhanced-session/
As more that 90% of our customers using virtualization use VMware, we can’t offer technical support for the above yet. But if this becomes more popular then we will include instructions in our installation guide / website.
Note that Telium is not affiliated with the Nakivo website above, and considers this feature experimental. Microsoft may chose to remove this capability at any time (as of August 2023 it worked), so use at your own risk.
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 PBX 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://telium.io/hafs
If you are not looking for a PBX, but rather looking to add highly available VoIP switching to an existing product, we invite you to consider our High Availability Switch Module (HAsm). You can learn more about HAsm at https://telium.io/hasm Please note that HAsm is designed for larger and more complex projects; if you have a low budget project then HAsm is not suitable.
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 = 31536000 -
AuthorPosts
