編集した 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 インターフェースと対応する項目を扱っています。

関連記事