Access Server diskdə dəyişdirdiyiniz post_auth skriptinə məhəl qoymur

Heç nəyi dəyişməyən redaktə edilmiş mac.py adətən ilk simptomdur. Diskdəki fayl Access Serverin icra etdiyi şey deyil; autentifikasiya xidməti skripti serverin konfiqurasiya verilənlər bazasından yükləyir və məhz həmin saxlanmış surət girişi müəyyən edir. Saxlanmış dəyər dəyişdirilməyincə hər test yalnız köhnə skriptin hələ də işlədiyini sübut edir.

İşi üç şərt müəyyən edir: dəyərin ümumiyyətlə konfiqurasiya verilənlər bazasına yazılıb-yazılmadığı, xidmətə onu yenidən yükləmək tapşırılıb-tapşırılmadığı və dəyişdirdiyiniz kodun həqiqətən hər bağlantıda işləyib-işləmədiyi. Hər birinin fərqli simptomu var və səhv olanı düzəltmək bir texniki xidmət pəncərəsini boşa verir.

Fayl mənbədir, işləyən surət deyil

Access Server post-auth skriptini auth.module.post_auth_script açarı altında saxlayır. Faylı redaktə etmək yalnız işçi surətinizi yeniləyir. Demon saxlanmış dəyəri oxuyur, ona görə də köhnə qeydi silib yeni faylı onun yerinə qoymayınca redaktə görünməz qalır. Həmin saxlanmış dəyər autentifikasiya xidmətinin müraciət etdiyi yeganə surətdir.

Dəyişməzdən əvvəl onu oxuyun. Əgər o, redaktə etdiyiniz faylla artıq uyğundursa, problem yaddaşda deyil və əhatə sualına keçin. Əgər köhnə versiyanı göstərirsə, redaktə xidmətə çatmayıb.

./sacli -k auth.module.post_auth_script ConfigGet

Saxlanmış surəti əvəz edin, sonra tətbiq edin

Yazmadan əvvəl silmək bəzək deyil. ConfigPut --value_file ilə dəyəri bir addımda əvəz edir, əvvəlcə ConfigDel isə köhnə və ya zədələnmiş qeydin qalmasını qeyri-mümkün edir. Başlamazdan əvvəl işləyən skriptin surətini skriptlər qovluğundan kənarda saxlayın.

./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 dəyişdirilmiş konfiqurasiyanı daxili xidmətlərə tətbiq edir və yeni skriptin qüvvəyə minməsinə səbəb olan məhz budur. Bu, bütün maşını və ya demonu yenidən başlatmaqla eyni deyil və etdiyiniz dəyişiklik bunu tələb etmirsə, onunla əvəz edilməməlidir.

Dəyər faylı üçün mütləq yol istifadə edin və rootun onu oxuya bildiyini təsdiqləyin. Sizin shellinizdən həll olunan, lakin xidmət hesabından həll olunmayan yol ConfigGet-də yaxşı görünən və ilk girişdə uğursuz olan saxlanmış dəyər yaradır. Saxlanmış nəticəni sacli start-dan sonra bir daha yoxlayın, əvvəl yox.

Modul əhatəsi yoxsa hər bağlantı: axtarış harada olmalıdır

Python modul səviyyəli ifadələri skript yüklənəndə bir dəfə icra edir. Ona görə də faylın yuxarısında yazılmış verilənlər bazası sorğusu cədvəli yükləmə zamanı oxuyur və həmin cavabı sonrakı bütün bağlantılar üçün saxlayır. Redaktənin heç nə etməməsi kimi görünməsinin ikinci səbəbi budur: kod işləyir, amma gözlədiyiniz vaxtda deyil.

Sorğunu post_auth emalçısının içərisinə qoyun ki, hər autentifikasiya üçün icra olunsun. Sənədləşdirilmiş imzanı saxlayın, emalçının aldığı autentifikasiya nəticəsini düzəldin və boş ədəd yerinə həmin obyektin özünü qaytarın.

Bağlantı idarəetməsini də emalçının içində saxlayın. İdxal zamanı açılan bağlantı ilk istifadəçi daxil olmadan server tərəfindən bağlana bilər və yaranan xəta pozulmuş skript kimi deyil, rədd edilmiş etimadnamə kimi görünür.

İki rədd yolu, bir sahib

Qərar lokal sorğudursa, nəticəyə Python emalçısı sahibdir. Xarici HTTP yoxlamasıdırsa, cavabı əmrin çıxış statusu daşısın: sıfırdan fərqli çıxan sarğı girişi rədd edir və son əmrin statusu açıq exit olmadan skriptin statusuna çevrilir.

Sirri proses siyahısından kənarda saxlayın. root tərəfindən oxuna bilən fayl və ya xidmətin ötürdüyü mühit dəyəri, hər hansı lokal istifadəçinin ps-dən oxuya biləcəyi arqumentdən daha təhlükəsizdir. Çağırışdan əvvəl son nöqtəni dəyişəndə bərkidin ki, yazı səhvi konfiqurasiya vaxtı uğursuz olsun, kiminsə girişi zamanı yox. Sirri digər etimadnamələr kimi vaxtaşırı dəyişin.

Hər yoxlama üçün bir sahib seçin. Həm verilənlər bazasına sorğu göndərən, həm də HTTP xidməti çağıran skript üçün ikisinin fərqləndiyi halda bəyan edilmiş üstünlük qaydası lazımdır, əks halda logdakı rədd səbəbi istifadəçiyə deyilənlə uyğun gəlməyəcək.

Administratoru bloklamadan tətbiq edin

İki qoruyucu dəyişikliyi geri qaytarıla bilən edir: skriptdən asılı olmayan ikinci admin hesabı və skriptlər qovluğundan kənarda saxlanan tanınmış yaxşı surət. Dəyişikliyi texniki xidmət pəncərəsində tətbiq edin, sonra əlaqəni kəsməzdən əvvəl bir sınaq girişini və bir qəsdən rəddi izləyin. Əgər log autentifikasiya qərarı yerinə sintaksis xətası göstərirsə, saxlanmış skript pozulub və hər giriş uğursuz olacaq.

İki şərt gözləmək deyir: dəyər faylını root kimi oxuya bilmirsiniz, və ya admin interfeysinə ikinci yolunuz yoxdur. Hər ikisi kiçik dəyişikliyi bloklanmaya çevirir və heç biri günün sonunda istehsal serverində sınamağa dəyməz. Access Server sənədləri post-auth interfeysini və onun dəstəklənən sahələrini əhatə edir.