How AI Designed a Storage Layout I'd Have Spent Days Planning Myself

Προτρέψτε τον Δρόμο σας προς το Linux: Μια Σειρά 4 Μερών

Μέρος 1: Επιλογή Διανομής → Μέρος 2: Αποθήκευση και Κρυπτογράφηση → Μέρος 3: Χειροκίνητη Εγκατάσταση → Μέρος 4: Υπηρεσίες και GPU

Αν έχετε ποτέ δει το root partition να γεμίζει στις 3 τα ξημερώματα και το σύστημά σας να παγώνει, ήδη γνωρίζετε: η προεπιλεγμένη κατάτμηση είναι παγίδα. Όμως ο σχεδιασμός ενός σωστού κρυπτογραφημένου LVM layout για έξι διαφορετικά φορτία εργασίας σε τρεις φυσικούς δίσκους; Αυτό είναι μια ολόκληρη μέρα μοναχικού σχεδιασμού, διασταύρωσης τεκμηρίωσης, υπολογισμού μεγεθών και αμφιταλάντευσης συνεχώς.

Ορίστε πώς να αφήσετε την τεχνητή νοημοσύνη να αναλάβει το βαρύ φορτίο του σχεδιασμού αποθήκευσης, ώστε να μην χαθείτε σε σελίδες man για μια ολόκληρη μέρα. Θα της δώσετε τις απαιτήσεις του φορτίου εργασίας σας, θα λάβετε πίσω μια πλήρη αρχιτεκτονική με αιτιολόγηση που μπορείτε πραγματικά να ακολουθήσετε, και θα φύγετε κατανοώντας κάθε επίπεδο αυτού που χτίζετε.

Στο Μέρος 1, επιλέξατε τη διανομή σας και χαρτογραφήσατε το υλικό. Τώρα έρχεται το μέρος όπου οι περισσότεροι άνθρωποι είτε αποδέχονται κακές προεπιλογές είτε τα παρατούν εντελώς: σχεδιασμός αποθήκευσης.

Ξεκινήστε με Φορτία Εργασίας, Όχι Μεγέθη Κατατμήσεων

Έχετε χαρτογραφήσει το υλικό σας από το Μέρος 1: ας πούμε ένα παλαιότερο ThinkPad με έναν δίσκο NVMe, έναν SSD και έναν HDD. Οι προδιαγραφές σας λένε τι είναι δυνατό. Αλλά τα φορτία εργασίας σας λένε τι είναι απαραίτητο.

Ορίστε η κίνηση. Μην ζητάτε από την τεχνητή νοημοσύνη έναν πίνακα κατατμήσεων. Μην καθορίζετε μεγέθη. Μην λέτε "βάλε το /home στη δική του κατάτμηση." Αντ' αυτού, περιγράψτε συμπεριφορές και απαιτήσεις και αφήστε την να εξάγει την αρχιτεκτονική. Κάτι σαν αυτό:

"Αυτό το μηχάνημα θα εκτελεί containers Docker, PostgreSQL με TimescaleDB, Redis, Ollama για τοπικά μοντέλα τεχνητής νοημοσύνης, και θα αποθηκεύει αντικείμενα επίθεσης από ένα δίκτυο honeypot. Χρειάζεται επίσης έναν κρυπτογραφημένο χώρο εργασίας ανάλυσης ξεχωριστό από το λειτουργικό σύστημα, και κρυπτογραφημένη αρχειακή αποθήκευση για μακροπρόθεσμα αποδεικτικά στοιχεία. Σχεδιάστε την καλύτερη στρατηγική κατάτμησης και κρυπτογράφησης για τους τρεις δίσκους που βρήκαμε."

Βλέπετε τη διαφορά; Παραδίδετε περιορισμούς και στόχους, χωρίς να διαχειρίζεστε λεπτομερώς τη λύση. Αν η αιτιολόγηση επιστρέψει σωστή, ο σχεδιασμός θα είναι επίσης. Και αν μια επιλογή δεν έχει νόημα, θα το εντοπίσετε γιατί καταλαβαίνετε τι χρειάζεται πραγματικά να κάνει το μηχάνημά σας.

Ταξινόμηση Φορτίων Εργασίας κατά Συμπεριφορά Δίσκου

