gemini://magaz.hellug.gr/27/05

Συνεχίζουμε την προσπάθεια για τη δημιουργία του δικού μας Linux, μπαίνοντας στα extra προγράμματα και τις ρυθμίσεις.

Την περασμένη φορά (προηγούμενο τεύχος) είχαμε φτάσει να έχουμε ένα minimum σύστημα το οποίο κάνει boot και έχει δίκτυο, telnet, ftp, compiler (και όλα τα απαιτούμενα tools για compile) και τα sources του πυρήνα. Αυτό το σύστημα το έχουμε και σε backup (ας το ονομάσουμε «στάδιο 2»). Τώρα πρέπει να κάνουμε το fork...

Αν το μηχάνημα το «χτίζουμε» για (π.χ.) stand-alone workstations φοιτητών σε Πανεπιστήμιο που θα μπαίνουν Internet, θα θέλουν mail, browser, editor και λοιπά παρόμοια προγράμματα, δεν χρειάζεται να του βάλουμε καθόλου servers και απλά θα εγκαταστήσουμε (αν τίθεται τέτοια απαίτηση για την χρήση του workstation) τα X-windows. Μπορούμε να μην σηκώνουμε καν το inetd για παράδειγμα, και ούτε κουβέντα για Apache, sendmail, postgres/mysql, squid και λοιπά καλούδια που μας βάζουν συνήθως οι distributions.

Αν το μηχάνημα το «χτίζουμε» για να εξυπηρετεί συγκεκριμένο service (π.χ. θα γίνει mail server) τότε απλά του εγκαθιστούμε το αντίστοιχο service και ένα πρόγραμμα για remote access. Σε όλες τις περιπτώσεις, για remote access προτιμώ το ssh έναντι των παραδοσιακών telnet/ftp. Δεν συζητάμε καθόλου βέβαια για r-tools εκτός αν πρόκειται το μηχάνημα να είναι backup-server (το rmt χρειάζεται rshd). Δημιουργούμε τα αντίστοιχα scripts για να σηκώνονται και να σταματάνε τα σχετικά services, κατά τα παραδείγματα του Gerard.

Αν μιλάμε για περίπτωση «τυπικού» server που θα εξυπηρετεί web, mail, dns, μία (τουλάχιστον) βάση, ίσως news, ότι σκεφτούμε δηλαδή (κλασικά παραδείγματα τέτοιων μηχανημάτων είναι ο tux.hellug.gr και το igloo.linux.gr, τα μηχανήματα του συλλόγου), τότε ξεκινάμε και εγκαθιστούμε όλα τα services, πολλά extra-libs, φτιάχνουμε όλα τα scripts για startup-shutdown, ίσως ακόμα και να πρέπει να φτιάξουμε (επιτέλους;) και κάποιο inetd.conf για να ξεκινάμε τον inetd (ανάλογα με τις απαιτήσεις πάλι), σίγουρα κάποιο cron, θα αυτοματοποιήσουμε κάποιες εργασίες... Πολλή δουλειά.

