Category Archives: Plesk

Plesk as a Primary DNS with InternetX/AutoDNS

Unleash the Power of Your Own DNS

Running your own primary Domain Name System (DNS) server can feel like taking the reins of your digital presence. It offers granular control and a deeper understanding of how the internet connects users to your services. When you pair a powerful control panel like Plesk with a robust DNS provider like InternetX/AutoDNS, you get a professional-grade setup that ensures reliability and performance. This guide will walk you through the essential steps to configure Plesk as your primary DNS server while using AutoDNS as a secondary, or „Hidden Primary,“ service.


Part 1: Laying the Groundwork in Plesk

Before you can hand off your DNS zones to AutoDNS, you need to get your Plesk server in order. This involves telling Plesk which nameservers are authoritative for your domains.

1. Fine-Tuning Your DNS Template

First, log into your Plesk server and navigate to the global DNS settings. This is where you’ll set up a template that will apply to all new domains you create.

  • Location: Tools & Settings => DNS Settings => DNS Template

Here, you’ll need to adjust the NS (Nameserver) records. You will be adding the nameservers provided by InternetX/AutoDNS. These act as the secondary servers that will mirror your primary Plesk DNS.

  • <domain>. NS b.ns14.net.
  • <domain>. NS c.ns14.net.
  • <domain>. NS d.ns14.net.

Crucially, don’t forget to include the nameserver for your own Plesk instance. This is your primary server!

  • <domain>. NS my-awesome-ns.xyz.

Important: You must use the fully qualified domain name (FQDN) of your server, not its IP address, for the NS record.

2. Setting the Primary Nameserver and SOA Record

Still within the DNS template, you need to explicitly define your Plesk server as the primary source of truth for your DNS zones.

  • Under the „Zone Settings Template“ tab, set the „Primary Nameserver“ to your server’s hostname: my-awesome-ns.xyz.

You may also want to review the SOA (Start of Authority) record settings. The SOA record contains important administrative information about the zone, such as the serial number and refresh timers. Some registrars require a specific format for the SOA serial number, which you can often adjust here.

3. Authorizing the Zone Transfer

A zone transfer (specifically, an AXFR) is the process by which your secondary nameservers (AutoDNS) will copy the DNS records from your primary server (Plesk). For this to happen securely, you must explicitly grant them permission.

  • Navigate to the „Transfer Restrictions Template“.
  • Add the IP addresses for the AutoDNS nameservers you added earlier. These are currently:
    • 217.160.113.32 (b.ns14.net)
    • 195.34.161.195 (c.ns14.net)
    • 74.208.164.110 (d.ns14.net)

Critical Step: InternetX/AutoDNS uses a central server to perform the actual zone transfers. You must also add its IP address to the allow list:

  • 62.116.132.5

Without this final IP, the connection will be refused, and your setup will fail.


Part 2: Configuring AutoDNS

With Plesk now ready to serve, it’s time to head over to your AutoDNS account and tell it where to pull its information from.

1. Setting Up Your Domain’s DNS Zones

In your AutoDNS dashboard, navigate to the „DNS Zones“ for the domain you’re configuring.

2. Engaging „Hidden Primary“ Mode

Select the „Nameserver“ tab. Here, you’ll change the mode to „Hidden Primary.“ This is a powerful feature that tells AutoDNS that while its nameservers will be the ones publicly listed for your domain, the actual „master“ records are held secretly on another server—your Plesk server.

Now, list the nameservers exactly as you did in the Plesk template, but with one key difference: replace a.ns14.net with your own Plesk server’s hostname (my-awesome-ns.xyz in our example).

3. Initiating the First Zone Transfer

As soon as you save these settings, AutoDNS will attempt to perform a zone transfer from your Plesk server. If it succeeds, congratulations! If not, the most common culprit is a firewall.

  • Firewall Check: Ensure that your firewall (on the Plesk server and at your hosting provider level) allows incoming TCP connections on port 53 from the AutoDNS transfer IP (62.116.132.5). While standard DNS lookups use UDP port 53, zone transfers require the more reliable TCP protocol.

You can run a quick check from any command line to see if your nameserver is responding correctly:
dig @my-awesome-ns.xyz your-domain.xyz -t NS

This command asks your Plesk server directly for the NS records of your domain. It should return the list of AutoDNS servers and your own.

4. Verifying the Records

Once the transfer is successful, refresh the page in AutoDNS. You can now switch to the „AXFR“ tab. This will display a complete copy of the DNS records it just pulled from your Plesk server. Carefully compare these entries with what you have in Plesk to ensure everything matches perfectly.


Final Step: Going Live

Once you’ve confirmed that Plesk and AutoDNS are in sync, you have one last task. You need to officially tell the domain registry about your new nameserver setup.

In AutoDNS, go to the domain’s main configuration page (not the DNS Zones section) and find the „Nameserver“ tab. Enter the exact same set of nameservers you just configured in the Hidden Primary settings.

