Access Server ignoră scriptul post_auth pe care l-ați editat pe disc

Un mac.py editat care nu schimbă nimic este primul simptom obișnuit. Fișierul de pe disc nu este ceea ce execută Access Server; serviciul de autentificare încarcă scriptul din baza de date de configurare a serverului, iar acea copie stocată este cea care decide o conectare. Până când valoarea stocată nu este înlocuită, fiecare test dovedește doar că scriptul vechi încă funcționează.

Trei condiții decid munca: dacă valoarea a fost vreodată pusă în baza de date de configurare, dacă serviciului i s-a poruncit să o reîncarce și dacă codul modificat rulează cu adevărat la fiecare conexiune. Fiecare are alt simptom, iar repararea celei greșite irosește o fereastră de mentenanță.

Fișierul este o sursă, nu copia care rulează

Access Server ține scriptul post-auth sub cheia auth.module.post_auth_script. Editarea fișierului actualizează doar copia dumneavoastră de lucru. Demonul citește valoarea stocată, așa că modificarea rămâne invizibilă până când ștergeți intrarea veche și puneți fișierul nou în locul ei. Acea valoare stocată este singura copie pe care o consultă serviciul de autentificare.

Citiți-o înainte de a o schimba. Dacă se potrivește deja cu fișierul editat, problema nu este în stocare și treceți la întrebarea despre amploare. Dacă arată o versiune mai veche, modificarea nu a ajuns niciodată la serviciu.

./sacli -k auth.module.post_auth_script ConfigGet

Înlocuiți copia stocată, apoi aplicați-o

Ștergerea înainte de scriere nu este decor. ConfigPut cu --value_file înlocuiește valoarea într-un singur pas, iar ConfigDel mai întâi face imposibilă lăsarea unei intrări învechite sau corupte. Păstrați o copie a scriptului funcțional în afara directorului de scripturi înainte de a începe.

./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 aplică configurația modificată serviciilor interne, și aceasta este ceea ce face noul script să intre în vigoare. Nu este același lucru cu repornirea întregii mașini sau a demonului și nu ar trebui înlocuit cu aceasta decât dacă modificarea dumneavoastră o cere.

Folosiți o cale absolută pentru fișierul de valoare și confirmați că root îl poate citi. O cale care se rezolvă din shell-ul dumneavoastră, dar nu din contul serviciului, produce o valoare stocată care pare corectă în ConfigGet și eșuează la prima conectare. Verificați rezultatul stocat încă o dată după sacli start, nu înainte.

Amploare de modul sau per conexiune: unde îi este locul interogării

Python execută instrucțiunile la nivel de modul o singură dată, la încărcarea scriptului. De aceea o interogare a bazei de date scrisă în capul fișierului citește tabelul la încărcare și păstrează acel răspuns pentru fiecare conexiune ulterioară. Acesta este al doilea motiv pentru care o modificare pare să nu facă nimic: codul rulează, dar nu când vă așteptați.

Puneți interogarea în interiorul handlerului post_auth ca să ruleze la fiecare autentificare. Păstrați semnătura documentată, ajustați rezultatul autentificării primit de handler și returnați același obiect în loc de un număr gol.

Păstrați și gestionarea conexiunii în interiorul handlerului. O conexiune deschisă la import poate fi închisă de server înainte ca primul utilizator să se conecteze, iar eroarea rezultată arată ca acreditări respinse, nu ca un script stricat.

Două căi de respingere, un singur proprietar

Dacă decizia este o interogare locală, handlerul Python deține rezultatul. Dacă este o verificare HTTP externă, lăsați starea de ieșire a comenzii să poarte răspunsul: un înveliș care iese cu un cod diferit de zero respinge conectarea, iar starea ultimei comenzi devine starea scriptului fără un exit explicit.

Țineți secretul în afara listei de procese. Un fișier citibil de root sau o valoare de mediu transmisă de serviciu este mai sigură decât un argument pe care orice utilizator local îl poate citi din ps. Fixați punctul final într-o variabilă înainte de apel, ca o greșeală de tastare să eșueze la configurare și nu în timpul conectării cuiva. Rotiți acel secret ca orice altă acreditare.

Alegeți un singur proprietar pentru fiecare verificare. Un script care interoghează baza de date și apelează un serviciu HTTP are nevoie de o regulă de prioritate declarată pentru cazul în care cele două nu sunt de acord, altfel motivul respingerii din jurnal nu se va potrivi cu ce i s-a spus utilizatorului.

Aplicați-o fără a bloca administratorul

Două măsuri fac modificarea reversibilă: un al doilea cont de administrator care nu depinde de script și o copie bună cunoscută păstrată în afara directorului de scripturi. Aplicați modificarea într-o fereastră de mentenanță, apoi urmăriți o conectare de test și o respingere deliberată înainte de a vă deconecta. Dacă jurnalul arată o eroare de sintaxă în locul unei decizii de autentificare, scriptul stocat este stricat și fiecare conectare va eșua.

Două condiții spun așteptați: nu puteți citi fișierul de valoare ca root sau nu aveți o a doua cale către interfața de administrare. Ambele transformă o modificare mică într-o blocare, și niciuna nu merită testată pe un server de producție la sfârșitul zilei. Documentația Access Server acoperă interfața post-auth și câmpurile acceptate.