אתה משתמש בדפדפן מיושן. יתכן והאתר הנוכחי יוצג באופן שגוי, כמו כן אתרים אחרים ברשת.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
אנא שדרג את הדפדפן או השתמש בדפדפן חילופי.
הפעלה אוטומטית
- פותח הנושא בוטש
- פורסם בתאריך
באיזו הפצה?
באופן עקרוני יש שתי דרכים: דרך אחת - להוסיף פקודה בקובץ etc/rc.loacl/ (הפקודה תרוץ לאחר שעלו כל שרותי המערכת) דרך שניה - אם רוצים שהשרות יעלה בזמן מסויים ב-boot, שמים קובץ הרצה המקבל את הפקודות start ו-stop בספריה בשם etc/init.d/, ויוצרים קישור אליה מספריה המתאימה ל-runlevel. שם הקישור צריך להתחיל באות S עבור התחלת השרות או באות K עבור סיומו, ובמספר בן שתי ספרות המורה על המיקום של השרות בין כל השרותים. לדוגמה: אם אתה רוצה להריץ apache ב-runlevel 3 אתה עושה את הצעדים הבאים: 1. שם קובץ הרצה ב-etc/init.d/apache/ 2. מקשר ל-runlevel כך: ln -s /etc/init.d/apache /etc/rc3.d/S94apache אם מדובר בשרות שקיים במערכת, אבל לא רץ באופן אוטומאטי - תצטרך להשתמש באפשרות השניה. אם מדובר בפקודה שאתה רוצה להריץ בכל אתחול, תוכל להשתמש בדרך הראשונה. ואם אין לך redhat או mandrake, זה יכול להיות שונה.
באופן עקרוני יש שתי דרכים: דרך אחת - להוסיף פקודה בקובץ etc/rc.loacl/ (הפקודה תרוץ לאחר שעלו כל שרותי המערכת) דרך שניה - אם רוצים שהשרות יעלה בזמן מסויים ב-boot, שמים קובץ הרצה המקבל את הפקודות start ו-stop בספריה בשם etc/init.d/, ויוצרים קישור אליה מספריה המתאימה ל-runlevel. שם הקישור צריך להתחיל באות S עבור התחלת השרות או באות K עבור סיומו, ובמספר בן שתי ספרות המורה על המיקום של השרות בין כל השרותים. לדוגמה: אם אתה רוצה להריץ apache ב-runlevel 3 אתה עושה את הצעדים הבאים: 1. שם קובץ הרצה ב-etc/init.d/apache/ 2. מקשר ל-runlevel כך: ln -s /etc/init.d/apache /etc/rc3.d/S94apache אם מדובר בשרות שקיים במערכת, אבל לא רץ באופן אוטומאטי - תצטרך להשתמש באפשרות השניה. אם מדובר בפקודה שאתה רוצה להריץ בכל אתחול, תוכל להשתמש בדרך הראשונה. ואם אין לך redhat או mandrake, זה יכול להיות שונה.
דורון אופק
New member
הייתי רק מוסיף ..
שהיא אחלה צודקת .. אבל אם מדובר ביישום שלא בנית אותו לבד - כלומר התקנה מסודרת של אפליקציה כלשהיא, בדרך כלל תהליך ההתקנה ידאג לשים את הקבצים במקומות הנכונים .. ואז כל מה שיש לך לעשות הוא לדאוג להפעלת השירות וגם לכך יש כלים אוטומטים כמו tksysv , ntsysv ,chkconfig וכיוצ"ב
שהיא אחלה צודקת .. אבל אם מדובר ביישום שלא בנית אותו לבד - כלומר התקנה מסודרת של אפליקציה כלשהיא, בדרך כלל תהליך ההתקנה ידאג לשים את הקבצים במקומות הנכונים .. ואז כל מה שיש לך לעשות הוא לדאוג להפעלת השירות וגם לכך יש כלים אוטומטים כמו tksysv , ntsysv ,chkconfig וכיוצ"ב
דורון אופק
New member
ידעתי גם ידעתי... ../images/Emo13.gif
כל התקנה מקובצי מקור תצריך פעולות כאלו , אלא אם כן הכניסו בתוך התיקייה שלה סקריפט כל שהוא להתקנה אשר ייקח קבצים כאלו (שגם אמורים להיות מוכנים שם ) יעתיק אותם אל /etc/init.d... וכו´ ולאחר מכן יקבע את ההפעלה שלהם ... ...נראה לי שאחרי קצת זמן שאני מתעסק עם לינוקסים הספקתי כבר לראות כמעט את כל הפטנטים האפשריים בנושא .. .. אני חושב שהדבר הכי חמוד בנושא הזה שראיתי לאחרונה הוא שימוש בlynx בכדי למשוך קובצי קונפיגורציה מתוך הרשת או מתוך האינטרנט אל מיקום ספציפי אצל הלקוח, כלומר לא רק שמתבצעת התקנת התוכנית אלל תוך כדי ההתקנה ניתן כבר לכוון את התוכנית ע"י שקיים אתר web (או ברשת הפנימית או באינטרנט) ואז תוכנית הלקוח פונה אליו ומושכת את קובץ הקונפ´ המתאים ספציפית אליה אל תוך המיקום שהוא מוגדר לעמוד בו.... רעיון חביב ..
כל התקנה מקובצי מקור תצריך פעולות כאלו , אלא אם כן הכניסו בתוך התיקייה שלה סקריפט כל שהוא להתקנה אשר ייקח קבצים כאלו (שגם אמורים להיות מוכנים שם ) יעתיק אותם אל /etc/init.d... וכו´ ולאחר מכן יקבע את ההפעלה שלהם ... ...נראה לי שאחרי קצת זמן שאני מתעסק עם לינוקסים הספקתי כבר לראות כמעט את כל הפטנטים האפשריים בנושא .. .. אני חושב שהדבר הכי חמוד בנושא הזה שראיתי לאחרונה הוא שימוש בlynx בכדי למשוך קובצי קונפיגורציה מתוך הרשת או מתוך האינטרנט אל מיקום ספציפי אצל הלקוח, כלומר לא רק שמתבצעת התקנת התוכנית אלל תוך כדי ההתקנה ניתן כבר לכוון את התוכנית ע"י שקיים אתר web (או ברשת הפנימית או באינטרנט) ואז תוכנית הלקוח פונה אליו ומושכת את קובץ הקונפ´ המתאים ספציפית אליה אל תוך המיקום שהוא מוגדר לעמוד בו.... רעיון חביב ..
דורון אופק
New member
ידעתי גם ידעתי... ../images/Emo13.gif
כל התקנה מקובצי מקור תצריך פעולות כאלו , אלא אם כן הכניסו בתוך התיקייה שלה סקריפט כל שהוא להתקנה אשר ייקח קבצים כאלו (שגם אמורים להיות מוכנים שם ) יעתיק אותם אל /etc/init.d... וכו´ ולאחר מכן יקבע את ההפעלה שלהם ... ...נראה לי שאחרי קצת זמן שאני מתעסק עם לינוקסים הספקתי כבר לראות כמעט את כל הפטנטים האפשריים בנושא .. .. אני חושב שהדבר הכי חמוד בנושא הזה שראיתי לאחרונה הוא שימוש בlynx בכדי למשוך קובצי קונפיגורציה מתוך הרשת או מתוך האינטרנט אל מיקום ספציפי אצל הלקוח, כלומר לא רק שמתבצעת התקנת התוכנית אלל תוך כדי ההתקנה ניתן כבר לכוון את התוכנית ע"י שקיים אתר web (או ברשת הפנימית או באינטרנט) ואז תוכנית הלקוח פונה אליו ומושכת את קובץ הקונפ´ המתאים ספציפית אליה אל תוך המיקום שהוא מוגדר לעמוד בו.... רעיון חביב ..
כל התקנה מקובצי מקור תצריך פעולות כאלו , אלא אם כן הכניסו בתוך התיקייה שלה סקריפט כל שהוא להתקנה אשר ייקח קבצים כאלו (שגם אמורים להיות מוכנים שם ) יעתיק אותם אל /etc/init.d... וכו´ ולאחר מכן יקבע את ההפעלה שלהם ... ...נראה לי שאחרי קצת זמן שאני מתעסק עם לינוקסים הספקתי כבר לראות כמעט את כל הפטנטים האפשריים בנושא .. .. אני חושב שהדבר הכי חמוד בנושא הזה שראיתי לאחרונה הוא שימוש בlynx בכדי למשוך קובצי קונפיגורציה מתוך הרשת או מתוך האינטרנט אל מיקום ספציפי אצל הלקוח, כלומר לא רק שמתבצעת התקנת התוכנית אלל תוך כדי ההתקנה ניתן כבר לכוון את התוכנית ע"י שקיים אתר web (או ברשת הפנימית או באינטרנט) ואז תוכנית הלקוח פונה אליו ומושכת את קובץ הקונפ´ המתאים ספציפית אליה אל תוך המיקום שהוא מוגדר לעמוד בו.... רעיון חביב ..
דורון אופק
New member
אופס ... ../images/Emo13.gif
דורון אופק
New member
חשוב לציין ..
ישנם מקרים שבהם לא תמיד כדאי לעבוד בשיטת ה rc.local בגלל כמה סיבות. השיטה הזו טובה במידה ואתה רוצה או צריך להפעיל פקודה ספציפית מסויימת אבל אני לא הייתי משתמש בה בהכרח גדי להפעיל שרת. בעבר היה נהוג להשתמש בקובץ כדי להעביר פרמטרים שונים ל kernel ע"י יישום של פקודות כגון echo 1>/proc/sys/net/ipv4/ip_forward אולם כיום ניתן להשתמש בקובץ /etc/sysctl.conf שמבצע את העבודה בצורה יותר נכונה מאשר rc.local (הוא מבצע בסה"כ את אותה עבודה- אבל בתזמון שונה).. כאמור כל פקודה שתרצה אפשר ליישם כאן והיא אכן תיכנס לפעילות בכל הפעלה של המערכת. אולם, כאשר מדובר בשרת שאנו רוצים שיעבוד במקרים רבים חלק מהשרתים עם הפעלתם פותחים תהליכים שונים וקבצים שונים (בדרך כלל במקומות זמניים (/tmp ) או תחת התיקייה /var ). כאר אתה מבצע סגירה של המערכת או reboot שרתים אלו כמו שתמר כבר הסבירה למעשה מסיימים את פעולתם בצורה מסודרת דרך הסקריפטים של system V . שרת שהפעלת אותו דרך rc.local למעשה לא עובר את "חווית הכיבוי המסודר" ופעולתו למעשה נפסקת בצורה "אלימה" יחסית דבר שעשוי לגרור בעיות בהפעלה הבאה שלו. לפיכך תלוי מה אתה כן רוצה להפעיל דרך קובץ זה .. פשוט תבדוק מה קורה עם כיבוי של אותה תוכנית.
ישנם מקרים שבהם לא תמיד כדאי לעבוד בשיטת ה rc.local בגלל כמה סיבות. השיטה הזו טובה במידה ואתה רוצה או צריך להפעיל פקודה ספציפית מסויימת אבל אני לא הייתי משתמש בה בהכרח גדי להפעיל שרת. בעבר היה נהוג להשתמש בקובץ כדי להעביר פרמטרים שונים ל kernel ע"י יישום של פקודות כגון echo 1>/proc/sys/net/ipv4/ip_forward אולם כיום ניתן להשתמש בקובץ /etc/sysctl.conf שמבצע את העבודה בצורה יותר נכונה מאשר rc.local (הוא מבצע בסה"כ את אותה עבודה- אבל בתזמון שונה).. כאמור כל פקודה שתרצה אפשר ליישם כאן והיא אכן תיכנס לפעילות בכל הפעלה של המערכת. אולם, כאשר מדובר בשרת שאנו רוצים שיעבוד במקרים רבים חלק מהשרתים עם הפעלתם פותחים תהליכים שונים וקבצים שונים (בדרך כלל במקומות זמניים (/tmp ) או תחת התיקייה /var ). כאר אתה מבצע סגירה של המערכת או reboot שרתים אלו כמו שתמר כבר הסבירה למעשה מסיימים את פעולתם בצורה מסודרת דרך הסקריפטים של system V . שרת שהפעלת אותו דרך rc.local למעשה לא עובר את "חווית הכיבוי המסודר" ופעולתו למעשה נפסקת בצורה "אלימה" יחסית דבר שעשוי לגרור בעיות בהפעלה הבאה שלו. לפיכך תלוי מה אתה כן רוצה להפעיל דרך קובץ זה .. פשוט תבדוק מה קורה עם כיבוי של אותה תוכנית.
יש לי גם שאלה בנושא
לפינ כמה ימים למדתי את הנושא של RC.LOCAL והשתמשתי בו כדי להפעיל את DNS2GO ,אם מישהו מכיר. הבעיה שאחרי הפעלת הקובץ (שבאופן עקרוני שולח פינג לשרת DNS ) המחשב לא המשיך לעלות והמשיך עם הפינג שבעצם אמור לפעול ברקע בלבד. אם יש רעיונות או עצות אני מאוד אשמח. תודה
לפינ כמה ימים למדתי את הנושא של RC.LOCAL והשתמשתי בו כדי להפעיל את DNS2GO ,אם מישהו מכיר. הבעיה שאחרי הפעלת הקובץ (שבאופן עקרוני שולח פינג לשרת DNS ) המחשב לא המשיך לעלות והמשיך עם הפינג שבעצם אמור לפעול ברקע בלבד. אם יש רעיונות או עצות אני מאוד אשמח. תודה
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.