Disable 3rdparty apps during upgrade to avoid broken installs

[ghost]

Hi,

the last day at this issue tracker and also the IRC channel has shown that many users are not disabling their 3rdparty apps as described in the upgrade docs.

This is causing broken installs like: #13999, #14023, #14020 etc.

It might be useful to disable all 3rdparty apps automatically during an upgrade to avoid such problems. This is especially needed as users with the packages from OBS probably more often not reading the manual upgrade instructions. (Ref.: owncloud-archive/documentation#714)

[DeepDiver1975]

I was actually thinking the same reading all the issues ....

[ghost]

Btw. this was also happening with older upgrades like from OC5 to OC6/7

[PVince81]

I thought we had this already but I remember that the update only disables incompatible apps (apps that do not meet the version requirements).

It might be an idea to disable third party apps during upgrade.
But then, do we ask the user to reenable manually ? (bad UX)

[ghost]

(bad UX)

Better UX than a completely broken installation. :-)

[DeepDiver1975]

I thought we had this already but I remember that the update only disables incompatible apps

The problem is that we cannot detect this reliably and an incompatible app will break the installation.

Furthermore an app needs to be updated (downloaded from the appstore) BEFORE is can be enabled.

Under this circumstance this approach seems reasonable.

[PVince81]

Too bad that we cannot try/catch the require_once call to the app's PHP scripts.

I'm dreaming of a better app design where apps actually publish classes with methods we can call like "create()" and "update()", methods for which we could catch exceptions reliably.

[buzzra]

@RealRancor @DeepDiver1975
In all fairness, this page:

http://doc.owncloud.org/server/8.0/admin_manual/maintenance/upgrade.html

has the "deactivate all third party apps" step listed under the "Manual Upgrade Procedure" heading. Before this in the document under the "Upgrading Your ownCloud Server" heading is this:

"The best method for keeping your ownCloud server on Linux servers current is by configuring your system to use the openSUSE Build Service, and then stay current by using your package manager to upgrade. You should still maintain regular backups (see Backing up ownCloud), and make a backup before every update/upgrade."

Which is the advice I followed. #14023
I also did NOT have this problem with previous upgrades. If I am using the recommended method, why would I follow instructions in the manual upgrade procedure? If the manual upgrade is always the preferred method, then the documentation on the ownCloud.org site should be updated to reflect this.

Please take this as constructive criticism and not complaining. I am very happy with my ownCloud, and appreciate all the help. I want ownCloud to be as bullet prooff as possible, so I can get more people to use it. The more individuals we can get using the community version, the more will take it into their businesses/workplace in the form of the enterprise version. Ease of upgrading is one of the most important in an enterprise situation.

Thanks,
buzz

[aspark21]

+1 with Buzzra on this one.

[PVince81]

Fixed by #14282 but let's wait for the backport before closing

@buzzra you might want to raise a ticket in the documentation repo: https://github.com/owncloud/documentation/issues (CC @carlaschroder)

[haffenloher]

you might want to raise a ticket in the documentation repo

Someone already did: owncloud-archive/documentation#839

[PVince81]

PRs were merged -> close

[KeithBronstrup]

Is it really necessary to disable all apps when upgrading within the 8.x branch, though? I just upgraded from 8.0.0 to 8.0.1 via my package manager and it (very annoyingly) disabled all of my apps; I thought this was only necessary for a major-version upgrade?

Is the app disabling routine a bit overzealous, or am I mistaken?

[ghost]

Yes, normally this should be only needed on major upgrades like OC7 to OC8.

[karlitschek]

In general I agree. Unfortunately we had cases where the ownCloud upgrade broke and users had an unusable ownCloud. To avoid this want to me as careful as possible.

[KeithBronstrup]

Sadly, the end result of that decision will be users who can't afford downtime blacklisting owncloud from automatic updates; that's not good for OC's security reputation.

At the very least, would it be possible to have OC put auto-disabled apps into a "recently disabled" category to make them easier to locate in the long list of applications many of us have (many of which there is no clear way to remove from the list), and remember the group restrictions of auto-disabled apps when they're re-enabled? I have a few that I really don't want non-admin users getting into, but it takes a few moments to finish re-enabling all of my apps, navigate to the "Enabled" page (which takes some time to load), locate the "restricted" apps, and re-restrict them.

I'll open a separate issue for this if necessary.

[KeithBronstrup]

@karlitschek wouldn't that still happen when the users re-enable the apps after the upgrade? I don't see the benefit to inconveniencing everyone in this instance.

[PVince81]

Or add a switch "disablethirdpartyappsonupgrade" in config.php that can be set to:

1. "never": never disables apps
2. "major": only disable on major updates
3. "always": disable on major and minor updates

I found it annoying too that apps are disabled even when I upgraded from 8.0.0-X to 8.0.0-Y (where X and Y are Suse package revisions, which general don't have any big changes that would affect apps, the upgrade was likely to be triggered by a bump of the fourth digit in versions.php)

[DeepDiver1975]

I honestly question if we really need more config switches - can we move this discussion to a new issue please - THX

[PVince81]

Let's continue here: #14754