Prevent downgrades

[LukasReschke]

There are a ton of users that are downgrading their instances in case they encounter some bug after upgrading. We had already quite often that this resulted in situations that were impossible to debug. ("Huh? How can this possibly happen?")

This is something which can lead to really really really big problems. Now they believe it's just fine to replace the files again and hope everything runs fine. It's certainly not. If one wants to downgrade they should use their backups.

We should add the latest version to the DB and do some logical check when the version decreased or so. Just like the update check.

[LukasReschke]

Thoughts?

cc @DeepDiver1975 @PVince81

[PVince81]

Maybe. But make it only detect patch level downgrades, not micro version (the fourth digit), so we devs can still easily switch versions without having to reset the DB every time.

[ghost]

Definitely useful 👍 Had some users at the forums in the past which downgraded against the advice that downgrading is not supported.

Ref for the documentation part: owncloud-archive/documentation#1458

[tflidd]

Couldn't you implement some scareware in the upgrade process to motivate backups? Some blank screen or an error-message? Finally, people will be relieved that their data isn't gone, only a shocking moment. They do a backup and then run their upgrade?
This sounds extreme but currently a large number of users end up with an unusable owncloud and need to go back to the previous version. Most don't do backups. They learn it the hard way that backups are really important.
The problem of people going back to the old version is not that they are too lazy to use their backup, they don't have one.

[PVince81]

Or maybe OC should have a mechanism to automatically backup the data + the database.
Problem is for people who have too many files and such.

And in an enterprise env you cannot automatically backup several terabytes of data.

[DeepDiver1975]

They learn it the hard way that backups are really important.

We should not educate people

[DeepDiver1975]

Let's add a hard check on this - but as @PVince81 suggested - we should ignore the patch level

[carlaschroder]

They learn it the hard way that backups are really important.

We should not educate people

I'm all for lots of handholding. But we do have to draw a line, and saying HEY YOU NEED BACKUPS is over that line. What else do we warn against, don't lick electric sockets? Try not to fall off tall buildings? Don't eat yellow snow?

I'll figure out something for warning against downgrades.

[carlaschroder]

In the manuals, of course.

[carlaschroder]

owncloud-archive/documentation#1507

[PopovK]

Funny seeing this here, and especially now after the days I had with Owncloud recently.

While you're are right advocating for user to do backups, and be obviously aware of the need of them, I think you're not seeing the pain you're inflincting on you userbase with the huge amount of major changes you do in minor version. It is expected to do a restore for a downgrade from major to major, but a downgrade from x.2 to x.1 shouldn't require more than switching the instance symlink.

The jump from 7.x to 8.0 was hard, with calendar and contact removed from the core, and understanding the new behavior.

I had the luck to fall in the 8.1.0 encryption nightmare, should have know better to do an Owncloud upgrade after 8.0.

And today, just spent 2 days to debug the new smb lib and backported ldap memberof changes in 8.1.1 (whose both seems to have an insane memory leak, memberof with the special AD search string memberOf:1.2.840.113556.1.4.1941, and the smb lib doesn't play well with "use username as share" and the ldap setting "Internal Username Attribute" set to AD userPrincipalName, which kills the whole httpd instance )
Also, while you could see the libsmbclient-php as minor, you might have a big surprise with enterprise users, and the security policies you can encounter restricting 3rd party binaries (meaning libsmbclient-php is a no-go)

I also still have the app updater not working and choking on curl due to a cert error (and only the app updater show this error in the logs)

What you need to do is seriously hit the brakes on the internal changes, iron them on minor version (x.1, x.2, ...), and only, only introduce them in major version (ie, 8.0, 9.0 and so on).
With the amount of customizable options available in owncloud and the interactions between them, the base is getting to much unstable to withstand this storm of changes

The major grip I have is between all the backups at my disposal (db+data and full owncloud VM), they are far too old to fall back to the last 7.x. Guess I'll try the downgrade anyway ...

Or not, I'm sorry about it, but I'm too fed up with it to continue, and started to seek another non-google solution as replacement. A shame since I joined the boat with v4.

[ghost]

@PopovK oC 8.1 is a major release, not a minor release

[PVince81]

@LukasReschke I see this code from you, it seems to already forbid downgrades ?
See https://github.com/owncloud/core/blob/v8.1.1/lib/private/updater.php#L224

However this method hasn't been adapted for the new version scheme where 8.1->8.2 is a major version.

I'll fix this and cover both cases.

[PVince81]

Fix here #18625

[PVince81]

Nope, this needs a different fix.

I just realized that if you downgrade your version, the update page doesn't appear.

We need to add a check in base.php somewhere to check if version.php is lower than config.php, and then show a warning / block the UI ?

[PVince81]

Another alternative is to make needsUpgrade() return true when the core version is different, regardless which one is bigger than the other one.

[PVince81]

Fix here #18684 with the needsUpgrade approach

[PVince81]

Downgrades will no more be possible on 8.2 beta and the upcoming 8.1.4