Το πρώτο πράγμα που πρέπει να ξεκαθαρίσετε είναι ο διαχωρισμός φορτίων εργασίας κατά μοτίβο IO. Όχι κατά μέγεθος, όχι κατά σπουδαιότητα, αλλά κατά τον τρόπο που κάθε φορτίο εργασίας αγγίζει πραγματικά τον δίσκο.

Οι Τρεις Λωρίδες

• Υψηλό IOPS, χαμηλή καθυστέρηση = NVMe. Εδώ ζουν το λειτουργικό σύστημα, το Docker, οι βάσεις δεδομένων και τα μοντέλα τεχνητής νοημοσύνης. Αυτά τα φορτία εργασίας κάνουν πολλές μικρές τυχαίες αναγνώσεις και εγγραφές. Χρειάζονται την ταχύτερη διαθέσιμη αποθήκευση.
• Γρήγορος χώρος εργασίας, απομονωμένος = SSD. Ο χώρος εργασίας ανάλυσης πηγαίνει εδώ. Χρειάζεται αξιοπρεπή ταχύτητα για την επεξεργασία καταγραφών και την εκτέλεση εργαλείων, αλλά πιο σημαντικό, χρειάζεται να είναι ξεχωριστός από τον δίσκο του λειτουργικού συστήματος. Αν η εργασία ανάλυσης καταστρέψει ένα σύστημα αρχείων ή γεμίσει έναν δίσκο, το λειτουργικό σύστημα συνεχίζει να λειτουργεί.
• Μεγάλη χωρητικότητα, διαδοχικές εγγραφές = HDD. Μακροπρόθεσμη αρχειακή αποθήκευση για pcaps, εξαγωγές αποδεικτικών στοιχείων και αντίγραφα ασφαλείας. Η απόδοση διαδοχικής εγγραφής είναι αρκετή. Η χωρητικότητα έχει μεγαλύτερη σημασία από την ταχύτητα.

Αυτός ο διαχωρισμός από μόνος του αποτρέπει την πιο συνηθισμένη αποτυχία: ένα φορτίο εργασίας να στερεί από ένα άλλο IO δίσκου ή χώρο.

Γιατί Κάθε Υπηρεσία Παίρνει τον Δικό της Λογικό Τόμο

Μην σταματάτε στους τρεις δίσκους. Στον NVMe, χωρίστε τον χώρο σε έξι ξεχωριστούς λογικούς τόμους, καθένας για συγκεκριμένο λόγο:

• Το /var/lib/docker παίρνει απομόνωση γιατί το Docker καταναλώνει δίσκο απρόβλεπτα. Ένα ξέφρενο build container ή μια ξεχασμένη cache εικόνων δεν πρέπει να μπορεί να γεμίσει το root.
• Το /var/lib/postgresql παίρνει απομόνωση για ανεξάρτητη αλλαγή μεγέθους, στιγμιότυπα αντιγράφων ασφαλείας και μελλοντική βελτιστοποίηση απόδοσης. Οι βάσεις δεδομένων έχουν μοναδικά μοτίβα IO που ωφελούνται από αποκλειστικό χώρο.
• Το /var/lib/ollama παίρνει απομόνωση γιατί τα μοντέλα τεχνητής νοημοσύνης είναι τεράστια και μεγαλώνουν ανεξάρτητα. Ένα μόνο LLM μπορεί να είναι 8GB ή περισσότερο. Δεν θέλετε οι λήψεις μοντέλων να ανταγωνίζονται με το λειτουργικό σύστημα για χώρο.
• Το /home παίρνει απομόνωση ώστε τα δεδομένα χρήστη, τα dotfiles και οι προσωπικές ρυθμίσεις να επιβιώνουν από επανεγκαταστάσεις λειτουργικού συστήματος.
• Το swap ως δικός του λογικός τόμος, με μέγεθος που υποστηρίζει αδρανοποίηση αν χρειαστεί.
• Το root (/) περιορισμένο σε σταθερό μέγεθος ώστε τίποτα εκτός των καθορισμένων διαδρομών να μην μπορεί να το γεμίσει. Αν το root γεμίσει, το σύστημα σταματά να λειτουργεί. Ο περιορισμός του είναι αμυντικός σχεδιασμός.

Η Κρυπτογράφηση Δεν Είναι Προαιρετική

