Clonezilla

מכירים את partimage? גם כאן מדובר בתוכנה היודעת לבצע clone למחיצה לצורך שיחזורה בשלב מאוחר יותר. להבדיל מ- partimage (שמבצעת clone לכל המחיצה – כלומר גם לשטח שאיננו בשימוש) clonezilla מבצעת clone רק לשטח שבשימוש. clonezilla תומכת בפורמטים רבים בינהם ext2 ,ext3 ,fat32 ,ntfs ועוד… ניסיתי אותה (בשני הכיוונים), ולדעתי יש לה עוד הרבה מה להשתפר (במיוחד בממשק המשתמש). בכל מקרה מדובר בפרויקט חדש, כך שיש למה לצפות. דרך אגב: מפתחי gparted הוציאו גרסה משולבת: gparted ו- clonezilla בדיסק bootable יחיד.

קישורים:
דף הבית
Gparted-Clonezilla

clonezilla.jpg

Open-Clipart

לפני שנים רבות נהגתי להשתמש באוסף התמונות של מיקרוסופט אופיס בעת שכתבתי מסמכים באופן-אופיס. האמת: לא חוקי ולא יפה ! כנראה שרבים הבינו את הבעיה וכך נוצר לו הפתרון: openclipart. מדובר באתר המאפשר לאנשים לתרום תמונות ברישיון חופשי (בפורמטים png ו- svg) וכך, כעבור מספר שנים, הצטברו באתר כבר למעלה מ- 7000 איורים!!! ניתן להוריד את האוסף כקובץ בודד (נניח לשימוש בסביבת בחלונות) או כחבילה בינארית. באובונטו (ואני בטוח שגם בהפצות נוספות) ארזו את האוסף בחבילה בשם openclipart שניתן להתקינה דרך התפריט "הוספה והסרה". האוסף מותקן בנתיב usr/share/openclipart/ וכל שנותר זה להשתמש באוסף המדהים הזה בכדי להעשיר את המסמכים שלכם.

geranium_ganson.png

rsync+ssh – פתרון הגיבוי האולטימטיבי

סיפרתי לכם על השאיפה שלי להקים שרת NAS "שיחזיק" את כל הגיבויים החשובים שלי (תוכנות, סרטים, מוזיקה, מסמכים ועוד…). מאחר ש- FREENAS עדיין לא תומך ב- SATA2 החלטתי לפעול בכיוון הבא: התקנתי על שרת יעודי את Ububtu Dapper Server בתצורתו המינימלית ביותר (ללא LAMP). בחרתי בהפצה זאת מפני שמדובר בהפצה מאוד יציבה (תכונה מאוד חשובה לשרת שמחזיק גיבויים). פתרון הגיבוי שהקמתי מתבסס על RSYNC ו- SSH. מספר מילים על RSYNC ו-SSH:

  • rsync היא תוכנה קטנה וגאונית. יש לה יכולות עצומות כשאני משתמש כרגע בתכונה אחת בלבד והיא תכונת ה- mirroring. כלומר rsync יצור תמונת ראי של קבצי הגיבוי החשובים בשרת המרוחק.
  • היתרון ב- rsync הוא בביצוע השוואת קבצים מאוד חכמה: נניח ששיניתי 1 בייט בקובץ של 1 גיגהבייט. תוכנת גיבוי רגילה תרגיש שמדובר בקבצים שונים ולכן תעתיק מחדש את כל ה- 1 גיגה לשרת. rsync (אמרתי שהיא תוכנה גאונית?) מחלקת את הקבצים לבלוקים רבים, ומבצעת השוואה לבלוקים אלו, ולכן תעלה לשרת הגיבוי רק את הבלוק שהשתנה (בפועל היא תעביר רק מספר קילובייט) ותיצור קובץ הזהה לחלוטין לקובץ המקורי תוך מספר שניות בלבד.
  • הפקודה הבסיסית לסנכרון תיקיות בין מחשב מקומי למחשב מרוחק (NAS) היא:
    rsync -arv –delete local_dir NAS:destination_dir
    הבעיה בפקודה היא שהשרת המרוחק מבקש סיסמה להזדהות, ולכן לא ניתן להשתמש בפקודה זאת בסקריפט שרץ באופן עצמוני. בנוסף אין הצפנה של הנתונים (פרמטר שלא חשוב לי, אבל חשוב במקומות העבודה)
  • ssh הוא shell מאובטח. בפתרון שבחרתי לכל צד (קליינט ושרת) יש זוג מפתחות: פרטי וציבורי. כשהקליינט מעוניין להעביר את המידע לשרת המרוחק הוא מצפין את המידע בעזרת המפתח הציבורי של השרת המרוחק. רק לשרת המרוחק יש את המפתח הפרטי שיכול לפתוח את ההצפנה, ולקבל את הנתונים האמיתיים.

הפתרון:

לצורך ביצוע פעולת גיבוי מוצפנת (SSH ) וחכמה (RSYNC) יש לבצע את השלבים המתוארים באיור הבא (כתבתי באנגלית מטעמי נוחות):

rsync_ssh_backup.jpg

