Ένα από τα πράγματα που με εκνευρίζουν είναι όταν οι developers ΔΕΝ ξέρουν τι κάνουν.
Και παραθέτω το εξής: η βιβλιοθήκη jpeg έχει φτάσει στην έκδοση 7
Όταν ένας developer θέλει να ελέγξει ή να κάνει χρήση της βιβλιοθήκης τότε απλά πρέπει να προσθέσει το εξής: -ljpeg κατά το compilation.
Οι περισσότερες διανομές έχουν την εξής βιβλιοθήκη: libjpeg ή jpeg-dev ή κάπως έτσι.
Αυτό που χρειαζόμαστε πραγματικά είναι η ύπαρξη της εξής βιβλιοθήκης:
[ebal@myhome:~]€ ldd /usr/lib/libjpeg.so
linux-gate.so.1 => (0xb7fe8000)
libc.so.6 => /lib/libc.so.6 (0xb7e54000)
/lib/ld-linux.so.2 (0xb7fe9000)
η οποία είναι συνήθως (99%) link στην αντίστοιχη έκδοση:
[ebal@myhome:~]€ ls -l /usr/lib/libjpeg.so
lrwxrwxrwx 1 root root 16 2009-06-27 12:54 /usr/lib/libjpeg.so -> libjpeg.so.7.0.0
Τώρα γιατί ΜΑ ΓΙΑΤΙ ένας developer να έχει ορίσει το libjpeg.so.62 με το χέρι στον κώδικά του δεν μπορώ να το καταλάβω?
Το αποτέλεσμα είναι το παρακάτω γελοίο μήνυμα:
error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
Στο παραπάνω πρόβλημα σκέφτηκα τρεις (3) λύσεις :
a. ln -s /usr/lib/libjpeg.so /usr/lib/libjpeg.so.62
b. downgrade σε libjpeg.so.62
c. edit source code και rebuild όλα τα source προγράμματα !
Η έκδοση 7 περιέχει αλλαγές και προσθήκες αλλά όχι αλλαγή αρχιτεκτονικής, η δημιουργία ενός συνδέσμου (επιλογή a) και ένα email στον αρχικό δημιουργό ώστε να τροποποιήσει εκείνος τον κώδικά του σε κάτι πιο ….. σωστό μου φάνηκε ο πιο γρήγορος κι εύκολος τρόπος.
Φυσικά τέτοια προβλήματα είναι το τίμημα όταν έχεις πάντα ένα υβριδικό μοντέλο μίας base διανομής και όλα τα υπόλοιπα να είναι built from scratch
Δυστυχώς ΔΕΝ έχω ακόμα βρει (δεν ξέρω φυσικά εάν θα την βρω και ποτέ) την υπέρτατη τέλεια διανομή.
ΥΓ: το παραπάνω πρόβλημα είναι ένα από τα “κλασικά” όταν κάνεις update ή όταν θέλεις να είσαι bleeding edge (ή κοινός να έχει τόσο ελεύθερο χρόνο ώστε να κάνει το testing σε unstable προγράμματα).
Αρκετές φορές θέλετε να πείτε κάτι πιο εμπιστευτικά σε φίλους ή συνεργάτες που έχετε στο pidgin, όπως για παράδειγμα να “μοιραστείτε” το συνθηματικό του διαχειριστή για έναν απομακρυσμένο διακομιστή (ναι καλά τώρα, σε πίστεψα ότι ΔΕΝ το έχεις κάνει ποτέ).
Εάν όλες οι επικοινωνίες ήταν εξ’ αρχής κρυπτογραφημένες τότε ίσως να ήταν λίγο καλύτερα τα πράγματα.
Η πρόταση (κι αρκετά καλή λύση) είναι να μιλάς Off The Record
Το otr (off-the-record) είναι στην πραγματικότητα ένα library (OTR Messaging Library) και χρειάζεται να εγκατασταθεί πριν το OTR plugin for Pidgin
Ένα καλό παράδειγμα λειτουργίας/επικοινωνίας είναι το εξής
Πρόσθεσα τις εξής λειτουργίες:
- Πλέον το PIrsyncD παρακολουθεί τον πηγαίο κατάλογο για τα εξής events: WRITE,CREATE & DELETE
- Ελέγχει τις ρυθμίσεις κι εάν τις πληρεί θα εκκινήσει.
- Ξεκινάει ένα 1ο rsync κατά την εκτέλεση του προγράμματος.
- ΔΕΝ ξεκινάει το rsync άμεσα, δλδ κατά την ενεργοποίηση ενός event αλλά μετά από μία καθυστέρηση των 5 δευτερολέπτων ώστε να έχει όσο γίνεται το latest state του καταλόγου.
Προβλήμα που θέλω να λύσω:
Ξεκινάει ένα rsync command που διαρκεί για αρκετή ώρα π.χ. 10 λεπτά.
Τα αρχεία που γράφονται στον πηγαίο κατάλογο σε αυτά τα 10 λεπτά δεν αντιγράφονται παρά μόνο στο επόμενο inotify event που θα ενεργοποιήσει τον δαίμονα.
Τέλος, δημιούργησα μία ξεχωριστή σελίδα: PIrsyncD
και πάντα η τελευαία έκδοση του script θα είναι η εξής:
http://balaskas.gr/PIrsyncD/PIrsyncD.tbz2
Κοιτώντας λίγο την λειτουργία του PIrsyncD (Python Inotify Rsync Daemon) διαπίστωσα το εξής πρόβλημα:
Όταν στον πηγαίο κατάλογο γράφονται πάρα πολλά αρχεία κατά την διάρκεια που εκτελεί το rsync process, τότε δημιουργούνται πάρα πολλά rsync threads με αποτέλεσμα να αυξάνει το process and memory usage. Το πρόβλημα αυξάνει όταν το synchronization των καταλόγων γίνεται μέσω δικτύου.
Για να αποφύγω τέτοια προβλήματα σκέφτηκα να δημιουργήσω προσωρινά ένα lockfile το οποίο θα λειτουργεί ως ασπίδα προστασίας. Εάν υπάρχει σημαίνει ότι ακόμα εκτελείτε προηγούμενο rsync proccess. Μόλις ολοκληρωθεί το rsync process διαγράφεται και το temporarily lockfile.
Μπορείτε να κατεβάσετε το πρόγραμμα από εδώ: PIrsyncD_20090713
Παραθέτω τον κώδικα:
#!/usr/bin/env python
# Python Inotify Rsync Daemon
# Evaggelos Balaskas, ebalaskas AT ebalaskas DOT gr
# Last change: Mon Jul 13 12:01:31 EEST 2009
import pyinotify,os
source_path = "/tmp/data/"
dest_path = "/tmp/data2/"
# Variables for rsync to a remote server
dest_server = ""
#dest_server = "server:"
rsync_ssh = ""
# rsync_ssh = "-e ssh"
rsync_path = "/usr/bin/rsync"
rsync_args = "-az --delete"
rsync_command = rsync_path + " " + rsync_args + " " + source_path + " " + rsync_ssh + " " + dest_server + dest_path
# LockFile - failsafe mechanism
lockfile = "/tmp/.PIrsync.lock"
wm = pyinotify.WatchManager()
mask = pyinotify.IN_CLOSE_WRITE
class PTmp(pyinotify.ProcessEvent):
def process_IN_CLOSE_WRITE(self, event):
if not os.path.exists(lockfile):
fd = os.open(lockfile, os.O_RDWR|os.O_EXCL|os.O_CREAT)
os.system(rsync_command)
os.remove(lockfile)
p = PTmp()
notifier = pyinotify.Notifier(wm, p)
wm.add_watch(source_path, mask, rec=True)
notifier.loop(daemonize=True, pid_file='/tmp/PIrsyncD.pid')
Mirroring directories with PIrsynD
Τον τελευταίο καιρό βρέθηκα αντιμέτωπος με το εξής πρόβλημα:
Real time Data Replication over network.
Έπρεπε να υλοποιήσω μία λύση ανάμεσα σε δύο συστήματα που θα λειτουργούν ως Active/Passive. Ξεκίνησα το οδοιπορικό μου, ρωτώντας φίλους και συνεργάτες για το μοντέλο που θα επέλεγαν οι ίδιοι.
Φυσικά και η απλούστερη λύση είναι το rsync, αλλά το rsync θα πρέπει να εκτελείτε από κάποιο δαίμονα (π.χ. crond). Το πρόβλημα εδώ είναι ότι υπάρχει time lug μεταξύ των δύο συστημάτων. Εάν βάλω τον δαίμονα ανά μία ώρα θα έχω μία τεράστια διαφορά των δεδομένων της τάξης μίας ολόκληρης ώρας, κατά την ατυχή περίπτωση failover. Εάν βάλω τον δαίμονα ανά 5 λεπτά υπάρχει περίπτωση να μην προλάβει στα 5 λεπτά να ολοκληρώσει το syncing. Γενικά πρέπει να δημιουργήσεις ένα custom script που θα ελέγχει όλα αυτά κι όχι μπορεί να προκύψουν και φυσικά η διαχειριστική ευθύνη και κόστος αυξάνει αρκετά.
Οι περισσότεροι μου πρότειναν το drbd με την χρήση του υπάρχοντος heartbeat. Απλά απαράδεκτο. Πάρα πολλοί περιορισμοί: Ανάγκη για ξεχωριστό δίσκο (block device), ΔΕΝ κάνει scale up, πολύ δύσχρηστο, αρκετή δουλειά μέχρι να το φέρεις στα μέτρα σου, δουλεύει μόνο ως Server/Client. Με απογοήτευσε αρκετά τολμώ να πω με θάρρος. Είναι όμως kernel module, το οποίο σημαίνει: ταχύτητα και διαφάνεια στον τρόπο που εργάζεται το υπόλοιπο σύστημα στο block device κι όντως έχεις Real time Data Replication
Η επόμενη επιλογή μου ήταν το gluster. Ένα από τα καλύτερα λογισμικά που έχω δει και δουλέψει. Μερικά από τα χαρακτηριστικά του είναι τα εξής: πανεύκολη εγκατάσταση, απλούστατο configuration, εξαιρετικό scale up (no limit πιστεύω), μπορείς να χρησιμοποιήσεις ως distribute filesystem, για replication, για striping, και μπορείς να υλοποιήσεις κάποια μοντέλα raid δια μέσου του δικτύου. Οι δυνατότητες που έχει, πιστεύω ότι μπορούν να καλύψουν τον οποιοδήποτε. Αλλά υλοποιείται με το μοντέλο server/client. Ορίζεις έναν client ο οποίος μπορεί να μιλήσει με n servers. Με δύο συστήματα μόνο ΔΕΝ μπορεί να δουλέψει και φυσικά μόνο όταν όλοι οι clients είναι linux.
Το επόμενο μου λογισμικό προς δοκιμή ήταν το incrond. Κάνει χρήση του inotify όταν αλλάζει ένα αρχείο οπότε με ελάχιστο scripting και λίγο rsync μπορείς να κάνεις αρκετά πράγματα. Αλλά και πάλι υπάρχει το διαχειριστικό κόστος, αρκετό scripting και φυσικά υπάρχει ένα θεματάκι με το recursive στους καταλόγους. Έχει όμως τρομερό documentation κι εάν το έχεις λίγο με τον προγραμματισμό μπορείς να δημιουργήσεις μία αρκετά καλή λύση.
Προσπαθώντας να βρω όντως την τέλεια λύση, στο μυαλό μου ήρθαν τα λόγια του Γιάννη Στοΐλη
- Γιάννη, έχεις δουλέψει ποτέ με κάποιο cluster file system ή κάτι παρόμοιο; Θέλω να βρω μία λύση για real time data replication
- Μπα, κάτι τέτοια τα αφήνω σε εσένα για δοκιμές, εγώ συνεχίζω να παίζω με custom rsync scripts
Τελικά το σκέφτηκα λίγο παραπάνω και μου ήρθε στο μυαλό η εξής εικόνα:
Ξεκίνησα λοιπόν να “ξαναβλέπω” το rsync ίσως με κάποιο inotify feature και voila: lsyncd
Μερικά δευτερόλεπτα μετά κι έτοιμο:
On server1:
lsyncd /data server2:/data
On server2:
lsyncd /data server2:/data
it’s just too simple
Αλλά … unbelievable αργό και buggy. Επίσης υπάρχει κι εδώ ένα θέμα με τo recursive, κρίμα γιατί μου άρεσε πάρα μα πάρα πολύ.
Σε αυτό το σημείο, σκέφτηκα να κάνω ένα βήμα πίσω και να ξαναδώ καλύτερα τις επιλογές μου. Αυτό που θέλω να υλοποιήσω είναι μία απλή και γρήγορη λύση για να συγχρονίζω δύο συστήματα. Στο μυαλό μου τριγύριζε η κουβέντα του Γιάννη: “Εγώ παίζω με custom rsync scripts” και σκέφτηκα: “What the fuck” ας κάνω κι εγώ κάτι τέτοιο. Έπρεπε όμως να βρω μία λύση να το συνδειάσω με το inotify.
Αναζητώντας στο διαδίκτυο για μία καλή υλοποίηση του inotify κατέληξα στο εξής: Pyinotify. Είναι η πιο πλήρης τεκμηριωμένη υλοποίηση του inotify, είναι γραμμένη σε python και έχει εξαιρετικά απλά παραδείγματα. Άρχισα να παίζω με τα παραδείγματα που έχει και να καταλαβαίνω καλύτερα το πως δουλεύει. Ίσως σε αυτό το σημείο να είναι καλό να αναφέρω ότι ΔΕΝ ξέρω python κι ότι ΔΕΝ έχω ξαναγράψει ποτέ κάποιο python script. Ξέρω όμως από προγραμματισμό και λίγο από εδώ - λίγο από εκεί κατέληξα στο εξής script: PIrsyncD!!!
To PIrsyncd σημαίνει: Python Inotify Rsync Daemon και είναι ένα εξαιρετικά απλό python script που τρέχει στο background ως δαίμονας. Ελέγχει συνεχώς έναν source κατάλογο που του έχουμε πει κι όταν γραφτεί κάτι σε αυτόν ή στους υποκαταλόγους του εκτελεί μία rsync εντολή ώστε να συγχρονίσει τους δύο καταλόγους. Το ενδιαφέρον εδώ είναι θα εκτελεστεί ΜΟΝΟ όταν γραφτεί κάτι, και ποτέ άλλοτε.
Παραθέτω τον κώδικα:
#!/usr/bin/env python
# Python Inotify Rsync Daemon
# Evaggelos Balaskas, ebalaskas AT ebalaskas DOT gr
# Last change: Sun Jul 12 22:50:17 EEST 2009
import pyinotify,os
source_path = "/tmp/data/"
dest_path = "/tmp/data2/"
# Variables for rsync to a remote server
dest_server = ""
#dest_server = "server:"
rsync_ssh = ""
# rsync_ssh = "-e ssh"
rsync_path = "/usr/bin/rsync"
rsync_args = "-az --delete"
rsync_command = rsync_path + " " + rsync_args + " " + source_path + " " + rsync_ssh + " " + dest_server + dest_path
wm = pyinotify.WatchManager()
mask = pyinotify.IN_CLOSE_WRITE
class PTmp(pyinotify.ProcessEvent):
def process_IN_CLOSE_WRITE(self, event):
os.system(rsync_command)
p = PTmp()
notifier = pyinotify.Notifier(wm, p)
wm.add_watch(source_path, mask, rec=True)
notifier.loop(daemonize=True, pid_file='/tmp/PIrsyncD.pid')
Η αλήθεια είναι ότι είναι αρκετά buggy και θέλει δουλίτσα, αλλά δουλεύει και μάλιστα αρκετά καλά. Όσοι γνωρίζεται από python στείλτε μου τις παρατηρήσεις σας, είναι μάλιστα καλή ευκαιρία για να μάθω python.
Εάν θέλετε να το δοκιμάσετε τότε χρειάζεται να εγκαταστήσετε και την pyinotify ή μπορείτε να κατεβάσετε το εξής αρχείο: PIrsyncD_20090712
Ολοκλήρωσα αυτές τις μέρες την πλήρη μετάβασή σε όλα τα μηχανήματά μου σε archlinux.
Μπορεί να είναι μόνο 3:
- home desktop
- laptop
- work desktop
Αλλά ειδικά ο υπολογιστής στο γραφείο μου πήρε λίγο παραπάνω χρόνο από όσο περίμενα.
Σκέφτηκα λοιπόν, να τρέξω ένα gtkperf ώστε να ελέγξω εάν όντως είναι ταχύτερο το xfce στο archlinux σε σχέση με το ubuntu.
Ιδού το αποτέλεσμα μου:
GtkPerf 0.40 - Starting testing: Thu Jul 9 08:52:58 2009
GtkEntry - time: 0,00
GtkComboBox - time: 0,82
GtkComboBoxEntry - time: 0,68
GtkSpinButton - time: 0,09
GtkProgressBar - time: 0,04
GtkToggleButton - time: 0,05
GtkCheckButton - time: 0,05
GtkRadioButton - time: 0,10
GtkTextView - Add text - time: 0,54
GtkTextView - Scroll - time: 0,09
GtkDrawingArea - Lines - time: 0,51
GtkDrawingArea - Circles - time: 0,90
GtkDrawingArea - Text - time: 0,70
GtkDrawingArea - Pixbufs - time: 0,14
—
Total time: 4,71
Και μάλιστα το xfce είναι εγκατεστημένο από subversion (δλδ είναι unstable και αρκετά buggy)
[ebal@mywork ~] € xfwm4 –version
This is xfwm4 version 4.7.0svn.r30079 (revision 30079) for Xfce 4.7.0
4.71 πιστεύω ότι αποτελεί μία αρκετά καλή & γρήγορη επίδοση
Η παλαιότερη μέτρησή μου ήταν κοντά στο 6, see my old post
Σήμερα προχώρησα με την αναβάθμιση του firefox στην έκδοση 3.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Μέχρι στιγμής φαίνονται όλα καλά, τόσο με την ταχύτητα όσο και με την απόδοση του συστήματός
Και σε ποιον δεν έχει τύχει να διαγράψει κατά λάθος ένα αρχείο.
Εάν όμως υπάρχει κάποια διεργασία που έχει “δεσμεύει” το αρχείο μας,
υπάρχουν αρκετές πιθανότητες να το ανακτήσουμε με την χρήση της lsof.
Η lsof μας δείχνει ποια είναι τα ανοιχτά αρχεία, δλδ τα αρχεία που αυτή την στιγμή έχουν “δεσμεύει οι διεργασίες του υπολογιστή μας.
Παραθέτω ένα πλήρες κι εύκολο παράδειγμα:
dmesg > dmesg.log
less dmesg.log
Ελέγχουμε το μέγεθος αλλά και το hash του αρχείου μέσω της md5sum για να πιστοποιήσουμε την ακεραιότητα παρακάτω:
ebal@myhome: € ls -l dmesg.log
-rw-r–r– 1 ebal ebal 28944 2009-07-02 21:46 dmesg.logebal@myhome: € md5sum dmesg.log
f8b02bca5b25244e71ada077a439a4cf dmesg.log
Διαγράφουμε το αρχείο, προσοχή το less που τρέχουμε παραπάνω είναι σε άλλο παράθυρο/τερματικό
ebal@myhome: € rm -f dmesg.log
ebal@myhome: € ls -l dmesg.log
ls: cannot access dmesg.log: Δεν υπάρχει τέτοιο αρχείο ή κατάλογος
Βλέπουμε εάν είναι “ανοιχτό” από κάποια άλλη διεργασία, περιμένουμε να δούμε την less
ebal@myhome: € lsof | grep dmesg.log
less 5412 ebal 4r REG 8,3 28944 6922 /tmp/dmesg.log (deleted)
Στην δεύτερη στήλη, ο αριθμός αυτός δηλώνει τον αριθμό της διεργασίας μας.
Κάθε φορά είναι διαφορετικός και σε κάθεναν θα είναι επίσης διαφορετικός.
Κάνοντας χρήση αυτού του αριθμού μέσω από το ψευδοαρχείο συστημάτων μας
μπορούμε να ανακτήσουμε το αρχείο που μόλις διαγράψαμε:
ebal@myhome: € cp /proc/5412/fd/4 /tmp/dmesg.log
Πριν συνεχίσουμε, μερικές πληροφορίες.
/proc : ο κατάλογος στον οποίο καταγράφουν όλες οι διεργασίες προσωρινά πληροφορίες
5412: o αριθμός διεργασίας της less
fd : file descriptor, εάν έχουν ανοιχτεί αρχεία
4 : Συνήθως είναι το αρχείο, με την εντολή ls -l στον κατάλογο /proc/5412/fd/4 το επιβεβαιώνουμε
Περισσότερα για το proc filesystem μπορείτε να διαβάσετε εδώ
Κι ελέγχουμε εκ νέου το μέγεθος και την ακεραιότητα του αρχείου μας.
ebal@myhome: € ls -l dmesg.log
-rw-r–r– 1 ebal ebal 28944 2009-07-02 21:54 dmesg.log
ebal@myhome: € md5sum dmesg.log
f8b02bca5b25244e71ada077a439a4cf dmesg.log
Οπότε την επόμενη φορά που θα διαγράψουμε ένα αρχείο, ρίχνουμε μια ματιά στην lsof.
Αρχική πηγή: linuxplanet
Τις τελευταίες ημέρες και καθώς προσπαθώ και ολοκληρώσω και το migration στο pc της δουλειάς σε archlinux αντιμετώπισα το εξής πρόβλημα:
Στο archlinux αναβάθμισαν τον πυρήνα σε 2.6.30
Ok παίδες βγήκε στις 10/06/2009 ως stable αλλά για κρατήστε τα άλογά σας λίγο (hold your horses).
Όταν οι περισσότερες εφαρμογές στηρίζονται σε προηγούμενες εκδόσεις του kernel και δεν έχουν προλάβει να κάνουν τις απαραίτητες διορθώσεις στον κώδικα τους, είναι εξαιρετικά unsafe να κάνεις upgrade τον kernel.
Είναι αντιπαραγωγικό να διορθώνει κάποιος με το χέρι τον κώδικα εφαρμογών, ή να περνάει diffs & patches από την development version ενός προγράμματος, επειδή η stable δεν παίζει πλέον.
Σε προσπάθεια να αναβαθμίσω την διανομή μου, διαπίστωσα κάποιο πρόβλημα με το πακέτο Virtualbox. Για να επιλύσω το σφάλμα των εξαρτήσεων θεώρησα καλή επιλογή να απεγκαταστήσω το Virtualbox και να προσπαθήσω να το επανεγκαταστήσω αργότερα. Δοκίμαζοντας αυτή την λύση προχώρησα με την αναβάθμιση της διανομής χωρίς κανένα πρόβλημα.
ebal@mylaptop:~ € sudo pacman -Syu
:: Synchronizing package databases…
core is up to date
extra is up to date
community 366,2K 212,3K/s 00:00:02 [#####################] 100%
:: Starting full system upgrade…
local database is up to date
Έπειτα προσπάθησα να επαναεγκαταστήσω το Virtualbox:
ebal@mylaptop:~ € sudo pacman -S community/virtualbox-ose
resolving dependencies…
error: cannot resolve “kernel26>=2.6.30”, a dependency of “virtualbox-modules”
error: failed to prepare transaction (could not satisfy dependencies)
:: virtualbox-modules: requires kernel26>=2.6.30
Σκέφτηκα να κοιτάξω στο forum του archlinux, μήπως βρω κάτι σχετικό.
Στο 1ο post που βρήκα, διαβάσα ότι έχει γίνει κάποιο λάθος κι ότι θα έπρεπε να αναβαθμίζω την διανομή μου με την εξής εντολή:
pacman -Syu –ignore virtualbox-modules
Δυστυχώς μία από τις κακές μου συνήθειες είναι και η εξής: shoot first, ask questions later.
Στην παραπάνω περίπτωση λοιπόν, πρώτα αφαίρεσα το virtualbox για να λύσω το πρόβλημα του upgrade κι έπειτα αναζήτησα για την λύση του error.
Με αφορμή το παραπάνω, σκέφτηκα ότι θα ήταν μία καλή περίπτωση να δοκιμάσω να εγκαταστήσω το virtualbox από το site της oracle: http://www.virtualbox.org
Σε αυτόν τον σύνδεσμο: Linux_Downloads
έχει μία λίστα με διανομές. Επέλεξα το All distributions
Kατέβασα στον υπολογιστή μου το αρχείο: VirtualBox-2.2.4
Εγκατάσταση:
Επιβεβαιώνω την ακεραιότητα του αρχείο σύμφωνα με τον εξής σύνδεσμο:MD5SUMS
ebal@mylaptop:~ € md5sum VirtualBox-2.2.4-47978-Linux_x86.run
cc24c081e53d03da1c009dc1a2eaa95d VirtualBox-2.2.4-47978-Linux_x86.run
Και δίνω το δικαίωμα εκτέλεσης, στον χρήστη που ανήκει:
ebal@mylaptop:~ € chmod u+x VirtualBox-2.2.4-47978-Linux_x86.run
Ξεκινώ την εγκατάσταση:
ebal@mylaptop:~ € sudo ./VirtualBox-2.2.4-47978-Linux_x86.run
Verifying archive integrity… All good.
Uncompressing VirtualBox for Linux installation……..
VirtualBox Version 2.2.4 (2009-05-29T17:23:26Z) installer
Installing VirtualBox to /opt/VirtualBox
tar: Record size = 8 blocks
Building the VirtualBox kernel module
Building the VirtualBox netflt kernel moduleVirtualBox has been installed successfully.
You will find useful information about using VirtualBox in the user manual
/opt/VirtualBox/UserManual.pdf
and in the user FAQ
http://www.virtualbox.org/wiki/User_FAQWe hope that you enjoy using VirtualBox.
Η εντύπωση που αποκόμισα μέχρι αυτό το σημείο ήταν: Πανεύκολη εγκατάσταση!
Εκτέλεση
Χωρίς να χρειαστεί κάποια επανεκκίνηση πληκτρολογώ την ακόλουθη εντολή:
ebal@mylaptop:~ € /opt/VirtualBox/VirtualBox
Και το αποτέλεσμα:
Όλα πήγαν εξαιρετικά λοιπόν.
Έχοντας κατά καιρούς προβλήματα με το ρεύμα στο σπίτι
αποφάσισα να προμηθευτώ με το εξής: Power Must 1400 USB P
Είχα την δυνατότητα να επιλέξω να το συνδέσω είτε μέσω RS-232 είτε μέσω USB,
μιας και τα usb είναι σχεδόν πάντα κατηλλημένα σκέφτηκα να βάλω το RS-232
To CD που παρέχετε μαζί με το PowerMust είναι υπερπλήρης !!!
- AIX
- FreeBSD
- GenericUnix
- HPUX
- Linux
- LinuxAMD64
- MacOSX
- Martrix usb driver for windows
- Quick Installation and Setup.pdf
- Solaris
- WinPower V2.5.0.3 manual.pdf
- Windows
Παρόλα αυτά σκέφτηκα να ρίξω μια ματιά στο site της Mustek: http://www.mustek.de/
και βλέπω γλώσσα Ελληνικά!!! Εάν και δεν έχει πολλές πληροφορίες στα ελληνικά
είναι από τις ελάχιστες φορές που βλέπω ένα τέτοιο site να έχει ελληνική σελίδα
έστω και για τους διανομείς.
Για να μην το πολυκουράζουμε το θέμα, βρίσκω την σελίδα με τους drivers
και κατεβάζω το εξής:
Χρειάζεται να υπάρχει jre (java runtime) και libxp (τουλάχιστον σε εμένα)
Η εγκατάσταση (ως διαχειριστές):
tar zxvf Winpower_setup_Linux.tar.gz
cd Winpower_setup_Linux/Linux/./setup.bin
Αφού ακολουθήσουμε την πανεύκολη διαδικασία της εγκατάστασης παρατηρούμε ότι η εγκατάσταση
έχει γίνει στον κατάλογο: /opt/upspilot/
Εάν κάνουμε επανεκκίνηση τότε θα πρέπει να δούμε να εκτελείτε το πρόγραμμα: S99Winpower
εάν όχι τότε πρέπει να κάνουμε τις απαραίτητες ενέργειες εμείς ώστε να ξεκινάει κατά
την εκκίνηση του υπολογιστή μας.
Εάν μέχρι εδώ πάνε όλα καλά (και γιατί να μην πάνε δλδ) τότε είμαστε έτοιμοι να
τρέξουμε το monitor πρόγραμμα:
(ως διαχειριστής)
cd /opt/upspilot/
./monitor
και θα ξεκινήσει το πρόγραμμά μας
Και τώρα το δύσκολο μέρος:
Από το menu: Act as Administrator
πληκτρολογούμε το προκαθορισμένο συνθηματικό: Administrator
(προσοχή είναι case sensitive)
Auto Search UPS
κι εάν αυτό δεν παίξει σωστά: COM Port Setting –> /dev/ttyS0 –> OK
Εάν όλα πάνε καλά θα δούμε κάτι σαν κι αυτό:
Και πάνω που ολοκλήρωσα το migration στο laptop σε archlinux,
διαπίστωσα ότι έχει ανοιχτεί επίσημα και η πρόσβαση στο mirror της otenet:
http://ftp.otenet.gr/linux/archlinux/
ftp://ftp.otenet.gr/linux/archlinux/
Αλλάζω το /etc/pacman.d/mirrorlist
ebal@mylaptop:~€ egrep -v ‘^#|^$’ /etc/pacman.d/mirrorlist
Server = ftp://ftp.otenet.gr/pub/linux/archlinux/$repo/os/i686
Και με την παραπάνω εντολή βλέπουμε ότι είμαστε οκ με την αναβάθμιση.
ebal@mylaptop:~# pacman -Syu
:: Synchronizing package databases…
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade…
local database is up to date
από ότι έμαθα το mirror στην otenet θα είναι ανά 8ώρο
Linux & WPA2
Έστω ότι βρισκόμαστε σε ένα ασύρματο δίκτυο όπου το κλειδί είναι σε WPA2 τι κάνουμε;
και φτάνεις σε αυτό το σημείο:
Passphrase is currently not supported
Άρα εάν δεν έχεις καλώδιο τι κάνεις οεο;
Γυρνάς σε MS Windows; όχιιιιιιιι υπάρχει λύση βρε κουτό: wpasupplicant
RTFM το wpasupplicant
Χρειαζόμαστε το αποτέλεσμα της εξής εντολής:
$ wpa_passphrase
usage: wpa_passphrase <ssid> [passphrase]
Έστω λοιπόν ότι το ssid μας είναι το εξής: myssid
και το συνθηματικό μας (passphrase): testtest
$ wpa_passphrase myssid testtest
network={
ssid="myssid"
#psk="testtest"
psk=520551d66108e15f8fcc6cac00e33b19e0f53fcb8af3d45b705ffdf20eb0524f
}
Αποθηκεύουμε το αποτέλεσμα σε ένα αρχείο:
$ wpa_passphrase myssid testtest > /etc/network/myssid.wpa2
Οπότε είμαστε έτοιμοι να απολαύσουμε το ασύρματο δίκτυο μας.
Εάν συνδεόμαστε με dhcp:
$ cat /etc/network/interfaces
auto lo wlan0
iface lo inet loopbackiface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/network/myssid.wpa2
Εάν πάλι συνδεόμαστε με στατική IP:
$ cat /etc/network/interfaces
auto lo wlan0
iface lo inet loopbackiface wlan0 inet static
address 192.168.2.131
netmask 255.255.255.0
gateway 192.168.2.1wpa-driver wext
wpa-conf /etc/network/myssid.wpa2
Ελπίζω να βοηθήσω λιγάκι να γλιτώσετε χρόνο :)
Hal & Devices
Όταν ήθελες να προσαρτήσεις μία συσκευή (κάποτε) έπρεπε να επεξεργαστείς το fstab κατάλληλα.
Αυτό γινόταν είτε με το χέρι, είτε μέσω ενός gui interface.
Μάλιστα όταν έπρεπε να συνδέσεις μία usb συσκευή έπρεπε να την βρεις πρώτα.
Πλέον με το hal & το dbus γίνονται όλα αυτόματα, αρκεί να ακολουθήσεις όμως κάποιους κανόνες.
Για αρχή χρειάζεται να ρίξουμε μια ματιά στα παρακάτω links:
Από το 1ο link βλέπουμε ότι μπορούμε να ορίσουμε την πολιτική για τους χρήστες μας.
Αυτό γίνεται στο εξής αρχείο:
/etc/PolicyKit/PolicyKit.conf
Για παράδειγμα το δικό μου PolicyKit.conf είναι το εξής:
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->
<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">
<config version="0.1">
<match user="ebal">
<match action="org.freedesktop.hal.storage.*">
<return result="yes"/>
</match>
<match action="hal-storage-mount-fixed-extra-options">
<return result="yes" />
</match>
<match action="hal-storage-mount-removable-extra-options">
<return result="yes" />
</match>
<match action="org.freedesktop.hal.power-management.*">
<return result="yes"/>
</match>
</match>
</config>
ΠΡΟΣΟΧΗ: Το δικό μου username είναι ebal, στο δικό σας παράδειγμα μπορεί να είναι κάτι άλλο.
Στο παραπάνω παράδειγμα υπάρχουν οι εξής δηλώσεις:
<match action=”org.freedesktop.hal.storage.*”>
<return result=”yes”/>
</match>
και
<match action=”org.freedesktop.hal.power-management.*”>
<return result=”yes”/>
</match>
Το πρώτο παράδειγμα επιτρέπει οποιαδήποτε ενέργεια σε ότι αφορά τους δίσκους (storage),
ενώ το δεύτερο παράδειγμα επιτρέπει οποιαδήποτε ενέργεια έχει να κάνει με την διαχείριση
του ρεύματος (π.χ. reboot ή shutdown)
Χρειάζεται να επιβεβαιώσουμε την ακεραιότητα του αρχείου, οπότε χρειάζεται να πληκτρολογήσουμε την εξής εντολή:
polkit-config-file-validateΧρήσιμες και ενδιαφέρουσες πληροφορίες για τις συσκευές μας μπορούμε να δούμε με την εξής εντολή:
lshalΦυσικά όταν ολοκληρώσουμε όλα τα παραπάνω χρειάζεται να επανεκιννήσουμε το dbus & hal
/etc/rc.d/dbus restart
/etc/rc.d/hal restart
Εάν μία διανομή σου έχει τα πάντα στο αυτόματο (δες ubuntu ή fedora) τότε καμιά φορά ξεκινάς από την αρχή όταν θέλεις να ρυθμίσεις κάτι με το χέρι. Έτσι λοιπόν ασχολήθηκα εχθές το απόγευμα και σήμερα, μαθαίνοντας και ρυθμίζοντας με το χέρι το Xorg και πως πραγματοποιείτε η εναλλαγή γλώσσας στο πληκτρολόγιο μέσω του hal.
Η πρώτη (και εύκολη) εργασία είχε λοιπόν ως σκοπό να δημιουργήσω και να ρυθμίσω κατάλληλα το xorg.conf. Αρκετά εντυπωσιακό το γεγονός ότι στο archlinux ΔΕΝ χρειάζεται να έχεις όντως αρχείο, αφού έχει την δυνατότητα να παράγει ένα generic on-the-fly όποτε τρέχεις startx και διαρκεί για την συνεδρία σου. Φυσικά όταν θέλεις να διορθώσεις κάποια πράγματα όπως η ανάλυση χρειάζεται να το κάνεις με το χέρι.
Σε αυτό το link: xorg κατέγραψα την προσπάθειά μου.
Η δεύτερη (και πιο δύσκολη) εργασία ήταν να προσθέσω την δυνατότητα της εναλλαγής γλώσσας για το πληκτρολόγιο μου. Στο archlinux και με την έκδοση 1.6.1 του xorg διαπίστωσα κάποιο πρόβλημα/bug όπου όταν απενεργοποιούσα το input hotplugging από το xorg μου, “κόλλαγε” η οθόνη μου. Οπότε αφιέρωσα κάμποσο χρόνο ώστε να κατανοήσω πλήρως την λειτουργία του Xorg - του hal - του dbus και κατέληξα σε ένα (πλήρης θέλω να φαντάζομαι) οδηγό για την εναλλαγή γλώσσας, ο οποίος βρίσκεται εδώ: Greek
Θα χαρώ πολύ να λάβω παρατηρήσεις για τον παραπάνω οδηγό.
Πως να αποφύγετε προβλήματα με το eshop.
Πολύ απλά ΔΕΝ αγοράζεις, είναι το δημοφιλέστερο online κατάστημα
και με την χειρότερη εξυπηρέτηση/πολιτική που υπάρχει.
Δευτέρα 04.05.2009 μετά τις 19.00 έκανα μία παραγγελία για μία τηλεόραση: SAMSUNG LE32B450 32 LCD
Τρίτη 05.05.2009 γύρω στις 12.00 μου την έχουν φέρει στην δουλειά. Πληρώνω μετρητά.
Πηγαίνω στο σπίτι το απόγευμα και την δοκιμάζω τοποθετώντας την εξωτερική κεραία που έχω ήδη σε άλλη τηλεόρασή. Αναζητώ για αναλογικά κανάλια, τα αποθηκεύει στις μνήμες του και ξεκινάω να δω
την ποιότητα.
ΠΟΙΑ ποιότητα;
ΠΟΙΑ κανάλια;
Η ευκρίνεια να τρεμοπαίζει και η εικόνα να είναι άθλια, όπως επίσης στο 95% των καναλιών δείχνει με χιόνια. Δοκιμάζω χειροκίνητη αναζήτηση, το ίδιο.
Τετάρτη 06.05.2009 επιστρέφω την τηλεόραση στο κατάστημα του Χαλανδρίου και ενημερώνω τον υπεύθυνο για την ποιότητα των καναλιών/ευκρίνεια κ.λ.π.
Σάββατο 09.05.2009 δέχομαι μήνυμα από το τμήμα Service όπου με ενημερώνει ότι η τηλεόραση δεν παρουσίασε κανένα πρόβλημα.
Την ίδια μέρα, προς το μεσημέρι δέχομαι μήνυμα να πάω να την παραλάβω από το Χαλάνδρι.
Δευτέρα 11.05.2009 μεταβαίνω στο κατάστημα του Χαλανδρίου, και μιλάω με τον υπεύθυνο.
Του εξηγώ τι έχει συμβεί και ζητάω τα χρήματά μου πίσω καθώς η τηλεόραση είτε είναι χαλασμένη
είτε δεν με ικανοποιείς καθώς δεν δείχνει καθόλου καλά.
Από τότε ξεκινάει ο γολγοθάς μου, τηλέφωνα/μηνύματα τπτ. Δεν μπορώ να βγάλω άκρη.
Έδωσα 420 ευρώ και δεν έχω το προϊόν.
Την Δευτέρα 25.05.2009 με ενημερώνουν ότι ΔΕΝ μου δίνουν τα χρήματα μου πίσω, ΔΕΝ γίνεται δεκτή η τηλεόραση.
Τους εξηγώ εκ νέου ότι η τηλεόραση ΔΕΝ παίζει και θέλω να γίνει ο έλεγχος μπροστά μου.
Κλείνουμε το ραντεβού για σήμερα 28.05.2009 (23 ημέρες μετά !!!) και παρουσιάζομαι στο κατάστημα του Μενιδίου.
Βάζουν την τηλεόραση σε μία εξωτερική κεραία και VOILA δεν παίζει τπτ. Πιάνει τα κανάλια αλλά είναι χάλια σε ποιότητα κ.λ.π.
Αφού εξηγώ στον τεχνικό πως να την δοκιμάσει εκ νέου διαπιστώνει ότι όντως η τηλεόραση ΔΕΝ παίζει σωστά.
Με ενημερώνει ότι θα αντικατασταθεί άμεσα με νέα τηλεόραση. Μιλάμε τον πωλητή για την αντικατάσταση ότι ΔΕΝ
με ενδιαφέρει άλλη τηλεόραση και πολύ φοβάμαι ότι επίσης ΔΕΝ θα παίζει σωστά ή θα έχω προβλήματα.
Με τα πολλά κατάφερα να μου στείλουν ένα μήνυμα για να μου πιστώσουν τα 420ευρώ κι όχι για την επιστροφή των χρημάτων μου.
Γιατί δλδ να πρέπει να τους ξαναδώσω τα χρήματά μου; Γιατί δεν μπορώ να τα πάρω πίσω;
Με όσους υπάλληλους μίλησα από το eshop ήταν ευγενέστατοι και εξυπηρετικοί.
Τα συμπεράσματά μου λοιπόν:
α. Δεν πρόκειται να αγοράσω ξανά από το eshop (δυστυχώς θα πρέπει να εξαντλήσω τα 420 ευρώ που έχω ως πιστωτικό)
β. Στις 09.05.2009 το τμήμα service ΔΕΝ διαπίστωσε πρόβλημα, αλλά στις 28.05.2009 παρουσία μου, διαπιστώνει πρόβλημα (αυτό το αφήνω προς προβληματισμό σας)
ΥΓ: Παρακαλώ την ανέχεια σας για την χρήση του πλανήτη για την δημοσίευση αυτού του post
Εάν και για τα screenshots χρησιμοποίησα ένα virtualbox, η διαδικασία που ακολούθησα και στο desktop μου είναι ακριβώς η ίδια.
Προς το παρόν όλα τα screenshots σε ένα album (αναλυτικά όλα τα βήματα)
Arch Linux - Installation Guide
και μόλις βρω λίγο χρόνο θα γράψω και ένα super αναλυτικό wiki βασισμένο στα screenshots ως οδηγό εγκατάστασης
Arch Linux aka boot in 12sec
Υπάρχουν 2 iso που μπορεί κάποιος να κατεβάσει:
α. core: το οποίο περιέχει και τα πακέτα (330MB), αποτελεί το base system του arch linux
β. ftp: το οποίο ΘΑ κατεβάσει τα latest πακέτα από τον mirror που έχεις επιλέξει. (148MB)
Μιας και έχω dsl αποφάσισα να κατεβάσω την έκδοση ftp.
Βρήκα mirror στο ntua και από το εξής url:
ftp://ftp.ntua.gr/pub/linux/archlinux/iso/latest/
κατέβασα το εξής iso: archlinux-2009.02-ftp-i686.iso
Το έκαψα σε ένα cd, επανεκκίνησα τον υπολογιστή μου και επέλεξα το boot από το cdrom. Η διαδικασία της εγκατάστασης αρκετά εύκολη. Δεν επέλεξα τπτ άλλο παρά να εγκαταστήσω μόνο το core (base system) του arch linux. Μερικά λεπτά αργότερα λοιπόν είχα έτοιμο τον υπολογιστή μου με την νέα μου διανομή.
Κάνω μια επανεκκίνηση και μέχρι να τακτοποιήσω λίγο το πληκτρολόγιο/ποντίκι/οθόνη στο γραφείο boot-αρε. Σκέφτηκα κάτι δεν πήγε καλά, ξανακάνω reboot και το χρονομετράω: 12 sec login screen.
Μερικές παρατηρήσεις:
Α. Η πρώτη εντολή θα πρέπει να είναι η εξής:
pacman -Sy
ώστε να ενημερωθεί η βάση των πακέτων ώστε να περιέχει και τα repositories πέρα του core.
Β. Η δεύτερη εντολή θα πρέπει να είναι:
pacman -S xfce4
Ευελπιστώ στις επόμενες μέρες να καταγράψω αναλυτικά την εγκατάσταση του arch με screenshots
όπως επίσης και πιο αναλυτικά blog posts γύρω από το arch.
Ένα λάθος script την λάθος ώρα, όπου κάπου ανάμεσα στις γραμμές τους έχει:
\rm -rf /usr
Φυσικά μετά το αποτέλεσμα, ένα χαμόγελο σχηματίστηκε στα χείλη μου.
Μιας και δεν έχω χάσει δεδομένα η πρώτη σκέψη μου ήταν η εξής:
“Ευκαιρία να βάλω fedora - και μετά σχεδόν άμεσα: Μα τι λέω, … ευκαιρία να βάλω arch”
Συμβουλή:
# mv /bin/rm /bin/rm.bakΈνα από τα πιο αγαπημένα μου προγράμματα είναι το screen. Εάν και είναι γνωστό κυρίως για δύο πράγματα:
α. Μπορείς να ανοίξεις πολλαπλές οθόνες κάνοντας χρήση ενός τερματικού &
β. Να συνεχίσει να τρέχει ένα απομακρυσμένο πρόγραμμα - ακόμα κι εάν χαθεί το δίκτυο.
Μπορείς έπειτα να ξανακαλέσεις το screen και να σου φέρει πάλι τις οθόνες που
χρησιμοποιούσες στο απομακρυσμένο μηχάνημα.
Το screen όμως δεν κάνει μόνο αυτά. Το manual από την άλλη είναι πληρέστατο και ευανάγνωστο.
Μία από τις εντολές που κάθε φορά ψάχνω να θυμηθώ είναι η hardstatus. Με αυτή την εντολή ορίζεις
στην τελευταία γραμμή να εμφανίζονται κάποιες πληροφορίες ώστε με μια ματιά να ξέρεις τι γίνεται.
Προσωπικά είμαι minimalistic τύπος οπότε το δικό μου είναι κάπως έτσι (μέσα από το screen πληκτρολογούμε μαζί Ctrl+a+: )
hardstatus alwayslastline “%w %d-%m-%Y %c”
Πάντως ένας πολύ ωραίο post για το πως να αλλάξεις το περιεχόμενο της τελευταίας γραμμής βρίσκεται εδώ
Ένα mini how to για το screen μπορείτε να βρείτε κι εδώ: mini screen howto