Access Server ignore le script post_auth que vous avez modifié sur le disque

Un mac.py modifié qui ne change rien est le premier symptôme habituel. Le fichier sur le disque n’est pas ce qu’exécute Access Server ; le service d’authentification charge le script depuis la base de données de configuration du serveur, et c’est cette copie stockée qui décide d’une connexion. Tant que la valeur stockée n’est pas remplacée, chaque test prouve seulement que l’ancien script fonctionne encore.

Trois conditions décident du travail : si la valeur a été un jour déposée dans la base de configuration, si le service a reçu l’ordre de la recharger, et si le code que vous avez modifié s’exécute réellement à chaque connexion. Chacune a un symptôme différent, et corriger la mauvaise gaspille une fenêtre de maintenance.

Le fichier est une source, pas la copie en cours

Access Server conserve le script post-auth sous la clé auth.module.post_auth_script. Modifier le fichier met à jour votre copie de travail et rien d’autre. Le démon lit la valeur stockée, donc la modification reste invisible jusqu’à ce que vous supprimiez l’ancienne entrée et placiez le nouveau fichier à sa place. Cette valeur stockée est la seule copie que consulte le service d’authentification.

Lisez-la avant de la changer. Si elle correspond déjà au fichier que vous avez modifié, le problème n’est pas le stockage et passez à la question du périmètre. Si elle montre une version plus ancienne, la modification n’a jamais atteint le service.

./sacli -k auth.module.post_auth_script ConfigGet

Remplacez la copie stockée, puis appliquez-la

Supprimer avant d’écrire n’est pas décoratif. ConfigPut avec --value_file remplace la valeur en une étape, et ConfigDel d’abord rend impossible de laisser une entrée obsolète ou corrompue. Gardez une copie du script qui fonctionne hors du répertoire des scripts avant de commencer.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start applique la configuration modifiée aux services internes, et c’est ce qui fait prendre effet au nouveau script. Ce n’est pas la même chose que redémarrer la machine entière ou le démon, et cela ne doit pas être remplacé par un tel redémarrage sauf si votre modification l’exige.

Utilisez un chemin absolu pour le fichier de valeur et confirmez que root peut le lire. Un chemin qui se résout depuis votre shell mais pas depuis le compte de service produit une valeur stockée qui semble correcte dans ConfigGet et échoue à la première connexion. Vérifiez le résultat stocké une fois de plus après sacli start, pas avant.

Portée du module ou par connexion : où placer la requête

Python exécute les instructions de niveau module une seule fois, au chargement du script. Une requête de base de données écrite en haut du fichier lit donc la table au chargement et conserve cette réponse pour chaque connexion ultérieure. C’est la seconde raison pour laquelle une modification semble ne rien faire : le code s’exécute, mais pas au moment que vous attendez.

Placez la requête à l’intérieur du gestionnaire post_auth pour qu’elle s’exécute à chaque authentification. Conservez la signature documentée, ajustez le résultat d’authentification que reçoit le gestionnaire et renvoyez ce même objet plutôt qu’un nombre nu.

Gardez aussi la gestion de la connexion dans le gestionnaire. Une connexion ouverte à l’import peut être fermée par le serveur avant la première connexion d’un utilisateur, et l’erreur qui en résulte ressemble à un identifiant rejeté plutôt qu’à un script cassé.

Deux chemins de rejet, un propriétaire

Si la décision est une requête locale, le gestionnaire Python possède le résultat. Si c’est une vérification HTTP externe, laissez le code de sortie de la commande porter la réponse : un enveloppeur qui sort avec un code non nul rejette la connexion, et le statut de la dernière commande devient celui du script sans exit explicite.

Gardez le secret hors de la liste des processus. Un fichier lisible par root ou une valeur d’environnement transmise par le service est plus sûr qu’un argument que tout utilisateur local peut lire depuis ps. Fixez le point de terminaison dans une variable avant l’appel, pour qu’une faute de frappe échoue à la configuration plutôt que pendant la connexion de quelqu’un. Renouvelez ce secret comme n’importe quel autre identifiant.

Choisissez un seul propriétaire par vérification. Un script qui interroge la base et appelle un service HTTP a besoin d’une règle de priorité énoncée pour le cas où les deux divergent, sinon le motif de rejet du journal ne correspondra pas à ce qui a été dit à l’utilisateur.

Appliquez sans verrouiller l’administrateur

Deux garde-fous rendent la modification réversible : un second compte administrateur qui ne dépend pas du script, et une copie connue comme bonne conservée hors du répertoire des scripts. Appliquez la modification dans une fenêtre de maintenance, puis observez une connexion de test et un rejet volontaire avant de vous déconnecter. Si le journal montre une erreur de syntaxe au lieu d’une décision d’authentification, le script stocké est cassé et toutes les connexions échoueront.

Deux conditions disent d’attendre : vous ne pouvez pas lire le fichier de valeur en root, ou vous n’avez pas de second accès à l’interface d’administration. Toutes deux transforment une petite modification en verrouillage, et aucune ne mérite d’être testée sur un serveur de production en fin de journée. La documentation d’Access Server couvre l’interface post-auth et ses champs pris en charge.