תהליך האיתחול ושרותי המערכת

דורון אופק

doron _AT_penguin.org.il

היסטוריית גירסאות
גירסה 1.0 21-05-2007 ליטל ברהום
הומר לפורמאט ויקי
גירסה 1.0 25-07-2002 דורון אופק
גירסא ראשונה


המדריך תחת רשיון ה GFDL

מבוא

מה איך קורה בתהליך האיתחול

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

זכויות יוצרים

כל הזכויות שמורות © 2002 , דורון אופק
הרשות נתונה בזאת להעתיק, להפיץ ו/או לשנות את המסמך הזה, תחת תנאי הרשיון לשימוש חופשי במסמכים של המוסד לתוכנה חופשית, גרסה 1.1 או כל גרסה מאוחרת יותר שתפורסם ע”י המוסד לתוכנה חופשית, כאשר הסעיפים הקבועים הם […], פסקאות העטיפה הקדמית הם […] ופסקאות העטיפה האחורית הם […]. העתק של הרשיון ניתן למצוא בסעיף שכותרתו “רשיון לשימוש חופשי במסמכים”.
השימוש במדריך מותר לשימוש לא מסחרי.
העתקתו / הפצתו מחדש, מותרת בצירוף זכויות היוצרים ובהתאם למפורט ברשיון ה GFDL.
רשיון ה-GFDL זמין כאן:
http://www.gnu.org/copyleft/fdl.html

הערת המחבר

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

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

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

תהליך איתחול מערכת

איתחול המערכת ומנהל האיתחול

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

