2. Βασικές αρχές

Καθώς ήδη είπαμε, οι clients μοιράζονται ολόκληρο το root-fs με τον server. Αλλά, φυσικά, οι clients μπορούν μόνο να το διαβάσουν : Αυτός είναι ο τρόπος λειτουργίας του συγκεκριμένου συστήματος.

2.1 Τα πράγματα δεν είναι τόσο απλά

Δυστυχώς, τα πράγματα δεν είναι τόσο απλά. Υπάρχουν καναδυό προβλήματα, που πρέπει να ξεπεράσουμε σ' αυτό το απλό σχήμα.

Κάθε ws χρειάζεται το (με δυνατότητα εγγραφής) δικό του αντίγραφο ενός αριθμού από καταλόγους.

Στο συνηθισμένο στήσιμο, το Linux πρέπει να μπορεί να γράψει στους εξής καταλόγους :

1. /dev
2. /var
3. /tmp

Υπάρχουν 3 λύσεις γι' αυτό, από τις οποίες η μία θα δουλέψει μόνο στο /dev :

1. φορτώνουμε ένα ramdisk και το γεμίζουμε με untarring ενός tarball, ή αντιγράφοντας ένα πρότυπο (template) κατάλογο.
   • Πλεονεκτήματα :
     1. Καθαρίζει με κάθε επανεκκίνηση, η οποία σβήνει αρχεία .tmp και αρχεία logs. Δεν χρειάζεται συντήρηση, αντίθετα απ' ό,τι οι κατάλογοι στην πλευρά του server.
     2. Δεν καταλαμβάνει χώρο στον server, και δε δημιουργεί κυκλοφορία στο δίκτυο. Ένα ramdisk χρησιμοποιεί λιγότερους πόρους του server και του δικτύου, και είναι ταχύτερο.
   • Μειονεκτήματα :
     1. Καταλαμβάνει μνήμη.
     2. Τα logs δεν διατηρούνται μετά από επανεκκίνηση. Εάν πραγματικά χρειάζεστε logging για όλα τα clients, πείτε στο syslog να επανακατευθύνει το logging προς τον server.
2. δημιουργούμε ένα dir για κάθε ws επάνω στον server, και το φορτώνουμε rw επάνω στο nfs.
   • Πλεονεκτήματα & μειονεκτήματα :
     1. Για τα dirs του server, τα παραπάνω πλεονεκτήματα-μειονεκτήματα αντιστρέφονται.
3. Στον kernel 2.2, το devfs μπορεί να χρησιμοποιηθεί αντί του /dev . Αυτό είναι ένα virtual filesystem, σαν το /proc του /dev.
   • 1. Πλεονεκτήματα :
     2. Το devfs χρειάζεται ελάχιστη μνήμη, μοιάζει με ramdisk / καθόλου χώρο σκληρού δίσκου επάνω στον server, και είναι ταχύτατο. Ένα συνηθισμένο /dev χρειάζεται τουλάχιστον 1.5 MB, αφού το ελάχιστο μέγεθος αρχείου (και άρα ενός device) είναι 1k, και υπάρχουν περίπου 1200 devices. Φυσικά, μπορείτε να χρησιμοποιήσετε ένα πρότυπο "απογυμνωμένου" /dev, με μόνο τα περιεχόμενα που θέλετε, για να εξοικονομήσετε κάμποσο χώρο. Το 1.5 MB είναι πολύ για ramdisk, και επίσης δεν είναι ωραίο επάνω στον server.
     3. Το devfs αυτόματα δημιουργεί καταχωρήσεις για τις νέες και τις ανιχνευμένες συσκευές, συνεπώς δεν χρειάζεται συντήρηση.
   • Μειονεκτήματα :
     1. Χάνεται κάθε αλλαγή στο /dev , όπως η δημιουργία symlinks για το ποντίκι και το cd-rom. To devfs έχει ένα script, το rc.devfs, που σώζει αυτές τις αλλαγές. Τα scripts, που σας δίνω σ' αυτό εδώ το howto, αποκαθιστούν αυτόματα τις ρυθμίσεις των symlinks, καλώντας το rc.devfs . Αν κάνετε οποιεσδήποτε αλλαγές στο /dev , χρειάζεται να καλέσετε εσείς το rc.devfs, για να τις σώσετε, δίνοντας :

     /etc/rc.d/rc.devfs save /etc/sysconfig

Όπως βλέπετε, υπάρχουν κάμποσοι τρόποι για να λυθεί αυτό το πρόβλημα. Για το υπόλοιπο μέρος αυτού του howto, κρατάμε τις ακόλουθες επιλογές :