Τέλος, μπορεί να θέλουμε να φτιάξουμε ένα πλήρες development μηχάνημα, το οποίο όπως το εννοώ εγώ είναι ένας συνδυασμός της πρώτης και τελευταίας από τις προαναφερθείσες περιπτώσεις. Δηλαδή πολλούς servers (που θα «σηκώνουμε» κατ' επιλογή όποιον/όποιους χρειαζόμαστε για να κάνουμε τους ελέγχους μας) και τα X-windows με τα αντίστοιχα προγράμματα για ppp, internet, writing-tools κλπ, ότι δίνει δηλαδή ένα distribution. (τόση δουλειά για να ξαναφτάσουμε εκεί που ξεκινήσαμε!!! :-)

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

Εφόσον δεν χρησιμοποιούμε κάποιο standard package management software (π.χ. rpm) πρέπει να έχουμε κάποιο τρόπο, να «κρατάμε» κάπου ένα κατάλογο με το αρχεία βάλαμε και σε ποιο σημείο. Εγώ χρησιμοποίησα το installwatch για αυτό το λόγο (και τώρα ετοιμάζομαι μα γράψω ένα απλό uninstall script που να παίρνει σαν input τα logs του installwatch) και θα πρότεινα, για να μην βρεθείτε πιο χαμένοι από ότι ξεκινήσατε, να χρησιμοποιήσετε κι εσείς κάποιο τέτοιο πακέτο.

Οι servers που εγκατέστησα (όχι ότι έχει και σημασία αφού όπως είπαμε ο καθένας βάζει ότι τον εξυπηρετεί) είναι οι apache, mysql, qmail, bind, sshd, ενώ και ένας nfs server μου φάνηκε χρήσιμος κάποια στιγμή (για να κάνω «βαριά» compiles στο άλλο, γρήγορο μηχάνημα που έχω... το πως και γιατί στο περίπου, μπορείτε να το βρείτε στο πρώτο-πρώτο τεύχος του magaz που ο Φώτης Γεωργάτος χρησιμοποίησε το ίδιο τρικ για να κάνει compile τον πυρήνα σε ένα μηχάνημα). Φυσικά εγκατέστησα και ένα cron, και μια που το παραδοσιακό cron είναι αρκετά παλιό, εγκατέστησα το fcron. Προτίμησα το qmail αντί για το sendmail για λόγους ασφαλείας και επειδή το qmail μου καλύπτει τις ανάγκες μου.

Έβαλα ολόκληρα τα πακέτα σε δικά τους ξεχωριστά directory (π.χ. o apache μπήκε στο /usr/local/apache). Αυτό ήταν εύκολο για ορισμένα πακέτα (apache, inn) και πιο δύσκολο για άλλα (mysql) ενώ για κάποια ακόμα (π.χ. ssh) δεν είχε νόημα.

Έφτιαξα (η άλλαξα όσα υπήρχαν έτοιμα) τα startup - shutdown scripts τα οποία μπήκαν στο /etc/init.d και φτιάχτηκαν τα αντίστοιχα links στο /etc/rc.d.

Αν έχουμε ένα παράλληλο μηχάνημα με τις ίδιες ρυθμίσεις μπορούμε να κάνουμε αυτό που προτείνουν πολλοί security experts, να μην αφήσουμε δηλαδή compiler(s) στο μηχάνημα και να αφαιρέσουμε όλα τα sources. Ένα tripwire ή ένα md5sum που το βάζουμε να "τρέχει" κάθε βράδυ και να μας στέλνει με mail τα αποτελέσματα για να τα συγκρίνουμε με τα αρχικά, μας βοηθάει και μας δημιουργεί λίγο την ψευδαίσθηση ότι το μηχανάκι μας είναι ασφαλές. Εμείς πάντως κάναμε ότι έπρεπε, από αυτή τη μεριά (γιατί υπάρχει πάντα και το θέμα του administration της βάσης, τα τυχόν cgi scripts που τρέχουν κλπ).

Αυτό το οποίο χρειάζομαι πραγματικά να έχω είναι ένα development μηχάνημα, το οποίο θα χρησιμοποιώ ως εξής:

Στήνω όλα τα services όπως στον server. Ένα ακριβές αντίγραφο του server. Ελλείψη τρίτου μηχανήματος, το κάνω αυτό στο βασικό μου μηχάνημα.

Περνάω επάνω ότι extra προγράμματα χρειάζομαι, όπως X-Windows, mail-client, browser, editors κλπ για να μπορώ να το δουλέψω χωρίς κανένα πρόβλημα. Τα βασικά στα βασικά τους σημεία (π.x. τα X-Windows στο /usr/X11R6) και τα μη βασικά εκεί που θέλω (π.χ. όλα τα γραφικά προγράμματα στο /opt και όλα τα προγράμματα κονσόλας στο /opt/local).

Θυμάστε που είπα προηγουμένως ότι όλα τα services τα έβαλα σε δικά τους directory; Ε, όλα τα directories ήταν και στο ίδιο filesystem (/usr/local). Ένα level 0 backup του filesystem σήμερα, και ένα differential όταν τελειώσω το development (της τυχόν εφαρμογής, ή τον έλεγχο της τυχόν νέας έκδοσης), με καλύπτει κατά 99% για πλήρη μεταφορά στον server. Το 1% που αφήνω είναι για τυχόν περιπτώσεις που δεν μου έρχονται τώρα στο μυαλό.

Μεταφέροντας το differential backup στον server, ξαναπαίρνω ένα level 0 backup και βρίσκομαι πάλι σε αυτό που μπορούμε να ονομάσουμε checkpoint.

Το εν λόγω μηχάνημα λοιπόν έχει περασμένα (εκτός από τα προγράμματα του server) και τα XFree86-4.01, gtk και glib (καθώς και gnome-libs και gnome-includes της έκδοσης 1.2), και τα υπόλοιπα desktop tools (Staroffice, Netscape, Acrobat κλπ).

Ωραία τα φτιάξαμε αυτά και δουλέυουν. Τι κερδίσαμε; Το όλο νόημα ήταν στην αρχή να μπορούμε να το μεταφέρουμε από δω κι από κει, όποιο "παρακλάδι" από αυτά που είπαμε στο τμήμα Forking θέλουμε, χωρίς πρόβλημα. E, αυτό είναι εύκολο...

1. Κατ' αρχάς υπάρχει η παραδοσιακή (και πολλές φορές καλύτερη) μέθοδος με το tar. Προσοχή λίγο στις παραμέτρους (συγκεκριμένα για τα permissions) και έχετε ένα tar image του συστήματός σας. Αν στο νέο σύστημα boot-άρετε από μία ειδική δισκέτα (π.χ. tom's boot disk), κάνετε mount ένα CD που έχετε το εν λόγω image, και κάνετε untar το image στον δίσκο, το μόνο που χρειάζεται να κάνετε μετά είναι ένα chroot στον νέο δίσκο, διόρθωμα αν χρειάζεται του /etc/fstab και /etc/lilo.conf, τρέχουμε ένα lilo και reboot. Θεωρητικά όλα είναι έτοιμα. Για να πω την αλήθεια, όχι μόνο θεωρητικά. Αυτή τη μέθοδο χρησιμοποίησα για να αντιγράψω το βασικό "server" μηχάνημα στο development.

