Moodle

Backup will not work, if you "mix" Servers with and woithout MNET functionality

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.9.3
  • Fix Version/s: 1.9.4
  • Component/s: Backup
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_19_STABLE

Description

You cant restore a course which has been backuped with a MNET-enabled-Moodleserver to a non MNET-enabled-Moodleserver. I know there may be problems with users and rights, but we should find a solution, because not possibility to restore is no solution. Maybe just restoring the users as "standard users".
regards Peter

Issue Links

Activity

Hide
Peter Sereinigg added a comment -

Its urgent, there is no possibility to restore a mnet enabled server-course on a non mnet enabled server!

Show
Peter Sereinigg added a comment - Its urgent, there is no possibility to restore a mnet enabled server-course on a non mnet enabled server!
Hide
Martin Dougiamas added a comment -

Eloy could you please have a look at this and try to identify what the problem is? Perhaps there is a simple fix? You can play with moodle.org and dev.moodle.org if you like.

Show
Martin Dougiamas added a comment - Eloy could you please have a look at this and try to identify what the problem is? Perhaps there is a simple fix? You can play with moodle.org and dev.moodle.org if you like.
Hide
Eloy Lafuente (stronk7) added a comment -

Hi,

I've been tracing this (using one backup of dev.moodle.org containing mnet users), and one of these messages should be displayed for backups containing mnet users in the last page before launching restore:

1) If the restore host is the SAME, this should be showed:

Note: This backup file contains remote Moodle Network user accounts which will be restored as part of the process.

2) I the the restore host is DIFFERENT:

Note: This backup file apparently originates from a different Moodle installation and contains remote Moodle Network user accounts that may fail to restore. This operation is unsupported. If you are certain that it was created on this Moodle installation, or you can ensure that all the needed Moodle Network Hosts are configured, you may want to still try the restore.'

But these notes are NEVER showed. I've found the original cause of this, with that info being called MNET_REMOTEUSERS on backup but being called MNET_EXTERNALUSERS on restore. So previous steps of restore don't detect that the file contains external users and fails.

Note that, no matter of this bug (that only affects to restore not displaying the message above), the restore process, effectively... will break if find one user whose mnet host isn't defined in the restore site. And that's current behaviour.

So, I'm going to:

1) Fix the MNET_REMOTEUSERS / MNET_EXTERNALUSERS bug in order to show the info properly before executing the restore. It's trivial to fix (and crazy that it wasn't detected before!)

And then... I think we have three alternatives:

a) Prevent completely restore to happen if backup contains mnet users and restore site is different from backup site. Easy to do, but blocks restore unless the moodle.xml is edited and that remote info is changed (can be done with a "simple shell script" anyway.
b) Allow to restore those users, and if no match with mnet hosts is found... convert them automatically to "manual" users (noticing about it in restore). Semi-easy to do but will decouple users completely from their original host. Perhaps only admins should be able to do this.
c) Pre-check all the mnet hosts existing in backup and compare them with mnet hosts existing in restore site. Abort restore and request admin to create those sites before continue. Complex (the pre-check involves to parse the xml file too early), but perhaps the more consistent solution.

So, apart of 1) that I'm going to fix now... what approach do you think is the best in a) b) c). Personally, thinking into privacy issues and consistency, I feel inclined to a) preventing restore completely and requesting to modify backup file. But I understand it isn't a 100% functional solution.

Please, comment about a-b-c (or other alternatives). Ciao

Show
Eloy Lafuente (stronk7) added a comment - Hi, I've been tracing this (using one backup of dev.moodle.org containing mnet users), and one of these messages should be displayed for backups containing mnet users in the last page before launching restore: 1) If the restore host is the SAME, this should be showed: Note: This backup file contains remote Moodle Network user accounts which will be restored as part of the process. 2) I the the restore host is DIFFERENT: Note: This backup file apparently originates from a different Moodle installation and contains remote Moodle Network user accounts that may fail to restore. This operation is unsupported. If you are certain that it was created on this Moodle installation, or you can ensure that all the needed Moodle Network Hosts are configured, you may want to still try the restore.' But these notes are NEVER showed. I've found the original cause of this, with that info being called MNET_REMOTEUSERS on backup but being called MNET_EXTERNALUSERS on restore. So previous steps of restore don't detect that the file contains external users and fails. Note that, no matter of this bug (that only affects to restore not displaying the message above), the restore process, effectively... will break if find one user whose mnet host isn't defined in the restore site. And that's current behaviour. So, I'm going to: 1) Fix the MNET_REMOTEUSERS / MNET_EXTERNALUSERS bug in order to show the info properly before executing the restore. It's trivial to fix (and crazy that it wasn't detected before!) And then... I think we have three alternatives: a) Prevent completely restore to happen if backup contains mnet users and restore site is different from backup site. Easy to do, but blocks restore unless the moodle.xml is edited and that remote info is changed (can be done with a "simple shell script" anyway. b) Allow to restore those users, and if no match with mnet hosts is found... convert them automatically to "manual" users (noticing about it in restore). Semi-easy to do but will decouple users completely from their original host. Perhaps only admins should be able to do this. c) Pre-check all the mnet hosts existing in backup and compare them with mnet hosts existing in restore site. Abort restore and request admin to create those sites before continue. Complex (the pre-check involves to parse the xml file too early), but perhaps the more consistent solution. So, apart of 1) that I'm going to fix now... what approach do you think is the best in a) b) c). Personally, thinking into privacy issues and consistency, I feel inclined to a) preventing restore completely and requesting to modify backup file. But I understand it isn't a 100% functional solution. Please, comment about a-b-c (or other alternatives). Ciao
Hide
Eloy Lafuente (stronk7) added a comment -

