Well, This brings again the problem of upgrading MGA6 nextcloud : we have released with version 11 which is not supported anymore upstream. Version 12 brings changes in the config file that we cannot add automaticaly, so installing the security update will require manual edit of the config file.

What is the best solution?

https://bugs.mageia.org/show_bug.cgi?id=22026

Just make sure that the manual changes needed are noted in the README.upgrade.urpmi and in the advisory for the update.  It's not the first time an update has required manual changes.  That's the best you can do.

Suggested advisory :
Mageia 6 brings Nextcloud 11, which is not supported anymore upstream.
This update brings version 12 with several security fixes. The database system is now in a separate package, so you will have to choose manually to one you are using.

NOTA : the config file has changed, so system administrators will have to edit it manually. Our tests showed that adding this may be enough at the end of config file, just before closing) :

'log_type' => 'syslog',
  'datadirectory' => '/var/lib/nextcloud/data',
  'updatechecker' => false,
  'check_for_working_htaccess' => false,
  'asset-pipeline.enabled' => false,
  'assetdirectory' => '/var/lib/nextcloud',
  'preview_libreoffice_path' => '/usr/bin/libreoffice',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/share/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/lib/nextcloud/apps',
      'url' => '/apps-appstore',
      'writable' => true,
    ),
  ),

Ref: https://nextcloud.com/changelog/#latest12

SRPM :
nextcloud-12.0.6-1.mga6.srpm

RPMS :

nextcloud-12.0.6-1.mga6.noarch.rpm
nextcloud-mysql-12.0.6-1.mga6.noarch.rpm
nextcloud-postgresql-12.0.6-1.mga6.noarch.rpm
nextcloud-sqlite-12.0.6-1.mga6.noarch.rpm

Status: NEW => ASSIGNED

