I'd like to push an update upgrading the nextcloud server in Mageia. - it will allow an easier upgrade to MGA7 without manual operations. - it is better for security to have recent app in such a public server - it allows to do a better packaging picking the problems in a slow pace, out of a whole system upgrade The idea is to always have at least the version before the latest, which must be already in cauldron. So for now it is version 12.0.3 that is pushed to MGA6 updates testing.
CC: (none) => mageiaAssignee: bugsquad => lists.jjorge
First test on a production system : unfortunately, we need some new lines in the config.php file, to manage better the apps directory. For now, they are in the rpmnew file. I think it will need an information. I had to add the following lines manually : 'integrity.check.disabled' => true, 'log_type' => 'syslog', '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, ), ),
A README.urpmi file was added to explain the changes in config.file. Please QA, test this update and decide if such manual operations are acceptable with an update. SRPM : nextcloud-12.0.3-2.mga6.srpm RPMS : nextcloud-12.0.3-2.mga6.noarch.rpm nextcloud-mysql-12.0.3-2.mga6.noarch.rpm nextcloud-postgresql-12.0.3-2.mga6.noarch.rpm nextcloud-sqlite-12.0.3-2.mga6.noarch.rpm
Assignee: lists.jjorge => qa-bugsStatus: NEW => ASSIGNEDCC: (none) => lists.jjorge
do you need me to pull in an old version of nextcloud and then upgrade or is a fresh install acceptable?
Keywords: (none) => feedbackCC: (none) => brtians1
Upgrades are actually the point of this update, and it's updating to a new stable branch, so testing updating from the release version is very important.
Keywords: feedback => (none)
Installing Base The following 43 packages are going to be installed: - apache-2.4.27-1.1.mga6.x86_64 - apache-mod_php-5.6.32-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.32-1.mga6.x86_64 - lib64t1lib5-5.1.2-19.mga6.x86_64 - lib64zip4-1.1.3-1.1.mga6.x86_64 - nextcloud-11.0.3-1.mga6.noarch - php-ctype-5.6.32-1.mga6.x86_64 - php-curl-5.6.32-1.mga6.x86_64 - php-dom-5.6.32-1.mga6.x86_64 - php-fileinfo-5.6.32-1.mga6.x86_64 - php-filter-5.6.32-1.mga6.x86_64 - php-ftp-5.6.32-1.mga6.x86_64 - php-gd-5.6.32-1.mga6.x86_64 - php-gettext-5.6.32-1.mga6.x86_64 - php-hash-5.6.32-1.mga6.x86_64 - php-iconv-5.6.32-1.mga6.x86_64 - php-ini-5.6.32-1.mga6.x86_64 - php-json-5.6.32-1.mga6.x86_64 - php-mbstring-5.6.32-1.mga6.x86_64 - php-opcache-5.6.32-1.mga6.x86_64 - php-openssl-5.6.32-1.mga6.x86_64 - php-pdo-5.6.32-1.mga6.x86_64 - php-pdo_sqlite-5.6.32-1.mga6.x86_64 - php-posix-5.6.32-1.mga6.x86_64 - php-session-5.6.32-1.mga6.x86_64 - php-sqlite3-5.6.32-1.mga6.x86_64 - php-suhosin-0.9.38-1.mga6.x86_64 - php-sysvsem-5.6.32-1.mga6.x86_64 - php-sysvshm-5.6.32-1.mga6.x86_64 - php-timezonedb-2017.2-1.mga6.x86_64 - php-tokenizer-5.6.32-1.mga6.x86_64 - php-xml-5.6.32-1.mga6.x86_64 - php-xmlreader-5.6.32-1.mga6.x86_64 - php-xmlwriter-5.6.32-1.mga6.x86_64 - php-zip-5.6.32-1.mga6.x86_64 - php-zlib-5.6.32-1.mga6.x86_64 - t1lib-config-5.1.2-19.mga6.x86_64 - webserver-base-2.0-10.mga6.noarch 144MB of additional disk space will be used. 38MB of packages will be retrieved. Is it ok to continue? I’ve configured it with a custom data folder /home/apache and using sqlite. Created a new user, besides admin, and posted some new documents in the repo. Seems to be working as designed. Now for upgrade Upgrading to 12.03 The following 9 packages are going to be installed: - lib64php5_common5-5.6.33-1.mga6.x86_64 - nextcloud-12.0.3-2.mga6.noarch - nextcloud-mysql-12.0.3-2.mga6.noarch - php-exif-5.6.33-1.mga6.x86_64 - php-ldap-5.6.33-1.mga6.x86_64 - php-mbstring-5.6.33-1.mga6.x86_64 - php-mysqlnd-5.6.33-1.mga6.x86_64 - php-pdo-5.6.33-1.mga6.x86_64 - php-pdo_mysql-5.6.33-1.mga6.x86_64 8.2MB of additional disk space will be used. 37MB of packages will be retrieved. Is it ok to continue? The configuration changes – I didn’t find the README.urpmi. I did click on update notes, but they just pointed to the /etc/nextcloud/config.php.rpmnew file. I looked at it. This isn’t clear what needs to be changed at all. I’m lost. Did I miss the README file somewhere?
Keywords: (none) => feedback
(In reply to Brian Rockwell from comment #5) > The configuration changes – I didn’t find the README.urpmi. I did click on > update notes, but they just pointed to the /etc/nextcloud/config.php.rpmnew > file. > > I looked at it. This isn’t clear what needs to be changed at all. > > I’m lost. > > Did I miss the README file somewhere? Thanks for testing. The README file is the updates notes. It is in /usr/share/doc/nextcloud. The problem is that configuration changes a lot. End users should probably just copy database and path from /etc/nextcloud/config.php to /etc/nextcloud/config.php.rpmnew and then replace the first with that last. I don't see a clean way to do this automaticaly...
ok - updated the config.php and was able to get it set up. With sqllite is lost my users and required me to reset them up. As long as I named them the same I got my document directories back. that could be convenient or quite frightening pending how you think about it. Jose did you run into the same thing?
(In reply to Brian Rockwell from comment #7) > ok - updated the config.php and was able to get it set up. > > With sqllite is lost my users and required me to reset them up. As long as > I named them the same I got my document directories back. that could be > convenient or quite frightening pending how you think about it. > > Jose did you run into the same thing? No. You should not lose you sqlite database. I have just tested with MariaDB database, but it should be the same. Can you ensure you choosed the same path for sqlite database?
When I started nextcloud, the application started as if new not upgraded, so it must of overlaid the database. I didn't have an option for choosing the directory. I suspect this is part of the "cost" of using sqlite. The rest of the application has worked fine, but I do see that risk.
(In reply to Brian Rockwell from comment #9) > When I started nextcloud, the application started as if new not upgraded, so > it must of overlaid the database. I didn't have an option for choosing the > directory. > Got it : as data has moved, you have to move your data directory when upgrading, or keep the old path in the config file : BEFORE: "datadirectory" => "/usr/share/nextcloud/data", AFTER: "datadirectory" => "/var/lib/nextcloud/data", As /usr/share/nextcloud/data was a symlink to /var/lib/nextcloud, it means one has to move /var/lib/nextcloud/* to /var/lib/nextcloud/data except data and apps directories. This upgrade is hard for those who have kept the default config!
As mentioned earlier, I retained the data directory, the old data was there, but not the database of users. So, there is something else in the database, I'll try another tomorrow and see if I emulate the same thing or can get it to work. If I can and I suspect it has to do with the hashes, I suspect we need to document carefully the configuration updates.
(In reply to Brian Rockwell from comment #9) > I suspect this is part of the "cost" of using sqlite. Forget my comment 10. You are right, I could reproduce the problem : nextcloud replaces existing sqlite file if you remove the installed => true line in config file. So this is a end user bug, where I can just say sys admin have to add this 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, ), ),
Hi - did a fresh build of 11.03. Built it and a user. Then installed 12.03, indicating as such as "installed" => true the system then tried to do the upgrade then flagged back that it cannot do upgrades between major versions. changed "installed" => false, this triggered a replace of the users, but data was retained. ----- It works, but no luck with the upgrade.
fyi - on a straight install of Nextcloud 12.03 it ends up failing for me. Apparently in that version SQLite is not a standard part of the install and thus the system is looking for mysql/mariadb. While those are certainly more powerful, they also create a whole new set of configuration challenges. In my case, mariadb was not installed yet NextCloud assumed it was. I ended up in this broken situation with no path to install that was in anyway easy. What did I do? I went back to Nextcloud 11.03 and built that. Is this upstream that they are dropping sqlite or is it our choice? If it is ours, please add that as part of the build for 12.03.
Okay - tried another 12.03 rebuild. included nextcloud-sqlite module --- didn't work. --- added php-pdo_sqlite-3:5.6.33-1.mga6.x86_64 ---- rebooted an it worked.
(In reply to Brian Rockwell from comment #15) > Okay - tried another 12.03 rebuild. > > included nextcloud-sqlite module > > --- > > didn't work. > > --- > > added > > php-pdo_sqlite-3:5.6.33-1.mga6.x86_64 > > ---- > > rebooted an it worked. we should probably makes the php-pdo-sqlite a dependency on nextcloud-sqlite (12.03) module I'll move on to mariadb and upgrade testing later today.
I installed Mariadb and restarted the system and confirmed mysqld is running. Next I hardened Mariadb using the script: mysql_secure_installation go through the prompts and set up admin password and clean-up anonymous stuff. Then log in as root using: # mysql -u root -p Once you’re in. Then set up a database for nextcloud. I’m very dynamic and original so I named my database next. MariaDB [(none)]> create database next; --- mariadb configured. Now installed nextcloud 11.03 Note, 11.03 tries to use sqlite by default. To correct this I had to add the php-pdo_mysql and restart everything to make it able to access mariadb. Fyi – removed php-pdo-sqlite as well. Also – all my work to create the nextcloud user was unnecessary for testing. It wants root anyhow. Added a user and tested the systems ability to save files. Upgrading to 12.03 The following 4 packages are going to be installed: - nextcloud-12.0.3-2.mga6.noarch - nextcloud-mysql-12.0.3-2.mga6.noarch - php-exif-5.6.33-1.mga6.x86_64 - php-ldap-5.6.33-1.mga6.x86_64 Working with the config.php was a lot of experimenting, but ultimately I was able to do an upgrade, using default data directory.
Keywords: feedback => (none)Whiteboard: (none) => mga6-64-ok
This update worries me, which is why I hold the advisory. Brian had a hell of a time testing it, trying one way then another. Several things strike me: * The previous version presumed the use of SQlite, the new one MySQL. There must be no obstacle to carrying forward the existing database. * > we should probably makes the php-pdo-sqlite a dependency on nextcloud-sqlite > (12.03) module Yes. And the same for the mariadb/MySQL? Or is 'php-pdo_mysql' already a dependancy of 'nextcloud-mysql'? * That apart, there is a host of information related to the update. > The README file is the updates notes. It is in /usr/share/doc/nextcloud Is this the message posted to read during the update? Are *all* the changes needing to be done by the user noted? Including config.php? The note should include the fact that it can be found in /usr/.../nextcloud. Is it worth posting it here to cross-check that everything that has been found along the way is covered? * In C13 Brian found (I think) that doing the update was refused because it was a version change. He had to frig the update to 'install' for it to go ahead, when it lost the user database. Is this problem still with us? It is not mentioned in C17.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #18) > > * In C13 Brian found (I think) that doing the update was refused because it > was a version change. He had to frig the update to 'install' for it to go > ahead, when it lost the user database. Is this problem still with us? It is > not mentioned in C17. Hi Lewis - C13 remains with sqlite. Mariadb/mysql - nextcloud allows an upgrade. Yes the steps need to be documented out, I hacked around until it worked, could take some hours to document carefully. Do you need me to focus on the steps that worked for me? It will involve doing snapshots of the config files before and after the updates. We should drop that in the /usr.../nextcloud directory. Also, it may be wise to try a non-default directory for the data. In the end, nextcloud and it's parent owncloud are challenging to do major upgrades.
The procedure is documented. See https://wiki.mageia.org/en/OwnCloud#Upgrading I haven't checked to see if the instructions are current, or need changes.
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #20) > The procedure is documented. See > https://wiki.mageia.org/en/OwnCloud#Upgrading > I haven't checked to see if the instructions are current, or need changes. Feel free! @Brian : Since you have installed the update, it should have the README file in /usr/share/doc/nextcloud/ ; is it short enough to post here? If not, please post it on the qa-discuss thread you raised in parallel. We can review it; and if it is insufficient, enhance it as necessary.
You should choose to keep rpmnew, but keep the original config.php (if you haven't made a copy). First thing you'll see after the rpmnew message: Upgrade information Starting with Nextcloud version 12, the config file changes a lot. When upgrading from a previous version, you will have to edit by yourself the config file using /etc/nextcloud/config.php.rpmnew as reference. ---- information in /usr/share/doc/nextcloud -rw-r--r-- 1 root root 47329 Sep 19 16:12 config.sample.php -rw-r--r-- 1 root root 8868 Sep 19 16:12 AUTHORS -rw-r--r-- 1 root root 232 Dec 25 03:41 README.urpmi [root@localhost nextcloud]# pwd /usr/share/doc/nextcloud [root@localhost nextcloud]# cat README.urpmi Upgrade information Starting with Nextcloud version 12, the config file changes a lot. When upgrading from a previous version, you will have to edit by yourself the config file using /etc/nextcloud/config.php.rpmnew as reference. I've backed up the old config.pho and made config.rpmnew the main file. I'll work on what changes..
<Users> An important thing to know, the information in your old configuration file will be different in content from this example # diff config.php config.1103 3,25c3,21 < "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, < ), < ), --- > 'instanceid' => 'ocmfkpxhsfta', > 'passwordsalt' => 'faAL9AqvJF9G1KIKkX14LonwHbHNzy', > 'secret' => 'mX15c1TjBZwWZf/th934RtuJQuF0L5hlnE2PMaZgS4B9PENi', > 'trusted_domains' => > array ( > 0 => '127.0.0.1', > ), > 'datadirectory' => '/usr/share/nextcloud/data', > 'overwrite.cli.url' => 'http://127.0.0.1/nextcloud', > 'dbtype' => 'mysql', > 'version' => '11.0.3.2', > 'dbname' => 'next', > 'dbhost' => 'localhost', > 'dbport' => '', > 'dbtableprefix' => 'oc_', > 'dbuser' => '<dbuser>', > 'dbpassword' => '<dbseed>', > 'logtimezone' => 'UTC', > 'installed' => true, Reviewing this I will add below "preview_libreoffice_path" => '/usr/bin/libreoffice',: 'instanceid' => 'ocmfkpxhsfta', 'passwordsalt' => 'faAL9AqvJF9G1KIKkX14LonwHbHNzy', 'secret' => 'mX15c1TjBZwWZf/th934RtuJQuF0L5hlnE2PMaZgS4B9PENi', Then I will add the following after the "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, ), ), This is pulled over from the old config file 'dbtype' => 'mysql', 'version' => '11.0.3.2', 'dbname' => 'next', 'dbhost' => 'localhost', 'dbport' => '', 'dbtableprefix' => 'oc_', 'dbuser' => '<dbuserid>', 'dbpassword' => '<dbpasswordseed>', 'logtimezone' => 'UTC', 'installed' => true, The config file is closed with: ); Once I’ve saved the config.php file, I go ahead and reboot. You can stop and start the instance if you’d like. When you return to the Nextcloud url, you’ll see the upgrade page. I run the upgrade page and it works. If you look at the config.php file after the upgrade, you’ll see that nextcloud has revised it as needed. <<<Hackers, be aware this is built on a VM I’m throwing away, so don’t get too excited>>>
I really don't like the idea of an update that requires such extensive changes. That said, as long as the readme.urpmi is clear on the needed changes, and given that the package is likely only used by more experienced users, I think we should allow this as an update. While the list of srpms is available above, we still need the purpose of the update, list of cve ids (if any), etc., for the advisory.
Adding the feedback tag. Please remove it when the info for the advisory has been added to this report.
Good work guys :) It is very convenient Nextcloud is packaged - That way it can be used by many single person/small companies/organisations or even home use. (In reply to Dave Hodgins from comment #24) > I really don't like the idea of an update that requires such extensive > changes. I agree with that. Many are like me, or less, that find Nextcloud is useful for internal needs, and they do not know much about cleaning up a mess. They cold probably read up on it, but do not want that surprise mess just suddenly landing on them when they just do not have the time but they need the server running. Many small internal installations may not even need update, those fractional-time-admins may not want to throw time on clearing out mess with some old incompatible plugin, or whatever, when they want to just continue their normal completely different occupation... As we do not have any repo for "know problematic and potentially borking updates" i suggest to "mis"use backport like before, to avoid some users borking their installation by ignorance or mistake. Still, for security updates some sites should be upgraded, si it is good if users be informed. Idea: What if we have a package that updates in normal updates repos, and the only thing that package do is trig that "This update comes with important information" dialog, and in that tell the user there is an update in backports, and also show a link to https://wiki.mageia.org/en/Nextcloud. That package should be pulled in as dependency first time Nextcloud is installed. User is then informed, and can read up and perform the update. (And/or note in blog there is a new Nextcloud, but all do not read it.) Note the difference from a message popping up *after* the update: "Please now check your server this update potentially borked... You must now... etc, etc..." ;) Note I am very grateful for you packaging it, it is just the serving i wish there is some caution with :) > Starting with Nextcloud version 12, the config file changes a lot. > When upgrading from a previous version, you will have to edit by yourself > the config file using /etc/nextcloud/config.php.rpmnew as reference. Well put. Maybe you can update https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12 When the update is settled? And may other info you see fit. :)
CC: (none) => fri
(In reply to Morgan Leijström from comment #26) > As we do not have any repo for "know problematic and potentially borking > updates" i suggest to "mis"use backport like before, to avoid some users > borking their installation by ignorance or mistake. > The problem is that even with backports, people won't install it except they are advanced users, and read the Wiki etc. But Ok, I will submit this to backports, we'll see if it helps. Sysadmins, please remove this update from updates_testing. SRPM : nextcloud-12.0.3-2.mga6.srpm RPMS : nextcloud-12.0.3-2.mga6.noarch.rpm nextcloud-mysql-12.0.3-2.mga6.noarch.rpm nextcloud-postgresql-12.0.3-2.mga6.noarch.rpm nextcloud-sqlite-12.0.3-2.mga6.noarch.rpm
Yes the idea is to avoid unexperienced users getting into trouble. Thanks /Morgan
Whiteboard: mga6-64-ok => (none)Keywords: feedback => (none)
Well, the need for a security update has changed our plans. Bug 22936 will bring version 12.0.6. Of course, a manual tweak of the config file is still needed, but our users will not stay with an unsupported version.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
Sure - ping me when you have the updates out there. Also, if we could add the instructions for migrating in the readme, detailed, I think that will go a long ways towards getting this moved along.
(In reply to Brian Rockwell from comment #30) > Sure - ping me when you have the updates out there. > > Also, if we could add the instructions for migrating in the readme, > detailed, I think that will go a long ways towards getting this moved along. Thanks for the help. All is done in bug 22936.