פורסם ב

DealExtreme

חבר הראה לי אתה מעניין לפני כמה חודשים: DealExtreme.

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

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

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

שווה בדיקה.

פורסם ב

שרת דואר חדש

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

אם לשפוט על פי התאריך של ההודעה הישנה ביותר בשרת הדואר שלי – את שרת הדואר שרץ בסלון הגדרתי בספטמבר 2005, מאז שדרגתי את המחשב שלו שלוש פעמים, אבל שרת הדואר נשאר וצבר דואר לרוב.
גם בפעם האחרונה השתמשתי באותו בהוראות מworkaround, אבל מאז הטוטוריאל השתנה כמובן, לא שזה מאוד משנה כי אחרי שלוש וחצי שנים לא ממש זכרתי איך זה הולך.
אחד הדברים שלא הוזכרו שם הוא שההודעות נשמרות בתיבת הדואר כקבצים – והשם שלהם מכיל את שם המכונה המקומית.
מכיוון שהשם של השרת השתנה, הייתי צריך לשנות את השמות של עשרות אלפי הקבצים מקבצים עם שמות כמו:
[code]
1234429393.V832I86d1dfM880219.home.firefang.net:2,RS
[/code]
לקבצים עם שמות כמו:
[code]
1234429393.V832I86d1dfM880219.flux.firefang.net:2,RS
[/code]

הדרך לעשות את זה בקלות היא בעזרת קומבינציה של find וmmv.
השמשתי בfind כדי למציא את כל הספריות ולהפעיל על כל ספריה פקודת mmv שתסדר את שמות הקבצים:
[code]
find -type d -exec mmv "{}/*home.firefang.net*" "{}/#1flux.firefang.net#2" \;
[/code]

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

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

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

מי שמעוניין יכול לפנות במייל (omry a@t yadan.net).

פורסם ב

העוקץ העיראקי

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

I want to move my family out of Iraq due to violence and I want to transfer
$12,500,000 to you.reply

פורסם ב

הרשת כמרקחה

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

נכנסתי לגוגל כהרגלי, חיפשתי את האתר של הלו דולי, וחשכו עיניי: האתר הפך לאתר רושעה!.

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

חשבתי שפרצו לי למחשב שוב!

העיתונאים החרוצים אף לקחו תמונת מסך של הפלא:

ואני שואל, למי איכפת? אז היתה טעות, תשיגו חיים.

פורסם ב

גוגל וM-Labs שחררו מכשירים לבדיקת מהירות הרשת

גוגל וM-Labs שחררו סט כלים שנועדו לבדוק אם ספק האינטרנט שלכם משחק משחקים מלוכלכים מאחורי גבכם.
בין היתר, הכלי יבדוק הורדת ביט-טורנט מול הורדת HTTP מכמה שרתים ברחבי העולם, וידע לזהות אם הספק שלכם פוגע בתקשורת של ישומים שמשתמשים בפרוטוקול הביט-טורנט.
מזכיר קצת את מה שהצעתי לפני שנה וחצי:
שגוף ניטראלי יקיים בדיקות מהירות (אוטומטיות) לכל אחת מספקי הרשת ויציג את התוצאות במקום מרוכז.
נשאלת השאלה, מה ימנע מספקי האינטרנט (שלא נודעו במיוחד בהגינות ובמשחק ההוגן לתעדף ספציפית את שרתי הבדיקה).
שאלה טובה.
M-Labs, המפתחים של הכלים ישחררו אותם ברשיון קוד פתוח ויעודדו אנשים להריץ אותם על שרתים משלהם.
אם זה יקרה, אנשים יוכלו לבצע את הבדיקות מול שרתים 'אנונימיים' שספקי האינטרנט שלהם לא תעדפו.

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

כצפוי, מקורות (אנונימיים) מתחום הISP כבר מכינים מאגר תרוצים למכירה למשתמשים עצבניים:

However, one ISP industry source, who asked not to be identified, questioned whether the tools would accurately point to the cause of broadband problems. Spyware or malware on computers can affect browser performance, and problems with the wider Internet can cause slowdowns, the source said.

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

פורסם ב

כלים לתחזוקת שרתים שוטפת

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


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

למשל, מונית יכולה

  • לוודא שהמקום הפנוי בהרדיסק לא יורד מתחת לרמה מסויימת
  • לוודא ששרת הApache לא תופס יותר מדי משאבים,ולהפעיל אותו מחדש אם הוא כן
  • לוודא שמכונה מסויימת עונה לפינגים, לחיבורי TCP או לחיבורי HTTP
  • לוודא שתהליך מסויים רץ, ולהפעיל אותו אם הוא לא (תחשבו על שרת SSH שקרס)

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

