CentOS 7.x Upgrade owncloud to newer version or updated stack
From Notes_Wiki
Home > CentOS > CentOS 7.x > Web Based Tools > owncloud > CentOS 7.x Upgrade owncloud to newer version or updated stack
There is newer version of this article at: Rocky 9.x Owncloud upgrade by migrating to a new VM with updated version
CentOS 7.x upgrade owncloud to newer version or updated stack using following steps:
The steps were built while upgrading source based installation of owncloud 9.1 and migrating to bitnami stack based installation of 10.1. For other versions use steps judiciously.
- Take database dump of older owncloud
- Restore database dump to newer owncloud using database crendentials of new server. For this no need to start apache/owncloud interface. Only start mysqld database on new server.
- For example in case of bitnami do "./ctlscript.sh start mysql"
- For this use steps similar to:
- Run "/opt/owncloud-10.1.0-1/mysql/bin/mysql -u bn_owncloud -p" on bash to get mysql prompt for running further commands
- drop database bitnami_owncloud;
- create database bitnami_owncloud;
- use bitnami_owncloud;
- source <path-to-sql-dump-from-old-server>;
- exit
- The path of data folder is hard-coded in database and full path hashes are used to search for file folder. Hence ideally we need to leave data folder at old location and only update datadirectory parameter in owncloud configuration file at '/opt/owncloud-<version>/apps/owncloud/htdocs/config/config.php.
- If older data directory is not from bitnami owncloud setup then setting daemon:daemon ownership is important.
- If it is really critical to move data directory then be prepared to build a new filecache using "occ files:scan" But whether doing this for entire server breaks sharing is not known.
- cd owncloud htdocs folder
- Eg /opt/owncloud-10.1.0-1/apps/owncloud/htdocs
- Then try to upgrade owncloud
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ maintenance:mode --on
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ upgrade
- This might show error such as
- ownCloud or one of the apps require upgrade - only a limited number of commands are available
- You may use your browser or the occ upgrade command to do the upgrade
- 2019-03-13T09:01:56+00:00 Set log level to debug
- 2019-03-13T09:01:56+00:00 Repair step: Upgrade app code from the marketplace
- 2019-03-13T09:01:56+00:00 Repair warning: You have incompatible or missing apps enabled that could not be found or updated via the marketplace.
- 2019-03-13T09:01:56+00:00 Repair warning: Please install or update the following apps manually or disable them with:
- occ app:disable activity
- occ app:disable files_pdfviewer
- occ app:disable files_texteditor
- occ app:disable gallery
- occ app:disable templateeditor
- 2019-03-13T09:01:56+00:00 Repair warning: For manually updating, see https://doc.owncloud.org/server/10.1/go.php?to=admin-marketplace-apps
- 2019-03-13T09:01:56+00:00 OC\RepairException: Upgrade is not possible
- 2019-03-13T09:01:56+00:00 Update failed
- 2019-03-13T09:01:56+00:00 Maintenance mode is kept active
- 2019-03-13T09:01:56+00:00 Reset log level
-
- In lab tests we have observed error for 'files_antivirus' is not shown during upgrade from 9.1 to 10.0. Also it makes sense to download apps such as onlyoffice and user_ldap at this stage if they were in use in previous setup before continuing with 'occ upgrade' so that these apps also get upgrades properly.
- user_ldap app can be downloaded from https://github.com/owncloud/user_ldap/releases
- onlyoffice app can be downloaded from https://marketplace.owncloud.com/apps/onlyoffice
- Based on this disable apps using
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ app:disable activity
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ app:disable files_pdfviewer
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ app:disable files_texteditor
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ app:disable gallery
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ app:disable templateeditor
- Then again try update using:
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ upgrade
- which might show error such as
- ownCloud or one of the apps require upgrade - only a limited number of commands are available
- You may use your browser or the occ upgrade command to do the upgrade
- 2019-03-13T09:07:29+00:00 Set log level to debug
- 2019-03-13T09:07:29+00:00 Repair step: Upgrade app code from the marketplace
- 2019-03-13T09:07:29+00:00 Repair step: Repair MySQL database engine
- 2019-03-13T09:07:29+00:00 Repair step: Repair MySQL collation
- 2019-03-13T09:07:29+00:00 Repair info: Change collation for oc_activity ...
- 2019-03-13T09:07:29+00:00 Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'ALTER TABLE `oc_activity` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;':
- SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
- 2019-03-13T09:07:29+00:00 Update failed
- 2019-03-13T09:07:29+00:00 Maintenance mode is kept active
- 2019-03-13T09:07:29+00:00 Reset log level
-
- This error is common while upgrading from 9.1 to 10.0. Hence while upgrading from 9.1 to 10.0 to avoid this error in first place edit '/opt/owncloud-10.1.0-1/apps/owncloud/htdocs/config/config.php' and update to ''mysql.utf8mb4' => false,'
- To fix MySQL issues on upgrade use
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ config:system:set mysql.utf8mb4 --type boolean --value="false"
- then upgrade using
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ upgrade
- and then disable maintenance mode using:
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ maintenance:mode --off
- If user_ldap app was used in 9.1 and then upgraded to 10.0 then note that LDAP users do not automatically show up until sync is run. For this use steps:
- Run manual sync using:
- cd /opt/owncloud-10.1.0-1/apps/owncloud/htdocs
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ user:sync "OCA\User_LDAP\User_Proxy"
- Example IO for this is
- If unknown users are found, what do you want to do with their accounts? (removing the account will also remove its data)
- [0] disable
- [1] remove
- [2] ask later
- > 2
- Analysing known accounts ...
- 3 [============================]
- No removed users have been detected.
- Inserting new and updating all known users from OCA\User_LDAP\User_Proxy ...
- 169 [============================]
-
- Based on below references:
- Run manual sync using:
- Optionally create or update previous /etc/cron.daily/owncloud-maintenance.sh with
- #!/bin/bash
- cd /opt/owncloud-10.1.0-1/apps/owncloud/htdocs
- sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php -f cron.php
- Set execute permissions on cron file and test it:
- chmod +x /etc/cron.hourly/owncloud-maintenance.sh
- /etc/cron.hourly/owncloud-maintenance.sh
- Run maintenance many times till it starts to finish immediately indicating no more pending tasks in queue.
- Check the backup configuration in /opt/take-database-backup.sh and update php path and DB password. Check if the backup is working properly. If there is issue related to missing PROCESS privilege(s) then use following:
- Reset MySQL / MariaDB root password by refering https://docs.bitnami.com/general/apps/owncloud/administration/change-reset-password/
- Then get MysQL process privilege as captured in steps at CentOS 7.x update lightsail redmine instance
- show grants for bn_owncloud@localhost;
- GRANT USAGE,PROCESS ON *.* TO `bn_owncloud`@`localhost`;
- flush privileges;
- \q
- Test the backup again. If there is warning for 'Using a password on the command line interface can be insecure.' use sshpass to work around it
- If the site is public with FQDN then optionally get lets-enncrypt certificate using:
- /opt/owncloud-<version>/bncert-tool --perform_dns_validation 0
- Perhaps there is no www.<owncloud-fqdn> and you may want to configure email relay via Gmail (Assuming Gmail ID has less secure-apps option enabled).
- The certificate generation may show warning related to old cron entries ignore it. You should update cron entry added by bn_cert from 0 0 * * * to A B * * 0 where A is between 0 and 59 and B is between 0 and 6. Also most importantly the certificate generation has perhaps started apache. If we are not ready for clients to connect to updated instance yet, immediately stop apache using:
- /opt/owncloud-<version>/ctlscript.sh stop apache
- At this point apache/owncloud frontend can be started.
- Example command ./ctlscript.sh start apache
Refer:
Additional lessons while using above process to upgrade owncloud
Used above steps to update from an older bitnami stack to newer bitnami stack. Some of the differences / additional lessons learned are captured below:
Wrong ownership on config/config.php file
During updated stack installation installation may fail with log output in /tmp such as:
Owner of config.php: daemon Try adding 'sudo -u daemon ' to the beginning of the command (without the single quotes) Console has to be executed with the user that owns the file config/config.php Current user: root #On the screen you might see Script stderr: child process exited abnormally Error running /opt/owncloud-10.5.0-1/apps/owncloud/scripts/owncloudinstall.sh : child process exited abnormally Problem running post-install step. Installation may not complete correctly Error running /opt/owncloud-10.5.0-1/apps/owncloud/scripts/owncloudinstall.sh : child process exited abnormally Executing /opt/owncloud-10.5.0-1/ctlscript.sh stop apache > /dev/null 2> /dev/null Script exit code: 0
To solve this open another terminal and run:
while true; do chown root:root /opt/owncloud-<version>/apps/owncloud/htdocs/config/config.php; sleep 1; done
With this the new log output in /tmp should be similar to:
Executing /opt/owncloud-10.5.0-1/apps/owncloud/scripts/owncloudinstall.sh Script exit code: 0
Onlyoffice avoid self-signed certificate validation
In config.php for owncloud include:
'onlyoffice' =>
array (
'verify_peer_off' => true,
),
Download apps before the upgrade in the new setup
We can compare the list of apps 'ls /opt/owncloud-<version>/apps/owncloud/htdocs/apps' between both old and new version. In case there are apps in older version that are not present in newer bitnami stack by default, we can download and keep extracted version of them in newer stack apps folder to upgrade them seamlessly while upgrading stack.
If there is an app for which newer version is not available we need to disable it using:
#:: sudo -u daemon /opt/owncloud-10.1.0-1/php/bin/php occ app:disable
before upgrade. For example during a specific upgrade the comparison result was:
[root@ldap ~]# diff old-apps.txt new-apps.txt 9a10 > files_mediaviewer 13d13 < files_videoplayer [root@ldap ~]#
Based on this disabled files_videoplayer during upgrade. Also validated that files_mediaviewer can play videos. This was necessary as no updated version of videoplayer was available on owncloud marketplace.
occ upgrade fails with table error
If "occ upgrade" failed due to columns on oc_activity table with error
2020-10-02T18:58:39+00:00 Repair info: Change collation for oc_accounts ... 2020-10-02T18:58:44+00:00 Repair info: Change collation for oc_activity ... 2020-10-02T19:09:32+00:00 Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'ALTER TABLE `oc_activity` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;': SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs 2020-10-02T19:09:32+00:00 Update failed 2020-10-02T19:09:32+00:00 Maintenance mode is kept active 2020-10-02T19:09:32+00:00 Reset log level
Then based on https://github.com/nextcloud/news/issues/226 dropping oc_activity table seemed likely a good idea as activity history is not that critical. Much more information about owncloud database structure has been learned since this maintenance and is available at CentOS 8.x Owncloud direct DB queries
Note that "occ upgrade" also took considerable time of total 12.5+ hours. Most time was spent in step
"Repair info: Change collation for oc_filecache..."
Home > CentOS > CentOS 7.x > Web Based Tools > owncloud > CentOS 7.x Upgrade owncloud to newer version or updated stack