(In reply to David Walser from comment #2)
> Just make sure that the manual changes needed are noted in the
> README.upgrade.urpmi and in the advisory for the update.  It's not the first
> time an update has required manual changes.  That's the best you can do.

Please ping me (i.e reply here) when it is documented what users need to do and i will add it to https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12 (or just do it)

( BTW i have not run a server for a while and have not followed, so if there should be some info on https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_11 i have missed please tell. )

CC: (none) => fri

Sorry, no coffe yet.
All that is needed to do is explained in comment 3?

Landing in backports as usual?

(In reply to Morgan Leijström from comment #6)
> Landing in backports as usual?

No, it is a security update, so going to updates_testing.

And yes all is indicated in comment 3. The idea is to compare config.php and config.php.rpmnew to get the good settings.

Tested in a production system that had already tested the manual upgrade to version 12.0.3. All Ok.

As the onwCloud/Nextcloud updates often like this breaks the server and need manual work to get it running we use to release it in backports (in lack of a better place).

We have also communicated that in wiki and release notes.

IMO a normal system update should not break a server like this do.

Another reason: Someone upgrading from mga5 should NOT get this latest version (which will normally be the case as updates is normally enabled during upgrade) as NC12 is not suitable as direct upgrade from last version in mga5 (NC10) (last i checked), but the one in mga6 core release (NC11) is.

(In reply to Morgan Leijström from comment #9)
> As the onwCloud/Nextcloud updates often like this breaks the server and need
> manual work to get it running we use to release it in backports (in lack of
> a better place).

Yes, but this was also a bad path. We leave users with known holes in a public server. And the users that read release notes and wiki also know that an update might need tweaks, so they will know what to do.

I will not do again the crazy work of MGA5, with 3 different backports to install one after other in order to be able to upgrade to MGA6.

*cloud are complex software, with 3 different databases systems to choose from, a data store path that one often ha

> Another reason: Someone upgrading from mga5 should NOT get this latest version

Previous message posted too fast by error. But we have finished to period where MGA5 was supported, so end users must have upgraded, or just go their less sure way.

$ uname -a
Linux localhost 4.14.30-desktop-3.mga6 #1 SMP Sun Mar 25 22:17:31 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

The following 45 packages are going to be installed:

- apache-2.4.27-1.1.mga6.x86_64
- apache-mod_php-5.6.35-1.mga6.x86_64
- lib64apr-util1_0-1.5.4-8.mga6.x86_64
- lib64apr1_0-1.5.2-2.1.mga6.x86_64
- lib64json2-0.12.1-1.mga6.x86_64
- lib64mbfl1-1.3.2-1.mga6.x86_64
- lib64onig2-5.9.6-2.mga6.x86_64
- lib64php5_common5-5.6.35-1.mga6.x86_64
- lib64t1lib5-5.1.2-19.mga6.x86_64
- lib64zip4-1.1.3-1.1.mga6.x86_64
- nextcloud-12.0.6-1.mga6.noarch
- nextcloud-mysql-12.0.6-1.mga6.noarch
- php-ctype-5.6.35-1.mga6.x86_64
- php-curl-5.6.35-1.mga6.x86_64
- php-dom-5.6.35-1.mga6.x86_64
- php-exif-5.6.35-1.mga6.x86_64
- php-fileinfo-5.6.35-1.mga6.x86_64
- php-filter-5.6.35-1.mga6.x86_64
- php-ftp-5.6.35-1.mga6.x86_64
- php-gd-5.6.35-1.mga6.x86_64
- php-gettext-5.6.35-1.mga6.x86_64
- php-hash-5.6.35-1.mga6.x86_64
- php-iconv-5.6.35-1.mga6.x86_64
- php-ini-5.6.35-1.mga6.x86_64
- php-json-5.6.35-1.mga6.x86_64
- php-ldap-5.6.35-1.mga6.x86_64
- php-mbstring-5.6.35-1.mga6.x86_64
- php-mysqlnd-5.6.35-1.mga6.x86_64
- php-openssl-5.6.35-1.mga6.x86_64
- php-pdo-5.6.35-1.mga6.x86_64
- php-pdo_mysql-5.6.35-1.mga6.x86_64
- php-posix-5.6.35-1.mga6.x86_64
- php-session-5.6.35-1.mga6.x86_64
- php-suhosin-0.9.38-1.mga6.x86_64
- php-sysvsem-5.6.35-1.mga6.x86_64
- php-sysvshm-5.6.35-1.mga6.x86_64
- php-timezonedb-2017.2-1.mga6.x86_64
- php-tokenizer-5.6.35-1.mga6.x86_64
- php-xml-5.6.35-1.mga6.x86_64
- php-xmlreader-5.6.35-1.mga6.x86_64
- php-xmlwriter-5.6.35-1.mga6.x86_64
- php-zip-5.6.35-1.mga6.x86_64
- php-zlib-5.6.35-1.mga6.x86_64
- t1lib-config-5.1.2-19.mga6.x86_64
- webserver-base-2.0-10.mga6.noarch

169MB of additional disk space will be used.

41MB of packages will be retrieved.

Is it ok to continue?


The following 2 packages are going to be installed:

- nextcloud-sqlite-12.0.6-1.mga6.noarch
- php-sqlite3-5.6.35-1.mga6.x86_64

53KB of additional disk space will be used.

34KB of packages will be retrieved.

Is it ok to continue?



Had to install pdo_sqlite

After installing that, system recognized sqlite and installed properly


Added photo to repos, that’s working

SQLITE NextCloud 12.06 working

CC: (none) => brtians1

(In reply to Brian Rockwell from comment #12)
 > Had to install pdo_sqlite
> 

Thanks for reporting that. I have updated the requires for sqlite and postgres, as both now seem to use PDO. Upgraded the release, so now all packages are 
12.0.6-2

I will update https://wiki.mageia.org/en/OwnCloud to describe this update comes in normal updates repo.

A thought: sqlite is because of performance deprecated by OC and NC folks since years, and also our wiki describe and recommend MariaDB and describe the installation and configuration.  So should NC package then really require sqlite?  I think NC rpm should not require any DB engine at all, as user can chose to install any of three?

(In reply to José Jorge from comment #11)

> I will not do again the crazy work of MGA5, with 3 different backports to 
> install one after other in order to be able to upgrade to MGA6.

The versions was needed, and OC/NC folks have all time been releasing incompatible updates faster than Mageia releases - i doubt that will change.
 
What is harder about putting in backports than in updates?


Now as we are forcing server interruption through update, is it possible to make it warn before installing NC update and user have option to abort?

Or at least at install pup up a warning with a link to https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12 ?

Morgan, please stop nagging about this.  It's not about being harder, it's about this is a security update for a package in core/release.  Those go in core/updates.  Backports is its own branch, but we don't force people to that just to continue to receive support for packages in core/release.

If the package has a README.urpmi or README.update.urpmi then it will print a message to the console when you install it and MageiaUpdate will pop up a window with that information.  We've done all we can do.

OK good.
sorry for nagging
Will update wiki.

(In reply to Morgan Leijström from comment #17)
> sorry for nagging

I've got no problems with your nagging : people like you increase much in our distro QA.

> Will update wiki.

Thanks for that work. Let's see if we go a good way...

Between, I have tested this upgrade in 2 other servers...

(In reply to Morgan Leijström from comment #14)
> A thought: sqlite is because of performance deprecated by OC and NC folks
> since years, and also our wiki describe and recommend MariaDB and describe
> the installation and configuration.  So should NC package then really
> require sqlite?  I think NC rpm should not require any DB engine at all, as
> user can chose to install any of three?

Please look at the packages : neoclust has already split nextcloud in 3 subpackages, so it is only nextcloud-sqlite which requires php-pdo_sqlite....

Created attachment 10107 [details]
libreoffice writer document - with installed items, plus screenshot of error

Hi Jose,
Works really well with updates you made.  SQLITE works properly now.  Signature issue on object.

Let me know if you want me to test it again.

(In reply to Brian Rockwell from comment #21)
> Signature issue on object.

This is a build system problem we're having since yesterday. Sysadmins will have to sign manually this RPM. Or should I submit again?

If the packages still aren't getting signed we'll have to wait.  I think this is the time of year that our signing key expires.

https://ml.mageia.org/l/arc/dev/2018-04/msg00247.html

" This is from when the disk was full, causing a failure to sign, and the
known problem that after too many failure to sign instead of failing it
just uploads it unsigned "

Ok - let me know if you need a 12.06-3 test done or if the signature can be addressed in this instance and I can give me ok for sqlite.

Can please an extra pair of eyes check if i got this correct:
https://wiki.mageia.org/en/OwnCloud#Upgrading
- especially point 5 & 6.x under 'PROCEDURE'

And https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12

...

For version 13, is there something we should mention at https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12

I look at https://docs.nextcloud.com/server/13/admin_manual/maintenance/upgrade.html#manual-steps-during-upgrade - Am i right in that users for best performance need to perform the actions described there, and what is it in our case? I guess:
# apache php occ db:add-missing-indice
# apache php occ db:convert-filecache-bigint
(while NC is put in maintenance mode)

For version 13 i meant https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_13

(In reply to Morgan Leijström from comment #26)
> Can please an extra pair of eyes check if i got this correct:
> https://wiki.mageia.org/en/OwnCloud#Upgrading
> - especially point 5 & 6.x under 'PROCEDURE'
> 
> And https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12
> 
> ...
> 
> For version 13, is there something we should mention at
> https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12
> 
> I look at
> https://docs.nextcloud.com/server/13/admin_manual/maintenance/upgrade.
> html#manual-steps-during-upgrade - Am i right in that users for best
> performance need to perform the actions described there, and what is it in
> our case? I guess:
> # apache php occ db:add-missing-indice
> # apache php occ db:convert-filecache-bigint
> (while NC is put in maintenance mode)
One  of the MySQL database commands have -uroot and must be -u root, please correct because some users ( I by example ) copy and paste the commands from the manuals

CC: (none) => neoser10

Oops I see the commands in my post was missing the beginnings
What i think the Nextcloud page say is that we need to run the php commands as the apache user, so in that case for Mageia, and adding that rest of wiki page do not utilise sudo:

 su apache
 php occ maintenance:mode --on   (make sure it is in maintenance mode)
 php occ db:add-missing-indice
 php occ db:convert-filecache-bigint
 php occ maintenance:mode --off   (only if all is ok to run)
 exit

But you mean one of them need be run as root, are you sure ?

( I am thinking occ runs like Nextcloud, and in turn use the same user we configured towards the database see https://wiki.mageia.org/en/OwnCloud#Configure_the_database_engine_MariaDB )

(I am far from an expert and have not been configuring own/next-cloud for over a year, just trying to get wiki good so bear with me...)

(In reply to Morgan Leijström from comment #29)
> Oops I see the commands in my post was missing the beginnings

A better practice : just put a link in our wiki to upstream, this way it will always be up to date. I think this special tunings go far beyond our packaging, it is optimising.

For NC13 i posted link and example for now, with note "untested".

Important: Do the steps for NC12 seem OK? 
> https://wiki.mageia.org/en/OwnCloud#Upgrading
> - especially point 5 & 6.x under 'PROCEDURE'


This is for our wiki, not our packaging.
The wiki already contain optimising and housekeeping info.
I just thought this was the quickest place to discuss, although maybe the wiki page discus tab would be more formally correct.

(In reply to Brian Rockwell from comment #25)
> Ok - let me know if you need a 12.06-3 test done or if the signature can be
> addressed in this instance and I can give me ok for sqlite.

 Version 12.06-3 pushed, let's see if the signature is good now.

$ uname -a
Linux localhost 4.14.30-desktop-3.mga6 #1 SMP Sun Mar 25 23:26:07 UTC 2018 i686 i686 i686 GNU/Linux


The following 50 packages are going to be installed:

- apache-2.4.27-1.1.mga6.i586
- apache-mod_php-5.6.36-1.mga6.i586
- libapr-util1_0-1.5.4-8.mga6.i586
- libapr1_0-1.5.2-2.1.mga6.i586
- libjson2-0.12.1-1.mga6.i586
- libmbfl1-1.3.2-1.mga6.i586
- libonig2-5.9.6-2.mga6.i586
- libphp5_common5-5.6.36-1.mga6.i586
- libpq5-9.6.7-1.mga6.i586
- libt1lib5-5.1.2-19.mga6.i586
- libzip4-1.1.3-1.1.mga6.i586
- nextcloud-12.0.6-3.mga6.noarch
- nextcloud-mysql-12.0.6-3.mga6.noarch
- nextcloud-postgresql-12.0.6-3.mga6.noarch
- nextcloud-sqlite-12.0.6-3.mga6.noarch
- php-ctype-5.6.36-1.mga6.i586
- php-curl-5.6.36-1.mga6.i586
- php-dom-5.6.36-1.mga6.i586
- php-exif-5.6.36-1.mga6.i586
- php-fileinfo-5.6.36-1.mga6.i586
- php-filter-5.6.36-1.mga6.i586
- php-ftp-5.6.36-1.mga6.i586
- php-gd-5.6.36-1.mga6.i586
- php-gettext-5.6.36-1.mga6.i586
- php-hash-5.6.36-1.mga6.i586
- php-iconv-5.6.36-1.mga6.i586
- php-ini-5.6.36-1.mga6.i586
- php-json-5.6.36-1.mga6.i586
- php-ldap-5.6.36-1.mga6.i586
- php-mbstring-5.6.36-1.mga6.i586
- php-mysqlnd-5.6.36-1.mga6.i586
- php-openssl-5.6.36-1.mga6.i586
- php-pdo-5.6.36-1.mga6.i586
- php-pdo_mysql-5.6.36-1.mga6.i586
- php-pdo_pgsql-5.6.36-1.mga6.i586
- php-pdo_sqlite-5.6.36-1.mga6.i586
- php-posix-5.6.36-1.mga6.i586
- php-session-5.6.36-1.mga6.i586
- php-suhosin-0.9.38-1.mga6.i586
- php-sysvsem-5.6.36-1.mga6.i586
- php-sysvshm-5.6.36-1.mga6.i586
- php-timezonedb-2017.2-1.mga6.i586
- php-tokenizer-5.6.36-1.mga6.i586
- php-xml-5.6.36-1.mga6.i586
- php-xmlreader-5.6.36-1.mga6.i586
- php-xmlwriter-5.6.36-1.mga6.i586
- php-zip-5.6.36-1.mga6.i586
- php-zlib-5.6.36-1.mga6.i586
- t1lib-config-5.1.2-19.mga6.i586
- webserver-base-2.0-10.mga6.noarch

169MB of additional disk space will be used.

41MB of packages will be retrieved.

Is it ok to continue?



----------------

Installed with sqlite and it works very well.  No issues at all.

I'll retry in 64-bit, hopefully tomorrow with postgresql.

---

Jose - thank you.

Whiteboard: (none) => mga6-32-ok

The following 49 packages are going to be installed:

- apache-2.4.27-1.1.mga6.x86_64
- apache-mod_php-5.6.36-1.mga6.x86_64
- lib64apr-util1_0-1.5.4-8.mga6.x86_64
- lib64apr1_0-1.5.2-2.1.mga6.x86_64
- lib64json2-0.12.1-1.mga6.x86_64
- lib64mbfl1-1.3.2-1.mga6.x86_64
- lib64onig2-5.9.6-2.mga6.x86_64
- lib64ossp_uuid16-1.6.2-16.mga6.x86_64
- lib64php5_common5-5.6.36-1.mga6.x86_64
- lib64pq5-9.6.7-1.mga6.x86_64
- lib64t1lib5-5.1.2-19.mga6.x86_64
- lib64zip4-1.1.3-1.1.mga6.x86_64
- nextcloud-12.0.6-3.mga6.noarch
- nextcloud-postgresql-12.0.6-3.mga6.noarch
- php-ctype-5.6.36-1.mga6.x86_64
- php-curl-5.6.36-1.mga6.x86_64
- php-dom-5.6.36-1.mga6.x86_64
- php-exif-5.6.36-1.mga6.x86_64
- php-fileinfo-5.6.36-1.mga6.x86_64
- php-filter-5.6.36-1.mga6.x86_64
- php-ftp-5.6.36-1.mga6.x86_64
- php-gd-5.6.36-1.mga6.x86_64
- php-gettext-5.6.36-1.mga6.x86_64
- php-hash-5.6.36-1.mga6.x86_64
- php-iconv-5.6.36-1.mga6.x86_64
- php-ini-5.6.36-1.mga6.x86_64
- php-json-5.6.36-1.mga6.x86_64
- php-ldap-5.6.36-1.mga6.x86_64
- php-mbstring-5.6.36-1.mga6.x86_64
- php-openssl-5.6.36-1.mga6.x86_64
- php-pdo-5.6.36-1.mga6.x86_64
- php-pdo_pgsql-5.6.36-1.mga6.x86_64
- php-posix-5.6.36-1.mga6.x86_64
- php-session-5.6.36-1.mga6.x86_64
- php-suhosin-0.9.38-1.mga6.x86_64
- php-sysvsem-5.6.36-1.mga6.x86_64
- php-sysvshm-5.6.36-1.mga6.x86_64
- php-timezonedb-2017.2-1.mga6.x86_64
- php-tokenizer-5.6.36-1.mga6.x86_64
- php-xml-5.6.36-1.mga6.x86_64
- php-xmlreader-5.6.36-1.mga6.x86_64
- php-xmlwriter-5.6.36-1.mga6.x86_64
- php-zip-5.6.36-1.mga6.x86_64
- php-zlib-5.6.36-1.mga6.x86_64
- postgresql9.6-9.6.7-1.mga6.x86_64
- postgresql9.6-plpgsql-9.6.7-1.mga6.x86_64
- postgresql9.6-server-9.6.7-1.mga6.x86_64
- t1lib-config-5.1.2-19.mga6.x86_64
- webserver-base-2.0-10.mga6.noarch

195MB of additional disk space will be used.

47MB of packages will be retrieved.

Is it ok to continue?



After rebooting – I checked to see if postgres started.  

It did.

Next is set up stuff.

In terminal I su’d over to root

From root I su’d over to postgres (could of done it from my account I suppose).

Got into psql

in psql I created database next (because I am so innovative with names).

postgres=# create database next;

Next I created a user nextcloud (same reason as above).

Okay at terminal I seem to be pretty much done.

Go into your favourite web-browser on the host and type in:  127.0.0.1\nextcloud

It should come back with the initial set up screen


Make up your own administrator ID and password (this is your nextcloud administrator account).

It should tell you postgresql is available.

Pick it and enter the special information you have to connect to postgres

user:  nextcloud

database: next

localhost:5432

then click next and hope it works..  If it is, it should delay for a few seconds while it builds out the system.


I was able to add documents to my repo.  As the admin I was able to create a new user and login with that user and add documents to the users repo.  Also able to replace documents.   Well what do you know it works.

mga6-64-ok

Whiteboard: mga6-32-ok => mga6-32-ok mga6-64-ok

Medals for those who worked so long & hard to get this right: José, Morgan, Brian.
Advisory from comments 3 & 32.

Keywords: (none) => advisory, validated_update
CC: (none) => sysadmin-bugs

And thank you Brian for the PostgreSQL test example, i took the liberty to link to it from https://wiki.mageia.org/en/OwnCloud#Database_choices :)

I've dropped this part from advisory:

<quote>
'log_type' => 'syslog',
  'datadirectory' => '/var/lib/nextcloud/data',
  'updatechecker' => false,
  'check_for_working_htaccess' => false,
  'asset-pipeline.enabled' => false,
  'assetdirectory' => '/var/lib/nextcloud',
  'preview_libreoffice_path' => '/usr/bin/libreoffice',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/share/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/lib/nextcloud/apps',
      'url' => '/apps-appstore',
      'writable' => true,
    ),
  ),
</quote>

as its in no way parseable by current advisory system...

If that info is needed, it should be in a version triggered README.urpmi.update

Keywords: validated_update => (none)
CC: (none) => tmb

Can it have a link to the same info at https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12 ?

And how do you inform all those that does not subscribe to updates-announce@ ?

(In reply to Thomas Backlund from comment #39)
> And how do you inform all those that does not subscribe to updates-announce@
> ?

The README.urpmi is already there. This info was for testers, and cannot be applied as is for any installation.

I am at a loss as to what is now needed (if anything) to validate this update. If the config file addition is in the update (to display in-flight, and in /usr/share/nextcloud for reference), can the update be validated as-is?

CC: (none) => lewyssmith

I think this is ready to go.  It installs properly and is working as designed. 

It should be validated and released.

<<My Opinion>>

Brian

(In reply to Brian Rockwell from comment #42)
> I think this is ready to go.  It installs properly and is working as
> designed. 
> It should be validated and released.
I agree. As there was no reply to my comment 41, am re-validating (you could have done). It will be sat on if something is still 'administratively' wrong. No doubting the validity of the update per se.

Keywords: (none) => validated_update

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0226.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED