קטגוריה: Ruby

מימוש RDP טבעי בשפת רובי

על רגל אחת, RDP הם ראשי תיבות של Remote Desktop Protocol. אך השם מעט מטעה. זוהי למעשה אסופה של הרבה מאוד פרוטוקולים, חלקם אפילו לא של מיקרוסופט, אלא של ארגון ITU. למעשה הוא מבוסס על סדרה של פרוטוקולים שהחלו את דרכם בארגון ה ITU אשר נועדו לאפשר לתוכנות לשתף מידע ותכנים בניהם.

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

כל זה נעשה תחת מערכת שמבצעת הזדהות מול מערכת כדוגמת Active Directory בפרוטוקולים כדוגמת NTLM ו spnego, אשר האחרון, הוא מימוש הזדהות התומך גם בקרברוס למשל, כאשר התעבורה אמורה להיות מוצפנת בגישות שונות, בהתאם לתמיכה של שני הצדדים. על כל זה מופעל סוג של compression למידע.

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

כל מי שהנושא מעניין אותו, מוזמן כמובן לגשת לפרויקט, וכמובן שאשמח גם לקבל תרומות קוד מאחרים 🙂

כתובת הפרויקט: https://github.com/Safe-T/rdp-rb

פיתון מול רובי, לא מה שחשבתם

הקדמה

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

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

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

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

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

שאלה ראשונה

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

a = 10.times.select{ |x| x % 2 == 0 }
a
=> [0, 2, 4, 6, 8]

