Τι μπορεί να θυμηθεί κανείς… Ο Σωτήρης έχει γράψει το cvi, ένα βολικό wrapper script για τον vi, ώστε να έχει version control στα αρχεία που επεξεργάζεται.

Διαβάζοντας τις λίγες γραμμές που έγραψε, θυμήθηκα αμέσως το vip, ένα άλλο bourne shell script -wrapper στον vi- χάρη στο οποίο μπορεί κανείς να κάνει interactive editing σε ένα Unix shell pipe. Περιγράφεται σε άρθρο στο ;login: του Οκτωβρίου του 1997.

Πριν δύο μήνες έλαβα ένα email από ένα φοιτητή:

“Συγνώμη για την ενόχληση […] επειδή θα γίνω admin στο Πανεπιστήμιο μου θέλω μερικές συμβουλές, όπως toolbox, books, sites, live CDs, etc.”

Συμπτωματικά είναι ό ίδιος φοιτητής που ρώτησε τον κ. Σπινέλλη πως να γίνει hacker (με την old-school έννοια του όρου).

(Οι επόμενες παράγραφοι είναι αφιερωμένες στο ερώτημα, αλλά δεν είναι απαραίτητα τοποθετημένες σε μία λογική σειρά.)

Από την περιγραφή του SAGE, για το SAGE Level 1:

Required Skills
* Strong interpersonal and communication skills; capable of explaining simple procedures in writing or verbally; good phone skills.
* Familiar with an operating system and its commands/utilities at a user level; can edit files, issue commands, find users’ home directories, navigate through the file system, and use I/O redirection.
* Able to follow instructions well.

Required Background
* Two years of college or equivalent post-high school education or experience.

Desirable Background and Skills
* A degree or certificate in computer science or a related field.
* Previous experience in customer support, computer operations, system administration, or another related area.
* Motivated to advance in the profession.

Appropriate Responsibilities
* Performs routine tasks under the direct supervision of a more experienced administrator.
* Acts as a front-line interface to users, accepting trouble reports and dispatching them to appropriate system administrators.

Είναι δύσκολο να γράψει κανείς για το πως μπορεί να γίνει κάποιος άλλος system administrator. Η εκπαίδευση για το επάγγελμα δεν είναι συστηματοποιημένη. Η κατάσταση μοιάζει με αυτή που περιγράφεται στο “Εκπαίδευση, Τεχνολογία και Βιομηχανικές Επιδόσεις στην Ευρώπη 1850-1939“. Για να γίνει κάποιος Μηχανικός είχε (ιστορικά) τρεις επιλογές:

1. Να μαθητεύσει άμισθα για μεγάλο χρονικό διάστημα δίπλα σε άλλους Μηχανικούς
2. Να μαθητεύσει πληρώνοντας ένα μεγάλο χρηματικό ποσό σε σχολές μαθητείας κατασκευαστών Μηχανολογικού (και όχι μόνο) εξοπλισμού και λίγο αργότερα
3. Να μαθητεύσει σε μια Πανεπιστημιακή σχολή πληρώνοντας ένα πολύ μικρότερο (αλλά όχι ευκαταφρόνητο) ποσό.

Σας θυμίζει τίποτε; Εμένα πολλά! Οι περισσότεροι System Administrators που ξέρω έχουν ακολουθήσει (more or less) την μέθοδο #1 (Always two there are; no more, no less: a master and an apprentice). Ή μήπως η χρηματική δαπάνη που απαιτείται για να αποκτήσει κανείς ένα καλό cisco, Sun, Microsoft, Oracle certifictation δεν θυμίζει το #2; Αυτό που σίγουρα δεν υπάρχει (ακόμα;) είναι το #3.

Παρόλο που δεν είχα επίσημα ένα master να με καθοδηγεί θεωρώ τον εαυτό μου προϊόν της διαδικασίας #1. Δεν ακολούθησα ποτέ την διαδικασία #2 και βρέθηκα ανάμεσα στα παιδιά του Εργαστηρίου Βάσεων Γνώσεων και Δεδομένων, το οποίο (τι καταπληκτικό!) είχε κοινή εσωτερική πόρτα με το NETMODE. Δεν νομίζω να είχα ποτέ ερώτηση στην οποία να μη βρήκα απάντηση.

