אחסון והרשאות

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

1.  יצירה ושימוש בדלי אחסון – Cloud Storage Bucket.

2.  Versioning & Lifecycle.

3.  IAM – משתמשים והרשאות.

4.  חשבונות שירות.

5.  חיבור דלי אחסון ככונן לשרת Linux.

דלי אחסון – Storage Bucket:

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

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

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

המשתמש האנושי כן יכול לנהל את הקבצים שלו ואת הדלי בתצורת תיקיות, אבל אלה אינן תיקיות כמו במערכת קבצים. מבחינת האחסון, התיקיות זה רק תוספת למחרוזת ב-Metadata של הקובץ. כאשר המשתמש מבקש להציג קבצים בתיקיה מסוימת, האינדקס מוצא את הקבצים שה-Metadata שלהם כולל בתוכו את שם ה"תיקיה" כחלק מהמחרוזת.

יצירת דלי:

בתפריט הניהול של GCP (שלושת הפסים) ללכת ל-Cloud Storage, Buckets. בדף שנפתח ללחוץ למעלה על CREATE.

לתת שם יחודי – נגיד, yos-storage. Continue. שכן אין שני דליים בכל תשתית GCP העולמית, שיש להם אותו השם. כל דלי חייב שם חדש שאף אחד בעולם עוד לא תפס.

לבחור Region – me-west1. CREATE.

תקפוץ חלונית אישור, לאשר בלי לשנות. הדלי נוצר ונפתח הדף שלו.

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

שימוש בדלי:

מתחילים בהעלאת קובץ פשוט.

יוצרים קובץ על שולחן העבודה במחשב, בשם doc.txt. בתוך הקובץ נכתוב את המילה test, נשמור, ואת הקובץ נעלה לדלי.

כעת יש לנו בדלי קובץ אחד.

אם לוחצים על הקובץ כדי לקבל את הפרטים שלו, נראה שיש לקובץ URL שדרכו נוכל לקבל את תוכן הקובץ דרך HTTPS, או נתיב שאפשר להשתמש בו ב-CLI.

לוחצים למעלה על החץ של חזרה אחורה כדי לחזור לדלי, ונעבור ללשונית של PROTECTION.

ניתן לראות ש-OBJECT VERSIONING OFF. לחיצה על השורה הכחולה תקפיץ חלונית לאישור, נלחץ CONFIRM.

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

אם זה לא קופץ ורק מחזיר לדף של PROTECTION, ניתן לראות ש-OBJECT VERSIONING ON, אבל מתחת מופיעה הודעה שאומרת שאין שום חוקים על ה-versioning. מה שאומר שבכל שמעלים או מוחקים קובץ, הקובץ מהגרסה הקודמת ישאר לנצח.

ככה הכל מצטבר ותופס עלויות אחסון.

לכן נגדיר 2 חוקים עבור גרסאות ישנות יותר.

החוק הראשון:

1.     לוחצים MANAGE RULES.

2.     לוחצים ADD A RULE.

3.     נסמן Delete object, ואז CONTINUE.

4.     כעת ב-Set Conditions נסמן את Number of newer versions.

5.     בשדה הטקסט נכתוב 3.

6.     לוחצים למטה CREATE.

החוק השני:

אותו הדבר כמו החוק הראשון, רק שבפעולה מס' 4 התנאי שנבחר יהיה Days since becoming noncurrent, בשדה הטקסט נסמן 7 ימים ואז ליצור את החוק.

תוחלת חיים ודרגות אחסון:

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

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

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

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

חוקי תוחלת חיים (Lifecycle) מאפשרים לנהל רכיבים בתוך דלי אחסון.

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

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

הגדרת חוק תוחלת חיים:

1.     כניסה לדף של הדלי בלוח הניהול – Cloud Storage >> Buckets >> yos-storage

2.     מעבר ללשונית LIFECYCLE

3.     לחיצה על ADD A RULE

4.     בוחרים באפשרות של Set storage class to coldline

5.     לוחצים CONTINUE

6.     נסמן Age ובשדה שיפתח נכתוב את המספר 90

7.     נסמן Storage class matches ובאפשרויות שיפתחו נסמן Standard

