Plesk

04th March
2010
written by Chris

Suppose you would like to send a copy of an incoming email to another account while the email still goes to the original account. You can do this by modifying the .qmail file of the original recipient and adding an entry that looks like the following:

&user@domain.com

On a Plesk server, a full .qmail file with the above changes looks like this:

| true
&user@domain.com
| /usr/bin/deliverquota ./Maildir

Keep in mind that if you do this on a Plesk server, these changes will be overwritten with mchk or upgrades so you will have to take measures to deal with this. I set the files immutable so they can't be changed by Plesk. This causes its own problems so you will have to decide if it is worth it.

12th December
2009
written by Chris

If you need to change the TTLs on all domains in Plesk at once, you can massage the database with the following command:

mysql> UPDATE `dns_zone` SET `ttl` = '300', `ttl_unit` = '60' WHERE `id` >1;

Substitute the TTL values for what you need. Since the flat files are still used by named to provide DNS resolution, those will need to be updated as well. This command will do the trick:

mysql -Ns -uadmin -p`cat /etc/psa/.psa.shadow` -D psa -e 'select name from domains' | awk '{print "/usr/local/psa/admin/sbin/dnsmng update " $1 }' | sh
Tags: ,
21st November
2009
written by Chris

I had occassion to run across the following question recently:

"Plesk was just upgraded to version 9.2.x and all domains now have an overuse policy set to not allow overuse. I can manually change this to allow overuse, but is there a way to do this through the database so I don't have to do it a domain at a time?".

The answer is yes, sort of. Plesk provides a 'domain_pref' utility that allows the setting of many of the parameters related to domain preferences. This allows one to change parameters for domains using the command line instead of logging into the interface. It works on one domain at a time, so some scripting foo is necessary in order to accomplish this on multiple domains.

In regards to the overuse policy, this handy little one-liner will allow the updating of all domains to a specific overuse policy.

mysql -Ns -uadmin -p<plesk_admin_password_here> psa -e "select name from domains" | awk '{printf("/usr/local/psa/bin/domain_pref –update %s -overuse block\n", $1)}' | sh

There are three options available for the overuse policy.

  • Block: Do not allow overuse
  • Notify: Allow overuse and notify the domain administrator when overuse has occurred.
  • Normal: Allow overuse with no notification.

The script above does the following things:
1. Connects to the Plesk database and selects a list of all domains from the 'domains' table.
2. Runs the 'domain_pref' CLI and sets the overuse policy to 'block'.

It has also come to my attention that the clients will have to have their overuse policy set as well.

mysql -Ns -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "select login from clients" | awk '{printf("/usr/local/psa/bin/client_pref –update %s -overuse normal\n", $1)}' | sh

As always, BACK UP the psa database before doing anything with the CLI.

07th October
2009
written by Chris

This is probably one of a million different ways to fix a Plesk upgrade failure. Here are the specifics…

During an upgrade, it is very important that the hostname match the IP address in /etc/hosts because the updater will use that information to make connections, etc.

While I was doing a recent upgrade I made a typo in the hostname and all went boom. I was following along with my upgrade instructions here: http://blog.mostlychris.com/2009/04/upgrading-plesk-without-using-the-updater/

Since everything was showing as installed, I could not run up2date again after correcting the /etc/hosts typo. Here are the steps I followed to resurrect the mess I created.

1. Get the package from the site (what you put in the sources during the upgrade).
2. Force install the package.

rpm -i –force <package>

3. Since the install removes the Plesk version file, you need to restore it. You can do this by cat'ing the version file you made in the backups from the first failed upgrade.

cat version_backup > /usr/local/psa/version

4. Run the rpm install again.

rpm -i –force <package>

You may need to play around with this a bit to get it to cooperate (ie; running the rpm install a few times). Make sure the version file exists and make sure you have fixed any errors that were caused in the original upgrade before attempting this fix.

15th August
2009
written by Chris

There are times when you may need to migrate many IP addresses in Plesk. You could either do this by hand, one domain at a time or you can modify the database by hand which will save countless years of your life.

I will assume you have logged into mysql and have selected the psa database. After logging in, get a listing of IP addresses. Make sure that you have read the new IP addresses into Plesk by first logging into the control panel and performing a "Reread IP".

mysql> SELECT * FROM IP_Addresses;

You will see a list of id numbers in the first column followed by the addresses in the second column. Perform the modification of the component_id table.

mysql> UPDATE Repository SET component_id = <new id> WHERE component_id = <old id>;

Then update the hosting table.

mysql> UPDATE hosting SET ip_address_id = <new id> WHERE ip_address_id = <old id>;

Finally, update the forwarding table if necessary.

mysql> UPDATE forwarding SET ip_address_id = <new id> WHERE ip_address_id = <old id>;

Once this is done, check the IP section in Plesk and everything should be moved.

Tags: ,
Previous