Adding Martin here...

Show
Eloy Lafuente (stronk7) added a comment - Adding Martin here...
Hide
Eloy Lafuente (stronk7) added a comment -

1) above applied (now the messages are messages are showed properly if backup contains mnet users)

a-b-c pending to decide... ciao

Show
Eloy Lafuente (stronk7) added a comment - 1) above applied (now the messages are messages are showed properly if backup contains mnet users) a-b-c pending to decide... ciao
Hide
Peter Sereinigg added a comment -

a.) and c.) is no solution
b.) "backup this only for admins" and converting users (if they dont exist) to manual one, would be a solution until we may find a better way
In this case, admins may decide, we will restore, and maybe we will break some users, but this may be changed easily later...
Hope you can do b.)
Thanks eloy

Show
Peter Sereinigg added a comment - a.) and c.) is no solution b.) "backup this only for admins" and converting users (if they dont exist) to manual one, would be a solution until we may find a better way In this case, admins may decide, we will restore, and maybe we will break some users, but this may be changed easily later... Hope you can do b.) Thanks eloy
Hide
Eloy Lafuente (stronk7) added a comment -

What about this approach (following b):

1) No changes in backup.
2) At restore:

  • 2a) If the destination site is the same than the original one, allow to restore normally to teachers. Users exist there, so no problem at all, no matter if there are mnet hosts or no.
  • 2b) If destination site is different and there are mnet hosts: forbid completely to teachers to restore with user info, only admins will be able to restore with user info, converting users to "manual" auth if needed.

I think this approach is a mix of a & b, where teachers can restore in same site and admins can in any site... what do you think?

Show
Eloy Lafuente (stronk7) added a comment - What about this approach (following b): 1) No changes in backup. 2) At restore:
  • 2a) If the destination site is the same than the original one, allow to restore normally to teachers. Users exist there, so no problem at all, no matter if there are mnet hosts or no.
  • 2b) If destination site is different and there are mnet hosts: forbid completely to teachers to restore with user info, only admins will be able to restore with user info, converting users to "manual" auth if needed.
I think this approach is a mix of a & b, where teachers can restore in same site and admins can in any site... what do you think?
Hide
Martin Dougiamas added a comment -

That sounds like a good solution to me!

Show
Martin Dougiamas added a comment - That sounds like a good solution to me!
Hide
Peter Sereinigg added a comment -

That sounds like a good solution to me too!

Show
Peter Sereinigg added a comment - That sounds like a good solution to me too!
Hide
Eloy Lafuente (stronk7) added a comment -

First part implemented:

  • Prevent teachers to execute restores of courses having mnet users & coming from other site. Allow it to admins.

Incoming:

  • On restore, if mnet host (by URL) is missing, switch authentication method to internal, informing about that.

ciao

Show
Eloy Lafuente (stronk7) added a comment - First part implemented:
  • Prevent teachers to execute restores of courses having mnet users & coming from other site. Allow it to admins.
Incoming:
  • On restore, if mnet host (by URL) is missing, switch authentication method to internal, informing about that.
ciao
Hide
Eloy Lafuente (stronk7) added a comment -

Second part implemented. Now users being restored and having one not-configured mnet host are automatically switched to local users (manual or email auth, depending of site settings).

I've attached two screenshoots about the preliminary message showed to admins (check.png) and the execution of the restore, displaying details about the switches performed (restore.png).

Seems to be working here. Please test! Changes are already in CVS (19_STABLE and HEAD).

Ciao

Show
Eloy Lafuente (stronk7) added a comment - Second part implemented. Now users being restored and having one not-configured mnet host are automatically switched to local users (manual or email auth, depending of site settings). I've attached two screenshoots about the preliminary message showed to admins (check.png) and the execution of the restore, displaying details about the switches performed (restore.png). Seems to be working here. Please test! Changes are already in CVS (19_STABLE and HEAD). Ciao
Hide
Eloy Lafuente (stronk7) added a comment -

Resolving as fixed. Feel free to reopen if necessary. Ciao

Show
Eloy Lafuente (stronk7) added a comment - Resolving as fixed. Feel free to reopen if necessary. Ciao
Hide
Petr Škoda (skodak) added a comment -

reviewed, closing, thanks

Show
Petr Škoda (skodak) added a comment - reviewed, closing, thanks
Hide
Eloy Lafuente (stronk7) added a comment -

I've introduced one minor improvement here so, at the end of the mnethostid calculation... if any user ends with mnethostid = local host and auth = mnet, his auth is switched to manual/email, informing admins, that are the only ones able to restore that type of course (as implemented in this bug some months ago).

Ciao

Show
Eloy Lafuente (stronk7) added a comment - I've introduced one minor improvement here so, at the end of the mnethostid calculation... if any user ends with mnethostid = local host and auth = mnet, his auth is switched to manual/email, informing admins, that are the only ones able to restore that type of course (as implemented in this bug some months ago). Ciao

Dates

  • Created:
    Updated:
    Resolved: