Details
Sub-task
Description
If you have used mnet and then disable it completely you can potentially have remote users kicking about in your system (with no provision to remove them of course). Backup seems to include these users regardless of the "master" setting for mnet. This can render your backup file useless as you won't be able to restore it again (see http://moodle.org/mod/forum/discuss.php?d=79460). You should be able to turn of networking and not have it lingering on.
Issue Links
| This issue will be resolved by: | ||||
| MDL-11145 | Deleting a mnet peer leaves its users in the database - no way to delete them all afterwards |
|
|
|
| This issue has a non-specific relationship to: | ||||
| MDL-16879 | When creating backup files, users not included even when selected |
|
|
|
| This issue has been marked as being related by: | ||||
| MDL-17009 | Backup will not work, if you "mix" Servers with and woithout MNET functionality |
|
|
|
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
delaying a bit, sorry
workaround is to delete remote users if mnet is not going to be used anymore; unfortunately deleting users is not an option if if ever intend to turn it on again, because the users would be duplicated 
could you please describe the exact steps how to reproduce and exact error messages? I do not have mnet working in my test server yet and need to work on other issues this week
could you please describe the exact steps how to reproduce and exact error messages? I do not have mnet working in my test server yet and need to work on other issues this week Well,
I'd say that partially. This problem has strong relations with both MDL-17009 and MDL-16879.
Right now, if one backup contains mnet users... it only can be restored by admins (in other servers), while teachers are able to restore it in same server. Also, while restoring, if it's found that the mnethost for one user doesn't exist in target server any more... then that user auth is switched to manual, and one message about the switch is shown in the restore process, for easier tracking of that user.
All this said, exclusively, for 1.9.x, not for the version where the original bug was reported (1.8.x series). So I'd consider that, in 1.9.x, restore of mnet users is being done more or less properly (it continues existing some combinations that could lead to some users duplicated, caused by problems is origin server). Hopefully those inconsistencies will be fixed by MDL-16879 soon.
So I'd consider this fixed... closing now. Feel free to reopen if necessary.
Ciao 
Edited: I was slept when wrote that, grrr. Fixes.
Edited: I was slept when wrote that, grrr. Fixes. Hi,
I wasn't really happy with those "combinations causing duplicates" in my previous comment, so I've reworked the restore of mnet users again. Here it's the summary of current behaviour:
1) If the target site is a different one (restore with mnet info only allowed to admins), then perform the mnet_check, ending with auth => manual/email and mnethostid => localhost if no match is found (informing users).
2) If the target site is the same and the user being restored doesn't exist (shouldn't really happen but in sites being rebuilt from problems/scratch), also perform the mnet_check with same effects than in 1)
3) If the target site is the same, but the user already exists, then DON'T perform any change in user auth/mnethost. If it's incorrect due to some other bug in mnet stuff (like MDL-16879), it's a server problem and restore won't try to "fix" that anymore.
I think that, with this approach, we are in the safe side, preventing modifications of user data in same server, while also do the best when creating users.
Ciao
Interestingly if you update any users who have an mnethostid<>1 (ie, remote host) to 'deleted=1' then manual backup works fine. However, automatic "nightly" backups still fail.