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 і підтримувані ним поля.