Ο system administrator δεν καταθέτει τα όπλα. Εκεί που οι άλλοι βλέπουν τοίχο, αυτός βλέπει ένα ενδιαφέρον πρόβλημα ή και παιχνίδι ακόμα. Όπλα του είναι η διαίσθηση, η εμπιστοσύνη στον εαυτό του και τα manual. Και ποτέ δεν πιστεύει τον χρήστη όταν “δεν έκανε τίποτε”. Πάντα ρωτάει “δείξε μου το τίποτε που έκανες”.

Ένα πράγμα που έχει πάντα μεγάλη σημασία είναι να μη φοβάται κανείς να ρωτάει. Δεν υπάρχουν χαζές ερωτήσεις, μόνο χαζοί άνθρωποι. Και να έχει κανείς ανθρώπους να μοιράζεται τους προβληματισμούς του και τα ευρήματά του. Τα πρώτα χρόνια, εγώ ο Unique Fish και ο Πάνος ήμασταν διαχειριστές σε διαφορετικά εργαστήρια στο ΕΜΠ. Πολύ συχνά συζητάγαμε για τα ευρήματά μας, τα προβλήματα (τεχνικά ή με χρήστες) και τις λύσεις μας. Δεν υπήρξε ποτέ μία στιγμή που να φοβήθηκε κάποιος να μοιραστεί αυτό που “βρήκε” με τους άλλους.

Το ξενύχτι είναι μεγάλος σύμμαχος. Τη νύχτα υπάρχει περισσότερη ησυχία, μπορείς να συγκεντρωθείς στο διάβασμα (και όταν τελειώσεις να βγεις έξω κατευθείαν). Mailing lists σαν το decstation-managers, sun-managers, coderpunks και cypherpunks και newsgroups σαν το comp.unix.programmer και το comp.security.misc ήταν για χρόνια στην ημερήσια διάταξη.

Το 1991 στη διάρκεια ενός σεμιναριακού μαθήματος, ένας από τους τότε διαχειριστές του ΕΜΠ μας είχε πει πως ο system administrator θυμάται ανά πάσα στιγμή απ’έξω περί τις 300 εντολές και τα ορίσματα που δέχονται. Είχαμε μείνει με το στόμα ανοιχτό. Στην πραγματικότητα όμως είχε πέσει έξω: Είναι πολύ περισσότερες.

Ο ίδιος διαχειριστής μας είχε πει (και είχε δίκιο) πως ο καλός system administrator πρέπει να ξέρει καλή C. Μάθετε το K&R απέξω! Και μια και ο λόγος είναι για τις γλώσσες προγραμματισμού, δεν βλάπτουν λίγη awk και Perl (για αρχή). AWK έμαθα από τα manuals της DEC (nawk) και πρόλαβα την Perl 4 οπότε την αντιμετώπισα αρχικά σαν απλοποιημένη C (δεν δηλώνω μεταβλητές, όλες οι μεταβλητές έχουν μπροστά $, βάζω παντού ; και δεν γράφω the Perl way). Αργότερα είχα την τύχη να δουλεύω για χρόνια με ένα Perl guru. Σήμερα υποθέτω κάποιος θα ξεκίναγε από το βιβλίο του Robbins (υπάρχει online, αλλά αγοράστε το καλύτερα). Για την Perl ο O’Reilly έχει κάνει καλή δουλειά.

Λειτουργικά συστήματα δεν διαχειριζόμαστε; Τι στο %$#@%$@ κάνει ένα λειτουργικό σύστημα; The Magic Garden Explained.

Υπάρχουν άραγε πουθενά τα sources του learn;

Δεν υπάρχει άνθρωπος που δεν θα συστήσει ποτέ το Unix Network Programming του W.R. Stevens (το οποίο και μου είχαν δανείσει από το NETMODE, όπως και το Advanced Programming in the Unix Environment). Σήμερα στο σπίτι μου έχω τα volume 1 και volume 2. Το The Unix Programming Environment το είχε το dblab (όποιος το έχει πάρει να το επιστρέψει!).

