switch from qmail to postfix with plesk (9.5)

Whatever the reason is – or was – for you to use qmail and plesk, if you encountered even half my problems with qmail, you absolutely must get away from it. The Plesk-software however is a great invention! Even though it’s proprietary, it’s really helpful and convinient to manage a webserver, including domains and mail.

Unfortunately, I found myself forced to roll back my server a couple of times, because my mailserver qmail had stopped working without any error-message in the logs. Even more unfortunate is the person trying to resolve the problems with it – in this case: me. ๐Ÿ˜ฆ The only error-message you get is: “#421 unable to read controls”. All my hour-long attempts to change this, had no ultimate success. I rewrote config, changed permissions, restarted the service, backed up my mail and so on. All this, while knowing that no mail can be received by my server hosting about 15 Domains total. ๐Ÿ˜ฆ

When I found out, that Plesk could also work with postfix, I was thrilled! I envisioned switching servers down the road and the new server would run Postfix. What I didn’t know was how easy switching is using plesk. This is really the killer-feature to me right now! You just gotta love the simplicity. It preserves the email on the server and just switches the MTA to Postfix. Just perfect! So here you go:

Simply run:

/usr/local/psa/admin/sbin/autoinstaller –select-release-current –install-component postfix

Wait a few minutes… and that’s it!!!

For me, it saved my day! After hours trying to figure out how to fix qmail for the 100th time, the fix took a few minutes. Now the server is soaring and finnaly giving me good log-messages. Thank you, postfix. Thank you Plesk-develpers!


custom apache-config for domain in Plesk

If you want to customize the configs of a specific domain oder subdomain, you can create a file in the ./conf directory named “vhost.conf”.
It’s contents will be integrated in the config by Plesk after you change the domain-configuration.

To manually trigger this, you can run:

/<path_to_plesk>/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=<domainname>

For an ubuntu-machine (with Plesk 9) this comes down to:

/opt/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=<domainname>

error in rails in locator.rb:91:in `add’: wrong number of arguments (3 for 1) (ArgumentError)

When I tried to start my rails-app this morning on my new server, I got:

** Starting Rails with development environment…
/usr/lib/ruby/gems/1.8/gems/rails-2.1.0/lib/rails/plugin/locator.rb:91:in `add’: wrong number of arguments (3 for 1) (ArgumentError)

That seems to be a problem with an old install of rubygems on my Ubuntu-machine. Didn’t know that. ๐Ÿ˜ฆ It lives inside /usr/lib/ruby while the new versions normally reside at /usr/local/lib/site_ruby


Delete /usr/lib/ruby/1.8/rubygems.rb and /usr/lib/ruby/1.8/rubygems (the latter is a directory)

Thanks to Stephan for this article:

avoid downtime due to DNS-drag

Ever had this problem?

You have to switch servers for some reason and so naturally your DNS-settings have to be updated to the new IP-Adress. Well, moving the website to the new server is not the problem in itsself. The Problem is, that DNS-settings sometimes take very long to take effect. They might be right at your nameserver, but that does not mean, that your visitors get the same result for a dns-query.

Most ISPs have their own DNS-machines that cache request – and some do that for a very long time – several days. Yes, and that way possible visitors for your site experience days of downtime even though your server is running perfectly.

My solution to the problem is pragmatic, but it works:

The DNS-cache serves out my old server’s IP-Adress. And because my old server stays online for at least a week after the switch (for failsave reasons etc.) I only had to find a way to make it respond to the requests that it gets because of DNS-cache.

The clue here is not to serve the page from the old server, but to retrieve the pages and files from the new server and serve them. As I had a mongrel-cluster running on my old server, most of the config was already in place. It makes use of the Apache Proxy Configuration. You basically define your new server as the host your old server proxies for. This config might not be the most elegant way to do this, but for something that should not stay online for longer than a week, I refused to spend more time researching.

So here is the config:
For each website you want to forward, write the following into you apache-config (on SuSE a new file in /etc/apache/conf.d did the trick)

<Proxy balancer://yoursite>
BalancerMember http://www.yoursite.com:80

<VirtualHost 123.456.334.332:80>
ServerNameย ย  yoursite.com:80
ServerAliasย  http://www.yoursite.com
RewriteEngine On
RewriteRule ^/(.*)$ balancer://yoursite%{REQUEST_URI} [P,QSA,L]

As I said, this might not be the most elegant solution, but it definately does the trick. ๐Ÿ˜‰

I hope, someone might find this useful. I know that it saved a few of my visitors from staring at an almost blank screen when expecting my site. ๐Ÿ˜‰


It turnes out that the above is no good for multiple domains. ๐Ÿ˜ฆ

