Most common cause for auth/ldap/cli/sync_users.php failing is extended or dodgy characters in the ldap account details. Try setting $CFG->extendedusernamechars = true; in config.php and see what happens.
Also check out the lukas.spacy account for anything odd like white space in their name. Things like that. Check the account directly after as well as sometimes it can give an error and those details but the actual problem is with fetching the next one.
thanks for the reply.
I tried the following steps to get more informations about the problem:
I don´t understand, why the script aborts with the same error, although the user doesnt exists anymore...
Here is the error code:
---------------------------------------------------------------
root@vmoodlet01:/home/administrator# /usr/bin/php /srv/www/auth/ldap/cli/sync_users.php >> /home/administrator/log_sync_user_15_06_2016_1.txt &
[1] 53652
root@vmoodlet01:/home/administrator# PHP Warning: Module 'mysqli' already loaded in Unknown on line 0
PHP Notice: Undefined property: stdClass::$dataroot in /srv/www/config.php on line 66
[AUTH LDAP] The users sync cron has been deprecated. Please use the scheduled task instead.
Default exception handler: Fehler beim Schreiben der Datenbank Debug: The statement has been terminated.
INSERT INTO #m20_tmp_extuser (username,mnethostid) VALUES (?,?)
[array (
0 => 'lukas.spacek',
1 => '1',
)]
Error code: dmlwriteexception
* line 446 of /lib/dml/moodle_database.php: dml_write_exception thrown
* line 282 of /lib/dml/mssql_native_moodle_database.php: call to moodle_database->query_end()
* line 926 of /lib/dml/mssql_native_moodle_database.php: call to mssql_native_moodle_database->query_end()
* line 1060 of /auth/ldap/auth.php: call to mssql_native_moodle_database->insert_record_raw()
* line 749 of /auth/ldap/auth.php: call to auth_plugin_ldap->ldap_bulk_insert()
* line 70 of /auth/ldap/cli/sync_users.php: call to auth_plugin_ldap->sync_users()
Potential coding error - existing temptables found when disposing database. Must be dropped!
^C
[1]+ Exit 1 /usr/bin/php /srv/www/auth/ldap/cli/sync_users.php >> /home/administrator/log_sync_user_15_06_2016_1.txt
root@vmoodlet01:/home/administrator#
root@vmoodlet01:/home/administrator# /usr/bin/php /srv/www/auth/ldap/cli/sync_users.php >> /home/administrator/log_sync_user_15_06_2016_1.txt &
[1] 53652
root@vmoodlet01:/home/administrator# PHP Warning: Module 'mysqli' already loaded in Unknown on line 0
PHP Notice: Undefined property: stdClass::$dataroot in /srv/www/config.php on line 66
[AUTH LDAP] The users sync cron has been deprecated. Please use the scheduled task instead.
Default exception handler: Fehler beim Schreiben der Datenbank Debug: The statement has been terminated.
INSERT INTO #m20_tmp_extuser (username,mnethostid) VALUES (?,?)
[array (
0 => 'lukas.spacek',
1 => '1',
)]
Error code: dmlwriteexception
* line 446 of /lib/dml/moodle_database.php: dml_write_exception thrown
* line 282 of /lib/dml/mssql_native_moodle_database.php: call to moodle_database->query_end()
* line 926 of /lib/dml/mssql_native_moodle_database.php: call to mssql_native_moodle_database->query_end()
* line 1060 of /auth/ldap/auth.php: call to mssql_native_moodle_database->insert_record_raw()
* line 749 of /auth/ldap/auth.php: call to auth_plugin_ldap->ldap_bulk_insert()
* line 70 of /auth/ldap/cli/sync_users.php: call to auth_plugin_ldap->sync_users()
Potential coding error - existing temptables found when disposing database. Must be dropped!
^C
[1]+ Exit 1 /usr/bin/php /srv/www/auth/ldap/cli/sync_users.php >> /home/administrator/log_sync_user_15_06_2016_1.txt
root@vmoodlet01:/home/administrator#
---------------------------------------------------------------
What else can i try?
Regards,
Robin
The error is coming from the account in AD, not the account in Moodle so deleting the Moodle account will not do anything. You need to fix the issue in AD. In addition to the previous suggestions, you might also check that the display name is filled in AD - I find that is often an issue.
Robin,
I suspect you are facing multiple issues.
Your script is throwing a PHP notice:
PHP Notice: Undefined property: stdClass::$dataroot in /srv/www/config.php on line 66That makes me suspect someone has been fiddling with your config.php and somehow corrupted the $CFG variable
Also, the part of your error message that says:
INSERT INTO #m20_tmp_extuser (username,mnethostid) VALUES (?,?)indicates that $CFG->prefix has been set to '#m20_'. That's a very unusual value to set that variable to. In fact, my guess is that someone has tried to comment something out in config.php and has placed a "#" in front of 'm20_' which is probably what $CFG->prefix is intended to be set to.
In short, I'll suggest you carefully examine your config.php and make sure there are no spurious characters.
Hi Olumuyiwa,
the config.php should be okay @line 66:
Line 65: $CFG->lock_factory = "\\core\\lock\\file_lock_factory";
Line 66: $CFG->lock_file_root = $CFG->dataroot . '/lock';
These parameters do not influence the sync-script i think.
The prefix ist 'm20_' without the '#'. The '#' only marks m20_tmp_extuser as teporary table.
I could identify some more AD-accounst which cause the error.
I added screenshots of their AD-atributes, perhaps u can see the problem there.
-Robin
You are correct in saying that the variables defined in lines 65 and 66 of config.php do not affect the sync script. However the error message regarding a variable that the script expects to have been defined earlier in config.php indicates that there is something wrong with the config.php, possibly someone modifying it and commenting out the definition of that variable.
Also, there is nowhere in the auth/ldap/auth.php where a '#' is prepended to the table name prefix for the purposes of indicating that it is a temporary table. And the script shouldn't have to since it is quite capable of knowing the name of a table it has created itself.
As I said, my suspicion is that the '#' has been put into config.php - possibly by someone trying to troubleshoot something.
In fact, I would go as far as guessing that your auth/ldap/cli/sync_users.php might have been modified and is now pointing to a config.php that has itself been modified.
Do you know whether someone has been poking around in your Moodle source files?
This user-account seems to work. The sync-script doesn´t cause an error:
But i don´t see any big difference to the 2 other ones that cause the error...
Check that there are no random spaces in their name or email address. I notice that these two do not have Attribute2 which appears to be a backup email - is this perhaps a mapped field in your ldap setting?
Also, check to see if they already have an account in Moodle. If so, is it set to LDAP? Is it suspended?
and as i said orginally have you set $CFG->extendedusernamechars = true; ?
Yes, i added $CFG->extendedusernamechars = true; to my config.php.
Hi,
I have a similar error message when running
php sync_users.php from /home/relax/htdocs/moodle/auth/ldap/cli
similar I get the following error message:
PHP Warning: PHP Startup: Invalid library (maybe not a PHP library) 'opcache.so' in Unknown on line 0
Verbindung zum LDAP-Server aufbauen...Temporäre Tabelle
tmp_extuser erstellen
((Making connection to LDAP Server... Creating temporary table tmp_extuser))
PHP Warning: ldap_list(): Search: Critical extension is unavailable in /home/relax/htdocs/moodle/auth/ldap/auth.php on line 729
Kein Nutzerkonto über LDAP einlesbar! Fehler?Potential coding error - existing temptables found when disposing database. Must be dropped!
((No user account readable through LDAP. Error))
The following changes didn't help:
I am running Moodle 2.9.4 on a Debian 7 machine.
I don't have experience with sync_users, but can tell you for nothing that changing the user attribute field to nothing is a gamble on the surface.
Doing that makes moodle assume the username in a network profile is in attribute 'cn' - and if that is not the case in your system, that will just make things worse.
In AD for example, ObjectGUID is a weird concoction (that you wouldn't expect anyone to remember) and sAMAccountName is the proper 'username' field.
That was only a test. User attribute is again set to "Uid".
Thanks
What version of PHP are you using? Is LDAP login working? Is this a MSAD ldap server?
Hi,
We have php 5.4.45.
I was wondering if php memory limit could be a cause. Its currently set to 512MB.
I have around 10,000 users. Don't know if that's a problem.
The error message mentions a tmp_extuser table. Perhaps this is part of the problem.
I have seen that error many times - normally though it stalls out after a specific user and it is due to something funky like a space in their username.
Can an LDAP user login?
LDAP users can log in. User are authenticated against our LDAP server.
When I look at that area in the ldap file (line 729), part of that section actually references cookies. I wonder if your ldap server is blocking that...hopefully Inaki can help here - I am more of a MSAD person and I have never seen this specific error before.
Some more information to my problem. With -F I get more info to the error.
php -F sync_users.php
--Returns
PHP Warning: PHP Startup: Invalid library (maybe not a PHP library) 'opcache.so' in Unknown on line 0
Fatal error: require_once(): Failed opening required '/course/lib.php' (include_path='/home/relax/htdocs/moodle/lib/zend:/home/relax/htdocs/moodle/lib/pear:.:/usr/share/php:/usr/share/pear') in /home/relax/htdocs/moodle/auth/ldap/cli/sync_users.php on line 52
After that I added
$CFG->dirroot = '/home/relax/htdocs/moodle';
to config.php
After that the error path error seems to be gone, but then I get
[AUTH LDAP] Plugin not enabled!
You could check that:
Something else you may want to look at is the protocol version supported by your LDAP server
You may need to talk to your LDAP administrator to get answers to those questions.
Thanks Olumuyiwa
paged results is supported as far as I know
I tried different page size settings in the LDAP Settings in Moodle. I tried 20, 250 and 10000 without any success.
The LDAP Version is
Sun-Directory-Server/11.1.1.7.2 B2014.1030.2115 64-bit
What did you mean with protocol version? Which protocol and where can we find that?
Above you were talking about issues regarding the config.php. I wanted to show you a (cleaned up) copy of my config.php. Perhaps this helps. I am not using most of the above-mentioned variables.
<?php // Moodle configuration file
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mysqli';
$CFG->dblibrary = 'native';
$CFG->dbhost = 'xxxxxxxx';
$CFG->dbname = 'xxxxxxxx';
$CFG->dbuser = 'xxxxxxx';
$CFG->dbpass = 'xxxxxxx';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => 0,
'dbsocket' => 0,
);
$CFG->wwwroot = 'xxxxxxx';
$CFG->dataroot = 'xxxxx';
$CFG->admin = 'xxxxx';
$CFG->defaultblocks_override = 'activity_modules,news_items:';
$CFG->directorypermissions = 0777;
$CFG->passwordsaltmain = 'xxxxxxxxx';
require_once(dirname(__FILE__) . '/lib/setup.php');
// There is no php closing tag in this file,
// it is intentional because it prevents trailing whitespace problems!
Your config.php looks OK.
I'm fairly sure that the issue you're having is different from the one originally reported.
By "protocol version" I mean the setting in your LDAP settings page that is labelled "Version", located just beneath the "Host URL" setting.
The reason I mention that (as well as page size) is that the LDAP sync script uses that setting to determine whether or not your LDAP server supports paging (RFC-2696 - https://www.ietf.org/rfc/rfc2696.txt), and if it does, it asks for the results of queries to be sent in page sized chunks.
If the server does not support paging, then the number of entries returned is limited to a maximum imposed by the LDAP server. This means you may get a smaller number of users than you actually have in your Moodle database.
I did a quick search on the capabilities supported by your LDAP server, and it appears that it does not in fact support RFC-2696: http://docs.oracle.com/cd/E29127_01/doc.111170/e28968/supported-standards-rfcs.htm.
To get around the problem you're having, you could set the "version" to "2". But bear in mind that your LDAP server could then send back fewer than the 10,000 users that you have in your Moodle database. You could probably fix that by convincing your LDAP administrator to increase the size limit to something over 10,000.
Note, this issue has been reported as a bug - https://tracker.moodle.org/browse/MDL-50625
Oh and its not a MSAD ldap server just an lpad server.
Could it be that you have this set up in the task server settings and then are trying to run from CLI? Perhaps it is already running?
I am running it from the command line.
On my test server I am pretty sure its not running in cron.
Right now I can't find the crontab or cron on my debian server that is responsible for this. Hope to ask my unix guy on Monday.
Would it make a difference if it is running through cron and in addition on the command line?
Just noticed I am even getting this error:
php schedule_task.php
PHP Warning: PHP Startup: Invalid library (maybe not a PHP library) 'opcache.so' in Unknown on line 0
We checked that opchache.so is installed but seems to be a problem.
Not sure about the cache message but some weird stuff interferes with that LDAP script sometime. I had a course format that broke it once! You might check your opcache settings in php.ini and ensure that they match the recommended settings for moodle (found in docs).
On debian, you should be able to crontab -u www-data e to see your cron script for moodle. However, if you are running a new version of moodle, go to SiteAdmin/Server/Scheduled Tasks and see if it is set up there.
Turn debugging on in your Moodle site and then run it again. Perhaps that will bring something else up..
As I explained in my earlier comment - https://moodle.org/mod/forum/discuss.php?d=333293#p1356300 - the issue seems to be due to your LDAP server not supporting paged results. I linked a few documents, in particular a bug related to the issue that has been reported in Moodle Tracker.
Try setting "Version" to "2" in your LDAP settings and see what happens. Note that it's likely that you won't be able to sync all your 10,000 users when you do that and you may have to request your LDAP administrator to increase the page size to a number that works for you.
Bingo. That was it.
I changed the Version to 2 under LDAP Server Settings.
After that the sync_user.php script ran and started suspending old users.
The script stopped around a third of the way through.
I will talk to my admin about raising the page size to 10,000.
I saw the moodle tracker issue and will vote for it. Thanks.
So I guess this issue is solved if I keep the version at 2 and have the page size increased. Hopefully the bug issue will be dealt with.
Thanks a lot.
"So I guess this issue is solved if I keep the version at 2 and have the page size increased"
You could also rate my comment "Useful"
Sorry, but I do have another question.
The sync_user.php script is working fine now after setting LDAP version to 2 (didn't need to change LDAP page size settings).
After the script ran the non-LDAP users were correctly "suspended" in Moodle, but
the script added LDAP users to Moodle, LDAP users wo previously didn't exist in Moodle.
Previously on my system, without the script, new users were added into Moodle only during the authenticatication during their first login in Moodle.
I am not sure if it is ok to have this script adding users to Moodle. There are a couple thousand LDAP users who don't need to be in Moodle.
Is there a way of preventing the script from adding users to Moodle?
I have a security group set up in Active Directory for my Moodle Users. I then filter down to the group in the LDAP settings by adding the following to the Object Class field. This way only those users assigned to the group get synced.
(|(&(objectClass=user)(!(objectClass=computer))(memberOf=cn=MoodleUser,ou=people ,dc=mydomain,dc=com)))
Thanks Emma.
I don't quite understand that.
I would prefer the sync_user.php script not adding any users to Moodle, just marking the old (non-LDAP) users as "deleted".
In LDAP we have, for example, users without an Email addresses. This could cause problems in Moodle.
Creating some sort of group is the only way to do this. You need to basically filter what users should be given access to Moodle. Then any user that is not in the group will be removed as you specify in the LDAP settings. Moodle needs a way to know which users are meant to be added to Moodle.
FYI - users without an email will just be prompted to add one when they first log in. I actually do this purposely so that users enter their current email when first logging in.