CentOS 6 PHP 5.4 and 5.5 yum repository
Wednesday, February 19. 2014
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.
Parallels Plesk Panel: Bug - DNS zone twice in DB
Sunday, February 16. 2014
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.