על בעיה X ופתרון Y

כאחד שנותן יעוץ לחברות, יוצא לי בלא מעט מקרים להיפגש עם נציגים טכניים של חברות שונות, מסטארט-אפים ועד לחברות גדולות – בכדי לתת להם יעוץ בנושא פתרון טכנולוגי זה או אחר לצורך פתרון בעיות או לצורך הטמעת פתרון חדש או משופר בהשוואה למה שיש להם כיום. דוגמא פשוטה: חברה מעוניינת לרכוש סטורג' חדש, והם מעוניינים לדעת האם פתרונות מבוססי קוד פתוח יכולים לתת להם מענה במחיר יותר זול מפתרון סטורג' קנייני. אי אפשר לעשות יעוץ בטלפון של שיחה כמו:

לקוח פוטנציאלי: היי חץ, יש לנו NetApp ואנחנו רוצים לדעת, יש פתרון מבוסס קוד פתוח שיכול להחליף?
חץ בן חמו: אולי.

בשביל לייעץ לבעיה כמו שציינתי לעיל, צריך לשבת עם הלקוח הפוטנציאלי לפגישת יעוץ מלאה, ולשמוע ממנו את הדברים הבאים:

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

ההבדלים ביני (וכמובן אחרים), כיועץ ואינטגרטור בלתי תלוי (כלומר אחד שהוא אינו בעצם Reseller של ברזלים ממותגים) הם דברים חשובים כגון:

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

לא לי ולא לאף פרילאנסר יועץ או אינטגרטור, אין מכונה לקריאת מחשבות, ולא קל "להוציא" מלקוחות פוטנציאליים את אותו Y. יחד עם זאת, בכל חברה, תמיד יש חיפוש לפתרונות לבעיות Y כלשהן, וכאן הייתי רוצה (ובוודאי פרילאנסרים אחרים) לשמוע מהן אותן בעיות Y שחברתכם מחפשת אליהן פתרון (מבוסס לינוקס או מבוסס קוד פתוח). אתם מוזמנים לענות כאן (ללא ציון שם חברה או פרטים מזהים אחרים של מקום עבודתכם) ואולי תקבלו הצעות מעניינות של פתרונות שונים ואם תרצו תוכלו לפנות למציע (כל פרילאנסר יכול כמובן לענות).

חושבים לשדרג את הפצת הלינוקס שלכם? קראו

כפרילאנסר, אני תמיד מחפש עבודות במגוון תחומים (יש רשימה ארוכה של נושאים שאני נותן בהם שרות, מי שרוצה, קורות חיים תמיד זמינים כאן), ולפעמים אני מקבל משימות שבהם הלקוח מעוניין לשדרג את הפצת הלינוקס. לפעמים זה לשרת אחד, לפעמים זה ל-Image של Appliance, ולפעמים מגיעים הפרויקטים של שדרוג שמהווה אתגר גדול – מעבר בין הפצת לינוקס X להפצת לינוקס Y כשאין תאימות (במיוחד שצריך להעביר קבצים בינאריים ללא קוד מקור…).

השדרוגים הכי קלים לביצוע הם בגרסאות minor version. בד"כ כל הפצת לינוקס שמכבדת את עצמה שומרת על תאימות בינארית מלאה כך שאם התקנת לדוגמא CentOS או RHEL גירסה 7.0 ושדרגת לגירסה 7.5, התאימות הבינארית תישאר לגמרי (למעט kernel modules חיצוניים שאותם יש צורך לשדרג, לפעמים בנפרד, אבל בלינוקס יש את GRUB ותמיד אפשר לחזור גירסת kernel אחורה על מנת להעלות את המערכת ולהשתמש ב-DKMS כדי לשדרג לקרנל האחרון באופן אוטומטי).

השדרוגים היותר בעייתיים הם גרסאות Major, נניח מגירסת RHEL 6 ל-RHEL-7 (אגב, RHEL-8 בטא יחל בקרוב). מי שיעיין בתיעוד של ההפצה (כן, יש הפצות שעושים חתיכת תיעוד – כמו SuSE ו-RHEL, ויש כאלו שכותבים תיעוד כמו מברקים) יוכל לראות מה הדברים שהשתנו ולהיערך בהתאם (כן, קרה לי כבר כמה מצבים שהזמינו אותי לאחר שניסו לשדרג מבלי לקרוא והמכונות תקועות..). חשוב לזכור: כל הפצות הלינוקס שוברות תאימות בינארית בצורה זו או אחרת כשמשדרגים גרסאות Major ואם אתה מתעקש להריץ קבצים בינאריים ישנים שלא נוצרו עבור המערכת החדשה, אז תצטרך להכיר מקרוב את ספריות ה-compat למיניהן (וגם זה סיפור לא קל, אם קבצי ה-DEB או RPM מתעקשים לקבל רק ספריות שונות). במקרים רבים יש גם שוני בקבצי קונפיגורציה או בכלל במערכת השרותים (כמו המעבר ל-SystemD). חברות יצרניות ההפצה אינן מאלו ש"יזרקו לקוחות לכלבים" בכל הנוגע למעבר והן מציעות באותה גירסת Major תאימות אחורה (לשרותי upstart לדוגמא) כך שהסקריפטים שלך ירוצו, אבל מומלץ בחום לנצל את ההזדמנות ולעשות פרויקט המרה של הסקריפטים לשרותים החדשים (לאחר השדרוג).