זהו, זה כל מה שצריך, שורה אחת 🙂
אסביר אותה בקצרה. ברובי כל דבר הוא אובייקט, אין כזה דבר משהו שהוא "פרימיטיבי" (בהשוואה לג'אווה למשל).
מספר שלם "רגיל", הוא אובייקט מסוג Fixnum. יש לו מתודה אשר מקבלת ירושה ממחלקת האב – Integer בשם times, אשר מבצעת כמות הפעמים של המספר המבוקש איטרציה.
במידה ולא יוצרים block או proc בשביל לרוץ כמניית האיטרציה, חוזרת לנו מחלקה מסוג Enumerator אשר היא מחלקת בסיס לדברים בעלי יכולת מנייה (כדוגמת מערכים). במחלקת ה Enumerator ישנה מתודה בשם select, המאפשרת להגדיר אילו ערכים באיטרציה כלשהי יחזרו אלי כמערך, כאשר אני יצרתי כאן למעשה proc עם הוראות.
היות וברובי השורה האחרונה בהכרח תמיד חוזרת (אם אין explicit return), אז הוא יודע שכאשר יש מספר זוגי, אז אני רוצה שזה הערך אשר יחזור אלי.
עכשיו הנה משהו מעניין על רובי תוך כדי ההסבר – אין ברובי אופרטורים. כל מה שנראה כאופרטור (כדוגמת חילוק השארית ופעולת השוויון), הם למעשה מתודות, ולכן מתודה כדוגמת even?‎ זהה למה שהייתי צריך, ויתר מזה, אין צורך בסוגריים, ולכן זה יכול גם להראות כך:

a = 10.times.select{ |x| x.even? }
a
=> [0, 2, 4, 6, 8]

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

שאלה ראשונה – תת שאלה

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

a = []
10.times do |i|
  a.push(i) if i.even?
  puts a.inspect
end

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

ובנוסף, לרובי גם יש תמיכה בשני תחבירים של משפט טרינארי אשר שם נפל השואל:

i = 1
a = if i.even? then 't' else 'f' end
b = i.even? ? 't' : 'f'

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

c = unless i.even? then 'f' else 't' end

שאלה שניה

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

a = [1, 2, ['a', 'b', [0xa, 0xb] ]]
=> [1, 2, ["a", "b", [10, 11]]]
a.flatten
=> [1, 2, "a", "b", 10, 11]

קצת הארכתי את הקוד, אשר יכול להיות בשורה אחת בלבד, אך רציתי להדגים את הערך שיחזור אלי.

כפי שכתבתי בתשובה לשאלה הראשונה, מערך ברובי, יורש מ Enumerable, אבל יש לו גם הרבה מתודות משל עצמו.
מתודה אחת כזו היא flatten, אשר עושה בדיוק את מה שאותו בחור ביקש.
המתודה יכולה להגיע גם בעוד צורה בשם flatten!‎ אשר התפקיד שלה הוא זהה, עם שינוי קטן אחד – היא לא מחזירה מערך חדש בלי לגעת בקיים (כפי ש flatten עושה), אלא היא משנה את המערך הקיים וחוזרת עם אובייקט המערך עצמו.

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

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

שאלה שלישית

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

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

str1 = 'yoyo'
print 'sdfsdfsfsdfsfsdf' if str1.eql?('aaaaa') || str1 == 'yopo' || str1 === 'yoyo'

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

שאלה רביעית

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

require 'open-uri'

image = open('https://www.google.com/images/srpr/logo11w.png')
open('/tmp/image.png', 'wb+') { |a| a.write(image.read) }
image.close

קצת פירקתי את הדברים לקריאות.
אני טוען את הספרייה open-uri, אשר תפקידה הוא לדעת לפתוח קישורים של ftp, http ו https כאילו היו file descriptor של רובי.

אני במקרה הזה ניגש לקובץ תמונה של גוגל, ושומר אותו כקובץ בינארי בספריית /tmp/ .
שימו לב כי אינני סוגר את הקובץ תמונה שאני שומר בדיסק, והוא נסגר לבד, בזכות פעולת ה proc, אשר בעצם מתבצעת "מאחורי הקלעים" באמצעות yield. וכאשר פקודה זו מסתיימת, הפונקציה של open סוגרת את עצמה לבד.

סיכום

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

recursive tail

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

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

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

אבל יש בעיה עם רקורסיות – כל פעם כאשר קוראים לפונקציה, נוסף stack frame חדש לקריאה הזו.
כלומר יש לי מספר עותקים של הפונקציה באוויר עם זיכרון במיוחד עבורה.

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

הגישה המוכרת ביותר לכך נקראת tail recursion. או רקורסיית זנב בעברית טכנית.

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

מה הכוונה? אשתמש בקוד רובי (שהוא לדעתי קריא מאוד) לשם כך.

רקורסיה בגישה ה"רגילה" תהיה כתובה כך:

def recursive(n)
  if n <= 1
    1
   else
     n * recursive(n - 1)
   end
end

recursive(4)
=> 24

רקורסיית זנב, תראה כך:

def tail_recursive(current, n, result)
  return result if current <= n

  new_result = result * current
  tail_recursive(current + 1, n, new_result)
end

tail_recursive(1, 4, 1)
=> 24

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

אבל לא הכל ורוד בזה. קשה יותר לדבג בעיות ברקורסיית זנב, היות ולמעשה אין לנו stack frames רבים, שיהיה ניתן להבין באיזה שלב יש בעיה. ובכך אין לנו stack trace שיסייע לנו בנושא.

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

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

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

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

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

לאחר טעינת התלויות, אני טוען קובץ בודד בשם app.rb שהוא בעצם מה שמנהל את האפליקציה שלי. אך במקום להשתמש ב require "רגיל", אני משתמש בפונקציה בשם require_relative, אשר מאפשרת לטעון דברים מהמיקום הנוכחי של הקובץ המנסה לטעון אותה.

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

למערכת שיצרתי ישנם שני מצבים – מערכת לדיבוג REST, ומערכת "בדיקות" אשר עליה אפשר לבדוק שדברים עובדים, והיא בעיקר על תקן "echo" כלשהו.

את המערכת של יצירת המסכים, ושליחת ה REST, יצרתי בקובץ rest.rb, והכל מאוגד שם.
יש שם משהו שהולך לעבור למקום אחר בקרוב, וזה מספר מתודות לסיוע בפעולות.

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

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

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

ההגדרות של puma, נמצאות תחת config, וכפי שניתן לראות את הקובץ הראשי והחשוב, הוא גם יודע לבנות לעצמו מבנה ספריות במידה והן לא קיימות, דבר שהוספתי לקוד עצמו. הוא כרגע מכוון למצב של development, ולכן יש לשנות קצת הגדרות בשביל שזה יעבור למצב production.

אתם מוזמנים לבצע fork, לשחק עם הקוד וגם להחזיק לי תיקונים ותוספות.

שינוי פורמט לוג של Rack, והסתרת אזהרות ברובי

יש לי מערכת העובדת עם Sinatra, unicorn ו nginx ביחד.

הבעיה היא, ש nginx נמצא בראש, והוא מעביר את הבקשה ל unicorn, אני מקבל את כתובת ה ip בלוג של ה nginx ולא של הפונה המקורי, ורציתי לשנות את זה, שאראה את הכתובת של הפונה, ולא של nginx.

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

# ... 
# snips 
# ...

# Overriding the original constant
FORMAT = %{%s - %s [%s] "%s %s%s %s" %d %s %0.4f\n}

# ... 
# snips 
# ...

def log(env, status, header, began_at)
  now = Time.now
  length = extract_content_length(header)

  logger = @logger || env['rack.errors']
  logger.write FORMAT % [
    # adding IP
    env['HTTP_X_REAL_IP'] || env['HTTP_X_FORWARDED_FOR'] || 
    env["REMOTE_ADDR"] || "-",
    env["REMOTE_USER"] || "-",
    now.strftime("%d/%m/%Y %H:%M:%S"),
    env["REQUEST_METHOD"],
    env["PATH_INFO"],
    env["QUERY_STRING"].empty? ? "" : "?"+env["QUERY_STRING"],
    env["HTTP_VERSION"],
    status.to_s[0..3],
    length,
    now - began_at 
  ]
end

# ...
# snips 
# ...

רוב הקוד לא מעניין, כי זה בעצם להשתמש בקוד קיים, אבל log מעניין אותנו, ולכן אני מציג רק אותו.
ברירת המחדל אומרת לספק את REMOTE_ADDR, אבל זו הכתובת של nginx.
אז ב nginx יצרתי הדר שאני מעביר את הפניה המקורית. השם שלו קיבל את השם HTTP_X_REAL_IP. ככה בחרתי.
יצרתי אותו בצורה הבאה:

proxy_set_header        X-Real-IP       $remote_addr;

במידה והוא אינו קיים, אני מנסה לבדוק האם HTTP_X_FORWARDED_FOR קיים, במידה ולא, אז אנסה את מזלי עם REMOTE_IP, ואם זה גם לא, אז אין IP.

במידה ותריצו את זה, תגלו אבל בעיה חדשה – הודעת אזהרה ש FORMAT כבר הוגדר:

warning: already initialized constant Rack::CommonLogger::FORMAT
/home/ik/.gem/ruby/2.0.0/gems/rack-1.5.2/lib/rack/commonlogger.rb:24: warning: previous definition of FORMAT was here

אז מצאתי להודעה הזו פתרון נחמד ופשוט:

module Kernel
  def suppress_warnings
    original_verbosity = $VERBOSE
    $VERBOSE = nil
    result = yield
    $VERBOSE = original_verbosity
    return result
  end
end

והשימוש בו יהיה בצורה הבאה:

module Rack
  class CommonLogger
    Kernel::suppress_warnings do
      # Overriding the original constant
      FORMAT = %{%s - %s [%s] "%s %s%s %s" %d %s %0.4f\n}
    end

    def initialize(app, logger=nil)
...

ועכשיו לא נקבל על כך הודעה, היות ואנחנו מודעים לכך שאנחנו מבצעים את הפעולה, היות והיא נעשת במודע, ואנחנו מעוניינים בה.

הקוד המלא נמצא כאן.

גו – השלמתה של שפה

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

למשל יכול להיות שרת ג'ינטו מ 2007 (שלא התעדכנה) ומערכת פדורה 20, שהמערכת צריכה לרוץ על שניהם.

אפשר כמובן להשתמש בשפות כמו רובי לצורך העניין, ואז rbenv או rvm, אבל זה סרבול וכאב ראש.
או אפשר לקחת שפות כמו פסקל וgo וליצור קובץ ריצה סטטי שבהכרח יעבוד על המערכות השונות.

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

אני החלטתי ללכת על Go, היות ויש לה מספר כלים שלא רציתי לפתח בפסקל שהם חסרים לי.

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

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

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

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

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

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

ענב הזעם – API

ברובי, הדבר הכי מוכר ביקום הוא framework בשם Rails, אשר מאפשר ליצור אתרים דינאמיים בצד השרת.

ישנם עוד מספר סוגי framework עבור עולם ה web, בהם Sinatra, שאני משתמש המון, ולאחרונה התחלתי לשחק גם עם framework מאוד מעניין שנקרא grape.

Grape הוא framework אשר נועד לתת לנו כלי לפיתוח API. זה אומר שכל הפיטצ'רים שלו הם על טהרת REST ואין שום דבר הקשור להצגת templates למשל בצד המשתמש.

כלומר ניתן להציג xml, json או כל מבנה אחר של מידע, אבל זה לא נועד ליצור אתר, אלא להחזיר מידע, או לבצע פעולות API.

הנה הדגמה קלה כיצד תראה תוכנית שכזו: להמשיך לקרוא

סידור תיבות דואר

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

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

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

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

  • חיפוש תתי ספריות ברקורסיה
  • איטרציה על קבצים
  • ביצוע פילטר על תוכן במערך
  • יצירת ספריות
  • העתקת תוכן של ספריות בצורה רקורסיבית

עוד מערכת לדיווח על אזעקות

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

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

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

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

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

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

לגבי כתיבה של גרסת Go כרגע ירדתי ממנה, אולי אבל אחזור ואצור משהו בנוסף, רק כהוכחת יכולת עבור עצמי.

 

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

מערכת פשוטה לשיתוף קבצים פנים ארגונית

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

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

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

אז החלטתי כי במקום להמשיך ולחפש תוכנה, אכתוב משהו פשוט שיעשה את זה, ותוך שעה וחצי, כולל דיבוג כתבתי את simple file sharing – גרסת mercurial וגרסת git.
זהו מנוע פשוט, הכתוב ברובי עם סינטרה ללא javascript שאני כתבתי, אלא cgi מול html/css פשוטים מאוד מבוססי foundation.

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

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

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