זהו… הרגשתי שהגיע הזמן להתמקצע בלינוקס – ופתחתי סדרת פוסטים, דיי hands-on (ובשאיפה לא משעממים, גם לאנשי תוכנה מקצוענים) על לינוקס.בחרתי בהפצת אובונטו כי:
היא “נחשבת”
היא שונה וקצת יותר נחמדה/מגניבה ממה שאתקל בעבודה (בעיקר הפצת SLES – Suse Linux Enterprise Server ואולי טיפה Red Hat Enterprise Linux).
ראיתי שכ”כ הרבה תוכנות זמינות או מתעדות שימוש ב apt-get (של אובונטו/debian) אבל לא ב zypper (של SUSE) או אפילו yum (של Red Hat/Centos/Fedora) – ורציתי לראות למה…
הערה: אם אין לכם מושג מה אמרתי, אבל אתם מרגישים שזה יכול להיות חשוב עבורכם – סדרת הפוסטים הזו היא בשבילכם.
אובונטו (ומשפחתו) נחשבים קצת יותר חזקים בצד ה Desktop – אבל אותי מעניין דווקא צד השרת ושימוש ב shell / command line בלבד. סדרה זו לא תקדם את מי שרוצה להשתמש בממשק גרפי בלינוקס, אלא אם מעניין אתכם מהם ה internals שמאחורי הממשק הגרפי.
למרות שההפצה “הכי מומלצת” ללמידת צד-השרת של לינוקס היא כנראה CentOS (סוג של red hat חינמי) – רוב מה שאכתוב בסדרת פוסטים זו תהיה רלוונטית כנראה גם למשתמשי CentOS/RHEL/SLES/Fedora וגם למשתמשים שולחניים (בעיקר Mint/Ubuntu) שרוצים להכנס לעומק ולהבין מה יש מאחורי ה”פנים היפות” של הממשק הגרפי.
אנו ממשיכים עוד קצת עם הטיול שלנו במערכת הקבצים, וקובעים מטרה: לוגים. אבל גם נהנים מהדרך עם: tail, redirects, find, קבצים מיוחדים ועוד כמה טריקים קטנים…
היבט חשוב של תפעול ועבודה עם מערכת הם הלוגים (log files) של המערכת ואפליקציות השונות.משמעות המילה log, כדרך אגב, היא “בול עץ”. כיצד בולי-עץ קשורים לקבצי log? הנה סיפור קצר:
בעבר ניווט בים נעשה ע”י סכימת מרחקי שיט שהספינה עברה. הספינה יצאה מנמל (עכו, למשל) והקפטן ספר: “6 שעות לכיוון מערב במהירות 10”.
המהירות חושבה בצורה מדעית למדי: מלח השליך בול עץ (log) למים מחרטום האוניה. מכיוון שהאוניה מהירה יותר (יש לה הנעה מהמפרשים), היא עקפה את בול העץ בהדרגה. המלח ליווה את בול העץ מחרטום האוניה על לירכתיים – ושר לעצמו שיר. ברגע שבול העץ הגיע לקו יכרכתי האוניה, השירה נפסקה ובול העץ נשלף מהמים. ע”פ המקום בו הפסיק השיר נקבעה – מהירות השיט: “אבל את לא מבינה…” – מהירות 7. “…אל תהיי תמימה” – מהירות 6.
הקפטן, מצידו, ניהל מסמך ארוך שנקרא Captain’s log שכלל שורה לכל קטע בשיט: .
לפי הרכבת השורות בלוג ניתן היה אפשר לשחזר את מסלול הספינה – ומכאן את מיקומה. כמה מאות ק”מ לפה או לשם…
באופן דומה, בעזרת קובץ לוג של תוכנה, ניתן לשחזר (בצורה גסה) מה התרחש במערכת – ומה בעצם הסיבה לתקלה שאנו רואים (פחות או יותר…)
בכל אופן, log files הם כלי פשוט, אמין – ומאוד שימושי. נרצה להשתמש בהם בלינוקס.
בואו נחפש את קבצי הלוג של מערכת האובונטו. בכדי למצוא קבצים במערכת הקבצים של לינוקס, משתמשים בפקודת find. למשל, כך מחפשים קובץ index.html בתוך התיקיה של המשתמש שלי (~):
find ~ -name index.html
אל תתנו לדגומה הקטנה הזו להטעות אתכם: find בלינוקס היא פקודה מבלבלת למדי: יש לה פרמטרים רבים, וחוקים שונים לגביהם.
התחביר שלה בפועל הוא משהו כזה:
find
symbolic links options – נתעלם מחלק זה. כברירת מחדל find לא “נכנסת” ל symbolic links.
root path- מתחתיו יתבצע החיפוש. אם לא צוין, יהיה . (התיקיה הנוכחית).
search options – נוגעים לאופן החיפוש: איזה עומק לחפש (depth), האם לחפש ב mounted drives (פרמטר mount-) וכו’.
action- מה לעשות עם הקבצים שהתאימו לחיפוש. ברירת המחדל היא print- (הצגה ל standard output). אפשרויות אחרות כוללות הפעלה פקודה כלשהי בלינוקס (rm, mv וכו’).
קצת קשה לזכור את הסדר של סוגי הפרמטרים השונים. אם מתבלבלים בסדר הפרמטרים אזי יופיע warning נוסח “non-option argument“, או במקרה הפחות טוב – יקרה משהו שונה ממה שהתכוונתם.
הנה דוגמה לכמה חיפושים אפשריים:
find ~/js_project -iname “*.js” -size -10k
תחפש קבצים בסיומת js. הארגומנט iname מחפש ע”פ שם בהתעלמות מ case. כלומר גם סיומת “Js” תמצא. הארגומנט size- מגביל את גודל הקובץ, במקרה שלנו עד 10kB. שימוש ב 10k+ היה מחפש קבצים בגודל 10kB ומעלה.
דוגמה קצת יותר מורכבת:
find /home ! -user baronlior -exec touch {} \\;
תחפש את הקבצים של משתמש שאינו (סימן !) המשתמש “baronlior” בתיקיה home/, ובמקום להדפיס את הקבצים למסך – תפעיל עליהם את פקודת הלינוקס touch. הפעולה exec- מקבלת expression כלשהו שנגמר ב ;. באובונטו צריך escaping (כל הפצה מתנהגת מעט שונה) – ולכן ;\\ מציין את סוף ה expression. הסוגריים המסולסלים יוחלפו כל פעם בשם הקובץ. לכן המשמעות בפועל היא הפעלת הביטוי הבא על כל קובץ שנמצא:
touch
פקודת touch מעדכנת את ה modification date של הקובץ לזמן הנוכחי. “נוגעת בקובץ, מבלי לשנות את תוכנו באמת”.
אם הקובץ לא קיים – היא תיצור אותו. פקודה שאני מוצא כשימושית למדי.
אחד העקרונות של ה shell של לינוקס הוא: “נגעת – נשאת”. אין שאלות “Are you sure” גם על פעולות משמעותיות. כדי להמנע מ”תקלה מצערת”, ניתן להפעיל את פקודת ה find הנ”ל בצורה הבאה:
find /home ! -user baronlior –ok touch {} \\;
ok- הוא כמו exec-, רק שהוא שואל אותנו, קובץ אחר קובץ, אם אנחנו בטוחים.
טוב… סטינו קצת מהדרך. אנו מחפשים את קבצי ה log של לינוקס. היכן הם יהיו?
אם אתם זוכרים את הפוסט הראשון בסדרה, קבצים בעלי גודל משתנה מאוחסנים בד”כ בתיקיה var/. בואו נחפש:
find /var -name “*log*” | grep log
כאשר משתמשים ב regex / wildcards – כדאי לעטוף את הערכים במרכאות כדי למנוע בלבול.
אני משתמש גם ב grep, כטריק קטן, בכדי להדגיש את התוצאות.
grep, אם אתם לא זוכרים מהפוסט השני בסדרה, הוא כלי ש”מפלטר” זרם (stream) של טקסט רק לשורות המכילות מילת מפתח – וגם מדגיש את המלים הללו.
grep יכול לעשות יותר מזה. הוספה של פרמטר 2 A- ,למשל, תאמר ל grep להציג 2 שורות נוספות מהטקסט לאחר השורה שבה היה match. הפרמטר הוא A עבור after ויש לו אח מקביל, B, עבור before.
ב grep ניתן להשתמש גם באופן עצמאי בכדי לחפש טקסט בתוך מספר קבצים (ע”פ pattern).
בכל מקרה, הנה התוצאה של החיפוש שלי:
קצת ארוך. בואו נקצר ע”י בקשה של חיפוש אחר תיקיות (type = d) בלבד:
2 תוצאות שמצאנו – נראות בהחלט רלוונטיות.
כפי שניתן לראות יש עוד 4 תיקיות בהן לא הצלחנו לבצע חיפוש – מכיוון שאין לנו הרשאות קריאה בהן. אולי אנחנו מפספסים משהו?
ניתן להשתמש ב sudo.
קצת מעצבן להקליד את השורה הארוכה (נניח) שכבר הרכבנו פעם נוספת, לא?
בעזרת SSH client מתקדם ל ניתן להריץ מחדש עם sudo בקלות יחסית עם העכבר / קופי-פייסט.
יש דרך קלה אפילו יותר, שתעבוד עם ה SSH client הפרימיטיבי ביותר / terminal:
sudo !!
!! הוא משתנה שערכו הוא הפקודה האחרונה שהוקלדה ב shell. לאחר שימוש בפקודה. כאשר אנו משתמשים ב !!, ה history שיזכר הוא כאילו הקלדנו הכל מחדש. מאוד נוח – רק שימו לב לא להקל ראש בשימוש ב sudo עם הטריק הזה.
בעזרת הרשאות sudo, מצאנו עוד תיקיה בשם logrotate. לא תיקיה שמעניינת אותנו כרגע.
בואו נתבונן על תסריט מעט אחר:
נניח שלא ניתן להשתמש ב sudo ויש הרבה תיקיות שאין לנו אליהן הרשאות (מצב הגיוני בשימוש ב find, במיוחד על שרת production). מה עושים? כיצד מפלטרים את כל הודעות השגיאה מהתוכן המשמעותי?
תזכורת של ה”בעיה”
אפשר בוודאי לעשות משהו עם grep, אבל אני רוצה לתקוף את הבעיה מכיוון אחר. ננסה:
זהו. אני מרגיש שהתחלנו להיכנס ל hardcore של השימוש ב shell. אני מניח שרוב מפתחי java ו / או C מכירים את 3 הערוצים של מערכת ההפעלה: stdout, stdin ו stderr (הממוספרים 0, 1 ו 2 – בהתאמה).
אלו הם ערוצי ה shell של לינוקס שב C עושים בהם שימוש, וג’אווה אמצה אותם כממשק (תחת המחלקה System):
ישנו ערוץ אחד של קלט (stdin) ושני ערוצי פלט. למרות שאנו רואים על המסך תוצאה של הרצת התוכנה / פקודה כשטף אחד של שורות טקסט, בעצם מערכת ההפעלה מסווגת ומנהלת אותם כ 2 ערוצים שונים:
stdout הוא קיצור של standard output – תוצאת ההרצה
stderr הוא קיצור של standard error – שגיאות שהתגלו בהרצה.
בעזרת פעולת I/O redirect (קרי <, <<, אך גם > הנדירה יותר) אנו יכולים לשלוח את התוצאות של פלט התכנית ל stream (קובץ, רשת) שהגדרנו. בעזרת ” <n “, כאשר n הוא מספר ערוץ הפלט 1 או 2, אנו יכולים לפצל את הערוצים ולשלוח רק אחד מהם ל stream נבחר.בפקודה למעלה שלחתי את ערוץ השגיאות לקובץ בשם err.txt, שכפי שניתן לראות בתצוגה שלו מיד לאחר כך – הוא קיבל את כל הודעות השגיאה.
ניסינו להציג את הקובץ – אך שום תוכן לא נראה. היכן השגיאות שלנו?!
האם קובץ כזה בכלל קיים? בדקנו – וכן, הוא קיים.
נשתמש ב file לבדוק מאיזה טיפוס הוא. הממ… “סוג מיוחד” (character special)
מה קורה פה? dev/null/ הוא קובץ מערכת מיוחד, אחד מכמה בודדים במערכת Linux (עד כמה שידוע לי).
dev/null/ הוא סוג של “recycled bin”: מה שנשלח אליו – נמחק לעד לפני שתספיקו לומר… “… sudo”.
מתי הוא שימושי? כתחליף לקובץ זמני שאנו מתכננים למחוק – אך אנו יכולים לשכוח למחוק (ואז נשאר “זבל”). אני מניח שהוא גם מהיר יותר – כי שום דבר לא נכתב באמת לדיסק.
אם יש לנו פעולה שמייצרת הרבה error, אבל אנו יודעים שזה בסדר ולא רוצים לראות את השגיאות (כמו בדוגמה לעיל) – כתיבה ל dev/null/ במקום err.txt – היא שימושית.
קובץ מיוחד נוסף הוא dev/zero שהוא בעצם stream אינסופי של אפסים.
כיצד ניתן להשתמש בכזו חיה מוזרה?
למשל:
cat /dev/zero >> large.txt
ייצר לנו קובץ (מלא אפסים) בגודל כמה MB תוך שניות בודדות. שימושי לצורך בדיקות מקרי-קצה.
הפקודה “cat large.txt” לא תציג שום דבר, כי ערך 0 של ASCII הוא בלתי מוצג (זה לא התו “0”, שערך ה ASCII שלו הוא 48). הפקודה:
xxd large.txt | less
דווקא תציג את תוכן הקובץ. xxd – קיצור (משונה) של hex dump. תוכנה זו הופכת מידע בינארי (כלומר: בייצוג הטבעי שלו) לתצוגה בינארית [א]. הצגתי את תוצאת ההמרה בתוך ה viewer הפשוט של לינוקס שנקרא less.
כשאפסים לא מתאימים למשימה, ניתן להשתמש באופן דומה dev/urandom/, שהוא פחות מהיר אך מייצר stream של מספרים פסודו-אקראיים.
קובץ מיוחד אחרון שאזכיר הוא dev/full/, שבכל פעם שננסה לכתוב אליו נקבל שגיאה שהדיסק מלא (שימושי עבור בדיקות).
אבל מה עם הלוגים?!
כן, נכון. התחלנו את המסע הזה בחיפוש אחר הלוגים.לוגים נמצאים בעקרון בתיקיה var/logs/:
אפשר לראות שלוגים ישנים יותר נדחסים (צבע אדום) בכדי לחסוך מקום. התהליך שעושה זאת נקרא logrotate.
אפשר לראות תיקיות עם עוד logs ע”פ נושאים (apt – התקנות או upstart – תהליך האתחול של אובונטו). כשמותקן שרת Apache, לדוגמה, הוא יאכסן את הלוגים שלו בתיקיית בת בשם /httpd.
כדי לצפות בקובץ שדחוס ב gzip (סיומת gz), יש פשוט להשתמש ב zcat, גרסה של cat שפותחת את הדחיסה on the fly:
zcat syslog.2.gz
אפשר לציין כמה לוגים עקריים:
syslog – לוג ברירת המחדל להודעות מערכת. syslog הוא לא רק קובץ לוג, אלא גם שם של פרוטוקול להעברת לוגים בין מערכות. למשל: הקצאת שרת אחד עליו יכתבו כל הלוגים של כל שרתי ה production.
daemon.log – לוג של שירותים שרצים ברקע.
kernel.log – הודעות קרנל של מערכת ההפעלה.
auth.log – רשימה של פעולות התחברות למערכת ושימוש בפקודת sudo.
אפשר למצוא רשימה מקיפה של קבצי הלוג בלינק הכללי הבא ללינוקס או בתיעוד של אובונטו (הקבצים מעט שונים. למשל באובונטו אין קובץ לוג של messages שמאוד נפוץ לשימוש בכל העולם של red hat).
פורמט קבצי הלוג, הוא בברירת המחדל משהו כזה (תלוי בקובץ, ותלוי בהגדרות המערכת):
[Timestamp in syslog format] [Host] [Process]: [Message text]
host, אפרופו, הוא חשוב מכיוון שפעמים רבות מרכזים בעזרת syslog את הלוגים לא על השרת בו התרחשו האירועים.
כדי לנטר בעיות עלייה של המערכת כולה, הכי פשוט להשתמש בפקודה בשם dmesg המרכזת נתונים שונים על טעינת המערכת. כדי להתמצא בשלל המידע, כדאי להשתמש ב grep, כפי שמוסבר במדריך הקצר שבלינק זה.
את הגדרות המערכת, מה הולך לאיזה לוג, ניתן למצוא תחת קבצי הקונפיגורציה של הלוגים בתיקיה etc/rsyslog.d/
הסיומת d. משמשת ב UNIX (ולכן גם בלינוקס) לסמן ספריות, בעיקר כאשר יש קובץ עם שם דומה במערכת.
קובץ ההגדרות הראשי הוא rsyslog.conf (הנמצא במקביל תיקיה rsyslog.d) – המגדיר את המודולים האחראים על הלוגים, הרשאות של קבצי log שיכתבו וכו’.
את ההגדרות היותר שימושיות ניתן למצוא בקובץ ברירת המחדל של הגדרות הלוג etc/rsyslog.d/50-default.conf:
ניתן למשל לראות, שקובץ הלוג של תהליכי הרקע (daemon.log) הוא disabled כברירת מחדל.
עוד טיפ קטן:
כאשר קבצי הלוג גדולים ו / או אתם בוחנים אותם דרך הרשת (למשל ssh) – הטעינה/הצגה שלהם הולכת לקחת זמן. פעמים רבות יעניינו אותנו רק השורות האחרונות, ואז כדאי להשתמש בפקודה tail. למשל:
tail -50 syslog | less
תציג לנו בתוכנת less רק את 50 השורות האחרונות של קובץ ה syslog. הטריק הוא לקרוא את כל הקובץ ולהציג רק את 50 השורות האחרונות: tail בעצם מבצע seek על הקובץ וקורא רק את הבלוקים האחרונים שלו עד שיש לו את מספר השורות שביקשנו – מה שמיעל דרמטית את זמן הטעינה של הלוג.
עוד דבר נחמד שקיים ב tail הוא הפרמטר f- (קיצור של follow) שיאזין לשינויים בקובץ לוג ויציג אותם ברגע שיתווספו לקובץ. למשל:
tail -f syslog
מוד זה הוא שימושי למצב שאנו מנטרים מערכת ורוצים לראות את השורות שמתווספות ללוג – בזמן אמת.
סיכום
עברנו עוד כברת דרך בטיפול בקבצים בלינוקס/אובונטו: פקודת find, קבצים מיוחדים, לוגים, ועוד. לפעמים ה”עוד” הזה הוא החלק החשוב ביותר 🙂
בתחום הקבצים בלינוקס/אובונטו נותר לנו לדבר בעיקר על הרשאות ו symbolic links…
שיהיה בהצלחה!
—
[א] בדומה למצב debug ב DOS – למי שזוכר, אבל אז כל מילה הייתה 16 ביט / 2 בתים.
בלינוקס, יש לנו path המתאר תיקיות בהן מחפשים קבצים, אם הם לא נמצאו בתיקיה הנוכחית – ממש כמו בחלונות.הערה: קצת מוזר לומר שמשהו ב Linux דומה לחלונות. המקור ממנו שתיהן הושפעו הוא כמובן UNIX, כאשר Linux הושפעה מאוד מ UNIX, וחלונות – רק במעט. בגרסאות האחרונות (Windows server 2003 ומעלה) ניתן לראות יותר מנגנונים בחלונות שדומים ל UNIX (ביצוע פעולות עם super user, יציאה מה registry לתיקיות קונפיגורציה, כל ההתפתחות של power shell, ועוד) – אולי בכדי לסגור פערים מול פ’יצרים מוערכים בלינוקס.
נחזור ל path. בכדי כדי לבדוק את ה path שכרגע מקונפג במערכת נקליד:
echo $PATH | tr ‘:’ ‘\\n’
מדוע השתמשתי בפקודה tr*?
א. כדי להוסיף קצת אקשן, וללמוד כמה דברים נוספים על הדרך, ו
ב. כדי לא לקרוא את ה path בשורה אחת צפופה, כמו כלב.
* יש פה גם pipe. אם אתם לא מכירים – קפצו לפוסט הקודם בסדרה או חפשו בגוגל.
הנה תוצאת הפקודה על המחשב שלי:
כמה הסברים על התוצאה – מדוע כך נראה PATH ברירת-המחדל:
לינוקס מפרידה בין executables לשימוש כללי (תיקיות bin; קבצים לדוגמה: ls או cat) ו executables המשמשים את מערכת ההפעלה עצמה (תיקיות sbin; קבצים לדוגמה: reboot, init או mkfs [א]).
תיקיות bin/ ו sbin/ (ישירות תחת ה root) – הן עבור executables שצריכים להיות זמינים בשלב מוקדם של ה boot sequence של מערכת ההפעלה, לפני שהתבצע mount לתיקיית ה usr/
תיקיית usr/, בניגוד ליוניקס או חלונות, היא איננה תיקיית “user data” אלא “user applications”.
תיקיות */usr/local/ נועדו לאפליקציות (או סקריפטים) שאנו מוסיפים למערכת. הם לא חלק מהמערכת ו / או מנוהלים ע”י ה package manager. אפליקציות שמגיעות דרך ה package manager לא יכולות להיות מותקנות בתיקיית ה local.
משחקים? על ubuntu server? אולי לשעות המתות של ההתקנות… (התיקיות עצמן ריקות).
נחזור לפקודה עצמה:
echo – אנחנו מכירים (אמורים להכיר מפוסט קודם). שלא כמו בחלונות, יש להקפיד על upper-case ב PATH (או כל משתנה אחר).
tr (קיצור של transliterate, אפשר לזכור את זה כקיצור של translate) הוא בעצם סוג של כלי search-replace. אנו מחליפים את “:” (ה separator בין paths במשתנה PATH) לשורה חדשה. מתכנתים אמורים להרגיש נוח עם n\\.
tr עובדת על תווים בודים (characters) ומבצעת החלפה, בהתאמה, בין ערכי הפרמטר הראשון לערכי הפרמטר השני. לצורך התרגיל:
echo $PATH | tr ‘:’ ‘\\n’ | tr ‘a-z’ ‘A-Z’
תחליף גם אותיות לטיניות ל upper case.
אם אנו באים מרקע של חלונות, אולי כדאי להציג את ה PATH בצורה יותר מוכרת, ב “Windows format”? 😉
לא להיבהל אם הפקודה עמוסה בסימנים. חתכו בראש את ה pipes ועברו שלב-שלב: אלו שלבים פשוטים.
את ההתחלה אתם כבר מכירים. עבור התו \\ היינו זקוקים ל escaping (\\\\). את ההוספה של :C בתחילת כל שורה לא יכולתי לעשות בעזרת tr: מכיוון ש tr מחליפה כל סימן בסימן אחר (או כלום) – אך היא לא יכולה לטפל במחרוזות ארוכות יותר “:C”. הקלידו mantr בשורת הפקודה כדי ללמוד על כמה אופציות נוספות שיש לה (בעיקר זיהוי סימנים טוב יותר או העלמה יעילה של תוים – החלפה בכלום).
כש tr הפשוטה לא מספיקה – עוברים ל sed (קיצור של stream editor).sed היא פקודה רבת-עוצמה המאפשרת חופש פעולה רב מאוד. במקרה הזה השתמשתי בה בכדי לבצע החלפת טקסט דומה ל tr. הפרמטר e- אומר שאני רוצה לעבוד עם sed script (מה שבמרכאות) והפתיחה באות s היא פקודה ב sed script בפורמט “/s/regex/replacement”. כלומר: ה regex הוא ^ (תחילת שורה) וההחלפה היא המחרוזת “:C”. / הם רק separators בין הפרמטרים.
צחקנו קצת – יופי.
הוספה ל path
נניח ואנו רואים את ה path ולא מרוצים ממנו. אנו רוצים להוסיף לו את התיקיה: usr/local/games/2048/ כדי שהמשחק (בגרסה ה shell-ית שלו) יהיה זמין לנו להפעלה מכל מקום ובכל רגע.
2048. גם אנשי bash – מתמכרים.
כדי להוסיף למשתנה path יש לכתוב:
PATH=$PATH:/usr/local/games/2048
תחביר דומה ל x = x + n. שימו לב שאנו זקוקים prefix של $ בכדי לקרוא את הפרמטר PATH – אך לא כדי לכתוב לתוכו.
יש לנו בעיה: לאחר login מחדש עם ה shell – ה PATH יחזור למצבו הקודם.
הסיבה: בכל התחברות מחדש עם SSH – רץ סקריפט שדורס את משתנה ה PATH.
מה נעשה? נדרוס אותו עוד פעם בעצמנו.
אתנחתא קלה
שניה! בחלונות אני מגדיר משתני סביבה – והם קבועים.
מה זה ה hack הזה בלינוקס שכותבים סקריפט שבכל התחברות ידרוס משהו קבוע? מה לא בסדר בלינוקס?!
ובכן, הכל בסדר בלינוקס. לינוקס פשוט – גלויה יותר.
גם בחלונות רצים scripts להגדרת הסביבה בכל פתיחה שלה (יהיה זה PowerShell, cmd, או Connect-WSMan) – פשוט מערכת ההפעלה מחביאה פרט זה מהמשתמש. כל script כזה הולך למקום בו שמורים ה environment variables ויוצר אותם בסביבה. אפשר בקלות רבה לממש לוגיקה דומה בלינוקס: קובץ משתנים וסקריפט שנטען לכל משתמש ויוצר את המשתנים הללו בסביבה.
הדרך המקובלת בלינוקס היא פשוט להוסיף עוד שורה ל script האתחול.
בהפעלה של ssh – רצים כמה סקריפטים:
etc/profile/ – סקריפט אתחול לכלל המשתמשים
profile./~ – סקריפט אתחול למשתמש, שבעקרון קיים בשביל תאימות-לאחור (אך בהחלט אפשר להשתמש בו)
bash_profile./~ סקריפט שרץ בזמן login של המשתמש
etc/bash.bashrc/ סקירפט אתחול לכלל המשתמשים בעת הפעלה של bash ב interactive mode (קרי טרמינל או SSH).
bashrc./~ סקריפט אתחול למשתמש בעת הפעלה של bash ב interactive mode.
רשימת הסקריפטים שנטענים תהיה שונה אם עובדים עם shell אחר, למשל ksh (קיצור של kornShell).
בד”כ עורכים את bashrc/~ (כלומר: בתיקיית הבית של המשתמש), אם רוצים להשפיע על המשתמש הבודד ב bash.
אם מדובר על משתני סביבה שיהיו בשימוש עבור איזה תהליך שרץ עבור המשתמש, בלי שהוא מחובר אינטרקטיבית – יש לערוך את profile./~ בכדי לקבל את התוצאה הרצויה.
“<<“ עובד בדיוק כמו שעובד בחלונות (הוספה לסוף קובץ), כך שלא משנה מה יש בקובץ – הוספה לסופו היא בטוחה למדי (כלומר: יחסית. כל מה שיכול להשתבש – אכן ישתבש).
“Unix is user-friendly. It just isn’t promiscuous about which users it’s friendly with.” – “Steven King, Software Archaeologist”
עוד טיפ קטן: לפעמים אתם רוצים לדעת איפה executable יושב: אולי חסרות לו הרשאות, ואולי לכם הוא זמין ב PATH ולחברכם לא – אבל אתם לא רוצים לזרוק עליו עשרה paths שאתם משתמשים בהם. פקודת which מחפשת ב PATH (ללא כניסה ל symbolic links) אחר executables ומדווחת על מיקומם:
סיכום
בחיי שרציתי לדבר על ניהול קבצים! ניהול הרשאות עם chmod, חיפוש עם find, אולי symbolic links, אולי משהו נוסף.
אבל – קצת נגררתי. אני רוצה לכסות את הנושאים בהם אני נוגע בצורה מעמיקה, כך שמי שקורא יבין ולא רק “ידע” – אבל בלינוקס זה אומר כנראה שיש הרבה מאוד מה ללמוד.
נראה לי שמשיך עוד קצת, עד שימאס לי או שאראה (ע”פ השימוש) – שלכם הקוראים זה נמאס.
שיהיה בהצלחה!
—[א] קיצור של make file system
[ב] הדרך הפשוטה להוסיף שורה בסוף הקובץ הוא לפתוח אותו ב editor כלשהו ולראות בעיניים מה עושים (אלא אם עושים זאת בסקריפט).
ה UNIX WAY אומרת: Clarity is better than cleverness. בטוח שהרבה כותבי סקריפטים בלינוקס לא הולכים לפי כלל זה. הנה דוגמה לסקריפט למעלה כשהוא “מתוחכם”, אך לא קריא (לטעמי):
echo $PATH | tr ‘:/a-z’ ‘\\n\\\\A-Z’ | sed -e ‘s/^/C:/’
בפוסט הקודם (אובונטו – התמצאות בסיסית) תיארתי כלי בשם apt, ואת הפקודה “apt-get install” בעזרתה ניתן להתקין תוכנות במערכת. בעזרת שיטה זו ניתן להתקין חלק נכבד מהאפליקציות הקיימות – אך לא את כולן. בפוסט זה ארצה לצלול לנושא ההתקנה – לעומק.גם כאשר אנו עובדים בכלים ויזואליים (באובונטו: Software Center) יש ערך להבנה כיצד הדברים עובדים שכבה אחת נמוך יותר. הבנה זו תוכל לעזור לנו להבין דברים שה UI לא יסביר לנו. הבנה כזו – נרכשת בעבודה עם ה command line.
Ubuntu Software Center. קצת מוזר לראות “חנות אפליקציות” עם אפליקציה “חמה” בשם GGcov… מקור
בלינוקס, יש בגדול 3 דרכים עיקריות (כל אחת עם כמה וריאציות) להתקין אפליקציות. ניסיתי לתמצת אותן בעזרת התרשים הבא:
הדרך הפשוטה ביותר להתקין אפליקציות בלינוקס היא בעזרת package manager tools (כלומר: yum, zypper, apt וכו’), המאפשרים לנו להתקין אפליקציה בעזרת שורת פקודה בודדת. כלים אלו יתקינו עבורנו את כל הספריות בהן האפליקציה תלויה – מה שעשוי לחסוך לנו זמן רב. הם שומרים בסיס נתונים פנימי של ההתקנות שבוצעו: מה הותקן, היכן ותלויות – כך שנוכל להסיר או לעדכן בקלות את האפליקציות בעתיד.
לפעמים חבילות ה rpm. או deb. זמינות לנו, כקבצים להורדה (דומה לקובצי msi. בחלונות) מאתר האפליקציה ולא דרך repositories . במקרה כזה אנו יכולים להוריד אותן ידנית (בעזרת wget/curl), ואז להשתמש ב package manager ישירות בכדי להתקין אותן. למשל באובונטו, נתקין את Apache Directory שהורדנו ידנית בעזרת הפקודה:
dpkg -i apacheds-2.0.0-M16-amd64.deb
dpkg היא האפליקציה של ה debian package manager. שמות קבצי ה deb (או rpm) ישמרו בד”כ על הקונבנציה הבאה:
–––.deb
ה build number (נקרא בד”כ “release”) הוא מספר גרסה מפורט / מדויק של התוכנה (ולפעמים יכלול את מספר הגרסה). ארכיטקטורה היא סוג המעבד (32 או 64 ביט, אולי sparc או mips). שימו לב ש amd64 הוא הסימון לארכיטקטורת אינטל או AMD 64 ביט – ומתאימה לשניהם.
רבות מהפעולות שאנו נוהגים לעשות בעזרת כלי ניהול התלויות (apt): הסרה, עדכון, ניקיון וקבלת מידע – ניתן לעשות גם ישירות עם ה package manager, קרי dpkg.
במידה וקיים רק קובץ deb., אך אתם עובדים עם הפצת לינוקס שמשתמשת ב rpm. (או להיפך) – אתם יכולים להמיר את פורמט החבילה. לא ניסיתי בעצמי.
מגבלות של שימוש ב package manage: לא תמיד האפליקציה זמינה ב repositories.
דרך התקנה נוספת, היא הורדה של קובץ tar ומיקום ידני של תוכנו במערכת. קובץ tar (מקור השם: tape archive – מימים עברו ב UNIX; בסלנג לינוקסי נקראים גם tarballs) הוא קובץ דומה ל zip ללא דחיסה. לעתים קרובות הוא יכיל אפליקציה מוכנה להפעלה (דומה להפצות “portable” בחלונות) וקבצים נלווים נדרשים, ולעתים – קוד מקור שיש לבנות בעצמנו. נדע את הרכבו רק לאחר שנפתח אותו. את קובץ ה tar פותחים בעזרת הפקודה הבאה:
tar xvf .tar
הפרמטרים של פקודת tar הם: x – פתיחת קובץ, v – פירוט הפעולות המתבצעות (קרי verbose) ו f – שהפעולה מתייחסת לקובץ קיים (בפעולות פתיחה, flag זה תמיד נדרש).
קובץ ה tar יכול להיות גם בעל סיומות מעט שונות כמו tgz או tar.gz – כאשר קובץ ה tar דחוס בדחיסת gzip. ייתכנו סיומות אחרות לקובץ – לתאור דחיסות אחרות.
tar.gz ארוז ואז דחוס. מקור: וויקיפדיה
בגרסאות ישנות יותר של tar היה צריך להוסיף flags ע”פ סוג הדחיסה של הקובץ – אך כיום זה לא אמור יותר להטריד אותנו.
כאשר יש אפליקציה מוכנה להפעלה, פשוט יש להעביר את הקבצים למיקום הגיוני: אם זה קובץ בינארי בודד – לתיקיה user/local/bin/ (שנמצאת ב path ונועדה לצרכים אלו), אם זו תיקיה של קבצים – אולי לתת-תיקייה שלה (+ הוספה של התיקיה ל path).
אם קובץ ה tar לא כולל executables מוכנים להפעלה, זה אומר שקיבלנו source code שיש לבנות. זוהי דרך ההתקנה השלישית לאפליקציות בלינוקס. דרך נפוצה נוספת (ואולי יותר מקובלת) לקבל קוד מקור היא בעזרת פקודת git clone (פוסט למי שלא מכיר git). העתקת קוד המקור לצורך בנייתו והתקנת התוכנה, לא נחשבת כ hack – אלא דרך מקובלת ולגיטימית. אפליקציות רבות (למשל: redis) מציעות דרך זו כדרך ההתקנה המועדפת או היחידה שלהן.
כאשר אנו הולכים לבנות אפליקציה מקוד המקור שלה, הדבר המומלץ הראשון לעשות הוא לרפרף על ההוראות לפני שאנו מבצעים על מיני פעולות עם משתמש-העל (sudo). כמעט תמיד יהיה קובץ README ארוז בחבילה. פשוט הכנסו לתיקיה והקלידו “cat README.md | less”.
למי שלא מכיר, סימן ה pipe (|) גורם ללינוקס לנתב את הפלט של התוכנה שלפני ה pipe, כקלט לתוכנה שאחרי ה pipe. ניתן לשרשר מספר רב של pipes להרכבת פעולה מורכבת. בדוגמה לעיל: less (שהוא viewer עם paging פשוט בלינוקס) מקבל כקלט את הפלט של cat (תוכן הקובץ) ומציג אותו עם יכולות דפדפוף.
הערת צד: השימוש ב pipe הוא אחד העקרונות התכנוניים של יוניקס / לינוקס:
“Write programs that do one thing, and do it well”
“You can do complicated things by gluing simple things together”
כלומר: יש בלינוקס הרבה אפליקציות פשוטות וממקודות בפעולה ספציפית, וניתן לבצע משימוש מורכבות ע”י הרכבה של מספר פעולות בסיסיות.
בנייה של הפרויקט תכלול בדרך רק פעולת make פשוטה (make הוא כלי ה build של לינוקס. דומה בערך ל maven).
האפליקציה “make” לא תהיה זמינים על הפצה נקייה (היא נחשבת ל”כלי פיתוח”). כדי לבנות קוד מקור – מומלץ להתקין חבילה בשם build-essential הכוללת gcc, make ובערך כל מה שאתם שתזדקקו לו בכדי לבנות פרויקט סטנדרטי. לעתים, ייתכן ותזדקקו גם לחבילות נוספות כגון automake או checkinstall.
ההמלצה היא לבצע את ה make (בנייה) עם הרשאות של משתמש רגיל. מדוע? – מחשש לסקריפט make שגוי או זדוני שעשוי לגרום לנזקים במערכת. הנה סיבה מדוע לא לעבוד במוד של משתמש-על (ע”י sudo bash או sudo – s): זה מאוד נוח, ואין מי שיזכיר לנו לשים לב כשאנו עושים פעולות שעלולות להיות מסוכנות.
לביצוע פקודת make install (התקנת האפליקציה) נזדקק להרשאות משתמש-על: השתמשו בפקודת sudo לאפשר זאת. הסיבה: סביר שהסקריפט ינסה להעתיק קבצים לתיקיות שרק למשתמש root יש הרשאות כתיבה אליהן (תיקיות כגון usr/bin/).
שימו לב שכמו ב maven, ההגדרה מה מתרחש ב “make” וב “make install” היא פתוחה לחלוטין. גורם זדוני יכול לעשות כל מה שירצה גם בפעולת make install. בסה”כ, “make install” הוא רק שם. אם אתם חשדנים – בדקו מה כולל סקריפט ה make install לפני שאתם מפעילים אותו ב sudo. כשאנו משתמשים ב VMs + יש לנו הרבה עבודה אחרת – אנו נוטים להיות לא-חשדניים, עם אופציה לזריקת ה VM והקמתו חדש במקרה הצורך :).
שונות בהפצות לינוקס
יש שונות בין הפצות הלינוקס השונות. ה package managers וכלי השימוש בהם (yum, zypper, apt) הן אחת מהשונויות המוקדמות בהן נתקלים. תאורטית, ניתן להתקין כלי שלא הגיע עם ההפצה. למשל : להתקין rpm ו yum על הפצת Debian, אבל הסיכוי לתקלות – גדל בהתאם.
בהחלט ייתכן ותתקלו במצב בו אתם רוצים להתקין חבילות על הפצה לה אינכם רגילים.
התחברנו לשרת לינוקס בעזרת SSH, אך אנו לא יודעים איזו הפצה או גרסה מותקנת. כיצד אפשר לבדוק זאת?
פשוט, הקלידו:
cat /etc/*-release
הסבר הפעולה: אנו מפעילים פקודת cat (הצגת תוכן של קובץ ל standard output) על קבצים בשם “release-” הנמצא בתיקיית הקונפיגורציה (etc/). שם הקובץ בו מופיע שם ההפצה וגרסתה, משתנה בין ההפצות: SUSE-release לסוזה או redhat-release להפצת red hat וכו’. השימוש ב* יציג את הקובץ המדובר – לא משנה מהי ההפצה.
איזה הפצות בכלל קיימות?
זה נושא רחב. התרשים הכי חביב שמצאתי בנושא הוא זה:
אבל הוא לא לגמרי מדויק. קשה עד בלתי אפשרי לספק תרשים יחיד ושלם בנושא הפצות הלינוקס: הפצות שונות של לינוקס שינו את ה barnching שלהן לאורך החיים. הקשרים הם דינמיים. למשל:
הפצת Mint (הפצה מתמחה ב desktop פשוט להפעלה) החליטה בשלב מסוים בחייה לנהל 2 גרסאות: אחת היא branch של דביאן, והשנייה של אובונטו. איך זה מתחבר עם “קלות שימוש עילאית”? – אל תשאלו אותי.רד האט, החליטה שהיא לא יכולה להיות בד-בבד גם מגניבה + עדכנית וגם יציבה מספיק ל Enterprise. היא התמקדה בגרסת ה Enterprise ששמה שונה ל RHEL (קיצור של Red Hat Enterprise Linux) והוציאה גרסה נוספת, קצת פחות יציבה אבל שמתעדכנת הרבה יותר מהר – בשם Fedora. החידושים ב Red hat לרוב מגיעים קודם כל לפדורה ורק מאוחר יותר ל RHEL. אז מי הוא branch של מי?
בתרשימים מסוימים fedora מוצגת כסוג של redhat, ובאחרים – ההיפך.
בוויקיפדיה יצרו תרשים שיסביר את הכל[א], מי שמצליח להבין אותו – מקבל קרנל של לינוקס בחינם.
שימו לב שחלק מהפצות הלינוקס הן branching של הפצות קיימות, וחלק אחר – מורכב מ scratch (מעל ה kernel הקיים – כמובן).
כמעט שם…
לפני שנצלול לרזי ה package managers, יש עוד כמה דברים שייתכן שנזדקק לסדר בדרך: proxies.
כנראה שיש לכם proxy במקום העבודה, דרכו התעבורה צריכה לעבור בכדי להגיע אל האינטרנט. בכל גישה לרשת, שכבת הרשת של לינוקס בודקת את המשתנה http_proxy, ומתחשבת בו.
דרך פשוטה להגדיר ערך למשתנה היא ע”י הפקודה:
http_proxy=http://proxy:8080
(או מה שלא יהיה הפרוקסי שלכם). שימו לב שמסביב ל = אין להשתמש ברווחים, אחרת לינוקס תבין את הפקודה בצורה שונה (וכנראה שגויה).
לאחר שהפעלנו את הפקודה, http_proxy הוא משתנה shell – מה שאומר שהוא מקומי ושהוא יימחק בסיום ה session של אפליקציית ה bash.
בכדי לשמור את הערך לטווח – יש לשמור אותו כמשתנה סביבה (דומה ל environment variable בחלונות):
export http_proxy
באופן זה “מייצאים” את משתנה ה shell – ל environment.
ניתן לקצר ולעשות את 2 הפעולות בשורה אחת:
export http_proxy=http://proxy:8080
זהו.
לא בטוחים מה הפרוקסי? אולי הוא כבר מוגדר נכון? פשוט הקלידו:
echo $http_proxy
הסימן $ מציין שאנו מעוניינים לעשות echo למשתנה: shell או סביבה. אפשר לבקש ספציפית משתנה סביבה ע”י הפקודה printenv http_proxy (אם לא קיים – יחזור ערך ריק) או פשוט להקליד printenv ולראות את כל משתני הסביבה שמוגדרים.
עוד טיפ קטן:
לעתים התקנת התוכנה דורשת reboot של המערכת. בלינוקס, אגב, זה קורה הרבה פחות מאשר בחלונות. ניתן לעשות זאת בעזרת “shutdown – r 0″ (כמו חלונות; כנראה שהמקור הוא לינוקס) או פשוט בעזרת פקודת reboot.
זהו. הגענו לחלק בו אסביר על שימוש מקיף יותר ב package manager, ובעיקר בכלי של אובונטו: apt. אני עלול לחזור על כמה פריטי-מידע מהפוסט הקודם.
כדי להתקין חבילה, יש פשוט להקליד:
sudo apt-get install
למשל: sudo apt-get install nodejs. אם החבילה כבר מותקנת, apt יניח שאנו רוצים לעדכן אותה לגרסה האחרונה.
הסרת חבילה נעשית ע”י:
sudo apt-get remove
לאפליקציה יש שני חלקים: binaries וקונפיגורציה. פקודת ה remove תסיר רק את ה binaries (נאמר: במידה ואתם חושבים שמשהו השתבש בהתקנה). בכדי להסיר גם את הקונפיגורציה, ולהעלים כל זכר לאפליקציה, יש להקליד:
sudo apt-get purge
update vs. upgrade
יש שתי פקודות דומות ב apt – שעושות דברים שונים מאוד:
apt-get update – תעדכן את קטלוג התוכנות הזמינות ב repositories.
apt-get upgrade – תעדכן את כל התוכנות המותקנות – לגרסה האחרונה. שימו לב שפקודה זו לעולם לא תסיר תלויות (שהותקנו עם התוכנה) או תתקין תלויות חדשות שנוספו לגרסה חדשה של אפליקציה. אם בסיכום הפעולה כתוב
“number> not upgraded>” – זה אומר שכמה אפליקציות לא אופגרדו (עודכנו) מכיוון שיש להן תלויות חדשות. עליכם לעדכן אותן ידנית בעזרת apt-get install ולאשר את התלויות החדשות. בכדי להסיר תלויות שכבר אינן בשימוש יש להשתמש ב apt-get autoremove.
מציאת חבילות להתקנה
אני חושב שהדרך הכי נוחה לחפש חבילות קיימות היא בגוגל. בכל זאת – ניתן לחפש בקטלוג.
apt-cache search
יבצע חיפוש בקטלוג ע”פ מילות מפתח התואמות לכותרת או tags שהוצמדו לחבילה. ניתן בחיפוש להשתמש גם ב regular expressions. שימושיים במיוחד עשויים להיות הסימנים ^ (“מתחיל ב…”) ו $ (“מסתיים ב…”). אם ידוע לכם שם החבילה – אתם יכולים להשתמש בחיפוש ע”פ הכותרת בלבד:
apt-cache search -n
עוד טריק שימושי הוא להעשיר את החיפוש בעזרת grep:
apt-cache search node | grep node
grep הוא כלי בלינוקס שמחפש על steam של טקסט. ה stream, במקרה שלנו, הוא תוצאות החיפוש של apt-cache והוא יחזיר לנו רק שורות בהן הוא מצא את הביטוי שחיפשנו. למה לעזאזל לחפש שוב את המילה node? א. זו דרך לסנן מקרים בהם המילה node הופיעה כ tag ולא בכותרת (דומה ל n-). ב. אנו מקבלים הדגשה נאה של המילה בסבך הטקסט.
אם מצאתם חבילה שנראית לכם אתם יכולים לבקשת עליה פירוט:
apt-cache show
אנונימי ענה בפוסט הקודם והציע את aptitude – תוכנה נוספת של אובונטו. אני שמעתי על aptitude כתחליף מודרני ל *-apt ש (עדיין) לא ממש תפס. כשהפעלתי את aptitude אצלי במחשב ללא פרמטרים, נגלה לעיני TUI (קרי Textual UI) שעשוי להיות דיי נוח לחיפוש חבילות / ניהול חבילות קיימות. תודה לאנונימי על הטיפ!
להלן טבלה המתארת את הפקודות הנפוצות בכלי ניהול חבילות של הפצות שונות. היא עשויה להיות שימושית למדי אם אתם נאלצים להשתמש בהפצה שאתם לא רגילים אליה:
הפעלת package managers בהפצות הראשיות (לחצו להגדלה). מקור (כולל עוד הפצות)
ניהול Repositories
מהן ה Repositories הללו, בהן משתמש apt למצוא אפליקציות?
ה repositories הן מן הסתם שרתים, המנוהלים (אני מניח) ע”י אנשים של אובונטו. יש כמה כאלו, וניתן להירשם לעוד.
את רשימת ה repositories שבשימוש ניתן למצוא בקובץ הקונפיגורציה etc/apt/sources.list/. בקובץ יש רשימה של repositories: חלקן בהערה (קרי: כדי להוסיפן – יש להסיר את ההערה). סוג מסוים של repository, למשל, הוא כונן CD/DVD – במידה ויש לכם דיסק של לינוקס ממנו התקנתם וכעת אתם רוצים להוסיף ממנו אפליקציות (כ”כ מיושן…) סה”כ הפורמט הוא:
deb …
בקובץ ניתן גם לתאר קשרים גם יותר מורכבים, למשל:
deb http://myURL precise-backports main restricted
אומר ש myURL מצביע למיקום בו נמצאים backports (שיש להתאים לפי גרסה מדויקת של אובונטו) ל repositories של main ו restricted.
הנה ה repositories הקיימים של אובונטו:
main – אפליקציות שמגיעות כחלק מאובונטו.
restricted – אפליקציות שמגיעות כחלק מאובונטו, אבל הרישיון שלהן הוא לא חופשי לחלוטין (אולי יש מגבלות מסוימות על ה source או אופן השימוש).
universe – אפליקציות המנוהלות ע”י הקהילה, ולא ע”י אנשי ההפצה של אובונטו או דביאן. נקרא universe, כנראה, כי יש המון אפליקציות כאן.
multiverse – כמו universe, אך אפליקציות בעלות מגבלות של רישיון (הרבה פעמים codecs למיניהם).
partner – אפליקציות הזמינות ע”י שותפים של אובונטו (למשל Adobe reader).
proposed (לא מופיעות בקובץ ב default – רק אם מוסיפים אותה לבד) – אפליקציות חדשות שעדיין לא אושרו ב repositories המרכזיים. סוג של “בטא” או “על אחריותכם”.
הנה סוגי הקשרים ל repositories:
security – תיקוני אבטחה. כדאי תמיד לעדכן.
updates – עדכונים שוטפים. יש הפרדה ברורה בין עדכוני אבטחה (אותם תמיד תרצו לעדכן) ועדכונים פונקציונליים (בעלי סיכון קטן לרגרסיה) – אותם אולי תרצו לבחון לפני שאתם מעדכנים.
extras – אפליקציות שהוסבו לגרסאות קודמות של אובונטו.
backports – אפליקציות שגרסאות חדשות שלהן הוסבו לגרסאות קודמות של אובונטו. כלומר: הגרסה החדשה של האפליקציה נתמכה רק על גרסה y של אובונטו, אבל מישהו התאים אותה גם לגרסה x של אובונטו בה האפליקציה נתמכה בעבר (בגרסה מוקדמת יותר). מקווה שהצלחתם להבין..
deb-src – אלו repositories מקביליים לנ”ל, הכוללים קוד מקור של האפליקציות ולא binaries שכבר קומפלו. חזון הקוד הפתוח.
כפי שציינתי – אתם יכולים להוסיף repositories נוספים, שמנוהלים ע”י מישהו חיצוני. אפשר לנהל repository פנימי של החברה. לאחר עריכת הקובץ כדאי מאוד לקרוא ל apt-get update בכדי לעדכן את הקטלוג מה repositories שנוספו / הוסרו.
הנה אתר שמייצר קובץ source.list וכולל repositories – לבחירתכם.
סיכום
טוב…. הפוסט יצא ארוך משתכננתי. התקנה של אפליקציות באובונטו הוא לא דבר קשה… אך יש כמה וכמה דברים שכדאי לדעת.כיסינו את הדרכים העיקריות להתקנת אפליקציות, ועוד כמה פריטי-מידע על לינוקס/אובונטו – במהלך הדרך.
