Access Server ignora el script post_auth que editó en el disco

Un mac.py editado que no cambia nada es el primer síntoma habitual. El archivo del disco no es lo que ejecuta Access Server; el servicio de autenticación carga el script desde la base de datos de configuración del servidor, y esa copia almacenada es la que decide un inicio de sesión. Hasta que se sustituye el valor guardado, cada prueba solo demuestra que el script antiguo sigue funcionando.

Tres condiciones deciden el trabajo: si el valor llegó a guardarse en la base de datos de configuración, si se ordenó al servicio que lo recargara y si el código que cambió se ejecuta realmente en cada conexión. Cada una tiene un síntoma distinto, y arreglar la equivocada desperdicia una ventana de mantenimiento.

El archivo es una fuente, no la copia en ejecución

Access Server guarda el script post-auth bajo la clave auth.module.post_auth_script. Editar el archivo actualiza su copia de trabajo y nada más. El demonio lee el valor guardado, así que la edición queda invisible hasta que borre la entrada antigua y ponga el archivo nuevo en su lugar. Ese valor guardado es la única copia que consulta el servicio de autenticación.

Léalo antes de cambiarlo. Si ya coincide con el archivo que editó, el problema no está en el almacenamiento y conviene pasar a la cuestión del alcance. Si muestra una versión más antigua, la edición nunca llegó al servicio.

./sacli -k auth.module.post_auth_script ConfigGet

Sustituya la copia guardada y luego aplíquela

Borrar antes de escribir no es decoración. ConfigPut con --value_file sustituye el valor en un solo paso, y ConfigDel primero hace imposible dejar una entrada obsoleta o corrupta. Guarde una copia del script operativo fuera del directorio de scripts antes de empezar.

./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 la configuración cambiada a los servicios internos, y eso es lo que hace que el nuevo script surta efecto. No es lo mismo que reiniciar toda la máquina o el demonio, y no debería sustituirse por ello salvo que el cambio que hace lo requiera.

Use una ruta absoluta para el archivo de valor y confirme que root puede leerlo. Una ruta que se resuelve desde su shell pero no desde la cuenta del servicio produce un valor guardado que parece correcto en ConfigGet y falla en el primer inicio de sesión. Compruebe el resultado guardado una vez más después de sacli start, no antes.

Ámbito del módulo o por conexión: dónde corresponde la consulta

Python ejecuta las sentencias de nivel de módulo una sola vez, al cargar el script. Por eso una consulta a la base de datos escrita al principio del archivo lee la tabla en el momento de la carga y conserva esa respuesta para cada conexión posterior. Esa es la segunda razón por la que una edición parece no hacer nada: el código se ejecuta, pero no cuando usted lo espera.

Ponga la consulta dentro del manejador post_auth para que se ejecute en cada autenticación. Mantenga la firma documentada, ajuste el resultado de autenticación que recibe el manejador y devuelva ese mismo objeto en lugar de un número desnudo.

Mantenga también el manejo de la conexión dentro del manejador. Una conexión abierta al importar puede ser cerrada por el servidor antes de que entre el primer usuario, y el error resultante parece una credencial rechazada más que un script roto.

Dos rutas de rechazo, un propietario

Si la decisión es una consulta local, el manejador de Python es dueño del resultado. Si es una comprobación HTTP externa, deje que el estado de salida del comando lleve la respuesta: un envoltorio que sale con un código distinto de cero rechaza el inicio de sesión, y el estado del último comando se convierte en el estado del script sin un exit explícito.

Mantenga el secreto fuera de la lista de procesos. Un archivo legible por root o un valor de entorno pasado por el servicio es más seguro que un argumento que cualquier usuario local puede leer desde ps. Fije el extremo en una variable antes de la llamada, para que una errata falle en la configuración y no durante el inicio de sesión de alguien. Rote ese secreto igual que cualquier otra credencial.

Elija un solo propietario por comprobación. Un script que consulta la base de datos y llama a un servicio HTTP necesita una regla de precedencia declarada para el caso en que ambos discrepen, o el motivo del rechazo en el registro no coincidirá con lo que se dijo al usuario.

Aplíquelo sin bloquear al administrador

Dos salvaguardas hacen reversible el cambio: una segunda cuenta de administrador que no dependa del script y una copia buena conocida guardada fuera del directorio de scripts. Aplique el cambio en una ventana de mantenimiento y luego observe un inicio de sesión de prueba y un rechazo deliberado antes de desconectarse. Si el registro muestra un error de sintaxis en lugar de una decisión de autenticación, el script guardado está roto y todos los inicios de sesión fallarán.

Dos condiciones dicen espere: no puede leer el archivo de valor como root, o no tiene una segunda vía a la interfaz de administración. Ambas convierten un cambio pequeño en un bloqueo, y ninguna merece probarse en un servidor de producción al final del día. La documentación de Access Server cubre la interfaz post-auth y sus campos admitidos.