Save your changes. This updates the domain at the registry level. And with that, you’re done!

Troubleshooting Common Errors

If you encounter an error like „ERROR: 118 Inconsistent set of NS RRs (IP, NS host names)“, it’s a clear signal that there’s a mismatch. The error means that the nameservers you are trying to assign to the domain at the registry do not match the NS records found within the DNS zone itself.

To fix this, meticulously check that the NS records in your Plesk DNS template are identical to the nameservers you’ve set in AutoDNS’s Hidden Primary configuration. Any small typo can cause this error. After making corrections, you may need to re-initiate the zone transfer and try saving the domain’s nameservers again.

Using centos 6 (with Plesk) after end of life (EOL)

If you are in need to install some software on a (very old) system, these may helps:
First of all use an archive version of plesk packaged:

plesk installer --source autoinstall-archives.plesk.com

Furthermore use need to update the source of your system packaged. This is a very good blog post about that: https://gcore.de/en/help/linux/centos6-new-repo-url-after-eol.php Thanks!

Just to be clear: Update as soon as possible to a modern system!

Plesk with Strapi 4 Node.js

To use Strapi on a Plesk server you will need an app startup file. This is one which is working for me: [server.js]

// @see https://docs.strapi.io/developer-docs/latest/development/typescript.html#start-strapi-programmatically
const strapi = require('@strapi/strapi');
const app = strapi({ 
	distDir: './dist',
	autoReload: false,
	serveAdminPanel: true,
}).start();

The „distDir“ parameter is needed when using TypeScript.

If you want, you can try to enable the „autoReload“ feature. However for me it did not worked correctly since there does not seem a parent process to process the reload event.

Plesk centos update to mysql 5.6 oder higher

If you like to upgrade your mysql installation to a newer version you may try this:

First of all we need to add a repo with contains the new mysql version. I’ve chose the one of the IUS Community

Then we need to check what currently is installed:
# rpm -qa | grep mysql
mysql-server-5.5.48-1.el6.remi.x86_64
plesk-mysql-server-12.5.30-cos6.build1205150826.19.x86_64
mysql-libs-5.5.48-1.el6.remi.x86_64
mysql-5.5.48-1.el6.remi.x86_64
compat-mysql51-5.1.54-1.el6.remi.x86_64
mysql-connector-odbc-5.1.5r1144-7.el6.x86_64
php-mysqlnd-5.6.19-1.el6.remi.x86_64

We need to remove the old stuff. Be sure to select only the parts we can really get rid off 🙂 Never every remove the one which starts with plesk-mysql-server !

rpm -e --nodeps mysql-server-5.5.48-1.el6.remi.x86_64 mysql-libs-5.5.48-1.el6.remi.x86_64 mysql-5.5.48-1.el6.remi.x86_64 compat-mysql51-5.1.54-1.el6.remi.x86_64 compat-mysql51-5.1.54-1.el6.remi.x86_64

Now install the new one. In my case I want mysql 5.7:
yum install mysql57u-server.x86_64 mysql57u.x86_64

Since the databases are in the old format we need to upgrade them to work with the new server version:
mysql_upgrade -u admin -p`cat /etc/psa/.psa.shadow`

This may take a while. After that you should restart the mysql server.

If you every modified /etc/my.cnf you may should have a look since it may reset to the defaults. But don’t worry. The original one should be saved to my.cnf.rpmsave (or something similar).

That’s it!

How delete single mails from the mail queue of postfix (PLESK)

If you like to delete mails from the mail queue of postfix on a given pattern (from/sender email) you can use this command:


postqueue -p | grep "name@sender.toplevel" | cut -f 1 -d ' ' | xargs -n 1 postsuper -d

 

  • postqueue -p you’ll get the queue.
  • grep just selects the line with the sender AND the message id.
  • cut extracts the message id.
  • xargs/postsuper will delete the message

Plesk: mysql admin password

Since Version 10 it’s possible that the password of the mysql database of Plesk is, well they call it encrypted. This is basically fine, but may can run you in some trouble. For example if you like to install you own global phpMyAdmin installation and then try to log in as admin.

You’ll first try will be to use the same password as you will use when log in to Plesk. That will not work! Then you’ll may step over the ssh shell and type in

cat /etc/psa/.psa.shadow

This will give you something like

$AES-128-CBC$X...==

Yeah … that looks like the password is encrypted. As Plesk admin you know an other way to get the password

/usr/local/psa/bin/admin --show-password

This will output the password you already tried. Then you’ll dig around the internet and may find this cmd

mysql -uadmin -p`cat /etc/psa/.psa.shadow`

And … it’s working! You get access to mysql. Hmm … now you’re may a bit confuse. But thing about it. If you want to access your mysql database outside of Plesk you have to use the whole output of