8.     לוחצים למטה CRAETE

כעת קבצים שנשארים בדלי לאחר 90 יום, עוברים מאחסון רגיל לאחסון זול יותר.

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

שימוש בגרסאות ו-gsutil:

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

כדי להציג את תוכן הדלי ב-CLI נפתח PowerShell ונזין בפנים את הפקודה:

gsutil ls gs://yos-storage 

או נציג את תוכן הקובץ:

gsutil cat gs://yos-storage/doc.txt 

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

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

gsutil cp $env:userprofile\desktop\doc.txt gs://yos-storage 

כעת נרענן את הדף של הדלי, ונראה שעדיין יש שם קובץ אחד, אבל בעמודה של version history רואים שישנה גרסה אחת ישנה יותר.

לחיצה על הקובץ ומעבר ללשונית VERSION HISTORY, תראה לנו את שתי הגרסאות לקובץ, ואת האפשרות לשחזר את הגרסה הישנה יותר שנדרסה על ידי החדשה.

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

שימוש בדלי מתוך מכונת לינוקס:

מפעילים את instance-1 (כפי שיצרנו במעבדה מס' 1) ומתחברים אליו ב-SSH. אז נזין את הפקודה הבאה:

gsutil ls gs://yos-storage

רואים את הקובץ שעלה קודם.

עכשיו צריך להעלות קובץ חדש. קודם ניצור אותו:

echo "test2" >> doc2.txt

הפקודה הזו מוסיפה את הטקסט "test2" לתוך הקובץ doc2.txt. אם הקובץ אינו קיים, הפקודה יוצרת אותו.

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

הפקודה cat doc2.txt תציג את תוכן הקובץ וכך נוודא שמה שרצינו נמצא בקובץ.

וכעת להעתיק את הקובץ לדלי:

gsutil cp doc2.txt gs://yos-storage

… הפקודה מחזירה קוד http 403 שאומר שאין הרשאות.

הרשאות ותפקידים ב-GCP:

למה קודם מהמחשב בבית מתוך PowerShell זה עבד ועכשיו לא?

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

gcloud auth list

והנה רואים שיש רק חשבון אחד מאומת – חשבון השירות המובנה של הפרוייקט להפעלת מכונות וירטואליות (Compute Engine default service account).

אם נזין את אותה הפקודה ב-PowerShell, נקבל כתוצאה את החשבון שלנו בגוגל, זה שאיתו אנו רשומים ל-GCP.

במעבדה מס' 1 ביצענו הליך אימות מול GCP כדי לאמת את המשתמש עבור PowerShell במחשב בבית. לכן הפקודות מתוך PowerShell מקבלות את ההרשאות שלנו. היות ואנחנו פתחנו את הפרוייקטים, אנחנו בעלי הרשאות Owner – שזו ההרשאה הגבוהה ביותר. תחת ההרשאה שלנו, ניתן לבצע כל פעולה. אבל חשבון השירות שמפעיל את מכונת הלינוקס, לא בא עם הרשאות עבור דליי אחסון. צריך לתת לו אותן, או לעשות משהו אחר.

–         מתן הרשאות עבור Compute Engine default service account, מעניק את אותן ההרשאות לכל מכונה המופעלת באמצעות אותו החשבון. לכן נכון יותר להקים חשבון שירות יעודי עבור מכונות שצריכות את ההרשאה הספציפית, ולהפעיל את המכונה שצריכה את ההרשאה באמצעות החשבון היעודי.

יצירת חשבון שירות:

1.     בתפריט הראשי ללכת אל IAM & Admin >> Service Accounts.

2.     ללחוץ למעלה CREATE SERVICE ACCOUNT.

3.     לתת לו שם – vm-access-bucket, וללחוץ CREATE AND CONTINUE.

4.     עכשיו צריך לתת לחשבון הרשאות. ללחוץ על התפריט איפה שכתוב Select a role.

5.     בשורה למעלה של ה-Filter, לכתוב Compute Viewer ולמצוא מבין התוצאות ולבחור את Compute Viewer. ללחוץ CONTINUE.

6.     עכשיו זה השלב האחרון, והוא פחות רלוונטי עבורנו.

בשלב זה אפשר להוסיף שמות של קבוצות או משתמשים שיש להם הרשאה להריץ פעולות באמצעות החשבון הזה, או לנהל אותו. לנהל אותו, זה אומר להוציא מפתחות אימות שלו וכו'.

אנחנו נדלג על זה ונבצע פעולה דומה בהמשך.

ללחוץ DONE.

חיבור מכונה לחשבון שירות:

1.     כניסה לדף של המכונה ב-Compute Engine >> VM instances.

2.     כיבוי המכונה (אם היא דולקת).

3.     כניסה לעריכת פרטי המכונה בלחיצה על EDIT למעלה.

4.     אחרי ההגדרות של הדיסקים, יש Security and access. שם אחת ההגדרות נקראת Identity and API access. ניתן לראות שמוגדר שם Compute Engine default service account. נלחץ על חץ התפריט מימין, ונבחר את חשבון השירות שיצרנו קודם – vm-access-bucket.

5.     ללחוץ SAVE.

6.     להפעיל את המכונה.

מתן הרשאות על דלי האחסון:

1.     חוזרים לדלי שיצרנו קודם. אם נשתמש בדוגמה שלי, הולכים ל-Cloud Storage >> Buckets >> yos-storage.

2.     עוברים ללשונית PERMISSIONS.

ניתן לראות כאן הגדרות ברירת מחדל, שכולן באות בתורשה מן הפרוייקט – בעלי הרשאות Editor או Owner בפרוייקט, מקבלים הרשאה דומה על הדלי. אנחנו נעשה משהו ממוקד יותר לפי העקרון של Least Priviledge.

3.     ללחוץ על GRANT ACCESS.

4.     בשדה שכתוב New principals לרשום את הכתובת המלאה של חשבון השירות שיצרנו – vm-access-bucket. ניתן למצוא את זה תחת IAM & Admin >> Service Accounts. ריחוף עם העכבר על ה"מייל" של החשבון מציג בצד לחצן העתקה. אותו מדביקים בשדה הנ"ל.

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

5.     ללחוץ עם העכבר על השדה בו כתוב Select a role , ותקפוץ חלונית עם רשימת Roles לבחירה. בשדה של Filter נכתוב Storage Legacy Bucket Writer.

אפשר גם לבחור ב-Storage Object Admin אבל זו הרשאה מעט יותר חזקה, ואנו נבחר במצומצמת יותר.

– ניתן לראות לצד כל Role ברשימה תיאור קצר של ההרשאות שהוא נותן.

6.     ללחוץ SAVE.

בדיקה:

כעת נתחבר שוב ל-Instance-1, נמצא את הקובץ doc2.txt ונתכונן להעלות אותו לדלי.

ראשית, צריך לוודא את ההרשאות שאיתן אנחנו עובדים:

gcloud auth list

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

עכשיו נוכל שוב לתת את הפקודה שמעלה את הקובץ לדלי:

gsutil cp doc2.txt gs://yos-storage

ונראה שהפקודה עברה בהצלחה.

נוכל לוודא ולהציג את הקבצים בדלי באמצעות הפקודה:

gsutil ls gs://yos-storage

וכך זה נראה:

משתמש ו-IAM:

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

עקרונות Least Priviledge בעד העדפה לתת הרשאה ברמת המשאב – אלא אם כן מדובר במשתמש (או קבוצת משתמשים) שתפקידו לגשת לכל המשאבים מסוג זה באותו הפרוייקט.

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

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

1.     נלך לדף הכללי של המשתמשים ב-IAM – IAM & ADMIN >> IAM

2.     נראה ברשימה את החשבון vm-access-bucket, ונראה גם שיש לו את ה-Role שניתן לו בזמן שהחשבון נוצר – Compute Viewer

3.     לוחצים על העפרון בצד ימין של השורה, ויפתח דף לעריכת ההרשאות

4.     לוחצים ADD ANOTHER ROLE

5.     הצבה של העכבר בשדה שנפתח, תקפיץ חלונית חיפוש של Roles

6.     כעת נוכל לתת לחשבון כל הרשאה שהיא ברמת הפרוייקט. היה אפשר לתת לו הרשאת Storage Object Admin (הרשאת ה-Legacy שנתנו לו ברמת הדלי, איננה זמינה ברמת הפרוייקט), או לתת לו הרשאות אחרות על VM, על רשתות וחומת אש ועוד.

7.     ללחוץ CANCEL כדי לסגור את חלון מתן ההרשאות ולחזור לרשימת המשתמשים.

8.     ללחוץ למעלה GRANT ACCESS

9.     בשדה שתחת Add principals  אפשר לשים כל כתובת אימייל שגוגל מכיר. כולל כתובת Gmail אחרת שיש לנו, כתובת של אח או חבר או כל דבר אחר.

10. בשדה Select a role אפשר לבחור ולתת לאותו חשבון שגוגל מכיר את ההרשאה, כפי שראינו קודם.

חיבור דלי למכונה ככונן אחסון:

ניתן לחבר דלי אחסון ישירות למכונת לינוקס, כפי שמחברים דיסק. הפתרון הזה עובד רק בגרסאות היותר חדשות, כמו Ubuntu 18.04 ומעלה, או CentOS 7 ומעלה.

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

מכיוון ש-instance-1 עובד על מערכת הפעלה של Debian, נשתמש בפקודות מתאימות להפצה זו של לינוקס. במקרים אחרים ניתן להסתכל ב-Docs של גוגל או במאמרים אחרים ברשת כדי לקבל הוראות התקנה שונות.

התקנת GCSFuse:

התקנת הרכיב הבסיסי של Fuse:

sudo apt-get install fuse

הוספה של ספריות ההתקנה והעדכון של GCSFues למקורות התוכנה של מערכת ההפעלה:

export GCSFUSE_REPO=gcsfuse-`lsb_release -c -s`
echo "deb https://packages.cloud.google.com/apt $GCSFUSE_REPO main" | sudo tee /etc/apt/sources.list.d/gcsfuse.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

עדכון המערכת בערכים שנוספו, והתקנת הרכיב GCSFuse:

sudo apt-get update
sudo apt-get install gcsfuse

הצבת הדלי ככונן במערכת לינוקס:

קודם צריך ליצור תיקיה שבה נוכל להציב את הדלי:

mkdir bucket

ואז נציב בה את הדלי:

gcsfuse yos-storage bucket

הפקודה בנויה בשלושה/ארבעה חלקים (החלק הרביעי אופציונאלי):

1.     שם הפקודה – gcsfuse.

2.     אופציונאלי – Flags, דגלים/מאפיינים שניתן לקבוע להצבה (נראה את זה בהמשך).

3.     שם הדלי (לא צריך הקדמות כמו gs://).

4.     התיקיה בה מציבים את הדלי.

כעת בתיקיה bucket רואים את תוכן הדלי. ככה זה נראה:

ניתן כעת ליצור תיקיות ובתוכן קבצים:

הצבה קבועה של הדלי ככונן במערכת לינוקס:

פקודת gcsfuse שביצענו כרגע כדי לחבר את הדלי לתיקיית bucket, מקבילה לפקודת mount שבה משתמשים בלינוקס כדי להציב כוננים ומחיצות במיקומים מסוימים במערכת. שתי פקודות אלה תקפות כל עוד הזכרון הנדיף פעיל, וברגע שהוא נמחק, הכל מתאפס.

לכן אם נאתחל את instance-1 נראה שלאחר האיתחול ההצבה נעלמה.

כך ניתן לדאוג להצבה קבועה של הדלי בתיקיה כלשהי, באמצעות הוספת השורה הבאה לקובץ fstab:

yos-storage /home/yosyos/bucket gcsfuse user,rw,allow_other,_netdev,file_mode=777,dir_mode=777,exec

• מידע על fstab, הצבה קבועה של אמצעי אחסון בשרת לינוקס ותחביר ה-Flags המרכיבים את הפקודה, מופיע בנספח.

נספח – הצבה קבועה של דלי ככונן במערכת לינוקס:

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

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

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

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

מי שלא איתחל את instance-1, צריך קודם להסיר את ההצבה הנוכחית כדי לראות שהפעולות הבאות מחילות שינויים:

umount bucket

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

df- h

או בפשטות, לסקור את תוכן התיקיה bucket ולראות שאין שם כלום:

cd ~
ls bucket

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

נפתח לעריכה את קובץ fstab:

sudo nano /etc/fstab

יורדים לשורה פנויה בקובץ ומזינים את הנוסח הבא:

yos-storage /home/yosyos/bucket gcsfuse defaults 0 0

לסגור ולשמור את הקובץ באמצעות ctrl + x, ולאחר מכן y.

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

בפקודה הבאה נריץ את הקובץ fstab באופן יזום, וכך נראה אם ישנן בעיות:

sudo mount -a

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

מה קרה?

נעבור רגע על תצורת הפקודה בקובץ fstab:

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

2.     לאחר מכן שמים את המיקום שבו רוצים להציב את מערכת הקבצים.

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

4.     לאחר מכן יש מקום לתצורת ההצבה. זה המקום של ה-Flags. במקרים רבים אפשר להשאיר ברירת מחדל, וזה מה שעשינו עד עכשיו.

5.     כאן יש ערך מספרי, שבעבר שימש לתצורת גיבוי. כיום לא משתמשים בזה ותמיד שמים 0.

6.     כאן יש עוד ערך מספרי, שמתייחס לסדר הקדימות של הצבת הדיסקים. למשל – מחיצת המערכת של קבצי מערכת ההפעלה, צריכה לקבל את הספרה 1, ודיסקים או מחיצות שבאים לאחר מכן, מקבלים מספרים עוקבים. הספרה 0 מציינת שאין סדר מיוחד, וכך נוהגים ברוב המקרים.

הערות:

• טעות במספור של סעיף 6 תגרום לשגיאה בהעלאת מערכת ההפעלה. ניתן לשים לב בקובץ שרק מחיצת המערכת ממוספרת בספרה 1.

• טעויות אחרות גם הן יכולות לגרום לשגיאה במערכת ההפעלה.

ערכים – Flags:

כרגע נתייחס לסעיף 4, שבפקודה שהכנסנו קיבל ערכי ברירת מחדל. אחד מהם אומר שרק מי שהעלה את מערכת הקבצים, מקבל גישה אליה. היות ומערכת הקבצים עלתה באמצעות fstab, מי שהעלה אותה היה בעצם המשתמש root. כך שלמשתמש שלי אין גישה אליה.

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

yos-storage /home/yosyos/bucket gcsfuse user,rw,allow_other,_netdev

את ערכי הספרות בסוף השמטנו.

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

yos-storage /home/yosyos/bucket gcsfuse user,rw,allow_other,_netdev,file_mode=777,dir_mode=777,exec

הערכים שהוזנו:

user – מאפשר גם למשתמש רגיל להציב את מערכת הקבצים.

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

allow_other – מאפשר למשתמש רגיל לגשת למערכת קבצים שמישהו אחר העלה.

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

file_mode – קובע הרשאה על קבצים מתוך מערכת הקבצים. במקרה שלנו קבענו 777, מה שנתן גישה אל הקבצים לכל משתמש שמחובר למכונה.

dir_mode – קובע הרשאה על תיקיות מתוך מערכת הקבצים. במקרה שלנו קבענו 777, כך שניתן ליצור קבצים חדשים בתיקיות על ידי כל משתמש המחובר למכונה.

Exec – קובע שניתן להפעיל קבצים מתוך מערכת הקבצים שעלתה.

הערות:

–         סדר ה-Flags חשוב, היות וישנם Flags שברגע שמציבים אותם, ברירת המחדל היא Flags נוספים. ולכן אם רוצים לבחור אפשרות אחרת, צריך שה-Flags שמשנים את ערכי ברירת המחדל, יבואו אחר כך.

–         למשל – user קובע כברירת מחדל את הערך noexec, לכן בפקודה ששמנו, שמנו קודם את ה-Flag user ולאחריו את ה-Flag שאומר exec, כדי לוודא שישנן הרשאות להפעלת קבצים מתוך הדלי.

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