Δοκίμασα 1. τους nvidia drivers και 2. το compiz fusion στο gutsy και εξεπλάγην! Καταρχάς οι nvidia drivers πέρα από ιδιόκτητοι (αλλά όμως είπε και ο jon maddog hall "nvidia is sweating right now" μετά την απόφαση της ATI να βγάλει o/s drivers) δεν έπαιζαν και καλά με το suspend και το hibernate του laptop μου. Αυτό και μόνο ήταν αρκετό για να μην ασχοληθώ περαιτέρω με αυτούς παλιότερα. Όμως λύση βρέθηκε! Αντικατέστησα στο αρχείο /etc/default/acpi-support τις παραμέτρους SAVE_VBE_STATE και POST_VIDEO από 'true' σε 'false'.

Επίσης αφαίρεσα την επιλογή sync_to_vblank στο compiz config

gconftool --set /apps/compiz/general/screen0/options/sync_to_vblank 0 --type bool


Μετά ενεργοποίησα το compiz από το μενού system->preferences->appearance και θα διαπίστωσα ότι οι 'normal' ρυθμίσεις του gutsy όχι μόνο δεν είναι κουραστικές, όχι μόνο φτάνουν για να αποδείξω ότι το Aero είναι της πλάκας αλλά και δίνουν μια αίσθηση ταχύτητας στο desktop.

Φαίνεται όμως ότι η οθόνη δεν κλείδωνε αυτόματα, όποτε έκλεινα το "καπάκι" του laptop και χρειάστηκε ακόμη μια επέμβαση στο gconf

gconftool --set /apps/gnome-power-manager/lock/blank_screen 1 --type bool


Και τώρα, μετά από αυτές τις κουραστικές ρυθμίσεις μπορώ να παίξω extreme tux racer!

Έκανα και εγώ το bleeding edge upgrade στο laptop μου για να γευτώ τα τελευταία τεχνολογικά κατορθώματα της κοινότητας του Ελεύθερου Λογισμικού αλλά είχα από το πρώτο 15' κακή εμπειρία. Και όταν λέω κακή εμπειρία, να μην βιαστούν οι υπέρμαχοι των Vista και της M$ να χαρούν, γιατί ο πήχης έχει ανέβει τόσο ψηλά τα τελευταία χρόνια στις διανομές Linux που κακή εμπειρία είναι να μην παίζει άψογα μετά από upgrade και όχι καθαρή, νέα εγκατάσταση το εξειδικευμένο feauture που είχες φτιάξει στο μηχάνημά σου.

Σε εμένα λοιπόν δεν έπαιξε αμέσως το κρυπτογραφημένο (με encfs) home το οποίο ήθελε μια επιπλέον γραμμή στο config του που αύξανε την ασφάλεια. Το fix ήταν τόσο μικρό και γρήγορο (και το κάλυπτε η τεκμηρίωση) που ούτε καν θυμάμαι τι έκανα και που.

Το απογοητευτικό bug ήταν όμως τα προβλήματα που παρουσιάστηκαν με το suspend/hibernate του υπολογιστή. Ο NetworkManager είναι πιο ασταθής από τον προηγούμενο και το σύστημα δεν αποκαθιστά πάντα την σύνδεση με το δίκτυο μετά το resume. Βέβαια ένα 'sudo killall -9 NetworkManager && sudo NetworkManager' κανεί την δουλειά αλλά γιατί να παίζει χειρότερα από πριν;.

Εφτιαξά λοιπόν και το δίκτυο και βάζω να ακούσω λίγη μουσική αλλά δεν ακουγόταν τίποτα! Αυτό πάει πολύ! Δηλωμένο bug με την συγκεκριμένη alsa έκδοση και τον Intel HD driver ήχου, αλλά πριν έπαιζε! Ευτυχώς για το Gutsy το πρόβλημα λύνεται -όπως συμβουλεύει η σελίδα Gutsy Intel HD Audio Controller μόνο με ένα

~# aptitude install linux-backports-modules-generic
~# echo "options snd-hda-intel model=dell-m42" >> /etc/modprobe.d/alsa-base

στο latitude d820 που έχω.

Με λίγα λόγια το Gutsy είναι εδώ, παίζει αξιοπρεπώς αλλά όπως και το Feisty τις πρώτες μέρες δεν σου δίνουν την αίσθηση του σταθερού μηχανήματος. Δεν έχω διαπιστώσει εάν απλά συμβιβάζομαι με τα προβλήματα ή τρέχει κανένα περίεργο δαιμονάκι με reinforced learning τεχνικές που διορθώνει το σύστημα σύμφωνα με τις προτιμήσεις σου... Γιατί από τους Software Freedom Fighters όλα να τα περιμένεις!

