Several issues with NCP update and PHP update

Boggle247 · October 26, 2022, 1:49am

Debian 11 Stable on a x64 NUC
Nextcloud 24.0.5.1
NextCloudPi version v1.50.3
PHP 7.4.30

Major issue, PHP 8.1
Oct. 22nd I ran a package update on my Debian 11 server and it updated the PHP version to 8.1x. After this I was unable to access the webUI for Nextcloud, and Webdav wouldn’t communicate. I rolled it back with a snapshot to undo the package updates, and it all works again. I read here [SOLVED] After Debian 11 upgrade "Failed to connect to the database..." that Nextcloud doesn’t support PHP8.1 yet. If this is true and the only solution is to not use that version, how can I hold this back to prevent issues?

This was my output for the package upgrades/updates in Debian:

Install: php8.1-opcache:amd64 (8.1.11-1+0~20220929.27+debian11~1.gbpe414ce, automatic), php8.1-common:amd64 (8.1.11-1+0~20220929.27+debian11~1.gbpe414ce, automatic), php8.1-readline:amd64 (8.1.11-1+0~20220929.27+debian11~1.gbpe414ce, automatic), php8.1-igbinary:amd64 (3.2.6+2.0.8-6+0~20220131.33+debian11~1.gbp1d540e, automatic), php8.1-phpdbg:amd64 (8.1.11-1+0~20220929.27+debian11~1.gbpe414ce, automatic), php8.1-redis:amd64 (5.3.7+4.3.0-1+0~20220330.42+debian11~1.gbp6fe8b7, automatic), php8.1-cli:amd64 (8.1.11-1+0~20220929.27+debian11~1.gbpe414ce, automatic)
Upgrade: php7.4-mbstring:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), libc6-i386:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), php-redis:amd64 (5.3.2+4.3.0-2+deb11u1, 5.3.7+4.3.0-1+0~20220330.42+debian11~1.gbp6fe8b7), php7.4-readline:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-gd:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-curl:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), tzdata:amd64 (2021a-1+deb11u5, 2021a-1+deb11u7), libpcre3:amd64 (2:8.39-13, 2:8.44-2+0~20210301.9+debian11~1.gbpa278ad), php7.4-bcmath:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-intl:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-opcache:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php-common:amd64 (2:76, 2:92+0~20220117.43+debian11~1.gbpe0d14e), php7.4:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-bz2:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-cli:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-mysql:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-fpm:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-gmp:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), libxml2:amd64 (2.9.10+dfsg-6.7+deb11u2, 2.9.14+dfsg-0+0~20220524.12+debian11~1.gbpc5dc45), php7.4-json:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php-igbinary:amd64 (3.2.1+2.0.8-2, 3.2.6+2.0.8-6+0~20220131.33+debian11~1.gbp1d540e), php7.4-xml:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-zip:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), libc6:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), locales:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), libpcre2-16-0:amd64 (10.36-2+deb11u1, 10.40-1+0~20220713.16+debian11~1.gbpb6cec5), libpcre2-8-0:amd64 (10.36-2+deb11u1, 10.40-1+0~20220713.16+debian11~1.gbpb6cec5), php7.4-common:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), php7.4-ldap:amd64 (7.4.30-1+deb11u1, 1:7.4.32-1+0~20220929.71+debian11~1.gbpe9c007), libc-dev-bin:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), libc-l10n:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), grub-common:amd64 (2.06-3~deb11u1, 2.06-3~deb11u2), libc-bin:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), libc-devtools:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), libc6-dev:amd64 (2.31-13+deb11u4, 2.31-13+deb11u5), libgd3:amd64 (2.3.0-2, 2.3.3-5+0~20220711.9+debian11~1.gbp72b297)

Minor issue - NCP version update

I ran NextcloudPi update and it updated to v1.50.3 and now the port status on the web panel server status shows closed for “port check 80” and “port check 443” as referenced here Open ports check fail due to an url change in ncp-diag file · Issue #1643 · nextcloud/nextcloudpi · GitHub this doesn’t seem to harm anything…

more importantly, This version update also seems to have broken my ability to restore a backup. i wanted to restore a backup of an older version of NCP, it proceeded and looked complete, but at the end it states there was an error and to try refreshing the page. Not sure if it’s related to this? After updating to v1.50.1 HPB service shows "down", nextcloud unreachable · Issue #1593 · nextcloud/nextcloudpi · GitHub

Below is a screenshot of my system info before reverting the package updates to the older PHP version.

