Arch Linux

If you modifiy /usr/share/webapps/nextcloud/lib/versioncheck.php
replacing
if (version_compare(PHP_VERSION, '7.4.0') !== -1) {
with
if (version_compare(PHP_VERSION, '7.5.0') !== -1) {
can you progress any further?

also needed to add an override for php-fpm containing:

[Service]
ReadWritePaths = /usr/share/webapps/nextcloud/data
ReadWritePaths = /usr/share/webapps/nextcloud/apps
ReadWritePaths = /etc/webapps/nextcloud/config/

besides that just some deprecation warnings, nothing serious

@wommel So every path used by webapps has to be added into the php-fpm.service? That does not sound very practical.

Changing the version as suggested by @loqs and setting ReadWritePaths to /etc/webapps and /usr/share/webapps let NC work with PHP 7.4.

no only the two paths in /usr and maybe /etc need write access.

having program data in /usr is somewhat wrong. the more standard conform way would be to have the two paths in /var/lib/nextcloud.
so only the data and apps dirs shoud be either allowed or moved (phpfpm has no special write restriction in /var besides the usual user/group based stuff).
allowing writes to /usr would allow an attacker who found a bug in any of your fpm served apps to modify the code it runs and not just the data.
write acces to /usr ist intentionaly and rightfully denied by fpm.
the webapp packages could either provide their necessary overrides as /usr/lib/systemd/system/php-fpm.service.d/$appname.conf or create /var/lib/webapps/$appname/ folders and use symlinks in /usr but that could be critical on updates.

a daemon having write access to its config file is in general debatable. thats why nextcloud offers the config option "config_is_read_only" so it stops complaining about missing write access. but you may have some problems on install & update if done via the webinterface (the fpm restrictions do obviously not apply to the cmd tool but careful about the user running it).

I wouldn't recommend editing "/usr/share/webapps/nextcloud/lib/versioncheck.php" until Nextcloud is tested with PHP 7.4.
I think that the maintainer of the package should specify package requirements to PHP 7.2 and 7.3, so that PHP don't get updated if there's Nextcloud installed.

Adding the dependency seems the right way. Should be done.

However, I suspect that there are quite some installations downloaded from nextcloud.com and installed manually out there. Adding a warning to PHP or PHP-FPM doesn't seem reasonable though since only a small fraction of PHP users will have nextloud installed (manually). Not sure what is the right way to handle this kind of "dependency".

@wommel In the actual situation, NC writes it's apps downloaded via webinteface also to /usr/share/webapps, maybe seperate app_path needs to be defined.

If the data and apps dir was set in config.php to be under /var would that not reduce the number of ReadWritePaths needed?
Additionally if config_is_read_only is set to true then could nextcloud be used without a service override?
Although this would prevent some configuration via the web interface.

There are patches to fix/add php 7.4 support that are comming in 18.x maybe adapt them:
https://github.com/nextcloud/server/pull/18064

For a config to /var/lib/nextcloud see here:
https://aur.archlinux.org/packages/nextcloud-uwsgi-service/#pinned-654441

Should work also when using php-fpm (I'm using uwsgi).

$CONFIG = array (
'datadirectory' => '/var/lib/nextcloud/data',
'cache_path' => '/var/lib/nextcloud/cache',


'log_type' => 'systemd',
'loglevel' => 2,

);

Setting the cache dir also keep user dirs from being crowded when using /home as data dir for user data. E.g. for example when users in nextcloud and in the system are the same because of ldap.

In the Nextcloud PR (https://github.com/nextcloud/server/pull/18064), Thaodan stated in respect to Arch not providing php-7.3 + php-7.4 in parallel: "distros should backport fixes if the software needs fixes". alerque argued: "7.3 → 7.4 is not a major version change that distros should be expected to check every webapp against. The latest 7.x should be workable and it is incumbent on projects like this one to support it. Distros shouldn't have to backport a bunch of patches to run on the latest interpreter, if anything only the opposite scenario should be necessary."

Alternatives for those that use Arch repo PHP and non-repo Nextcloud:

stick to PHP 7.3 (by pinning all packages in /etc/pacman.conf like this:
IgnorePkg = php php-apcu php-fpm php-gd php-igbinary php-imagick php-intl php-redis
Downside: Uncertain what to do IF security relevant patches for one of those packages emerge.

upgrade to PHP 7.4 as soon as NC 18 becomes available (NC 18 supports PHP 7.4)
NC 18 beta will be available mid December 2019 (~ 2 weeks)
NC 18 release is scheduled for mid January 2020 (~ 6 weeks)

immediately upgrade to PHP 7.4 but modify the "required" tests in NC 17 without NC 17 having been tested against PHP 7.4

PKGBUILD.diff adds the commit to allow php7.4, looking at the rest of https://github.com/nextcloud/server/pull/18064
most of the commits are for tests or automation which the PKGBUILD does not use.
Not in those categories are:
https://github.com/nextcloud/server/commit/bfaca7fc78680f8efa4405d497a13a32e760b7ba
https://github.com/nextcloud/server/commit/0568b012672d650c6b5a49e72c4028dde5463c60
https://github.com/nextcloud/server/commit/9a64759af55ecfb9c13da79b6e4ca0384201d18f
https://github.com/nextcloud/server/commit/ff419de3c69d341ff3f16791d924b9e643a9b383

Also not covered is the ReadWritePaths issue.

PHP 7.3 to 7.4 was a minor update. It is not expected to break software. I wonder why NC has this runtime check at all.

PHP do break stuff though only changing the minor version number. They don't do strict semantic versioning. See https://www.php.net/manual/en/migration74.incompatible.php
And I think PHP 7.4 is light on the changes. This is one of the reasons, why most distros supply seperate minor version packaging.

Quick rollback to 7.3.9 EDIT: to 7.3.12, thanks @nursoda:
$ for pkg in "" "-fpm" "-gd" "-intl"; do sudo pacman -U https://archive.archlinux.org/packages/p/php"$pkg"/php"$pkg"-7.3.12-1-x86_64.pkg.tar.xz; done
$ sudo pacman -U https://archive.archlinux.org/packages/p/php-apcu/php-apcu-5.1.18-1-x86_64.pkg.tar.xz

Or if the packages are already cached:
for pkg in "" "-fpm" "-gd" "-intl"; do sudo pacman -U /var/cache/pacman/pkg/php"$pkg"-7.3.12-1-x86_64.pkg.tar.xz; done
sudo pacman -U /var/cache/pacman/pkg/php-apcu-5.1.18-1-x86_64.pkg.tar.xz

7.3.12 was the latest PHP 7.3 version, so why 7.3.9?
I followed this: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date
I set back to this /etc/pacman.d/mirrorlist:
Server=https://archive.archlinux.org/repos/2019/11/29/$repo/os/$arch
and rolled back system with pacman -Syyuu.
Then I pinned 7.3 packages with this line in /etc/pacman.conf:
IgnorePkg = php php-apcu php-fpm php-gd php-igbinary php-imagick php-intl php-redis
After that, I restored the original mirrorlist and continued to keep the rest of the system up-to-date with pacman -Syu

EDIT: Nope, it's all broken and I am unable to fix it.
DON'T DO THE BELOW

previous message:
------------------
I have a custom install of nextcloud, but I think this is still relevant:

I've followed the suggestion by loqs.

I've applied the changes here:
https://github.com/nextcloud/server/commit/bfaca7fc78680f8efa4405d497a13a32e760b7ba
https://github.com/nextcloud/server/commit/0568b012672d650c6b5a49e72c4028dde5463c60
https://github.com/nextcloud/server/commit/9a64759af55ecfb9c13da79b6e4ca0384201d18f

For this one:
https://github.com/nextcloud/server/commit/ff419de3c69d341ff3f16791d924b9e643a9b383

I've entered "3rdparty" and ran

```
sudo composer require "swiftmailer/swiftmailer:6.2.3"
```

Then I chowned the newly installed directories back to http:http:

```
sudo chown -R http:http 3rdparty/swiftmailer && sudo chown -R http:http 3rdparty/symfony
```

Then I edited `lib/versioncheck.php` and changed `7.4.0` with `7.5.0`

I then restarted php-fpm and nginx

```
sudo systemctl restart php-fpm
sudo systemctl restart nginx
```

Things seem to be working fine-ish.

The desktop file syncing app works correctly.
The Password app for example isn't syncing correctly with the Firefox password extension. Maybe I'll discover other problems as I go along.
But I figure I can hold on 2 weeks this way until the nextcloud update comes along

When trying to temporary revert php back to 7.3 (see Daniel's comment) I encountered this other bug: https://bugs.archlinux.org/task/33992
I had to wget the packages locally before installing them, clearing the cache might have worked too.

This same thing happened during the php7.2 to php7.3 upgrade. (NC16 required <7.2, NC17 added 7.3). It probably going to happen next year, too. PHP minor versions introduce breaking changes and have long support cycles. As such I really don't think anyone's ever going to convince the Nextcloud devs to change their policy around testing/supporting PHP updates mid release.

Perhaps Nextcloud should be pushed back into to AUR where having multiple versions of a package is more palatable? Upgrading right away to NC18 might not always be desirably anyway as plugins tend to lag behind, so multiple versions of nextcloud and multiple versions of php in AUR would probably offer a better user experience.

@nursoda, you're correct, my mistake. I was just looking at the directory listing in alphabetical order. Will edit my earlier post.

NC 18 beta is available on beta channel through the admin interface now. However, this is the CURRENT list of apps. Surely, many apps will be updated during the next weeks, and they may work now, but some may not, and I expect that I takes rather long until all of them are fully PHP 7.4 compatible. Here's the list of my test instance, sorted for my personal app importance. Edit: Updated list Dec, 24:

===== WITH Update/Compatibility for NC 18 =====

Contacts
Calendar
Tasks
Mail
Notes
Bookmarks
Talk

Group folders
Collabora Online

Two-Factor Admin Support
Two-Factor Authentication via Nextcloud notification
Two-Factor TOTP Provider
Two-Factor U2F
Two-Factor Gateway

Registration
Suspicious Login

File access control
Files automated tagging
Preview Generator
Automated PDF conversion
Video converter
Metadata
Music
Custom CSS
AppOrder
Cookbook
Extract
Link editor
PhoneTrack
Cospend

===== WITHOUT Update for NC 18 (may or may not be compatible) =====

Impersonate
Polls
ONLYOFFICE
OwnBackup

Maps
News
Mind Map
Deck
Circles
Social
Social sharing via email
Simple poll for Nextcloud Talk
Time Tracker
Carnet
Two Factor e-mail provider
Ransomware protection
ShareRenamer
Checksum
Terms of service
Data Request
Markdown Editor

Quota warning
Ransomware recovery
INotify file watcher
Retention
Files From Mail
Brute-force settings
Announcement center
Audio Player
Audio Player - ID3 Editor (add-on)
Camera RAW Previews
Flow Upload
External sites
Full text search - Files
README.md
ocDownloader
Activities for shared file downloads, visible to all admins
Full text search
Guests
Phone Sync
Optical character recognition
Printer
Favorites Quickaccess Sorting
Quick notes
RainLoop
SMB connection test
Upload Details
External user authentication
User retention
W2G2
Weather

Additional Note: After upgrading NC 17 to 18 beta on his Raspberry Pi running Arch with PHP 7.4 my son got segfaults. So I'll still wait a bit…

> PHP 7.3 to 7.4 was a minor update. It is not expected to break software. I wonder why NC has this runtime check at all.

In spite of being the one to argue this point on the NC issue (and I think it's true), I can understand where they are coming from. PHP has an absolutely terrible track record of breaking changes in minor releases. I remember this being a problem 15 years ago and it's still a problem in the last few cycles. Blocking future releases with this kind of check actually makes sense. Sadly. What doesn't make sense is their refusal to do anything about their own development timeline. In this case they have the patches, it would not be that hard to backport them to a point release. In my case everything works just dropping the runtime check. Obviously that doesn't work for all apps, but 7.4 doesn't have huge changes that they need to rework all their code for. They could have (and I think should have) backported 7.4 support as soon as (or even before) it was announced. The dev cycle on PHP is plenty long to see these things coming and put out minor updates to stay compatible before things break. The dogged expectation that distros should keep old releases around is what should change here.

Given that we've been round this merry go round a couple times and the NC folks aren't seeing the light, I would suggest from the Arch side that this package matches the internal check and explicitly requires the same version range as is being checked for at runtime. This would block system updates from breaking systems — not just now but in future cycles as well. Then when standoffs like this occur on a case by case basis we can look into what it takes to unblock the updates: whether that is patches or beta versions or whatever.

After applying versioncheck.php hack you also need to disable PHP 7.4 new system protection:

sed 's/ProtectSystem=full/ProtectSystem=false/g' /usr/lib/systemd/system/php-fpm.service -i
systemctl daemon-reload
systemctl restart php-fpm.service

I cannot agree more with @bobpaul. Every year or so the same story repeats over and over.

Why don't we have depends=('php<7.4' 'php-gd')?

When nextcloud 18 is released, we should have depends=('php<7.5' 'php-gd') instead.

This would ensure things like this never repeat again...

@Sergio:
I would suggest putting that change in an override file to the systemd unit like this:

mkdir /etc/systemd/system/php-fpm.service.d
echo "ProtectSystem=false" > /etc/systemd/system/php-fpm.service.d/overide.conf

It is bad practice to modify the systemd units in /usr/lib/systemd/system/ directly.

An even better solution would be to just exclude the folders that actually need write access from read-only-mode with

ReadWritePaths=
see documentation for details: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths=

Or use systemctl edit <unit> and paste.

I agree with @bobpaul and @Musikolo. Why the hell do we have this every single year? The package maintainer should add the versioned dependency to this package that is clearly communicated by the Nextcloud developers. PHP minor updates always introduce some incompatibilities and those will naturally affect a complex software like Nextcloud.

So today I noticed the nextcloud package was signed today - 1.1.2020 and the version is 17.0.2. Is it safe to upgrade now?

I think no, versioncheck.php still mentions 7.4.0.