תכירו את IPFS

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

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

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

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

לפתרון קוראים IPFS, והפתרון הזה שואב השראה הן מ-BitCoin והן מה-Bittorrent. אפשר לקרוא את הפרטים הטכניים ואיך להשתמש בזה כאן.

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

עם IPFS, הדברים שונים. אם לדוגמא מאן דהוא רוצה להעלות קובץ WORD או קובץ PDF או קובץ HTML (לא ניתן להשתמש ב-PHP או שפות אחרות ולא ניתן להעלות קבצים או תוכן דינמי) או תמונות. מהרגע שמשתמשים ב-Client להעלות תכנים, התוכנה יוצרת שורת טקסט שנקראת hash. ה-hash הזה מייצג בעצם היכן נמצא התוכן. ב-IPFS כל התוכן מבוזר בשיטת Peer to peer (כמו ביטורנט), כך שהורדה של מכונה שמאחסנת את התוכן לא תעזור מכיוון שהחומר נמצא במכונות אחרים שמארחים תוכן IPFS. הגולשים המעוניינים לגשת לתוכן, יכולים להשתמש באחד משרתי ה-Gateway כדי לקבל את התוכן. לדוגמא: אם נכנסים לכתובת https://ipfs.io/ipfs, יש להזין בסוף את ה-hash שקיבלנו (לדוגמא: https://ipfs.io/ipfs/Qmaisz6NMhDB51cCvNWa1GMS7LU1pAxdF4Ld6Ft9kZEP2a ) ואז נקבל את התוכן. אם מישהו ינסה דרך בית המשפט לחסום לדוגמא את הכתובת ipfs.io, אז לצערו של התובע יש עשרות Gateways ורק לאחרונה גם Cloudflare החליטה להיכנס לתחום ה-IPFS והם מציעים Gateway משלהם, כך שלהסיר תכנים זה כמעט בלתי אפשרי. כמובן ש-IPFS זה סיוט ענק ליצרני תכנים מסחריים (סרטים, סדרות, תוכנות מסחריות) אבל סביר להניח שהם ינסו לנקוט בשיטת ה"תבע את המוריד תכנים".

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

רוצים דוגמא? הנה תמונה שהעליתי ל-IPFS. לחצו על הלינק כאן.

תקלות בפלאפון ומה כולם יכולים ללמוד מכך

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

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

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

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

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

בעבר הרחוק, אמצעי העזר שעמדו לרשותך היו קבצי TAR (בלינוקס, יוניקס) שהכנת לפני השדרוג (אם כמובן גיבית את הכל והתוכנה לא זורקת איזה קובץ so באיזה חור נידח והוא לא כלול בקובץ TAR) או גיבוי לקלטת. עם מערכות Solaris היה אפשר להשתמש ב-Veritas Volume Manager כדי ליצור Snapshot, בלינוקס בזמנו היה LVM אבל לא היה Snapshot וב-Windows (לפני שנות ה-2000) המצב לא היה טוב יותר.

עכשיו ב-2018 דברים השתנו. הרוב רץ על VM כיום אז אין בעיה ליצור Snapshot לכל המכונות המושפעות משדרוג ואם יש תקלה, אפשר לחזור אחורה. כל DB מאפשר לעשות dump שבמקרה הצורך ניתן לשחזרו, ובכל מערכת DR ניתן לעשות את הסינכרון הדו כיווני המתמשך כשעושים עבודת שדרוג.

כיום, גם מבחינת מערכות ההפעלה השדרוגים יותר נוחים. בתחום הלינוקס, כל מערכת ניהול חבילות מאפשרת שדרוג ושנמוך בקלות, וב-Windows אתה יכול לעשות Blacklist ל-KB מסויימים שה-QA של מיקרוסופט, כרגיל, עשה עבודה גרועה בבדיקת תאימות ושחררו זאת בכל זאת.

לכן, שדרוגים לא צריכים רק להיבדק רק על המכונה (או על רפליקציה של המכונה ב-LAB) אלא גם על המכונות שמושפעות מכך, ויש צורך לעשות גיבוי או snapshot לכל דבר שמושפע, כך שאם רכיב מסויים דופק דברים, צריך לעשות rollback לא רק לרכיב, אלא גם למכונות שהושפעו מכך (אם הושפעו). Snapshot, אני מעוניין להזכיר, שומר רק את ה-Delta (שינויים) בין המצב של המערכת לפני ה-Snapshot ולמצב הנוכחי, כך שלא מדובר במקום רב בדיסק, כך שאין צורך לחשוש לגבי מקום בדיסק בגלל Snapshot (כמובן שמומלץ כמה ימים אחרי השדרוג לבטל את ה-Snapshot ואם צריך לשחזר – להשתמש בגיבוי).

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