So here is a better version:

<VirtualHost *:80>
     ServerName red.x-tend.be

     ProxyRequests off
     ProxyPreserveHost On
ย     ProxyPass / http://red.internal.x-tend.be/
     ProxyPassReverse / http://red.internal.x-tend.be/

custom Apache-config in Plesk

I ran into this problem duzens of times before: I had to make changes in my Apache-config-file to enable a feature in order to make my application work. This is especially the case for ruby-on-rails applications, because they usually require the DocumentRoot to be the “public”-directory inside the rails-app. And since both the Fast-CGI and the Passenger-way of deploying a rails-app require this, I found no other way, that to patch the config file in {domain-name}/conf/http.include.

The downside of this however is, that the next time, you make changes to the domain (or migrate it to another server or user) your changes get overwritten by Plesk, because it generates the http.include-file on the fly and does not look for changes.

But today I found the solution to this:
It turns out, Plesk supports a way for custom changes to the Apache config in so called vhost.conf files. You can put these files in the “conf” directory, both in the main directory or in the subdomain’s dir.

What you write into this file will be included directly into the <VirtualHost> block of the Apache-config.
My first vhost.conf just looked like this:

DocumentRoot /path/to/domain/httpdocs/public

That’s all! And it really works! ๐Ÿ˜‰

To make Plesk include your changes, run:

/usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=domain.com

Have fun with this feature – I know I will! ๐Ÿ˜‰

MediaWiki and mySQL

All right – one more for tonight. ๐Ÿ˜‰

I tried to migrate a MediaWiki-driven site over to the new server. And this time around I got about the same error I got last time I migrated servers.ย 

Specified key was too long; max key length is 1000 bytesย 

Guys, this really sucks! There has not been a fix to this from mySQL – neither is there a version of MediaWiki that doesn’t run into the problem – at least it seams that way. ๐Ÿ˜ฆ

However, if you run into this and have a bit of memory to spare, just turn on innoDB-support inside your my.cnf config-file. On my Ubuntu-box I just had to comment-out the “skip-innodb” line and it worked fine. However, mySQL takes up considerably more memory after the change! So I’ll try to find a different solution to this, for my server has insufficient memory as is. ๐Ÿ˜ฆย 

All right – now off to bed for real! ๐Ÿ˜‰

migrate to Plesk 9.0.1

Ok – this one is a bit special. Plesk is server-management software. You can manage your web- and emailserver with Plesk and it is really easy to use and well structured!
I have been working with Plesk since Version 7.5.x and so far it always served me well.

This week however, I finally took the plunge and migrated to a new server. And that comes with Plesk 9.0 preinstalled. After a quick update to the current version 9.0.1 I had to discover, that the number one feature I loved having Plesk on the new server didn’t work! ๐Ÿ˜ฆ
That feature is called the “migration manager” and is basically a one-click server migration. The migration had promised to be a matter of hours instead of days. However that feature didn’t make it in time for the 9.0 realease and will only reappear in 9.2 – that’s at least what the guys at Parallels (the manufacturer) are saying.
So – no option for me there, because my old server goes offline some time a week from now. ๐Ÿ˜ฆ

I looked around a bit and found an how-to on parallels website, that I would like to point others with the problem to. It explains, how to do the migration by hand (on the command-line, of which no admin should be afraid! ๐Ÿ˜‰ ). I tried it – at least the part for Customer-migration and it worked fine so far. It gives you the usual little problems, but nothing major really.
You basically run one of these commands

for the complete server:
/usr/local/psa/bin/pleskbackup all /path/to/your_backupfile

for a domain:
/usr/local/psa/bin/pleskbackup domains DOMAIN.NAME /path/to/your_backupfile

for a client/customer:
/usr/local/psa/bin/pleskbackup clients CLIENT.LOGIN /path/to/your_backupfile

on your old server (the source machine).

Then you copy that file over to the new server and run:

/usr/local/psa/bin/pre9-backup-convert -v convert -d /var/lib/psa/dumps/ BACKUP.FILE

This worked good on my new server, which runs Ubuntu 8.04 LTS.

Afterwards you can find the backups in your Plesk Panel. For domains and clients, you have to create a “blank” domain / client with the exact same name and without any hosting content (domains only). When you open the Domain / Client in Plesk Panel and click on “Backup Manager” – like magic – you will find the backups. It’s almost all downhill from there. Just click your way through and put up with the errors, that Plesk hits you with. ๐Ÿ˜‰

I have already migrated about 1/3 of my domains – and I like it so far.

I think I will call it a day and leave the rest for tomorrow. ๐Ÿ˜‰
Good night.