Access Server ignora o script post_auth que editou no disco

Un mac.py editado que non cambia nada é o primeiro síntoma habitual. O ficheiro do disco non é o que executa Access Server; o servizo de autenticación carga o script desde a base de datos de configuración do servidor, e esa copia almacenada é a que decide un inicio de sesión. Ata que se substitúe o valor gardado, cada proba só demostra que o script antigo segue funcionando.

Tres condicións deciden o traballo: se o valor chegou a gardarse na base de datos de configuración, se se ordenou ao servizo recargalo e se o código que cambiou se executa realmente en cada conexión. Cada unha ten un síntoma distinto, e arranxar a equivocada desperdicia unha xanela de mantemento.

O ficheiro é unha fonte, non a copia en execución

Access Server garda o script post-auth baixo a clave auth.module.post_auth_script. Editar o ficheiro actualiza a súa copia de traballo e nada máis. O daemon le o valor gardado, así que a edición queda invisible ata que borre a entrada antiga e poña o ficheiro novo no seu lugar. Ese valor gardado é a única copia que consulta o servizo de autenticación.

Léao antes de cambialo. Se xa coincide co ficheiro que editou, o problema non está no almacenamento e convén pasar á cuestión do alcance. Se mostra unha versión máis antiga, a edición nunca chegou ao servizo.

./sacli -k auth.module.post_auth_script ConfigGet

Substitúa a copia gardada e logo aplíquea

Borrar antes de escribir non é decoración. ConfigPut con --value_file substitúe o valor nun só paso, e ConfigDel primeiro fai imposible deixar unha entrada obsoleta ou corrupta. Garde unha copia do script operativo fóra do directorio de scripts antes de comezar.

./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 aplica a configuración cambiada aos servizos internos, e iso é o que fai que o novo script surta efecto. Non é o mesmo que reiniciar toda a máquina ou o daemon, e non debería substituírse por iso salvo que o cambio que fai o requira.

Use unha ruta absoluta para o ficheiro de valor e confirme que root pode lelo. Unha ruta que se resolve desde a súa shell pero non desde a conta do servizo produce un valor gardado que parece correcto en ConfigGet e falla no primeiro inicio de sesión. Comprobe o resultado gardado unha vez máis despois de sacli start, non antes.

Ámbito do módulo ou por conexión: onde corresponde a consulta

Python executa as sentenzas de nivel de módulo unha soa vez, ao cargar o script. Por iso unha consulta á base de datos escrita ao principio do ficheiro le a táboa no momento da carga e conserva esa resposta para cada conexión posterior. Esa é a segunda razón pola que unha edición parece non facer nada: o código execútase, pero non cando vostede o espera.

Pona consulta dentro do manexador post_auth para que se execute en cada autenticación. Manteña a sinatura documentada, axuste o resultado de autenticación que recibe o manexador e devolva ese mesmo obxecto en lugar dun número espido.

Manteña tamén o manexo da conexión dentro do manexador. Unha conexión aberta ao importar pode ser pechada polo servidor antes de que entre o primeiro usuario, e o erro resultante parece unha credencial rexeitada máis que un script roto.

Dúas rutas de rexeitamento, un propietario

Se a decisión é unha consulta local, o manexador de Python é dono do resultado. Se é unha comprobación HTTP externa, deixe que o estado de saída do comando leve a resposta: un envoltorio que sae cun código distinto de cero rexeita o inicio de sesión, e o estado do último comando convértese no estado do script sen un exit explícito.

Manteña o segredo fóra da lista de procesos. Un ficheiro lexible por root ou un valor de contorno pasado polo servizo é máis seguro ca un argumento que calquera usuario local pode ler desde ps. Fixe o extremo nunha variable antes da chamada, para que unha errata falle na configuración e non durante o inicio de sesión de alguén. Rote ese segredo igual que calquera outra credencial.

Escolla un só propietario por comprobación. Un script que consulta a base de datos e chama un servizo HTTP necesita unha regra de precedencia declarada para o caso en que ambos discrepen, ou o motivo do rexeitamento no rexistro non coincidirá co que se lle dixo ao usuario.

Aplíqueo sen bloquear ao administrador

Dúas salvagardas fan reversible o cambio: unha segunda conta de administrador que non dependa do script e unha copia boa coñecida gardada fóra do directorio de scripts. Aplique o cambio nunha xanela de mantemento e logo observe un inicio de sesión de proba e un rexeitamento deliberado antes de desconectarse. Se o rexistro mostra un erro de sintaxe en lugar dunha decisión de autenticación, o script gardado está roto e todos os inicios de sesión fallarán.

Dúas condicións din espere: non pode ler o ficheiro de valor como root, ou non ten unha segunda vía á interface de administración. Ambas converten un cambio pequeno nun bloqueo, e ningunha merece probarse nun servidor de produción ao final do día. A documentación de Access Server cobre a interface post-auth e os seus campos admitidos.