“Ρε συ Γιώργο τι netmask έχουμε;” Internetworking with TCP/IP Vol.1.

Η έλλειψη μακροχρόνιου ενδιαφέροντος για ένα και μόνο πράγμα στην Πληροφορική επίσης με βοήθησε πολύ. Για τι ενδιαφερόμαι αυτό το μήνα; Για ότι κι αν ενδιαφερόμουν εκείνο το μήνα, φρόντιζα να το ψάξω καλά. Για τα περισσότερα άλλωστε είχα ανθρώπους γύρω μου που είτε ήξεραν να μου απαντήσουν, είτε ήξεραν κάποιον που ήξερε. Αλλά και για αυτά που δεν ενδιαφέρονταν με έμαθαν πως να ψάχνω. Π.χ. την περίοδο που με ενδιέφερε το reverse engineering, δέχτηκα μια από τις πιο σημαντικές συμβουλές. Ζήτησα από τον der Mouse να μου πει για τον decompiler που έχει φτιάξει: “Είναι ανάμεσα στα αυτιά μου”.

Κάνε το ίδιο install πολλές φορές. Οι φίλοι μου θα πρέπει να έχουν ξεκαρδιστεί από τα γέλια. Το ίδιο install του ίδιου OS το επαναλλαμβάνω πολλές φορές ακόμα και στο ίδιο μηχάνημα. Με τις ίδιες επιλογές ή και με διαφοροποιήσεις. Μπορεί να παίρνει ώρες (learn to multitask) αλλά σίγουρα βοηθάει. Θα βρεις γρήγορα μπροστά σου εκείνη την κουλή περίπτωση για την οποία θα πρέπει να είσαι προετοιμασμένος. Και μιλάμε για ένα system administrator τώρα, όχι για ένα developer, ούτε φυσικά για ένα casual user.

Θυμάμαι ήμουν κάτι μήνες μόνο system admnistrator όταν ο sv1xv με ρώτησε “και αυτό με το DNS πως το κάνεις;”. Τι είναι το DNS; Τι μου λέει τώρα; Θυμάμαι που με ντροπή τον ρώτησα “τι είναι DNS;” και έκατσε με όρεξη να μου εξηγήσει. Φαντάζομαι είναι πιο εύκολο να ξεκινήσει κανείς σήμερα από το DNS and BIND.

Και δεν έχω γράψει τίποτε για τα θέματα ασφάλειας υπολογιστικών συστημάτων. Το Thinking about firewalls είναι μόνο μια αρχή.

Η μεγαλύτερη χαρά μου είναι όταν φίλοι μου με ρωτάνε για πράγματα για τα οποία δεν ξέρω την απάντηση. Ο Παναγιώτης έχει ένα ιδιαίτερο ταλέντο σε αυτό, όπως και στο να βρίσκει τελικά άλλη λύση από αυτή που του προτείνω. Παρόλαυτά, η τριβή με το πρόβλημα σε ασκεί, σε αναγκάζει να επικαιροποιήσεις τις γνώσεις σου, να γίνεις καλύτερος.

Σπάνια πια θα υπάρχει ένα σύστημα που θα διαχειρίζεται κάποιος το οποίο να μην τρέχει μία βάση δεδομένων. Η δικιά μου πρόταση για κάποιον που δεν ενδιαφέρεται να μάθει πολλά για βάσεις δεδομένων, αλλά που θέλει να ξέρει από βάσεις και να μην τις αντιμετωπίζει σαν μια συλλογή πινακοποιημένων δεδομένων είναι το Theory and Practice of Relational Databases. Φαντάζομαι πως κανείς θα περίμενε κάποιο βιβλίο για MySQL ή για PostgreSQL. Απεχθάνομαι αυτά τα βιβλία! Εάν κάποιος έχει κατανοήσει τα βασικά του Σχεσιακού Μοντέλου το online documentation είναι παραπάνω από αρκετό για να μπορέσει να τα βγάλει πέρα.

