התקנת אפליקציות בלינוקס

בפוסט הקודם (אובונטו - התמצאות בסיסית) תיארתי כלי בשם 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) ישמרו בד"כ על הקונבנציה הבאה:

<lib name>-<version>-<build number>-<architecture>.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 filename>.tar <target directory>

הפרמטרים של פקודת tar הם: x - פתיחת קובץ, v - פירוט הפעולות המתבצעות (קרי verbose) ו f - שהפעולה מתייחסת לקובץ קיים (בפעולות פתיחה, flag זה תמיד נדרש).

קובץ ה tar יכול להיות גם בעל סיומות מעט שונות כמו tgz או tar.gz - כאשר קובץ ה tar דחוס בדחיסת gzip. ייתכנו סיומות אחרות לקובץ - לתאור דחיסות אחרות.

tar.gz ארוז ואז דחוס. מקור: וויקיפדיה

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

כאשר יש אפליקציה מוכנה להפעלה, פשוט יש להעביר את הקבצים למיקום הגיוני: אם זה קובץ בינארי בודד - לתיקיה user/local/bin/ (שנמצאת ב path ונועדה לצרכים אלו), אם זו תיקיה של קבצים - אולי לתת-תיקייה שלה (+ הוספה של התיקיה ל path).

יתרונות של הפצה בקובצי tar:

• מתאימים לכל הפצות הלינוקס
• ניתן להתקין תוכנה ללא הרשאות root.

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



אם קובץ ה tar לא כולל executables מוכנים להפעלה, זה אומר שקיבלנו source code שיש לבנות. זוהי דרך ההתקנה השלישית לאפליקציות בלינוקס. דרך נפוצה נוספת (ואולי יותר מקובלת) לקבל קוד מקור היא בעזרת פקודת git clone (פוסט למי שלא מכיר git). העתקת קוד המקור לצורך בנייתו והתקנת התוכנה, לא נחשבת כ hack - אלא דרך מקובלת ולגיטימית. אפליקציות רבות (למשל: redis) מציעות דרך זו כדרך ההתקנה המועדפת או היחידה שלהן.

מקור

כאשר אנו הולכים לבנות אפליקציה מקוד המקור שלה, הדבר המומלץ הראשון לעשות הוא לרפרף על ההוראות לפני שאנו מבצעים על מיני פעולות עם משתמש-העל (sudo). כמעט תמיד יהיה קובץ README ארוז בחבילה. פשוט הכנסו לתיקיה והקלידו "cat README.md | less".

למי שלא מכיר, סימן ה pipe (|) גורם ללינוקס לנתב את הפלט של התוכנה שלפני ה pipe, כקלט לתוכנה שאחרי ה pipe. ניתן לשרשר מספר רב של pipes להרכבת פעולה מורכבת. בדוגמה לעיל: less (שהוא viewer עם paging פשוט בלינוקס) מקבל כקלט את הפלט של cat (תוכן הקובץ) ומציג אותו עם יכולות דפדפוף.

הערת צד: השימוש ב pipe הוא אחד העקרונות התכנוניים של יוניקס / לינוקס:

1. "Write programs that do one thing, and do it well"
2. "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.

לינק: תיעוד נוסף על משתני הסביבה.

ניהול חבילות בעזרת apt

זהו. הגענו לחלק בו אסביר על שימוש מקיף יותר ב package manager, ובעיקר בכלי של אובונטו: apt. אני עלול לחזור על כמה פריטי-מידע מהפוסט הקודם.

כדי להתקין חבילה, יש פשוט להקליד:

sudo apt-get install <package name>

למשל: sudo apt-get install nodejs. אם החבילה כבר מותקנת, apt יניח שאנו רוצים לעדכן אותה לגרסה האחרונה.

הסרת חבילה נעשית ע"י:

sudo apt-get remove <package name>

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

sudo apt-get purge <package name>

update vs. upgrade

יש שתי פקודות דומות ב apt - שעושות דברים שונים מאוד:

