tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: upgrade glitches with php, maybe
> Date: Thu, 27 Mar 2025 12:36:35 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
>
> I just updated a a server to 2025Q1 (well, pkgsrc-current almost to
> that) and had some php_trouble.
This sounds very bad and, in my estimation (not having any position of
authority here), a reasonable candidate for a showstopper, so I
investigated.
I was not able to reproduce your symptoms, but I did hit several other
serious usability and security problems for users. I believe this
needs some urgent attention for anyone using PHP binary packages.
> pkgin add php82 and removed php, and updated many php82-foo. That seems
> good.
>
> I found that php_fpm's listening config was not consistent with that of
> nginx. I set this up long enough ago that I don't remember.
>
> It feels like /usr/pkg/etc/php/php_fpm.conf was deleted even though it
> was modified. And probably php.ini. I'll check backups. But, I wanted
> to
www/php-fpm/Makefile reads (before/after the multiversion php change):
-CONF_FILES= ${EGDIR}/php-fpm.conf ${PKG_SYSCONFDIR}/php-fpm.conf
...
+CONF_FILES= ${PREFIX}/${PHP_EGDIR}/php-fpm.conf ${PKG_SYSCONFDIR}/php-fpm.conf
Two builds of the package read:
-# FILE: etc/php-fpm.conf c share/examples/php/php-fpm.conf 0644
...
+# FILE: etc/php/8.2/php-fpm.conf c share/examples/php/8.2/php-fpm.conf 0644
So I think it is unlikely that a file called `php_fpm.conf' was
touched. However, it's possible you confused it with a file
previously called /usr/pkg/etc/php-fpm.conf, and now (after the
multiversion php change) called /usr/pkg/etc/php/8.2/php-fpm.conf.
There are expected to be some differences in these files:
--- a/share/examples/php/php-fpm.conf 2024-12-28 16:30:09.000000000 +0000
+++ b/share/examples/php/8.2/php-fpm.conf 2025-03-15 12:57:02.000000000 +0000
@@ -14,14 +14,14 @@
; Pid file
; Note: the default prefix is /var
; Default Value: none
-pid = run/php-fpm.pid
+pid = run/php-fpm82.pid
; Error log file
; If it's set to "syslog", log is sent to syslogd instead of being written
; into a local file.
; Note: the default prefix is /var
; Default Value: log/php-fpm.log
-;error_log = log/php-fpm.log
+;error_log = log/php-fpm82.log
; syslog_facility is used to specify what type of program is logging the
; message. This lets syslogd specify that messages from different facilities
@@ -140,4 +140,4 @@
; Relative path can also be used. They will be prefixed by:
; - the global prefix if it's been set (-p argument)
; - /usr/pkg otherwise
-include=/usr/pkg/etc/php-fpm.d/*.conf
+include=/usr/pkg/etc/php/8.2/php-fpm.d/*.conf
> 2) ask if my belief that a user-modified config file should never be
> deleted by pkg_* and pkgin is shared by others and believed to be how
> it is.
This belief is correct and such a deletion, if confirmed, should be
treated as a severe regression that should hold up the branch.
The existing logic in mk/pkginstall/deinstall that is pasted into
php82-fpm-8.2.26nb11 deinstall script reads:
# Remove configuration files if they don't differ from the default
# config file.
#
${TEST} ! -x ./+FILES ||
./+FILES REMOVE ${PKG_METADATA_DIR}
This calls into the REMOVE logic in mk/pkginstall/files, with the
following input embedded in the php82-fpm-8.2.26nb11 install script:
# FILE: etc/php-fpm.conf c share/examples/php/php-fpm.conf 0644
which is broken into
file=etc/php-fpm.conf
f_flags=c
f_eg=share/examples/php/php-fpm.conf
f_mode=0644
f_user=
f_group=
The REMOVE logic deletes $file only under the conjunction of certain
conditions:
(a) The refcount token file exists and matches this package.
AND
(b) Some other condition about the refcount token file I didn't
follow.
AND
(c) The file is not marked preexisting.
AND
(d) $file exists as a regular file.
AND
(c) $f_eg exists as a regular file or a device special file.
AND
(e) `${CMP} -s "$file" "$f_eg"` exits zero, i.e., the configuration
file $file is identical in content to the example $f_eg.
AND
(f) $f_flags contains `f' (here it does not), OR
$f_flags does not contain `r' and _PKG_CONFIG=yes, OR
$f_flags contains `r' and _PKG_CONFIG=yes and _PKG_RCD_SCRIPTS=yes.
_PKG_CONFIG and _PKG_RCD_SCRIPTS are sanitized versions of the
environment variables PKG_CONFIG and PKG_RCD_SCRIPTS from the
environment, which default to yes.
You can verify whether or not your config file was modified by
fetching the old package and extracting the example file, for now. My
guess is that you used this package:
https://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All/php82-fpm-8.2.26nb11.tgz
> Or is there some purge-harder mode invoked by pkgin when superceding?
> If so, I think that's a bug.
I can't fathom this as a thing that would happen and I would begin to
question sanity if it did. In fact it doesn't look like pkgin is
doing any superseding at all here.
I attempted to reproduce this from your approximate instructions, and
I failed to reproduce it but I did hit snag with updating which makes
me suspect that the multiversion php change is not working right and
still needs (a) more work and (b) an automated testbed to verify
upgrades from the ancien regime.
In a fresh NetBSD 10.0 installation, I ran:
# PKG_PATH=https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All pkg_add pkgin
# pkgin up
# pkgin -V in php82-fpm
Then I edited /usr/pkg/etc/php-fpm.conf to add local changes, and I
created a file called /usr/pkg/etc/php/php_fpm.conf with something
recognizable in it.
I took a zfs snapshot to compare before/after at this point.
Next, I mounted a pkgsrc-current build at /mnt (from shadow.n.o),
replaced /usr/pkg/etc/pkgin/repositories.conf by file:///mnt/All, and
ran:
# pkgin up
# pkgin -V in php82
(I'm not sure if this is the right way forward. Perhaps the right way
forward was `pkgin ug' instead but I was following your message where
you said: `pkgin add php82 and removed php, and updated many
php82-foo. That seems good.' I interpreted `pkgin add' to mean
`pkgin in', although now I see you probably meant to just say
descriptively that `pkgin [ug] added php82, removed php, and updated
many php82-foo'.)
This prompted me without issue:
calculating dependencies...done.
2 packages to refresh:
readline-8.2nb2 xmlcatmgr-2.2nb1
3 packages to upgrade:
libxml2-2.12.10 pcre2-10.45 php82-fpm-8.2.28nb12
1 package to install:
php82-8.2.28
0 to remove, 2 to refresh, 3 to upgrade, 1 to install
0B to download, 47M of additional disk space will be used
proceed ? [Y/n]
During the course of the installation, it printed the following
message:
The following files are no longer being used by php82-fpm-8.2.26nb11,
and they can be removed if no other packages are using them:
/usr/pkg/etc/php-fpm.conf
This tells me that it did not delete my locally modified
/usr/pkg/etc/php-fpm.conf, and, sure enough, there were no changes.
However, it proceeded to fail after updating several packages:
pkg_add: Package `php82-8.2.28' conflicts with `php-[0-9]*', and `php-8.2.26' is installed.
pkg_add: Can't install dependency php82>=8.2.0<8.3
pkg_add: Expected dependency php82>=8.2.0<8.3 still missing
pkg_add: 1 package addition failed
[6/6] installing php82-8.2.28...
pkg_add: Package `php82-8.2.28' conflicts with `php-[0-9]*', and `php-8.2.26' is installed.
pkg_add: 1 package addition failed
reading local summary...
processing local summary...
At this point, the only manually installed package was pkgin itself:
# pkg_info -u
pkgin-24.12.0 Apt / yum like tool for managing pkgsrc binary packages
This itself appears to be a problem: `pkgin in php82' had the effect
of (upgrading some packages and) _deleting_ php82-fpm. However, it
left both /usr/pkg/etc/php-fpm.conf and /usr/pkg/etc/php/php_fpm.conf
intact.
Next, I tried `pkgin ug'. It did not suggest replacing php-8.2.6 by
php82-8.2.8:
calculating dependencies...done.
1 package to refresh:
pkgin-24.12.0
2 packages to upgrade:
pkg_install-20250219 sqlite3-3.48.0
0 to remove, 1 to refresh, 2 to upgrade, 0 to install
0B to download, 194K of additional disk space will be used
proceed ? [Y/n] n
This is in spite of the fact that the pkg_summary.gz has
PKGNAME=php82-8.2.28
...
SUPERSEDES=php-[0-9]*
which strikes me as another problem: users who try to upgrade naively
will get stuck with outdated PHP packages.
Now, it's not clear to me _which_ php package is actually supposed to
supersede php-[0-9]* since php56, php74, php81, php82, php83, and
php84 all claim to be successors of exactly the same pattern. Perhaps
the patterns should be more like:
PKGNAME=php82-8.2.28
...
SUPERSEDES=php-8.2.*
Next, I tried `pkgin in php82-fpm' again, in attempt to get back the
package that pkgin unceremoniously deleted:
# pkgin -V in php82-fpm
calculating dependencies...done.
2 packages to install:
php82-8.2.28 php82-fpm-8.2.28nb12
0 to remove, 0 to refresh, 0 to upgrade, 2 to install
0B to download, 60M of additional disk space will be used
proceed ? [Y/n]
[1/2] installing php82-8.2.28...
pkg_add: Package `php82-8.2.28' conflicts with `php-[0-9]*', and `php-8.2.26' is installed.
pkg_add: 1 package addition failed
[2/2] installing php82-fpm-8.2.28nb12...
pkg_add: Package `php82-8.2.28' conflicts with `php-[0-9]*', and `php-8.2.26' is installed.
pkg_add: Can't install dependency php82>=8.2.0<8.3
pkg_add: Expected dependency php82>=8.2.0<8.3 still missing
pkg_add: 1 package addition failed
I appear to be stuck, unless I manually delete php-8.2.26.
So, there are several issues here, all of which I would describe as
serious:
1. When I ran `pkgin in php82', pkgin detected no issues up front,
began to delete packages, and then failed partway through.
2. pkgin is unable to use the SUPERSEDES relations to resolve the
php82-fpm dependencies.
3. `pkgin ug' doesn't even recognize that php needs to be upgraded, so
users will get stuck with an outdated PHP.
4. There appears to be no process for migrating the old config file at
/usr/pkg/etc/php-fam.conf to the new config file at
/usr/pkg/etc/php/8.2/php-fam.conf.
However, I don't see how any of this process, or a similar process,
could have deleted a locally modified configuration file.
Home |
Main Index |
Thread Index |
Old Index