• Αντί για το /dev , θα χρησιμοποιούμε το devfs.
• Αντί για τα /var και /tmp , θα χρησιμοποιούμε ένα διαμοιραζόμενο (shared) ramdisk του ενός MB. (Το κάνουμε shared, για να χρησιμοποιήσουμε τον χώρο του όσο το δυνατόν αποτελεσματικότερα.) Το /tmp αντικαθίσταται μ' ένα symlink προς το /var/tmp , για να κάνουμε εφικτό τον διαμοιρασμό.
• Δουλεύει εξ ίσου καλά το να γεμίσουμε το ramdisk με tarballs, ή πρότυπα (template) dirs. Αλλά με τα πρότυπα directories είναι πολύ ευκολότερο να κάνουμε αλλαγές, άρα θα χρησιμοποιήσουμε αυτά.

Μπορεί ν' αναγκαστούμε να δώσουμε δικαίωμα εγγραφής στο /home

Δεν είναι πραγματικό πρόβλημα, αφού σε κάθε στήσιμο client/server σε *nix συστήματα το /home φορτώνεται rw από τον server. 'Αρα, θα κάνουμε ακριβώς αυτό! ;)

Πώς βρίσκει ένας ws το ip του, ώστε να επικοινωνήσει με τον server;

Ευτυχώς για μας, αυτό το πρόβλημα έχει ήδη λυθεί, και ο πυρήνας του Linux υποστηρίζει δύο τρόπους αυτόματου καθορισμού της διεύθυνσης ip :

1. RARP
2. Bootp

Το rarp είναι ευκολότερο στη ρύθμιση, το bootp είναι το πιο ευέλικτο. Μιά που οι περισσότερες bootroms (ROMs εκκίνησης από κάρτα δικτύου) υποστηρίζουν μόνο το bootp, αυτό και θα χρησιμοποιήσουμε.

Τί γίνεται με τις ρυθμίσεις για κάθε ws

Στο RedΗat, τα περισσότερα αρχεία ρυθμίσεων που εξαρτώνται από τον συγκεκριμένο Η/Υ, βρίσκονται ήδη στο /etc/sysconfig . Εμείς θα μετακινήσουμε μονάχα όσα δεν βρίσκονται εκεί, και θα βάλουμε symlinks. Μετά, θα φορτώσουμε ένα ξεχωριστό /etc/sysconfig για κάθε ws. Κι αυτό είναι το μόνο μέρος των ρυθμίσεων, που εξαρτάται από τη distribution : Σε άλλες distributions, μπορείτε απλά να φτιάξετε ένα directory ρυθμίσεων, να μετακινήσετε όλα τα μη διαμοιραζόμενα αρχεία ρυθμίσεων εκεί, και να δημιουργήσετε symlinks. Επίσης, το /etc/rc.d/rc3.d (ή τα παρόμοια των υπολοίπων distributions) μπορεί να χρειαστεί να διαφοροποιηθούν στον server, απ' ό,τι είναι στους workstations. Υποθέτοντας ότι όλοι οι ws τρέχουνε τις ίδιες services στο runlevel 3, θα φτιάξουμε ξεχωριστά runlevels 3 για τους workstations και τον server :

1. κατασκευή του /etc/rc.d/rc3.ws και του /etc/rc.d/rc3.server
2. κάνουμε το /etc/rc.d/rc3.d symlink προς το /etc/sysconfig/rc3.d
3. κάνουμε το /etc/sysconfig/rc3.d symlink προς το κατάλληλο /etc/rc.d/rc3.xxx
4. αντικαθιστούμε το S99local στο rc3.ws μ' ένα link προς το /etc/sysconfig/rc.local , ώστε κάθε ws να έχει το δικό του rc.local

Διάφορα προβλήματα

Υπάρχουν ακόμη κάποια προβλήματα :

1. Το /etc/rc.d/rc.sysinit χρειάζεται το /var, άρα το /var πρέπει να φορτωθεί ή να δημιουργηθεί πριν τρέξει το /etc/rc.d/rc.sysinit . Επίσης, καλό θα ήταν το για κάθε ws /etc/sysconfig να φορτωθεί πριν τρέξουν οποιαδήποτε initscripts.
   • Θα δώσουμε τον κώδικα για ένα script εκκίνησης για ws, επάνω-επάνω στο /etc/rc.d/rc.sysinit . Σημειώστε ότι αυτό το script θα το τρέξει (φυσικά) και ο server κατά την εκκίνηση, άρα το script πρέπει να προβλέψει αυτό το ενδεχόμενο, και να μην κάνει τίποτε επάνω στον server.
2. Πρέπει να μπορούμε να γράψουμε στο /etc/mtab :
   • Αυτό εδώ μπορεί να μας κάνει κόλπα! Απλά φτιάξτε ένα link προς το /proc/mounts , και επίσης φτιάξτε ένα άδειο αρχείο mounts στο /proc , ώστε τα fsck και mount να μην παραπονεθούν όσο τρέχουν τα initscripts, όταν το /proc δεν έχει φορτωθεί ακόμη. Σημείωση : Το smb(u)mount δεν σέβεται το να είναι link το mtab, και γράφεται πάνω του. Αρα, αν θέλετε να χρησιμοποιήσετε το smb(u)mount, φτιάξτε wrapper scripts, που αποκαθιστούν το symlink.