cat /etc/psa/.psa.shadow

as password! Even if it look like it’s encrypted. This is your database password!

 
If you don’t like to have such a super long password and can live with a plain text password in the file /etc/psa/.psa.shadow you can change it back. But remember to repeat this every time you change the password via the Plesk panel 🙂

/usr/local/psa/bin/init_conf -u -passwd 'some_password' -plain-password

 
Alternative you can add an other user with full admin rights to your database.

Plesk: Get password of an email account

As server admin you are sometimes in the need to know the password of an email address. Plesk is making this very easy. Just run this command and you’ll get a list of all mail accounts of your server. Also the plain text password of the accounts are shown 🙂


/usr/local/psa/admin/sbin/mail_auth_view

 
Of course of have to adjust the path to your Plesk installation.

Typo3: „Cannot find tslib“ and „Lock file could not be created“

Recently I had to move my Typo3 Installation from one server to new one. It should be easy to move. However the reality is another one 😉 In specialty if you are using Plesk.

After I used the MigrationManager of Plesk the site wasn’t running. I got the message

Cannot find tslib/. Please set path by defining $configured_tslib_path in index.php.

A quick search showed up that the symbolic link of the global typo3 installation isn’t working. I’ve checked that but it was correct. But then I got an idea: The old installation was running on Plesk Version 9 and the new one on Version 11. In Version 9 you hat to the open_basedir youself via the vhost.conf file. Since Version 11 you can (and have to) do this via the web interface. So I changed the php setting of the subscription to {WEBSPACEROOT}/:{TMP}/:/srv/typo3 (where /srv/typo3 is the path to my global Typo3 installation) and I got a step further.

Next try to load the site. After a while just a blank page showed up. Quick view into the error_log show this message

Lock file could not be created
Exception thrown in file ...

This is an easy one: Just adjusted the permissions of you typo3temp directory and everything went fine.

Typo3 cli_dispatch.phpsh scheduler Exception ‚localconf.php is not found!‘

After a system update or something else it may happen you get an Exception of your Typo3 Installation. It’s not always the main site but can also could be your „cron“ scripts (cli_dispatch.phpsh)

Fatal error: Uncaught exception 'Exception' with message 'localconf.php is not found!' in ../t3lib/config_default.php:707
Stack trace:
#0 ../typo3/sysext/cms/tslib/index_ts.php(128): require()
#1 ../index.php(84): require('...')
#2 {main} thrown in ../t3lib/config_default.php on line 707


or

Fatal error: Uncaught exception 'Exception' with message 'localconf.php is not found!' in ../t3lib/config_default.php:707
Stack trace:
#0 .../typo3/init.php(206): require()
#1 .../typo3/index.php(63): require('...')
#2 {main} thrown in .../t3lib/config_default.php on line 707

Of course the line numbers could be different 😉
So …. what’s the problem? It so simple that you just forget how you solved it the last time. „Last time? I don’t remember that there was a last time!?“. But you did!
Just check the php.ini and ensure that safe_mode = Off is set. Furthermore check the open_basedir setting. Ensure that (when used at all) all needed directories are set.

Plesk and „qq trouble in home directory“

After upgrading Plesk from an old, but working, 8.6.0 to a recent version everything worked fine afterwards. Then I did the „mistake“ and enabled the build-in greylisting feature. Out of sudden I wasn’t able to send a mail anymore. I got a „qq trouble in home directory“ error message.

Hmm … Bad!. Ok. First I checked the permissions of the qmail installation. All fine. So I searched around. A lot of people out there are having the same problem. It’s the greylisting feature! Plesk qmail thinks we are an extern sender and routes even local domains through the greylist. Bump!

So you may think: „A lot of people are having the same problem, so there is a quick solution!“. Nope – There isn’t! It take some a lot of hours to find a solution by myself. At all it’s easy – if you know how 🙂

So what to do? Since Plesk Version 9.0 you can choose your MTA between qmail and postfix. However the postfix implementation is causing more problems then the qmail one. So I still use qmail. Via the autoinstaller script of Plesk you can easily switch between these two MTAs. And that’s was the solution of my qmail „qq trouble in home directory“ problem.
Start the autoinstaller /usr/local/psa/admin/bin/autoinstaller. On the component list choose Postfix mailserver and continue. The script will uninstall the qmail mailserver and install the postfix mailserver. All current mails will keep in place. So don’t worry (however a backup is always and every time a good idea :-)). The completion of the script takes several minutes. After that do the same thing but select Qmail mailserver. For me it worked fine and the „qq trouble in home directory“ error was gone.

Quick ToDo:

  • Start /usr/local/psa/admin/bin/autoinstaller
  • Select Postfix mailserver as mailserver
  • Finish the installation
  • Start /usr/local/psa/admin/bin/autoinstaller
  • Select Qmail mailserver as mailserver
  • Finish the installation
  • Done