Access Server ignora lo script post_auth che hai modificato sul disco

Un mac.py modificato che non cambia nulla è il primo sintomo abituale. Il file sul disco non è ciò che esegue Access Server; il servizio di autenticazione carica lo script dal database di configurazione del server, e proprio quella copia memorizzata decide un accesso. Finché il valore memorizzato non viene sostituito, ogni prova dimostra solo che il vecchio script funziona ancora.

Tre condizioni decidono il lavoro: se il valore è mai stato inserito nel database di configurazione, se al servizio è stato ordinato di ricaricarlo e se il codice modificato viene davvero eseguito a ogni connessione. Ognuna ha un sintomo diverso, e correggere quella sbagliata spreca una finestra di manutenzione.

Il file è una fonte, non la copia in esecuzione

Access Server tiene lo script post-auth sotto la chiave auth.module.post_auth_script. Modificare il file aggiorna solo la copia di lavoro. Il demone legge il valore memorizzato, quindi la modifica resta invisibile finché non elimini la vecchia voce e metti il nuovo file al suo posto. Quel valore memorizzato è l’unica copia consultata dal servizio di autenticazione.

Leggilo prima di cambiarlo. Se corrisponde già al file che hai modificato, il problema non è la memorizzazione e passa alla questione dell’ambito. Se mostra una versione più vecchia, la modifica non ha mai raggiunto il servizio.

./sacli -k auth.module.post_auth_script ConfigGet

Sostituisci la copia memorizzata, poi applicala

Eliminare prima di scrivere non è decorazione. ConfigPut con --value_file sostituisce il valore in un solo passaggio, e ConfigDel prima rende impossibile lasciare una voce obsoleta o corrotta. Conserva una copia dello script funzionante fuori dalla directory degli script prima di iniziare.

./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 applica la configurazione modificata ai servizi interni, ed è ciò che rende efficace il nuovo script. Non è la stessa cosa di riavviare l’intera macchina o il demone, e non va sostituito da questo se non lo richiede la modifica che stai facendo.

Usa un percorso assoluto per il file del valore e conferma che root possa leggerlo. Un percorso che si risolve dalla tua shell ma non dall’account del servizio produce un valore memorizzato che sembra corretto in ConfigGet e fallisce al primo accesso. Controlla il risultato memorizzato ancora una volta dopo sacli start, non prima.

Ambito del modulo o per connessione: dove va la query

Python esegue le istruzioni a livello di modulo una sola volta, al caricamento dello script. Perciò una query al database scritta in cima al file legge la tabella al momento del caricamento e conserva quella risposta per ogni connessione successiva. È il secondo motivo per cui una modifica sembra non fare nulla: il codice viene eseguito, ma non quando te lo aspetti.

Metti la query dentro il gestore post_auth perché venga eseguita a ogni autenticazione. Mantieni la firma documentata, adatta il risultato di autenticazione che riceve il gestore e restituisci lo stesso oggetto invece di un numero nudo.

Mantieni anche la gestione della connessione dentro il gestore. Una connessione aperta all’importazione può essere chiusa dal server prima che entri il primo utente, e l’errore che ne deriva sembra una credenziale rifiutata più che uno script rotto.

Due percorsi di rifiuto, un proprietario

Se la decisione è una query locale, il gestore Python possiede il risultato. Se è un controllo HTTP esterno, lascia che lo stato di uscita del comando porti la risposta: un wrapper che esce con codice diverso da zero rifiuta l’accesso, e lo stato dell’ultimo comando diventa lo stato dello script senza un exit esplicito.

Tieni il segreto fuori dall’elenco dei processi. Un file leggibile da root o un valore d’ambiente passato dal servizio è più sicuro di un argomento che qualsiasi utente locale può leggere da ps. Fissa l’endpoint in una variabile prima della chiamata, così un errore di battitura fallisce in configurazione e non durante l’accesso di qualcuno. Ruota quel segreto come qualsiasi altra credenziale.

Scegli un solo proprietario per controllo. Uno script che interroga il database e chiama un servizio HTTP ha bisogno di una regola di precedenza dichiarata per il caso in cui i due discordino, altrimenti il motivo del rifiuto nel registro non corrisponderà a ciò che è stato detto all’utente.

Applicalo senza bloccare l’amministratore

Due salvaguardie rendono reversibile la modifica: un secondo account amministratore che non dipende dallo script e una copia buona nota conservata fuori dalla directory degli script. Applica la modifica in una finestra di manutenzione, poi osserva un accesso di prova e un rifiuto deliberato prima di disconnetterti. Se il registro mostra un errore di sintassi invece di una decisione di autenticazione, lo script memorizzato è rotto e ogni accesso fallirà.

Due condizioni dicono aspetta: non puoi leggere il file del valore come root, oppure non hai una seconda via all’interfaccia di amministrazione. Entrambe trasformano una piccola modifica in un blocco, e nessuna merita una prova su un server di produzione a fine giornata. La documentazione di Access Server copre l’interfaccia post-auth e i suoi campi supportati.