מצטער על השאלות החובבניות..
הספרית עבודה שלי עם eclipse נמצאת תחת ספרית /home.
יצרתי symlink לתיקית הDocument Root של הapache.
ע"י הפקודה הבאה:

קוד:

ln -s /home/username/workspace /var/www/html

עכשיו כשאני נכנס ל /var/www/html אני רואה את הספריה /workspace.
כשאני נכנס ל

קוד:

http://localhost/workspace/

אני מקבל את השגיאה

קוד:

Forbidden

 You don't have permission to access /oolamit on this server.

  Apache/2.2.22 (Fedora) Server at localhost Port 80

אז עשיתי:

קוד:

chmod 755 /var/www/html/workspace/

ניסיתי גם להתייחס אליו כקובץ:

קוד:

chmod 644 /var/www/html/workspace

זה לא עובד לי. למה?


**עדכון:

ניסיתי גם

קוד:

chown apache /home/username/workspace/

עדיין לא עובד... =\

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

או שתסדר את ההגדרות כך שגם הספריה הרצוייה תהיה מאושרת (ולא רק var/www/ ...)

או שתעשה טריק:

קוד:

mkdir -p /var/www/html/workspace
mount -o bind /home/username/workspace /var/www/html/workspace

(אבל לא לשכוח למחוק את ה symlink העונה לשם workspace קודם לכן)

נ.ב. הרשאות על symbolic link הן לא הגיוניות. זה רק מצביע, לא באמת קובץ. ההרשאות שקובעות הן של הקובץ האמיתי.

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

