The Linux Fix uses some pretty cool gear to run our phone system.   With some help from VMWare, an install of Trixbox here in the California office is trunked to a few Broadvoice SIP business accounts.  Internally, we use some nice Aastra 480i IP Hardphones in the office that communicate via SIP to the Trixbox PBX.

This setup provides us with inexpensive long distance, a $5.00 toll-free number, as well as the ability to do ring-groups and call forwarding to mobile phones when customers dial in and need support.

The Linux Fix also has a few people that help out and live out of state.  For one of these guys, we have established a permanent VPN setup a few months ago (with the help of a few Fortigate units) to provide them with an actual extension and ease management tasks.

Ever since we’ve had this setup, there was a nagging issue that we just couldn’t get to the bottom of.   When calling from the office->out, everything worked fine.   However, when the remotes called into the office, or try to dial out (remember, everything is trunked from the Trixbox here in California), the call would last exactly 20 seconds and then just suddenly disconnect.  Trixbox would also log something along the lines of:

“Hanging up call 699105eb51dc2bb700889eafbf955a5e@10.0.2.10 – no reply to our critical packet.”

Googling around reveals that quite a few people have at least some variation of the same problem.  After some research we finally figured it out.   It all has to do with NAT, Firewalling, and Trixbox (and thus Asterisk’s) NAT settings.  It’s a a bit hard to explain in a blog post, so hopefully these diagrams will sort it out and help explain what is going on.

The “Wrong” Way, and, The “Right”Way

Yesterday a few of you noticed some problems with PHP-enabled sites on the TLF servers.   We were notified about it pretty quickly, and got to work on it just as fast.

Anyway, we discovered that H-Sphere’s PHP5 support, as installed; has a bug in the php.ini files that it creates.   Since H-Sphere can support both PHP4 and PHP5 in parallel, as well as Apache 1.x and 2.x, there’s quite a bit of configuration file juggling going on.

The php.ini file for PHP5 that was in use was referring to the PHP loadable module path for Apache 1.x, and not 2.x.   For other administrators of H-Sphere, you might want to double check that this line is appropriate in your own php.ini.

For instance, our /hsphere/local/config/httpd2/php5/php.ini file had this entry:

;include_path = “.”
include_path = “.:/hsphere/shared/apache/libexec/php5ext/php/”
doc_root =
user_dir =
extension_dir = “/hsphere/shared/apache/libexec/php5ext/”
cgi.fix_pathinfo = 1

When it really should have been:

;include_path = “.”
include_path = “.:/hsphere/shared/apache2/libexec/php5ext/php/”
doc_root =
user_dir =
extension_dir = “/hsphere/shared/apache2/libexec/php5ext/”
cgi.fix_pathinfo = 1

This must have occured when we did the PHP5 upgrade, and didn’t take effect until Apache actually restarted again some time later.

Thanks for being patient during the issue!

After much testing, we’ve enabled PHP5 for all hosting plans.  H-Sphere implements this in a module/CGI type configuration so our users can choose between PHP4 and PHP5.   Check your settings under “Web Options” to find out which you’re using.

Part of the update included moving to a newer version of Apache as well, all went off without a hitch.

Enjoy!

We recently upgraded the control panel to version 3.1, which went off without a hitch.  A nice side benefit is that we now support Ruby on Rails on all our web hosting plans.   Ruby fans unite!