Να μην αναζητάς το “μπούσουλα”, αλλά το πως δουλεύουν τα πράγματα. Το να έχεις μια λίστα που να λέει “αν γίνει αυτό, τότε κάνε αυτό” δεν λέει τίποτε. Δεν θα σε βοηθήσει ποτέ να καταλάβεις γιατί η εφαρμογή που τρέχει στο server “πάει αργά” (αν πάει) ούτε θα σε βοηθήσει να βρεις τι φταίει, ούτε πως να λυθεί. Θέλεις να είσαι ο go-to guy ή όχι; Εάν ναι, πρέπει να ξέρεις πολλά από πολλά πράγματα. Εάν όχι, κάνε παρέα με τα checklists και μη βγαίνεις ποτέ έξω από αυτά.

Και πως θα μπορούσε να λείπει μια αναφορά στο bat book;

Μέχρι τώρα απέφυγα να γράψω οτιδήποτε για εργαλεία / toolbox. Στην πραγματικότητα διαβάζοντας και δουλεύοντας δημιουργείς το toolbox σου. Δεν έχει νόημα να ξεκινήσεις ανάποδα. Όμως δεν μπορώ να μην αναφερθώ στα ακόλουθα εργαλεία: netcat, traceroute και host. Ειδική μνεία θα ήθελα να κάνω στο tcpdump. Άλλωστε για να μπορέσει κανείς να εκμεταλλευτεί το δυναμικό τους θα πρέπει να έχει διαβάσει πολύ. Αν προσπαθήσει να διαβάσει και τον πηγαίο κώδικά τους, θα μάθει περισσότερα.

Δεν νομίζω πως υπάρχει βιβλίο που να έχει αποδώσει περισσότερο σε εμένα από το SICP. Σε μαθαίνει να σκέφτεσαι.

Όπως βλέπεις φίλε Νίκο, το μόνο που μπορώ να σου ευχηθώ είναι καλή χρονιά, καλή δύναμη και καλό διάβασμα. Το post αυτό βγήκε μεγάλο και με τη βοήθεια και άλλων ίσως να γίνει καλύτερο και διαφωτιστικότερο.

Aντί για το:

$ sudo mount /dev/sd0i /mnt
$ sudo cp lala.txt /mnt

καταλλήγει κανείς να γράψει:

$ sudo cp /dev/sd0i /mnt

@!#$&^

Η κούραση είναι κάκιστος βοηθός.

Χαζές ερωτήσεις είναι μόνο αυτές που δεν κάνει κανείς, αλλά:

Η ποιότητα της απάντησης είναι πάντα ανάλογη της ποιότητας της ερώτησης.

Για αυτό: How To Ask Questions The Smart Way.  Κανείς δεν πρέπει ντρέπεται να ρωτάει 0-τι-δή-πο-τε.  Αλλά επίσης δεν πρέπει και να εκνευρίζεται εάν η απάντηση δεν είναι αυτή που περιμένει…

– Βάλε μνήμη! Ο υπολογιστής σου θα “πάει” πιο γρήγορα.
– Αλήθεια;

The Nerd Handbook: Υποχρεωτικό ανάγνωσμα για συζύγους, συντρόφους, συμβίες.

[via]

core dumb: n.

Η πνευματική κατάσταση στην οποία περιέρχεται ο διαχειριστής όταν έχει προβεί σε όλες τις προτεινόμενες από τον κατασκευαστή ενέργειες και όμως συνεχίζει να παίρνει core dumps.

Ο όρος εφευρέθηκε από τον coby.

“Μου χάλασαν 460 μέρες uptime στο firewall”. Φίλος χτες, κατά τη διάρκεια δοκιμών προσπαθώντας να ξεπεράσει (route arround) το χθεσινό πρόβλημα.

Δεν χωρεί αμφιβολία πως το uptime είναι ένα καλό μέτρο σταθερότητας των συστημάτων που διαχειρίζεται (συντηρεί) ένας system administrator. Το να γίνεται όμως αυτοσκοπός (και μερικές φορές ένα είδος συναδελφικής “κόντρας”) είναι επικίνδυνο:

