Produits Entr'ouvert » Authentic 2

Benjamin Dauvergne a écrit :

[...]

Bonjour,

Si il faut passer en python 3, existe-t-il une procédure ?
Sinon une correction pour python 2 conviendrait tout aussi bien.

Merci.

Vous êtes déjà en python3, la trace contient le nom python3.5.

Benjamin Dauvergne a écrit :

Vous êtes déjà en python3, la trace contient le nom python3.5.

Ah oui en effet

Je ne comprends pas car si je demande la version active sur l'OS je suis en python 2.7

python -V
Python 2.7.13

Authentic distribue donc ses propres librairies ?

Non c'est simplement que vous vous adressez au mauvais binaire, le binaire pour python3 s'appelle python3:

entrouvert-smihai@idp:~$ python3 -V
Python 3.5.3

Benjamin Dauvergne a écrit :

Non c'est simplement que vous vous adressez au mauvais binaire, le binaire pour python3 s'appelle python3:
[...]
Les deux versions peuvent êtres installées en parallèle.

Ah pardon pour mon ignorance.

Benjamin Dauvergne a écrit :

Limiter les caractères dans --source ne servait à rien.

Bonjour,

Est-ce que je dois appliquer ce patch en éditant directement le fichier suivant ?

/usr/lib/python3/dist-packages/authentic2/saml/management/commands/sync-metadata.py

PS : je ne trouve pas ce fichier dans mon environnement

tests/test_commands.py

Merci

Gautier Auburtin a écrit :

Est-ce que je dois appliquer ce patch en éditant directement le fichier suivant ?

Non j'ai déjà fait le nécessaire; je vous demandais justement de vérifier l'état de la fédération sur votre ticket, #48488.

Benjamin Dauvergne a écrit :

Gautier Auburtin a écrit :

Est-ce que je dois appliquer ce patch en éditant directement le fichier suivant ?

Non j'ai déjà fait le nécessaire; je vous demandais justement de vérifier l'état de la fédération sur votre ticket, #48488.

Ah. Merci beaucoup, je en connaissais pas la procédure.

Au fait je n'ai pas accès à https://dev.entrouvert.org/issues/48488

Et dans /usr/lib/python3/dist-packages/authentic2/saml/management/commands/sync-metadata.py

je n'ai pas vu la modification
mais j'ai vu que le fichier avait été modifié le 13/11 vers 15H30

Je pense que le moissonnage a été fait, puisque le SP que j'avais déclaré localement MYPSL - PROD a été MAJ par le SP de la fédération (ajout du tag 'renater')

Par contre on ne le voit pas dans l'historique du SP : est-ce normal ?

D'ailleurs, si je comprends bien, lorsque je déclare un SP localement (local-mypsl-prod) sans passer par la fédération Renater et que son entityId est déjà déclaré dans la fédération, il sera forcément MAJ (même s'il n'a pas le tag 'renater' initialement.

Voilà ce que dit la doc.
https://authentic2.readthedocs.io/en/stable/sync-metadata_script.html

source

    Used to tag all imported providers with a label. This option is used to metadata reloading and deletion in bulk.

    Reloading a metadata file, when a provider with same entity is found, it is updated. If a provider in the metadata file does not exist it is created. If a provider exists in the system but not in the metadata file, it is removed.

    For reloading, a source can only be associated with a unique metadata file. This is due to the fact that all providers of a source not found in the metadata file are removed.

On risque un pb de priorité entre

- un SP déclaré localement
- un SP déclaré sur renater
- un SP déclaré edugain

Si 1 SP est déclaré sur renater et edugain, qui gagne ? la dernière fédération moissonnée ?
On peut pas déclarer localement un SP sans qu'il soit déclaré sur renater
Mais si il est (mal?) déclaré sur Renater (ex. certificat), on est coincés il faudra toujours attendre que les métadonnées de renater soient mises à jour et cela prend parfois bcp de temps (min. 2H - parfois 72h le WE)

Gautier

Gautier Auburtin a écrit :

Benjamin Dauvergne a écrit :

Gautier Auburtin a écrit :

Est-ce que je dois appliquer ce patch en éditant directement le fichier suivant ?

Non j'ai déjà fait le nécessaire; je vous demandais justement de vérifier l'état de la fédération sur votre ticket, #48488.

Ah. Merci beaucoup, je en connaissais pas la procédure.

Au fait je n'ai pas accès à https://dev.entrouvert.org/issues/48488

Ok cela explique le problème, je vous ai donné l'accès.

Et dans /usr/lib/python3/dist-packages/authentic2/saml/management/commands/sync-metadata.py

je n'ai pas vu la modification

Elle est différente mais résout tout de même le problème, la mise à jour des paquets fera converger les choses.

Je pense que le moissonnage a été fait, puisque le SP que j'avais déclaré localement MYPSL - PROD a été MAJ par le SP de la fédération (ajout du tag 'renater')

Par contre on ne le voit pas dans l'historique du SP : est-ce normal ?

Oui l'historique n'est pas géré par cette commande.

D'ailleurs, si je comprends bien, lorsque je déclare un SP localement (local-mypsl-prod) sans passer par la fédération Renater et que son entityId est déjà déclaré dans la fédération, il sera forcément MAJ (même s'il n'a pas le tag 'renater' initialement.

Oui, un SP est unique via son entityID.

Voilà ce que dit la doc.
https://authentic2.readthedocs.io/en/stable/sync-metadata_script.html

Cette documentation n'est plus maintenu depuis longtemps, il se peut que les détails diffèrent.

On risque un pb de priorité entre

- un SP déclaré localement
- un SP déclaré sur renater
- un SP déclaré edugain

Si 1 SP est déclaré sur renater et edugain, qui gagne ? la dernière fédération moissonnée ?
On peut pas déclarer localement un SP sans qu'il soit déclaré sur renater
Mais si il est (mal?) déclaré sur Renater (ex. certificat), on est coincés il faudra toujours attendre que les métadonnées de renater soient mises à jour et cela prend parfois bcp de temps (min. 2H - parfois 72h le WE)

C'est possible mais nous ne gérons pas ce cas.

Benjamin Dauvergne a écrit :

[...]

Merci Benjamin pour toutes ces réponses.