[Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Denis Guiziou,
Nombre de réponses : 12

Bonjour Patrick,

Finalement en inspectant mon log sync_users, j'ai également plusieurs username vides (une bonne cinquantaine).

J'ai aussi les utilisateurs windows style "utilisateurs du bureau à distance" ou "administrateur" mais pour ne pas polluer les utilisateurs Moodle je les rejette lors de la synchro. J'ai donc dû modifier les scripts php pour cela.

Je crois avoir aussi eu un problème avec SSO car lors de la synchro users, il y a une fonction clean_field qui supprime les accents et autres caractères de username ce qui fait qu'après le nom AD n'étant plus en adéquation avec celui de Moodle.

Cordialement

Denis



Moyenne des évaluations  -
En réponse à Denis Guiziou

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Patrick Lemaire,
Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Denis, et la communauté,

Intéressant de constater que tu rencontres aussi des insertions d'utilisateurs sans login... Je ne suis donc pas seul langue tirée

Pour ma part, afin de ne pas bloquer la synchro, j'en suis arrivé à bypasser la phase 3 du script, celle qui met à jour les données des comptes. En effet, j'ai paramétré l'authentification CAS (qui s'appuie sur LDAP) pour que les champs "nom", "prénom" et "courriel" notamment soient, à chaque connexion, synchronisés. Or, il s'avère que dans le script de synchro, qui peut se découper en 4 phases :

  • la première (lignes 754 à 806 du fichier auth/ldap/auth.php de mon Moodle 3.1.3) supprime ou suspend, selon la configuration choisie, les comptes qui n'apparaissent plus dans LDAP mais qui sont toujours dans Moodle ;
  • la seconde (lignes 808 à 833) réactive, selon la configuration, les comptes précédemment suspendus s'ils  apparaissent à nouveau dans LDAP ;
  • la troisième (lignes 836 à 902), selon la configuration, écrase les champs synchronisés en prenant les valeurs LDAP comme références ;
  • et enfin la quatrième (lignes 904 à 968) ajoute les comptes nouveaux qui sont présents dans LDAP mais pas encore dans Moodle.

Il est indiqué dans le code que la phase 3 est consommatrice de ressource mais par contre, il n'est pas possible de désactiver cette phase alors que, pour moi, les champs sont verrouillés et ne peuvent être modifiés. A priori, je n'ai aucun raison de penser que ces valeurs pourraient être modifiées après leur création, la synchro est donc superflue. J'ai donc commenté ces lignes... Et ça fonctionne bien. Les 3 autres phases se déroulent sans accro. Ma base d'usagers est donc totalement synchronisée.

J'ai tenté de comprendre pourquoi la quatrième phase échoue. J'ai bien identifié la tentative d'insertion d'un usager avec un username vide, que la base de données interdit, mettant le script en erreur. Mais je n'arrive pas à y remédier ni à comprendre pourquoi ces données sont retournées vides.

Je suis toujours preneur d'informations ou de constats qui me permettraient d'avancer. En attendant, je vais patcher les futures mises à jour.

A suivre...
Patrick

Moyenne des évaluations  -
En réponse à Patrick Lemaire

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Denis Guiziou,

Bonjour Patrick,

Suite à ton mail et ayant eu moi-même ce problème (utilisateur vide), j'avais réussi à résoudre ceci en testant si $username != ''. Si c'est bien le cas je fais la création sinon je ne fais rien.

Je viens de passer l'après-midi à essayer de comprendre pourquoi $username est parfois vide, et j'ai au moins trouvé une cause : dans AD j'ai des utilisateurs avec un espace en trop à la fin du nom (exemple : "Dupont ").