Munin:
"הוגין ומונין הם העורבים של אודין האל הנורדי, הם עפו בשבילו במידגארד, רואים וזוכרים – ואז סיפרו לו מה הם ראו".
מונין זה זכרון.

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

  • עומס על הCPU
  • צריכת זכרון
  • שגיאות בממשק הרשת
  • תעבורת רשת
  • אימיילים שתקועים בתור היוצא בשרת הדואר

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

אפשר לראות את מונין בפעולה כאן.

Puppet
Puppet, להלן פאפט, הוא כלי לניהול מרכזי של כמה שרתים.
פאפט מאפשר להגדיר את השרתים ממקום אחד, ולדאוג שהם ישארו מעודכנים, יתקינו חבילות מסויימות, יעתיקו קבצים מסויימים, ובעצם כמעט כל דבר שתרצו.
השימוש בפאפט הוא יחסית מורכב, והוא הופך למשתלם אם יש לכם כמה שרתים עם תצורה זהה או דומה, שמשתנים בצורה די תכופה (כאשר התצורה שלהם צריכה להשאר מסונכרנת).
עקומת הלמידה של פאפט די תלולה, ולא קל להתחיל להשתמש בו, אבל מצד שני – יש לפאפט ערוץ IRC מאוד מועיל בfreenode.
כמו רוב הכלים שהזכרתי, פאפט מבוסס גם הוא על מתודולגית שרת-לקוח. השרת – puppetmaster אחראי על העברת הגדרות התצורה ללקוחות. על כל מחשב רץ לקוח שאחראי לישם את ההגדרות שמגיעות מהשרת.
כאמור, פאפט מאוד גמיש. ההגדרות שלו נקבעות בקבצים בשפה הצהרתית מיוחדת. ככה נראה קובץ פאפט שכתבתי שמפעיל פיירוואל מבוסס iPKungFu (תסריט להגדרה נוחה של iptables) על מכונה מסויימת:
[code lang="bash"]
class firewalled {

package{["ipkungfu","ulogd"] : ensure => latest}

set_file{[
"/etc/default/ipkungfu",
"/etc/ipkungfu/ipkungfu.conf",
"/etc/ipkungfu/services.conf",
"/etc/ipkungfu/accept_hosts.conf",
"/etc/ipkungfu/log.conf"
]:
require => Package[ipkungfu]
}

exec { "/etc/init.d/ipkungfu restart":
subscribe => [File["/etc/ipkungfu/ipkungfu.conf"],
File["/etc/ipkungfu/accept_hosts.conf"],
File["/etc/ipkungfu/log.conf"]
],
refreshonly => true,
require => [Package[ipkungfu],Set_file["/etc/default/ipkungfu"]]
}
}
[/code]

הפקודה set_file היא פקודת מקרו שכתבתי שמעתיקה קובץ מהמאגר של פאפט אל המכונה. אפשר להעתיק בשימוש בפקודת פאפט רגילה – אבל המקרו שלי קצת יותר קצר לשימוש.
במקרה הזה, set_files מעתיקה קבצי קונפיגורציה שהגדרתי מבעוד מועד ושמתי על הpuppet-master.
הקובץ גם מוודא שיהיו הגרסאות האחרונות של pkungfu ו ulogd.
פאפט תומך בכל מני מערכות, ובכל מערכת הוא ישתמש במנהל החבילות הנכון.
פקודת הexec מפעילה מחדש את ipkungfu ברגע שאחד מהקבצים בקטע הsubscribe משתנה.
היופי הוא שברגע שזה מוגדר, כדי להוסיף firewall למכונה כל מה שאני צריך לעשות זה לכלול את הסקריפט הזה בהגדרה של המכונה. (ברמת include, לא להעתיק אותו).

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

פורסם ב

טכנובוקר

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

פורסם ב

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

היום הכוננים הקשיחים גדולים מתמיד, אבל אני עדיין מצליח להתקל במצבים כרוניים של חוסר מקום.
הסיבה לכך היא בעיקר שאני קמצן מדי כשאני מקצה מקום למחיצה הראשית של מערכת ההפעלה, בין אם זה הלינוקס שאני משתמש בו באופן שוטף שקיבל מחיצה של 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. תסירו תוכנות שמנות, ותתקינו אותן במחיצה אחרת.

פורסם ב

הבאג שנלכד

מאז שעברתי לשרת החדש, היו לי בעיות עם שרת האפאצ'י: לפעמים הוא פשוט הפסיק לענות לבקשות, וחזר לעצמו רק אחרי 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.

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

פורסם ב

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

לאחרונה נתקלתי בבעיה עיקשת וקשה לפיתרון:
השעון של אחד השרתים שאני אחראי אליהם החליט שדיוק זה לא הקטע שלו, ונדד משהו כמו ארבע שעות בכל יום.
סינכרון 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, הבעיה נפתרה ולכל השרתים היו את אותם מקורות שעון.