118 γραμμές
15 KiB
Markdown
118 γραμμές
15 KiB
Markdown
+++
|
||
title = 'To \...δικό μας Linux. Γιατί και πως μέρος 2ο'
|
||
date = '2000-10-01T00:00:00Z'
|
||
description = ''
|
||
author = 'Μιχάλης Καμπριάνης(mailto:kabrianis@hellug.gr)'
|
||
issue = ['Magaz 27']
|
||
issue_weight = 5
|
||
+++
|
||
|
||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||
|
||
*Συνεχίζουμε την προσπάθεια για τη δημιουργία του δικού μας Linux, μπαίνοντας στα extra προγράμματα και τις ρυθμίσεις.*
|
||
|
||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||
|
||
Την περασμένη φορά (προηγούμενο τεύχος) είχαμε φτάσει να έχουμε ένα minimum σύστημα το οποίο κάνει boot και έχει δίκτυο, telnet, ftp, compiler (και όλα τα
|
||
απαιτούμενα tools για compile) και τα sources του πυρήνα. Αυτό το σύστημα το έχουμε και σε backup (ας το ονομάσουμε «στάδιο 2»). Τώρα πρέπει να κάνουμε το
|
||
fork\...
|
||
|
||
**1. Forking**
|
||
------------------------------------
|
||
|
||
**2. Κοινός server**
|
||
------------------------------------------
|
||
|
||
**3. Development μηχάνημα**
|
||
-------------------------------------------------
|
||
|
||
**4. Μεταφορά**
|
||
-------------------------------------
|
||
|
||
|
||
### [1. Forking]{#s1}
|
||
|
||
Από εδώ και πέρα, αποφασίζουμε τι ακριβώς ανάγκες θα εξυπηρετεί το μηχάνημά μας.\
|
||
Αν το μηχάνημα το «χτίζουμε» για (π.χ.) **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]{#s2}
|
||
|
||
Εφόσον δεν χρησιμοποιούμε κάποιο 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 που τρέχουν κλπ).
|
||
|
||
|
||
### [3. Development μηχάνημα]{#s3}
|
||
|
||
Αυτό το οποίο χρειάζομαι πραγματικά να έχω είναι ένα 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 κλπ).
|
||
|
||
|
||
### [4. Μεταφορά]{#s4}
|
||
|
||
Ωραία τα φτιάξαμε αυτά και δουλέυουν. Τι κερδίσαμε; Το όλο νόημα ήταν στην αρχή να μπορούμε να το μεταφέρουμε από δω κι από κει, όποιο \"παρακλάδι\" από αυτά
|
||
που είπαμε στο τμήμα 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.
|
||
|