השדרוג היותר מאתגר הוא שדרוג בין 2 גרסאות שונות של אותה הפצת לינוקס (נניח RHEL 5 ל-RHEL 7). במקרים רבים, נסיון שדרוג של החלפת קבצי REPO והרצת YUM UPDATE לדוגמא יתנו מערכת שאולי תרוץ, אבל זו תהיה מערכת שעלולה כל רגע לקרוס, ולכן לא מומלץ לשדרג ב"קפיצות" כאלו כלל וכלל אלא להקים מערכת חדשה, להגדיר אחד אחד את השרותים שצריך, ואז להעביר את האפליקציות. ברוב המקרים גם קבצי הקונפיגורציה יצטרכו להשתנות (ובחלק מהמקרים גם המיקומים שלהם… אהלן Docker עם גירסת CE מול גירסת הפצה!), ולכן שדרוגים כאלו יכולים לקחת גם ימים ספורים (תלוי במורכבות אותה מכונה. יש לא מעט כאלו שהתקינו בעבר לפני מעבר לוירטואליזציה 30 שרותים שונים על מכונת לינוקס אחת, לך תמיר את זה לגירסת לינוקס מודרנית).

העבודה הכי קשה היא להמיר מכונות לינוקס קיימות להפצת לינוקס אחרת שאינה תואמת (נניח SLES ל-Debian). כל עוד הדברים קיימים כחבילות בינאריות רשמיות, הדברים יחסית די קלים (אבל עדיין לוקחים זמן, כל הפצה וההגדרות שלה, ואפליקציית Alien לא תמיד עוזרת בהמרה), אבל אם לדוגמא לקוח רוצה להעביר מרכזיה קיימת עם אותם קבצים בינאריים מהפצה להפצה, זו חתיכת עבודה שבמקרים לא מעטים גם מחייבת קימפול או השגת תאימות בינארית מהמכונה הישנה לחדשה, לא דבר כל כך קליל.

לכן, אני ממליץ לחשוב לגבי הנקודות הבאות:

  • עדכונים בתוך אותה הפצה (כלומר עדכוני אבטחה ובאגים) – לעדכן תדיר, אחת לשבועיים או אחת לחודש.
  • שדרוג הפצה לגירסת Major הבאה – להמתין מעט ולא לרוץ לעשות זאת מיד כשההפצה יוצאת (במיוחד כשמדובר ב-Ubuntu ששם לצערי כמות הטסטים שמבוצעים היא די זעומה, גם בגרסאות LTS, חטפתי מספיק Kernel Panic גם כזה LTS). חכו עם זה חודשיים שלוש.
  • לא לשדרג הכל במכה אחת! נכון, יש היום Ansible ו-Puppet ו-Chef ומאוד מתחשק להשתמש בכלים הללו לשדרג באופן אוטומטי, אבל יש סיכוי גדול שיחד עם אותה אוטומציה תקבלו מספר מכונות שלא יעבדו, ולכו תסבירו לבוס מדוע המכונות לא עובדות.
  • אם אין לכם מומחה לינוקס ויש לכם מס' מכונות לינוקס שאתם רוצים לשדרג לגירסה החדשה – קחו יעוץ חיצוני לפני השדרוג (אני מכיר מקרה שאיש סיסטם חשב שגירסת שרתים זה גירסת Desktop והוא פשוט הריץ sudo apt update && sudo apt dist-upgrade לכל מכונות הרינדור ופתאום לא היה להם שום מכונת רינדור) וקחו את הזמן לשדרג, לא עושים זאת במהירות.
  • מעבר בין הפצות לינוקס או מעבר "קפיצה" בין גרסאות ישנה מאוד לחדשה – עדיף להתחיל מאפס ולהעביר שרותים וקבצים וקבצי קונפיגורציה לאט ובזהירות. להשאיר את המכונה הישנה פועלת, להעביר, לעבור לחדשה (עוד לא למחוק את הישנה) ורק כשהכל תקין וכולם מאשרים שהשרותים שהם משתמשים פועלים – אז אפשר לכבות את המכונה הישנה ועדיף לא למחוק אותה.

לגבי מכונות דסקטופ/לאפטופים והפצות לדסקטופ – יצאה גירסה חדשה? אחלה, אל תרוצו לשדרג, תנו לזה חודש חודשיים עד שיתקנו את הבאגים, כי מה לעשות, יש לא מעט מצבים בהם שדרוגים שוברים דברים קיימים במחשב, קימפולים של היצרן שמשאירים Unresolved symbol (מה שגורם לאפליקציות לא לרוץ), או שסתם דופקים את כל ה-REPO הפנימי ובשום מקרה לא להשתמש בפרמטר force (אלא אם בא לכם לשרוף כמה שעות טובות ולדפוק את הראש בקיר). נקודה חשובה נוספת: משתמשים בכרטיס nVidia או כל ציוד שמצריך מודול בינארי? המודולים לא יהיו תואמים במרבית המקרים להפצה שיצאה רק אתמול, אז תמתינו בסבלנות.

