Τον τελευταίο καιρό προσπαθώ να θυμηθώ βασικές αρχές προγραμματισμού από τον καιρό που ήμουν φοιτητής. Δεν θεωρώ τον εαυτό του σε καμία περίπτωση προγραμματιστή. Μάλιστα οι κόποι μου αποτελούν μικρά patches (diffs) στην δουλειά που κάνουν ήδη άλλοι (hacks) και πιο ειδικά στο xfce.
Όμως απογοητεύτηκα αρκετά από τους προγραμματιστές της isc. Προσπαθώντας να εγκαταστήσω ένα dhcp server για τις ανάγκες ενός μικρού lan από τον πηγαίο κώδικα, διαπίστωσα ότι κατά το compilation που επέστρεφε ένα όχι και τόσο συνηθισμένο σφάλμα:
packet.c:139: error: ‘ip’ is used uninitialized in this function
Οκ προφανώς κάτι μου λείπει;
Αυτό δεν σκέφτεστε όλοι;
Κι όμως ….
Η έκδοση που χρησιμοποιώ είναι η current stable: DHCP 4.1.0p1 και μετά από αρκετό διάβασμα του κώδικα τελικά κατάφερα να βρω γιατί επιστρέφει το συγκεκριμένο μήνυμα.
Ο dhcp προσπαθεί by-default να υποστηρίξει IPV6. Οκ μέχρι εδώ όλα καλά.
Δυστυχώς όμως οι προγραμματιστές ΔΕΝ έχουν βάλει ένα IF-THEN-ELSE κατά την περίπτωση που το linux-box ΔΕΝ έχει ipv6!!! και για αυτό “σκάει” το compilation με το παραπάνω μήνυμα.
Η λύση είναι εξαιρετικά απλή: Πρέπει να απενεργοποιηθεί η υποστήριξη για IPV6
./configure --disable-dhcpv6; make; make installΑλλά μέχρι να το βρεις από ξυρισμένος κόντρα, καταλήγεις σαν τον stallman
Κατά καιρούς (και μέχρι να μάθω από regular expressions) ένα από τα προβλήματα που με έχει ταλαιπωρήσει αρκετά ήταν το εξής:
Ήθελα σε άπειρα εις το τετράγωνο αρχεία που βρίσκονται κάτω από άπειρους καταλόγους να τροποποιήσω ένα και μόνο αλφαριθμητικό. Στο google θα βρείτε αρκετά προγράμματα κ.λ.π. - κ.λ.π., αλλά μπορεί να γίνει πανεύκολα με μία και μόνο εντολή:
find ΑΡΧΙΚΟΣ_ΚΑΤΑΛΟΓΟΣ -type f -name “ΤΟ ΜΟΤΙΒΟ ΤΩΝ ΑΡΧΕΙΩΝ” -exec sed -r -i ’s/ΑΛΦΑΡΙΘΜΗΤΙΚΟ/ΤΟ_ΝΕΟ_ΑΛΦΑΡΙΘΜΗΤΙΚΟ’ {} \;
και δίνω ένα παράδειγμα για να γίνω πιο κατανοητός:
find /www -type f -name "*.php" -exec sed -r -i 's/ebal/Evaggelos Balaskas/' {} \;
Εάν για παράδειγμα θέλετε να αντικαταστήσετε παραπάνω από ένα αλφαριθμητικό τότε μπορεί κανείς να χρησιμοποιήσει κάτι τέτοιο (έστω ότι θέλω να αλλάξω τις λέξεις ebal ή ebalaskas με το Evaggelos Balaskas):
find /www -type f -name "*.php" -exec sed -r -i 's/(ebal|ebalaskas)/Evaggelos Balaskas/' {} \;
ΥΓ: Την 1η φορά που κατάφερα να κάνω μία υπερβολικά περίπλοκη εργασία σε μερικά δευτερόλεπτα ένιωσα έτσι: i know regular expressions !!!
Στις 30 Αυγούστου 2009 ο David Rosal, δημοσίευσε την νέα έκδοση του paco: 2.0.7.
Αυτή η έκδοση δεν έχει να προσθέσει νέα χαρακτηριστικά, αλλά να βελτιστοποιήσει κυρίως το gpaco (gtk based GUI)
Βρήκα όμως σήμερα την αφορμή για να το εγκαταστήσω εκ νέου και να κάνω ένα review στο Paco Mini How To που διατηρώ για το paco (και έχει προσθέσει στα links και ο David στο project - είναι αυτό με την ελληνική σημαία: http://paco.sourceforge.net/doc.html)
Διαβάζοντας λοιπόν το man 8 paco, πρόσεξα το εξής option:
-o, --configure-optionsτο οποίο μου είχε διαφύγει στο παρελθόν. Μπορείς να δεις με τι options είχες εγκαταστήσει ένα πρόγραμμα:
paco -o pidgin
–disable-screensaver –disable-vv –disable-meanwhile –disable-nm –disable-tcl
Πολύ εντυπωσιακό έτσι;
Επίσης στα scripts, πρόσθεσε και ένα αρχείο για bash_completion.d:
cp scripts/paco_bash_completion /etc/bash_completion.d/pacoΓια όσους ασχολούνται με source compilation ας μην το προσπεράσουν.
Το paco είναι από τα καλύτερα προγράμματα που έχω δουλέψει κι ελπίζω το παραπάνω mini how to που έχω γράψει να σας βοηθήσει.
Σε προηγούμενο μου post είχα αναφέρει κάποια ενδιαφέροντα δρώμενα που συμβαίνουν γύρω από το xfce.
Πλέον η μεταφορά όλων των έργων σε git έχει ολοκληρωθεί, και πολύ σημαντικό είναι ότι ολοκληρώθηκε και η εγκατάσταση ενός instance του transifex για την διαδικασία των μεταφράσεων.
Τα στατιστικά μας για τα κύρια προγράμματα είναι τα εξής:
Xfce: 78% (2007/27/537)
Applications: 65% (2435/159/1151)
Panel Plugins: 42% (601/31/784)
Thunar Plugins: 19% (62/0/262)
Οι δύο (2) συνήθεις ύποπτοι είναι οι εξής:
Σταύρος Γιαννούρης κι εγώ (Ευάγγελος Μπαλάσκας).
Κατά την προσωπική μου άποψη χρειαζόμαστε τουλάχιστον τέσσερα (4) actions που πρέπει να γίνουν και σχετικά γρήγορα.
a. QA στις μεταφράσεις που έχουμε ανεβάσει (θέλει πολύ δουλίτσα αυτό)
b. Φυσικά να 100% τουλάχιστον το xfce (δεν είναι ΠΑΡΑ πολύ δύσκολο αυτό)
c. Να βρούμε ανθρώπους που χρησιμοποιούν το xfce στα ελληνικά και να μας προτείνουν διορθώσεις
d. Να βρούμε ανθρώπους που θα βοηθήσουν στις μεταφράσεις του xfce.
Το QA στις ήδη υπάρχουσες μεταφράσεις είναι σχετικά δύσκολο.
Όσο κι εάν προσπαθούμε με τον Σταύρο να έχουμε ένα “κοινό” μεταφραστικό στυλ, αυτό συνήθως χάνεται με τον καιρό ή γινόμαστε πιο έμπειροι (τουλάχιστον εγώ) και βλέπω λάθη στην απόδοση των όρων.
Δυστυχώς ο χρόνος μας (σίγουρα ο δικός μου - πιστεύω και του Σταύρου) μειώνεται μέρα με την μέρα και όσο περνάει ο καιρός κάποια πράγματα μένουν αρκετά πίσω. Για αυτό λοιπόν όπως ενδιαφέρεται να βοηθήσει με τις μεταφράσεις του xfce ας κάνει ένα βήμα μπροστά. Το μόνο που χρειάζεται είναι λίγο μεράκι παραπάνω και αρκετή υπομονή.
Το archlinux έβγαλε νέα αρχεία iso στις 10.08.2009. Το καλό με τις Rolling release διανομές είναι ότι έχεις πάντα την τελευταία έκδοση, κι αυτό στο archlinux γίνεται πολύ εύκολα και με τον ίδιο τρόπο που γίνεται η αναβάθμιση των πακέτων:
pacman -Syu
Για να δω την εγκατάσταση μέσω του διαδικτύου (net install), κατέβασα το εξής iso image: archlinux-2009.08-netinstall-i686.iso και το boot-άρα μέσω του virtualbox.
Κατέγραψα όλα τα screenshot και δημιούργησα ένα album όπου μπορεί κανείς να δει μία εγκατάσταση archlinux μέσω διαδικτύου:
http://balaskas.gr/archlinux-2009.08/
ΥΓ: Ο οδηγός είναι εξαιρετικά αναλυτικός με 92 εικόνες!
Τον τελευταίο καιρό αναπτύσω ένα python project: PIrsyncD. Χωρίς να έχω γράψει ποτέ κώδικα σε python έκανα το Python Language Reference bookmark. Τολμώ να πω ότι μου λείπουν τα user examples όπως για παράδειγμα αναφέρονται στο Php Manual, αλλά υπάρχουν αρκετά sites για να καλύψουν και τους πιο απαιτητικούς.
Ένα από αυτά χρίζει ιδιαίτερης αναφοράς, κι αυτό είναι το blog του Doug Hellmann: http://blog.doughellmann.com/. Ο ίδιος γράφει το: Python Module of the Week.
Πολλοί μπορεί να τον γνωρίζεται είτε ως συγγραφέα του Python Magazine είτε ως συγγραφέα στο O’Reilly
Για όσους ενδιαφέρονται για python, ρίξτε μια ματιά.
ΥΓ: Εάν έχετε παρόμοια τέτοια sites/blogs αφήστε ένα σχόλιο.
Το καλοκαίρι ήταν αρκετά παραγωγικό για όλους όσους εμπλέκονται με το Xfce. Έπειτα από την συνάντηση όλων των developers στην fosdem, πάρθηκαν αρκετές αποφάσεις σε ότι αφορά την εξέλιξη του έργου.
Μερικά (κι όχι όλα) είναι τα εξής:
Release Model
Translations through Transifex
Move to Git
Better Xfce API documentation
Λίγα λόγια για τα παραπάνω: αποφασίστηκε και δημιουργήθηκε ένα νέο release model που αφορά τόσο το core development όσο και το release των goodies. Για να είναι όμως ενιαίο πλέον όλα τα projects φιλοξενούνται πλέον στο git on xfce. Το οποίο πρακτικά σημαίνει ότι πλέον όσοι τρέχουν κάποιο xfce instance από subversion (like me) χρειάζεται να αλλάξουν από το παλιό svn on xfce σε git. Ταυτόχρονα αποφασίστηκε η αλλαγή του τρόπου που ανεβαίνουν οι μεταφράσεις. ΔΕΝ θα δίνεται svn OR git access στους μεταφραστές αλλά χρησιμοποιείται ένα instance του transifex. Με αυτά τα abstract layers κατά το development, οι core developers αποφορτίζονται από τα διάφορα καθήκοντά τους και εστιάζουν καλύτερο σε αυτό που είναι σημαντικό: Την ανάπτυξη του project. Έγιναν μερικές επιλογές και δοκιμές ώστε να αλλάξει το panel και κάποια core libraries ώστε να συμβαδίσουν με τις εξελίξεις. Και φυσικά επειδή οι core devepolers είναι λιγότεροι από 10 τεκμηρίωσαν (όσο μπορούν) καλύτερα τα διάφορα APIs του xfce και φυσικά τα xfce bindings ώστε να μπορούν όσοι ενδιαφέρονται να αναπτύξουν ευκολότερα panel/thunar plugins ή διάφορες εφαρμογές. Το thunar νομίζω ότι μπορεί να καλύψει τις ανάγκες και των πιο απαιτητικών χρηστών (το bulk rename που έχει είναι απλά το καλύτερο που έχω δουλέψει).
Τα πράγματα δείχνουν αρκετά ενδιαφέροντα και νομίζω ότι μέχρι την επόμενη fosdem 2010 θα είμαστε σε θέση να συζητάμε ακόμα περισσότερα πράγματα.
Φαίνεται αρκετά ενδιαφέρον:
SecureComm 2009
September 14 - 18, Athens, Greece
http://www.securecomm.org/.
Κατά την (αποτυχημένη μέχρι στιγμής) προσπάθειά μου να κρυπτογραφήσω αμφίδρομα την επικοινωνία μεταξύ ενός mail client (π.χ. thunderbird) κι ενός mail server (π.χ. dovecot), καθώς και την αυθεντικοποίηση των mail client μέσω πιστοποιητικών ασφαλείας (x509 certificates), κατέληξα την συγγραφή ενός mini howto.
Εάν ενδιαφέρεται κανείς να δει απλές οδηγίες για το πως να εγκαταστήσει εύκολα και γρήγορα το dovecot ώστε να υποστηρίζει imap over ssl (993 tpc port) αλλά και να δει μέσω screenshots τι ρυθμίσεις χρειάζονται στον thunderbird, μπορεί να βρει το mini how to εδώ:
btw εάν κανείς μπορεί να βοηθήσει με το εξής, ας κάνει τον κόπο να μου στείλει ένα email.
Η τελευταία παρασκευή του ιουλίου είναι η
χρόνια πολλά σε όσους γιορτάζουν,
μακάρι το uptime σας να είναι αντιστρόφως ανάλογο με τον μισθό σας
Ο μιντόρι web browser είναι ένας αρκετά ελαφρύς (και γρήγορος) gtk2 περιηγητής ιστού, βασισμένος στο webkit. Ακριβώς επειδή βασίζεται στο webkit μπορεί να περνάει από αρκετά WaSP, ένα από αυτά είναι το acid3:
Με την έκδοση 3.5 του firefox, ο firefox ανέκτησε αρκετό από το χαμένο έδαφος που είχε να κάνει με τα εξής προβλήματα:
- κολλήματα
- αργός
- κρασαρίσματα
- 100% cpu usage
- 100% memory usage
Ήδη βρισκόμαστε την έκδοση 3.5.1, οπότε σκέφτηκα να δοκιμάσω εκ νέου το acid3 test, ορίστε τα αποτελέσματα:
Υπάρχει λοιπόν αρκετός δρόμος ακόμα για τον firefox μέχρι να κατακτήσεις τα web standards.
Στην διαμάχη Διαχειριστές Vs Προγραμματιστές να προσθέσω και το εξής:
αποφασίζει ο εκάστοτε super duper developer να αλλάξει το version control σύστημά του από subversion σε git, όχι επειδή του δίνει επιπλέον δυνατότητες - αλλά επειδή άκουσε ότι το έχει γράψει ο linus και είναι πολύ της μοδός.
Οκ ρε μάστορα, αφού την κάνεις την αλλαγή ΓΙΑΤΙ δεν ενημερώνεις και κανέναν ?
Η λογική (εάν θριάμβευε δλδ) θα τον έκανε να προσθέσει ένα ακόμα subversion commit που να γράφει στο log:
έεειι εσύ, ναι εσύ, εσύ που χρησιμοποιείς το πρόγραμμά μου και το ανανεώνεις μέσω subversion:
να ξέρεις, έχει πάψει να υπάρχει. Δες εδώ: ….. για το git
Τι μυστικοπάθεια είναι αυτή ρε γμτ, ο λόγος γίνεται γιατί στην προσπάθειά μου να ανανεώσω το midori, έπρεπε να ανανεώσω το webkit που έπρεπε να ανανεώσω το libsoup το οποίο τράβαγα από subversion και η latest έκδοση του ΔΕΝ ικανοποιούσε κανέναν.
Τελικά έχουν δίκιο για τους gnome developers (η ακακία μου)
Αυτές τις μέρες προσπάθησα να ασχοληθώ λίγο με το PIrsyncD.
Πρόσθεσα την δυνατότητα να ορίζει κανείς τους καταλόγους (source/destination) από την γραμμή εντολών κατά την εκκίνησή, ώστε να μην χρειάζεται να ανοίγει το αρχείο και να τροποποιεί τις μεταβλητές. Οι προκαθορισμένοι κατάλογοι παραμένουν οι εξής:
source: /tmp/data
destination: /tmp/data2
Πρόσθεσα επίσης παραμέτρους ώστε να εμφανίζει την τρέχουσα έκδοση και μία μικρή βοήθεια.
Θα προσπαθήσω τον επόμενο καιρό να προσθέσω νέες επιλογές και δυνατότητες.
Πλέον τα inotify events που παρακολουθεί το PIrsynD είναι τα εξής:
- IN_ATTRIB
- IN_CLOSE_WRITE
- IN_CREATE
- IN_DELETE
- IN_MODIFY
- IN_MOVED_TO
- IN_MOVED_FROM
- IN_DELETE_SELF
Τέλος προσπάθησα να καταγράψω μερικές ερωτήσεις/απαντήσεις και έτσι δημιουργήθηκε ένα μικρό faq, στο οποίο προσπαθώ να εξηγήσω καλύτερα τι είναι και τι κάνει το PIrsynD
Always the latest version is here: PIrsyncD
Σίγουρα έστω και μία φορά έχει χρειαστεί να χρησιμοποιήσεις dhcp σε κάποιο μηχάνημα.
Η δυνατότητα να παίρνει αυτόματα όλες τις ρυθμίσεις σου λύνει τα χέρια.
Απλά βάζει το καλώδιο του δικτύου σε μία πρίζα και voila - δεν χρειάζεται να κάνεις τπτ.
Το πρόβλημα:
Όταν ο υπολογιστής σου συνδέεται σε πολλά και διαφορετικά δίκτυα στα οποία ΔΕΝ είσαι πάντα ο διαχειριστής. Έχεις φτιάξει τόσα χρόνια ωραία και όμορφα το routing tables σου, έχει ορίσει τους dns servers κ.λ.π.-κ.λ.π.
Και με το τρέχει το dhclient σου διαλύει τα πάντα !!!
Πως λες στο dhcpclient να ΜΗΝ αλλάξει το /etc/resolv.conf αρχείο σου;
- Εύκολα, απλά κάνεις το εξής:
# cat > /etc/dhclient-enter-hooks << EOF
make_resolv_conf() {
echo "doing nothing to resolv.conf"
}
EOF
Η ερώτηση μου είναι η εξής:
Πως λες στο dhcpclient να ΜΗΝ σου αλλάξει το routing table;
Ένα από τα πράγματα που με εκνευρίζουν είναι όταν οι 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