Produits Entr'ouvert » Authentic 2

Je ne sais pas ce que contient exactement l'exception on peut tenter de la passer dans ligne de log aussi ("%s" % e) (il faudrait tester ça sur une erreur SSL voir ce que ça donne, suffit de faire un faux endpoint ssl avec openssl s_server le truc n'ira pas plus loin que le handshake SSL).

Benjamin Dauvergne a écrit :

Je ne sais pas ce que contient exactement l'exception on peut tenter de la passer dans ligne de log aussi ("%s" % e) (il faudrait tester ça sur une erreur SSL voir ce que ça donne, suffit de faire un faux endpoint ssl avec openssl s_server le truc n'ira pas plus loin que le handshake SSL).

Ok pour logguer l’exception, mais pour reproduire je pensais plutôt instancier un serveur ldap avec un mauvais certif. Slapd ne me laisse pas faire ça :)
L’idée du faux endpoint tls ne m’inspire pas trop : on voudrait un vrai échec de handshake, pas besoin de mocker au niveau tls dans ce cas.

Je vais creuser voir si on peut reproduire le cas du serveur ldap qui présente un mauvais certificat comme dans #56661.

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Je ne sais pas ce que contient exactement l'exception on peut tenter de la passer dans ligne de log aussi ("%s" % e) (il faudrait tester ça sur une erreur SSL voir ce que ça donne, suffit de faire un faux endpoint ssl avec openssl s_server le truc n'ira pas plus loin que le handshake SSL).

Ok pour logguer l’exception, mais pour reproduire je pensais plutôt instancier un serveur ldap avec un mauvais certif. Slapd ne me laisse pas faire ça :)
L’idée du faux endpoint tls ne m’inspire pas trop : on voudrait un vrai échec de handshake, pas besoin de mocker au niveau tls dans ce cas.

Ben si justement, je ne comprends pas à quoi tu penses, pour avoir un handshake il faut une terminaison TLS; bon de fait j'ai vérifié avec s_server et python-ldap ça renvoie juste SERVER_IS_DOWN, pas moyen d'avoir mieux de la part de libldap (ou alors vaguement en activant le debug maximum avec ldapsearch mais va savoir comment faire ça en python et ou ça va partir). Si on veut faire mieux il faut tenter une connexion via socket sur le même port en cas d'erreur, il n'y a pas vraiment d'autre moyen, ou alors on en reste à server is down parce qu'on ne sait pas faire mieux et c'est tant pis.

Je vais creuser voir si on peut reproduire le cas du serveur ldap qui présente un mauvais certificat comme dans #56661.

Je sais déjà que ça ne donnera rien de mieux qu'actuellement.

Benjamin Dauvergne a écrit :

Ben si justement, je ne comprends pas à quoi tu penses, pour avoir un handshake il faut une terminaison TLS; bon de fait j'ai vérifié avec s_server et python-ldap ça renvoie juste SERVER_IS_DOWN, pas moyen d'avoir mieux de la part de libldap (ou alors vaguement en activant le debug maximum avec ldapsearch mais va savoir comment faire ça en python et ou ça va partir). Si on veut faire mieux il faut tenter une connexion via socket sur le même port en cas d'erreur, il n'y a pas vraiment d'autre moyen, ou alors on en reste à server is down parce qu'on ne sait pas faire mieux et c'est tant pis.

Le ticket voulait simplement ne pas logguer “server is down” alors que ce n’est pas forcément le cas. Mais c’est ce que la bibliothèque ldap utilisée nous remonte.
Je vais voir ce que donne la piste de la connexion via socket sur le même port. Iirc on fait quelque comme ça dans ldaptools lorsque la connexion par url ne fonctionne pas.

Comme je suis l'inspirateur du ticket je précise que mon idée est juste d'arrêter d'écrire "server is down" alors que c'est faux dans 99,99% des cas. C'est toujours un problème réseau (inclus les soucis TLS). C'est pour éviter de se voir répondre trop vite dans un ticket "votre serveur est-il en panne ?" (vu y'a quelque jour je ne sais plus où, alors que c'était un pépin tls).

Thomas Noël a écrit :

Comme je suis l'inspirateur du ticket je précise que mon idée est juste d'arrêter d'écrire "server is down" alors que c'est faux dans 99,99% des cas. C'est toujours un problème réseau (inclus les soucis TLS). C'est pour éviter de se voir répondre trop vite dans un ticket "votre serveur est-il en panne ?" (vu y'a quelque jour je ne sais plus où, alors que c'était un pépin tls).

Pour moi si t'as plus de réseau ou que ton certificat TLS est mauvais, ton serveur il est en panne vu d'ici. Alors si vous voulez dire "il y a un problème dans la liaison avec le serveur LDAP quelque part entre lui et nous" si vous voulez; mais quand je lis server is down, ça veut dire la même chose. Lister les 100 cas d'erreur possible ne changera pas le fait qu'il faut chercher le bon pour pouvoir réparer, et donc on va faire ldapsearch -H ldaps://trucmuche -d 255 -v -b '' * et espérer que le mode debug de libldap nous sorte quelque chose; ce qu'on faisait déjà.

Donc moi si ce n'est pas pour donner une indication plus précise du souci qui permet de débugger en 2s, je ne vois pas bien l'intérêt de changer quelque chose, parce que je ne vois pas à qui ça va vraiment faire gagner du temps. Le fait de retester la connection avec un coup de :

# https://docs.python.org/3/library/ssl.html \o/
with socket.create_connection((hostname, bind_port or 636), timeout=2) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        pass

Benjamin Dauvergne a écrit :

Donc moi si ce n'est pas pour donner une indication plus précise du souci qui permet de débugger en 2s, je ne vois pas bien l'intérêt de changer quelque chose, parce que je ne vois pas à qui ça va vraiment faire gagner du temps. Le fait de retester la connection avec un coup de :
[...]
apporterait ces informations.

Très bien, faisons comme ça. J’ai commencé à écrire quelque chose qui va en ce sens. Commit wip poussé dans la branche. Je vais regarder comment tester, avec les indications que tu m’as précédemment données.

Benjamin Dauvergne a écrit :

J'aurai bien vu un test de résolution DNS.

C’est à dire ? Mocker une réponse DNS qui renvoie une mauvaise adresse ?

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

J'aurai bien vu un test de résolution DNS.

C’est à dire ? Mocker une réponse DNS qui renvoie une mauvaise adresse ?

Non tu mets un hostname qui n'existe pas genre 'jenexistepas.example.com'.

(J’attends que Jenkins voie vert avec la branche rebasée, et je pousse ensuite.)