Access Server는 디스크에서 편집한 post_auth 스크립트를 무시합니다

편집했는데 아무것도 바뀌지 않는 mac.py 이 흔한 첫 증상입니다. 디스크의 파일은 Access Server가 실행하는 대상이 아닙니다. 인증 서비스는 서버의 구성 데이터베이스에서 스크립트를 읽어오며, 저장된 그 사본이 로그인을 결정합니다. 저장된 값이 바뀌기 전까지 모든 시험은 예전 스크립트가 아직 동작한다는 것만 증명합니다.

작업을 결정하는 조건은 세 가지입니다. 값이 구성 데이터베이스에 들어간 적이 있는지, 서비스에 다시 읽으라는 명령이 있었는지, 그리고 바꾼 코드가 정말 연결마다 실행되는지입니다. 각각 증상이 다르고, 틀린 쪽을 고치면 유지보수 시간을 낭비합니다.

파일은 원본이고 실행 중인 사본이 아닙니다

Access Server는 post-auth 스크립트를 auth.module.post_auth_script 키 아래에 보관합니다. 파일을 편집하면 작업 사본만 갱신됩니다. 데몬은 저장된 값을 읽으므로, 예전 항목을 지우고 새 파일을 그 자리에 두기 전까지 변경은 보이지 않습니다. 그 저장된 값이 인증 서비스가 참조하는 유일한 사본입니다.

바꾸기 전에 읽어 보세요. 편집한 파일과 이미 일치한다면 문제는 저장이 아니므로 범위 질문으로 넘어가세요. 더 오래된 버전을 보여 준다면 변경이 서비스에 도달하지 않은 것입니다.

./sacli -k auth.module.post_auth_script ConfigGet

저장된 사본을 교체한 뒤 적용하세요

쓰기 전에 지우는 것은 장식이 아닙니다. ConfigPut 과 --value_file 는 값을 한 단계로 교체하고, 먼저 ConfigDel 를 하면 낡거나 손상된 항목이 남을 수 없습니다. 시작하기 전에 동작하는 스크립트의 사본을 스크립트 디렉터리 밖에 두세요.

./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 는 바뀐 구성을 내부 서비스에 적용하며, 새 스크립트가 효력을 갖게 하는 것이 바로 이것입니다. 전체 머신이나 데몬을 다시 시작하는 것과 같지 않고, 하려는 변경이 요구하지 않는 한 그것으로 대체해서는 안 됩니다.

값 파일에는 절대 경로를 쓰고 root가 읽을 수 있는지 확인하세요. 셸에서는 풀리지만 서비스 계정에서는 풀리지 않는 경로는 ConfigGet 에서는 맞아 보이고 첫 로그인에서 실패하는 저장 값을 만듭니다. 저장된 결과는 sacli start 이후에 한 번 더 확인하고, 그 전에는 확인하지 마세요.

모듈 범위인지 연결마다인지, 질의가 있어야 할 자리

Python은 모듈 수준 문장을 스크립트를 읽을 때 한 번 실행합니다. 그래서 파일 맨 위에 쓴 데이터베이스 질의는 읽을 때 표를 조회하고 그 답을 이후 모든 연결을 위해 보관합니다. 변경이 아무것도 하지 않는 것처럼 보이는 두 번째 이유입니다. 코드는 실행되지만 기대한 시점이 아닙니다.

질의를 post_auth 처리기 안에 두어 인증마다 실행되게 하세요. 문서화된 서명을 유지하고, 처리기가 받는 인증 결과를 조정하고, 맨 숫자 대신 같은 객체를 돌려주세요.

연결 관리를 처리기 안에 두세요. 가져올 때 연 첫 연결은 첫 사용자가 로그인하기 전에 서버가 닫을 수 있고, 그 결과 생기는 오류는 깨진 스크립트가 아니라 거부된 자격 증명처럼 보입니다.

거부 경로 둘, 소유자 하나

결정이 로컬 질의라면 Python 처리기가 결과의 소유자입니다. 외부 HTTP 검사라면 명령의 종료 상태가 답을 나르게 하세요. 영이 아닌 코드로 끝나는 래퍼는 로그인을 거부하고, 마지막 명령의 상태가 명시적 exit 없이 스크립트의 상태가 됩니다.

비밀은 프로세스 목록 밖에 두세요. root가 읽을 수 있는 파일이나 서비스가 넘기는 환경 값이, 어떤 로컬 사용자든 ps 에서 읽을 수 있는 인자보다 안전합니다. 호출 전에 끝점을 변수에 고정해, 오타가 구성 시점에 실패하고 누군가의 로그인 중에 실패하지 않게 하세요. 그 비밀은 다른 자격 증명과 같은 방식으로 주기적으로 교체하세요.

검사마다 소유자를 하나 고르세요. 데이터베이스를 조회하면서 HTTP 서비스도 호출하는 스크립트는 둘이 어긋날 경우를 위한 우선순위 규칙을 밝혀야 합니다. 그렇지 않으면 로그의 거부 사유가 사용자에게 말한 내용과 맞지 않습니다.

관리자를 잠그지 않고 적용하세요

두 가지 안전장치가 변경을 되돌릴 수 있게 합니다. 스크립트에 의존하지 않는 두 번째 관리자 계정과, 스크립트 디렉터리 밖에 둔 알려진 정상 사본입니다. 유지보수 시간에 변경을 적용하고, 연결을 끊기 전에 시험 로그인 하나와 의도적 거부 하나를 지켜보세요. 로그가 인증 결정 대신 구문 오류를 보여 준다면 저장된 스크립트가 깨진 것이고 모든 로그인이 실패합니다.

기다리라는 조건은 두 가지입니다. root로 값 파일을 읽을 수 없거나, 관리 인터페이스로 들어가는 두 번째 길이 없을 때입니다. 둘 다 작은 변경을 잠금으로 바꾸고, 하루 끝에 운영 서버에서 시험할 가치가 없습니다. Access Server 문서는 post-auth 인터페이스와 지원되는 필드를 다룹니다.