If anyone wants steps I followed to make this “just work”, please let me know. There were a number of queries that had to be run in between upgrades getting to NextCloud 11 and then there was the upgrade to php 7.1 and the opcache and the rest.
If anyone wants me to document what I did, let me know and I will. I got it to a repeatable process where I was finally able to run the production upgrade in 1h when I was finally ready to switch over and sure it all worked.
Your documented procedure to make a multi-release jump up to Nextcloud 11 could be very helpful for me. I’m on OC 8.1.1 which serves a number of family+friends. The same instance has been running for ~18 months 24/7 and I need to minimise downtime with upgrades. The prime OC storage is external on a RAID5 NAS box using an isolated NFS LAN. The OC encryption feature is active along with a local-host mySQL instance.
If you think your documentation would be applicable or “good guidance” for upgrading my set-up then I would appreciate this knowledge.
Cheers…!
Using such outdated versions with known vulnerabilities (https://owncloud.org/security/advisories/) is careless, you should be running 8.1.11 (Changelog - ownCloud).
You need to go through all major upgrades,
OC 8.1.1 → OC 8.1.11 → OC 8.2.9 → NC 9.0.55 → NC 10.0.2 → NC 11.0.0
Make a full backup (database, keys, data, config-file) of the current setup because there is no other way to downgrade. After each major upgrade, it’s also a good idea to login, see if you can access al files, then enable all apps since there might be some changes to their database as well.
Plan some time to carry out the whole update procedure, especially with the encryption app it is worth double checking and reading the upgrade-notices.
Thank you for this observation on the OC 8.1.1 that I am running. My situation has been that ownCloud 8.1.1 was so incredibly stable that I just left well alone. Perhaps for too long, but I never expected it to stretch and be operational this far. Now I find that my vague memories of the set-up options and results are unsure. Almost like I’m back to square-one.one… I mean, Nextcloud one.one
@tflidd - you may be a “support hero” but your choice of words are far more harsh than you may realize.
One of the things I found infuriatingly debilitating in the ownCloud community was the hubris that anyone that could do or had done was in some way better than the rest of us that also could do. And that one person’s viewpoint was the “right one.” Even when someone was offering a choice or an alternative solution instead of just complaining.
I would like to take this moment to refer to your comment of @humbug’s use of 8.1.1 as “careless”. Without knowing his situation, you passed a value-judegment. While you are correct that he was “vulnerable,” careless implies that he intentionally left himself vulnerable without weighing the risks of upgrading and/or his regard for and his ability to handle security was incompetent. I do not know whether this was your intent. But this is what came across.
Perhaps your future posts will be more helpful, and thoughtful and less judgemental. We would all like to keep this community positive and not have to have people be pointing fingers at each other.
Thanks for listening.
My upgrade path was:
7.0.1.1 -> 7.0.4.2 -> 8.0.0.7 -> 8.1.9.2 -> 8.2.7.1 -> 9.0.4.1 (OC) -> 10.0.0.2 (NC) -> 11.0.0.0 (NC)
I found the upgrade to 9.0.55 (NC) to be extremely painful.
Funny enough, your comment is actually “Bang-On” target with my situation. I am very “risk-aware” as it is embedded from a long Sysprog career in IBM mainframes and DR contingency. Being “careless” would have jeopardised my pension. Rest assured @tflidd that I have set-up my ownCloud system focused on covert availability hidden behind a good firewall. What I find “careless” is my kids and similar folk who are oblivious to the value of their “data” and how easily it can be lost. With my significant domestic investment in IT equipment, the biggest security+availability threat that it faces is burglary, fire damage and my mortality. One of which is a certainty. 
Sorry, someone gave me this “title” I didn’t do this myself. At certain points I’m human as well, especially when you see certain types of questions over and over again. Then a harsh comment hits someone who actually doesn’t deserve it.
However, for me “careless” doesn’t imply that he did it intentionally. If he operated his ownCloud behind a VPN, there wouldn’t be any risk to anybody outside of it. Other more common php software (Wordpress, Joomla, …) is known to be targeted once security issues get public. This leaves you very little time to upgrade these setups. Nextcloud is not that popular yet. Spam mails, bot net attacks, … that gets quickly a problem for many people.
Coming back to @humbug, after a short post you don’t know the complete situation of the other person and you tend to judge based on this little information you get. The best situation is to run an up to date software without known security vulnerabilities. Firewalls can help to prevent certain attacks, and even if something happens you can control the situation. Sorry that I got you into the pot with the 99% who think their system is secure because they use a different port.
Unfortunately, all this upgrading in owncloud/Nextcloud is a nightmare. Frequent releases and cumbersome updates hold you back and if you miss some of them, you have to respect a certain order (don’t skip major upgrades). If you are part of this Nextcloud-ecosystem, you get used to it and somehow expect other to do so as well instead of forcing better software. You can improve documentation and write FAQs but this must work out of the box.
On the forums, if you are not a developer, you can’t do much except pointing it out to the developers. Nextcloud wrote a completely new updater app and a new app store, two things that have been criticized for a very long time. This is a remarkable improvement but there is certainly progress to be made.
How do you want me to share my update scripts? A few preconditions exist in order to make this fly. Should I post the files here or should I post the files somewhere else? Do we have a community “NextCloud” instance for this sort of thing?
Ok, so here is the update process - you may need to edit the files but I have included all the parts for the automated run. Please be advised, this is designed for automated upgrade and manual downgrade. Restore only requires the version number to restore to.:
#!/bin/sh
# update.sh file
set -x
BASE="bak"
OC="owncloud"
NX="nextcloud"
FILE="$1"
shift
VERSION=`grep version owncloud/config/config.php | cut -f2 -d\> | cut -f2 -d\'`
BKP="$BASE/$OC.$VERSION-installed.tar.bz2"
CFG="owncloud/config/config.php"
CFGNEW="bak/config-$VERSION.php"
./backup.sh
echo "Removing old owncloud content"
umount $OC/data -v
rm -rf owncloud
tar jxf $FILE
if [ -d "$NX" ] ; then
mv $NX $OC
fi
cp "$CFGNEW" "$CFG" -v
mkdir $OC/data
chown -R apache.apache $OC
mount $OC/data -v
sudo -u apache php $OC/occ maintenance:mode --on
sudo -u apache php $OC/occ upgrade
if [ $? -eq 0 ] || [ "$1" == "--auto" ] ; then
sudo -u apache php $OC/occ maintenance:mode --off
else
echo -n Upgrade did not complete - turn off maintenance mode? [N/y]
read REPLY
if [ "$REPLY" == "y" ] || [ "$REPLY" == "Y" ] ; then
sudo -u apache php $OC/occ maintenance:mode --off
else
echo Maintenance mode not turned off
fi
fi
if [ "$2" != "--nostop" ] ; then
echo -n "Continue? [N/y] "
read REPLY
if [ "$REPLY" != "y" ] && [ "$REPLY" != "Y" ] ; then
exit
fi
fi
# EOF
#!/bin/sh
# backup.sh
set -x
BASE="bak"
if [ ! -d "bak" ] ; then
mkdir "bak"
fi
OC="owncloud"
NX="nextcloud"
if [ "$1" != "" ] ; then
SUFFIX="-$1"
shift
else
SUFFIX=
fi
VERSION=`grep version owncloud/config/config.php | cut -f2 -d\> | cut -f2 -d\'`
BKP="$BASE/$OC.$VERSION$SUFFIX-installed.tar.bz2"
CFG="owncloud/config/config.php"
CFGNEW="bak/config-$VERSION$SUFFIX.php"
umount $OC/data -v
echo Creating archive $VERSION$SUFFIX
tar cjf $BKP $OC
cp "$CFG" "$CFGNEW" -v
echo Dumping database $VERSION$SUFFIX
mysqldump --add-drop-database --add-drop-table owncloud > $BASE/$OC-$VERSION$SUFFIX.sql
mount $OC/data -v
# EOF
#!/bin/sh
# update-all.sh
set -x
./update.sh /root/data/owncloud.archive/owncloud.7.0.4.2-18-15.tar.bz2 --auto $*
mysql owncloud < fix.7.0.4.sql
./update.sh /root/data/owncloud-upgrade/owncloud-8.0.0.tar.bz2 --auto $*
./update.sh /root/data/owncloud.archive/owncloud-8.1.9.tar.bz2 --auto $*
sudo -u apache php owncloud/occ upgrade
sudo -u apache php owncloud/occ maintenance:mode --off
./update.sh /root/data/owncloud.archive/owncloud-8.2.7.tar.bz2 --auto $*
mysql owncloud < fix.9.0.4.sql
./update.sh /root/data/owncloud.archive/owncloud-9.0.4.tar.bz2 --auto $*
#./update.sh nextcloud-9.0.55.tar.bz2
#./update.sh nextcloud-10.0.2.tar.bz2 --auto $*
./update.sh nextcloud-11.0.0.tar.bz2 --auto $*
# EOF
# fix.sql
if exists table oc_dupes drop table oc_dupes;
create table oc_dupes(numeric_id int);
insert into oc_dupes
select o1.numeric_id from oc_storages o1 join oc_storages o2 where case when o1.id="home::" then o2.id="local::/var/www/html/owncloud/data" else locate(concat('/',right(o1.id,length(o1.id)-6)),o2.id)<>0 end and o1.id like 'home::%' and o2.id like 'local::%';
delete from oc_storages where numeric_id in (select * from oc_dupes);
update oc_appconfig set configvalue='no' where configkey='enabled' and appid='gallery';
# owncloud 9.0.4 updates
drop table oc_addressbooks;
drop table oc_notifications;
drop table oc_trusted_servers;
drop table oc_cards;
drop table oc_addressbookchanges;
drop table oc_calendarobjects;
drop table oc_calendars;
drop table oc_calendarchanges;
drop table oc_calendarsubscriptions;
drop table oc_schedulingobjects;
drop table oc_cards_properties;
drop table oc_dav_shares;
# EOF
#!/bin/sh
# restore.sh
set -x
umount owncloud/data
if [ ! -d "owncloud/data/.ocdata" ] ; then
rm -rf owncloud
tar jxf bak/owncloud.$1-installed.tar.bz2
mysql owncloud < bak/owncloud-$1.sql
mount owncloud/data
else
echo Umount did not work
fi
# EOF