apt-get update - תעדכן את קטלוג התוכנות הזמינות ב repositories.

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

 "number> not upgraded>" - זה אומר שכמה אפליקציות לא אופגרדו (עודכנו) מכיוון שיש להן תלויות חדשות. עליכם לעדכן אותן ידנית בעזרת apt-get install ולאשר את התלויות החדשות. בכדי להסיר תלויות שכבר אינן בשימוש יש להשתמש ב apt-get autoremove.

מציאת חבילות להתקנה

אני חושב שהדרך הכי נוחה לחפש חבילות קיימות היא בגוגל. בכל זאת - ניתן לחפש בקטלוג.

apt-cache search <search term>

יבצע חיפוש בקטלוג ע"פ מילות מפתח התואמות לכותרת או tags שהוצמדו לחבילה. ניתן בחיפוש להשתמש גם ב regular expressions. שימושיים במיוחד עשויים להיות הסימנים ^ ("מתחיל ב...") ו $ ("מסתיים ב..."). אם ידוע לכם שם החבילה - אתם יכולים להשתמש בחיפוש ע"פ הכותרת בלבד:

apt-cache search -n <search terms in title>

עוד טריק שימושי הוא להעשיר את החיפוש בעזרת grep:

apt-cache search node | grep node

grep הוא כלי בלינוקס שמחפש על steam של טקסט. ה stream, במקרה שלנו, הוא תוצאות החיפוש של apt-cache והוא יחזיר לנו רק שורות בהן הוא מצא את הביטוי שחיפשנו. למה לעזאזל לחפש שוב את המילה node? א. זו דרך לסנן מקרים בהם המילה node הופיעה כ tag ולא בכותרת (דומה ל n-). ב. אנו מקבלים הדגשה נאה של המילה בסבך הטקסט.
אם מצאתם חבילה שנראית לכם אתם יכולים לבקשת עליה פירוט:

apt-cache show <package name>

אנונימי ענה בפוסט הקודם והציע את aptitude - תוכנה נוספת של אובונטו. אני שמעתי על aptitude כתחליף מודרני ל *-apt ש (עדיין) לא ממש תפס. כשהפעלתי את aptitude אצלי במחשב ללא פרמטרים, נגלה לעיני TUI (קרי Textual UI) שעשוי להיות דיי נוח לחיפוש חבילות / ניהול חבילות קיימות. תודה לאנונימי על הטיפ!

(לחצו להגדלה). מקור: וויקיפדיה.

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

הפעלת package managers בהפצות הראשיות (לחצו להגדלה). מקור (כולל עוד הפצות)

ניהול Repositories

מהן ה Repositories הללו, בהן משתמש apt למצוא אפליקציות?
ה repositories הן מן הסתם שרתים, המנוהלים (אני מניח) ע"י אנשים של אובונטו. יש כמה כאלו, וניתן להירשם לעוד.

את רשימת ה repositories שבשימוש ניתן למצוא בקובץ הקונפיגורציה etc/apt/sources.list/.  בקובץ יש רשימה של repositories: חלקן בהערה (קרי: כדי להוסיפן - יש להסיר את ההערה). סוג מסוים של repository, למשל, הוא כונן CD/DVD - במידה ויש לכם דיסק של לינוקס ממנו התקנתם וכעת אתם רוצים להוסיף ממנו אפליקציות (כ"כ מיושן...) סה"כ הפורמט הוא:

deb <repository url> <distro matching> <repository name 1 > ... <repository name n>

בקובץ ניתן גם לתאר קשרים גם יותר מורכבים, למשל:

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 - לבחירתכם.

סיכום

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

כיסינו את הדרכים העיקריות להתקנת אפליקציות, ועוד כמה פריטי-מידע על לינוקס/אובונטו - במהלך הדרך.


שיהיה בהצלחה!

---

קישורים:
מדריך לשימוש ב apt של דביאן.


---

[א] סתם. הוא מספק את מימד הזמן, אבל לא מציין את הקשרים "החיים" בין ההפצות.