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 ואת השדות הנתמכים בו.