ארכיון חודשי: יולי 2014

אפצ'י מפסיק לפעמים להגיב לבקשות בצורה רנדומאלית

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

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

הגעתי אל המשרדים של השותף, במטרה ליום שלם של מחקר בנושא. ובאיזשהו שלב, גם הצלחתי לשחזר את הבעיה – ובעיה זו היתה מאוד קשה לשחזר, ולמעשה רק אחרי הצהריים הצלחתי להגיע אליה, למרות שהתחלתי את המחקר ב9 בבוקר.

הפעלתי wireshark, וגיליתי כי three way handshake אינו מתבצע עד הסוף, ולמעשה ה ACK האחרון לא נשלח חזרה על ידי השרת (ה wireshark היה על השרת עצמו).
יש מספר נסיונות שליחה של לחיצת היד, ובסוף יש RST על הבקשה כי לא ניתן היה ליצור קשר, והבקשה התנתקה.

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

בנתיים דיברתי עם בוריס, והוא הצליח למצוא קישור מעניין שמדבר כי אפצ'י בברירת המחדל מגיע עם דגל של TCP_DEFER_ACCEPT. עד כמה שאני מבין, הדגל הזה אומר לשרת לא לחכות ל three way handshake, אלא במידה ונשלח מידע אחרי החיבור הראשוני, כשעוד אין ACK, אלא רק SYN-ACK, ניתן כבר לקבל את המידע, ולמעשה רק כשהוא יסתיים להישלח, ישלח גם ה ACK.

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

בשביל לכבות את הדגל בחיבור, צריך לשים ב httpd.conf הראשי, את הקוד הבא:

 AcceptFilter http none

במידה ויש הגדרה אחרת בנושא, למשל עם data, יש לשכתב אותה לnone.
וזה מכבה למעשה את הדגל של TCP_DEFER_ACCEPT ועכשיו אפצ'י חייב לחכות ללחיצת היד כמו שצריך לפני שיוכל לנתח את מה שנשלח.

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

 

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

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

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

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

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

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

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

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

 

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

NaCl, Sodium והצפנה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כנס אלטרנטיבי לאוגוסט פנגווין

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

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

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

  • אנשים שיסיעו לארגן
  • מרצים
  • יצירת גרפיקה ואתר לכנס
  • סיוע בתמלול ההרצאות לאנשים עם מוגבלויות שונות כדוגמת חרשים
  • צילום ההרצאות
  • סיוע ביצירת נגישות להרצאות – בכל מה שניתן
  • סיוע בפרסום
  • להגיע לכנס 🙂

עריכה: אתר הכנס
ניתן ליצור קשר עם "חתול" – אחד המארגנים.

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

פוסטים נוספים בנושא:

node.js כן או לא ?

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

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

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

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

אמנם node.js לא משתמש ב webkit או ב blink, אבל הוא יוצר לי בעיות קשות:

  1. האם v8 ישאר גם מחר ?
  2. האם יהיה fork ?
  3. האם הוא ימשיך להיתמך ?
  4. האם הכיון שלו כיום ישאר, או אולי ישוכתב/ישתנה לגמרי בגרסאות חדשות יותר ?

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

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

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

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

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

סליחה, יש לכם אולי זמן ללמוד טכנולוגיה חדשה ?

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

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

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

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

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

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

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

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

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

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