Η κρυπτογράφηση δεν είναι προαιρετική εδώ, και η αιτιολόγηση είναι απλή. Αυτό είναι ένα laptop που λειτουργεί ως σταθμός εργασίας ασφαλείας και αποθηκεύει ευαίσθητα δεδομένα σε ηρεμία: καταγραφές honeypot, αντικείμενα επίθεσης, αποτελέσματα ανάλυσης δικτύου. Αν το μηχάνημα κλαπεί, χαθεί ή αποσυρθεί, κάθε δίσκος πρέπει να είναι αδύνατο να διαβαστεί χωρίς τη φράση πρόσβασης.

Η πλήρης κρυπτογράφηση δίσκου με LUKS είναι βασική απαίτηση για αυτή τη χρήση. Τελεία.

Αφήστε Περιθώριο στην Ομάδα Τόμων σας

Αυτή η λεπτομέρεια ξεχωρίζει τον καλό σχεδιασμό LVM από τον ερασιτεχνικό. Αφήστε περίπου 5-10% της ομάδας τόμων σας αδέσμευτο. Όχι χαμένο. Δεσμευμένο. Να γιατί:

Με το LVM, μπορείτε να μεγαλώσετε λογικούς τόμους εν κινήσει χωρίς επανεκκίνηση. Αν το Docker χρειαστεί περισσότερο χώρο σε έξι μήνες, επεκτείνετε τον LV και αλλάζετε μέγεθος στο σύστημα αρχείων σε δευτερόλεπτα. Αν είχατε δεσμεύσει τα πάντα εκ των προτέρων, θα έπρεπε να συρρικνώσετε έναν τόμο για να μεγαλώσετε έναν άλλο, και η συρρίκνωση είναι αργή, επικίνδυνη και μερικές φορές αδύνατη με ορισμένα συστήματα αρχείων.

Το εσκεμμένο περιθώριο είναι χαρακτηριστικό, όχι σπατάλη.

Το Νοητικό Μοντέλο του Επιπέδου Αποθήκευσης

Αυτό το νοητικό μοντέλο είναι το πιο πολύτιμο πράγμα που πρέπει να πάρετε από ολόκληρο αυτό το κεφάλαιο. Όχι τα μεγέθη κατατμήσεων. Όχι τα σημεία προσάρτησης. Αυτή η στοίβα 8 επιπέδων που εξηγεί πώς λειτουργεί πραγματικά η αποθήκευση Linux, από πάνω προς τα κάτω.

Οι περισσότερες αποτυχίες που θα αντιμετωπίσετε κατά την πραγματική εγκατάσταση, ειδικά με fstab και crypttab στο Μέρος 3, προέρχονται από σύγχυση αυτών των επιπέδων. Γράψιμο ενός UUID από το επίπεδο 2 όπου αναμενόταν το επίπεδο 6. Αναφορά σε μια διαδρομή συσκευής από το επίπεδο 3 σε μια ρύθμιση που χρειαζόταν το επίπεδο 1. Κάθε σφάλμα αποθήκευσης αντιστοιχεί σε αναντιστοιχία επιπέδου.

Αποθηκεύστε αυτή τη στοίβα. Χαράξτε την στο μυαλό σας. Μόλις εσωτερικεύσετε αυτά τα οκτώ επίπεδα, η αποθήκευση Linux σταματά να είναι μυστηριώδης. Είναι απλώς οκτώ πράγματα, καθένα κάνει μια δουλειά, συνδεδεμένα με σειρά.

Η Τελική Διάταξη NVMe

Ορίστε ο πλήρης σχεδιασμός για τον κύριο δίσκο NVMe:

Κύριος NVMe (nvme0n1)

Μέσα στο container LUKS στο nvme0n1p3:

nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (Ομάδα Τόμων)

Δευτερεύοντες Δίσκοι

SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis

HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive

Τρεις κρυπτογραφημένοι δίσκοι. Έξι λογικοί τόμοι στον κύριο. Κάθε φορτίο εργασίας στη δική του λωρίδα. Τίποτα δεν μοιράζεται χώρο με κάτι που δεν πρέπει.

Μετατρέποντας τον Σχεδιασμό σε Script Κατασκευής

Μόλις ο σχεδιασμός οριστικοποιηθεί, το επόμενο prompt είναι απλό:

"Δώσε μου τις ακριβείς εντολές για να κατασκευάσω ολόκληρη αυτή τη διάταξη αποθήκευσης από το ζωντανό περιβάλλον Kali. Υπόθεσε ότι και οι τρεις δίσκοι μπορούν να διαγραφούν."

