Posts Tagged ‘PSA’

Unable to send attachments in Horde

Thursday, September 29th, 2011

I recently came across a bizzare issue in the version of Horde webmail shipped with Parallels Plesk 9.5.2 where it would allow you to attach files to an e-mail you are composing, but when you send the e-mail the attachment never arrives. Sending the same attachment via the Atmail webmail client or a traditional SMTP client wasn’t a problem and the mail server logs didn’t indicate that the attachment was getting stripped, so it was eveidently never getting attached to the e-mail in the first place.

For some reason Parallels Plesk doesn’t specify a seperate ErrorLog for the Horde webmail.domain.com vhost in /etc/httpd/conf.d/zzz_horde_vhost.conf so all of the logs from Horde end up in the main Apachce HTTPD error log at /var/log/httpd/error_log.

In the logs there should be PHP errors where Horde is unable to load one of it’s shared libraries that is used for processing attachments:

PHP Fatal error: Can’t load Horde/Serialize.php, open_basedir restriction. in /usr/share/psa-horde/lib/Horde/SessionObjects.php on line 134,

The easiest way to fix this is to change the relative path to the file (Horde/Serialize.php) to an asbolute path, so take a copy of /usr/share/psa-horde/lib/Horde/SessionObjects.php as a backup then open the file up and
look for two lines that say:

require_once ‘Horde/Serialize.php’;

And edit these two lines to have the full path:

require_once ‘/usr/share/psa-horde/lib/Horde/Serialize.php’;

Now all you have to do is save the file and test that Horde has started working as expected. Remember that future updates to Horde from Parallels will overwrite this file and you will have to re-apply your change.

Parallels Plesk and Atomic Secured Linux

Monday, June 27th, 2011

If you are experiencing HTTP 500 Internal Server Error messages from the license management part of the Parallels Plesk control panel when running on Atomic Secured Linux, then you are probably running into some buggy anti-reverse engineering code that Parallels have built into the Plesk software.

It seems that Parallels are using ptrace to determine if someone has attached a debugger to Plesk in order to reverse engineer it. The problem is that AtomiCorp have implemented GRSecurity ptrace protection in the Atomic Secured Linux kernel in order to prevent malicious software such as TTY sniffers and Parallels Plesk is incorrectly interpreting it’s inability to ptrace as suspicious debugging behaviour.

Until Parallels fix this behaviour in Plesk (and there is no sign that they will, given that it has been a known issue for many months), then the only thing that you can to is disable the GRSecurity ptrace feature in the Atomic Secured Linux kernel. This can be done whilst the system is running using sysctl:

sysctl -w kernel.grsecurity.harden_ptrace=0

In order to make this change permanent so that it doesn’t disappear every time you reboot your server, you will need to edit /etc/sysctl.conf and add the following line:

kernel.grsecurity.harden_ptrace = 0

Now restart the Parallels Plesk service and enjoy your error free license management :)

WHMCS 4.41 and the Plesk server module

Sunday, December 19th, 2010

WHMCS version 4.41 has split the Plesk server automation module out into three separate versions; plesk8, plesk9 and plesk10, but the upgrade script doesn’t handle changing the automation module settings for either your servers or your products/services.

As a result of this short sightedness on the developer’s part you will loose all automation of your Plesk servers (account creation, suspension, termination, statistics updates etc.) and start experiencing fatal PHP errors in both the admin and client areas of WHMCS where the functions provided by the old “plesk” module are used (which is basically any area using products/services or servers defined with the “plesk” module) unless you retain the generic “plesk” module from your previous WHMCS 4.31 install.

As copying over the “modules/servers/plesk” folder from WHMCS v4.31 or symlinking the appropriate folder of one of the new modules to “modules/servers/plesk” seems like a massive dirty hack to me, instead I decided to do what the WHMCS 4.41 installer should have done in the first place and fix the database to use the correct version of the new Plesk server module.

For me the new “plesk9″ module is the one to use, but you can adjust the following SQL appropriately to suit your needs (remember to backup your database however you see fit before you begin!):

UPDATE tblproducts SET servertype=’plesk9′ WHERE servertype=’plesk’;

and

UPDATE tblservers SET type=’plesk9′ WHERE type=’plesk’;

As usual with WHMCS, there are no mention of any changes to the Plesk module in the release notes for version 4.41.