To howto αυτό θα μας δείξει πως να δρομολογήσουμε δεδομένα IP (TCP, UDP κτλ) "πάνω" ή καλύτερα μέσα σε DNS δεδομένα τύπου ΤΧΤ. Με απλά ελληνικά: πως θα πάρω πρόσβαση στο internet από εκείνο το wifi hotspot στο πλοίο (ή το αεροδρόμιο ή οπουδήποτε έχουν το θράσος να χρεώνουν γι' αυτό το απαραίτητο αγαθό της ζωής!)

Συστατικά:

• Ένα linux laptop σε τοποθεσία με επί-πληρωμή wifi. Κατα προτίμηση με κάτι debian based. Εγώ το έκανα με Ubuntu
• Ένας linux server
• Ένα domain που να μπορούμε να επεξεργαστούμε τα subdomain του
• Το nstx λογισμικό (debian πακέτο nstx) website

Βασική ιδέα

Η βασική ιδέα πίσω από το όλο εγχείρημα είναι η εξής. Βρισκόμαστε σε ένα χώρο με wifi hotspot στο οποίο μπορούμε να συνδεθούμε, παίρνουμε IP και μόλις ζητήσουμε ένα site αντί για το site εμφανίζεται μία ωραία σελίδα που σου λέει να βάλεις τον κωδικό σου. Σε αυτές τις περιπτώσεις συνήθως επιτρέπεται να κάνεις ping ή/και dns queries χωρίς πρόβλημα. Οπότε αμέσως το διαβολάκι πάνω από τον αριστερό σου ώμο σε ρωτάει: "Δεν είναι δυνατόν να δρομολογήσουμε κάπως δεδομένα IP "πάνω" από ICMP (ping) ή DNS?" Φυσικά και είναι δυνατόν.

Σε δύο εγκαταστάσεις με αυτό το σύστημα που έχω δει, επιτρέπουν και οι δύο ping και dns δεδομένα χωρίς να τα φιλτράρουν (τα dns φυσικά μόνο προς τον δικό τους dns server). Δυστυχώς όμως οι λύσεις IP over ICMP (παρόλο που υπάρχουν πολλές στο google και το ptunnel σε πακέτο στο ubuntu) δεν έπαιξαν επειδή έπαιρνες εσωτερικό IP και είχες πρόσβαση στο δίκτυο μέσω NAT. Οπότε κάπου κόλλαγε η διαδικασία.

Απορρίπτουμε λοιπόν το IP over ICMP και πάμε στο πιο δύσκολο στο set-αρισμα, αλλά πολύ πιο πιθανό να παίζει εάν όχι σε όλες, τουλάχιστον στις περισσότερες εγκαταστάσεις τέτοιου τύπου IP over DNS. Με απλά λόγια αυτό που κάνουμε είναι ο εξής, δημιουργούμε ένα κανάλι δεδομένων στο οποίο αποστέλλουμε πληροφορία κωδικοποιημένη στο subdomain για το οποίο ζητάμε πληροφορίες και λαμβάνουμε πληροφορία κωδικοποιημένη στο TXT πεδίο της DNS απάντησης. Δηλαδή όταν ζητάμε να μάθουμε για το domain jsKsje38.tunnel.foo.gr στην ουσία λέμε στην άλλη μεριά του καναλιού ssh root@1.2.3.4 και η απάντηση μας έρχεται ο DNS πληροφορία κ.ο.κ.

Για να παίξει αυτό θα πρέπει να κάνουμε ρυθμίσεις στο dns server που διαχειρίζεται το domain μας foo.gr, να έχουμε ένα άλλο μηχάνημα που να μην τρέχει DNS για να τρέξουμε τον nstx server που πρέπει να καταλαβαίνει τι του στέλνουμε και να μας απαντά κατάλληλα (έστω ότι έχει την IP 1.2.3.4) και φυσικά να ρυθμίσουμε το nstx client στο laptop.

DNS site:

Έστω ότι έχουμε το domain foo.gr, θα πρέπει να δημιουργήσουμε δύο νέες καταχωρήσεις στο dns server μας τύπου


tunnel.foo.gr. 1 IN NS ntunnel.foo.gr.
ntunnel.foo.gr. 1 IN A 1.2.3.4


Όπου tunnel.foo.gr είναι το domain που θα χρησιμοποιήσουμε ως tunnel για να μεταφέρουμε τα ΤΧΤ δεδομένα μας και πληροφορίες για το domain αυτό θα μας δίνει ο ntunnel.foo.gr nameserver που ακούει στην διεύθυνση 1.2.3.4.

TIP: Για να λειτουργήσει το σύστημα δεν θέλουμε αναγκαστικά δύο μηχανήματα. Μπορούμε να δώσουμε σε μία κάρτα δικτύου δύο διαφορετικά (ή και παραπάνω IP) χρησιμοποιώντας IP aliasing. Φυσικά πρέπει να έχουμε δύο διαφορετικά public IP. Στο παράδειγμά μας έχουμε τα IP 1.2.3.3 (o dns server μας) και το 1.2.3.4 (o nstx server μας).

Server side:

Χρησιμοποιούμε το ip aliasing για να δημιουργήσουμε το interface eth0:1 με την διεύθυνση 1.2.3.4


ifconfig eth0:1 1.2.3.4 netmask 255.255.255.0 up


Κατεβάζουμε το nstx


apt-get install nstx


To nstx χρησιμοποιεί το αρχείο /etc/default/nstx για την ρύθμισή του, αλλά κάτι πήγαινε στραβά με αυτό και το έτρεξα με το χέρι.

Τρέχουμε το nstx server


nstxd -i 1.2.3.4 tunnel.foo.gr


Όπου -i σημαίνει να ακούει μόνο στην διεύθυνση 1.2.3.4 (στην διεύθυνση 1.2.3.3 έχουμε τον πραγματικό DNS) και να επεξεργάζεται δεδομένα του domain tunnel.foo.gr.

Επίσης δημιουργούμε το interface που θα χρησιμοποιήσει το nstx server για να μεταφέρει δεδομένα


modprobe tun
ifconfig tun0 10.0.0.1 netmask 255.0.0.0 up


Τέλος θέλουμε ότι δεδομένα φτάνουν στο tun0 interface (δηλαδή δεδομένα από τον nstx server) να μπορούν να έχουν πρόσβαση στο net, οπότε θα χρησιμοποιήσουμε IP Masquarate για να τα δρομολογήσουμε μέσω του interface eth0 που έχει πρόσβαση στο διαδίκτυο.

Εγκαθιστούμε το iptables και κάνουμε τις κατάλληλες ρυθμίσεις


apt-get install iptables
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
iptables -I FORWARD -j ACCEPT -s 10.0.0.0/8
echo "1" >> /proc/sys/net/ipv4/ip_forward


Συνοψίζουμε: Όποιος ζητήσει πληροφορίες για το domain tunnel.foo.gr θα μάθει ότι ο nameserver του tunnel.foo.gr είναι το ntunnel.foo.gr που ακούει στην διεύθυνση 1.2.3.4. Άρα θα στείλει τον DNS server στην διεύθυνση 1.2.3.4 δηλαδή τον nstx server δεδομένα, τα οποία το nstx τα μεταφράζει σε χρήσιμα δεδομένα και τα δρομολογεί στο interface eth0.

Client side:

Έχουμε συνδεθεί στο δίκτυο και έχουμε IP. Πρέπει να μάθουμε μερικά πράγματα για το δίκτυο που βρισκόμαστε. Πρώτα το IP του dns server που πρέπει να χρησιμοποιούμε. Βρίσκεται στο αρχείο /etc/resolv.conf . Δεύτερον το IP του gateway που έχουμε τώρα.

H καταχώρηση στο route table με flags UG είναι το gateway μας


route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
xx.xx.xx.xx 0.0.0.0 255.255.255.248 UG 0 0 0 eth0


Κατεβάζουμε το nstx (το έχουμε από πριν! θυμάστε ότι δεν έχουμε πρόσβαση εδώ που βρισκόμαστε!)


apt-get install nstx


Και το εκτελούμε


nstxcd tunnel.foo.gr <ip dns server που πρέπει να χρησιμοποιούμε>


Δημιουργούμε το interface για το nstxcd


modprobe tun
ifconfig tun0 up 10.0.0.2 netmask 255.255.255.0


Και τώρα πρέπει να ορίσουμε ως νέο default interface το tun0 και να δρομολογούμε από το παλιό μόνο τις αιτήσεις DNS.


route del defautl
route add default gw 10.0.0.1 tun0
route add -host gw dev eth1


To eth1 είναι το wifi device στο laptop. Σε άλλους μπορεί να είναι wlan.

Voila! Τώρα όλα τα δεδομένα δρομολογούνται μέσω του tun0 μεταφράζονται σε dns queries κ.ο.κ. και εσύ απολαμβάνεις internet access χωρίς να πληρώνεις 10 ευρώ τα 15' λεπτά! (ναι για τέτοιες τιμές μιλάμε!)

Τελικές παρατηρήσεις:

Δεν ξέρω για άλλους χώρους, αλλά στα πλοία η πρόσβαση στο Inet πέρα από πανάκριβη είναι και τόσο ασταθής και αργή που ουσιαστικά δεν μπορεί να χρησιμοποιηθεί. Προσωπικά κατάφερα μερικά ssh connections (για web ούτε για αστείο) χρησιμοποιώντας συμπίεση και ssh version 1 (δεν ξέρω γιατί αλλά έπαιζε καλύτερα από το δύο. μάλλον λιγότερα δεδομένα και αυτές δεν διαρκούσαν παραπάνω από 1-2 εντολές, εάν έφταναν μέχρι εκεί.