Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 1.8, 1.8.1, 1.8.2
-
Fix Version/s: None
-
Component/s: General
-
Labels:None
-
Environment:Not relevant
-
Database:MySQL
-
Affected Branches:MOODLE_18_STABLE
Description
I will explain what just happened to our system:
We use only LDAP authentication.
We pull user details in from LDAP.
We have some scripts that update personal information from LDAP, thus keeping our Moodle records up to date.
One day there was a problem with our LDAP server and "blank" mail addresses were inserted into mdl_user.
Moodle then viewed these users as "incomplete"
As users were older than 7 days the cron job came and deleted all the users whose mail addresses had been blanked by the LDAP error.
Users then came to log on with LDAP details and new accounts were created.
Now we have many users with one deleted account and orphaned data, and one new account with no data!!!
Now I know about this I would be more careful about using LDAP to pull in updates for personal details, check for blanks etc, however, it would also make sense for Moodle to modify the cron scrip so that the "delete incomplete user" lines ONLY ran if email authentication / account creation was in use.
This code serves no purpose in a 100% LDAP environment, and, as I found to my cost is actually very dangerous!!
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
I had a similar case in Moodle v1.9.9.
It started, when I got the following error in cron.php:
Fatal exception from Lucene subsystem. Search engine may not have been updated.
exception 'Zend_Search_Lucene_Exception' with message 'chmod() [<a href='function.chmod'>function.chmod</a>]: Operation not permitted' in /htdocs/search/Zend/Search/Lucene/Storage/Directory/Filesystem.php:190
Stack trace:
#0 /htdocs/search/Zend/Search/Lucene/LockManager.php(85): Zend_Search_Lucene_Storage_Directory_Filesystem->createFile('read.lock.file')
#1 /htdocs/search/Zend/Search/Lucene.php(413): Zend_Search_Lucene_LockManager::obtainReadLock(Object(Zend_Search_Lucene_Storage_Directory_Filesystem))
#2 /htdocs/search/delete.php(49): Zend_Search_Lucene->__construct('/moodledata/moo...')
#3 /htdocs/search/cron_php5.php(16): require_once('/domains/moodle...')
#4 /htdocs/search/cron.php(25): include('/domains/moodle...')
#5 /htdocs/blocks/search/block_search.php(83): include('/domains/moodle...')
#6 /htdocs/admin/cron.php(148): block_search->cron()
#7 {main}
So I did what a post
http://tracker.moodle.org/browse/MDL-15824
suggested:
The quick way of solving this issue is as follows (for Moodle 1.9.6+ that is):
1. Go to line 421 in <MOODLE>/search/Zend/Search/Lucene.php and add this line:
// See tracker MDL-15824
$create = !$this->_directory->fileExists('segments');
2. Go to Moodledata folder and:
a) delete search folder if it exists
b) execute chmod -R 777 moodledata
c) execute chown -R <webserveruser>:<webservergroup> moodledata
d) recreate index from global search block <moodle>/search/indexer.php?areyousure=yes
After search index creation, I did run cron again, and I was surprized, that it deletes a lot user:
Checking user module for updates.
Delete: User: Test User (database id = 20420, index id = 11249, moodle instance id = 1670)
Is my problem related to this bug?
Was this user deletion affected users which had any subscription/participation in any courses?
Or just inactive users was deleted, which had no course subscriptions at all.
Thanks for your answer!