Ζήτησε ένα πλήρες shell script: διαγραφή υπαρχόντων υπογραφών, δημιουργία πινάκων κατατμήσεων GPT, δημιουργία κατατμήσεων με sgdisk, δημιουργία κοντέινερ LUKS2 με ισχυρές προεπιλογές, άνοιγμά τους, αρχικοποίηση φυσικών τόμων LVM, δημιουργία της ομάδας τόμων, κατανομή και των έξι λογικών τόμων, μορφοποίηση όλων, και στη συνέχεια επανάληψη της ρύθμισης LUKS για τον SSD και τον HDD.

Περίμενε περίπου 80 γραμμές. Κάθε εντολή πρέπει να είναι ελέγξιμη. Αν κάτι στο script δεν σου βγάζει νόημα, ζήτησε από το AI να εξηγήσει εκείνη τη συγκεκριμένη γραμμή πριν την εκτελέσεις.

Τι Θα Πάει Στραβά (Και Δεν Θα Φταίει ο Σχεδιασμός)

Προειδοποίηση: ο σχεδιασμός θα είναι στέρεος. Η εκτέλεση θα σε δυσκολέψει. Να οι παγίδες που πρέπει να προσέξεις:

Αλλαγές γραμμής των Windows. Αν γράψεις το script σε μηχάνημα Windows και το μεταφέρεις στο ζωντανό περιβάλλον μέσω USB, κάθε γραμμή τελειώνει με \r\n αντί για \n. Το Bash πνίγεται σε κάθε μεμονωμένη εντολή και τα μηνύματα σφάλματος είναι κρυπτικά. Διόρθωσέ το με sed -i 's/\r$//' script.sh πριν εκτελέσεις οτιδήποτε.

Καταστροφή του shebang. Σχετίζεται με το πρόβλημα αλλαγής γραμμής. Η γραμμή #!/bin/bash αποκτά έναν αόρατο χαρακτήρα carriage return, οπότε ο πυρήνας δεν μπορεί να βρει τον interpreter. Το σφάλμα μοιάζει σαν το script να μην υπάρχει, παρόλο που υπάρχει ξεκάθαρα.

Σύγχυση διαδρομών. Το USB προσαρτάται σε μία διαδρομή, αλλά αναφέρεσαι στο script από διαφορετικό τρέχοντα κατάλογο. Η συμπλήρωση με Tab και οι σχετικές διαδρομές σε ζωντανό περιβάλλον είναι αναξιόπιστες όταν διαχειρίζεσαι πολλά σημεία προσάρτησης. Χρησιμοποίησε απόλυτες διαδρομές.

Λανθασμένη σύνταξη εκτέλεσης. Να ξεχνάς το ./ πριν από το όνομα του script, ή να μην ορίζεις πρώτα δικαιώματα εκτέλεσης. Κλασικά λάθη που δεν έχουν καμία σχέση με τον σχεδιασμό αποθήκευσης και όλα να σχετίζονται με τη μυϊκή μνήμη.

"Το AI μπορεί να γράψει το script, αλλά εσύ πρέπει ακόμα να καταλαβαίνεις τι επικολλάς. Αν μια εντολή δεν σου βγάζει νόημα, σταμάτα και ρώτα."

Μόλις τακτοποιηθούν τα προβλήματα αλλαγής γραμμής και εκτέλεσης, η κατασκευή αποθήκευσης ολοκληρώνεται σε λιγότερο από δύο λεπτά. Κάθε κοντέινερ LUKS ανοίγει. Κάθε δομή LVM δημιουργείται καθαρά. Κάθε σύστημα αρχείων μορφοποιείται. Ο σχεδιασμός αντέχει.

Επαλήθευσε Τα Πάντα με το Μοτίβο Επικόλλησης και Ελέγχου

Μην υποθέτεις επιτυχία. Αφού τελειώσει το script, επικόλλησε την έξοδο του τερματικού σου πίσω στο AI και ζήτησέ του να ελέγξει το αποτέλεσμα:

"Να η έξοδος lsblk και lvs μου. Κατασκευάστηκε όλα σωστά;"

Επικόλλησε την ακατέργαστη έξοδο του τερματικού και ζήτησε από το AI να τη διατρέξει γραμμή προς γραμμή. Θα πρέπει να επιβεβαιώσει: cryptnvme ενεργό, vgkali παρόν με έξι λογικούς τόμους στα σωστά μεγέθη, σωστά συστήματα αρχείων σε καθένα, δευτερεύοντες δίσκοι κρυπτογραφημένοι και μορφοποιημένοι.

