אחרי שגילינו איך לגרום לפונקציונליות העיקרית של המערכת נטולת-המסך לעבוד, הגיע הזמן להכין חומרה מסודרת, להוסיף אופציה לכיבוי מסודר (בלי לחסום את עצמנו בטעות) וגם להגן מפני ונדליזם היי-טקי.
שלב 7: חומרה נורמלית
בתכנון המקורי למערכת חשבתי לתפעל ממסר אלקטרו-מכני, וספציפית את הממסר שבתמונה הבאה, שהתאים לי כי הוא דורש 5V להפעלה וזרם חלש יחסית (בסביבות 60 מיליאמפר), ואת שניהם אפשר לקחת מפין 5V של הפיי.
אך ברגע האחרון השתנו התוכניות, בגלל שרשרת לדים דקורטיבית שקניתי עם הילדים בחנות השמונצים השכונתית. הסתערתי עליה עם קאטר (על השרשרת, לא על החנות!) חתכתי את החוטים שבין בית הסוללות ללדים והתקנתי על הקצוות קונקטורים. כך אפשר לחבר את השרשרת מחדש ולהשתמש בה כמו שהיצרן התכוון, או לחבר אותה ללוח משלי ולמתג את החשמל באמצעות טרנזיסטור. דגם הטרנזיסטור שבחרתי הוא BS170, מפני שכבר היה לי כזה ומפני שהוא מסוגל להעביר, לפי המפרט, 0.25A, בעוד ששרשרת הלדים צורכת (מדדתי) רק כ-0.1A.
הנה תמונה של הלוח. יש לו כניסה ויציאה לבית הסוללות ולשרשרת הלדים, ושלושה חוטים שמגיעים מהפיי: אדמה, סיגנל ללד הסטטוס הירוק, וסיגנל לטרנזיסטור. בפינת הלוח יש נגד pull-down עם ערך 200K אוהם, גם כן עבור הטרנזיסטור, כי גיליתי שביציאה מהתוכנית שלי, פין ה-GPIO של הפיי עובר למצב High-z והטרנזיסטור עלול להגיב באופן אקראי.
שלב 8: המקלדת לא סובלת הכול
כעת הגיע הזמן לנטרל את יכולתו של משתמש זדוני פוטנציאלי ללחוץ Ctrl+Alt+Del או Ctrl+C ולהפריע כך לפעולת התוכנית. לחיצה על Ctrl+C היא אחת ממספר "סיגנלים" מוכרים בלינוקס, והפקודה trap מאפשרת לנו לנתב את הטיפול בכל סיגנל (במקרה זה, סיגנל מס' 2) כרצוננו. בקובץ .bashrc נקיף את הקריאה לתוכנה בשתי פקודות נוספות, בהתחלה לניתוב הסיגנל המסוכן לשום-מקום, ואחר כך (אחרי שהתוכנית מסתיימת) להחזרתו למוטב. זה נראה כך:
trap '' 2 python3 sisma.py trap 2
הטיפול ב-Ctrl+Alt+Del שונה, ולרוע המזל הוא השתנה בין גרסאות של מערכת ההפעלה, כך שרוב הפתרונות שעולים כרגע בגוגל הם כבר לא רלוונטיים. את הפתרון שעבד מצאתי כאן, ואותו מבצעים פעם אחת בלבד והוא תקף לתמיד, מה שאומר שלא נוכל עוד להשתמש בצירוף המקשים הזה בפיי (אלא אם ננקוט פעולות מיוחדות להחזיר את המצב לקדמותו). בשורת הפקודה הרגילה, נכתוב את שתי הפקודות האלה:
sudo rm /lib/systemd/system/ctrl-alt-del.target sudo ln -s /dev/null /lib/systemd/system/ctrl-alt-del.target
שלב 9: סגירה זהירה
התוכנה שלנו כוללת כזכור סיסמה שנייה שמסיימת את ריצת התוכנית, אבל כשזה יקרה, מערכת ההפעלה עדיין תישאר פעילה. במקום להכריח את המפעיל לכתוב את פקודת הכיבוי הסטנדרטית "על עיוור", החלטתי לשים גם אותה בסוף הקובץ .bashrc . אבל כאן צריך להיזהר במיוחד: התוכנה עולה אוטומטית, מיד אחריה הפיי יכבה אוטומטית, ובין לבין כבר אין אפשרות להפסיק אותה עם Ctrl+C! זה אומר שאם בעתיד נרצה לשנות משהו בקוד שלנו או בהגדרות, אין לנו דרך מעשית להגיע לשם. נצטרך להתקין ולהגדיר את הכול מהתחלה!
כדי לחסוך את כאב הלב הוספתי עוד קצת קוד ל-.bashrc (אם כי בשלב זה ייתכן שהיה חכם יותר ליצור script נפרד לכל ההתעסקות הזו). הקוד מתבסס על פקודת read, שקוראת מחרוזת מהמשתמש וניתן להגביל אותה בזמן (במקרה זה, 10 שניות). את המחרוזת אני שומר במשתנה, ולאחר סיום read אני בודק אם יש במשתנה הזה משהו. אם לא, סימן שהמפעיל לא לחץ על כלום (או רק על Enter), ואז אני מריץ את הפקודה שמכבה את המערכת. אם כן הוקלד משהו, אני מדלג על הכיבוי ובעצם חוזר ל-CLI (ממשק שורת הפקודה) הרגיל, דרכו אוכל לשנות ולנהל מה שארצה. הנה צילום מסך של הקוד הרלוונטי:
וזהו בעצם, המערכת מוכנה ועומדת בכל הדרישות העיקריות והמשניות שהגדרתי. הפיתוח היה מאתגר מהצפוי בקטע של העבודה עם לינוקס, אבל הקשיים היו מסוג שצריך לפתור רק פעם אחת, ושאפשר להשתמש בפתרונות גם במקומות אחרים.
מעניין מאוד. מה קורה שלוחצים על CTRL+ALT+F5 לדוגמא?
עד עכשיו אפילו לא שמעתי על הצירוף הזה… המערכת כבר פורקה כך שקשה לי לבדוק, בהחלט ייתכן שזהו סיכון נוסף לפעולת המערכת שהייתי צריך להכיר ולקחת בחשבון!
בכל מקרה, הכוונה שלי היא בעצם שכנראה הייתי תוקף את כל הסיפור מזווית אחרת בכמה עניינים:
1. גישת פיתוח על RPI: במקום לעבוד עם מקלדת ומסך ישירות על המכשיר הן: א. לעבוד על ה-SD על מחשב אחר ולדחוף אותו למכשיר שהכל מוכן; ב. לעבוד דרך NETWORK+SSH; או שילוב של שתי השיטות.
2. את הישום הייתי כנראה מריץ כ-service ולא באמצעות autologin.
3. סביר להניח שלא הייתי מאפשר למקלדת להתחבר באופן רגיל למחשב אלא מתייחס אליה כ-device מיוחד. לא בדקתי את זה, אבל ראה למשל:
https://python-evdev.readthedocs.io/en/latest/apidoc.html#evdev.device.InputDevice.grab
https://github.com/whizse/exclusive-keyboard-access
https://stackoverflow.com/questions/1698423/how-can-you-take-ownership-of-a-hid-device/1698686#1698686
https://stackoverflow.com/questions/19732978/how-can-i-get-a-string-from-hid-device-in-python-with-evdev
ואולי בעצם עובד בשיטה יותר דומה למה שאתה עשית:
https://superuser.com/questions/473411/redirect-physical-keyboard-input-to-ssh/1299783#1299783
(הרציונל הוא לא לאפשר בשום אופן למשתמש להגיע ל-BASH או משהו כזה בטעות – סכנה יחסית גדולה שעושים autologin)
(ומצד שני לאפשר לך עדיין לעשות login דרך ssh)
בסופו של דבר זה תמיד עניין של דרישות המערכת. אם כל הסיפור הזה צריך לשבת כחלק מחידה בחדר בריחה, ו"משתמש הקצה" בלחץ זמן לפתור את החידה ורואה מולו רק מקלדת – נו מילא, גם אם הוא האקר מהמדרגה הראשונה, המקסימום שהוא יכול לעשות זה לדפוק לעצמו את החידה ולהכריח את המפעיל לאתחל את הפיי…