הנחה את דרכך ללינוקס: סדרה בת 4 חלקים
חלק 1: בחירת ההפצה שלך → חלק 2: אחסון והצפנה → חלק 3: התקנה ידנית → חלק 4: שירותים ו-GPU
אם אי פעם חוויתם מצב שבו מחיצת הבסיס התמלאה בשלוש לפנות בוקר וראיתם את המערכת קורסת לאט, אתם כבר יודעים: חלוקת מחיצות ברירת מחדל היא מלכודת. אבל לתכנן פריסת LVM מוצפנת מסודרת לשישה עומסי עבודה שונים על פני שלושה דיסקים פיזיים? זה יום עבודה שלם של תכנון עצמאי, הצלבת תיעוד, חישוב גדלים, וספקות שמלווים אתכם כל הדרך.
הנה איך לתת ל-AI לשאת בעול הכבד של תכנון האחסון, כדי שלא תהיו קבורים בדפי מדריך יום שלם. תזינו את דרישות עומס העבודה שלכם, תקבלו בחזרה ארכיטקטורה מלאה עם הנמקה שאפשר באמת לעקוב אחריה, ותצאו עם הבנה של כל שכבה במה שאתם בונים.
בחלק 1, בחרתם את ההפצה שלכם ומיפיתם את החומרה. עכשיו מגיע החלק שבו רוב האנשים או מקבלים ברירות מחדל גרועות או מוותרים לגמרי: תכנון אחסון.
התחילו מעומסי עבודה, לא מגדלי מחיצות
יש לכם את החומרה ממופה מחלק 1: נניח ThinkPad ישן עם כונן NVMe, SSD ו-HDD. המפרטים אומרים לכם מה אפשרי. אבל עומסי העבודה אומרים לכם מה הכרחי.
הנה הצעד. אל תבקשו מה-AI טבלת מחיצות. אל תציינו גדלים. אל תגידו "שים את /home במחיצה נפרדת." במקום זאת, תארו התנהגויות ודרישות ותנו לו להסיק את הארכיטקטורה. משהו כזה:
"המכונה הזו תריץ קונטיינרים של Docker, PostgreSQL עם TimescaleDB, Redis, Ollama למודלי AI מקומיים, ותאחסן ממצאי תקיפה מרשת honeypot. היא גם צריכה סביבת עבודה מוצפנת לניתוח נפרדת ממערכת ההפעלה, ואחסון ארכיב מוצפן לראיות לטווח ארוך. תכנן את אסטרטגיית המחיצות וההצפנה הטובה ביותר לשלושת הדיסקים שמצאנו."
רואים את ההבדל? אתם מוסרים אילוצים ויעדים, לא מנהלים את הפתרון בפרטי פרטים. אם ההנמקה חוזרת הגיונית, גם העיצוב יהיה כזה. ואם בחירה מסוימת לא הגיונית, תזהו אותה כי אתם מבינים מה המכונה שלכם צריכה לעשות.
מיון עומסי עבודה לפי התנהגות דיסק
הדבר הראשון שצריך לסדר הוא הפרדת עומסי עבודה לפי דפוס IO. לא לפי גודל, לא לפי חשיבות, אלא לפי האופן שבו כל עומס עבודה נוגע בדיסק בפועל.
שלושת הנתיבים
- IOPS גבוה, זמן תגובה נמוך = NVMe. כאן גרים מערכת ההפעלה, Docker, מסדי נתונים ומודלי AI. עומסי עבודה אלה מבצעים הרבה קריאות וכתיבות אקראיות קטנות. הם זקוקים לאחסון המהיר ביותר הזמין.
- שטח עבודה זמני מהיר, מבודד = SSD. סביבת העבודה לניתוח נמצאת כאן. היא צריכה מהירות סבירה לעיבוד לכידות והרצת כלים, אבל חשוב מכך, היא צריכה להיות נפרדת מדיסק מערכת ההפעלה. אם עבודת הניתוח משחיתה מערכת קבצים או ממלאת דיסק, מערכת ההפעלה ממשיכה לפעול.
- קיבולת גדולה, כתיבות רצופות = HDD. אחסון ארכיב לטווח ארוך לקבצי pcap, ייצוא ראיות וגיבויים. ביצועי כתיבה רצופה מספיקים. קיבולת חשובה יותר ממהירות.
הפרדה זו לבדה מונעת את מצב הכשל הנפוץ ביותר: עומס עבודה אחד שמרעיב אחר ב-IO של דיסק או שטח.
מדוע כל שירות מקבל נפח לוגי משלו
אל תעצרו בשלושה דיסקים. ב-NVMe, חלקו את השטח לשישה נפחים לוגיים נפרדים, כל אחד למטרה ספציפית:
- /var/lib/docker מקבל בידוד כי Docker אוכל דיסק בצורה בלתי צפויה. בנייה של קונטיינר שיצאה מכלל שליטה או מטמון תמונות שנשכח לא אמורים להיות מסוגלים למלא את root.
- /var/lib/postgresql מקבל בידוד לצורך גדילה עצמאית, תמונות גיבוי וכוונון ביצועים עתידי. למסדי נתונים יש דפוסי IO ייחודיים שנהנים משטח ייעודי.
- /var/lib/ollama מקבל בידוד כי מודלי AI הם ענקיים וגדלים באופן עצמאי. מודל שפה בודד יכול להיות 8GB ויותר. אתם לא רוצים שהורדות מודלים יתחרו עם מערכת ההפעלה שלכם על שטח.
- /home מקבל בידוד כדי שנתוני משתמש, קבצי הגדרות ותצורות אישיות ישרדו התקנות מחדש של מערכת ההפעלה.
- swap כנפח לוגי משלו, בגודל שתומך בהתמסכות אם צריך.
- root (/) מוגבל לגודל קבוע כדי שכלום מחוץ לנתיבים המיועדים לא יוכל למלא אותו. אם root מתמלא, המערכת מפסיקה לתפקד. הגבלתו היא עיצוב הגנתי.
הצפנה אינה אופציונלית
הצפנה אינה אופציונלית כאן, וההנמקה פשוטה. זהו מחשב נייד שפועל כתחנת עבודה לאבטחה ומאחסן נתונים רגישים במנוחה: לכידות honeypot, ממצאי תקיפה, תוצאות ניתוח רשת. אם המכונה נגנבת, אובדת או יוצאת משימוש, כל דיסק צריך להיות בלתי קריא ללא ביטוי הסיסמה.
הצפנת דיסק מלאה עם LUKS היא קו הבסיס לתרחיש שימוש זה. נקודה.
השאירו מרחב פנוי בקבוצת הנפחים שלכם
פרט זה מפריד בין עיצוב LVM טוב לעיצוב חובבני. השאירו כ5-10% מקבוצת הנפחים שלכם לא מוקצה. לא מבוזבז. שמור. הנה למה:
עם LVM, אתם יכולים להגדיל נפחים לוגיים תוך כדי פעולה ללא הפעלה מחדש. אם Docker צריך יותר שטח בעוד שישה חודשים, אתם מרחיבים את ה-LV ומשנים גודל מערכת הקבצים תוך שניות. אם הקצאתם הכל מראש, תצטרכו לכווץ נפח אחד כדי להגדיל אחר, וכיווץ הוא איטי, מסוכן, ולעיתים בלתי אפשרי עם מערכות קבצים מסוימות.
מרחב פנוי מכוון הוא תכונה, לא בזבוז.
המודל המנטלי של שכבת האחסון
המודל המנטלי הזה הוא הדבר היחיד הכי בעל ערך לקחת מהפרק הזה כולו. לא גדלי המחיצות. לא נקודות ההרכבה. המחסנית בת 8 שכבות הזו שמסבירה כיצד אחסון לינוקס עובד בפועל, מלמעלה למטה.
מחסנית האחסון בת 8 השכבות
כל חלק מהאחסון שלכם עובר דרך השכבות האלה, מלמעלה למטה:
- מחיצה גולמית: מה ש-
fdiskאוgdiskיוצרים על הדיסק הפיזי - הצפנה (LUKS): עוטפת את המחיצה הגולמית במיכל מוצפן
- התקן ממפה: מה שמופיע לאחר פתיחת הנעילה:
/dev/mapper/cryptnvme - נפח פיזי של LVM (PV): התקן הממפה הרשום כאחסון עבור LVM
- קבוצת נפחים (VG): PV אחד או יותר מקובצים יחד לבריכה
- נפח לוגי (LV): פרוסה מה-VG, בגודל למטרה ספציפית
- מערכת קבצים: ext4 או swap, מעוצבת על ה-LV
- נקודת הרכבה: המקום שבו מערכ�� הקבצים מופיעה בעץ הספריות
כשמשהו נשבר, התיקון הוא כמעט תמיד בשכבה ספציפית אחת. אם אינכם יכולים לזהות איזו שכבה, תבזבזו שעות בפתרון בעיות במקום הלא נכון.
רוב הכשלים שתיתקלו בהם במהלך ההתקנה בפועל, במיוחד עם fstab ו-crypttab בחלק 3, נובעים מבלבול בין השכבות האלה. כתיבת UUID משכבה 2 כשנדרשה שכבה 6. הפניה לנתיב התקן משכבה 3 בתצורה שצריכה שכבה 1. כל שגיאת אחסון חוזרת לאי-התאמת שכבות.
שמרו את המחסנית הזו. קעקעו אותה על האמה שלכם. ברגע שתפנימו את שמונת השכבות האלה, אחסון לינוקס יפסיק להיות מסתורי. זה פשוט שמונה דברים, כל אחד עושה עבודה אחת, מחוברים בסדר.
פריסת ה-NVMe הסופית
הנה העיצוב המלא לכונן ה-NVMe הראשי:
NVMe ראשי (nvme0n1)
| מחיצה | גודל | סוג | מטרה |
|---|---|---|---|
| nvme0n1p1 | 1 GB | מערכת EFI (FAT32) | קושחת אתחול |
| nvme0n1p2 | 2 GB | /boot (ext4) | ליבה ו-initramfs |
| nvme0n1p3 | שאר | מוצפן LUKS2 | כל השאר |
בתוך מיכל ה-LUKS על nvme0n1p3:
nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (קבוצת נפחים)
| נפח לוגי | גודל | מערכת קבצים | נקודת הרכבה |
|---|---|---|---|
| root | 120 GB | ext4 | / |
| swap | 24 GB | swap | [swap] |
| docker | 220 GB | ext4 | /var/lib/docker |
| ollama | 180 GB | ext4 | /var/lib/ollama |
| postgres | 120 GB | ext4 | /var/lib/postgresql |
| home | 200 GB | ext4 | /home |
| (פנוי) | ~65 GB | n/a | n/a |
דיסקים משניים
SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis
HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive
שלושה דיסקים מוצפנים. שישה נפחים לוגיים על הראשי. כל עומס עבודה בנתיב שלו. שום דבר לא חולק שטח עם מה שלא צריך.
הפיכת העיצוב לסקריפט בנייה
לאחר שהעיצוב נעול, הפרומפט הבא פשוט:
"תן לי את הפקודות המדויקות לבניית פריסת האחסון הזו כולה מסביבת Kali החיה. הנח שניתן למחוק את כל שלושת הדיסקים."
בקש סקריפט shell מלא: מחיקת חתימות קיימות, יצירת טבלאות מחיצות GPT, חיתוך מחיצות עם sgdisk, יצירת מכולות LUKS2 עם ברירות מחדל חזקות, פתיחתן, אתחול אמצעי אחסון פיזיים של LVM, יצירת קבוצת האמצעים, הקצאת כל שישה הכרכים הלוגיים, פורמט של הכל, ולאחר מכן חזרה על הגדרת LUKS עבור ה-SSD וה-HDD.
צפה לכ-80 שורות. כל פקודה צריכה להיות ניתנת לביקורת. אם משהו בסקריפט אינו מובן לך, בקש מה-AI להסביר את אותה שורה ספציפית לפני שתריץ אותה.
מה ישתבש (וזה לא יהיה העיצוב)
אזהרה הוגנת: העיצוב יהיה מוצק. הביצוע יילחם בך. הנה המלכודות שכדאי לשים לב אליהן:
סיומות שורה של Windows. אם תכתוב את הסקריפט במחשב Windows ותעביר אותו לסביבה החיה דרך USB, כל שורה מסתיימת ב-\r\n במקום ב-\n. Bash נחנק על כל פקודה בודדת, והודעות השגיאה מסתוריות. תקן זאת עם sed -i 's/\r$//' script.sh לפני שתריץ כל דבר.
שחיתות Shebang. קשורה לבעיית סיומות השורה. השורה #!/bin/bash מקבלת החזרת כרכרה בלתי נראית, כך שהגרעין אינו מוצא את המפרש. השגיאה נראית כאילו הסקריפט אינו קיים למרות שהוא ברור ונראה לעין.
בלבול נתיבים. ה-USB מותקן בנתיב אחד, אך אתה מפנה לסקריפט מספריית עבודה שונה. השלמת Tab ונתיבים יחסיים בסביבה חיה אינם אמינים כאשר אתה מתמודד עם מספר נקודות עגינה. השתמש בנתיבים מוחלטים.
תחביר הרצה שגוי. שכחת ./ לפני שם הסקריפט, או שלא הגדרת הרשאות הרצה תחילה. טעויות קלאסיות שאין להן שום קשר לעיצוב האחסון ויש להן הכל לעשות עם זיכרון שרירים.
"AI יכול לכתוב את הסקריפט, אך אתה עדיין צריך להבין מה אתה מדביק. אם פקודה אינה מובנת לך, עצור ושאל."
לאחר שבעיות סיומות השורה וההרצה מסודרות, בניית האחסון מסתיימת תוך פחות משתי דקות. כל מכולת LUKS נפתחת. כל מבנה LVM נוצר בצורה נקייה. כל מ��רכת קבצים מקבלת פורמט. העיצוב עומד בתנאים.
אמת הכל עם תבנית ההדבקה-ובדיקה
אל תניח הצלחה. לאחר שהסקריפט מסיים, הדבק את פלט הטרמינל שלך חזרה ל-AI ובקש ממנו לבדוק את התוצאה:
"הנה הפלט של
lsblkו-lvsשלי. האם הכל נבנה כראוי?"
הדבק את פלט הטרמינל הגולמי ובקש מה-AI לעבור עליו שורה אחר שורה. הוא צריך לאשר: cryptnvme פעיל, vgkali קיים עם שישה כרכים לוגיים בגדלים הנכונים, מערכות קבצים נכונות על כל אחד, דיסקים משניים מוצפנים ומפורמטים.
תבנית ההדבקה-ואימות הזו היא אחת הטכניקות השימושיות ביותר לניהול מערכות עם AI. אתה מריץ פקודה, מדביק את הפלט, ושואל האם המציאות תואמת את התוכנית. זה תופס בעיות שהיית מפספס כי אתה קרוב מדי לעבודה:
- כרך לוגי שפורמט בטעות כסוג מערכת קבצים שגוי
- כרך שנמדד במגה-בייט כאשר התכוונת לגיגה-בייט
- מחיצה חסרה שהסקריפט דילג עליה בשקט
- מכולת LUKS שלא נפתחה בפועל
אתה יכול לעשות זאת עם כמעט כל מצב מערכת: lsblk, lvs, pvs, vgs, blkid, fdisk -l, cryptsetup status. הדבק. בקש מה-AI לבדוק. זה מהיר ויסודי יותר מלבדוק הכל בעצמך.
המסקנה: עצב לפי עומסי עבודה, לא לפי ברירות מחדל
פריסת האחסון כאן לא נבחרה מתבנית או הועתקה מפוסט בפורום. היא נגזרה מדרישות עומס עבודה אמיתיות. Docker זקוק לבידוד מרחב. מסדי נתונים זקוקים ל-IO ייעודי. מודלי AI זקוקים למקום לצמוח. ממצאי אבטחה זקוקים להצפנה במנוחה. ארכיונים זקוקים לקיבולת על פני מהירות.
כל החלטה מתחקה חזרה לדרישה אמיתית. זה ההבדל בין פריסת אחסון שמחזיקה מעמד שישה חודשים לבין כזו שמתפרקת בפעם הראשונה שמשהו בלתי צפוי קורה.
גישה זו עובדת לכל בנייה, לא רק לתחנות עבודה לאבטחה. ספר ל-AI מה המחשב יעשה. תאר את השירותים, דפוסי הנתונים, ציפיות הצמיחה, תרחישי ה��של שאתה רוצה לשרוד. ואז תן לו להבין כיצד לארגן את הדיסקים. ההיגיון שהוא מראה לך בעל ערך רב יותר מטבלת המחיצות הסופית, כי תבין מדוע כל בחירה נעשתה ומתי היא עשויה להצטרך להשתנות.
הדיסקים שלך מחולקים למחיצות, מוצפנים וחרוטים לכרכים לוגיים. הארכיטקטורה מוכנה. עכשיו מגיע החלק שבאמת שובר אנשים: התקנת מערכת הפעלה על גבי כל זה ללא מתקין גרפי שמחזיק לך את היד.
ב**חלק 3: התקנה ידנית**, תעגן את הכרכים המוצפנים, תאתחל את Kali מאפס, תחבר את fstab ו-crypttab כך שהכל יפתח בעת האתחול, ותבנה תצורת bootloader עובדת. כאן המודל בן 8 השכבות עובר מבחן לחץ אמיתי, ושם UUID שגוי אחד יכול להשאיר אותך מביט בפרומפט הצלה של GRUB. הכן קפה.