2. Υπάρχει η λύση του cluclo (cluster cloning) αν το νέο μηχάνημα έχει δίκτυο. Διαβάστε το documentation καλά κάντε τα 3-4 βήματα που λέει, και είστε έτοιμοι.

3. Κάποιος μου είπε για κάποιο πρόγραμμα με όνομα ghost που κάνει κάτι τέτοιο, αλλά είναι λέει για Windows οπότε δεν μπόρεσα να το δοκιμάσω.

4. Υπάρχει και το αντίστοιχο (ίδιο;) πρόγραμμα open source για Linux. Λέγεται Partition Image και θα το βρείτε και αυτό στο Freshmeat. Από μία σύντομη ματιά που έριξα στο documentation, κρίνω ότι μάλλον είναι ιδιαίτερα εύχρηστο και ευέλικτο.

5. Πάντα παίζει και η λύση του dd. Βάζουμε δηλαδή τον δίσκο του νέου μηχανήματος στο παλιό μηχάνημα, και αν ο δίσκος είναι ίδιος του κάνουμε ένα dd και τελειώνει η υπόθεση, ενώ αν οι δίσκοι διαφέρουν, παίζουμε λίγο με τα partitions και κάνουμε dd το partition.

Όλες οι μέθοδοι που αναπτύξαμε πιο πάνω, είναι σαφώς πιο γρήγορες από μία εγκατάσταση από CD. Βέβαια έτσι κάνεις μόνο τυποποιημένες εγκαταστάσεις, αλλά μπορείς να τις τροποποιήσεις πολύ εύκολα (μια που ξέρεις ακριβώς τι υπάρχει μέσα) και, βέβαια, πόσες φορές χρειάζεσαι μία διαφορετική εγκατάσταση απ' ότι έκανες την περασμένη φορά;

To ...δικό μας Linux. Γιατί και πως μέρος 2ο

[1. Forking]

[2. Κοινός server]

[3. Development μηχάνημα]

[4. Μεταφορά]