Συνήθως διαχειριζόμαστε πολλά συστήματα και μηχανές, όχι μόνο ένα-δύο. Τα συστήματα αυτά έχουν αλληλεξαρτήσεις μεταξύ τους, οι οποίες πολλές φορές δεν είναι ούτε καταγεγραμμένες, ούτε προφανείς.

Τα συστήματα που διαχειριζόμαστε εξελίσσονται (μεταλλάσσονται που λέει και ένας καθηγητής μου) με την προσθήκη νέων υποσυστημάτων που “πατάνε” στην παλαιότερη υποδομή. Και ναι, η ικανοποίηση είναι μεγάλη όταν μπορείς να επιτύχεις δραστικές αλλαγές στο σύστημα χωρίς να “κατεβάσεις” μηχάνημα (χωρίς να χαλάσεις το uptime δηλαδή).

Αλλά:

Στη διαδικασία αυτών των αλλαγών μεταβάλλονται κατά τρόπο μη προφανή δύο διαδικασίες:

• Διαδικασία παύσης όλου του συστήματος
• Διαδικασία έναρξης όλου του συστήματος

και επηρεάζεται εξίσου και η διαδικασία επανεκκίνησης τμημάτων ή όλου του συστήματος. Πολλές φορές το να έχουν κάποια μηχανήματα υψηλό uptime (πάνω από 6 μήνες κατά τη γνώμη μου) είναι περισσότερο πρόβλημα, παρά στοιχείο υπερηφάνειας:

Μπορεί στο μεσοδιάστημα να έχουν αλλάξει περισσότερους από ένα διαχειριστές, με ότι σημαίνει αυτό ως “χαμένη εμπειρία” για το σύστημα, ειδικά εάν ο παλαιότερος διαχειριστής έχει αλλάξει εργοδότη.

Υψηλό uptime σημαίνει πως τουλάχιστον kernel patches δεν έχουν εφαρμοστεί, με ότι σημαίνει το ρίσκο αυτό κατά περίπτωση. Ναι, ξέρω πως υπάρχουν λειτουργικά συστήματα στα οποία μπορείς να κάνεις upgrade τον kernel χωρίς reboot. Πόσοι δουλεύετε με τέτοια και πόσοι από αυτούς που όντως δουλεύετε με τέτοια κάνετε έτσι τα upgrades;

Πολλές φορές δεν μπορούμε να δουλεύουμε με καινούριες μηχανές. Μερικές φορές κρίσιμη υποδομή ενδέχεται αναγκαστικά να βρίσκεται σε μηχανήματα 10+ χρόνια παλιά. Με το πέρασμα του χρόνου το κάθε μηχάνημα αποκτά τα “χούγια” του (π.χ. ο διακόπτης πρέπει να πατηθεί “κάπως” για να δουλέψει) ενώ ακόμα και στο software που τρέχει το να κάνεις reboot μπορεί να σημαίνει πως κάποιες διαδικασίες πρέπει να τις κάνει υποχρεωτικά με το χέρι πριν το reboot, ή μετά το boot, κ.ο.κ.

Έτσι όταν τα πράγματα θα πάνε στραβά (γιατί θα πάνε) ο χρόνος ανάνηψης είναι τελικά μεγαλύτερος, γιατί την εμπειρία των ιδιαίτερων λεπτομερειών του κάθε συστήματος, υποσυστήματος, μηχανής και την μέθοδο επανεκκίνησης με όλα τα ιδιαίτερα χαρακτηριστικά της, θα πρέπει να την μάθει κανείς (και ελπίζω και να την καταγράψει) εκείνη ακριβώς τη στιγμή, με όλη την πίεση πάνω του.

Και μην ξεχνάμε: 99.999% uptime is for Wal-Mart. Γι’αυτό:

Downtime is not an option.

Ο αρχικός τίτλος του post ήταν: uptime (ή ποιος την έχει μεγαλύτερη)

Ακριβέστερα του recovering BOFH, όπως έχει αποδοθεί από τον coby.