לסיכום: זה כיף להיות עם הפצת הלינוקס בגירסה האחרונה שהמילה האחרונה בטכנולוגיה מותקנת אצלך, אבל צריכים להיות זהירים וסבלניים. תקלות יקרו, טעויות יגרמו. אנחנו בני אדם ולפעמים לא שמים לב לדברים, ולכן לא מומלץ לעשות דברים בחופזה.

על בניית מערכת מוקשחת לאנדרואיד

בארגונים רבים יש נוהל בו ניתן טלפון סלולרי לעובד מחברה כלשהי. מכשיר זה בד"כ מנוהל ע"י צוות ה-IT והוא מקבל עדכונים רשמיים הן מיצרן המכשיר והן דרך תשתית ה-IT (או חנות האפליקציות – כמו Google Play Store או ה-Appstore של אפל). בד"כ מנהל ה-IT יוכל להגדיר לשם אבטחה ביטול או חסימת אפליקציות ושרותים מסויימים. ארגונים שמחפשים להגן על תוכן וגישה לאפליקציות מסויימות במכשיר, יכולים להשתמש בתשתית כמו KNOX (במקרים של סמסונג) או בדברים יותר פשוטים כמו Applock שמאפשרים לנעול אפליקציות מסויימות כך שניתן יהיה להשתמש בהן רק עם טביעת אצבע או קוד מיוחד שיש רק לבעל המכשיר.

אולם יש מקרים בהן חברות (במיוחד חברות אבטחה) רוצות שהמכשירים יהיו לחלוטין מוקשחים, עם רשימת דרישות משלהם, אחרת המכשיר לא יכנס לשרות, וכאן לעיתים יש בלבול בין הקשחות שרתים ודסקטופים שרבים מאנשי האבטחה מכירים – לבין הקשחת מכשיר אנדרואיד.

בואו נסתכל לדוגמא על שרת לינוקס או שרת Windows: לא חשוב אלו הוראות תבצעו ע"מ להקשיח את השרת, ברוב מוחלט של המקרים הדברים מדובר בין היתר על ביצוע הפעולות הבאות:

  • הסרת שרותים שונים שמותקנים בשרת (או ביטול התקנה שלהם אם זה שרת חדש)
  • סגירת כניסות ויציאות שונות (הן פיזית והן ברמת תקשורת)
  • שינוי הגדרות שונות לפי ההוראות שיש (לדוגמא של CIS)

לעומת זאת, במכשירי אנדרואיד (ובמידה מסוימת iOS) – אין לך שום אפשרות כזו. אתה יכול להסיר רק חלק מהאפליקציות, וחלק אחר של האפליקציות אתה יכול "להקפיא" (שזה כמובן לא פתרון, המשתמש עדיין יוכל "להחיות" אותן מחדש). ההגדרות היחידות שאתן יכול לשנות במכשיר הן ההגדרות שמופיעות במסך "הגדרות" (Settings). בחלק מהמקרים אפשר להגביל את המשתמש שלא יוכל לשנות הגדרות מסוימות, אבל אם תשאלו אנשי אבטחה במוסדות בטחוניים שונים – זהו אינו פתרון מספק.

על מנת לשלוט טוטאלית על מה שיהיה במכשיר ומה לא יהיה, אלו פונקציות יהיו פעילות ואלו לא יהיו קיימות – יש צורך "לבנות" את האנדרואיד מחדש למכשיר ולקמפל כמעט הכל מחדש על מנת ליצור מספר Images שונים – וכאן ה-"Fun" מתחיל…

הנה סיפור קצרצר: לפני מס' חודשים פנתה אליי חברה עם 2 מכשירי גלקסי S7 ו-S7 Edge עם "רשימת מכולת" הכוללת בערך 50 דברים שהחברה לא רוצה לראות במכשיר ודברים שהיא רצתה שיפעלו ללא אפשרות כיבוי ועוד הגדרות שונות. שאלתי את החברה האם יש שיתוף פעולה מצד סמסונג בכך שיתנו את הקוד מקור והאם שינויים אלו לא יפרו את האחריות. התשובה ל-2 השאלות היתה "לא". בצער רב החזרתי את המכשירים לחברה באותו יום עם הסבר מדוע לא אוכל לבצע את הפרויקט המבוקש, ולהלן הסיבות:

  • כל שינוי הגדרות שאינו שינוי שמשתמש יכול לבצע (כמו הפעלת Root – דבר הכרחי כדי לשנות דברים ברמת הבסיס) מבטל מיד קבלת העדכונים שהיצרן (במקרה זה: סמסונג) משחרר מדי חודש או חודשיים למכשירים (ניתן לראות ולוודא זאת בכניסה למסך הגדרות, "אודות המכשיר", "סטטוס", ובסוף אותו דבר ישנו "סטטוס מכשיר" – אם הוא רשמי, תקבלו עדכונים. אם לא, מכשירכם לא יקבל עדכונים).
  • בנוסף, שינוי שאינו מורשה ע"י היצרן גם מבטל אחריות של המכשיר, בין בטיפול בתקלת תוכנה או תקלת חומרה. שינית? להתראות לאחריות (ואגב, השינויים במכשירים כמו של סמסונג מפעילים Trigger כך שכשמפעילים את המכשיר ולוחצים על מספר כפתורים יחד, ניתן לראות מיד אם בוצע שינוי או לא, וברוב המקרים לא ניתן גם "למחוק" את הסטטוס הזה).