הערות:

  • בשלב 1 קובעים את שיטת ההצפנה (dsa) ויוצרים זוגות של מפתחות
  • בשלב 2 מעתיקים את המפתח הציבורי לשרת המרוחק.
  • בשלב 3 מכניסים את המפתח הציבורי למחסן המפתחות המאושרים.
  • בשלב 5 ניתן להוסיף את האופציה z וכך לדחוס את המידע המועבר לשרת החיצוני.
  • ניתן להריץ את הסקריפט באופן ידני ויבש (dry-run) עם האופציה -n וכך לראות אילו שינויים אמורים להתבצע.

אבטחת המחשב באמצעות קובץ host

קובץ ה- host משמש כידוע כמתרגם שמות (גם שמות מתחם) לכתובות IP. בעקבות מאמר של עמית בנושא יישמתי בכל המחשבים שלי בבית את ההגנה המוצעת. הפתרון מאוד פשוט כשהמטרה היא שכל כתובת זדונית תיתקל ב-"קיר בטון" (127.0.0.1). מי שמתעצל לקרוא את המאמר המלא יכול לקבל כאן קובץ המעודכן ל- 7.4.2007. בלינוקס קובץ ה- hosts נמצא ב-
etc/ ובחלונות 2000/XP הוא נמצא ב- c:windowssystem32driversetc . מיותר לציין שיש לעדכן את הקובץ מידי פעם…

הדגמה: ניסיון גישה לאתר המפוקפק www.oralse.cx (מופיע בקובץ) נחסם בצורה אלגנטית.

host.png

top vs htop בתמיכה בריבוי ליבות/מעבדים

המחשב הראשי בבית מכיל מעבד כפול ליבה AMD 3800+ X2. החלטתי לבדוק כיצד לינוקס מנצלת את ריבוי הליבות. לצורך הבדיקה כתבתי תוכנה פשוטה בפייתון (ראו צילומי המסך: 3 שורות שגורמות לכניסה ללולאה אינסופית ולכן גורמות לניצולת של 100% מעבד). במהלך הבדיקה גיליתי מספר דברים מעניינים:

  • top מיושנת במקצת ולכן מספקת צריכה ממוצעת של המעבד (כ- 50%), כשאין הפרדה ויזואלית בין הליבות השונות.
  • htop חכמה יותר. יש חלוקה בין הליבות השונות: ניתן לראות שהתוכנה גורמת בליבה אחת לצריכה של 100% בעוד שהליבה השנייה קרובה ל- 0% צריכה.
  • הדבר היותר מעניין שגיליתי הוא שאחת לכמה זמן, מבלי שאגע בדבר, לינוקס מחליט (באופן עצמוני) להעביר את הטיפול בתוכנה לליבה אחרת, וכך תצרוכת המעבד בליבה השנייה קופצת ל- 100% בעוד שבליבה הנוכחית התצרוכת יורדת ל- 0%.

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

cpu1.png

cpu2.png

OpenOffice Base

על אופן אופיס בוודאי שמעתם. אני משתמש בעיקר ב- writer ו- calc ודי מרוצה. לפני כשנה ניסיתי לעבוד עם תוכנת ה- Databasa אך התייאשתי (בגלל הבאגים שהיו בה). לפני מספר ימים שוחרר גיליון 17 של מגזין התוכנה החופשית ובו פורסם המאמר הבא: The simplest way to make databases in OpenOffice.org . קראתי קצת והחלטתי לנסות שוב את הBase בתקווה שהתקופה שעברה עזרה לו להתייצב. בחרתי בפתרון הפשוט ביותר שהוצג במאמר ויצרתי בסיס נתונים באמצעות calc. היתממשקתי אליו עם Base והכל נראה תקין. עכשיו ניסיתי לייצר טופס האמצעות האשף: עברתי על כל השלבים, עיצבתי את הטופס והגעתי לשלב בו נשאר ללחוץ על Finish. אך הלחיצות על Finish לא עזרו והאשף סירב לסיים עבודתו. נכנסתי לפורום הבינלאומי של אופן אופיס ושם ראיתי שעוד אנשים נתקלים בבאג הנ"ל. עברתי לחלונות (שם מותקנת גרסה 2.04) ובאורח פלא הבאג לא קיים שם. יצרתי את הטופס די בקלילות, עברתי באמצעות הטופס על בסיס הנתונים וראיתי שהוא מתפקד די טוב. הגעתי לשלב הבא והוא שלב הכנסת הנתונים לבסיס הנתונים (באמצעות הטופס שהכנתי): ניסיתי וניסיתי אבל הטופס סירב להכניס את הנתונים לבסיס הנתונים. שוב פעם נכנסתי לפורום ומסתבר שגם זה באג… בשלב זה הנחתי ל- Base. הדבר החשוב ביותר לתוכנה שעובדת עם בסיס הנתונים הוא היציבות ויצירת אמון מלא מול המשתמש. הבאגים הבסיסיים האלו לא נתנו לי את הביטחון הזה. משום מה נדמה לי שרוב המאמצים מופנים ל-writer (אולי בהצדקה מסוימת) ולכן Base מוזנח יחסית.

base_form.jpg