Πρώτο commit
Αυτό το commit περιλαμβάνεται σε:
infl00p
commit
8ec8e9bee2
451 αρχεία άλλαξαν με 46736 προσθήκες και 0 διαγραφές
416
content/articles/35/01_X-Windows.md
Κανονικό αρχείο
416
content/articles/35/01_X-Windows.md
Κανονικό αρχείο
|
|
@ -0,0 +1,416 @@
|
|||
+++
|
||||
title = 'X-windows, πως και γιατί;'
|
||||
date = ''
|
||||
description = ''
|
||||
author = 'Καπελώνης Κωστής kkapelon _AT_ freemail.gr(mailto:kkapelonSPAM@SUXfreemail.gr)'
|
||||
issue = ['Magaz 35']
|
||||
issue_weight = 1
|
||||
+++
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Στο άρθρο αυτό προσπαθούμε να αποκαλύψουμε τις πραγματικές δυνατότητες των X-windows οι οποίες συχνά είναι άγνωστες στους χρήστες τους. Βασικά θέλουμε να πούμε
|
||||
ότι τα X-Windows ΔΕΝ είναι το γραφικό περιβάλλον του Linux. Αν και σήμερα (κυρίως μέσα από το KDE και το GNOME) χρησιμοποιούνται με αυτόν τον τρόπο, στην
|
||||
πραγματικότητα η φιλοσοφία πίσω από τα X-Windows είναι λίγο διαφορετική. Το άρθρο απευθύνεται σε μέσους χρήστες GNU/Linux (και ορεξάτους αρχάριους).*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Εισαγωγή**
|
||||
-------------------------------------------
|
||||
|
||||
**2. X-Windows το γιατί (η αλλιώς η θεωρία)**
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
- [2.1 Αρχιτεκτονική](#ss2.1)
|
||||
- [2.2 Περί ενοποίησης (Integration).](#ss2.2)
|
||||
- [2.3 Όλα για το δίκτυο](#ss2.3)
|
||||
- [2.4 Απόκρυψη των λεπτομερειών (abstraction)](#ss2.4)
|
||||
- [2.5 Δύο εφαρμογές με ενδιαφέρον](#ss2.5)
|
||||
|
||||
**3. X-Windows το πως (η αλλιώς η πράξη)**
|
||||
----------------------------------------------------------------------
|
||||
|
||||
- [3.1 Ο εύκολος τρόπος](#ss3.1)
|
||||
- [3.2 Ο δύσκολος τρόπος](#ss3.2)
|
||||
- [3.3 Ο ασφαλής τρόπος](#ss3.3)
|
||||
|
||||
**4. Άλλα θέματα και επίλογος**
|
||||
-----------------------------------------------------------
|
||||
|
||||
|
||||
### [1. Εισαγωγή]{#s1}
|
||||
|
||||
Χρησιμοποιείτε GNU/Linux εδώ και λίγο καιρό. Αν ανάμεσα στα χιλιάδες ερωτήματα σας είναι και τα παρακάτω\...
|
||||
|
||||
- Γιατί το γραφικό περιβάλλον του Linux είναι τόσο αργό;
|
||||
- Τι εννοούν οι \"παλιοί\" όταν λένε ότι τα X-Windows είναι \"network-transparent\";
|
||||
- Παλαιότερα λέγαν ότι το Linux ήταν πολύ πιο γρήγορο από τα MSWindows, σήμερα όμως είναι πιο αργό στην πραγματικότητα. Γιατί;
|
||||
- Γιατί τα X-Windows αναφέρονται ως \"σύστημα\";. Δεν είναι απλά το γραφικό περιβάλλον του Linux;
|
||||
- Τι εννοεί η τάδε διανομή όταν λέει ότι δεν χρησιμοποιεί πια XFREE86 αλλά τον server από το X.org ;
|
||||
- Υπάρχει κάτι αντίστοιχο σε remote assistance/desktop για Linux συστήματα;
|
||||
|
||||
\...τότε αυτό το άρθρο είναι γραμμένο για σας! Αν όχι τότε μπορείτε να γράψετε και να στείλετε το δικό σας άρθρο στο Magaz. Το περιμένουμε με αγωνία!
|
||||
|
||||
|
||||
### [2. X-Windows το γιατί (η αλλιώς η θεωρία)]{#s2}
|
||||
|
||||
Τα X-Windows δεν αποτελούν εξαίρεση στον κανόνα. Ακολουθούν και αυτά την φιλοσοφία του Unix. Δηλαδή κατασκευάζουμε μικρά προγράμματα που κάνουν μια δουλειά καλά
|
||||
και δίνουμε στον προγραμματιστή την μέγιστη ελευθερία να προσαρμόσει το περιβάλλον του όπως θέλει. (το \"μικρά\" βέβαια σε αυτήν την περίπτωση είναι
|
||||
αμφιλεγόμενο)
|
||||
|
||||
Αυτό έρχεται σε αντίθεση με τα καταναλωτικά λειτουργικά συστήματα (γκουχ,γκουχ) που πιστεύουν ότι \"ξέρουμε τι θέλουν οι χρήστες μας πριν από αυτούς για αυτούς
|
||||
και θα τους παρέχουμε εμείς το καλύτερο γραφικό περιβάλλον. Ξέρουμε βέβαια ότι αυτό θα ικανοποιήσει μόνο το 80% των χρηστών. Δεν πειράζει όμως, το υπόλοιπο 20%
|
||||
ας πάει να πνιγεί\".
|
||||
|
||||
### [2.1 Αρχιτεκτονική]{#ss2.1}
|
||||
|
||||
Μετά από αυτήν την σύντομη αλλά αναγκαία προπαγάνδα μπορούμε να δούμε τα πράγματα από μια πιο ρεαλιστική σκοπιά. Έτσι λοιπόν ένα μονολιθικό λειτουργικό σύστημα
|
||||
που βασίζεται στην πλήρης ενοποίηση (integration) όλων των υποσυστημάτων του μοιάζει κάπως έτσι [\[εικόνα\]](/35/img/integrated.png)
|
||||
|
||||
Κύριο πλεονέκτημα αυτής της αρχιτεκτονικής είναι βέβαια ή ταχύτητα. Με αυτό εννοούμε ότι όλα τα υποσυστήματα (άρα και το γραφικό περιβάλλον) είναι πλήρως
|
||||
εναρμονισμένα μεταξύ τους (αφού είναι εντελώς προβλέψιμη η σύνθεση τους) και τα κανάλια επικοινωνίας μεταξύ τους είναι τα βέλτιστα δυνατά.
|
||||
|
||||
Αντιθέτως σε ένα GNU/Linux σύστημα όπου Linux σημαίνει μόνο ο πυρήνας (φαντάζομαι ότι το ξέρετε αυτό :-) τα πράγματα είναι κάπως έτσι
|
||||
[\[εικόνα\]](/35/img/modular.png) . Η εικόνα δείχνει ένα σύστημα βασισμένο σε gtk+/GNOME αλλά ανάλογα πράγματα ισχύουν και για QT/KDE.
|
||||
|
||||
Το όλο σύστημα δηλαδή αποτελείται από αυτοδύναμα κομμάτια τα οποία μπορούν να να συνεργαστούν με διάφορους τρόπους μεταξύ τους. Κύριο πλεονέκτημα αυτής της
|
||||
αρχιτεκτονικής είναι η επεκτασιμότητα και η ευελιξία. Έτσι είναι δυνατόν κάποιος ανάλογα με τις ανάγκες του να αρχίσει να αφαιρεί από \"την κορυφή\"
|
||||
υποσυστήματα φτάνοντας σε ένα πιο ελαφρύ σύστημα.
|
||||
|
||||
Θα μπορούσατε ας πούμε να αφαιρέσετε το GNOME και να βάλετε έναν άλλο απλό window manager κρατώντας όμως τις Gtk βιβλιοθήκες. H να αφήσετε μόνο τα ίδια τα
|
||||
X-windows για να τρέχετε μόνο μια συγκεκριμένη εφαρμογή σε Motif. Η ακόμα να αφαιρέσετε όλο το γραφικό περιβάλλον αφήνοντας μόνο τον πυρήνα και τις εφαρμογές
|
||||
κονσόλας, έχοντας έτσι ένα πολύ γρήγορο σύστημα ιδανικό για server.
|
||||
|
||||
Στην πραγματικότητα βέβαια επειδή κάποιος θέλει να τρέχει πολλά και διαφορετικά προγράμματα τα πράγματα δεν είναι τόσο απλά. Έτσι αν είστε στο KDE και σηκώσετε
|
||||
το Mozilla θα φορτωθούν όλες οι βιβλιοθήκες του στην ίδια μνήμη που είναι ήδη φορτωμένες αυτές του KDE. Αν σηκώσετε και GIMP ας πούμε θα έχετε και το GTK+ να
|
||||
καταναλώνει μνήμη. Ουσιαστικά δηλαδή σε ένα μηχάνημα έχετε 3 ειδών βιβλιοθήκες. Αυτήν την ευελιξία (πολλά είδη εφαρμογών) την πληρώνετε σε απόδοση (μνήμη)
|
||||
|
||||
Επίσης είναι δυνατόν να αλλάξουν τα \"κάτω\" ή τα \"πάνω\" επίπεδα του συστήματος χωρίς καμία επίπτωση. Όπως θα ξέρετε τα X-windows δεν είναι αποκλειστικό
|
||||
προνόμιο του Linux. Τα \*ΒSDς τρέχουν επίσης X-Windows όπως και μερικά εμπορικά Unix (π.χ. Solaris). Αυτό δίνει πάλι μεγάλη ευελιξία καθώς ένα πρόγραμμα που
|
||||
χρησιμοποιεί μόνο γραφικές βιβλιοθήκες (Xlib και πάνω) τρέχει όπου υπάρχουν X-windows άσχετα με το αν \"από κάτω\" υπάρχει Linux/FreeBSD/Solaris ή οτιδήποτε
|
||||
άλλο.
|
||||
|
||||
Τα KDE/GNOME για παράδειγμα τρέχουν άνετα σε FreeBSD. Προφανώς θα μεταφέρθηκαν (ported) κάποια συγκεκριμένα κομμάτια από το ένα σύστημα στο άλλο, αλλά κανείς
|
||||
δεν ξανάγραψε κώδικα \"από το γραφικό περιβάλλον του Linux\" στο \"γραφικό περιβάλλον του FreeBSD\".
|
||||
|
||||
Τέλος, η αντικατάσταση των πάνω επιπέδων σημαίνει αντικατάσταση των X-Windows. Τι σημαίνει αυτό; Τι θα μπορούσαμε να βάλουμε στην θέση τους; Εδώ φτάνουμε σε ένα
|
||||
σημαντικό σημείο του άρθρου. Τα x-windows (η επίσημα \"The X-Window system\") είναι απλά μια περιγραφή (specification). Ο XFree86 είναι απλά μια δωρεάν
|
||||
υλοποίηση (implementation). Υπάρχουν και άλλες υλοποιήσεις. Προφανώς αρκετές είναι forks του XFree86 αλλά υπάρχουν και εμπορικές εκδόσεις με διάφορα
|
||||
χαρακτηριστικά (π.χ. 3D επιτάχυνση). Τον τελευταίο καιρό λόγω διάφορων νομικών επιπλοκών με την άδεια χρήσης του XFree86 αρκετές διανομές ψάχνουν εναλλακτικές
|
||||
λύσεις. Αυτό όμως δεν έχει καμία επίπτωση στο τεχνικό επίπεδο. Όλες οι γραφικές εφαρμογές μπορούν να λειτουργήσουν όπως και πριν.
|
||||
|
||||
### [2.2 Περί ενοποίησης (Integration).]{#ss2.2}
|
||||
|
||||
Μέχρι στιγμής δεν έχουμε πει τίποτα καινούριο. Γιατί λοιπόν αυτή η ευελιξία που προσφέρουν τα X-Windows μεταφράζεται σε μειωμένη απόδοση; (άσχετα με το μπάχαλο
|
||||
με τις πολλές βιβλιοθήκες που έχει μεγαλύτερη επίπτωση στην μνήμη παρά σε επεξεργαστική ισχύ). Η απάντηση είναι η εξής.
|
||||
|
||||
Κάθε γραφικό πρόγραμμα (Χ client) είναι μια εφαρμογή που στο 99% των περιπτώσεων αναλογεί σε μία διεργασία του Unix (process). Το ίδιο όμως το υποσύστημα
|
||||
γραφικών (Χ server) που ελέγχει οθόνη, πληκτρολόγιο και ποντίκι είναι επίσης απλά άλλη μία διεργασία του συστήματος που τρέχει πάνω από τον πυρήνα (userspace).
|
||||
Ξαναδιαβάστε την τελευταία πρόταση δύο φορές. Δεν υπάρχει καμία ειδική μεταχείριση μέσα στο πυρήνα του Linux για γραφικά ή για Χ servers ή για διάφορα άλλα
|
||||
τέτοια. (Εδώ κλέβω λίγο βέβαια, αλλά αν το ξέρετε αυτό είστε αρκετά έμπειρος ώστε αυτό το άρθρο μάλλον δεν σας ενδιαφέρει). Το \"γραφικό περιβάλλον\" είναι
|
||||
δηλαδή άλλο ένα πρόγραμμα που μοιράζεται τους πόρους του μηχανήματος στην ίδια βάση με τα υπόλοιπα προγράμματα που τρέχουν εκείνη την στιγμή (κονσόλας ή
|
||||
γραφικά).
|
||||
|
||||
Αυτό μπορείτε να το διαπιστώσετε και οι ίδιοι. Με ένα απλό ps μπορείτε να βρείτε τον ίδιο τον Xserver και \"σκοτώνοντας\" τον θα καταρρεύσει αυτομάτως όλο το
|
||||
γραφικό περιβάλλον. Τόσο απλά. Μάλιστα μπορείτε να χρησιμοποιήσετε τις κλασσικές εντολές του Unix πάνω στον Xserver. Για παράδειγμα με την εντολή nice μπορείτε
|
||||
να ανεβάσετε ή να μειώσετε την προτεραιότητα του Xserver σε σχέση με τα άλλα προγράμματα. Ακόμα και στα επίπεδα πάνω από τα ίδια τα X-Windows η λογική είναι η
|
||||
ίδια. O window manager που σχεδιάσει τα περιγράμματα των παραθύρων και ασχολείται με την θέση τους είναι επίσης απλά άλλο ένα userspace πρόγραμμα. Τα ίδια
|
||||
ισχύουν και για KDE/GNOME. Το πάνελ τους, o window manager, ο file manager κ.τ.λ είναι \"κανονικά\" προγράμματα χωρίς κάποιο ειδικό χαρακτηριστικό.
|
||||
|
||||
Ξαναδείτε τις δύο εικόνες που αναφέρθηκαν προηγουμένως. Αν φανταστείτε ότι κάθε \"βελάκι\" αποτελεί μία σημαντική καθυστέρηση (communication overhead) μπορείτε
|
||||
εύκολα να δείτε ότι ένα σύστημα βασισμένο σε GNOME/KDE και γενικά με X-Windows πληρώνει μερικές έξτρα καθυστερήσεις οι οποίες πολύ απλά δεν υπάρχουν σε ένα
|
||||
μονολιθικό λειτουργικό σύστημα όπου τα πάντα είναι ενωμένα (και ο πυρήνας έχει και λειτουργίες για γραφικά).
|
||||
|
||||
Αυτό είναι το τίμημα που πληρώνετε για την ευελιξία των X-Windows. Να το θυμάστε λοιπόν την επόμενη φορά που θα επιδοθείτε στο αγαπημένο σπορ των απανταχού
|
||||
Unixάδων, αυτό δηλαδή της εύρεσης του κατάλληλου συνδυασμού window manager/background/theme/dockapps/desklets/toolbars/panels που θα σας δώσουν το \"τέλειο\"
|
||||
υπολογιστικό περιβάλλον.
|
||||
|
||||
Ειδικά το GNOME και το KDE πάσχουν σε ταχύτητα όσο καλός και αν είναι ο κώδικας τους (το KDE βέβαια πρέπει να παραδεχτώ ότι έχει κάνει τρομερή πρόοδο στον τομέα
|
||||
ταχύτητα) γιατί είναι κατασκευασμένα για να παρέχουν λειτουργίες και να μιμούνται το περιβάλλον ενός μονολιθικού λειτουργικού συστήματος, κάτι που τα X-Windows
|
||||
ποτέ δεν προορίζονταν να κάνουν.
|
||||
|
||||
### [2.3 Όλα για το δίκτυο]{#ss2.3}
|
||||
|
||||
Τώρα βέβαια θα πείτε: \"Και καλά, αν δεν είναι κατασκευασμένα τα X-Windows για να παρέχουν γραφικά σε ένα μονολιθικό λειτουργικό σύστημα, τότε για τι είναι
|
||||
κατασκευασμένα;\", και θα έχετε κάθε δίκιο να το ρωτήσετε αυτό.
|
||||
|
||||
Η μαγική φράση δεν είναι τόσο το \"μονολιθικό σύστημα\" όσο το \"σε ένα\". Τα X-Windows σχεδιάστηκαν για το δίκτυο. O σκοπός τους είναι να παρέχουν γραφικές
|
||||
υπηρεσίες ανάμεσα σε πολλούς υπολογιστές που επικοινωνούν μεταξύ τους. Αναφερόμαστε βέβαια στο περιβόητο \"network transparency\". (Δεν νομίζω ότι μπορώ να βρω
|
||||
καλή ελληνική μετάφραση του όρου.)
|
||||
|
||||
Οι προγραμματιστές των X-Windows σκέφτηκαν ως εξής όταν τα σχεδίαζαν (όλα αυτά μέσα στα \'80s). \"Ξέρουμε ότι στο μέλλον τα δίκτυα θα είναι παντού. Και ξέρουμε
|
||||
επίσης ότι πολλοί προγραμματιστές θα θέλουν να γράψουν γραφικά προγράμματα που θα τρέχουν πάνω από το δίκτυο. Θα ήταν επίσης κρίμα ο κάθε προγραμματιστής να
|
||||
γράφει κάθε φορά κώδικα που αφορά μεταφορά δεδομένων μέσα από το δίκτυο, κάτι το οποίο δεν έχει σχέση με το ίδιο το πρόγραμμα. (γνωστό και ως plumbing
|
||||
code/infrastructure ή και βαρετός κώδικας/εφεύρεση του τροχού για νιοστή φόρα στα ελληνικά :-). Θα κάνουμε λοιπόν το εξής: Θα γράψουμε μία φορά εμείς οι ίδιοι
|
||||
τον κώδικα του δικτύου και θα δώσουμε στους άλλους προγραμματιστές την δυνατότητα να γράψουν τα προγράμματα τους βασισμένα στα X-Windows χωρίς πότε να πρέπει να
|
||||
ασχοληθούν αυτοί με το δίκτυο άλλα να μπορούν να επικεντρώσουν την προσοχή τους στο ίδιο το πρόγραμμα τους\".
|
||||
|
||||
Τι ακριβώς εννοούσαν λοιπόν οι προγραμματιστές των X-Windows και τι έλεγε αυτή η επαναστατική τους (ακόμα και σήμερα κατά την ταπεινή γνώμη του αρθρογράφου)
|
||||
ιδέα;
|
||||
|
||||
Ας δούμε ένα παράδειγμα. Έχετε δύο υπολογιστές συνδεδεμένους στο δίκτυο. Θέλετε να πάρετε κάποιες μετρήσεις από τον Α (οι οποίες μπορεί να είναι
|
||||
θερμοκρασίες/hits σε ένα webserver/στατιστικά μιας βάσης δεδομένων και ότι άλλο μπορείτε να φανταστείτε) και να τις δείτε με ένα γραφικό πρόγραμμα στον Β στον
|
||||
οποίο και κάθεστε.
|
||||
|
||||
Αν οι δύο υπολογιστές τρέχουν ένα μονολιθικό λειτουργικό σύστημα πρέπει στην ουσία να γράψετε δύο προγράμματα. Το πρώτο (που δεν είναι απαραίτητο να είναι
|
||||
γραφικό) θα τρέχει στον Α, θα μαζεύει τα δεδομένα και θα τα στέλνει μέσω δικτύου στο δεύτερο πρόγραμμα που θα τρέχει στον Β και το οποίο θα τα δείχνει γραφικά
|
||||
στην οθόνη. Δείτε την [\[εικόνα\]](/35/img/client-server.png) .Στις περισσότερες περιπτώσεις ο κώδικας του δικτύου θα είναι χαμηλού επιπέδου (sockets) και θα είναι
|
||||
στενά συνδεδεμένος με τα δεδομένα που μεταφέρονται. Παρατηρήστε επίσης ότι ο κώδικας αυτός δεν έχει καμία απολύτως σχέση ούτε με την συλλογή δεδομένων η οποία
|
||||
μπορεί να είναι πολύ περίπλοκη από μόνη της ούτε με την επεξεργασία και γραφική τους αναπαράσταση που επίσης μπορεί να είναι πολύ περίπλοκη.
|
||||
|
||||
Κλασσικά παραδείγματα αυτής της αρχιτεκτονικής είναι τα άπειρα γραφικά database frontends που επιτρέπουν σε κάποιον να χειριστούν γραφικά μια απομακρυσμένη βάση
|
||||
δεδομένων, και τα διάφορα remote administration προγράμματα γενικότερα. Ακόμα και όλα τα κακόβουλα προγράμματα τύπου δούρειου ίππου (trojan horse) βασίζονται σε
|
||||
αυτήν την ιδέα.
|
||||
|
||||
Αν όμως έχετε X-Windows στους δύο υπολογιστές τα πράγματα είναι πολύ πιο απλά! Οι προγραμματιστές των X-Windows έχουν γράψει ήδη των κωδικά του δικτύου για εσάς
|
||||
πριν από εσάς. Σε αυτήν την περίπτωσή θα γράψετε ένα μόνο πρόγραμμα (όπως και ήταν η αρχική σας επιδίωξη) το οποίο θα τρέξετε κανονικά στον Α και μετά με κάποιο
|
||||
συγκεκριμένο τρόπο θα του πείτε \"Θέλω να δω την έξοδο του προγράμματος στην οθόνη του υπολογιστή Β και όχι στην οθόνη του υπολογιστή Α που το έτρεξα\". Και
|
||||
αυτό ήταν! Δείτε την [\[εικόνα\]](/35/img/X-win.png) . Ο Α δεν χρειάζεται να τρέχει X-Windows. Στην πραγματικότητα ο Α δεν χρειάζεται να έχει καν οθόνη. Μπορεί να
|
||||
είναι κάλλιστα ένας headless server που κάθεται στα φωτεινά υπόγεια μιας πολυεθνικής εταιρίας ή στο σκοτεινό πατάρι του γείτονα. Το μόνο που χρειάζεται ό Α
|
||||
είναι οι βιβλιοθήκες γραφικών των X-Windows (xlib/Xt) και ότι άλλο toolkit χρησιμοποιεί (gtk+/qt/fltk/tk/motif κ.τ.λ) το πρόγραμμα. Κατά τα άλλα δεν χρειάζεται
|
||||
να ασχοληθείτε εσείς ως προγραμματιστής, καθόλου με κώδικα για δίκτυο. Η μεταφορά των δεδομένων μέσα από τον δίκτυο γίνεται με τον τρόπο που έχουν
|
||||
\"ενσωματωμένο\" (built-in) τα ίδια τα X-windows.
|
||||
|
||||
Κάτι σημαντικό που πρέπει να παρατηρήσετε στην δεύτερη εικόνα και το οποίο έχει μπερδέψει αρκετούς ανθρώπους (μαζί και τον αρθρογράφο) είναι η ανάποδη
|
||||
αντιστοίχηση των όρων client και server. Έχουμε συνηθίσει να έχουμε το client κομμάτι στον υπολογιστή που καθόμαστε (π.χ. ftp client/web browser/database
|
||||
client) και το server κομμάτι στον απομακρυσμένο υπολογιστή (π.χ. ftp server/web server/database server). Στην περίπτωση των X-Windows όμως τα πράγματα είναι
|
||||
ανάποδα. Ο χρήστης κάθεται στον X-Server (= οθόνη,πληκτρολόγιο και ποντίκι) ενώ το απομακρυσμένο πρόγραμμα είναι ο X-client. Αυτό είναι εύκολο να το θυμάστε αν
|
||||
σκεφτείτε ότι ο client είναι πάντα αυτός που ξεκινάει την σύνδεση. Στην συγκεκριμένη περίπτωση ο χρήστης κάθεται στον X-Server που \"περιμένει\" συνδέσεις από
|
||||
X-Clients σε άλλα μηχανήματα που θέλουν να χρησιμοποιήσουν την οθόνη του.
|
||||
|
||||
Αυτά όσον αφορά το \"network\" κομμάτι. Τι ακριβώς όμως σημαίνει το \"transparency\" κομμάτι; (Στα ελληνικά transparent = διάφανος και transparency =
|
||||
διαφάνεια).
|
||||
|
||||
### [2.4 Απόκρυψη των λεπτομερειών (abstraction)]{#ss2.4}
|
||||
|
||||
Φτάνουμε λοιπόν στην δεύτερη σημαντική απόφαση των προγραμματιστών των X-Windows. Η απόφαση αυτή έχει να κάνει με το τι γίνεται στην περίπτωση που ένα γραφικό
|
||||
πρόγραμμα δείχνει την έξοδο του στον ίδιο τον υπολογιστή που τρέχει και άρα δεν χρειαζόμαστε μεταφορά δεδομένων μέσω δικτύου. Αυτή η περίπτωση μας ενδιαφέρει
|
||||
πολύ γιατί έτσι τρέχουν το 99% των χρηστών GNU/Linux το KDE/GNOME στον υπολογιστή τους. Αυτή είναι η πλειοψηφία των περιπτώσεων της εφαρμογής των X-Windows
|
||||
σήμερα δηλαδή.
|
||||
|
||||
Είπαν λοιπόν οι προγραμματιστές των X-Windows: \"Το ξέρουμε ότι θα μπορούσαμε (για λόγους ταχύτητας) να γράψουμε διαφορετικό κώδικα που θα δίνει την δυνατότητα
|
||||
στον προγραμματιστή να έχει απευθείας πρόσβαση στο υποσύστημα γραφικών όταν το πρόγραμμα του έχει την έξοδο στον ίδιο τον υπολογιστή που τρέχει. Κάτι τέτοιο
|
||||
όμως θα ήταν πιο πολύπλοκο και επίσης θα χάλαγε \"την ομοιομορφία\" του συστήματος μας (τα X-Windows δηλαδή). Προτιμούμε να δώσουμε στον προγραμματιστή ένα
|
||||
ενιαίο τρόπο κατασκευής γραφικών εφαρμογών άσχετα αν αυτές χρησιμοποιούν το δίκτυο τελικά ή όχι. Θα ακολουθήσουμε αυτήν μας την απόφαση παρόλο που ξέρουμε ότι
|
||||
δεν είναι η βέλτιστη δυνατή από άποψη ταχύτητας, είναι όμως η βέλτιστη δυνατή λύση από άποψη ευελιξίας\". Έτσι ακριβώς έγινε.
|
||||
|
||||
Τελικά δηλαδή τα X-Windows δεν ενδιαφέρονται αν υπάρχει στην μέση δίκτυο ή όχι. Ακόμα και όταν τα πάντα (Χ-server και X-Clients) τρέχουν σε έναν υπολογιστή
|
||||
τοπικά, όλα τα δεδομένα πάλι μέσα από το \"δίκτυο\" θα σταλούν. Το \"δίκτυο\" βέβαια θα είναι το ιδεατό(virtual) δίκτυο που έχει πάντα ένας υπολογιστής με τον
|
||||
εαυτό του. Αυτό πρακτικά σημαίνει ότι κάθε γραφικό πρόγραμμα που ξεκινάτε στον υπολογιστή σας συνδέεται μέσω δικτύου στην οθόνη του localhost/127.0.0.1 Δεν
|
||||
υπάρχει κάποια ειδική ρύθμιση για να αποφασίσετε αν ένα γραφικό πρόγραμμα τρέχει μέσω δικτύου ή τοπικά. Είναι ακριβώς το ίδιο. Εκεί αναφέρεται και ο όρος
|
||||
\"transparency\".
|
||||
|
||||
Και βέβαια από όλα αυτά καταλαβαίνετε ότι ένα γραφικό πρόγραμμα δεν έχει ποτέ απευθείας πρόσβαση στην κάρτα γραφικών του μηχανήματος που θα τρέξει ακόμα και αν
|
||||
τρέχει τοπικά. Τα πάντα θα περάσουν μέσα από το δίκτυο και μέσα από τον XServer (εδώ πάλι κλέβω αλλά αν το ξέρετε αυτό μπλα,μπλα). Θα μπορούσαν δηλαδή οι
|
||||
προγραμματιστές των X-Windows να δώσουν ένα διαφορετικό API για την περίπτωση που το πρόγραμμα τρέχει τοπικά, προτίμησαν όμως να μην το κάνουν αυτό για χάρη της
|
||||
ευελιξίας και ομοιομορφίας του συστήματος.
|
||||
|
||||
Να λοιπόν ένας ακόμα λόγος που τα X-Windows δεν μπορούν να ανταγωνιστούν τα γραφικά περιβάλλοντα των μονολιθικών λειτουργικών συστημάτων στο θέμα της ταχύτητας.
|
||||
Για άλλη μια φορά θυσίασαν την ταχύτητα για χάρη της ευελιξίας.
|
||||
|
||||
### [2.5 Δύο εφαρμογές με ενδιαφέρον]{#ss2.5}
|
||||
|
||||
Προφανώς υπάρχουν πολλές διαφορετικές περιπτώσεις όπου τα X-Windows μπορούν να χρησιμοποιηθούν για απομακρυσμένη εκτέλεση γραφικών εφαρμογών. Ανάλογα με τις
|
||||
ανάγκες του καθενός είναι δυνατόν τα X-Windows τις καλύψουν χωρίς να χρειάζεται η προμήθεια εξωτερικών εφαρμογών. Εμείς θα θέλαμε να αναφέρουμε δύο περιβάλλοντα
|
||||
που πιστεύουμε ότι αξίζουν την προσοχή σας.
|
||||
|
||||
Περιβάλλον 1. Ας φανταστούμε έναν (δύστυχο) system administrator που κάθεται στο γραφείο του που τρέχει GNU/Linux και θα ήθελε να ξέρει ανά πάσα στιγμή των
|
||||
σημαντικών πόρων/μηχανημάτων του δικτύου. Προφανώς μέσω SSH ο απομακρυσμένος έλεγχος (remote administration) των μηχανημάτων είναι δυνατόν να γίνει χωρίς καν να
|
||||
σηκωθεί από την καρέκλα του. Δεν θα ήταν όμως ιδανικό να μπορούσε να σηκώσει και γραφικά προγράμματα απομακρυσμένα;
|
||||
|
||||
Χωρίς λοιπόν την προσθήκη έξτρα προγραμμάτων ο system administrator αλλά με τις σωστές ρυθμίσεις θα μπορούσε να κάνει κάτι όπως την
|
||||
[\[εικόνα\]](/35/img/central-control.png)
|
||||
|
||||
Αυτός κάθεται λοιπόν σε ένα μηχάνημα χαμηλών/μέσων επιδόσεων και μπορεί να βλέπει στην (ας πούμε TFT 19\") οθόνη του ταυτόχρονα
|
||||
|
||||
- Το γραφικό hit analyser που τρέχει στο Webserver του με FreeBSD
|
||||
- Το γραφικό του network analyser που τρέχει στο router/firewall me OpenBSD
|
||||
- Το γραφικό του database frontend που τρέχει στον application server με Solaris
|
||||
- Το γραφικό του -βάλτε το δικό σας πρόγραμμα εδώ- που τρέχει στον server με GNU/Linux
|
||||
|
||||
Στο όλο σύστημα δηλαδή τρέχει ένας μόνο X server (στον κεντρικό υπολογιστή) και οι υπόλοιποι X-clients τρέχουν περιφερειακά σε διαφορετικά μηχανήματα. Προφανώς
|
||||
οι servers μπορούν κάλλιστα να είναι headless.
|
||||
|
||||
Γιατί είναι σημαντική αυτή η σύνθεση (configuration);
|
||||
|
||||
- Κεντρικός έλεγχος. O sys admin έχει όλα τα γραφικά προγράμματα σε μία οθόνη στο γραφείο του.
|
||||
- Κατανεμημένοι πόροι. Συνήθως μια βάση δεδομένων είναι μια βαριά εφαρμογή. Επίσης ένας πολυάσχολος web server τείνει να ζορίζει ένα σύστημα. Σε αυτήν την
|
||||
περίπτωση όμως ο system admin βλέπει σε μία οθόνη προγράμματα που θα ήταν αδύνατο να τρέξουν σε έναν υπολογιστή όλα μαζί. Επίσης ο ίδιος ο υπολογιστής του
|
||||
sys admin έχει πολύ χαμηλό φόρτο αφού το μόνο που κάνει είναι να \"δείχνει\" τα δεδομένα και όχι να τα επεξεργάζεται. Έτσι η εταιρία μπορεί να επενδύσει
|
||||
πολλά χρήματα στον database server και όχι στον υπολογιστή του sys admin. (Αυτή η λογική δεν ισχύει πάντα στην πραγματικότητα :-)
|
||||
- Ανεξαρτησία. Αν ο sys admin είναι από τους νευρωτικούς που θέλουν να συνεχίσουν να έχουν τον έλεγχο ακόμα και όταν φεύγουν από την δουλειά δεν υπάρχει
|
||||
κανένα πρόβλημα. Θα μπορούσε ας πούμε ο sys admin να πάει σπίτι του (θεωρητικά) και να σηκώσει το frontend της βάσης δεδομένων από το GNU/Linux μηχάνημα που
|
||||
έχει στο υπνοδωμάτιο του. Θα έχει ακριβώς το ίδιο περιβάλλον που είχε και στην δουλειά.
|
||||
|
||||
Περιβάλλον 2. Η δεύτερη περίπτωση είναι η λογικά αντίθετη (σχεδόν). Έχουμε στο κέντρο τον X-Client και διάφοροι X-Servers σηκώνουν το πρόγραμμα γραφικά. Τυπικό
|
||||
παράδειγμα τέτοιας λύσεις αποτελούν τα πανεπιστήμια. Υπάρχει εγκατεστημένη σε ένα μηχάνημα μια σημαντική/εμπορική εφαρμογή και όλοι οι φοιτητές σηκώνουν το
|
||||
γραφικό περιβάλλον από τον υπολογιστή που κάθονται. Η εφαρμογή δεν μπορεί να υπάρξει εγκατεστημένη σε άλλους υπολογιστές για διάφορους λόγους
|
||||
|
||||
- Είναι εμπορική και το πανεπιστήμιο έχει μόνο μια άδεια
|
||||
- Χρησιμοποιεί συγκεκριμένο υλικό συνδεδεμένο μόνο σε αυτόν τον αυτόν τον υπολογιστή
|
||||
- Έχει πολύ μεγάλες απαιτήσεις σε πόρους (μπορεί να τρέξει μόνο σε αυτόν τον υπολογιστή)
|
||||
|
||||
Δείτε την [\[εικόνα\]](/35/img/distributed.png). Τα χαρακτηριστικά αυτής της σύνθεσης είναι:
|
||||
|
||||
- (Το κύριο) Πολλοί χρήστες χρησιμοποιούν μια γραφική εφαρμογή η οποία στην πραγματικότητα είναι εγκατεστημένη σε ένα μηχάνημα.
|
||||
- Εύκολη αναβάθμιση της εφαρμογής, αφού βρίσκεται σε ένα κεντρικό σημείο.
|
||||
- Οικονομική λύση. Ο μόνος απαιτητικός υπολογιστής είναι ο κεντρικός. Οι χρήστες μπορούν να έχουν απλούς thin clients. Εφόσον όμως δεν έχουν μπροστά τους μια
|
||||
απλή εφαρμογή WEB αλλά μια κανονική εφαρμογή συστήματος που έχει διαθέσιμους όλους τους πόρους ενός μηχανήματος τελικά τα περιφερειακά μηχανήματα είναι
|
||||
thick clients.
|
||||
|
||||
Και τα δύο περιβάλλοντα που αναφέραμε δεν λειτουργούν ακριβώς έτσι στην πραγματική ζωή και για αυτό συμβάλλουν κυρίως δύο λόγοι. Ό ένας είναι ότι απαιτείται ένα
|
||||
γρήγορο δίκτυο (αν ο sys admin έχει απλό dial-up σπίτι του δεν μπορεί να κάνει και πολλά). Ο δεύτερος λόγος είναι η ασφάλεια την οποία θα αναφέρουμε και στο
|
||||
επόμενο τμήμα του άρθρου.
|
||||
|
||||
|
||||
### [3. X-Windows το πως (η αλλιώς η πράξη)]{#s3}
|
||||
|
||||
Και ερχόμαστε στο πρακτικό κομμάτι του άρθρου. Δεν πρόκειται όμως να αναφερθούμε εκτενώς στις λεπτομέρειες καθώς αυτές είναι ήδη μαζεμένες στο Remote-X-apps
|
||||
HOWTO το οποίο οφείλετε να διαβάσετε αν θέλετε πραγματικά να ασχοληθείτε με το \"άθλημα\". Θα περιοριστούμε λοιπόν σε μερικά μόνο σημαντικά σημεία.
|
||||
|
||||
Καταρχήν πρέπει να ξέρετε τρία πράγματα πριν ξεκινήσετε οποιοδήποτε πείραμα. Πρώτον προσέξτε το firewall της διανομή σας. Μερικές διανομές έχουν ανάμεσα στις
|
||||
προκαθορισμένες (default) ρυθμίσεις τους και ένα απλό firewall. Επειδή τα X-Connections δεν τρέχουν σε χαμηλές πόρτες (ports) (1-1024) αλλά συνήθως
|
||||
χρησιμοποιούν πόρτες με αριθμό 6000 και κάτι ψιλά είναι πολύ πιθανό να μην μπορεί ο υπολογιστής που έχει τον X-Server να δεχτεί συνδέσεις.
|
||||
|
||||
Δεύτερον πρέπει να δώσετε μεγάλη σημασία στο θέμα της ασφάλειας. Τα Χ-Windows πάσχουν από διάφορα προβλήματα ασφαλείας (βλέπε και telnet/ftp/rlogin) αν δεν
|
||||
ρυθμιστούν σωστά. Αναφερόμαστε τόσο στο ποιος μπορεί να συνδεθεί στον X-server (authentication) όσο και στην ίδια την μεταφορά των δεδομένων μέσα από το δίκτυο.
|
||||
Μην ξεχνάτε ότι ένας X-server είναι οθόνη και ποντίκι και πληκτρολόγιο. Έτσι θα μπορούσε ένας κακόβουλος χρήστης να συνδεθεί στον X-server σας και να βάλει τα
|
||||
δικά του παράθυρα στην οθόνη σας. (κάτι που μπορεί να είναι αστείο). Θα μπορούσε όμως να φτιάξει και ένα πρόγραμμα που συνδέεται στον X-Server σας και διαβάζει
|
||||
τι γράφετε στο πληκτρολόγιο (κάτι που δεν είναι καθόλου αστείο).
|
||||
|
||||
Έτσι θα πρέπει στην καλύτερη περίπτωση να κάνετε τα πειράματα σας σε ένα μικρό δίκτυο που δεν διαθέτει εξωτερική σύνδεση στο Internet, ενώ στην χειρότερη σε ένα
|
||||
καλά προστατευμένο δίκτυο πίσω από ένα \"σοβαρό\" (π.χ. εταιρικό) firewall. Μερικοί μπορεί να τα θεωρήσουν γελοία όλα αυτά, αλλά είναι καλό να είστε λίγο
|
||||
περισσότερο παρανοϊκοί από όσο πρέπει στο θέμα της ασφάλειας. Δείτε και τα άλλα τεύχη του Magaz με θέμα την ασφάλεια δικτύων.
|
||||
|
||||
Και τρίτον θα πρέπει ο ίδιος ο X-server να είναι ρυθμισμένος ώστε να δέχεται εξωτερικές συνδέσεις. Πάλι για λόγους ασφάλειας μερικές διανομές μπορεί να έχουν
|
||||
απενεργοποιήσει αυτήν την λειτουργία. Εδώ πρέπει να ψάξετε την τεκμηρίωση της διανομής σας. Για XFREE86 αυτό μπορεί να είναι κάτι απλό όπως η παράμετρος
|
||||
\"-nolisten tcp\". Τις περισσότερες φορές όμως αυτό είναι \"θαμμένο\" πίσω από διάφορα startup scripts και ο χρήστης έχει επιλογές \"υψηλότερου επιπέδου\". Θα
|
||||
μπορούσε ας πούμε η διανομή σας να έχει σε κάποιο αρχείο ρυθμίσεων την γραμμή \"ALLOW\_REMOTE\_X\_CONNECTIONS=no\" την οποία εσείς πρέπει να αλλάξετε βέβαια σε
|
||||
\"yes\". Δείτε πάλι την τεκμηρίωση της διανομή σας. Δεν έχει νόημα να μπούμε σε περίπλοκες λεπτομέρειες για το θέμα.
|
||||
|
||||
Από την μεριά του X-client τα πράγματα είναι σχετικά απλά. Η μαγική λέξη είναι DISPLAY. Κάθεστε στον υπολογιστή, βάζετε στην μεταβλητή περιβάλλοντος
|
||||
(environment variable) DISPLAY το όνομα (hostname) του υπολογιστή με τον X-Server προσθέτοντας και το display στο τέλος (στο 99% των περιπτώσεων θα είναι :0.0)
|
||||
και τέλος τρέχετε το γραφικό πρόγραμμα που θέλετε. Αν όλα πάνε καλά θα πρέπει το πρόγραμμα να εμφανίσει το περιβάλλον του στον X-Server χρησιμοποιώντας όμως
|
||||
πάντα τους πόρους (resources) του Χ-Client. Για tcsh/csh ας πούμε αυτό γίνεται
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
>setenv DISPLAY xserver.example.gr:0.0
|
||||
>gftp
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αντίστοιχα και για άλλα shells (π.χ bash). Για περισσότερες λεπτομέρειες δείτε το HOWTO.
|
||||
|
||||
Ας δούμε και τις ρυθμίσεις από την πλευρά του X-Server.
|
||||
|
||||
### [3.1 Ο εύκολος τρόπος]{#ss3.1}
|
||||
|
||||
Στην πιο απλή περίπτωση ο X-Server κρατάει μία λίστα με υπολογιστές (hostnames) που μπορούν να ανοίξουν μια σύνδεση με αυτόν. Η λίστα αυτή παραμετροποιείται με
|
||||
την εντολή xhost. Η παράμετρος είναι ένα όνομα (hostname) που θέλετε να βάλετε ή να βγάλετε από την λίστα. Αυτό καθορίζεται με ένα + η - πριν από το όνομα
|
||||
(χωρίς κάποιο κενό). Έτσι στον X-Server μπορείτε να τρέξετε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
xhost +xclient.example.gr
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Και μόλις τελειώσετε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
xhost -xclient.example.gr.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Υπάρχει επίσης ή xhost + που επιτρέπει σε οποιονδήποτε να συνδεθεί (απαγορεύεται δια ροπάλου) και η xhost - που δεν αφήνει κανέναν να συνδεθεί εκτός από
|
||||
X-Clients που τρέχουν στον ίδιο τον X-Server (localhost δηλαδή μονό).
|
||||
|
||||
Όπως καταλάβατε αυτός ο τρόπος πιστοποίησης (authentication) ασχολείται μόνο με hostnames και δεν είναι καθόλου ασφαλής. Αν χρησιμοποιήσετε αυτόν τον τρόπο
|
||||
σημαίνει ότι ξέρετε πολύ καλά τι κάνετε και ότι εμπιστεύεστε την ασφάλεια του δικτύου σας. Εμείς τον προτείνουμε μόνο για δοκιμές σε ένα μικρό προστατευμένο
|
||||
τοπικό δίκτυο χωρίς σύνδεση στο δίκτυο.
|
||||
|
||||
Προσέξτε επίσης ότι ακόμα και το xhost - δεν είναι 100% ασφαλές. Είναι δυνατόν κάποιος κακόβουλος χρήστης αντί να τρέξει τον keylogger του απομακρυσμένα, να
|
||||
πάρει πρόσβαση στον υπολογιστή που τρέχει ο X-Server με τους συνήθεις τρόπους και μετά να \"ανεβάσει\" τον keylogger του και να τον τρέξει τοπικά. Τότε o
|
||||
keylogger θα συνδέεται από τον υπολογιστή \"localhost\" που έχει πάντα πρόσβαση στον X-Server άσχετα με τα αποτελέσματα της εντολής xhost.
|
||||
|
||||
### [3.2 Ο δύσκολος τρόπος]{#ss3.2}
|
||||
|
||||
Ο δεύτερος τρόπος είναι με χρήση της εντολής xauth (σύστημα MIT-MAGIC-COOKIE-1) Σε αυτήν την περίπτωση ο XServer ξέρει μία \"μαγική λέξη\"(magic-cookie). Μόνο
|
||||
όσοι X-Clients ξέρουν επίσης την ίδια ακριβώς μαγική λέξη μπορούν να ανοίξουν σύνδεση. Το \"μαγικό\" στην όλη υπόθεση αναφέρεται στο γεγονός ότι δεν έχει
|
||||
σημασία τόσο το περιεχόμενο αυτής της λέξης όσο το ότι πρέπει να είναι η ίδια και από τις δύο μεριές (X-Server/X-Client) ώστε να ανοιχτεί επιτυχώς η σύνδεση.
|
||||
Στα \"νεοελληνικά\" δηλαδή συνδέονται στον X-server μόνο όσοι X-clients έχουν το κοκκαλάκι της νυχτερίδας.
|
||||
|
||||
Εδώ θα μπορούσαμε να αναφέρουμε άπειρες λεπτομέρειες για το πως μπορείτε να φτιάξετε τα cookies αυτά, πώς θα τα μεταφέρετε από τον X-server στον Χ-client, και
|
||||
άλλα τεχνικά ζητήματα. Κάτι τέτοιο δεν έχει νόημα όμως γιατί όλα αυτά είναι ήδη γραμμένα στο Remote-X-Apps HOWTO και δεν πρόκειται να ασχοληθούμε ξανά εδώ με τα
|
||||
ίδια θέματα.
|
||||
|
||||
Θα σταθούμε μόνο σε δύο σημαντικά σημεία. Το ένα είναι ότι με το xauth μπορείτε να καθορίσετε την πρόσβαση σε επίπεδο χρήστη πια (και όχι σε επίπεδο υπολογιστή
|
||||
όπως το xhost) κάτι το οποίο είναι απαραίτητο σε ένα μέσο/μεγάλο τοπικό δίκτυο έτσι και αλλιώς. Το δεύτερο σημείο είναι ότι για να χρησιμοποιήσετε αυτόν τον
|
||||
τρόπο πιστοποίησης πρέπει να τρέξετε τον XServer με την παράμετρο -auth και το όνομα του αρχείου που περιέχει το cookie ( /.Xauthority).
|
||||
|
||||
### [3.3 Ο ασφαλής τρόπος]{#ss3.3}
|
||||
|
||||
Σχεδόν πάντα βέβαια ο χρήστης κάθεται στον X-server (= οθόνη, πληκτρολόγιο και ποντίκι). Επομένως μέσα από telnet στον X-client ξεκινάει την γραφική εφαρμογή
|
||||
που τον ενδιαφέρει και εφόσον έχει θέσει την μεταβλητή περιβάλλοντος DISPLAY το πρόγραμμα θα εμφανιστεί στην οθόνη που έχει μπροστά του. Αυτό όμως σημαίνει
|
||||
βέβαια ότι τα δεδομένα περνάνε μέσα από το δίκτυο χωρίς καμία κάλυψη (αναφερόμαστε γενικότερα στην απομακρυσμένη σύνδεση). Υπάρχει ο όμως και η λύση του ssh
|
||||
(secure shell). Σε αυτήν την περίπτωση έχετε αυτομάτως κρυπτογραφημένα δεδομένα. Πιο ενδιαφέρον είναι το γεγονός ότι μέσω της παραμέτρου -Χ λέτε στο ssh ότι
|
||||
θέλετε X forwarding. Αυτό αυτοματοποιεί την όλη διαδικασία Δηλαδή
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
>ssh -X xclient.example.gr
|
||||
>gftp.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Εννοείται βέβαια ότι πρέπει να έχετε στήσει τον αντίστοιχο δαίμονα (sshd) στο μηχάνημα. Για άλλη μία φορά δείτε το αντίστοιχο HOWTO για τις λεπτομέρειες.
|
||||
|
||||
|
||||
### [4. Άλλα θέματα και επίλογος]{#s4}
|
||||
|
||||
Θα μπορούσαμε να συνεχίσουμε να απαριθμούμε και άλλες δυνατότητες των X-Windows τότε όμως το άρθρο αυτό θα έχανε τον εισαγωγικό του χαρακτήρα. Οφείλετε ανάλογα
|
||||
με τις ανάγκες σας να δείτε τι σας ενδιαφέρει και πως μπορείτε να το χρησιμοποιήσετε στο δικό σας περιβάλλον. Ορίστε μερικές άλλες ιδέες.
|
||||
|
||||
Displays/screens.
|
||||
|
||||
Μπορείτε να έχετε περισσότερα από ένα Χ displays σε έναν υπολογιστή και να αλλάζετε μεταξύ τους ακριβώς όπως αλλάζετε τις κονσόλες σας με Ctrl-alt-Fx. Έτσι
|
||||
μπορείτε να έχετε και δύο χρήστες ταυτόχρονα στο ίδιο μηχάνημα με εντελώς διαφορετικό περιβάλλον την ίδια στιγμή. Επίσης είναι δυνατόν να έχετε δύο φυσικές
|
||||
οθόνες σε έναν υπολογιστή αν η κάρτα γραφικών σας το επιτρέπει. Τα X-Windows το υποστηρίζουν και αυτό.
|
||||
|
||||
Xinerama.
|
||||
|
||||
Το xinerama είναι μια επέκταση (Extension) που σας επιτρέπει να έχετε ένα \"ενοποιημένο\" περιβάλλον από πολλές οθόνες. Φανταστείτε παράθυρα που τα κάνετε drag
|
||||
and drop από την μία οθόνη στην άλλη και μακρόστενες ταπετσαρίες (backgrounds) στο υπολογιστικό σας περιβάλλον.
|
||||
|
||||
x2x
|
||||
|
||||
Το x2x είναι ένα μικρό προγραμματάκι που σας επιτρέπει να ενώσετε δύο X-displays. Προσέξτε όμως ότι δεν είναι απαραίτητο να είναι στον ίδιο υπολογιστή. Δεν
|
||||
είμαστε σίγουροι για την σημερινή κατάσταση του προγράμματος μέχρι πρόσφατα πάντως ήταν μέσα στο Debian archive.
|
||||
|
||||
xnest.
|
||||
|
||||
Ένα διασκεδαστικό πρόγραμμα (κατά την γνώμη του αρθρογράφου). Σας επιτρέπει να έχετε ένα Χ-display μέσα σε ένα παράθυρο μέσα σε άλλο X-display. Φανταστείτε τον
|
||||
άνθρωπο που κρατάει έναν καθρέφτη και επειδή είναι ο ίδιος μπροστά από έναν δεύτερο καθρέφτη η αντανάκλαση είναι ό ίδιος και μέσα στον καθρέφτη που κρατάει
|
||||
φαίνεται ο ίδιος και μέσα στον καθρέφτη που κρατάει κ.τ.λ.
|
||||
|
||||
XDMCP
|
||||
|
||||
Το XDMCP είναι ένα πρωτόκολλό που σας επιτρέπει να πάτε ένα επίπεδο πιο πάνω. Αντί δηλαδή να έχετε X-clients μέσα από το δίκτυο έχετε ολόκληρα X-sessions. Αν
|
||||
ασχοληθείτε προσέξτε πάλι το θέμα ασφάλειας.
|
||||
|
||||
vnc.
|
||||
|
||||
Το vnc (virtual network computing) δεν έχει άμεση σχέση με τα X-windows, δεν θα μπορούσαμε όμως να μην το αναφέρουμε. Σας επιτρέπει να έχετε remote desktops
|
||||
ανάμεσα σε διαφορετικούς υπολογιστές ακόμα και αν αυτοί τρέχουν μονολιθικά λειτουργικά συστήματα. Ουσιαστικά δηλαδή μπορείτε να κάνετε αυτό που κάνουν τα
|
||||
X-windows εγγενώς ακόμα και αν τα λειτουργικά σας δεν τρέχουν X-windows. Προφανώς πρέπει το ίδιο το λειτουργικό σύστημα να υποστηρίζεται από το vnc. ΤΟ vnc
|
||||
βασίζεται στην λογική client-server. Εδώ όμως η ορολογία είναι η \"φυσική\". Ο υπολογιστής με τον vnc server σερβίρει το desktop του στον vnc client στον οποίο
|
||||
κάθεται και ο χρήστης. Υπάρχει και java based client που μπορεί να τρέχει και σε Web browser. Ένα μειονέκτημα του vnc είναι ότι πραγματικά σας δίνει τον έλεγχο
|
||||
του desktop δηλαδή δεν μπορεί και κάποιος άλλος να χρησιμοποιήσει τον server ταυτόχρονα με εσάς. Και αν κάποιος κάθεται εκεί δίπλα θα βλέπει στην οθόνη του
|
||||
server ακριβώς αυτά που κάνετε από τον client (ναι ακόμα και την κίνηση του ίδιου του mouse pointer). Δείτε επίσης και το tightvnc.
|
||||
|
||||
- Πηγές
|
||||
- Remote-X-Apps howto
|
||||
- Xwindow-USer-howto
|
||||
- XDMCP HOWTO
|
||||
|
||||
240
content/articles/35/02_kernel-shrink.md
Κανονικό αρχείο
240
content/articles/35/02_kernel-shrink.md
Κανονικό αρχείο
|
|
@ -0,0 +1,240 @@
|
|||
+++
|
||||
title = 'Αγάπη μου, Συρρίκνωσα τον Πυρήνα!'
|
||||
date = ''
|
||||
description = ''
|
||||
author = 'Παντελής Κουκούσουλας'
|
||||
issue = ['Magaz 35']
|
||||
issue_weight = 2
|
||||
+++
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Βελτιστοποιώντας ένα πυρήνα της σειράς 2.6 για χρήση σε παλαιότερα / ενσωματωμένα συστήματα.*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Εισαγωγή**
|
||||
-----------------------------------------------
|
||||
|
||||
**2. Ξεκινώντας - Διαμόρφωση του πυρήνα**
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
**3. Παίζοντας με τις επιλογές του μεταγλωττιστή**
|
||||
----------------------------------------------------------------------------------
|
||||
|
||||
**4. Το -tiny patchset**
|
||||
--------------------------------------------------------
|
||||
|
||||
**5. Άλλες επεμβάσεις**
|
||||
-------------------------------------------------------
|
||||
|
||||
**6. Συμπεράσματα**
|
||||
---------------------------------------------------
|
||||
|
||||
**7. Αναφορές**
|
||||
-----------------------------------------------
|
||||
|
||||
|
||||
### [1. Εισαγωγή]{#s1}
|
||||
|
||||
Είναι γεγονός! Η νέα σειρά πυρήνων 2.6 είναι εδώ και υπόσχεται να κάνει τη συμβίωση με τον υπολογιστή μας αρκετά πιο ευχάριστη! Preemptible kernel, βελτιωμένο
|
||||
σύστημα διαχείρισης μνήμης και άλλες αλλαγές όλα συμβάλλουν σε ακόμα καλύτερη απόδοση των μηχανημάτων μας!
|
||||
|
||||
Στο άρθρο αυτό, θα προσπαθήσουμε να εκμεταλλευτούμε τα οφέλη από τις παραπάνω καινοτομίες και σε παλαιότερα μηχανήματα που πιθανώς χρησιμοποιούμε, μέσω μιας
|
||||
σειράς παρεμβάσεων στον πυρήνα, οι οποίες στοχεύουν στη μείωση των απαιτήσεών του σε μνήμη, καθώς και του χρόνου που χρειάζεται για την εκκίνηση (booting time).
|
||||
Για να βεβαιωθούμε ότι οι τεχνικές μας είναι εφαρμόσιμες σε όσο το δυνατόν περισσότερα συστήματα, θα τις δοκιμάσουμε σε ένα μηχάνημα που πλησιάζει τις ελάχιστες
|
||||
απαιτήσεις του Linux, δηλ. σε ένα 386sx/25 με 4mb RAM και 40 Mb σκληρό. Έτσι, όσοι έχουν ανώτερα από αυτό συστήματα θα μπορέσουν να υιοθετήσουν μόνο τις
|
||||
αναγκαίες γι αυτούς παρεμβάσεις από αυτές που θα παρουσιαστούν στη συνέχεια.
|
||||
|
||||
Για την αξιολόγηση κάθε τεχνικής, μετράμε σε κάθε ενδιάμεσο στάδιο το μέγεθος του ασυμπίεστου πυρήνα (vmlinux), το μέγεθος του συμπιεσμένου πυρήνα (system size
|
||||
- vmlinux.bin), το μέγεθος του συμπιεσμένου αρχείου (bzImage), την ελεύθερη μνήμη που αφήνει για τις εφαρμογές ο πυρήνας αμέσως μετά την εκκίνηση (από τα 4mb)
|
||||
και το χρόνο από το πάτημα του κουμπιού \"power\" στον 386 μέχρι την εμφάνιση του prompt (χρόνος εκκίνησης). Ειδικά τα δύο τελευταία μετρούν σε μεγάλο βαθμό την
|
||||
εφαρμοσιμότητα του πυρήνα σε κάποιο μηχάνημα. Για την εκκίνηση του μηχανήματος χρησιμοποιείται το init του busybox, το οποίο τρέχει ένα ιδιαίτερα στοιχειώδες
|
||||
bootscript (/etc/rcS) που δεν αναμένεται να προσθέσει περισσότερο από μισό με ένα δευτερόλεπτο στο χρόνο εκκίνησης. Έτσι, ο τελευταίος καθορίζεται σε μεγάλο
|
||||
βαθμό από τον πυρήνα.
|
||||
|
||||
Εννοείται ότι καθώς οι επεμβάσεις στον πυρήνα και το BIOS είναι εξίσου επικίνδυνες για την υγεία του υλικού σας με τον υπερχρονισμό (overclocking), ο γράφων δεν
|
||||
δίνει καμία εγγύηση ότι οι παρακάτω ενέργειες θα δουλέψουν για εσάς χωρίς προβλήματα κλπ. καθώς και παραιτείται από κάθε ευθύνη για τις επιπτώσεις του υπόλοιπου
|
||||
άρθρου στη λειτουργία του Η/Υ σας, τις σχέσεις με το έτερον ήμισυ, την ψυχική υγεία του σκύλου σας ή οτιδήποτε άλλο.
|
||||
|
||||
Ας μη σπαταλάμε όμως άλλο χρόνο στα εισαγωγικά και ας περάσουμε στην καθαυτό συρρίκνωση του πυρήνα μας!
|
||||
|
||||
|
||||
### [2. Ξεκινώντας - Διαμόρφωση του πυρήνα]{#s2}
|
||||
|
||||
Για να μπορούμε να μετρήσουμε το όφελος των βελτιστοποιήσεων μας, χρειαζόμαστε ένα σύστημα αναφοράς. Ξεκινάμε λοιπόν κατεβάζοντας ένα πυρήνα 2.6.5 από το
|
||||
gr.kernel.org. Καθώς θέλουμε το ελάχιστο δυνατό μέγεθος για το bzImage του, (ώστε να φορτώνει γρήγορα στη μνήμη κατά την εκκίνηση), θα μεταγλωττίσουμε μόνο την
|
||||
απαραίτητη λειτουργικότητα για την εκκίνηση και την προσάρτηση του θεμελιώδους (root) partition στον πυρήνα. Όλη η υπόλοιπη λειτουργικότητα (δηλ. οι δυνατότητες
|
||||
που δεν θα χρησιμοποιούνται συνέχεια και ταυτόχρονα), θα μεταγλωττιστεί ως modules. Έτσι πετυχαίνουμε γρήγορη εκκίνηση χωρίς να θυσιάζουμε λειτουργικότητα (δεν
|
||||
φορτώνουμε modules κατά την εκκίνηση παρά μόνο τη στιγμή που θα χρειαστούν).
|
||||
|
||||
Στην περίπτωσή μου, έκανα τις εξής επιλογές: (όποιο μενού δεν αναφέρω, σημαίνει ότι τα αφήνουμε όλα ως έχουν):
|
||||
|
||||
- Στο μενού General Setup: Επιλέγουμε μόνο την υποστήριξη για swap και System V IPC. Επίσης μπαίνουμε στο μενού Remove kernel features και αφήνουμε επιλεγμένα
|
||||
μόνο τον deadline I/O scheduler και το futex support. Δεν επιλέγουμε το optimize for size γιατί θέλουμε να αρχίσουμε με ένα vanilla (και όσο το δυνατόν πιο
|
||||
σταθερό) kernel.
|
||||
- Στο μενού Loadable module Support: Επιλέγουμε μόνο τα \"Enable loadable module support\" και \"Module unloading\".
|
||||
- Στο Μενού Processor type and features: Επιλέγουμε μόνο τον τύπο του επεξεργαστή μας (σε εμένα pc-compatible και 386), το \"preemptible kernel\" και το math
|
||||
emulation (εκτός αν ο υπολογιστής μας έχει FPU - από 486dx και πάνω δηλαδή)
|
||||
- Στο Μενού Power management options: Αποεπιλέγουμε τα πάντα (προσοχή γιατί το ACPI είναι επιλεγμένο).
|
||||
- Στο Μενού Bus Options: Αφήνουμε μόνο το ISA Support (καθώς οι 386 έχουν μόνο ISA slots).
|
||||
- Στο Executable File Formats: Αφήνουμε μόνο το elf.
|
||||
- Στο device drivers: Επιλέγουμε μόνο τα ATA/ATAPI/κλπ support, Old hard disk driver, Networking support, Network device support, TCP Networking, i8042 PC
|
||||
Keyboard controller, keyboards, AT Keyboard support, Virtual Terminal, console on virtual terminal και Unix98 PTY Support.
|
||||
- Στο μενού file systems, επιλέγουμε μόνο το minix (ή το ext2) filesystem και το /proc filesystem.
|
||||
- Αποεπιλέγουμε όλες τις επιλογές των υπόλοιπων μενού. (Ότι χρειαζόμαστε, το διαλέγουμε ως module)
|
||||
|
||||
Για να μην πληκτρολογείτε άσκοπα, μπορείτε να βρείτε το .config που χρησιμοποίησα [εδώ](http://www.intelligence.tuc.gr/~pantelis/linuxlite/initial.config). Για
|
||||
να το χρησιμοποιήσετε, απλώς το τοποθετείτε στον κύριο κατάλογο του κώδικα του Linux και το ονομάζετε .config. Μετά κάνετε: make oldconfig
|
||||
|
||||
Ονομάζουμε τον πυρήνα που προέκυψε από αυτή τη διαδικασία (με make bzImage) \"kernel-initial\". Ο πυρήνας αυτός έχει τα ακόλουθα χαρακτηριστικά:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Μέγεθος vmlinux: 1.5Mb
|
||||
Μέγεθος system: 604kb
|
||||
Μέγεθος bzImage: 612kb
|
||||
Ελεύθερη μνήμη: 1484kb
|
||||
Χρόνος εκκίνησης: 32s
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Για τη μεταγλώττιση του παραπάνω πυρήνα χρησιμοποιήσαμε τη gcc-2.95.3 που συνιστά η ομάδα ανάπτυξης του πυρήνα, για μέγιστη δυνατή σταθερότητα. Αν και όπως
|
||||
παρατηρούμε ο πυρήνας που προέκυψε (στο εξής θα αναφερόμαστε σε αυτόν ως kernel-initial) είναι ήδη αρκετά μικρός, θα προσπαθήσουμε για ακόμα καλύτερα
|
||||
αποτελέσματα, δεδομένου ότι στον 386 κάθε βελτίωση είναι αισθητή.
|
||||
|
||||
|
||||
### [3. Παίζοντας με τις επιλογές του μεταγλωττιστή]{#s3}
|
||||
|
||||
Ως γνωστόν, το μεγαλύτερο μέρος του Linux είναι γραμμένο στη γλώσσα προγραμματισμού C, η οποία όπως όλες οι γλώσσες υψηλού επιπέδου, βασίζεται σε ένα ειδικό
|
||||
πρόγραμμα (το μεταγλωττιστή) για την μετατροπή της σε γλώσσα μηχανής. Είναι λοιπόν λογικό, ότι ενεργοποιώντας συγκεκριμένες επιλογές του τελευταίου, θα
|
||||
μπορέσουμε να επηρεάσουμε λίγο ως πολύ τα χαρακτηριστικά του τελικού πυρήνα.
|
||||
|
||||
Η μέθοδος των επιλογών του μεταγλωττιστή έχει το πλεονέκτημα ότι προσφέρει μείωση του μεγέθους του τελικού πυρήνα, χωρίς επέμβαση στον πηγαίο κώδικα, άρα είναι
|
||||
πιο γενικά εφαρμόσιμη. Από την άλλη, λάθη στην υλοποίηση του μεταγλωττιστή τείνουν να παρουσιάζονται ευκολότερα αν έχουμε ενεργοποιήσει ασυνήθιστες επιλογές και
|
||||
μπορούν να προξενήσουν ένα μη λειτουργικό πυρήνα!
|
||||
|
||||
Καταρχήν, για να έχουμε τα καλύτερα δυνατά αποτελέσματα, θα χρησιμοποιήσουμε την πιο πρόσφατη έκδοση του μεταγλωττιστή gcc (3.4.0). Στην έκδοση αυτή, το
|
||||
υποσύστημα που αναλαμβάνει τη βελτιστοποίηση έχει βελτιωθεί αρκετά, οδηγώντας σε μικρότερο και γρηγορότερο κώδικα. Οι επιλογές (options) που θα χρησιμοποιήσουμε
|
||||
φαίνονται παρακάτω:
|
||||
|
||||
- -Os. Η πιο γνωστή επιλογή για τέτοιες δουλειές, λέει στο μεταγλωττιστή να μικρύνει όσο μπορεί τον τελικό κώδικα ακόμη και σε βάρος της απόδοσης. Βέβαια,
|
||||
λόγω του τρόπου με τον οποίο λειτουργούν τα σύγχρονα μηχανήματα, διάφορες φήμες λένε ότι στην πραγματικότητα οι πυρήνες γίνονται εξίσου ή ίσως και λίγο πιο
|
||||
γρήγοροι με αυτή την επιλογή. Για να ενεργοποιήσουμε την -Os, επιλέγουμε \"optimize for size\" στο μενού \"Remove kernel features\"
|
||||
- -funit-at-a-time. Επιλέγεται αυτόματα αν χρησιμοποιούμε τη gcc-3.4.0 ή νεώτερη. Λέει στο μεταγλωττιστή να φορτώνει ολόκληρο το κάθε αρχείο στη μνήμη, πριν
|
||||
αρχίσει την παραγωγή τελικού κώδικα (μηχανής). Η περισσότερη πληροφορία που έχει έτσι ο μεταγλωττιστής στη διάθεσή του, οδηγεί στην καλύτερη απόρριψη
|
||||
άχρηστου κώδικα μεταξύ άλλων. Το μόνο κόστος αυτής της επιλογής είναι λίγη παραπάνω μνήμη στο μηχάνημα που θα κάνει τη μεταγλώττιση.
|
||||
- -mregparm=3. Η λιγότερο ασφαλής από τις επιλογές, αλλά και αυτή με το μεγαλύτερο όφελος. Αν ενεργοποιηθεί, αλλάζει τον τρόπο κλήσης των συναρτήσεων στον
|
||||
κώδικα του πυρήνα. Έτσι, για τα πρώτα τρία ορίσματα κάθε συνάρτησης δεν θα χρησιμοποιείται πλέον η στοίβα (μικρή περιοχή της RAM) αλλά οι καταχωρητές, δηλ η
|
||||
γρηγορότερη (και μικρότερη) μορφή μνήμης σε ένα υπολογιστή. Έτσι ο πυρήνας γίνεται όχι μόνο μικρότερος αλλά και γρηγορότερος. Το μειονέκτημα είναι ότι λόγω
|
||||
αυτής της αλλαγής, τυχόν binary modules που χρησιμοποιούμε (π.χ. drivers της nVidia ή ασύρματων καρτών γραφικών) παύουν αυτομάτως να λειτουργούν! Βέβαια,
|
||||
επειδή πρακτικά όλοι οι οδηγοί για ένα παλιό μηχάνημα είναι λογισμικό ανοιχτού κώδικα, η επιλογή αυτή θα μπορέσει να ωφελήσει τους περισσότερους, χωρίς
|
||||
τέτοιου είδους προβλήματα.
|
||||
|
||||
Θα ονομάσουμε τον πυρήνα που προέκυψε από αυτές τις αλλαγές kernel-opts. Τα χαρακτηριστικά του φαίνονται παρακάτω:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Μέγεθος vmlinux: 1.4Mb
|
||||
Μέγεθος system: 527kb
|
||||
Μέγεθος bzImage: 536kb
|
||||
Ελεύθερη μνήμη: 1616Kb
|
||||
Χρόνος εκκίνησης: 27s
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Όπως παρατηρούμε, καταφέραμε να γλιτώσουμε περίπου 100kb από ένα ήδη σχετικά μικρό πυρήνα, απλώς με την αναβάθμιση της gcc και την ενεργοποίηση 2 επιλογών! Σε
|
||||
μεγαλύτερους πυρήνες μάλιστα έχουν αναφερθεί μειώσεις μεγέθους της τάξεως των 300kb. Τις παραπάνω επιλογές καλό θα ήταν να σκεφτούν και οι κάτοχοι καινούργιων
|
||||
μηχανημάτων, τουλάχιστον όσοι δε χρησιμοποιούν binary drivers.
|
||||
|
||||
|
||||
### [4. Το -tiny patchset]{#s4}
|
||||
|
||||
Για ακόμα δραστικότερες μειώσεις μεγέθους, ο μόνος τρόπος είναι να επέμβουμε στον κώδικα του πυρήνα. Αυτό άλλωστε είναι ένα από τα σημαντικότερα πλεονεκτήματα
|
||||
του open source! Ο μόνος κίνδυνος είναι ότι με τις επεμβάσεις μας μπορεί να εισάγουμε νέα λάθη τα οποία θα κάνουν ίσως κάποιο καιρό να ανακαλυφθούν, ανάλογα και
|
||||
με τη δημοτικότητα των αλλαγών μας. Αν δεν είμαστε προγραμματιστές, ή θέλουμε κάποιο καλό σημείο εκκίνησης, ο Matt Mackall διατηρεί ένα σύνολο τέτοιων
|
||||
επεμβάσεων (patches) που σκοπό έχουν να κάνουν τον καινούργιο πυρήνα φιλικότερο σε παλαιότερα ή ενσωματωμένα μηχανήματα, καθώς διαπιστώνει ότι η προσοχή του
|
||||
Linux μετακινήθηκε από αυτά \"από τότε που ο Linus βρήκε μια πραγματική δουλειά\".
|
||||
|
||||
Οι αλλαγές αυτές αποτελούν το -tiny patchset, διαθέσιμο στη διεύθυνση www.selenic.com/tiny. Εφαρμόζοντας το patch αυτό στον πυρήνα μας, παρατηρούμε ότι μια
|
||||
σειρά από νέες επιλογές εμφανίζονται κάτω από το μενού \"Remove kernel features\", το οποίο μάλιστα αλλάζει όνομα σε \"Configure standard kernel features (for
|
||||
small devices)\". Οι επιλογές αυτές ρυθμίζουν διάφορες παραμέτρους του \"εσωτερικού\" του πυρήνα δίνοντάς μας τη δυνατότητα να μικρύνουμε το μέγεθος διάφορων
|
||||
εσωτερικών δομών αλλά και γενικότερα να προσαρμόσουμε τον πυρήνα στα ιδιαίτερα χαρακτηριστικά του μηχανήματός μας.
|
||||
|
||||
Οι επιλογές που αξίζει να ενεργοποιήσουμε σε αυτό το μενού είναι: \"various size reductions for core\" (και networking), futex support, POSIX file locking API,
|
||||
Deadline I/O Scheduler, Optimize for size (και with register passing), Set compiler arch flags .. (-march=i386), sys file system (υποχρεωτικά!), support for
|
||||
executable shell scripts, block device support και από supported processor vendors, μόνο αυτόν που έχει φτιάξει τον επεξεργαστή μας (για μένα intel). Επίσης
|
||||
number of swap files = 0 (δηλαδή επιτρέπουμε ένα μόνο swap file (δεν ξέρω κανένα να χρησιμοποιεί παραπάνω από 1 έτσι κι αλλιώς, πόσο μάλλον σε ένα σκληρό των
|
||||
40Mb!), 4 tty line disciplines (είναι αρκετά), 10 realtime priority levels (μικραίνει τις δομές του δρομολογητή - scheduler) και 100Hz timer interrupts per
|
||||
second. Η τελευταία επιλογή είναι πολύ σημαντική για τη γρήγορη λειτουργία του υπολογιστή μας καθώς με περισσότερα Hz έχουμε μεν μεγαλύτερη ακρίβεια και
|
||||
καλύτερο χρόνο απόκρισης αλλά και μεγαλύτερο overhead το οποίο αφαιρεί πολύτιμους κύκλους από τους ήδη λίγους του επεξεργαστή μας. Τα 100Hz είναι κατά τη γνώμη
|
||||
μου ένας καλός συμβιβασμός για προ pentium επεξεργαστές.
|
||||
|
||||
Φυσικά και πάλι για να μην πληκτρολογείτε άσκοπα, το .config που χρησιμοποίησα βρίσκεται [εδώ](http://www.intelligence.tuc.gr/~pantelis/linuxlite/tiny.config).
|
||||
Τα χαρακτηριστικά του πυρήνα που προκύπτει από αυτή τη διαμόρφωση (kernel-tiny) φαίνονται παρακάτω.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Μέγεθος vmlinux: 1.2Mb
|
||||
Μέγεθος system: 446kb
|
||||
Μέγεθος bzImage: 456kb
|
||||
Ελεύθερη μνήμη: 2052kb
|
||||
Χρόνος εκκίνησης: 43s
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Είναι εύκολο να παρατηρήσουμε τη σημαντική οικονομία σε μνήμη που πετύχαμε με τις παραπάνω επιλογές, διατηρώντας παράλληλα τη λειτουργικότητα που θέλαμε και ένα
|
||||
σχετικά σταθερό πυρήνα. Το περίεργο που προέκυψε είναι ότι ο χρόνος αποσυμπίεσης του νέου πυρήνα έγινε σημαντικά μεγαλύτερος, πράγμα που αποτελεί την κύρια
|
||||
αιτία για την (ομολογουμένως σημαντική) αύξηση του χρόνου εκκίνησης. Η αύξηση αυτή πιστεύω ότι οφείλεται στις αλλαγές στον κώδικα αποσυμπίεσης του πυρήνα που
|
||||
περιλαμβάνονται στο -tiny patchset και σκοπό έχουν τη μείωση του μεγέθους εις βάρος της ταχύτητας. Παρόλα αυτά, το πρόβλημα αυτό δεν μας αφορά ιδιαίτερα καθώς
|
||||
θα προτείνουμε μια πολύ καλύτερη λύση για τη συμπίεση στην επόμενη ενότητα.
|
||||
|
||||
|
||||
### [5. Άλλες επεμβάσεις]{#s5}
|
||||
|
||||
Έχοντας δοκιμάσει τον προηγούμενο πυρήνα και βεβαιωθεί ότι δουλεύει και μάλιστα πολύ καλά και σταθερά για τις εφαρμογές που θέλουμε να τον χρησιμοποιήσουμε,
|
||||
μπορούμε να προβούμε και σε πιο δραστικές λύσεις, προκειμένου να ελευθερώσουμε ακόμα περισσότερη μνήμη, όπως το να απενεργοποιήσουμε τα μηνύματα του πυρήνα
|
||||
(printk) και τον κώδικα ανίχνευσης και αναφοράς των kernel panics. Οι επιλογές αυτές είναι αρκετά πιο επικίνδυνες από τις προηγούμενες και επίσης δεν προσφέρουν
|
||||
τόσα οφέλη, αλλά σε ένα μηχάνημα με π.χ. 2mb RAM είναι μάλλον αναγκαίες για να μπορέσει να λειτουργήσει έστω και στοιχειωδώς.
|
||||
|
||||
Τέλος, για ιδιαίτερα γρηγορότερη αποσυμπίεση καθώς και ακόμα μικρότερο μέγεθος bzImage, μπορούμε να συμπιέσουμε τον πυρήνα μας με το upx 1.90. Αν και ο
|
||||
συμπιεστής αυτός δεν είναι ανοιχτό λογισμικό, ο αποσυμπιεστής (που βάζει στο αρχείο του πυρήνα) είναι και μας δίνει το πλεονέκτημα αφενός της καλύτερης
|
||||
συμπίεσης από το gzip (376kb αντί για 436kb τελικό αρχείο) και αφετέρου της τρομερά γρηγορότερης αποσυμπίεσης (περίπου 2x). Επίσης, ο αποσυμπιεστής έχει μέγεθος
|
||||
μόνο μερικά bytes! (είναι γραμμένος σε assembly).
|
||||
|
||||
Έτσι φτάνουμε στον τελικό πυρήνα που έχει τα παρακάτω χαρακτηριστικά:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Μέγεθος vmlinux: 1.2Mb
|
||||
Μέγεθος system: 424kb
|
||||
Μέγεθος bzImage: 376kb
|
||||
Ελεύθερη μνήμη: 2112kb
|
||||
Χρόνος εκκίνησης: 15s
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Από εδώ κι εμπρός, υπάρχουν μεν κι άλλα πράγματα που μπορεί κάποιος να κάνει για ακόμα μικρότερους πυρήνες αλλά όλα περιλαμβάνουν αρκετό κόπο για ελάχιστα
|
||||
παραπάνω οφέλη, όποτε θα σταματήσουμε εδώ. Έτσι κι αλλιώς, τα 15s του χρόνου εκκίνησης είναι ήδη λιγότερα από τους χρόνους των περισσότερων φίλων μου με πολύ
|
||||
γρηγορότερους υπολογιστές από τα 8.19 BogoM\*ps του 386! (οι οποίοι όμως τρέχουν μη βελτιστοποιημένους πυρήνες και init sequences).
|
||||
|
||||
|
||||
### [6. Συμπεράσματα]{#s6}
|
||||
|
||||
Εκμεταλλευόμενοι το νεότερο μεταγλωττιστή και τις μεγαλύτερες δυνατότητες διαμόρφωσης του νέου πυρήνα, καταφέραμε να μειώσουμε σημαντικά το μέγεθός του (από 612
|
||||
σε 376kb για το bzImage) καθώς και το χρόνο εκκίνησης του συστήματος (σε λιγότερο από το μισό - από 32 σε 15 second!) φέρνοντας μάλιστα τον τελευταίο κοντά στα
|
||||
επίπεδα του dos ( 12s γιατί το dos χρειάζεται περισσότερες λειτουργίες από το BIOS τις οποίες μπορούμε να απενεργοποιήσουμε όταν χρησιμοποιούμε το Linux).
|
||||
|
||||
Ο πυρήνας που προέκυψε μπορεί άνετα να χρησιμοποιηθεί σε μηχανήματα με ακόμα και 4 (ή και 3Mb) RAM, επιτρέποντάς τους να εκμεταλλευτούν τις νέες δυνατότητες που
|
||||
προσφέρει (καλύτερη δικτύωση, καλύτερη υποστήριξη εφαρμογών πραγματικού χρόνου κλπ). Στη δική μου περίπτωση, ο 386 μπόρεσε με αυτό τον τρόπο να βγει από την
|
||||
αχρησία και απέκτησε αρκετές πρωτότυπες εφαρμογές (streaming video σε ascii-art! αλλά αυτό είναι μια άλλη ιστορία).
|
||||
|
||||
Αναστήστε λοιπόν κι εσείς τους παλιούς σας υπολογιστές και γελάστε άφοβα στα μούτρα όσων σας πουν ότι τα Longhorn θα χρειάζονται επεξεργαστή 2GHz και μνήμη
|
||||
512Mb μόνο για να ξεκινήσουν!!!.
|
||||
|
||||
|
||||
### [7. Αναφορές]{#s7}
|
||||
|
||||
- Shrinking the kernel with gcc (LWN) - http://lwn.net/Articles/67175/
|
||||
- Linux: Reducing Disk And Memory Footprint - http://kerneltrap.org/node/view/1769
|
||||
- UPX 1.90: http://upx.sourceforge.net/
|
||||
|
||||
324
content/articles/35/03_squid.md
Κανονικό αρχείο
324
content/articles/35/03_squid.md
Κανονικό αρχείο
|
|
@ -0,0 +1,324 @@
|
|||
+++
|
||||
title = 'Bandwith Limiting using Squid Proxy Server with Delay Pools and CBQ'
|
||||
date = ''
|
||||
description = ''
|
||||
author = 'Αντώνιος Χάψας'
|
||||
issue = ['Magaz 35']
|
||||
issue_weight = 3
|
||||
+++
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Ένα από τα κοινά προβλήματα που αντιμετωπίζει κάποιος στο μοίρασμα μιας σύνδεσης είναι ο σωστός καταμερισμός του bandwith και ο τρόπος διαχείρισης των χρηστών
|
||||
κατά τέτοιο τρόπο ώστε να υπάρξει η μέγιστη χρήση του δικτύου και η ισόποση κατανομή πακέτων σε όλους. Το παρακάτω κείμενο είναι μια μικρή προσπάθεια επίλυσης
|
||||
ενός τέτοιου προβλήματος.*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Σενάριο**
|
||||
--------------------------------------
|
||||
|
||||
**2. Τι θα χρειαστούμε**
|
||||
------------------------------------------------
|
||||
|
||||
**3. Εγκατάσταση Squid Proxy with Delay Pools Enabled**
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
- [3.1 Παράδειγμα 1](#ss3.1)
|
||||
- [3.2 Παράδειγμα 2](#ss3.2)
|
||||
|
||||
**4. Introducing CBQ (What is CBQ ?)**
|
||||
--------------------------------------------------------------
|
||||
|
||||
**5. About**
|
||||
------------------------------------
|
||||
|
||||
**6. Τέλος**
|
||||
------------------------------------
|
||||
|
||||
|
||||
### [1. Σενάριο]{#s1}
|
||||
|
||||
Ας υποθέσουμε ότι έχουμε μια dsl γραμμή και 5 χρήστες που μοιράζονται αυτή την σύνδεση μέσω ενός proxy server που τρέχει linux. Θα θέλαμε για παράδειγμα όταν
|
||||
κατεβάζουν όλοι διάφορα αρχεία από internet να έχουν συγκεκριμένη ταχύτητα πχ. 15 kb/s, κάποιος που κατεβάζει παραπάνω από 2 ώρες να πέφτει η ταχύτητά του στα 5
|
||||
kb/s (ποίος κατεβάζει συνέχεια ταινίες ?!) και κάποιος που κατεβάζει π.χ. ένα αρχείο .avi η ταχύτητά του να μην ξεπερνάει τα 2kb/s (ας πρόσεχε !). Η λύση σε
|
||||
αυτό γίνεται με την χρήση magic word πχ. .mp3,.exe,.zip.
|
||||
|
||||
|
||||
### [2. Τι θα χρειαστούμε]{#s2}
|
||||
|
||||
Καταρχήν ένα pc που τρέχει linux, (στην δικιά μας περίπτωση έτρεχε Mandrake 9.1 αλλά έχει δοκιμαστεί και σε RedHat 6.2, οπότε λογικά πρέπει να παίζει και σε
|
||||
άλλες γνωστές εκδόσεις) μια κάρτα δικτύου σε αυτό και μπόλικη όρεξη. Αυτός ο οδηγός προϋποθέτει ότι υπάρχουν οι βασικές γνώσεις Linux και για αυτό δεν θα
|
||||
σταθούμε αναλυτικά σε εντολές bash. Κατεβάζουμε το squid source από http://www.squid-cache.org, στην συγκεκριμένη περίπτωση το squid είχε έκδοση
|
||||
squid-2.5.STABLE4 (έχει δοκιμαστεί και με παλιότερα sources). Για να υπάρχει καλύτερη απόδοση προτείνεται να υπάρχει ένας ξεχωριστός δίσκος που θα υπάρχει η
|
||||
cache του proxy.
|
||||
|
||||
|
||||
### [3. Εγκατάσταση Squid Proxy with Delay Pools Enabled]{#s3}
|
||||
|
||||
Σε κονσόλα πάντα προσθέτουμε τον χρήστη squid (αν δεν υπάρχει, αν υπάρχει τον αφαιρούμε με userdel) αφού έχουμε φτιάξει ένα directory με όνομα cache:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# useradd -d /cache/ -r -s /dev/null squid >/dev/null 2>&1
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Κανένας δεν μπορεί να κάνει login σαν χρήστης squid εννοείται και ο root. Αυτό είναι ένα βήμα βέλτιστης ασφάλειας που μπορεί βεβαίως να παραλειφθεί αν δεν
|
||||
υπάρχει άμεσος κίνδυνος. (πάντα υπάρχει !)
|
||||
|
||||
Αφού έχουμε κατεβάσει το squid source το αποσυμπιέζουμε πχ. στο /tmp:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# cd/tmp
|
||||
# tar xzfv squid-2.5.STABLE4-src.tar.gz
|
||||
# cd squid-2.5.STABLE4
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Είμαστε έτοιμοι για το compile.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
#./configure --prefix=/opt/squid --exec-prefix=/opt/squid --enable-delay-pools --enable-cache-digests \
|
||||
--enable-poll --disable-ident-lookups --enable-truncate --enable-removal-policies
|
||||
# make all
|
||||
# make install
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αφού ολοκληρώσουμε επιτυχώς o squid έχει εγκατασταθεί στο /opt/squid. Και για να είμαστε σίγουροι ότι τα πάντα κάτω από το /opt/squid και /cache ανήκει στον
|
||||
χρήστη squid γράφουμε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# chown -R squid:squid /opt/squid
|
||||
# chown -R squid:squid /cache
|
||||
|
||||
ή
|
||||
|
||||
# chown -R squid.squid /opt/squid
|
||||
# chown -R squid.squid /cache.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Υποθέτουμε ότι το δίκτυο μας είναι το 192.168.0.0/24. Μετά πάμε στο /opt/squid/etc/squid.conf που είναι το σημαντικότερο βήμα. Ένα τυπικό squid.conf είναι το
|
||||
παρακάτω:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# SQUID CONFIGURATION FILE
|
||||
# by Αντώνιος Χάψας © 2003.
|
||||
visible_hostname Dias #Your name pc
|
||||
http_port 8080
|
||||
icp_port 3130
|
||||
acl QUERY urlpath_regex cgi-bin ?
|
||||
no_cache deny QUERY
|
||||
cache_mem 64 MB
|
||||
|
||||
cache_dir ufs /cache 250 16 256
|
||||
redirect_rewrites_host_header off
|
||||
cache_replacement_policy GDSF
|
||||
emulate_httpd_log on
|
||||
|
||||
acl localnet src 192.168.0.0/255.255.255.0
|
||||
acl localhost src 127.0.0.1/255.255.255.255
|
||||
acl Safe_ports port 80 443 210 119 70 21 1025-65535
|
||||
acl CONNECT method CONNECT
|
||||
acl all src 0.0.0.0/0.0.0.0
|
||||
http_access allow localnet
|
||||
http_access allow localhost
|
||||
http_access deny !Safe_ports
|
||||
http_access deny CONNECT
|
||||
http_access deny all
|
||||
|
||||
maximum_object_size 3000 KB
|
||||
store_avg_object_size 50 KB
|
||||
|
||||
#Αυτό το κομμάτι το γουστάρω πολύ,
|
||||
#για τους έξω χρήστες χρησιμοποιείται τον παρακάτω browser !
|
||||
anonymize_headers deny User-Agent
|
||||
fake_user_agent Shit/1.0 (FuckWindows; U; WindowsShit 1.0 i8088)
|
||||
|
||||
cache_mgr root
|
||||
cache_effective_user squid
|
||||
cache_effective_group squid
|
||||
log_icp_queries off
|
||||
buffered_logs on
|
||||
|
||||
# Εδώ είναι το κρίσιμο κομμάτι που μας ενδιαφέρει
|
||||
#DELAY POOLS
|
||||
#Δεν θέλουμε να περιορίσουμε το κατέβασμα στο τοπικό μας δίκτυο
|
||||
acl magic_words1 url_regex -i 192.168
|
||||
#Θέλουμε να περιορίσουμε το κατέβασμα των παρακάτω αρχείων
|
||||
#Όλα σε μια σειρά
|
||||
acl magic_words2 url_regex -i ftp .zip .exe .mp3 .rpm .zip .avi .mpeg
|
||||
# Δεν βάζουμε .htm .html .jpg .gif γιατί συνήθως δεν καταναλώνουν μεγάλο bandwith.
|
||||
#Εχουμε 2 διαφορετικά delay_pools
|
||||
delay_pools 2
|
||||
#1st Delay pool
|
||||
delay_class 1 2
|
||||
#-1/-1 σημαίνει ότι δεν έχουμε όρια
|
||||
delay parameters 1 -1/-1 -1/-1
|
||||
delay_access 1 allow magic_words1
|
||||
|
||||
#2nd Delay pool
|
||||
delay_class 2 2
|
||||
#Τα παρακάτω νούμερα είναι σε bytes
|
||||
# 6000/15000 είναι τα νούμερα για όλο το δίκτυο
|
||||
# 5000/15000 είναι για μια απλή ΙΡ
|
||||
#για κατέβασμα αρχείων μεγαλύτερο από 150000 bytes
|
||||
#οι χρήστες συνεχίζουν το κατέβασμα με 5000 bytes/s
|
||||
delay_parameteres 2 6000/150000 5000/150000
|
||||
delay_access 2 alllow magic_words2
|
||||
#Τέλος Αρχείου.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αφού είμαστε σίγουροι ότι το παραπάνω αρχείο είναι σωστό γράφουμε για να δημιουργηθούν τα cache του directories:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# /opt/squid/sbin/squid -z
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Λογικά πρέπει να είμαστε εντάξει, κάνουμε ένα έλεγχο με τους browser μας βάζοντας την ip του server στο 8080. Γράφουμε ένα ps -A \| grep squid για να δούμε αν
|
||||
τρέχει. Για να τρέχει κάθε φορά που ξεκινάει ο server μας βάζουμε την παρακάτω γραμμή στο τέλος του /etc/rc.d/rc.local
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
/opt/squid/sbin/squid -D
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Aλλες χρήσιμες εντολές θα μπορούσε να είναι η
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# /opt/squid/sbin/squid -κ reconfigure (κάνει reconfigure αν κάναμε αλλαγές στο squid.conf)
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
όπως και η
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# /opt/squid/sbin/squid -help.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
### [3.1 Παράδειγμα 1]{#ss3.1}
|
||||
|
||||
Περιορισμός μιας γραμμής ολικού bandwith ας πούμε στα 512 Kbs.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
acl all src 0.0.0.0/0.0.0.0 #μπορεί να έχει επαναληφθεί πιο πάνω.
|
||||
delay pools 1
|
||||
delay_class 1 1
|
||||
delay_access 1 allow alll
|
||||
delay_parameteres 1 64000/64000 #512 kbits = 64 kbytes pes sec
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
### [3.2 Παράδειγμα 2]{#ss3.2}
|
||||
|
||||
Περιορισμός μια γραμμής στα 128 Kbps.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
acl 128Kusers src 192.168.0.1/255.255.255.0
|
||||
acl all src 0.0.0.0/0.0.0.0
|
||||
delay_pools 1
|
||||
delay_class 1 3
|
||||
delay_access 1 allow 128kusers
|
||||
delay_access 1 deny all
|
||||
delay_parameters 1 64000/64000 -1/-1 16000/64000
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Το παραπάνω παράδειγμα δίνει μια λύση σε ένα δίκτυο από ένα σύνολο 512Kbits, και κάθε ΙΡ παίρνει μόνο 128Kbits από αυτό το pool.
|
||||
|
||||
Περισσότερα παραδείγματα στο http://www.squid-cache.org/Doc/FAQ/FAQ-19.html.
|
||||
|
||||
|
||||
### [4. Introducing CBQ (What is CBQ ?)]{#s4}
|
||||
|
||||
Η παραπάνω διαδικασία ισχύει αν όλο το traffic διακινείται μέσω του squid proxy server από έναν browser πχ. Internet Explorer. Τι γίνεται όμως αν πχ. έχουμε
|
||||
έναν υπολογιστή που βρίσκεται πίσω από Linux server με Ip Masquerade ? Η λύση λέγεται CBQ. Για να δούμε όμως τι γίνεται. Καταρχήν πρέπει να είναι εγκαταστημένο
|
||||
στο linux μας το iproute2 (συνήθως είναι). Κατεβάζουμε το cbq.init-v0.7.2 από το https://sourceforge.net/projects/cbqinit και το βάζουμε στο /etc/sysconfig/cbq
|
||||
(το directory αν δεν υπάρχει, το φτιάχνουμε). Φτιάχνουμε ένα αρχείο για να περιορίσουμε την κίνηση μέσω του ftp πρωτοκόλλου
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# touch /etc/sysconfig/cbq/cbq-10.ftp-network
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Βάζουμε μέσα σε αυτό:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
DEVICE=eth0,10Kbit,1Mbit
|
||||
RATE=10Kbit
|
||||
WEIGHT=1Kbit
|
||||
PRIO=5
|
||||
RULE=:20,192.168.0.0/24
|
||||
RULE=:21,192.168.0.0/24
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Για κάθε μια από τις παραπάνω εντολές υπάρχει επεξήγηση στο cbq.init-v0.7.2 αρχείο.
|
||||
|
||||
Μετά τρέχουμε ./cbq.init-v0.7.2 compile (είναι εκτελέσιμο, αν δεν είναι chmod +x cbq.init-v0.7.2) και κατόπιν ./cbq.init-v0.7.2 start και είμαστε έτοιμοι για
|
||||
δοκιμές. Σε μένα λειτούργησε χωρίς κανένα πρόβλημα απολύτως. Με το παραπάνω ο server μας δεν θα στέλνει ftp data στο eth0 γρηγορότερα από 10kbits/sec και δεν θα
|
||||
κατεβάζει γρηγορότερα από 10kbits/sec. Αν πχ μέσω squid υπάρχει καλύτερη απόδοση ο χρήστης θα αναγκαστεί να χρησιμοποιεί τον squid για τα downloads του. Ας
|
||||
φτιάξουμε ένα ακόμα παράδειγμα πχ. για το Windows Media Player και το Emule.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
DEVICE=eth0,10Mbit,1Mbit
|
||||
RATE=50Kbit
|
||||
WEIGHT=5Kbit
|
||||
PRIO=5
|
||||
#Windows Media Player
|
||||
RULE=:1755,192.168.0.0/24
|
||||
#Emule
|
||||
RULE=:4661,192.168.0.0/24
|
||||
RULE=:4671,192.168.0.0/24 # Διορθώστε με μήπως κάνω λάθος τις πόρτες.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αν θέλουμε να είμαστε πιο έξυπνοι μπορούμε να βάλουμε πολλούς ρόλους στο cbq και να είμαστε αυστηροί στο μοίρασμα του bandwith (με το σταγονόμετρο !) έτσι ώστε
|
||||
να αναγκάσουμε όλο τον κόσμο να χρησιμοποιεί τον proxy server (θέλοντας και μη !). Αν τρέχουμε Ip-Masquerade για να έχουν οι χρήστες icq, email κ.α. ή για
|
||||
κάποιο άλλο λόγο, καλό θα ήταν για τους εξυπνάκηδες του δικτύου μας, να τρέχαμε iptables με περιορισμούς (ipchains επίσης για παλαιότερες εκδόσεις Linux) έτσι
|
||||
ώστε κανένας να μην συνδέετε απευθείας (Ip-Masquerade).
|
||||
|
||||
Τέλος αφού βλέπουμε ότι όλα είναι εντάξει βάζουμε στο /etc/rc.d/rc.local στο τέλος το cbq.init-v0.7.2 start για να ξεκινάει κάθε φορά που γίνεται εκκίνηση στον
|
||||
υπολογιστή μας.
|
||||
|
||||
Υπάρχει ένας ακόμα εύκολος αλλά μάλλον ξεπερασμένος τρόπος για να γίνει αυτό το traffic shaping. Στην διαδρομή
|
||||
/usr/src/linux-2.4.21-0.13mdk/Documentation/networking/ (σε έκδοση Mandrake 9.1) υπάρχει το αρχείο shaper.txt που αναφέρει πως, αλλά είναι μάλλον για μια εύκολη
|
||||
και περιστασιακή περίπτωση και δεν δίνει ευελιξία στον server μας.
|
||||
|
||||
|
||||
### [5. About]{#s5}
|
||||
|
||||
Το παραπάνω κείμενο δημιουργήθηκε εξ ολοκλήρου σε Linux Mandrake 9.1 και γράφτηκε με την χρήση του προγράμματος OpenOffice 1.0.2. (Για να είμαι πάντως
|
||||
ειλικρινής είχα εγκαταστήσει την γραμματοσειρά verdana από τα windows στο OpenOffice!) Οι παραπάνω οδηγίες έγιναν επιτυχώς στο ίδιο λειτουργικό χωρίς κανένα
|
||||
απολύτως πρόβλημα.
|
||||
|
||||
|
||||
### [6. Τέλος]{#s6}
|
||||
|
||||
Η παραπάνω προσπάθεια έγινε εκ μέρους μου θέλοντας να βάλω και εγώ ένα λιθαράκι στην προσπάθεια μερικών administrators να ομαλοποιήσουν και να αυξήσουν τις
|
||||
δυνατότητες των δικτύων τους, με την χρήση πάντα Open Source λειτουργικών συστημάτων και προγραμμάτων που είναι free. Το παραπάνω κείμενο λογικά θα περιέχει
|
||||
κάποια λάθη γι αυτό θα εκτιμηθεί ιδιαίτερα οποιαδήποτε διόρθωση. Το email μου είναι το antonyhapsas\@hotmail.com και είναι δεκτή οποιαδήποτε
|
||||
διόρθωση/παρατήρηση. Αυτή είναι η πρώτη έκδοση αυτού του tutorial, λογικά θα υπάρξει και νεότερη με περισσότερες τεχνικές και διορθώσεις.
|
||||
|
||||
Και για να έχουμε φυλαγμένα τα νώτα μας
|
||||
|
||||
ΔΕΝ ΥΠΑΡΧΕΙ ΚΑΜΙΑ ΑΠΟΛΥΤΩΣ ΕΓΓΥΗΣΗ ΟΤΙ ΤΑ ΠΑΡΑΠΑΝΩ ΔΕΝ ΠΡΟΚΕΙΤΑΙ ΝΑ ΚΑΤΑΣΤΡΕΨΟΥΝ ΤΟ ΛΕΙΤΟΥΡΓΙΚΟ ΣΑΣ Η ΝΑ ΔΗΜΙΟΥΡΓΗΣΟΥΝ ΑΝΕΠΑΝΟΡΘΩΤΗ ΒΛΑΒΗ ΣΤΟΝ ΥΠΟΛΟΓΙΣΤΗ ΣΑΣ. Η
|
||||
ΠΑΡΑΠΑΝΩ ΔΙΑΔΙΚΑΣΙΑ ΓΙΝΕΤΑΙ ΠΑΝΤΑ ΜΕ ΔΙΚΗ ΣΑΣ ΕΥΘΥΝΗ.
|
||||
|
||||
241
content/articles/35/04_pubkey-gr.md
Κανονικό αρχείο
241
content/articles/35/04_pubkey-gr.md
Κανονικό αρχείο
|
|
@ -0,0 +1,241 @@
|
|||
+++
|
||||
title = 'Passwordless public key authentication using SSH/OpenSSH'
|
||||
date = ''
|
||||
description = ''
|
||||
author = 'Στέφανος Χαρχαλάκης'
|
||||
issue = ['Magaz 35']
|
||||
issue_weight = 4
|
||||
+++
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Ένας βήμα προς βήμα οδηγός για ενεργοποίηση public-key authentication σε SSH/OpenSSH.*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Εισαγωγή**
|
||||
-------------------------------------------
|
||||
|
||||
**2. Δημιουργία κλειδιών**
|
||||
------------------------------------------------------
|
||||
|
||||
- [2.1 Δημιουργία DSA κλειδιών με χρήση SSH](#ss2.1)
|
||||
- [2.2 Δημιουργία DSA κλειδιών με χρήση OpenSSH](#ss2.2)
|
||||
|
||||
**3. Configuration του Client**
|
||||
-----------------------------------------------------------
|
||||
|
||||
- [3.1 Configuration του Client (SSH)](#ss3.1)
|
||||
- [3.2 Configuration του Client (OpenSSH)](#ss3.2)
|
||||
- [3.3 Μετατροπή του public key](#ss3.3)
|
||||
- [3.4 Client: OpenSSH, Server: OpenSSH](#ss3.4)
|
||||
- [3.5 Client: SSH, Server: SSH](#ss3.5)
|
||||
- [3.6 Client: OpenSSH, Server: SSH](#ss3.6)
|
||||
- [3.7 Client: SSH, Server: OpenSSH](#ss3.7)
|
||||
|
||||
**4. Configuration του Server**
|
||||
-----------------------------------------------------------
|
||||
|
||||
- [4.1 Configuration του Server (SSH)](#ss4.1)
|
||||
- [4.2 Configuration του Server (OpenSSH)](#ss4.2)
|
||||
|
||||
**5. Δοκιμή**
|
||||
-----------------------------------------
|
||||
|
||||
|
||||
### [1. Εισαγωγή]{#s1}
|
||||
|
||||
Το κείμενο αυτό περιγράφει τα βήματα τα οποία απαιτούνται για να πραγματοποιηθεί public key authentication χρησιμοποιώντας SSH ή/και OpenSSH.
|
||||
|
||||
Για τις ανάγκες του κειμένου υποθέτουμε ότι:
|
||||
|
||||
- Υπάρχει ένα μηχάνημα με το όνομα Client (hostname: Client.hell.gr, IP: 10.1.1.2).
|
||||
- Υπάρχει ένα μηχάνημα με το όνομα Server (hostname: Server.hell.gr, IP: 10.1.1.3).
|
||||
- Υπάρχει ένα account με το όνομα clntacnt στο Client.
|
||||
- Υπάρχει ένα account με το όνομα srvacnt στο Server.
|
||||
- Ο clntacnt\@Client θα προσπαθήσει να συνδεθεί στο srvacnt\@Server.
|
||||
- Θα χρησιμοποιηθεί η έκδοση 2 του SSH πρωτοκόλλου και ο DSA σαν αλγόριθμος παραγωγής κλειδιού.
|
||||
|
||||
Για να λειτουργήσει η πιστοποίηση δεν πρέπει να είναι κλειδωμένος ο srvacnt ούτε να έχει λήξει το password του.
|
||||
|
||||
Για την πραγματοποίηση του public key authentication ο χρήστης πρέπει:
|
||||
|
||||
- Να δημιουργήσει ένα ζευγάρι public/private DSA κλειδιών.
|
||||
- Να έχει τα public και private κλειδιά στο Client.
|
||||
- Να έχει το public κλειδί στο Server.
|
||||
|
||||
|
||||
### [2. Δημιουργία κλειδιών]{#s2}
|
||||
|
||||
Τα κλειδιά μπορούν να δημιουργηθούν στο Client ώστε να αποφευχθεί η μεταφορά του private κλειδιού μέσα από το δίκτυο εκτός και αν η μεταφορά γίνει με κάποιο
|
||||
ασφαλή τρόπο όπως το sftp.
|
||||
|
||||
Το κείμενο αυτό περιγράφει την διαδικασία δημιουργίας κλειδιών στη μεριά του Cleint χρησιμοποιώντας SSH ή OpenSSH. Το SSH χρησιμοποιεί το /.ssh2 ενώ το OpenSSH
|
||||
χρησιμοποιεί το /.ssh για να αποθηκεύσουν τα αρχείου τους για το SSH2.
|
||||
|
||||
### [2.1 Δημιουργία DSA κλειδιών με χρήση SSH]{#ss2.1}
|
||||
|
||||
Για τη δημιουργία των κλειδιών με SSH χρησιμοποιείστε το ssh-keygen2 χωρίς να δώσετε κάποιο passphrase (πατήστε enter όταν ζητηθεί):
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ ssh-keygen2
|
||||
Generating 1024-bit dsa key pair
|
||||
3 o.oOo.ooOo.o
|
||||
Key generated.
|
||||
1024-bit dsa, clntacnt@Client, Thu Mar 06 2003 17:20:35 +0200
|
||||
Passphrase :
|
||||
Again :
|
||||
Key is stored with NULL passphrase.
|
||||
(You can ignore the following warning if you are generating hostkeys.)
|
||||
This is not recommended.
|
||||
Don't do this unless you know what you're doing.
|
||||
If file system protections fail (someone can access the keyfile),
|
||||
or if the super-user is malicious, your key can be used without
|
||||
the deciphering effort.
|
||||
Private key saved to /home/clntacnt/.ssh2/id_dsa_1024_a
|
||||
Public key saved to /home/clntacnt/.ssh2/id_dsa_1024_a.pub
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
### [2.2 Δημιουργία DSA κλειδιών με χρήση OpenSSH]{#ss2.2}
|
||||
|
||||
Στην περίπτωση του OpenSSH χρησιμοποιείστε το ssh-keygen χωρίς να δώσετε κάποιο passphrase:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ ssh-keygen -t dsa
|
||||
Generating public/private dsa key pair.
|
||||
Enter file in which to save the key (/home/clntacnt/.ssh/id_dsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /home/clntacnt/.ssh/id_dsa.
|
||||
Your public key has been saved in /home/clntacnt/.ssh/id_dsa.pub.
|
||||
The key fingerprint is:
|
||||
04:91:c8:22:7b:aa:2a:c4:e7:66:1e:61:1e:2b:32:d8 clntacnt@Client
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
|
||||
### [3. Configuration του Client]{#s3}
|
||||
|
||||
Αυτή τη στιγμή έχουν δημιουργηθεί τα κλειδιά και καλό είναι να μετονομαστούν σε κάτι που να έχει νόημα (π.χ. clntkey και clntkey.pub). Στη συνέχεια θα πρέπει να
|
||||
δημιουργηθεί η να αλλαχθεί το configuration του Client ώστε να χρησιμοποιεί αυτό το κλειδί για πιστοποίηση στον Server:
|
||||
|
||||
### [3.1 Configuration του Client (SSH)]{#ss3.1}
|
||||
|
||||
Ανοίξτε το clntacnt/.ssh2/identification και προσθέστε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Server.hell.gr:
|
||||
IdKey clntkey
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
### [3.2 Configuration του Client (OpenSSH)]{#ss3.2}
|
||||
|
||||
Ανοίξτε το clntacnt/.ssh/config και προσθέστε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Host Server.hell.gr
|
||||
IdentityFile ~/.ssh/clntkey
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
### [3.3 Μετατροπή του public key]{#ss3.3}
|
||||
|
||||
Το SSH και το OpenSSH έχουν διαφορετική μορφή για τα αρχεία των public και private κλειδιών. Αν οι δαίμονες στο Client και το Server δεν είναι ίδιοι θα πρέπει
|
||||
να γίνει μετατροπή του public key χρησιμοποιώντας το ssh-keygen του OpenSSH. Αυτό θα γίνει στο μηχάνημα στο οποίο υπάρχει το OpenSSH.
|
||||
|
||||
### [3.4 Client: OpenSSH, Server: OpenSSH]{#ss3.4}
|
||||
|
||||
Στείλτε το clntkey.pub στο Server και τοποθετήστε το στο srvacnt/.ssh/clntkey.pub.
|
||||
|
||||
### [3.5 Client: SSH, Server: SSH]{#ss3.5}
|
||||
|
||||
Στείλτε το clntkey.pub στο Server και τοποθετήστε το στο srvacnt/.ssh2/clntkey.pub.
|
||||
|
||||
### [3.6 Client: OpenSSH, Server: SSH]{#ss3.6}
|
||||
|
||||
Πρώτα μετατρέψτε το public key στη μορφή που το χρειάζεται το SSH (στο Client):
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ ssh-keygen -e -f clntkey.pub > tmp
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
και στη συνέχεια στείλτε το στο Server και τοποθετήστε το στο srvacnt/.ssh2/clntkey.pub.
|
||||
|
||||
### [3.7 Client: SSH, Server: OpenSSH]{#ss3.7}
|
||||
|
||||
Πρώτα στείλτε το public key στο Server τοποθετώντας το στο srvacnt/.ssh/clntkey.pub και στη συνέχεια μετατρέψτε το:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ ssh-keygen -i -f clntkey.pub.tmp > clntkey.pub
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
|
||||
### [4. Configuration του Server]{#s4}
|
||||
|
||||
### [4.1 Configuration του Server (SSH)]{#ss4.1}
|
||||
|
||||
Αυτή τι στιγμή το public key πρέπει να βρίσκεται στο srvacnt/.ssh2/clntkey.pub. Ανοίξτε το srvacnt/.ssh2/authorization και προσθέστε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
10.1.1.2:
|
||||
Key clntkey.pub
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
(Το 10.1.1.2 είναι η IP διεύθυνση του Client)
|
||||
|
||||
### [4.2 Configuration του Server (OpenSSH)]{#ss4.2}
|
||||
|
||||
Αυτή τι στιγμή το public key πρέπει να βρίσκεται στο srvacnt/.ssh/clntkey.pub. Ανοίξτε το και προσθέστε στην αρχή του το \`\`from=\"Client.hell.gr\"\'\'. Το
|
||||
όλο clntkey.pub πρέπει να δείχνει κάπως έτσι:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
from="client.hell.gr" ssh-dss AAAAB3NzaC1kc .... gSlSJA==
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Τέλος, προσθέστε το κλειδί αυτό στο τέλος του srvacnt/.ssh/authorized\_keys:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ cat clntkey.pub >> authorized_keys
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
|
||||
### [5. Δοκιμή]{#s5}
|
||||
|
||||
Πηγαίνετε στο Client και σαν clntacnt δώστε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ ssh srvacnt@Server.hell.gr
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αν όλα πήγαν καλά θα σας βάλει μέσα στο Server χωρίς να ζητήσει password. Πρέπει να δώσετε ολόκληρο το hostname, ακριβώς όπως υπάρχει μέσα στο configuration
|
||||
file του Client.
|
||||
|
||||
|
||||
### [6. Δοκιμή]{#s6}
|
||||
|
||||
Πηγαίνετε στο Client και σαν clntacnt δώστε:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ ssh srvacnt@Server.hell.gr
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αν όλα πήγαν καλά θα σας βάλει μέσα στο Server χωρίς να ζητήσει password. Πρέπει να δώσετε ολόκληρο το hostname, ακριβώς όπως υπάρχει μέσα στο configuration
|
||||
1253
content/articles/35/05_rce4.md
Κανονικό αρχείο
1253
content/articles/35/05_rce4.md
Κανονικό αρχείο
Το diff αρχείου καταστέλλεται επειδή είναι πολύ μεγάλο
Φόρτωση διαφορών
Φόρτωση…
Προσθήκη πίνακα
Προσθήκη υπερσυνδέσμου
Παράθεση σε νέο ζήτημα