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 и поддържаните му полета.