אז האם ניתן "לבנות" את תוכנת המכשיר מחדש עם צרכי הלקוח? בהחלט, אולם לשם כך יש צורך במספר דברים:

  • ראשית, יש צורך בשיתוף פעולה מצד יצרן המכשיר במסירת קוד המקור למכשיר או שיתוף פעולה ע"י יצרן המעבד. הסיבה העיקרית לכך היא שישנם חלקים רבים של קוד שאינם קוד פתוח ובלעדיהם לא ניתן לבנות מערכת חדשה. קחו לדוגמא את עניין הדרייברים: ללא קוד מקור לדרייברים, לא ניתן לבצע קימפול אפילו לקוד שמפעיל אפשרות להתחבר לרשת סלולרית או WIFI, מסך מגע או תצוגה חלקה של המסך. ללא שיתוף פעולה ניתן "לקושש" באינטרנט אחר דרייברים בינאריים שנבנו עבור גירסה מסויימת לאנדרואיד, אולם אין שום בטחון שהם יפעלו.
  • רוב יצרני הטלפונים הסלולריים נועלים את מכשיריהם בפני עדכונים לא-מורשים בכך שהם חותמים כל עדכון עם שילוב מפתח פרטי/ציבורי, כך שכל Image שיבנה עבור המכשיר – לא יוכל להיות מותקן על המכשיר. כשיש שיתוף פעולה עם היצרן, ניתן להעביר אליו בקשות חתימה ולעדכן בעזרת תוכנות שונות את קושחת המכשיר. ללא שיתוף פעולה של היצרן – יש צורך בלבצע Root, להתקין תוכנת Recovery (כמו TWRP), לבטל מספר בדיקות שאמורות להגן על המכשיר משינויים ורק אז ניתן להתקין Image שנבנה עבור הלקוח.
  • במידה ומדובר במכשיר שמיוצר עבור החברה (נניח בסין) אז בהחלט ניתן לבנות Image, אולם יש לקחת בחשבון שהעבודה צריכה להתבצע מאפס. אני לא ממליץ לשום חברה בטחונית (או חברה שאבטחת המידע חשובה לה) להסתמך על קושחה/ROM של היצרן הסיני, המכשירים בד"כ מגיעים קושחה עמוסת חורי אבטחה ולפעמים גם הקושחה מגיעה עם תוכנות ש"מחייגות הביתה".
  • עבודת בניית Image היא פרויקט שלוקח זמן (זו הסיבה שיצרני חומרה משחררים עדכוני קושחה רק לאחר מספר חודשים) הואיל וישנם דברים רבים שצריך לכוון ולהגדיר לפי הבקשות של הלקוח. בנוסף, אלו בד"כ פרויקטים מתמשכים – הואיל וגוגל משחררת מדי חודש עדכוני אבטחה ויש צורך לבנות עדכון על סמך העדכונים של גוגל. בנוסף, גוגל משחררת גרסאות אנדרואיד חדשות כל שנה ויש צורך לבצע את רוב העבודה מחדש (גירסת Kernel מוחלפת ואז יש צורך לוודא אם הדרייבים מצליחים לפעול או שצריך לחכות לדרייברים חדשים מיצרן החלק הספציפי של החומרה) – בקיצור אם מישהו חושב שזה תהליך שלוקח שבוע, הוא "טיפה" טועה 🙂

לסיכום: אפשר בהחלט לבנות את מערכת ההפעלה למכשירי אנדרואיד מחדש לפי דרישות לקוח, אולם כדאי להתחיל את הפרויקט לפני שמחליטים איזה מכשיר לרכוש ומה צריך שיהיה במכשיר בסוף – ולא להגיע למצב שיש ללקוח 500 מכשירים ועכשיו צריך לבנות להם קושחה חדשה. פרויקטים כאלו דורשים זמן על מנת לבצע אותם (הכוונה זמן שלוקח חודשים, לא שנים, עדכונים לוקח זמן קצר יותר של ימים או שבועות – רוב הזמן בייצור עדכונים הולך על בדיקות תאימות).

כמה מילים על Thin Client ל-Citrix

לא מעט חברות גדולות בארץ משתמשות במערכות Citrix. חברות ביטוח, קופות חולים, רשתות שיווק ועוד ועוד. רובן משתמשות במכונת PC כ-Client וחלקם קונים "קופסאות קטנות" (מותגים) כדי לאפשר עבודה למשתמשים מרחוק. אחד הדברים החשובים ב-Thin Client עבור אותן חברות – הוא ניהול מרכזי. בפוסט זה אני אכתוב לגבי הצד החומרתי של הקופסאות ועל מערכת ההפעלה שנמצאת בקושחה שלהן.

ל-2 סוגי הפתרונות הנ"ל יש יתרון בכך שקל יחסית לנהל אותן, הן מבחינת הגדרות מערכת, והן מבחינת נעילה וכו', אולם ישנן כמה נקודות שכדאי לתת עליהן את הדעת:

  • במקרים של "קופסאות", לא תמיד קיימת האופציה לשדרג קושחה לגירסה חדשה של Client. חלק מהספקים משחררים קושחה עם עדכונים לגרסאות Client חדשות, אולם חלק אחר של הספקים משחררים עדכון רק לדגמים מהשנה, שנה וחצי האחרונות.
  • במקרים רבים, בפתרונות "קופסא" – אתה צריך לסמוך לחלוטין על ספק הקופסא ועל הקושחה שהוא מספק איתה, ולא תמיד היצרן משחרר במהירות עדכוני אבטחה למערכת ההפעלה שרצה על הקופסא.
  • מחירי הקופסאות – לא ממש זולים.

