💾 Archived View for magaz.hellug.gr › 27 › 05_lfs › index.gmi captured on 2024-02-05 at 09:36:46. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

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

Μιχάλης Καμπριάνης(mailto:kabrianis@hellug.gr)
Οκτ 2000

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

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

1. Forking

2. Κοινός server

3. Development μηχάνημα

4. Μεταφορά

[1. Forking]

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

Αν το μηχάνημα το «χτίζουμε» για (π.χ.) 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. (τόση δουλειά για να ξαναφτάσουμε εκεί που ξεκινήσαμε!!! :-)

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

[2. Κοινός server]

Εφόσον δεν χρησιμοποιούμε κάποιο 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 μου καλύπτει τις ανάγκες μου.

Τα σημαντικά (για μένα) κομμάτια είναι τα εξής:

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

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

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

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

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

Ωραία τα φτιάξαμε αυτά και δουλέυουν. Τι κερδίσαμε; Το όλο νόημα ήταν στην αρχή να μπορούμε να το μεταφέρουμε από δω κι από κει, όποιο "παρακλάδι" από αυτά που είπαμε στο τμήμα 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. Βέβαια έτσι κάνεις μόνο τυποποιημένες εγκαταστάσεις, αλλά μπορείς να τις τροποποιήσεις πολύ εύκολα (μια που ξέρεις ακριβώς τι υπάρχει μέσα) και, βέβαια, πόσες φορές χρειάζεσαι μία διαφορετική εγκατάσταση απ' ότι έκανες την περασμένη φορά;

Αν δεν σας φτάνουν αυτοί οι τρόποι, βρείτε κάποιον μόνοι σας. Εξάλλου, αυτή είναι η ομορφιά του Linux.

Αρχική Σελίδα