Nextcloud releases bugfix and security updates every month. Mageia 6 has upgraded to Nc12 in May, but this version will be EOL in August. So I will push version 13 to updates_testing to ensure a smooth upgrade. Version 13.0.4 pushed for now. Hopefully no config file changes, so a much easier upgrade than 11->12 one.
Suggested advisory : Nextcloud releases bugfix and security updates every month. This update also upgrades to version 13 as version 12 is EOL in August 2018. It brings also Nextcloud Talk, a private videoconference solution with Android and iOS clients. SRPM : nextcloud-13.0.4-1.mga6.srpm RPMS : nextcloud-13.0.4-1.mga6.noarch.rpm nextcloud-mysql-13.0.4-1.mga6.noarch.rpm nextcloud-postgresql-13.0.4-1.mga6.noarch.rpm nextcloud-sqlite-13.0.4-1.mga6.noarch.rpm
CC: (none) => lists.jjorgeStatus: NEW => ASSIGNED
Tested in x86_64 for my own server. All went smoothly simply with a click in the upgrade button in the login page.
Whiteboard: (none) => MGA6-64-OK
Hi José I simply for now say thanks :) and follow this for updating Wiki. I do not have a NC installation currently to test.
CC: (none) => fri
Do you think my notes on optimising is OK? https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_13
Can you confirm this does not break existing installs? As in installing the update on a system with the service already running, without any further changes by the user, will it continue working on a reboot?
CC: (none) => davidwhodgins
This is a major version update. I have stated it before, so I will only repeat it once here: If we are going to adhere to the policy that updates shouldn't break existing running services, Nextcloud should *never* be in updates, and especially major version updates may go wrong. It needs at least a click in the web ui or to use corresponding cli command, and many things can go wrong even if our packaging is perfect, (just check the NC forum) so if the content is important users should always take backups of data and database, and then update NC. I dont know if but probably it is still the way that after installing the update *any* user can initiate the real upgrade via the web UI, and that is not good if sysadmin was not prepared and have not made backup. On large data it can also take much time. Sysadmin must also be prepared to disable, upgrade, enable extensions. To make it worse: if users are upgrading from Mageia 5, and have updates repos enabled, the major version will skip more than what is supported.
Summary: nextcloud bugfix update => nextcloud major version update
(In reply to Morgan Leijström from comment #6) Your notes on optimising seem good to me, I have applied on my system. > To make it worse: if users are upgrading from Mageia 5, and have updates > repos enabled, the major version will skip more than what is supported. Yes, but we have no choice : providing a web service means security updates, and for sysadmins learning how to use it. Users that only upgrade from MGA5 now are users that don't care about security. They can still downgrade to version 12 to upgrade, as this is upstream choice. We target both needs: - use nextcloud without being a sysadmin for small users; - use our package as real sysadmin and as such, one puts nextcloud in maintenance mode before applying any update; Tested in a second system, x86_64.
Having nextcloud as a regular update can break existing working installs, which is not acceptable. Having nextcloud as a backport can leave users unaware there is an update that needs to be installed, also, not acceptable. By default all users can install updates for already installed packages, and those users may not be the nextcloud admin. A way this could be handled would be to keep nextcloud as a backport, but create a new package that goes in core updates called something like nextcloud-check, that is kept in sync with new versions in backports, and is required by the nextcloud package. When installed, the nextcloud-check update would display detailed info that there is a new backport available with instructions (or have a script for the admin user to run) to download and install the new backport. That way admin users would be made aware of new backports, but wouldn't have existing installs unexpectedly broken by one of their non-admin users choosing to install updates.
nextcloud-check is a very good idea :)
Morgan, if nextcloud can't be in updates, then it can't be packaged in Mageia at all. Either we can support it or we can't. The fact that you have to upgrade from one major version to the next without skipping any is bad, but it's well known and it's an upstream issue. There's nothing we can do about it. Sysadmins are expected to read the Release Notes, which should address issues like this, so that they know about packages that require extra care and/or manual intervention. As far as something needing to be initiated in the web app (or PHP CLI) after a package update, that is not unique to this package and has been the case for other webapps as well. Sysadmins need to be aware of this and take extra care with how and when the package is updated. We shouldn't have to do any extra unusual machinations like the nextcloud-check suggestion; let's not overcomplicate things. It's bad enough as it is.
Yes it is known to be cumbersome. We just have different ideas about how to handle that :)
$ uname -a Linux localhost 4.14.50-desktop-2.mga6 #1 SMP Mon Jun 18 13:19:12 UTC 2018 i686 i686 i686 GNU/Linux Instaled Nextcloud 12.06 with sqlite. This worked as designed, I tested by uploading a video to the system. To satisfy dependencies, the following package(s) also need to be installed: - nextcloud-mysql-13.0.4-1.mga6.noarch - nextcloud-sqlite-13.0.4-1.mga6.noarch - php-pcntl-5.6.36-1.mga6.i586 339KB of disk space will be freed. I rebooted the instance and then installed Nextcloud 13.04. In this case, the NextCloud team has developed an automated upgrade process. It explains what it will upgrade and then performs it. My users and files were retained without issue. 12.06 to 13.04 works smoothly. I think this can be pushed as an update Works as Designed (and better than usual)
Whiteboard: MGA6-64-OK => MGA6-64-OK MGA6-32-OKCC: (none) => brtians1
For discussion: Maybe we should step back from packaging the server from mga7 on. Instead, provide good instructions for manual install. The server have good abilities to update itself, if file rights etc are set for allowing it. I suggest the basic instructions be written to support that, so home users and the like can rather easily install it, and let it update itself. The server announce in the GIU when updates are available, in four different channels admin can select (production, stable, beta, daily). Also provide some hints providing a more locked down installation for them wishing more security and reliability, with some hint to what to temporarily change for the server to auto update, and link to server documentation how to do it manually (and note on any specifics to Mageia) for those that prefer to do it that way. And of course how to handle backing up. For mga6 -> mga7 note how it is currently set up by the mga6 rpm, and what need be changed to facilitate auto update. And also what can be optimised when upgrading mga6 to mga7 environment. And in mga7 release notes link to that. Put all at https://wiki.mageia.org/en/Nextcloud , based on packagers knowledge and https://wiki.mageia.org/en/OwnCloud but much cleaned.
Advisory committed to svn. Validating the update.
Keywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2018-0128.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
This also fixed CVE-2018-376[12]: https://lists.opensuse.org/opensuse-updates/2018-07/msg00023.html