Archive for the ‘Plesk’ Category

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.

Tags: , , , , , ,
Posted in Plesk | No Comments »

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 :)

Tags: , , , , ,
Posted in Plesk | 1 Comment »

Parallels Plesk 9 and SSL certificates signed by an intermediate Certificate Authority (CA)

Wednesday, February 9th, 2011

Parallels Plesk 9 doesn’t seem to like installing certificates signed by an intermediate Certificate Authority (which is becoming more and more common and will be all certificates in the next year or two) through the SSL certificates part of the Plesk interface available to both administrators and end users.

A work around to this seems to be to install the CA bundle (both the root CA and the intermediate CA certificates) together and then install your certificate separately, otherwise you will just receive an error saying that the certificate was not signed by the certificate authority.

Tags: , , , , , ,
Posted in Plesk | No Comments »

Parallels Plesk for Windows upgrade and lots of session files

Monday, December 27th, 2010

Be careful when running the Parallels Plesk update utility on Windows servers if you have a large number of files in “C:\Program Files (x86)\Parallels\Plesk\admin\sessions” as once it has finished the upgrade the utility will try and clear this directory before letting you do anything else, including the mandatory reboot. It seems that it is quite easy for there to be hundreds of thousands of files in this folder, which in turn means that this part of the upgrade process can take well over an hour even on a decent machine!

Tags: , , ,
Posted in Plesk, Windows | No Comments »

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.

Tags: , , ,
Posted in Plesk, WHMCS | 1 Comment »

Parallels Plesk 9.5.1/9.5.2 and Greylisting

Friday, June 11th, 2010

In April’s Plesk 9.5.1 update (following on from 9.3.x – apparently Parallels can’t count so just skipped 9.4.x and 9.5.0 entirely…) they managed to seriously break one of the great Plesk 9 features for Postfix users… greylisting!

One of the big improvements when Plesk 9 was released (apart from ditching QMail!) was that it no longer relied upon unsupported third party software such as QGrey to add greylisting features. The big benefit of this was that the greylisting was tied in the with authentication of mail users, so users who authenticated to your SMTP server in order to use it as a relay automatically bypassed the greylisting filters.

The use of third party greylisting in Plesk 8.x was the source of much frustration from users who were trying to send e-mails and were getting unhelpful error messages from their e-mail clients. This puts server administrators in a difficult position; deal with the user complaints, or disable greylisting and put up with a massive increase in spam e-mail.

In Plesk 9.5.1 this feature mysteriously stopped working. At first Parallels claimed that greylisting was working as designed, but then admitted that it was a bug and they would fix it. The Plesk 9.5.2 release came and went with no fix and no word from Parallels. In the end, it was well over a month from Pleks 9.5.1 being released and the bug first being reported to a patch being available.

The fix that they have released isn’t released as a hotfix and so doesn’t show up in the normal Plesk update process either from the command line auto-installer or the Plesk web GUI’s udpate manager, nor is it applied as part of a fresh install. It’s not even on the Parallels Knowledge Base, you have to go on their forums and find it in a thread by a Parallels member of staff known as “IGorG” called “Workarounds” in the “Parallels Plesk Panel 9.5 for Linux/UNIX Suggestions and Feedback” forum.

Even once you have located the ZIP file containing the patched code and got your forum login to work long enough for you to download it without getting a “Can’t create new user ” error, Parallels have only release the fix for certain platforms (in particular, CentOS 4.x and 5.x both 32-bit and 64-bit as well as Debian 5 64-bit only) and they don’t seem to have any intention of releasing the patch for the other Linux/UNIX platforms supported by Plesk 9.x (SuSE, openSuSE, FreeBSD, Fedora, Debian 3.x & 4.x, Debian 5.x 32-bit, Ubuntu or CloudLinux).

If you are lucky enough to be on one of the supported platforms for which they have released a patch then you can download the ZIP file with the new postfix-queue files from the “official” post on the Parallels forum at http://forum.parallels.com/showpost.php?p=413387&postcount=62

Once you have copied it onto your server and extracted the contents, you should find several folders which correspond to the patched platforms (Cos4x32, Cos4x64, Cos5x32, Cos5x64 and Deb5x64), each of which has a fixed copy of the “postfix-queue” binary inside.