Αυτό το μοτίβο επικόλλησης και επαλήθευσης είναι μία από τις πιο χρήσιμες τεχνικές για διαχείριση συστήματος με AI. Εκτελείς μια εντολή, επικολλάς την έξοδο και ρωτάς αν η πραγματικότητα ταιριάζει με το σχέδιο. Εντοπίζει προβλήματα που θα έχανες επειδή είσαι πολύ κοντά στη δουλειά:

• Ένας λογικός τόμος που μορφοποιήθηκε κατά λάθος με λάθος τύπο συστήματος αρχείων
• Ένας τόμος με μέγεθος σε megabytes ενώ εννοούσες gigabytes
• Μια κατάτμηση που λείπει και την οποία το script παρέλειψε αθόρυβα
• Ένα κοντέινερ LUKS που στην πραγματικότητα δεν άνοιξε

Μπορείς να το κάνεις αυτό με σχεδόν οποιαδήποτε κατάσταση συστήματος: lsblk, lvs, pvs, vgs, blkid, fdisk -l, cryptsetup status. Επικόλλησέ το. Ζήτησε από το AI να το ελέγξει. Είναι πιο γρήγορο και πιο διεξοδικό από το να ελέγχεις τα πάντα μόνος σου.

Το Συμπέρασμα: Σχεδίασε Βάσει Φόρτου Εργασίας, Όχι Προεπιλογών

Η διάταξη αποθήκευσης εδώ δεν επιλέχθηκε από κάποιο πρότυπο ούτε αντιγράφηκε από κάποια ανάρτηση σε φόρουμ. Προέκυψε από πραγματικές απαιτήσεις φόρτου εργασίας. Το Docker χρειάζεται απομόνωση χώρου. Οι βάσεις δεδομένων χρειάζονται αποκλειστικό IO. Τα μοντέλα AI χρειάζονται χώρο για να μεγαλώσουν. Τα αντικείμενα ασφαλείας χρειάζονται κρυπτογράφηση σε ηρεμία. Τα αρχεία χρειάζονται χωρητικότητα πάνω από ταχύτητα.

Κάθε απόφαση ανάγεται σε μια πραγματική απαίτηση. Αυτή είναι η διαφορά μεταξύ μιας διάταξης αποθήκευσης που επιβιώνει έξι μήνες και μιας που καταρρέει την πρώτη φορά που συμβεί κάτι απροσδόκητο.

Αυτή η προσέγγιση λειτουργεί για οποιαδήποτε κατασκευή, όχι μόνο για σταθμούς εργασίας ασφαλείας. Πες στο AI τι θα κάνει το μηχάνημα. Περίγραψε τις υπηρεσίες, τα μοτίβα δεδομένων, τις προσδοκίες ανάπτυξης, τα σενάρια αποτυχίας που θέλεις να επιβιώσεις. Στη συνέχεια άσε το να καταλάβει πώς να οργανώσει τους δίσκους. Η συλλογιστική που σου δείχνει είναι πιο πολύτιμη από τον τελικό πίνακα κατατμήσεων, γιατί θα καταλαβαίνεις γιατί έγινε κάθε επιλογή και πότε μπορεί να χρειαστεί να αλλάξει.

Οι δίσκοι σου είναι κατατμημένοι, κρυπτογραφημένοι και χωρισμένοι σε λογικούς τόμους. Η αρχιτεκτονική είναι έτοιμη. Τώρα έρχεται το κομμάτι που σπάει πραγματικά τους ανθρώπους: εγκατάσταση λειτουργικού συστήματος πάνω σε όλα αυτά χωρίς γραφικό πρόγραμμα εγκατάστασης να σε κρατά από το χέρι.

Στο Μέρος 3: Χειροκίνητη Εγκατάσταση, θα προσαρτήσεις τους κρυπτογραφημένους τόμους, θα εκκινήσεις το Kali από μηδενική βάση, θα συνδέσεις fstab και crypttab ώστε να ξεκλειδώνουν όλα κατά την εκκίνηση, και θα κατασκευάσεις μια λειτουργική ρύθμιση bootloader. Εδώ το μοντέλο 8 επιπέδων δοκιμάζεται για τα καλά, και εδώ ένα λάθος UUID μπορεί να σε αφήσει να κοιτάς μια προτροπή GRUB rescue. Φέρε καφέ.