מה המשמעות של
mount -o bind /home/username/workspace /var/www/html/workspace?
איך אני מחזיר אחורה את הפעולה הזו? (אני מפחד למחוק אותה - שלא תמחק לי גם התיקיה המקורית שיושבת ב/home ..

המשמעות היא שהמערכת ממקמת מבחינה לוגית את המיקום הראשון, במיקום השני, ולתוכנות זה נראה כאילו מה שיש במיקום הראשון נמצא לכל דבר ועניין במיקום השני (בשונה מלינק שהוא רק מצביע)

כדי לבטל - umount /var/www/html/workspace (גם אתחול היה מבטל; עשינו את זה כפעולה חד"פ, לא שמרנו את זה ב etc/fstab/)

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

בכ"א, הפתרון היה אמור לעבוד (בהנחה ש home/username/workspace/ והקבצים שבתוכו הם בעלי הרשאות קריאה לכולם כמובן). תסתכל בקובץ הלוג ותראה מה קורה, חבל שנעסוק בניחושים.

נמאס לכם לזכור סיסמאות? לחצו כאן!

oolamit מופיע כALIAS בקובץ conf של אפצ'י.
בכל מקרה, גם http://localhost/workspace/index.php לא עובד עם אותה השגיאה.
שיניתי את כל הרשאות התיקיות ותתי התיקיות ל 755, את כל הרשאות הקבצים ל644.


עכשיו ניסיתי שוב עם קישור סימבולי וזה מה שכתוב בקובץ הלוג

קוד:

[Mon Jul 16 12:18:12 2012] [error] [client 127.0.0.1] Symbolic link not allowed or link target not accessible: /var/www/html/workspace
[Mon Jul 16 12:18:26 2012] [error] [client 127.0.0.1] Symbolic link not allowed or link target not accessible: /var/www/html/workspace

מחקתי שוב את הקישור הסימבולי ועשיתי את פקודת הmount שנתת לי (ושמתי לב שבפעם הקודמת רשמתי mkdir בלי הערך -p )

עכשיו יש לי דף שגיאה אחר- 404 Not found.

וקובץ הלוג כותב

קוד:

[Mon Jul 16 12:40:00 2012] [error] [client 127.0.0.1] script '/var/www/html/workspace/index.php' not found or unable to stat

כאשר הקובץ קיים במקום בוודאות... =\

אם אתה רוצה לאפשר מעקב אחרי Symlink-ים (לא רצוי מבחינת אבטחה וביצועים באופן כללי...), תאפשר את האפשרות FollowSymLinks.. ראה: http://httpd.apache.org/docs/2.0/mo....html#directory (לא לשכוח להפעיל את אפאצ'י מחדש אחרי שינויים בקובץ הקונפיגורציה...)

ה p- שנתתי קודם משנה רק אם הספריות שמעל לא היו קיימות, אם הן היו קיימות, הוא לא עושה כלום...

אני רואה שאפאצ'י מזהה שהקובץ המדובר הוא סקריפט. בסקריפט יש עניינים אחרים. צריך לראות איך נראית ההגדרה שמאפשרת להריץ קבצי PHP. מה קורה שאתה מנסה לטעון קובץ שאיננו סקריפט?

לגבי ה 755 שנתת לכל הספריות - גם ל workspace עצמה?

נמאס לכם לזכור סיסמאות? לחצו כאן!

קודם כל, ההרשאות של כל התיקיות כולל workspace עצמה - 755.

אני יכול לראות קבצי PHP/HTML שנמצאים ב /var/www/html/ כמו שצריך...

מחר אכנס לקובץ ההגדרות של apache ואבדוק אם יש שם משהו שאני מפספס וגם אנסה לאפשר קישורים סימבולים.

תודה רבה עד כה, אעדכן כשיהיה מה.. =)

לא ב html, ב workspace המדובר, רק שלא php. אני רוצה לראות אם השרת מצליח לפתוח סתם קבצים... סקריפטים רצים קצת אחרת (תלוי איך התקנת את שפת צד השרת המטפלת בהם, בתוך הקונפיגורציה של אפאצ'י)

נמאס לכם לזכור סיסמאות? לחצו כאן!

לשאלותיך (מצטער שלקח זמן)
קבצי סקריפט \ HTML רצים היטב כשהם בתיקית ה Document Root (/var/www/html/)
ולא רצים (גם לא קבצי HTML) כשהם בתוך workspace. (עם אותה השגיאה)

בנוסף, בבדיקת קובץ ה conf של אפצ'י- קישור סימבולי מאופשר.

אין לי מושג מה הבעיה ואני ממש נואש.
אני מוכן לאפשר לך גישה בSSH אם בא לך להעיף מבט...

הללויה! הבעיה נפתרה!
מישהו אמר לי לבטל את SElinux.
מהרגע שהוא בוטל, הכל עובד חלק. תודה רבה על התמיכה והעזרה שימי! =)

אני לא מבין למה מלכתחילה מופעל SELinux מבלי להבין את המשמעויות

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

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

once upon a time תוכנת ההתקנה שאלה אותך אם אתה מעוניין, ונדמה לי שגם היה שם הסבר מה זה. אולי היום כבר לא שואלים :| בגירסאות שרת אני אולי יכול להבין, אבל אם אתה מריץ הפצה "שולחנית", תמיכה בזה - זה סבבה - אבל לדעתי צריך לשאול במהלך ההתקנה אם אתה מעוניין.

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

אולי באמת כדאי שאני אשים על זה עוגן או משהו

נמאס לכם לזכור סיסמאות? לחצו כאן!

דווקא בלקרוא ולנסות ולהבין אני די טוב, ואני לא תופס מעצמי דביל.
אני בטוח ב99.9% שלא נשאלתי האם אני מעוניין להתקין את SELinux ושלא נדבר על הסבר מהי SELinux.
יש מישהו שבאמת צריך להשתמש בפונקציה הזאת??

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

בהפצות שולחן עבודה, היכן שנוהגים לאפשר דברים מגוחכים כגון 'sudo su' פתוח ללא סיסמא, זה לדעתי קצת מיותר, ובעיקר - מפריע, מבלי שמבינים למה, במקרים כמו שלך. (אם כי יש פלט ב dmesg שזה קורה...). קצת כמו UAC במיקרוסופט :|

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

Joshua Brindle (an SELinux developer) has comments on disabling SELinux here, which states clearly that applications should be fixed to work with SELinux, rather than disabling the OS security mechanism.

מקור- http://www.crypt.gen.nz/selinux/disable_selinux.html

אחרי ההסבר שלך נראה לי שאבטל אותו בכל זאת, תודה רבה.

אני מסכים איתו שעדיף לכוון את המערכת ל SELinux מאשר לבטל אותו (מבחינת אבטחה, בכל אופן. מה ה overhead בביצועים, אף פעם לא בדקתי...), אבל הבעייה היא ש: א. זה לא טריוויאלי, בטח לא למשתמש הביתי (לך תסביר למשתמש מה זה security context...), וב. אתה לא יודע מתי זה ינגוס בך בעתיד. אם איכשהו הודעות השגיאה היו חכמות יותר, להגיד לך שבעיית ההרשאה נובעת מחסימה של SELinux, מילא. אבל אתה בהחלט עלול למצוא את עצמך במערכת שעובדת סבבה (כי זה סידרת את זה כמו שהוא רוצה), ואז, בעוד שנה, אחרי ששכחת בכלל ש SELinux קיים, להתקל בבעייה בדיוק כמו זו שבגינה פתחת את האשכול הזה, ולתלוש שיערות מרוב שאתה לא מבין מה לכל הרוחות קורה.

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

נמאס לכם לזכור סיסמאות? לחצו כאן!