Parallels Plesk Panel

In 2013 I packaged PHP versions 5.4, 5.5 and 5.6 into RPMs suitable for installing and running in my Plesk-box. PHP is a programming language, more about that @ https://www.php.net/. Plesk is a web-hosting platform, more about that @ https://www.plesk.com/.

As I chose to distribute my work freely (see announcement https://talk.plesk.com/threads/centos-6-4-php-versions-5-4-and-5-5.294084/), because there wasn't that much innovation there. I just enabled multiple PHP versions to co-exist on a single server as I needed that feature myself. In 2015 Plesk decided to take my freely distributed packages and started distributing them as their own. They didn't even change the names! A sucker move, that.

However, I said it then and will say it now: that's just how open-source works. You take somebody else's hard work, bring something of your own and elevate it to the next level. Nothing wrong with that. However, a simple "Thanks!" would do it for me. Never got one from big greedy corporation.

In this case, the faceless corpo brought in stability, continuity and sustained support. Something I would never even dream of providing. I'm a single man, a hobbyist. What they have is teams of paid professionals. They completed the parts I never needed and fixed the wrinkles I made. Given the high quality of my and their work, ultimately all my boxes have been running PHP from their repo ever since.

This summer, something changed.

My /etc/yum.repos.d/plesk-php.repo had something like this for years:

baseurl=http://autoinstall.plesk.com/PHP_7.2/dist-rpm-CentOS-$releasever-$basearch/

I was stuck at PHP 7.2.19, something that was released in May 2019. Six months had passed and I had no updates. On investigation I bumped into https://docs.plesk.com/release-notes/obsidian/change-log/#php-191126. It states for 26th November 2019 for PHP 7.2.25 to be available for Plesk. That's like a big WHAAAAAAT!

More investigation was needed. I actually got a fresh VM, downloaded Plesk installer and started installing it to get the correct URL for PHP repo. It seems to be:

baseurl=http://autoinstall.plesk.com/PHP73_17/dist-rpm-CentOS-$releasever-$basearch/

Ta-daa! Now I had PHP 7.3.12:

# rpm -q -i plesk-php73-cli
Name : plesk-php73-cli
Epoch       : 1
Version     : 7.3.12
Release     : 1centos.8.191122.1343
Architecture: x86_64
Source RPM  : plesk-php73-cli-7.3.12-1centos.8.191122.1343.src.rpm
Build Date  : Fri 22 Nov 2019 01:43:45 AM EST
Build Host  : bcos8x64.plesk.ru
Packager    : Plesk <info@plesk.com>
Vendor      : Plesk
Summary     : Command-line interface for PHP
Description :
The php-cli package contains the command-line interface
executing PHP scripts, /usr/bin/php, and the CGI interface.

Actually PHP 7.4 is also available, just replace PHP73_17 with PHP74_17, to get the desired version.

PS.
Most of you are super-happy about your Apache/PHP -pair your distro vendor provides. If you're like me and ditched Apache, getting Nginx to run PHP requires some more effort. And if your requirements are to run a newer version of PHP than your vendor can provide, then you really short on options. Getting tailored PHP from Plesk's repo and pairing that with you Nginx takes one stresser out.

Last year I spent couple of days tinkering PHP-packages that will work on my Parallels Plesk Panel box. To my surprise, my box failed to auto-upgrade itself. The reason was: "Exception: Failed to solve dependencies:
plesk-php54-mysqlnd-5.4.31-1.el6.x86_64 requires plesk-php54-pdo = 5.4.31-1.el6
plesk-php55-mysqlnd-5.5.6-1.el6.x86_64 requires plesk-php55-pdo = 5.5.6-1.el6". I was dumbfounded, as the proper packages were already installed.

A closer inspection revealed, that packages from my own repository weren't good for installation. There were package dependencies, that required packages with exactly the same name, but from somebody else's repository.

Here are some links:

• http://autoinstall.plesk.com/PHP_5.4.40/dist-rpm-CentOS-6-x86_64/packages/
• http://autoinstall.plesk.com/PHP_5.5.24/dist-rpm-CentOS-6-x86_64/packages/
• http://autoinstall.plesk.com/PHP_5.6.8/dist-rpm-CentOS-6-x86_64/packages/

If you need to install new version, do something like this:

yum install --enablerepo PHP_5_6_8-dist plesk-php56-cli

The information for those came from file /etc/yum.repos.d/autoinstaller-sources.repo.

My only conclusion is, that Parallels guys took my source RPMs and created their own. Thanks for ripping me off!
Ok, this is open-source. I put my stuff out there willingly and knowing, that somebody eventually will use it. The sensible thing to do is to give appropriate credit, though. That one the big greedy corporation didn't do.

I updated all Parallels Plesk Panel PHP-versions to latest. Included in my yum-repo, there is a PHP 5.6.0 version with fully working PHP-FPM.

If something doesn't work in PHP 5.6, please drop me a comment. 

All the nerds like me (escpecially me!) love new versions of software.

Backup

I got new toys for my Parallels Plesk Panel box and went for the automated upgrade. I attempted to do the mandatory full backup first:

/usr/local/psa/bin/pleskbackup server \
 --output-file=/Backups/pre-12.0.18.backup.tar -v -v

... just to make sure, that I have something to roll back to if it hits the fan. But it kept failing on me. Any domains having PostgreSQL databases failed to backup properly. I got log entries like:

Failed to execute backup database
Failed to pack files backup_hqcs_blog_1407141359 in /dumps/domains/hqcodeshop.fi/databases/hqcs_blog [ 115057410048 bytes free of 158532106240 bytes total on mount point 0]

Totally puzzling. Didn't make any sense at all! Looking at the detailed XML-log of the backup revealed following:

<?xml version="1.0" encoding="UTF-8"?>

<object name="server" type="server">
    <object name="hqcodeshop.fi" type="domain" uuid="domain#hqcodeshop.fi">
        <object name="hqcs_blog" type="postgresql">
            <message id="e6d718ef-5b52-49af-8c4f-4473393b30bd" severity="error" code="msgtext">
                <description>Failed to execute backup database</description>
            </message>
            <message id="d5e6cfd1-fa94-45d4-89b6-a47a0627134a" severity="warning" code="msgtext">
                <description>sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                </description>
            </message>
        </object>
    </object>
</object>

What command not found!? After a few puzzling moments later I realized it, that is the end of my panel admin's password! In the original form the password was [lot of characters here]>AB12. Somebody at the Parallels goofed! What would happen if your password has special characters. What if some of those characters were special in your command prompt? Not very solid backup code, huh!

The next thing was to change the password to one not containing any of these characters £$<>()&;"'`, they have special meaning on *nix command prompt. I always use randomly generated passwords and during my quests I regularily bump into systems that do not sanitize user input properly. I find that the ones from the number keys with shift are especially nasty. During registration process it is very easy to input a proper random passwod, but the system botches something and don't let me log in, or does something nasty like Parallels Plesk did.

Unfortunately changing the admin password didn't make the backup succeed! Apparently PostgreSQL password is stored somewhere else. I did do a:

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

... to confirm, that system knows what the new password was. The thing is, that PostgreSQL password needs to be changed manually. I found the knowledge base article about that KB 120262 - How to update password for PostgreSQL admin user in Plesk? Running:

# plesk bin database-server --update-server localhost:5432 \
 -type postgresql \
-passwd `/usr/local/psa/bin/admin --show-password`
SUCCESS: Server localhost:5432 is successfully updated.

... did solve it. Then I managed to get backups.

Upgrade

There were no issues during upgrade. The web-upgrader took a while and then it said everything was done. There really was nothing special about this part.

During my checkings I found a really good knowledge base article about system settings. This is something that Parallels didn't have for previous versions. This is really good stuff: Parallels Plesk Panel for Linux services logs and configuration files. I kept going back to that one a lot.

Testing

When the new version was running, I naturally wanted to see that all my services were running properly. Things I found to be broken were POP3 and IMAP SSL-certificates. Also the Presence Builder didn't upgrade properly.

The funny thing about Courier IMAP/POP3 was, that upgrade reset my certificate settings back to something really stupid. I went to /etc/courier-imap/ to check the imapd-ssl and pop3d-ssl. I changed both of them to contain:

TLS_PROTOCOL=TLS1

That was done to reflect the setting I have in my /etc/postfix/main.cf:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

My policy is, that if you're running something that does not support TLSv1, v1.1 nor v1.2 then you should use somebody else's services. It simply is insane to rely on SSL!

The Web Presence Builder said this on startup:

File: /usr/local/sb/include/Base/ORM/Object.php; Line: 249
Message: Undefined property "controlPanelLink" in object "SB_ORM_TokenAccess".; Code: 0

Luckily, that issue is covered by knowledge base article KB 119875: Cannot open a site in Web Presence Builder: "Undefined property "controlPanelLink" in object "SB_ORM_TokenAccess". A simple SQL-command:

ALTER TABLE `token_access` ADD `control_panel_link` VARCHAR( 255 ) NULL DEFAULT '' AFTER `skin_code`;

did do the fix.

Life after the upgrade

My system has been running as usual. There hasn't been any complaints from the users or I have not encountered anything else that didn't work.

The latest PHP versions are available for CentOS Plesk Panel admins. If you are using my YUM-repo as suggested, the update should be a painless one.

I managed to get the FPM running for PHP 5.4, for the PHP 5.5 it is still pending. Example:

# service php-fpm54 status     
php-fpm (pid  4318) is running...

Please note, that the FPM is still work-in-progress and it may contain bugs.

The latest PHP FPM has a fix for CVE-2014-0185. It is not a really dangerous one, it just takes care of 0666 permissions for the FastCGI unix-socket. It can be considered a security flaw if any local user can execute code via FastCGI-interface. Most web-servers don't have many local users, but this flaw can be combined with other security issues to get more gain out of it.

I maintain RPM-packages for PHP 5.4 and 5.5, see earlier post about it.

As any sysadmin can expect, there was too much trouble running the updates. Since CentOS 6 native way is running yum repositories, I created one.

Kick things going by installing the repo-definition:

yum install \
 http://opensource.hqcodeshop.com/CentOS/6%20x86_64/Parallels%20Plesk%20Panel/plesk-php-repo-1.0-1.el6.noarch.rpm

After that, a simple yum install command:

yum install plesk-php55

... will yield something like this:

/opt/php5.5/usr/bin/php -v
PHP 5.5.9 (cli) (built: Feb  9 2014 22:04:05)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

I'll be compiling new versions to keep my own box in shape.

Earlier I had trouble with with a disabled DNS-zone not staying disabled. I'm running version 11.5.30 Update #32.

The problem bugged me and I kept investigating. To debug, I enabled the DNS-zone and actually transferred it with AXFR to an external server. There I realized, that the SOA-record was bit strange. Further trials reveald that in the NS-records, there was always an extra one. With that in mind, I went directly to the database to see what I had stored there for the zone.

To access the MySQL database named psa, I have to get the password for that. See KB article ID 170 [How to] How can I access MySQL databases in Plesk? for details about that. The database schema is not documented, but it has become familiar to me during all the years I've been sysadmining Plesk Panels. To get the ID for the DNS-zone I did:

SELECT *
FROM dns_zone
WHERE name = '-the-zone-';

And what do you know! There were two IDs for the given name. That is a big no-no. It's like you having two heads. A freak of nature. It cannot happen. It is so illegal, that there aren't even laws about it. To fix that I did rename the one with a smaller ID:

UPDATE dns_zone
SET name = '-the-zone-_obsoleted', displayName = '-the-zone-_obsoleted'
WHERE id = -the-smaller-ID-;

After that a manual refresh of the BIND records from the DB:

/usr/local/psa/admin/bin/dnsmng --update -the-zone-

And confirmation from the raw BIND-file:

less /var/named/chroot/var/-the-zone-

Now everything was in order. I'm hoping that will help and keep the zone disabled. To me it is now obvious why that happened. Database had become badly skewed.

Parallels has "improved" their support-policy. Now you need support contract or pre-purchased incidents just to report a bug. Because my issue is not on my own box (where I have support), but on a customer's server, there is nobody left for me to complain about this. So, here goes:

For some reason on Parallels Plesk Panel 11.5.30 Update #30 (which is the latest version at the time of writing this) a single and every time the same domain creates a DNS-zone into /etc/bind.conf. That would be fully understandable, if that particular domain would have the DNS enabled. It doesn't. The web-GUI clearly indicates the DNS-service for the domain as switched off.

I did investigate this and found that couple of commands will temporarily fix the issue:

/usr/local/psa/bin/dns --off -the-domain-
/usr/local/psa/admin/sbin/dnsmng --remove -the-domain-

The first command will hit the DNS with a big hammer to make sure it is turned off. The second command will polish the leftovers from the /etc/bind.conf and properly notify BIND about configuration change. The problem is, that the zone will keep popping back. I don't know what exactly makes it re-appear, but it has done so couple of times for me. That is really, really annoying.

Parallels: You're welcome. Fix this for the next release, ok?

Rest of you: Hopefully this helps. I had a nice while debugging really misguided DNS-queries just to figure out a zone has DNS enabled.

One of my servers is running Parallels Plesk Panel 11.5 on a CentOS 6. CentOS is good platform for web hosting, since it is robust, well maintained and it gets updates for a very long time. The bad thing is that version numbers don't change during all those maintenance years. In many cases that is a very good thing, but when talking about web development, once a while it is nice to get upgraded versions and the new features with them.

In version 10 Parallels Plesk introduced a possibility of having a choice for the PHP version. It is possible to run PHP via Apache's mod_php, but Parallels Plesk does not support that. The only supported option is to run PHP via CGI or FastCGI. Not having PHP via mod_php is not a real problem as FastCGI actually performs better on a web box when the load gets high enough. The problem is, that you cannot stack the PHP installation on top of each other. Different versions of a package tend to reside in the same exact physical directory. That's something that every sysadmin learns in the beginning stages of their learning curve.

CentOS being a RPM-distro can have relocatable RPM-packages. Still, if you install different versions of same package to diffent directories, the package manager complains about a version having been installed already. To solve this and have my Plesk multiple PHP versions I had to prepare the packages myself.

I started with Andy Thompson's site webtatic.com. He has prepared CentOS 6 packages for PHP 5.4 and PHP 5.5. His source packages are mirrored at http://nl.repo.webtatic.com/yum/el6/SRPMS/. He did a really good job and the packages are excellent. However, the last problem still resides. Now we can have a choice of the default CentOS PHP 5.3.3 or Andy's PHP 5.4/5.5. But only one of these can exist at one time due to being installed to the same directories.

My packages are at http://opensource.hqcodeshop.com/CentOS/6 x86_64/Parallels Plesk Panel/ and they can co-exist with each other and CentOS standard PHP. The list of changes is:

• Interbase-support: dropped
• MySQL (the old one): dropped
• mysqlnd is there, you shouldn't be using anything else anyway
• Thread safe (ZTS) and embedded versions: dropped
• CLI and CGI/FastCGI are there, the versions are heavily optimized to be used in a Plesk box
• php-fpm won't work, guaranteed!
• I did a sloppy job with that. In principle, you could run any number of php-fpm -daemons in the same machine, but ... I didn't do the extra job required as the Plesk cannot benefit from that.

After standard RPM-install, you need to instruct Plesk, that it knows about another PHP. Read all about that from Administrator's Guide, Parallels Plesk Panel 11.5 from the section Multiple PHP Versions. This is what I ran:

/usr/local/psa/bin/php_handler --add -displayname 5.4 \
  -path /opt/php5.4/usr/bin/php-cgi \
  -phpini /opt/php5.4/etc/php.ini \
  -type fastcgi

After doing that, in the web hosting dialog there is a choice:

Note how I intentionally called the PHP version 5.4.22 as 5.4. My intention is to keep updating the 5.4-series and not to register a new PHP-handler for each minor update.

Also on a shell:

-bash-4.1$ /usr/bin/php -v
PHP 5.3.3 (cli) (built: Jul 12 2013 20:35:47)

-bash-4.1$ /opt/php5.4/usr/bin/php -v
PHP 5.4.22 (cli) (built: Nov 28 2013 15:54:42)

-bash-4.1$ /opt/php5.5/usr/bin/php -v
PHP 5.5.6 (cli) (built: Nov 28 2013 18:20:00)

Nice! Now I can have a choice for each web site. Btw. Andy, thanks for the packages.

The mail disable cannot be done via GUI. Going to subscription settings and un-checking the Activate mail service on domain -setting does not do the trick. Mail cannot be disabled for a single domain, the entire subscription has to be disabled. See KB Article ID: 113937 about that.

I found a website saying that domain command's -mail_service false -setting would help. It does not. For example, this does not do the trick:

/usr/local/psa/bin/domain -u domain.tld -mail_service false

It looks like this in the Postifx log /usr/local/psa/var/log/maillog:

postfix/pickup[20067]: F2B5222132: uid=0 from=<root>
postfix/cleanup[20252]: F2B5222132: message-id=<20131128122425.F2B5222132@da.server.com>
postfix/qmgr[20068]: F2B5222132: from=<root@da.server.com>, size=4002, nrcpt=1 (queue active)
postfix-local[20255]: postfix-local: from=root@da.server.com, to=luser@da.domain.net, dirname=/var/qmail/mailnames
postfix-local[20255]: cannot chdir to mailname dir luser: No such file or directory
postfix-local[20255]: Unknown user: luser@da.domain.net
postfix/pipe[20254]: F2B5222132: to=<luser@da.domain.net>, relay=plesk_virtual, delay=0.04, delays=0.03/0/0/0, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
postfix/qmgr[20068]: F2B5222132: removed

not cool.
However KB Article ID: 116927 is more helpful. It offers the mail-command. For example, this does do the trick:

/usr/local/psa/bin/mail --off domain.tld

Now my mail exits the box:

postfix/pickup[20067]: 5218222135: uid=10000 from=<user>
postfix/cleanup[20692]: 5218222135: message-id=<mediawiki_0.5297385c4d15f5.15419884@da.server.com>
postfix/qmgr[20068]: 5218222135: from=<user@da.server.com>, size=1184, nrcpt=1 (queue active)
postfix/smtp[20694]: certificate verification failed for aspmx.l.google.com[74.125.136.27]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
postfix/smtp[20694]: 5218222135: to=<luser@da.domain.net>, relay=ASPMX.L.GOOGLE.COM[74.125.136.27]:25, delay=1.1, delays=0.01/0.1/0.71/0.23, dsn=2.0.0, status=sent (250 2.0.0 OK 1385642077 e48si8942242eeh.278 - gsmtp)
postfix/qmgr[20068]: 5218222135: removed

Cool!

My adventures with Parallels Plesk Panel's API continued. My previous fumblings can be found here. A fully working application started to say:

11003: PleskAPIInvalidSecretKeyException : Invalid secret key usage. Please check logs for details.

Ok. What does that mean? Google (my new favorite company) found nothing with that phrase or error code. Where is the log they refer to?

After a while I bumped into /usr/local/psa/admin/logs/panel.log. It said:

2013-10-16T11:34:35+03:00 ERR (3)  [panel]: Somebody tries to use the secret key for API RPC "-my-super-secret-API-key-" from "2001:-my-IPv6-address-"

Doing a:

/usr/local/psa/bin/secret_key --list

revealed that previously they accepted an IPv4 address for secret key, but apparenly one of those Micro-Updates changed the internal policy to start using IPv6 if one is available.

When I realized that, it was an easy fix. The log displayed the IP-address, I just created a new API-key with secret_key-utility and everything started to work again.

Parallels: Document your changes and error codes, please.

For some unknown reason a customer's backup job hung. A ps axuww looked like this after a failed kill 3150 attempt:

3150 ?        Z      0:00 [mysqldump] <defunct>

There was no other way of getting rid of that other than a reboot. It didn't help, though. It automatically re-started the backup job and did the same thing again.

All customer's services were disabled, there was Suspend domain until backup task is completed -setting enabled. At that point I was really screwed. The backup job turned undead and all customer's services were out of action. Nice going! The message that was given from Parallels Panel at control panel was: "The subscription is temporarily suspended until the backup or restore process is complete".

Parallels forums had an article about unsuspending a domain. I did the same thing for a subscription. Apparently at the time of writing in Plesk 9, there were no subscriptions. So I ran this:

/usr/local/psa/bin/subscription -u customer's domain name here.com  -status enabled

It helped! It un-suspended the services. The backup is not working yet, but the services were running again. I need to further investigate the backup issue and get back about that.