I ran into something very strange today.
As part of a database maintenance thing I decided to upgrade all our customers mysql-passwords to the new mysql password hash (31bit instead of 16) with the internal PASSWORD-function. The updating itself run smooth and without any problems and all sites were working as before…
I really can’t seem to shake off the problems with Parallels Plesk Panel 10.4.
Some time ago, a customer complained about an increase in spam on his mail-account. I checked it, and everything seemed to run fine – I even doublechecked the spamassassin-configuration. All fine and good and all.
Some weeks later I suddently noticed, that I can’t seem to find spamassassin doing any work in the maillog (/usr/local/psa/var/log/maillog). So I started digging. I quickly found out that Spamassassin indeed wasn’t running anymore. Puzzling.
Those that encounter the problem that FastCGI isn’t working anymore after an update to Plesk 10.4.4 may want to read further.
After yesterdays security debacle @Plesk I decided to upgrade my Plesk installation. The upgrade process ran smooth for once. I also switched to PHP 5.3 some months ago.
But after that I encountered a pretty nasty bug. FastCGI wasn’t running anymore! I was lucky enough that our customers didn’t seem to notice anything, but it was still driving me crazy.
I just learned something great today: A VoIP Carrier Fallback would be awesome.
It really sucks when Company A crashes their Core-Switch and you just can’t do anything to fix it. You’ll have to wait and wait and wait while your customers call you all the time complaining about their phone not working and your crappy service.
Obviously you can’t have an ISDN link as backup for every customer, but a second fiber link into another carriers voice backbone would be nice.
You know, just in case.
In case you are using Plesk as your favorite hosting-server-managing software (believe me, it’s not my favorite at all) and and it’s watchdog, the chances are high that you’re receive an error like the following once in a while since beginning 2011.
Error occurred while processing database query: 'MySQL query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'group by service_id, type, round(unix_timestamp(time) / 200, 0) having count(val' at line 3'
wd__db_query(string 'select service_id, type, unix_timestamp(min(time)) as min_time, unix_timestamp(max(time)) as max_time, avg(value) as avg
from module_watchdog_sys_stat where
group by service_id, type, round(unix_timestamp(time) / 200, 0) having count(value) > 1 limit 10000;')
pack_statistics(integer '200', boolean false, boolean false)
This will be my first post on this blog… How exiting!
Recently I had to implement a pretty useful Asterisk Behaviour in Callweaver: The Reason header for Calls that have been answered elsewhere.
Asterisk behaviour is: When you get a call on a ringgroup and somebody picks it up, every other extension will receive the REASON-header with following content (SIP;cause=200;text=”Call completed elsewhere”) alongside its CANCEL. And this little header does some real magic, because the call won’t be listed as missed on your phone anymore!
Default Callweaver behaviour would be: As long as you yourself do not pick the phone up, it will be shown as a missed call, which can be quite annoying (and you can’t be sure anymore if this is really a missed call, or if somebody else has already picked it up).