Au niveau de la procédure get_userinfo de la page php auth/ldap/auth.php, s'il y a un espace en fin de nom, il semble sortir de la procédure :

    function get_userinfo($username) {
 >> j'ai fait un debug de $username ici : OK
        $extusername = core_text::convert($username, 'utf-8', $this->config->ldapencoding);

 >> j'ai fait un debug de $extusername ici : OK

        $ldapconnection = $this->ldap_connect();
        if(!($user_dn = $this->ldap_find_userdn($ldapconnection, $extusername))) {    >> sort ici  quand nom avec espace
            $this->ldap_close();
            return false;
        }

 >> j'ai fait un debug de $extusername ici : on ne passe pas ici quand le nom contient un espace.

Apparemment j'ai pas mal d'utilisateurs comme çà dans AD, un collègue m'a dit que çà provient probablement d'une copie d'un compte AD sur un autre.

En corrigeant l'utilisateur dans AD au niveau de plusieurs champs , puis en repassant le script de synchro, l'utilisateur a correctement été détecté et a été ajouté dans Moodle.

Pour plus de détails :

Dans le script auth/ldap/auth.ldap vers la ligne 950, j'ai :

            foreach ($add_users as $user) {

>> ici le username est en core OK

                $user = $this->get_userinfo_asobj($user->username);   >> get_userinfo_asobj appelle get_userinfo qui ne trouve pas l' utilisateur dans AD => $username est vide

                // Prep a few params
                $user->modified   = time();
                $user->confirmed  = 1;
                $user->auth       = $this->authtype;
                $user->mnethostid = $CFG->mnet_localhost_id;
                // get_userinfo_asobj() might have replaced $user->username with the value
                // from the LDAP server (which can be mixed-case). Make sure it's lowercase

Je pense que le problème doit se situer par là.

Bon courage ...

Denis


Moyenne des évaluations Utile (1)
En réponse à Denis Guiziou

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Patrick Lemaire,
Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Denis,

Intéressant !!! pensif

Par contre, si ça vient de la fonction get_userinfo ou get_userinfo_asobj, pourquoi est-ce que cela fonctionnerait sur un de mes serveurs et pas un autre alors qu'ils interrogent tous deux le même annuaire LDAP à partir du même code ?? Et pourquoi quand je saute la phase 3, ça passe aussi ?!?

Mmmmm... Je suis également curieux de savoir combien d'administrateurs rencontre ce genre de problème. Visiblement, nous sommes... au moins deux langue tirée

Merci en tout cas !
A suivre...
Patrick

Moyenne des évaluations  -
En réponse à Patrick Lemaire

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Patrick,

De mon côté, je ne rencontre (a priori) pas de problème.

Mais il est vrai que depuis cette année, et l'utilisation de Moodle 3.1, j'ai délaissé l'appel direct du script de synchronisation CAS/LDAP via un cron dédié au profit de la tâche planifiée équivalente intégrée à Moodle.

Séverin

Moyenne des évaluations  -
En réponse à Patrick Lemaire

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Denis Guiziou,

Bonjour Patrick,

Déjà avec quel annuaire LDAP travailles-tu : Windows AD ? Au final j'ai fait un script vbscript qui m'a sorti la liste des utilisateurs AD pas corrects (avec un espace en début ou en fin de nom). 6 noms sont ressortis et on a pu corriger.

Me concernant, Je me demande si le problème ne vient pas du fichier : auth/ldap/auth.php, vers la ligne 750, il y a :

                        $value = ldap_get_values_len($ldapconnection, $entry, $this->config->user_attribute);
                        $value = core_text::convert($value[0], $this->config->ldapencoding, 'utf-8');

                        $value = trim($value);
                        $this->ldap_bulk_insert($value); 

Dans mon cas, dans AD, on a, admettons, "serge.dupont " (un espace en fin de nom). Le script vers la ligne 750, récupère les noms depuis AD mais comme il y a $value = trim($value), "serge.dupont " va devenir "serge.dupont" ensuite ldap_bulk_insert stocke "serge.dupont" dans une table xmldb temporaire tmp_extuser. 

Plus tard, vers la ligne 950      

// $add_users contient la liste des noms relus à partir de tmp_extuser

foreach ($add_users as $user) {
                 $user = $this->get_userinfo_asobj($user->username); 

                 // appel de la fonction get_userinfo_asobj qui exécute get_userinfo qui va renvoyer FALSE car get_userinfo va rechercher avec "serge.dupont" dans AD (et donc pas trouver le compte) au lieu de "serge.dupont " (avec un espace). Ensuite le script appelle user_create_user qui se plante car on doit avoir une valeur FALSE je pense, comme paramètre user.

A mon avis, le problème viendrait donc déjà de $value=trim($value);. A la rigueur sur un serveur Moodle de test, voir si en mettant en commentaire cette ligne et en repassant le script si çà va mieux ?

Concernant ton annuaire LDAP et le fait que çà marche dans un cas et pas dans l'autre, je ne saurais quoi te répondre. Ton annuaire LDAP est certainement répliqué sur plusieurs serveurs, peut-être qu'un serveur Moodle attaque un serveur LDAP et ton autre serveur Moodle se connecte à une copie du serveur LDAP où il y aurait des différences ?

Pour Sévérin, au final il me semble qu'en passant par le cron ou sync_task ce sont les mêmes modules php qui sont appelés (?) mais vu votre longue expérience de Moodle comparée à la mienne (2 mois), je ne m'avancerais pas plus dans mes élucubrations grand sourire

Denis



Moyenne des évaluations Utile (1)
En réponse à Denis Guiziou

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Nicolas Martignoni,
Avatar Développeurs Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour,

Si votre analyse est juste (et elle semble tout à fait correcte), je suggère d'ouvrir un bogue dans le tracker, qui demande que dans ce cas un avertissement ou une erreur avec un message adéquat soit retourné et que le compte utilisateur en question soit "sauté" pour éviter de bloquer le processus.

En effet, il me semble que le fait de supprimer les espaces n'est pas un bogue, car ces espaces en début et fin ne devraient pas être là, alors qu'en revanche, le fait que l'on ne sache pas ce qui ce passe et que ça bloque le processus est un bogue.

Pour référence : MDL-42993 (et son doublon MDL-44448).

Moyenne des évaluations Utile (2)
En réponse à Nicolas Martignoni

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Denis Guiziou,

Bonjour Nicolas,

Concernant les noms d'utilisateurs avec espace en début ou en fin çà n'est effectivement pas très normal d'avoir cela en amont (au niveau d'AD). Ces cas sont assez exceptionnels et on les a corrigés. Après j'espère que mon analyse est effectivement à peu près correcte vu que je ne maitrise pas très bien ce php "objet" et que je découvre depuis peu Moodle.

Pour le bogue tracker, je vais voir mais vu que l'on a corrigé les noms d'utilisateurs dans AD, cela me sera sans doute difficile de reproduire le problème. Mais je vais voir sourire

Cordialement

Denis



 

Moyenne des évaluations  -
En réponse à Denis Guiziou

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Denis Guiziou,

Bonjour Nicolas,

Bon j'ai essayé le bogue tracker, mais pas possible de CREER la demande. Il me demande à chaque fois si, auparavant, j'ai cherché dans les anciennes demandes pour voir s'il n'y avait pas un sujet similaire, chose que j'ai faite. Du coup je laisse tomber.

Effectivement j'ai aussi retrouvé le sujet :

MDL-42993
Username with spaces no longer valid for LDAP authenticated users

Cordialement

Denis




Moyenne des évaluations  -
En réponse à Denis Guiziou

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php - créer une demande dans le traqueur

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Denis,

Pour éviter le SPAM, la création d'une demande dans le traqueur n'est possible que pour les gens ayant déjà effectué quelque action, telle que voter pour (ou suivre) une demande (ouverte) du traqueur. Ceci est expliqué ici dans la documentation (en anglais) sourire

Tu sais ce qu'il te reste à faire clin d’œil

Séverin

PS : cette information me semblant importante, j'ai créé une discussion séparée pour rendre cette information plus visible.

Moyenne des évaluations  -
En réponse à Séverin Terrier

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php - créer une demande dans le traqueur

par Denis Guiziou,

Bonjour Séverin,

Merci c'est bon à savoir ! clin d’œil

Denis


Moyenne des évaluations  -
En réponse à Denis Guiziou

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Patrick Lemaire,
Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Denis, Séverin,

Mon établissement emploie un annuaire LDAP (OpenLDAP) avec une interconnexion Windows AD mais à ma connaissance, chez nous, c'est LDAP qui nourrit l'AD et non l'inverse.

Je trouve ton analyse poussée intéressante et, comme Nicolas, je pense que le signalement pourrait permettre à d'autres de s'inquiéter de ce sujet.

Pour en revenir à ta remarque, Séverin, j'ai arrêté d'utiliser les tâches planifiées concernant la synchro LDAP parce que je manquais de visibilité sur son exécution et surtout, je pense qu'elle échoue à cause d'une limite de mémoire allouée. Mais peut-être que je me trompe sur ce dernier point.

A bientôt,
Patrick

Moyenne des évaluations  -
En réponse à Patrick Lemaire

Re: [Moodle 3.1] Pb "duplicate key" avec /auth/cas/cli/sync_users.php

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Patrick,

Effectivement, c'était bien pour avoir des "logs" séparés, plus faciles à vérifier, que j'utilisais jusque là des cron spécifiques pour la synchronisation des comptes LDAP liés à l'authentification CAS.

Mais rien ne t'empêches, si tu enregistres les sorties d'exécution des cron, de manière datée, d'utiliser une ligne (de commande, sous unix) telle que :

grep -c 'CAS' /chemin/vers/log/cron.2017-0* | grep -v ".txt:0"

ou (il faut doubler les \) :

grep -c 'auth_cas\\task\\sync_task' /chemin/vers/log/cron.2017-0* | grep -v ".txt:0"
Cela permet de connaitre le nombre de lignes liées à la synchronisation des comptes CAS. Il devrait y avoir 2 occurrences à chaque fois (début et fin d'exécution de la tâche du cron concerné). Je suppose que si ce n'est pas le cas, c'est signe d'un problème...

Si tu enregistres les sorties de cron dans un fichier unique, il faudra(it) adapter les commandes.

Sinon, pour essayer de cibler les cron ayant généré des erreurs :

grep -c 'rror' /chemin/vers/log/cron.2017-0* | grep -v ".txt:0"

Il faudrait ensuite arriver à scripter l'analyse des différents logs pour envoyer automatiquement une alerte à l'administrateur. J'avais lancé une discussion à ce sujet.

Séverin

Moyenne des évaluations Utile (1)