NextcloudPi log for that day Sat 22 Oct 2022 07:35:43 AM EDT - Running /etc/cron.daily/ncp-autoupdate...[ n - Pastebin.com

Could someone help me determine the root cause for both issues, and how to resolve it? My system works now, but not performing system updates isn’t a good solution.

theCalcaholic · October 26, 2022, 4:35pm

Hi,

Unfortunately, the information you provided is insufficient to determine the cause of the issue.
The logs you posted only show that your database was not reachable for NC at the time (but not why).

If you still have issues, please include the output of ncp-report.

jivanpal · October 26, 2022, 4:59pm

NextcloudPi (NCP) is designed as an all-in-one solution. NCP instances are not supposed to run other services, nor be manually updated. Rather, you should rely on Debian’s unattended-upgrades package/feature to automatically install security patches. In other words, do not run apt upgrade or apt-get upgrade.

Minor (feature, not patch) updates to software are tested/vetted by the NCP team to work properly with NCP before being released via a new NCP version. Updates to NCP are received through its nc-update script, though you should really enable its automated counterpart, nc-autoupdate-ncp, instead.

All of this (and more) is mentioned in the NCP documentation, on the page Staying up to date:

nc-autoupdate-ncp

Automatically apply NextCloudPi updates (i.e. v1.12.4). A cron job checks for updates once a day.

nc-update

Update NextCloudPi. If you do not enable nc-autoupdate-ncp, you will need to manually run this once a week.

unattended-upgrades

Automatic installation of security updates. Keep your OS and cloud safe. NCP users do not need to run apt manually. Should you decide to do so anyway keep in mind there are various issues that can occur, one of those being a mismatch of the PHP versions of all the modules installed, > specifically the php-fpm module. Often the answer is simply to install the missing module and reboot, otherwise look to the forum for help.

Since your Debian upgrade moved you to PHP 8, you should either:

(a) downgrade PHP and check your Apache config is still pointing to the right PHP-FPM server; or

(b) upgrade your PHP modules (since your currently installed ones all seem to be for PHP 7.4) and update your Apache config to point to the new PHP-FPM server.

In my opinion, option (a) is the simpler of the two. You should be able to do this with this chain of commands:

sudo apt update \
&& sudo apt install -y php7.4-fpm \
&& sudo apt remove -y php8.1-fpm \
&& sudo apt-mark auto php-fpm \
&& sudo apt autoremove -y

Save/copy the output of that, as it may be useful for troubleshooting, but a reboot should get your server back up and running after you run that. If it’s still not working, it’ll most likely be an Apache misconfiguration at that point, but let’s check what PHP-related packages you have installed with dpkg -l | grep php and go from there.

Boggle247 · October 27, 2022, 2:07am

I ran it but since I performed a restore, the logs don’t go back before today. I’ll remember that for the future.

Boggle247 · October 27, 2022, 2:10am

Thank you for pointing that out regarding updates. I do have ncp auto updates enabled already.

I will try step A from your suggestions (maybe tomorrow). However, I do want to note that I’ve restored from a backup and the system works as intended now. I have not updated any packages since restoring. So perhaps it is unnecessary to perform the php portion of your post?

jivanpal · October 27, 2022, 5:24pm

Since you have restored from a backup (presumably a snapshot of the full system, not just NCP-related parts of the filesystem/database?) and now have a working system, there should be nothing else that needs to be done.

You can check whether you have any rogue PHP 8 packages installed (you shouldn’t have any installed) by looking at the output of dpkg -l | grep php. All listed packages should have 7.4 or no number in their name, rather than 8.1 (e.g. php7.4-fpm or php-fpm rather than php8.1-fpm), and should have 7.4 rather than 8.1 in their full version number (before the plus + if one appears, e.g. 7.4.30-1+deb11u1 or 2:7.4+76 are good), which is shown in the third column of the output (after ii, which means “installed”, and the package name).

Mark_F · October 27, 2022, 8:14pm

It is sometimes the case that if Apache and php were updated/upgraded then the apache mod for php would need to be enabled for php8 and disabled for php7

possibility.

jivanpal · October 27, 2022, 8:36pm

This is mentioned in option (b) in my answer.

Boggle247 · October 27, 2022, 10:53pm

$ dpkg -l | grep php
ii  php-common                            2:76                                 all          Common files for PHP packages
ii  php-igbinary                          3.2.1+2.0.8-2                        amd64        igbinary PHP serializer
ii  php-redis                             5.3.2+4.3.0-2+deb11u1                amd64        PHP extension for interfacing with Redis
rc  php7.3-common                         7.3.31-1~deb10u1                     amd64        documentation, examples and common module for PHP
rc  php7.3-readline                       7.3.31-1~deb10u1                     amd64        readline module for PHP
ii  php7.4                                7.4.30-1+deb11u1                     all          server-side, HTML-embedded scripting language (metapackage)
ii  php7.4-bcmath                         7.4.30-1+deb11u1                     amd64        Bcmath module for PHP
ii  php7.4-bz2                            7.4.30-1+deb11u1                     amd64        bzip2 module for PHP
ii  php7.4-cli                            7.4.30-1+deb11u1                     amd64        command-line interpreter for the PHP scripting language
ii  php7.4-common                         7.4.30-1+deb11u1                     amd64        documentation, examples and common module for PHP
ii  php7.4-curl                           7.4.30-1+deb11u1                     amd64        CURL module for PHP
ii  php7.4-fpm                            7.4.30-1+deb11u1                     amd64        server-side, HTML-embedded scripting language (FPM-CGI binary)
ii  php7.4-gd                             7.4.30-1+deb11u1                     amd64        GD module for PHP
ii  php7.4-gmp                            7.4.30-1+deb11u1                     amd64        GMP module for PHP
ii  php7.4-intl                           7.4.30-1+deb11u1                     amd64        Internationalisation module for PHP
ii  php7.4-json                           7.4.30-1+deb11u1                     amd64        JSON module for PHP
ii  php7.4-ldap                           7.4.30-1+deb11u1                     amd64        LDAP module for PHP
ii  php7.4-mbstring                       7.4.30-1+deb11u1                     amd64        MBSTRING module for PHP
ii  php7.4-mysql                          7.4.30-1+deb11u1                     amd64        MySQL module for PHP
ii  php7.4-opcache                        7.4.30-1+deb11u1                     amd64        Zend OpCache module for PHP
ii  php7.4-readline                       7.4.30-1+deb11u1                     amd64        readline module for PHP
ii  php7.4-xml                            7.4.30-1+deb11u1                     amd64        DOM, SimpleXML, XML, and XSL module for PHP
ii  php7.4-zip                            7.4.30-1+deb11u1                     amd64        Zip module for PHP

No remnants of PHP8x. Yes I used a system backup of my / partition only (minus /home) using timeshift.

If I enable auto security updates as shown here: How to Configure Automated Security Updates on Debian | Linode , will it also update my other packages as if I ran apt upgrade? In other words, will it upgrade me back to PHP 8.1?

My other minor issue with the port check status, is still present as I’m still on NCP v1.50.3, restoring my nc-backup to an earlier version fails (which is a known bug). Still looking to resolve that. Everything functions, but on that ncp web panel status page, port 80 and 443 show as closed.

jivanpal · October 28, 2022, 2:10pm

No remnants of PHP8x.

Looks good to me. The couple of packages associated with PHP 7.3 (php7.3-common and php7.3-readline) are marked rc, which means they are marked for removal/deletion, and this will automatically happen when NCP next runs upgrades (via it running apt autoremove behind the scenes).

If I enable auto security updates as shown here: How to Configure Automated Security Updates on Debian | Linode , will it also update my other packages as if I ran apt upgrade? In other words, will it upgrade me back to PHP 8.1?

Not if you use the defaults. Unattended upgrades will only perform upgrades using the repos explicitly specified in its config file. By default, these are just the security update repos. Curiously, the excerpt shown in the Linode article misses out the following line that appears in the default configuration. You should probably include it so that you get updates from the bullseye-security repo:

"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

You can refer to Debian’s official article for more info.

To satisfy yourself that you won’t be upgraded to PHP 8.1, you can see what updates will occur without actually performing them by running sudo unattended-upgrades --dry-run --debug, as mentioned in the Linode article.

My other minor issue with the port check status

I’m afraid I’m not familiar enough with NCP to comment directly on that (I don’t actually use it myself, I use a native installation on a Debian 11 VM that uses Nginx), but suffice it to say that if you can access your cloud via HTTPS, and attempting to access it via plain HTTP in an incognito window causes you to be redirected to the HTTPS site, then you’re good (ports 80 and 443 are definitely open and Apache is almost certainly configured correctly), and I would say that the message saying the ports are closed is a bug in NCP.

@theCalcaholic Perhaps you can shed some more light on this?

Boggle247 · October 28, 2022, 4:36pm

The port status issue is being discussed here: Open ports check fail due to an url change in ncp-diag file · Issue #1641 · nextcloud/nextcloudpi · GitHub probably best to follow @theCalcaholic 's discussion over there. I was just trying to pull some other idea’s from this forum to try and share on that issue.

Linode article misses out the following line that appears in the default configuration. You should probably include it so that you get updates from the bullseye-security repo:
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

Regarding this, it is in fact referenced on that article. The format isn’t entirely clear on the guide but it’s there, I believe:
"origin=Debian,codename=${distro_codename},label=Debian-Security"

jivanpal · October 29, 2022, 5:13pm

This line is also within the default config, in addition to the line I mentioned. Overall, the default config enables updates for the following:

"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

I am not sure of the reason for the presence of both lines 2 and 3, nor what “labels” are in this context (and googling hasn’t been much help to me on that yet). I would assume that bullseye-security is the repo you need to be interested in, and thus that it is line 3 (which is the one that is missing from the Linode article) that is crucial. Regardless, I would check that all three lines are present.

Boggle247 · February 8, 2024, 11:23am

Hate to revive an old post but how would I run npc-report? Is that literally what I would type in the cli after the issue occurs? Should I run it after nextcloud web ui fails to load?

I’m ronkn from github by the way. I talked about this yesterday morning on an issue and you mentioned to open a new github issue about it. I’ll have to find time to attempt the package update again on Debian 11 to see if I can trigger the issue again. Then I’ll create a github issue.