פתרוות של PC שמריץ את ה-Client של Citrix הם פתרונות טובים, אולם מכיוון שזה PC – אתה עדיין צריך לתחזק אותם: דיסקים קשיחים, מאווררים וכמובן שאתה צריך להוסיף אותם למחיר שאתה משדרג מערכת הפעלה, אנטי וירוס ושאר תוכנות שהחברה דורשת כמינימום (גם אם זה PC שרק מריץ Client פשוט).

כיום ישנו גם פתרון שהוא יותר זול.

piלמי שלא מכיר – זהו ה-Raspberry Pi-3 (מודל B). זהו מחשב בגודל קטן מאוד עם כמות זכרון של 1 ג'יגהבייט והוא מריץ מערכת Linux ויש לו גם Client מלא ל-Citrix עם כל הפונקציות פעילות. הוא יכול לשמש בעקרון כ-Thin Client מאוד זול ולהתאים לחברות…

… בערך …

לי אישית בבית היו לי כמה Pi ולוחות אחרים שמריצים דברים שונים (אני מאוד חובב חומרה), אבל פתרון כזה כמו שנראה בתמונה בחיים לא יכנס לחברה. חברות רוצות משהו סגור, עם ניהול מרוכז, משהו יציב שיש לו אבא ואמא..

HDX-READY-Pi