במערכות לינוקס ניתן למצוא בדרך כלל אחד משני מנהלי איתחול ( lilo ( LInux LOader שהוא הנפוץ יותר או את (GRUB (Grand Unified Boot loader .

מכוון שה lilo נמצא בשימוש מקיף יותר נדבר כרגע עליו.
מנהל האיתחול lilo נשען על הגדרות אשר מצויות בקובץ /etc/lilo.conf וששוכתבו מחדש אל ה MBR .
תהליך התוכנית מורכב משני שלבים, השלב הראשון הינו הגעה אל ה mbr וטעינתו, השלב השני הינו טעינת הקבצים הרלוונטים.
במידה והלילו “נתקע” על אחד שלבים אנו נקבל על כך חיווי אל המסך. בתהליך האיתחול של הלילו נראה את האותיות LILO נכתבות אל המסך , אותיות אלו יספקו לנו את החיווי במידה והתהליך כושל וזאת על פי עצירה בטעינתם או הפעת תווים נוספים.
התווים שר יכולים להופיע בכזו סיטואציה הינם:

L– שלב א' הוטען והתחיל.
LI– שלב ב' נטען.
LIL – שלב ב' התחיל.
LIL? – שלב ב' הוטען בכתובת שגויה.
LIL - שגיאות בטבלת boot.b .
LILO – הכל הוטען כיאות.

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

טעינת ה - kernel

תוך כדי שלב ה lilo , ה kernel של המערכת נטען אל תוך הזיכרון , וזוהי למעשה החשיבות או התפקיד שאותו ה lilo אמור לבצע.
לאחר מכן, ה lilo כבר מסתיים למעשה וה kernel מצוי בזיכרון נכנס ה kernel לתהליכי עבודה, בשלב הראשון מנסה ה kernel ליצור תקשורת / הזדהות מול התקני החומרה שהוא מכיר, ומבצע טעינה של המודולים הדרושים להפעלת התקנים כאלו, במידה והם לא נמצאים אצלו.
בכדי לבצע את זה הוא מבצע mount ל root partition במצב של קריאה בלבד, וטוען את המודולים המתאימים.

לאחר מכן מתחיל ה kernel את התהליך הראשי לטעינת המערכת – הוא תהליך ה init .

תהליך ה - init

בעבר אדם שאני מכיר נשאל “מהו התהליך החשוב ביותר באיתחל הלינוקס” ובכן הוא ענה מייד שטעינת ה kernel הינה התהליך החשוב ביותר.
כמובן שהוא צודק מבחינת חשיבותו של ה kernel – ללא ה kernel מערכת ההפעלה לא תוכל לעבוד. אולם כל מה שתיארנו עד עכשיו אינו “תהליך” אלא פרוצדורה של עליית המחשב.
כל זאת מהסיבה שאילו זה היה תהליך הוא היה אמור כמו כל תהליך לקבל מספר תהליך (PID ), אבל לכל מה שקרה עד עתה אין מספר תהליך ואין תהליכים “בנים” ולפיכך הוא אינו עונה להגדרתו של תהליך.
התהליך הראשוני שמערכת ההפעלה מפעילה הינו תהליך ה init תהליך זה הינו למעשה תהליך האב של כל תהליכי המערכת, מספרו של תהליך זה הינו 1 (PID ) וכל מה שמתרחש החל מרגע עבודתו מוגדר כתהליך ילד שלו.

בשלב הראשון ניגש ה kernel אל הקובץ /etc/inittab , ומתחיל לבדוק הגדרות לגבי רמת הריצה של המערכת (runlevel ) אשר הוא אמור להפעיל ולמעשה “מוליד” את תהליך ה init .

הקובץ inittab

שורות המתחילות עם התו ”#” הינו שורות הערה והמערכת לא מתייחסת אליהן.
(שאר ההערות וההסברים על הקובץ יופיעו בתוכו).

hings to run in every runlevel. \\  ud::once:/sbin/update #
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
#
# Author: Miquel van Smoorenburg,
# Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault: 
  • עד השלב הזה קיבלנו תיאור של רמות הריצה שהקובץ יכול לעבוד בהן, לכל רמת עבודה כזו יש הסבר על איך ולמה , ובסופו של תאור רמות הריצה המערכת מקבלת את הערך default של רמת הריצה הרצויה , בדרך כלל יהיה ערך זה של 3 או 5.
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit 
  • בשלב הזה ישנה הכוונה אל סקריפט טעינה הראשוני של מערכת ההפעלה בקובץ זה קיימות הגדרות של משתני מערכת שונים הנכנסים לפעילות והמועברים אל ה kernel
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
  • בחלק הזה קיימת הכוונה אל תיקיות שונות, לכל runlevel קיימת תיקייה ובה קבצים המגדירים את השירותים הנכנסים לפעילות באותה רמת עבודה, בגלל שקיימים שינויים בין רמות עבודה שונות יש לכל רמת תיקיה עם קישור לקבצים שונים. מי שיבדוק את תוכולת תיקיות אלו יראה שקיימים בהם לינקים (קיצורי דרך) אל התיקיה /etc/rc.d/init.d אשר בה נמצאים הסקריפטים האמיתיים.
# Things to run in every runlevel.
ud::once:/sbin/update 
  • הגדרת פעילות המתאימה לכל רמות הריצה.
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
  • הגדרת פעילות לחיצה על הכפתורים CTRL-ALT-DELETE ביחד (יכבה את המערכת) , ניתן להפוך שורה זאת להערה ובכך למנוע את כיבוי המערכת ע”י גורם לא מוסמך.
# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
  • הגדרות של פעילות UPS (מגן על המחשב במקרה של נפילת מתח).
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
8:2345:respawn:/sbin/mingetty tty8
9:2345:respawn:/sbin/mingetty tty9
10:2345:respawn:/sbin/mingetty tty10
11:2345:respawn:/sbin/mingetty tty11
12:2345:respawn:/sbin/mingetty tty12
  • בשורות אלו נדון נושא הטרמינאלים שאר יעבדו עם איתחול המערכת, קיימות מספר תוכניות טרמינל אשר יכולות לעבוד כולן עוסקות בנושא של התקנים טוריים . תוכניות אלו נבדלות זו מזו במהירות ואיכות עבודתן, המתאימה מבינהן הינה mingetty אולם אם נרצה לאפשר כניסה / ביצוע login למערכת מהתקן סיריאלי אחר ייתכן ונצטרך להפעיל טרמינאלים אחרים על אותו התקן (תוכניות טרמינל). בברירת המחדל לא יהיו 12 מסכים , הקובץ הספציפי הזה עבר הרחבת ל 12 טרמינאלים ווירטואלים.
# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon
  • הגדרת איתחול התהליך הגרפי (לרמת ריצה 5 ).
    ניתן לשים לב כי קיימות מספר “רמות עבודה” בה מערכת ההפעלה יכולה לעבוד.
  • 0 - המערכת מכובה (גם זה מוגדר כמצב עבודה)
  • 1 - מצב שנקרא single user , מצב זה עשוי לעזור כאשר נרצה לטפל בבעיות שונות , במצב זה לא נכנסת לעבודה הרשת ולא נכנסים לעבודה מודולים של אבטחה, לפיכך לא תידרש סיסמה , כל משתמש שייכנס במצב זה יעבוד כ root – זוהי פירצה במערכת ולעיתים יש לסגור אותה (תלוי היכן נמצא המחשב ולאיזו מטרה).
  • 2 - מצב בו עובדים מודולי האבטחה ולפיכך תידרש סיסמה ושם משתמש אולם הרשת אינה פעילה.
  • 3 - מצב בו גם הרשת עובדת אולם לא פעיל המצב הגרפי.
  • 4 - מצב לא מוגדר .
  • 5 - מצב מלא – עם סביבה גרפית.
  • 6- מצב של reboot .

ניתן לשים לב כי קיימות 7 רמות עבודה אולם עבודה יכולה להתממש רק בחמישה מתוכם. קיימת הדרגתיות בין רמות העבודה, כלומר כל רמת מפעילה את הרמה שמתחתיה ביחד עם שינויים ואיפיונים לאותה רמת עבודה ספציפית.
ניתן לעבור בין רמות עבודה שונות ע”י הקשת שם הרמה הרצויה לדוגמה אם אני מצוי ברמה 3 וברצוני לעבור לרמה 5 אני פשוט יקליד init 5 .
כמו כן ניתן לתת בשלב ה lilo פרמטר למערכת לגביי רמת העבודה הרצויה (אם אני רוצה להפעיל ברמת עבודה שונה מרמת ברירת המחדל) אני פשוט יקליד ב lilo הגרפי Ctrl +x בכדי לעבור ל lilo במצב טקסט ולאחר מכן אני יקליד linux 3 (במידה ואני רוצה להפעיל ברמה 3 או כל מספר אחר בהתאם לרמת העבודה הרצויה) – מסייע במצבי תקלה למינהם.

הקובץ rc.sysinit

מי שקרא את הקובץ inittab בוודאי שם לב כי בכל רמות העבודה האפשריות המערכת קוראת בעת תהליך האיתחול את הקובץ rc.sysinit .
קובץ זה נקרא רק כאשר נאתחל את המערכת , המערכת לא קוראת אותו בעת מעבר בין רמות עבודה שונות. ובכן נוכל להניח כי קובץ הסקריפט הזה מגדיר הגדרות אשר יהיו נכונות לכל רמות העבודה, ואכן כך הוא הדבר תפקידו של הקובץ הוא להעביר ל kernel הגדרות לגביי המחשב הספציפי, הסקריפט ניגש לקובצי תצורה שונים ומריץ פקודות שונות בכדי לקבוע פרמטרים שונים ולהעבירם ל kernel .
פרמטרים אלו אינם קבועים (חלקם משתנים בכל איתחול וחלקם עשויים להשתנות ע”י הגדרות המשתמש – root ).
בין פרמטרים אלו ניתן למצוא הגדרות לגביי תיפקודיות המערכת בסביבת הרשת ( פרמטרים של ה kernel ), כגון האם להעביר או לא להעביר חבילות ip , האם לקבל או לא קריאות רשת מסוגים שונים, עם איזה פורטים ( port ) המערכת תעבוד (טווח) וכן הלאה (בעבר ניתן היה ליישם הגדרות אלו ע”י הסקריפט rc.local אולם היום ניתן להעביר פרמטרים אל ה kernel ולקבע פקודיות המערכת ע”י שימוש בקובץ התצורה /etc/sysctl.conf אשר מופעל ע”י rc.sysinit ).
כמו כן מועבר ל kernel הגדרות כגון שמו של המחשב, הגדרות שעה, טעינת מפת מקשים ביצוע mount למחיצת swap , ביצוע mount למחיצת ”/” ( root partition ) ( היא היתה עד עכשיו ב mount במצב של קריאה בלבד כתוצאה מהגדרות ב lilo ), הגדרות RAID – במידה וקיים, הגדרת מכסות משתמש ( quota ) – במידה ויש כאלו, ביצוע mount למערכות קבצים אחרות וכן הלאה.

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

במידה ונבצע עליו עריכה הדבר עשוי להשפיע על איתחול תהליכי המערכת!!!
(אל דאגה עד סופו של הפרק נראה איך כן ניתן לאכוף מדיניות מסויימת על המחשב).

הסקריפטים של init - שלב 2

לאחר שמערכת ההפעלה ביצעה את הסקריפט rc.sysinit היא ניגשת להמשך הרצת הסקריפטים של האיתחול.
מכוון שהמערכת ניגשה כבר לקובץ inittab היא יודעת מהיא רמת העבודה/ רמת הריצה ( run level ) שנמצאת ב default (בברירת המחדל). ולפי כך היא ניגשת להמשך הרצת הסקריפטים המתאימים כלומר שרותי המחשב והרשת המתאימים לאותה רמת ריצה שבחרנו ( כאמור מרמה 1 ועד רמה 6 ).

למעשה כל הסקריפטים לכך נמצאים תחת הספרייה /etc/rc.d/init.d , כל סקריפט שולט על הפעלה של שירות מסויים (ונושא את שמו).

ליד התיקיה init.d ממקמות תיקיות בשם rc1.d, rc2.d, וכן הלאה כל תיקיה כזו מרכזת בתוכה את השירותים המתאימים לאותה רמת עבודה. השירותים ההלו הינם בסה”כ לינק סימבולי ( Slink , קיצור דרך) אל הקובץ האמיתי המצוי תחת init.d .
הלינקים הללו מסומנים בשם , השם מורכב מאות גדולה (S או K ) לאחר מכן מספר סידורי ולאחר מכן בדרך כלל שמו של השירות כפי שמופיע תחת התיקייה init.d .
המספרים הסידוריים נועדו כדי לתזמן את הפעלת השירותים, לדוגמה שרותי הרשת יופעלו לפני הפעלת שרת האינטרנט (web ) קיים הגיון בסדר הפעלת התהליכים מכוון שישנם תהליכים (שירותים) התלויים בקיומם של שירותים אחרים.

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

האותיות S ו K הינן קיצור של המילים Start ו- Kill , כאשר המערכת נכנסת לאותה רמת עבודה היא עוברת על השמות שמתחילים באות ( S (start ולפיכך מפעילה אותם. כאשר המערכת מסיימת את העבודה באותה רמת עבודה כתוצאה מכבוי או ממעבר לרמה אחרת היא משתמשת באלו המתחילים באות ( K (kill ומכבה אותם. בשני המקרים המערכת עוברת על פי הסדר המספרי, המספרים שהמערכת משתמשת בהם הינם מ 1 – 99 כלומר אם הפעלנו שרות עם הספרור 60 (בגלל שהוא תלוי בשרותים אחרים) בכיבוי הוא אמור להיות במספר 40 , בצורה זו המערכת שומרת על איזון בין הפעלה לכיבוי. המערכת יכולה לתת מספר זהה ל 2 תהליכים. הסקריפט ששולט בהדלקת השירותים וכיבויים בתוך רמת העבודה הרצויה הינו הקובץ /etc/rc.d/rc .

הסקריפטים של init - שלב 3

סופו של התהליך הוא בהרצתו של הסקריפט האחרון אשר נקרא /etc/rc.d/rc.local
והא למעשה “סוגר” את תהליך האיתחול, במידה ויש ברצוננו לקבע משתנה שיהיה נכון לכלל המערכת המקומית , ניתן לקבע אותו כאן, במידה ואנו רוצים להריץ תוכנית כלשהיא באופן קבוע באיתחול המערכת אנו יכולים לרשום בסופו של הקובץ את ההפנייה אליה. כל מה שנבצע על קובץ זה (שיכתוב מחדש של משתנים, בנייה של משתנים יחודיים, הרצת תוכניות וכו') יפעלו על כל משתמשי המערכת.

כלים לעריכת האיתחול

ניתן לבצע עריכה ושינוי בכל שלבי התהליך כמעט וזאת ע”י עריכת הקבצים הרלוונטיים לאותו שלב.
אם ברצוננו לשנות את שלב ה lilo , להוסיף או להסיר אלמנטים לאותו שלב איננו יכולים לשנות את קובץ ההרצה עצמו אנו יכולים לשנות את קובץ הקונפיגורציה
(/etc/lilo.conf ) ולהריץ את הפקודה lilo (אפשר עם הפרמטר v ) וליצור בנייה מחדש של ה MBR , בכל המקרים של שינויים בלילו מדובר על שינוי או הוספה של kernel חדש למערכת או בהעברת פרמטרים שונים אל ה kernel , כגון רזולוציה סיסמה לשלב הלילו וכיוצ”ב.
במידה ואנו רוצים לשנות את ה default runlevel – עלינו לערוך את השינוי ב
/etc/inittab , לחילופין ניתן לשנות את איתחול התוכניות שישנם בinittab לדוגמה אם נרצה להוסיף או להסיר טרמינלים למערכת או אם נרצה להפעיל תוכנית טרמינל על התקן חומרה כלשהו (תוכנית טרמינל שתופעל על המודם).
כל השינויים הללו מתבצעים עם עורכי טקסט לקבצים הרלוונטיים כמובן.
בכדי לערוך את השירותים שייכנסו לפעילות בזמן האיתחול ישנה האופציה להוסיף או להסיר את קיצורי הדרך בתיקיה הרלוונטית, לשם כך ישנם גם מספר כלים אשר ניתן לעשות בהם שימוש לקביעת איזה שרותים ירוצו בזמן איתחול המערכת.

  • chkconfig – התוכנית עובדת בשורת הפקודה, מספקת מידע על השירותים והאם הם פעילים או לא, לתוכנית קיימים פרמטרים שונים אשר ניתן לנצל ועל ידי כך לקבוע את פעילותם או אי-פעילותם של שרותים אלו.
    לדוגמה קבלת חיווי על השרותים הפעילים ברמות ההפעלה השונות ניתן לקבל ע”י הפרמטר - - list (הדוגמה עובדה כדי למנוע פלט ארוך ) :
[root@server1 root]# chkconfig --list
keytable     0:off    1:on    2:on    3:on    4:on    5:on    6:off
atd     0:off    1:off    2:off    3:on    4:on    5:on    6:off
syslog     0:off    1:off    2:on    3:on    4:on    5:on    6:off
gpm     0:off    1:off    2:on    3:on    4:on    5:on    6:off
netfs     0:off    1:off    2:off    3:on    4:on    5:on    6:off
network     0:off    1:off    2:on    3:on    4:on    5:on    6:off
random     0:off    1:off    2:on    3:on    4:on    5:on    6:off
iptables     0:off    1:off    2:on    3:on    4:on    5:on    6:off
crond     0:off    1:off    2:on    3:on    4:on    5:on    6:off
anacron     0:off    1:off    2:on    3:on    4:on    5:on    6:off
lpd     0:off    1:off    2:on    3:off    4:off    5:off    6:off
xfs     0:off    1:off    2:on    3:on    4:on    5:on    6:off
portmap     0:off    1:off    2:off    3:on    4:on    5:on    6:off
xinetd     0:off    1:off    2:off    3:on    4:on    5:on    6:off
nfs     0:off    1:off    2:off    3:off    4:off    5:off    6:off
nfslock     0:off    1:off    2:off    3:on    4:on    5:on    6:off
nscd     0:off    1:off    2:off    3:off    4:off    5:off    6:off
sshd     0:off    1:off    2:on    3:on    4:on    5:on    6:off
smb     0:off    1:off    2:off    3:off    4:off    5:off    6:off
httpd     0:off    1:off    2:off    3:off    4:off    5:off    6:off
named     0:off    1:off    2:off    3:off    4:off    5:on    6:off
postfix     0:off    1:off    2:on    3:on    4:on    5:on    6:off
xinetd based services:
    rlogin:    off
    rsh:    off
    ntalk:    off
    talk:    off
    telnet:    off
    wu-ftpd:    on
    imap:    off
    imaps:    off
    ipop2:    off
    ipop3:    off
    pop3s:    off
    swat:    on 
[root@server1 root]#
  • כדי לשים לב כי בתוכנית קיימים 2 חלקים , החלק הראשון אשר עוסק ברמות העבודה השונות והחלק השני העוסק בשרותים אשר תחת xinet .
    tksysv – תוכנית בממשק גרפי אשר מציגה בפנינו מספר רמות עבודה שונות, בעזרת תוכנית זו ניתן גם כן לקבוע איזו שרותים יעבדו באיזו רמה ולמה, לא קיימת בגרסאות האחרונות של red hat , הוחלפה על ידי התוכנית serviceconf .
  • ntsysv – תוכנית מבוססת תפריט, יכולה לעבוד הן בסביבה הגרפית והן בסביבה הטקסטואלית , מאפשרת לערוך את השירותים אשר נכנסים לפעילות עם הדלקת המערכת.
    serviceconf – תוכנית חדשה יחסית, נכנסה במקום tksysv , מאפשר גם כן לערוך את השרותים אשר ייכנסו לפעילות ברמות העבודה השונות.
    ניתן דרך התפריט Edit Runlevel לבצע כיוונון לרמות עבודה שונות מרמת העבודה הנוכחית , כמו כן דרך שימוש בתפריטים ניתן לבצע הפסקה, הדלקה מחדש וכו' של תוכניות.

ניתן להפעיל את התוכנית גם דרך Start Here ⇒ system-settings ⇒ Service Configuration .

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

שרותים במערכת

daemons במערכת

Daemon הינם שרותים אשר קיימים במערכת ומסייעים לתיפקוד שלה, במרבית המקרים יהיה קל לזהות deamon על פי שמו, פשוט בנוסף לשם אשר מתאר את התיפקודיות שלו מוסיפים לו d בסוף השם,כך שלדוגמה httpd הינו ה daemon אשר אחראי לשרותי ה http dhcpd הינו ה daemon שאחראי לשרות חלוקת כתובות ip דינאמיות, klogd הינו ה daemon שאחראי לשרותי ה log של ה kernel ו cron ( או crond ) הינו השירות האחראי לביצוע של תיזמון משימות.
מתוך הדוגמאות המעטות שהוזכרו לעיל, ניתן לראות מספר דברים, האחד הוא שלא תמיד יהיה מצורף ל daemon הוא d (כמו במקרה של cron, sendmail ושרותים רבים אחרים), השני הוא ש daemon אינו בהכרח “שירות” שהמערכת מספקת לרשת, לעיתים daemon מוגדר גם כשירות אשר המערכת מספקת לעצמה (עם זאת אכן חלק גדול משרותי הרשת הינם daemons ).
אם ננסה להגדיר מהו daemon , נגיע למסקנה ש daemon הינו כל סוג של שירות , תהליך, אשר המערכת מספקת הן לעצמה והן לרשת ואשר עובד ברקע.
במרבית המקרים נרצה שאותם שרותים לא יצריכו מאיתנו הפעלה ידנית כלשהיא ושהם יבצעו את עבודתם בצורה אוטומטית ללא התערבות של משתמש כלשהוא, לפיכך קיימים מספר דרכים אשר בעזרתם ניתן להפעיל את אותם שרותים, האיבחון בין הדרכים השונות נעוץ בדרך התיפקוד של אותם deamons .

סוגים שונים של daemons

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

  • תהליכים המופעלים בעת האיתחול על ידי תהליך ה init עצמו, תהליכים אלו יופעלו דרת הקובץ /etc/inittab , במרבית המקרים מדובר על שרותים אשר אינם שרותי TCP ואינם שרותי רשת כלל, דוגמה לתוכניות אלו הינה התוכנית mingetty אשר מופעלת דרך ה inittab על מסכי הטרמינל השונים ולמעשה מספקת את מסך הכניסה אל המערכת (המסך הטקסטואלי), תוכנית זו (בדרך כלל מדובר על תוכניות המקבילות לה ומספקות תיפקודיות דומה) יכולה להיות מכוונת ליציאת המודם או לסוגי יציאות אחרות , תוכנית אחרת שיכולה להיות מופעלת הינה sulogin בעת כניסה אל רמות עבודה ( runlevel ) אשר אינן מוגדרות ב default , או לחילופין התוכנית xdm אשר נכנסת לפעילות ברמת עבודה מסויימת:
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon
  • סוג אחר של תוכניות אשר גם הם מוגדרות כתהליכים עצמאיים , הינם התוכניות המאותחלות ע”י סקריפט עצמאי אשר מצוי בתוך התיקיה /etc/rc.d/init.d/ במרבית המקרים מדובר בשרותים אשר המערכת מספקת לרשת (אולם ייתכנו גם שרותים שהמערכת מספקת לעצמה כגון X font server ), תהליכים אלה נטענים לעבודה ע”י לינקים אשר מצויים בתוך התיקיה המגדירה את רמת הריצה. שליטה ועצירה של תהליכים אלו יכולה להתבצע על ידי פניה ישירה לסקריפט המפעיל או ע”י תוכנית אשר הצגנו אותם מוקדם יותר. במרבית המקרים מדובר על שרותים אשר לצורך עבודתם צריכים להיבדק מספר פרמטרים, באחריות הסקריפט המפעיל לבדוק את קיומם של קבצים שבהם השירות תלוי, לטעון את קובצי הקונפיגורציה השונים וכיוצ”ב. חשוב לציין שקיימת תלות בין תהליכים אלו כך שאם נרצה לשנות את סדר הכניסה לעבודה שלהם , ניתן לעשות כך אולם צריך לשקול זאת מראש, לדוגמה שירות ה httpd ייכנס לעבודה בברירת המחדל לאחר ששירות הפעלת הרשת נכנס לפעילות. בעת כניבה ל runlevel המערכת תפעיל את כל הסקריפטים אשר מתחילים באות S (ולאחר מכן על פי הסדר המספרי) ובעת יציאת מ runlevel המערכת תפעיל את הסקריפטים אשר מתחילים באות K (דבר אשר יביא לסגירת השירות).

transient – תוכניות daemon “ארעיות” , למעשה אלו הם תהליכים אשר נשלטים ע”י שירות שלישי, שירות זה אחראי לפעילות שלהם וקרוי היום xinetd (ראה תזכורת אליו בתוכנית chkconfig אשר מופיע מוקדם יותר בפרק). במרבית המקרים מדובר על שירותים יחסית “חלשים” אין חשיבות קריטית למהירות התגובה שלהם.

שרת xinetd ( Extended Internet Service Daemon )- super server

ראשית ה xinet הינו תהליך אשר עיקר כוונתו לחסוך במשאבי מערכת.
בגרסאות ישנות יותר ניתן למצוא את שרת ה inetd אשר הינו גרסה ישנה יותר של השירות הזה.
אם נחשוב לרגע מה קורה כאשר daemon עצמאי נכנס לפעילות (הכוונה הינה לשירות אשר מצוי תחת /etc/rc.d/init.d ןמוגדר לעבודה בעת כניסה ל runlevel מסויים), התהליך הוא יחסית לא מורכב, עם כניסת ה kernel לעבודה והפעלה של תהליך ה Init , תהליך ה Init יפעיל את אותו שירות אשר מוגדר לעבודה , הסקריפט אשר אחראי על אותו שירות (נניח httpd ) ייוודא את קיומם של הקבצים הנדרשים לפעילות השירות , ובמידה ואין חוסר בקובץ כל שהוא הוא יכניס את התהליך לעבודה, מאותו רגע ה daemon , כמו כל תהליך אחר במערכת , יקבל מהמערכת משאבים כגון זמן עיבוד וזיכרון, בפועל אם לא תתממש פעילות על אותו תהליך , מן הסתם מתי שהוא המערכת תוריד את חלקו אל קובץ ה swap המצוי במערכת .
בכל מקרה התהליך גזל משאבי מערכת , במידה והיו אליו קריאות מלקוחות הוא אכן נתן להם מענה , אולם אם לא היו קריאות מלקוחות הוא פשוט ביזבז משאבים אשר המערכת יכלה לנצל לטובת תהליכים אחרים.
הפתרון לכך נמצא בדמותו של ה inetd (גרסה ישנה יותר) ומה שקרוי בגרסאות החדשות שרת ה xinetd .
הרעיון ברמה הכללית הינו די פשוט , במקום להפעיל את ה daemon עצמו, נפעיל daemon אחר שיבצע את עבודת האזנה ל port של ה daemon , השירות למעשה לא ייכנס לפעילות אבל כאשר תהיה קריאה מלקוח אליו השירות אשר מאזין ל port יפעיל את תוכנת השירות הרלוונטית.
למעשה אם נחזיק שירות כזה על כל daemon שקיים במערכת , לא יהיה הבדל גדול בנושא של ניצול משאבים , מכוון שאותו שירות שאחראי על ההקשבה ל port והפעלה של תוכנת השירות בעצמו צורך משאבים , אבל במידה ושרת כזה יוכל לעבוד בשביל כמה שרותים בו זמנית , אנו מבצעים למעשה חיסכון במשאבי המערכת.

זוהי למעשה תכליתו של שרת ה xinet , להוות daemon אשר יאזין לכל הקריאות לשרותים אשר עובדים תחתיו וכאשר מתקבלת קריאה לשירות מסויים , על בסיס ה port שבו התקבלה הקריאה ה xinetd “יידע” איזה שירות הוא צריך להפעיל , לאחר ההפעלה של אותו שירות השירות “תופס פיקוד” על קיום התקשורת עם הלקוח.
כמו שכבר הוצג, לשיטה זו יש ייתרון בכך שהיא לא גורמת לעומס על המערכת , משאבי המערכת נשארים פנויים ורק כאשר יש צורך אז מופעל שירות , על בסיס קריאה מלקוח.
אולם לשיטה זו יש גם חיסרון מרכזי, מכוון שקיים גורם נוסף אשר נמצא בתווך כלומר בין הלקוח שצריך את השירות ובין השירות עצמו, לוקח לשירות זמן רב יותר לענות לקריאת הלקוח, במידה והשירות היה פעיל (כמו שרותים מסויימים) הוא היה יכול להגיב במהירות יחסית גבוהה לקריאה מלקוח, לעומת זה אם שירות מצוי תחת xinetd , ה xinetd מקבל את קריאת הלקוח, והולך להפעיל את השירות ורק אז השירות משתלט על התקשורת עם הלקוח, ולמעשה מגיב לקריאה .. בתצורה זו הלקוח מחכה יותר זמן לקבלת השירות ולכן כדאי לשקול האם, איך ואילו שרותים להפעיל תחת ה xinetd (בברירת המחדל ייכנסו לעבוד תחתיו שירותים אשר נכנסים יחסית מהר לפעילות , או שירותים “חלשים” יחסית , אבל כמו כל דבר במערכת גם זה ניתן לשינוי).
מכוון שה xinet הינו בעצמו daemon יש לו סקריפט בתוך /ect/rc.d/init.d הוא בעצמו שייך לקבוצת השרותים העצמיים (כי הוא צריך להיכנס לפעילות באיתחול המערכת ולבצע האזנה על השרותי שעליהם הוא אחראי).
קבצים נוספים אשר שייכים לשירות הינם /etc/xinetd.conf והתיקיה /etc/xinetd.d אשר מכילה את קבצי הפעלה של השרותים שעובדים תחת שרת ה xinet .

בתמונת המסך ניתן לראות את התכולה של התיקיה /etc/xinetd.d ואת קובצי הקונפיגורציה אשר מצויים בתוכה, ניתן לראות שקיימים קובצי קונפיגורציה עם הסיומת rpmnew אשר הינם תולדה של התקנה מחדש של התוכנית בתצורה של rpm (אם ה rpm אמור להכניס למערכת קובץ קונפיגורציה והוא מזהה שקיים קובץ קונפיגורציה ישן יותר הוא לא יפגע בו , על מנת לשמר את הקונפיגורציה הקיימת וישים את הקובץ החדש עם הסיומת rpmnew ).

הקובץ /etc/xined.conf

כמו שכבר אמרנו השירות הינו שירות עצמאי ולכן קיים לו סקריפט הפעלה עצמאי תחת התיקיה /etc/init.d ( התיקיה /etc/init.d הינה לינק סימבולי לתיקיה /etc/rc.d/init.d ), במערכות של red hat לרבים מהשרותים במערכת קיים קובץ תחת התיקיה /etc/sysconfig אשר בעזרתו ניתן להעביר פרמטרים שונים וקונפיגורציה מיוחדת אל השירות (על מנת שלא יהיה צורך לשנות את סקריפט ההפעלה לשירות עצמו , השירות מוגדר עם הפעלתו לבדוק אם קיימים פרמטרים נוספים לגביי פעילותו אשר מצויים ב /etc/sysconfig/service_name ), גם לשירות ה xinet קיים קובץ כזה וניתן להעביר אל השירות פרמטרים שונים אשר ישפיעו על אופי הפעילות של השירות.
בנוסף על שני קבצים אלו קיים הקובץ /etc/xinetd.conf אשר מכיל בתוכו הנחיות כלליות אשר ישפיעו על התנהגות השרותים השונים , כלומר בתוך קובץ זה ניתן ליישם הגדרות אשר נרצה שהם ישפיעו על כל השרותים אשר עובדים תחת שרת ה xinetd , תהיה תורשה של ההגדרות מתוך הקובץ הכללי אל קובצי הקונפיגורציה של השרותים.
דוגמה לקובץ כזה:

#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{
    instances = 60
log_type = SYSLOG authpriv
log_on_success        = HOST PID
log_on_failure        = HOST
    cps            = 25 30
}

includedir /etc/xinetd.d

מה שאנו רואים בקובץ זה הינן הגדרות כלליות לשרותים השונים אשר פועלים תחת ה xinet

  • .instances – הגדרת כמות השרתים אשר יכולים להיות פעילים בו זמנים על שירות מסויים , ניתן להשתמש בהגדרה מספרית או בהגדרה של UNLIMITED במידה ולא רוצים לספק מגבלה כלשהיא.
  • log_type – תצורת הרישום של קובצי הרישום של השירות, יכול להכיל את ההגדרה SYSLOG בכדי להפנות את רישום ה log אל שרותי ה log של המערכת (כלומר השרת יירשם בתוך קובצי ה log הרגילים), בדרך כלל מצריך הגדרות נוספות הנוגעות למערכת ה sub-system המספקת את הרישום ורמת הרישום ( log level ). לחילופין ניתן להשתמש במילת המפתח FILE ולהפנות את הרישום אל תוך קובץ רישום עצמאי.
  • log_on_succcess – משמש כדי להגדיר את האירועים שיש לבצע לגביהם רישום כאשר משתמש מתחבר לשירות, מילות מפתח מסמנות את הנתונים אשר יש לבצע לגביהם רישום , כגון: HOST - כתובת המחשב שהתחבר לשירות, PID – רישום ה PID של התהליך על השרת , USERID – רישום זהות המשתמש במידה והמכונה המרוחקת מאפשרת רישום כזה (בתאימות ל RFC 1413 ), מאופיין על שרותי .TCP
  • log_on_faliure – רישום נתונים כאשר מכונה מרחקת נכשלת בכניסה לשירות, כולל מילות מפתח לרישום הארועים.
  • cps – הקמה של מגבלה על כמות ההתקשרויות הנכנסות אל תוך המערכת, המגבלה כוללת שני ערכים, הערך הראשון הינו כמות הכניסות לשניה אשר המכונה יכולה לאפשר, במידה והיו יותר נסיונות כניסה המכונה לא תאפשר זאת, והשירות יהיה לא זמין. הערך השני הינו מספר השניות להמתנה לפני הפעלה מחדש של השירות.
  • includedir – תיקיה אשר מכילה את שאר קובצי הקונפיגורציה (דובר על זה מקודם), במקום להכניס אל קובץ הקונפיגורציה הזה את הקונפיגורציות של השרותים השונים , הקובץ מפנה אל תיקיה אשר בתוכה קיימים קובצי קונפיגורציה נוספים, קובצי קונפיגורציה אלו אמורים להיות במבנה דומה לקובץ הנוכחי ומהווים המשך שלו, בתוך התיקיה הקבצים יכולים לשאת שמות שונים אך בדרך כל הם ישאו את שם השירות, בצורה זו במקום שכל השירותים יהיו רשומים תחת קובץ יחיד גדול (כמו שהיה בגרסה הקודמת הקרויה inetd ) ישנו למעשה קובץ ברירת מחדל (שהו הקובץ /etc/xinetd.conf ) ובתוך התיקיה קיים קובץ עצמאי לכל שירות, הקבצים בתיקייה נקראים ע”י השרת בסדר אלפבתי, ומכילים למעשה מידע על כל שירות עם איפיונים היחודיים לו.
    בהמשך ניגע מעט בקונפיגורציית הקבצים .

קבוצות שרותים תחת xinetd

ניתן לתחום את השרותים המסופקים תחת xinet ל 2 קבוצות של שרותים.
Multi-threaded ו- single-threaded , המאפיין הזה מגדיר את אופן הפעילות של השירות .
אם ננסה להבין מה קורה כאשר מתקבלת קריאה לשירות מסויים , יקל עליו להבין את ההגדרה, נניח לצורך הדוגמה שאנו מדברים על שירות בשם xx כאשר אנו מאתחלים את המערכת xinetd נכנס לפעולה ומאזין לקריאות ב port ששיך לשרת xx כאשר מתקבלת בקשה לשירות מלקוח ברשת שרת ה xinetd מפעיל את השרת xx . עד כאן קיימת זהות בעבודת 2 קבוצות השרתים.
במידה והשרת xx הינו single-threaded , שרת ה xinetd מפעיל אותו ומפסיק להאזין לקריאות של לקוחות ב port שייך לשרת xx , למעשה שרת xx “לוקח פיקוד” ומטפל הן בקריאה שבגללה הוא הופעל והן בקריאות של לקוחות נוספים אשר מתקבלות כאשר הוא פעיל. שרת ה xinetd יחזור להאזין על ה port של xx כאשר שרת ה xx יסיים את הטיפול בכל הלקוחות ולמעשה התהליך שלו יגיע לקיצו (ימות).
מצד שני אם שרת ה xx עובד בתצורה של multi-threaded , שרת ה xinetd מפעיל אותו וממשיך להאזין על ה port שלו, כאשר מתקבלת קריאה חדשה שרת ה xinetd יצור הפעלה שוב של השרת , כלומר כל הפעלה של השרת מטפלת ב connection יחיד.

תצורת קובץ ההגדרה של שרתים תחת xinetd

כמו שכבר נאמר, קיימת התיקיה /etc/xinetd.d/ אשר מכילה בתוכה קובצי תצורה לשרתים השונים העובדים תחת המעטפת של שרת ה xinetd .
למעשה שרת ה xinetd משתמש בקובץ xinetd.conf כקובץ ההגדרה שלו שאותו ממשיכים הקבצים המצויים בתיקיה /etc/xinetd.d/ (הם לכאורה נטענים אליו בסדר אלפבתי) , הכוונה מאחורי יצירת מבנה מוצל היא שאין צורך להחזיק קובץ אחד גדול אשר שירותים רבים בו לא יהיו מיושמים כלל, בתצורה מבוזרת ניתן למעשה להחזיק קובצי קונפיגורציה רק של השרותים שאכן מותקנים במערכת (שירות שאין אנו צריכים אותו וודאי לא יהיה מותקן כלל ).
לפיכך קובץ התצורה לכל שירות ושירות הינו למעשה מקטע בקובץ התצורה של השרת ( xinetd ).
דוגמה לקובץ תצורה של שירות ה ftp ( wu-ftp )

# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
#    normal, unencrypted usernames and passwords for authentication.
service ftp
{
    disable    = no
    socket_type        = stream
    wait            = no
    user            = root
    server            = /usr/sbin/in.ftpd
    server_args        = -l -a
    log_on_success        += DURATION USERID
    log_on_failure        += USERID
    nice            = 10
}

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

  • disable – יכול להכיל את הערכים yes או no , מציין האם השירות הינו פעיל או לא.
  • socket_type – מתאר את תצורת התקשורת שבה השירות עובד, בדרך כלל יכיל את הערכים stream – עבור תקשורת TCP , dgram – עבור תקשורת UDP (datagram ), raw – שירות אשר ניגש בצורה ישירה ל ip
  • wait – יכול להכיל את הערכים yes בעבור שירות אשר עובד בתצורה של single-threaded או no בעבור שירות המאופיין כ multi-threaded (ראה הסבר לעיל).
  • user – משתמש אשר על תהליך השירות פועל על ה uid שלו.
  • server – ניתוב אל תוכנית אשר תפעל כאשר ה xinetd יצטרך להפעיל את השרת , זהו למעשה ניתוב אל תוכנית השרת.
  • server_args - ארגונמטים אשר יועברו לשרת כאשר הוא יאותחל על ידי ה xined , ארגומנטים אלו לא יכללו את שם השרת , אלא רק את הפרמטרים שנרצה להפעיל עליו.
  • log_on_success – בדיוק כמו בהגדרה אשר מופיעה ב xinetd.conf (ראה לעיל) ניתן לראות כי יש כאן שימוש ב += , בכוונה היא להיוסיך את הערכים הללו לערכים הקיימים ב default , במידה והיה מופיע -= הכוונה היתה להסיר ערכים (יש לציין שלא כל סוגי ההגדרות מאפשרות את השימוש בתווים אלו).
  • log_on_failure – נידון לעיל , בקובץ xinetd.conf .
  • nice – רמת הקדימות אותה יקבל תהליך השרת כאשר יופעל. המספר יכול לנוע בין -20 (קדימות גבוהה) לבין 19 (קדימות נמוכה).

הגדרות מתקדמות לשימוש

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

שירות ה xinetd כוון לתמוך במכניזם libwrap , מכניזם זה מאפשר לדחות או לקבל קריאות ממשתמשים על בסיס המיקום ממנו הם מגיעים – בסופו של דבר המכניזם הזה מתיישם מול כתובת ה ip של הלקוח. הכוונה היא שניתן לכוון את השירות לענות או לא לענות לקריאה מצד לקוח בהתבסס על ה ip או הרשת ממנה הוא מבקש את השירות, דרך מימוש עבודה עם מכניזם שזה ניתן ליצור למעשה acl ( access control list ) של התחנות שלהם מותר להתחבר לשירות, קבצים רלוונטים לקביעת התנהגות זו הינם /etc/hosts.allow ו- /etc/hosts.deny .
מעבר למכניזם זה ניתן לקבע היישר בתוך השירותים של xinetd בקרת גישה כזו, במידה והמערכת עובדת עם המכניזמים הללו, כאשר לקוח יבקש להתחבר לשירות הוא ייבדק כנגד ה tcp-wrapper (קובצי התצורה של libwrap ) במידה והוא רשאי לגשת לשירות יפעל המנגנון acl הקיים בתוך ה xinetd.

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

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

פרמטרים אשר יכולים להיות מועברים בהגדרות אלו הינם מספרי תחנה (ip של תחנה) , כתובות ip של רשתות, שמות של רשתות (בהתבסס על NIS או על /etc.network ) ושמות FQDN של רשתות או תחנות. דוגמה לקובץ שכזה:

# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
#     to configure your Samba server. To use SWAT, \
#     connect to port 901 with your favorite web browser.
service swat
{
    disable    = no
    port        = 901
    socket_type    = stream
    wait         = no
    only_from     = 127.0.0.1
    user        = root
    server        = /usr/sbin/swat
    log_on_failure    += USERID
}

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

# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
#     to configure your Samba server. To use SWAT, \
#     connect to port 901 with your favorite web browser.
service swat
{
    disable    = no
    port        = 901
    socket_type    = stream
    wait         = no
    no_access    = 192.168.1.0 192.168.{2,3} station1.test.org .test.com
    user        = root
    server        = /usr/sbin/swat
    log_on_failure    += USERID
}

דוגמה שניה תידחה גישה מתוך הרשתות 192.168.1.0 192.168.2.0 192.168.3.0 כמו כן תידחה הגישה מתחנה בשם station1 בארגון test.org ותידחה כניסה מכל הארגון test.com .

בקרה על כמות ההתקשרויות ממקור יחיד

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

# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
#    normal, unencrypted usernames and passwords for authentication.
service ftp
{
    disable    = no
    socket_type        = stream
    wait            = no
    user            = root
    server            = /usr/sbin/in.ftpd
    server_args        = -l -a
    log_on_success        += DURATION USERID
    log_on_failure        += USERID
    nice            = 10
    per_source        = 1
} 

בדוגמה הלקוח מוגבל לקיום של התקשרות אחת אל השירות.

מגבלה על זיכרון או על זמן cpu

ניתן לתחום את התהליכים במגבלות על כמות הזיכרון או זמן ה cpu שהם יוכלו להשתמש בו , כדי ליישם זאת ניתן להשתמש בהגדרות rlimiy_as - כדי לתחום כמות זיכרון או rlimiy_cpu כדי לתחום זמן עבודת cpu
לדוגמה:

 # Limit telnet sessions to 8 Mbytes of memory and a total
# 20 CPU seconds for child processes.
service telnet
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}

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

סקירה קצרה על השרותים המופעלים בעת איתחול המערכת

מהם השרותים המופעלים בעת האיתחול ...

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

  • amanda – שירות גיבוי רשתי.
  • amd – שירות ביצוע mount אוטומטי על פי קריאה, automounter אשר מקורו ב BSD
  • anacron – שירות אשר מוגדר להריץ פעילויות cron אשר זמן הפעלתן היה כאר המערכת היתה מכובה.
  • apmd - שרת “ניהול כח מתקדם” חשוב מאוד למחשבים ניידים, מספק יכולות ניטור לסוללה וכיבוי מערכת כאשר סוללה עומדת להגמר.
  • arpwatch – שירות אשר משתמש למעקב אחר כתובות MAC של תחנות ברשת וה – ip שלהן .
  • atd – שירות המאפשר להריץ תוכניות בזמנים עתידיים באופן אוטומטי.
  • autofs – שירות המאפשר ביצוע mount להתקנים מקומיים והתקנים רשתיים , לאחר פרק זמן אשר לא תיתבצע פעילות על אותם התקנים יבוצע umount באופן אוטומטי.
  • bgpd – שירות אשר הינו חלק משירות zebra ואשר מספק יכולת עבודה עם פרוטוקולי רשת שונים כגון BGP4 ו - BGP4+ .
  • crond – שירות סטרנדרטי בעולם ה unix אשר נועד כדי לספק תיזמון של משימות בצורה רוטינית. * (dhcpd (Dynamic Host Control Protocol – שירות רשתי אשר מספק קונפיגורציית tcp לתחנות ברשת
  • gated – שרת ניתוב, routing daemon , המספק יכולות עבודה עם פרוטוקולי ניתוב שונים.
  • gpm – מספק יכולת לעבוד עם עכבר ועם תוכניות שונות המבוססות תפריטים.
  • httpd – שרת ה apache , מספק שרותי wb ללקוחות.
  • identd – שרת המאפשר זיהוי משתמשים מרחוק.
  • imap/imaps – פרוטוקול דואר ( וגרסה שלו עם ssl ) המאשפר למשתמש למשוך דואר מחשבון דואר על שרת מרוחק, או לנהל את הדואר על אותו שרת.
  • ipcaines - אתחול של חוקי “חומת האש” של המחשב ( התוכנית הנ”ל הינה מיושנת מעט אולם מספיקה בדר”כ למשתמש ביתי ).
  • iptables – אתחול תוכנית ה firewall – קיימת החל מ kernel 2.4 מספקת מימדי גמישות ויכולות עבודה גבוהות ביחס ל .ipchains
  • ipop2/ipop3 – שרותי פרוטוקול ( pop ( postoffice protocol , בגרסאות 2 ו-3 פרוטוקול זה משמש למשיכת דואר משרת הדואר.
  • irda – שרותי אינפרה-אדום , לטובת התקנים אשר עובדים בפרוטוקול זה, מצריך הפעלת תמיכה בתוך ה kernel .
  • iscsi – תוכנית שרות אשר משמשת לאיפשור גישה להתקני scsi על תשתית .ip.
  • isdn – שרות עבודה עם התקני isdn .
  • junkbuster – שירות שמשמש להאצת העבודה באינטרנט בכך שהוא חוסם את תוכנית הדפדפן מלהפעיל חלק מהמידע הפירסומי המופיע באינטרנט.
  • keytable – מאתחל הגדרות מקלדת.
  • kudzu - מגלה חומרה חדשה ומתקין אותה. אותה פונקציונליות כמו היכולת של חלונות לזהות חומרה חדשה בזמן אתחול.
  • ldap – שרותי ספריית הרשת העובדים תחת פרוטוקול LDAP ( Lightweight Directory Access Protocol ).
  • lpd - line printing daemon , שירות מדפסות.
  • mysql – שרות database ( sql server ).
  • named – שרות DNS , מדובר בתוכנית BIND .
  • netfs – שירות המאחזר חיבורי רשת, הכוונה היא לשרותי שיתוף על בסיס פרוטוקול NFS ( Network Filesystem ), SMB (Lan Manager/Windows ו- NCP ( NetWare ).
  • network - אתחול התקני הרשת .
  • nfs – Network Filesystem , שירות שיתוף קבצים בסביבת Unix\Linux .
  • nfslock – שירות יצירת נעילת קבצים על פרוטוקול nfs .
  • ntpd - Network Time Protocol , שרת ה”מייצא” שרותי שעון לכלל הרשת.
  • ospfd – תת שירות תחת zebra , מדובר בפרוטוקול ניתוב אשר יכול לשמש את המערכת כנתב דינאמי.
  • pcmcia – שירות המספק יכולת עבודה מול התקני pcmcia , בדרך כלל ניתן למצוא התקנים כאלו במחשבים נישאים.
  • portmap – שירות המנהל את קישורי ה RPC של המערכת, שרותי RPC הינם שרותי בסיס שעליהם נשענים שרותים כגון NFS , NIS ועוד.
  • postfix – שרותי (זMTA ( Mail Transport Agent , מדובר לעשה בשרת דואר.
  • postgresql – שירות database .
  • random – איתחול של מאגר של מספרים אקראיים המשתמשים את המערכת בשרותים שונים (כגון שרותי הצפנה), קיימות במערכת 2 שיטות להפעלת מספרים אקראיים, השירות מאתחל אחת משיטות אלו.
  • rarpd – שרת המאחזר מידע על כתובות MAC של תחנות וכתובות ה IP שלהם.
  • rawdevices - ניהול התקני אכסון במצב raw . בשביל מסדי נתונים מתקדמים כמו Oracle , שירות זה מספק למעשה גישה ישירה להתקני כונן.
  • syslog – הפעלת מערכת הלוגים של לינוקס (קובצי היומן).
  • sshd – שרותי shell מאובטחים, שירות זה מחליף שרותי גישה מרחוק כגון telnet , rlogin , rexec וכו' אשר לא מספקים אבטחה על השירות.
  • tux – שירות httpd אשר עובד היישר מתוך ה kernel .
  • sendmail - שרת הדואר הנפוץ ביותר באינטרנט.
  • xfs - שרת הגופנים ל-X ( X Font Server )
  • zebra - תוכנית ניהול לפרוטוקולי ניתוב.
  • יש לציין כי לא נסקרו כאן כל השירותים , קיימים עוד שירותים רבים אשר עשויים להיות מופעלים בתהליך האיתחול.
מדריכים/תהליך_האיתחול_ושרותי_המערכת.txt · שונה לאחרונה ב: 2008/06/19 18:34 (עריכה חיצונית)
chimeric.de = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0