Talk:Nextcloud
Migrating to php-legacy
I've added a new subsection under Troubleshooting Migrating to php-legacy.
I've written this section a bit in a hurry (wanted to get my Nextcloud installation up and running again). Additionally the VMs I've been using while preparing the big overhaul in Feb 2022 have long gone. So I was not able to test the instructions completely for all combinations of web servers and application servers.
Therefore, I would appreciate any review of this section - preferably by applying the steps to an existing setup that is some other combination than Nginx and PHP-FPM. Many thanks in advance. Wolegis (talk) 13:03, 15 January 2023 (UTC)
- I'm not sure, so I'll ask here instead of editing the article directly: in section "FPM configuration" the file naming may not be entirely correct. There it says: "Modify /etc/php-legacy/php-fpm.d/nextcloud.conf" followed by "/etc/php-legacy/php-fpm.d/nextcloud.ini". I think it should be called "nextcloud.conf" in both cases. Or am I wrong here?
- Also, I have some problems with my Nextcloud (Nginx and PHP-FPM on a RPi4B) after switching to php-legacy as described ("Internal Server Error" without error messages in a any log file). Tonight I'll start again from scratch after restoring a backup - I think it's just a typo in one of my configuration files. UomoInvisibile (talk) 06:52, 27 January 2023 (UTC)
Be consistent with the php-legacy-fpm name
I think that given the new php-fpm
module for php-legacy
was named as php-legacy-fpm
, I think all paths should use the word php-legacy-fpm
rather than php-fpm-legacy
. In my view that would make all paths and settings consistent with the name of the new module. Alternatively, the new module should be renamed as php-fpm-legacy
and keep all paths as they are. Either or but be consistent. Thoughts?
Musikolo (talk) 17:01, 21 January 2023 (UTC)
- Good catch. I have replaced
php-fpm-legacy
byphp-legacy-fpm
wherever possible. One exception being the name of the executable/usr/bin/php-fpm-legacy
(referenced by some drop-in files). You may get in touch with the maintainer(s) of pgp-legacy-fpm and point out the inconsistency. But I strongly doubt that the executable will be renamed as probably too many people have already adapted to the new (inconsistent) name. Wolegis (talk) 17:10, 21 January 2023 (UTC)
Leads to FS#77232 AndyRTR (talk) 17:14, 22 January 2023 (UTC)
As this is right now described with /run/php-legacy-fpm/nextcloud.socket
being used, this leads to a 503-Error when accessing the servers web-page after server-reboot because of the php-fpm-legacy.service
(yes, that's the name of the service although enableing php-legacy-fpm
according to the wiki) failing to start because the directory /run/php-legacy-fpm/
isn't persistent on reboot (while /run/php-fpm-legacy/
is).
Also, this directory /run/php-legacy-fpm/
and /var/log/php-legacy-fpm/
and /var/lib/nextcloud/sessions/
have to be generated manually in order to Nextcloud being able to start - at least for me.
--NextUser (talk) 10:59, 13 February 2023 (UTC)
- I've created a new sub-section below Application / FPM covering
/run/php-legacy-fpm/
by copying the very same statement from the Troubleshooting section. I regarded this as a temporary hack to work around inconsistencies in php-legacy-fpm. But as it looks, there probably won't be any significant changes to php-legacy-fpm. So maybe I will rollback some changes (and become more inconsistent again) in the near future. The mentioned hack will then not be necessary anymore.
/var/lib/nextcloud/sessions/
has already been covered in the section Configuration / System and Environment.
- I'm still contemplating how and where to cover
/var/log/php-legacy-fpm/
Wolegis (talk) 11:35, 13 February 2023 (UTC)
- OK, thanks! IMHO it's really useful it's not only mentioned in troubleshooting/migration from php-pfm to php-legacy-fpm because this also appears in an initial fpm-installation. --NextUser (talk) 16:12, 13 February 2023 (UTC)
According to FS#77232 some naming inconsistencies in php-legacy-fpm will remain. I have adapted the article accordingly. Wolegis (talk) 11:05, 19 February 2023 (UTC)
Issues with Redis setup procedure
Apparently, it is not enough to set extension=igbinary extension=redis
in both /etc/webapps/nextcloud/php.ini
and /etc/php-legacy/php-fpm.d/nextcloud.conf
(albeit with php_value[extension]...
), since nginx will consistently return 500.
Following steps provided in PHP#Redis mitigate this. Weirdly enough, the provided igbinary.ini
template coming with php-legacy-igbinary uses extension=igbinary.so
instead of extension=igbinary
. However, changing this in both the pool file as well as nextcloud's php.ini does not resolve this.
Sir-Photch (talk) 17:29, 13 March 2023 (UTC)
- I'm pretty sure it is sufficient to set
/etc/php-legacy/php-fpm.d/nextcloud.conf
php_value[extension] = igbinary php_value[extension] = redis
- and
/etc/webapps/nextcloud/php.ini
extension=igbinary extension=redis
- Please double-check your setup.
- It's difficult to guess what might be the root cause of your issue. In the first place: Was your Nextcloud instance setup in line with the wiki article, i.e. avoiding any modifications in
/etc/php-legacy/php.ini
? If so: Is your FPM started correctly with--php-ini /etc/php-legacy/php-fpm.ini
specified in a drop-in file? - (Actually
/etc/webapps/nextcloud/php.ini
is not relevant for processing HTTP(S) requests. So focus on/etc/php-legacy/php-fpm.d/nextcloud.conf
and your general FPM setup.) - As with your second issue:
extension=igbinary.so
is the legacy format how to specify a PHP extension. Since PHP 7.2 it is recommended to strip the.so
(or.dll
on Windows). I'm not aware of any significant differences between the two variants, except the latter is more portable. - Wolegis (talk) 20:30, 13 March 2023 (UTC)