תכירו את Viewsonic SC-T25: זהו המוצר של חברת Viewsonic ובתוכו יש בדיוק את אותו Raspberry Pi-3 Model B, אך כאן מדובר למוצר שמיועד לחברות. יש לו מערכת הפעלה לינוקסאית הכוללת ניהול מרכזי והמכשיר תומך בכל הפונקציות של Citrix. המכשיר ישווק בקרוב במחיר הכרות של 89$ לקופסא (בחו"ל).

מדוע אני ממליץ על הקופסא הזו? מכיוון שהלינוקס שבתוכה ניתן להרחבה ע"י איש/צוות הסיסטם בחברה. קחו לדוגמא מצב פשוט בו משתמש (או משתמשים) לא מצליחים להתחבר. אפשר לנטר את הקופסא מרחוק ולבדוק שיש אליה Ping לדוגמא ובמקרים ויש בעיה, תמיד אפשר לבצע ssh.

דוגמא אחרת שחשובה לאבטחה וקשה לבצע בקופסאות סגורות אחרות: רוב הקופסאות מגיעות עם 4 כניסות USB אבל המשתמש מנצל רק 2 (מקלדת, עכבר) או 3 (כרטיס חכם או מתאם USB->Serial). נשארה כניסה אחת או יותר פתוחה ואנו רוצים לנעול על מנת שהמשתש לא יכניס ציוד לא מורשה. בעזרת סקריפט פשוט (דוגמא: כאן) אפשר לכבות את הכניסות האלו כך שגם אם יוכנס ציוד, המערכת לא "תראה" אותו ולא ניתן יהיה להפעיל אותו, וניתן להוסיף עוד 1001 דברים שירוצו על הקופסא או מחוץ לקופסא כדי להרחיב את השימוש בהתאם לצרכי החברה. (אגב, בקרוב ל-Pi תהיה תמיכת PXE כך שלא יהיה צורך לעדכן שום דבר בקופסא. מכבים, מדליקים, הקופסא מוכנה לשימוש).

נקודה נוספת חשובה: אפשר להרחיב קופסא כזו (ע"י המשתמש, לא היצרן קופסא) לתמוך ב-RDP מלא, אולם כדאי לקחת בחשבון שמיקרוסופט גובה 100$ רשיון על שימוש בקופסא כזו מכיוון שהיא לא מריצה מערכת הפעלה של מיקרוסופט.

לסיכום: שימוש בקופסאות למשתמשים זה טוב ונחמד, אבל במקרים רבים יצרנים לא מספקים עדכוני אבטחה וחלקם גם לא מספיק עדכוני גרסאות. עם קופסא כמו זו שציינתי, השליטה עוברת אליכם. אתם יכולים לקבל עדכונים או להכניס עדכונים ושינויים בעצמכם, קל לנטר את הקופסא וקל לתקן תקלות מרחוק ובנוסף – המחיר די זול. זה לדעתי יכול להיות פתרון מעולה אם אתם רוצים להחליף את ה-PC בקופסא או להחליף קופסאות ישנות.

הבהרה
לי אין קשר ל-Viewsonic או ליבואן ופוסט זה נכתב מהאספקטים של לינוקס, אבטחה וניהול יותר קל של Citrix Clients.

מערכות משובצות: ללכת באופן מסודר

במדינות רבות מכירים את מדינת ישראל מבחינת היי-טק כ"מדינת פטיש ומברג". ה"מנטליות" הידועה היא שישראלים בהיי-טק כשהם מקבלים מוצר, הם יפרקו אותו לגורמים וילמדו כיצד לבנות אותו מחדש או משהו יותר טוב.

במקרים רבים כשזה מגיע לפרויקטים בתחומי Embedded אני רואה דברים שקרובים לזה: מישהו בחברה החליט לרכוש לוח X או טאבלט Y או סמארטפון Z – ועל זה יפתחו את המוצר וכשזה לא עובד (וכן – בהרבה פעמים זה לא עובד), מזמינים את עבדכם הנאמן (או מישהו אחר), מראים לו את הלוח/טאבלט/סמארטפון וכמובן שיש בקשה לעשות איזה "הוקוס פוקוס" ולפתור את זה.

מנסיוני בתחום – כדאי לעשות את הדברים בצורה אחרת לגמרי. נכון, לפעמים יש אילוצי זמן, Time to market וכו', אבל אם ניקח את ההשקעה הכספית בהבאת יועץ חיצוני או מתכנת חיצוני (ב-2 המקרים זה לא זול) בשביל שינסה לעשות משהו שקשה עד בלתי אפשרי לעשות – נראה שבסופו של דבר היה עדיף מלכתחילה לשנות את הדרך ולהתחיל .. הפוך

הדבר הראשון שיש למצוא הוא "מה צריך כח?". לדוגמא – אם הקופסא תשמש כנתב, אז רכיבי הרשת צריכים יחס מיוחד ואסור לסמוך על מה שיצרן ה-SoC נותן בצ'יפ. צריכים לטפל בתעבורה של 1 ג'יגהביט לדוגמא? כדאי וצריך לצייד את הלוח בצ'יפ רשת יעודי (עם שאר החלקים). דוגמא אחרת: צריכים ראיה ממוחשבת שתדע למצוא עצמים במהירות פריימים גבוה? אז אתם צריכים GPU חזק שמגיע ברוב המקרים יחד עם CPU חזק (כדאי לשים לב: במקרים כמו של מעבדי אינטל, לדוגמא סידרת Atom X3/X5/X7 – אתם תקבלו מעבד בהחלט חזק בהשוואה למעבדי ARM בינוניים, אבל בכל מה שקשור ל-GPU, כל מעבד ARM בינוני עם Mali 500 ומעלה עוקף אותו). עוד דוגמא היא עניין המצלמות: מצלמות סיניות פשוטות לא יעשו את העבודה, ומצלמות שמוציאות YUV (ושאר פורמטים קרובים) רק יקטינו את כמות הפריימים שתוכלו לעבד עם תוכנות ראיה ממוחשבת.

גוגל כמובן יכול לסייע רבות במציאת סקירות על לוחות שונים, כדאי למצוא עמודים שמשווים בין מוצרים מתחרים כך שיהיה לכם מושג מי נגד מי וכו'.

הדבר השני והחשוב הוא: לבנות את ה-Image בעצמכם ולא לסמוך על מה שמגיע עם המכשיר. במקרים רבים אתם יכולים לקבל ב-Image חלקים סגורים (קושחה, מודולים בינאריים, וכו'). בלינוקס במקרים רבים יש צורך לעיתים לעבור מגירסת ליבה אחת לגירסת ליבה שניה ולא תמיד מגיעים קבצי "דבק" שיודעים להתאים את המודולים הסגורים לעבוד עם גרסאות ליבה אחרות ולכו תבקשו עזרה מיצרן ציוד סיני שלא ממש מבין אנגלית…

עוד נקודה שרבים שוכחים: לא לרכוש לוח אחד אלא לפחות 2 או יותר. ראיתי מספיק פרויקטים שרצו מצוין על לוח אחד וכשהגיע BATCH – הפרויקט רץ באופן איטי או מוזר עליהם למרות שיש בדיוק את אותם רכיבים בלוח Evaluation ובציוד שאמור להיות סופי. קנו מספר ציודים זהים והשוו שהדברים רצים בצורה זהה.

ונקודה חשובה אחרונה: אל תמצאו ODM/OEM לבד ותחתמו איתו על חוזה. אם יש לכם לוח שאתם לייצר בכמות המונית, פנו ליצרן המעבד ובקשו קישור ביניכם ליצרן כזה, אחד שכמובן דובר אנגלית מקצועית. לפני חתימת הסכם יצור, בקשו לראות עבודות קודמות או הפניות מלקוחות אחרים שלהם. אישית נתקלתי בלא מעט יצרנים סיניים שהוציאו לוחות עם ערימות באגים ופשוט לא היה עם מי לשוחח בקשר לקבלת תיקונים/עדכונים.

לסיכום: אל תזרקו את כספכם על ציוד זול שמצאתם דרך eBay או Ali Express. חפשו אתרים עם השוואות ביצועים בתחום של המערכת שאתם תוציאו. דברו עם יצרן עם המעבד, ודאו שיש לכם אנשי קשר שיודעים אנגלית שוטפת ותמיד כדאי להתייעץ עם מישהו לפני שסוגרים יצור של כמה אלפי מוצרים – לוודא שהדברים אכן מתאימים.

גילוי נאות
כותב שורות אלו נותן שרותי אינטגרציה למערכות משובצות

טיפים לפרויקטים למערכות משובצות

אם יש תחום שהשתנה מאוד בשנים האחרונות, הרי זהו תחום המערכות המשובצות (Embedded). בשנות ה-90 ועד ועד לעשור האחרון, בתחום זה שלטו מערכות קניינות (היי VXWorks!) והמעבדים היו יחסית די חלשים. לינוקס נכנס לתחום בשנות ה-2000 עם כל מיני פתרונות, חלקן קוד פתוח לחלוטין, חלקן מעורבות בחלקים עם קוד סגור והדברים החלו להשתנות באופן רציני במיוחד ב-5 שנים האחרונות.

ישנן בארץ לא מעט חברות שמפתחות פתרונות על מערכות משובצות, אולם נראה כי במקרים רבים חברות לא יודעות או לא מנסות להשתמש בכלים חדשים ויותר מודרניים, ופוסט זה ינסה לשפוך מעט אור על ההתפתחויות האחרונות. (גילוי נאות: כותב שורות אלו בונה גם פתרונות משובצים עוד משנת 2010).

נתחיל עם המעבדים: אם יש משהו אחד שאני רואה בחברות רבות בשימוש – זה לוחות מבוססים I.MX של NXP (לשעבר Freescale זכרונה לברכה). מעבד זה הוא מעבד כלל לא רע והוא מעולה בפתרונות לוידאו, אך כיום ישנם לא מעט פתרונות מחברות מתחרות שונות שלא רק נותנות את מה ש-I.MX (כולל דור אחרון) נותנים, הם נותנים גם ביצועים יותר טובים וגם מחיר יותר טוב (תלוי כמובן בכמות המוזמנת). מעבדים של סמסונג, קוואלקום, Rockchip, Texas Instruments, Amologic ואחרות מציעות מעבדי ARM שונים בין אם מדובר ב-32 או 64 ביט, עם תמיכה לציודים שונים, כולל התקנים חדשים (כמו פתרונות Wifi בסטנדרטים האחרונים).

בעבר, השגת לוח Evaluation היתה עסק לא כל כך קל ולא תמיד זול. אם היית עובד בשת"פ עם יצרן מעבדים כזה, אז השגת לוחות היתה הבעיה האחרונה שלך והיית מקבל במהירות ובשליחות אקספרס ערימה של לוחות מבלי לשלם אגורה שחוקה. אם לעומת זאת היית סטארט אפ, היית צריך לשלם כמה מאות דולרים פר לוח. זה לא הרבה לחברה גדולה, זה קצת מעיק לסטארט אפ קטן או לאינדיבידואלים שמתכננים את הפרויקט שלהם.

כיום לעומת זאת, התחרות מ-ט-ו-ר-פ-ת! ה-Raspberry Pi יצא במחיר מגוחך של 35$ והמתחרים הגיבו בהתאם, וכיום אפשר להשיג לוחות עם מעבדים ברמות שונות בפחות מ-150$ (בקצה הגבוה) ללוח שכולל את המעבד, זכרון, כניסות ויציאות ועוד. אף אחד לא האמין שנגיע לסיטואציה הזו.

מה שמוביל לסיטואציה המעניינת הבאה שעדיין נראית בחברות רבות: שימוש בכלים ישנים. כיום כל מפתח מערכת משובצת נעזר ב-PC כדי לקמפל את הקוד ל-ARM על ה-PC ולהריץ את הקוד על הלוח, אולם רבים שוכחים שגם כלי הבניה השתנו מאוד לאחרונה (במיוחד ב-4 שנים האחרונות). ישנן עדיין חברות שמשתמשות ב-LTIB בשביל לקמפל (למרות שהכלי כבר מת)

אבל כיום ישנה דרך אחרת שכדאי לתת את הדעת עליה: אם אתם מכינים את המוצר שלכם, סביר להניח שניסיתם אותו בסביבת לינוקס על PC בשלב ה-PoC, וזה מעולה, אבל במקום להתחיל לעבוד על Yocto, אני ממליץ ללכת בדרך אחרת: לרוב המעבדים המודרניים (מבוססי ARM) יש היום גירסת לינוקס כמו אובונטו שקומפלה לאותו מעבד (אם אין, אפשר לבנות עבורכם. צרו קשר). קחו את ה-IMAGE הזה, התקינו אותו על כרטיס מיקרו SD (לפחות Class 10 או U1) והריצו את הלינוקס הזה על הלוח ואז התקינו את מוצרכם על אותו אובונטו שרץ על ה-ARM. זה יתן לכם מושג כללי איך המוצר שלכם רץ על מערכת משובצת. יכול להיות שזה יהיה קצת יותר איטי מבניה מצומצמת (עם Yocto ועל השאר תיכף ארחיב) – אבל זה יכול לתת לכם מושג אם זה רץ ואיך, ולמפתחים זה יכול לעשות את החיים יותר קלים אם הם אינם מכירים לינוקס לעומק בצורה מעולה – כי זה נראה בדיוק כמו דסקטופ לינוקס.

אחרי שהמוצר שלכם רץ על אובונטו מבוסס ARM – יגיע הזמן להתחיל לבנות את ה-IMAGE שאותו תתקינו על ה-eMMC שנמצא על הלוח. כאן מומלץ בשלב ראשון אם אתם עדיין משתמשים ב-LTIB – לצאת לגמרי מהכלי הזה (שוב, הוא מת). אם אתם משתמשים ב-Yocto לבנות Image (עם או בלי ה-BSP של היצרן) הגיע הזמן גם לבדוק חלק נוסף שנקרא Open Embedded – כיום שתיהם משולבים והיתרון הגדול של OE הוא כמות נוספת (ולעיתים נחוצה) של "מתכונים" המאפשרים הוספת חבילות חדשות בעת יצירת ה-Image, שלא לדבר על היתרון הגדול של הכלי smart שנמצא ב-Yocto שמאפשר לכם לבנות עדכונים חלקיים (הן כ-RPM או APT או IPK או OPKG) כך שכשמוצאים חור אבטחה באחת מהחבילות, סקריפט פשוט בתוך המערכת המשובצת שאתם בונים יכול להוריד מהשרתים שלכם עדכון חבילה ספציפית ושימוש ב-smart יכול להתקין את החבילה – וכך אין צורך להוציא IMAGE שלם בגלל חור אבטחה.

כלי נוסף שכדאי להתאמן עליו ולהכיר לעומק (במיוחד ל-IoT) הוא Buildroot – שמאפשר לכם לבנות Image שלם והכל מתוך תפריט המאפשר בחירת חלקים שונים שאתם זקוקים. כך יוצא Image קטן (יחסית) שכולל את הכל, וכך יש גם פחות חורי אבטחה פוטנציאליים, וגם קל להעביר את הפרויקט לפלטפורמות אחרות ומעבדים אחרים והוא גם קל מאוד לשימוש ע"י אנשים שמכירים את הצ'יפים אך אינם מכירים לעומק את עולם הלינוקס.

עוד כלי שכדאי להכיר (ולהפתעתי עוד לא פגשתי חברות שמשתמשות בו) זה Docker לבניית Images. מדוע? כשמריצים Yocto, אין אפשרות להריץ מספר סשנים של Bakebit. לעומת זאת, עם טכנולוגיית קונטיינרים כמו Docker אפשר בהחלט להקים כמה קונטיינרים ולהריץ בכל אחד מהם Bakebit, זה יכול מאוד לסייע אם מקמפלים קוד לכמה מעבדים או לכמה מטרות (Targets) שונות. יתרון נוסף של Docker זה שהכל רץ במהירות טבעית ויש אפשרות מובנית לשיתוף תיקיות (כמו תיקיית Cache ל-Yocto. אגב, טיפ קטן לאלו שצריכים לעבוד המון עם Yocto – להריץ bitbake world בפעם הראשונה, עדיף לעשות זאת בסופ"ש או בלילה לפני שיוצאים – וכך יהיה לכם Cache שיעזור "לאפות" דברים יותר מהר).

נקודה אחרונה שאני מעוניין להתייחס אליה היא נקודת ה"חסכנות" שקיימת בחברות רבות שרוצות שהמהנדס שבונה את הדרייברים/אלגוריתמים – גם יכין את ה-Image הלינוקסי, גם יכין פתרונות עדכון ועוד ועוד, ולצערי כאן יש פספוס רציני (ולעיתים התוצאות בהתאם, אני יכול להראות לכם ערימות של מודמים מלאי חורי אבטחה, פרוצדורות עדכון תמוהות ועוד).

אין לי ספק שאנשי פיתוח אלגוריתמים ודרייברים הם אנשים חכמים ומוכשרים, אבל במקרים רבים אין להם את הידע שצריך "מסביב". כך לדוגמא, אם יש צורך בכך שהמערכת תציע ממשק Web, ישנם כמה פתרונות. לפעמים יש צורך להציג גרפיקה, ויש הבדל ענקי בין להוסיף Xorg ל-Image או להסתפק ב-Frame Buffer, וישנן עוד מאות דוגמאות שאיש לינוקס רציני יכול להמליץ להוסיף/להחליף במקום פתרון ברירת מחדל (שאחר כך יכול להתגלות כחור אבטחה ענק או כחבילה שלא מתוחזקת ע"י המפתח שלה כבר שנים). לכן, המלצתי היא דווקא במקרים של פרוייקטים משובצים לפצל את המשרה ל-2. תנו למפתח לעשות את עבודתו המקצועית ותנו לאיש הלינוקס לבנות את השאר, בדיוק כמו שתיקחו גרפיקאי ומעצב UX לעצב לכם את הממשק Web ולא תסמכו על המתכנת שיעצב לכם את הממשק.

לסיכום: כדאי להכיר את המעבדים החדשים, כדאי לקנות לוחות (הם זולים!) וכדאי בשלב הראשון להתקין הפצת לינוקס רגילה על הלוח המשובץ כדי שתוכלו לבנות PoC טוב – עוד לפני שאתם מתקרבים לכלים לפיתוח/הכנה של Image למערכת המשובצת. כדאי להתעדכן גם בכלים שיש וגם מומלץ כמה שפחות להיות תלותיים בפתרונות (וגם ספריות) בקוד סגור. מומלץ לא "לזרוק" את כל עבודת הפרויקט על מפתח הדרייברים/אלגוריתמים ולסיום – כדאי לעבוד עם כלים שמאפשרים עדכונים חלקיים במקום לשחרר Image חדש כל פעם שמתגלה חור אבטחה או מעדכנים תכונות מסויימות.