Back up your current postfix-queue from “/usr/lib/plesk-9.0/postfix-queue” (32-bit copies of Plesk) or “/usr/lib64/plesk-9.0/postfix-queue” (64-bit copies of Plesk) to somewhere safe and then copy the postfix-queue file from the appropriate directory over the /usr/lib/plesk-9.0/postfix-queue or /usr/lib64/plesk-9.0/postfix-queue file and restart the Postfix service.

Your authenticated users should now be able to send e-mail again without having to wait for the greylisting timers.

Tags: , , ,
Posted in Plesk | No Comments »

@mail in Plesk 9.3

Friday, March 5th, 2010

I recently upgraded a server to Plesk 9.3 only to find that it broken @mail. The list of available webmail clients no longer has @mail in it and trying to remove the psa-atmail RPM failed with a script error.

In the end, I had to force the removal of the RPM with the –noscripts option and then go and manually delete /var/www/atmail as well as any entries in /etc/psa-webmail/atmail, /etc/psa-webmail/atmailcom, /etc/psa/webmail/atmail and /etc/psa/webmail/atmailcom before I could get the RPM to re-install correctly.
Even then, the RPM install failed with “Unable to get options for atmail webmail” and I had to run “/usr/local/psa/admin/bin/webmailmng –install –name=atmail” to get it back in to the list of available webmail clients.

It seems that this has all come about with Parallels moving the webmail config files from /etc/psa-webmail/ to /etc/psa/webmail/ and botching up the RPMs somehow.

Tags: ,
Posted in Plesk | No Comments »

Per-domain/per-account settings for Plesk 9′s greylisting

Thursday, February 4th, 2010

Plesk 9 introduced the very useful feature of greylisting for the Postfix SMTP server (and presumably the QMail one as well, but I only use Postfix as QMail gives me a headache!).

Greylisting basically sends a “resource temporarily unavailable, please try again later” message whenever someone connects and tries to deliver an e-mail. For legitimate SMTP servers, this isn’t a problem; they will do as the server and the SMTP RFC says and try again later.

Spammers on the other hand don’t generally retry as they are just focused on blasting out as many e-mails as possible to as many addresses as possible. They don’t have time to come back to your server later as all of the retries would tie them up and prevent them from sending to other potentially reachable servers. They also generally use poorly written software that doesn’t conform to standards.

The greylisting software keeps track of the IP addresses trying to send e-mails through the SMTP server that it is protecting and after a resonable amount of time (say 15 minutes or so) it will allow re-delivery attempts to pass through.
If a server tries to re-connect too soon and/or too frequently after being told to try again later, then it is penalised by the greylisting software.

The only two downsides to greylisting are that some legitimate e-mail servers don’t retry sending e-mails (so you have to whitelist them in order to be able to receive e-mail from them) and that greylisting slows down e-mail delivery as you have to wait for the sending server to retry.

The Plesk web interface is a bit limited when it comes to greylisting, but luckily (as with most Plesk features) there are comprehensive CLI tools to accomplish what you need. In this case, the “grey_listing” command, which for CentOS/RHEL systems can be found in /usr/local/psa/bin/grey_listing

Some useful commands:

Show server wide settings:

/usr/local/psa/bin/grey_listing –info-server

Show per domain settings:

/usr/local/psa/bin/grey_listing –info-domain spheron1.co.uk

Show per e-mail address settings:

/usr/local/psa/bin/grey_listing –info-mailname postmaster@spheron1.co.uk

Enable server wide greylisting:

/usr/local/psa/bin/grey_listing –update-server -status on

Disable greylisting per-domain:

/usr/local/psa/bin/grey_listing –update-domain spheron1.co.uk -status off

Set the time to greylist new IP addresses for (in minutes):

/usr/local/psa/bin/grey_listing –update-server -grey-interval 5

Set the expiry time for allowed IP addresses (in minutes):

/usr/local/psa/bin/grey_listing –update-server -expire-interval 43200

Set the time to penalise IP addresses for (in minutes):

/usr/local/psa/bin/grey_listing –update-server -penalty-interval 2

Enable penalising of IP addresses:

/usr/local/psa/bin/grey_listing –update-server -penalty-status on

Whitelist e-mail from all @gmail.com addresses to postmaster@spheron1.co.uk:

/usr/local/psa/bin/grey_listing –update-mailname postmaster@spheron1.co.uk -whitelist add:*@gmail.com

Server wide blacklist e-mail from postmaster@hotmail.com:

/usr/local/psa/bin/grey_listing –update-server -blackelist add:postmaster@hotmail.com

Tags: ,
Posted in Plesk | No Comments »