Όλα τα συστήματα δεν είναι ίδια. Θα βρείτε συχνά τον όρο service και τον όρο daemon. Πολλές φορές δεν υπάρχει διαφορά και άλλες υπάρχει. Σε ορισμένες περιπτώσεις το service είναι ένα ολόκληρο πρόγραμμα που τρέχει κανονικότατα στο background και περιμένει εντολές. Σε άλλες, ο daemon, είναι ένα κομματάκι του προγράμματος αυτού που περιμένει ένα signal (σινιάλο) για να ξεκινήσει το κύριο πρόγραμμα ή να κάνει κάποιες μετατροπές στην λειτουργία του, κλπ,
H αρχή πολλών νέων συστημάτων είναι το daemontools, στο οποίο βασίστηκε το runit, perp, s6, nosh, minit, cinit, ninit, και το anopa που είναι σαν front του s6. To nosh έχει ιδιαίτερο ενδιαφέρον.
Όταν ξεκινάει ένα σύστημα η κύρια λειτουργία είναι να διαβαστεί το σύνολο του πυρήνα (κέρνελ) και να ανιχνευτεί το μηχανικό υλικό (hardware) για να ξέρει το σύστημα τι κάνει τι και που βρίσκεται το κάθε τι. Πληκτρολόγιο και ποντίκι για να μιλάς στο μηχάνημα, γραφικά/monitor/printer για να σου μιλάει αυτό, δίσκοι, κάρτες νέτγουορκ, κλπ. Υπάρχουν διάφορα είδη συστημάτων δίσκων/αρχείων που μπορεί να διαχειριστεί το λίνουξ, fat, ntfs, ext2,3,4, btrfs, zfs (νέο κόλπο με τρομερές επιδόσεις - υπάρχει στήριξη για 100% χρήση zfs στο Obarun) και πρέπει αυτά τα filesystem fs να αναγνωριστούν και να ελεγχθούν ότι είναι σωστά πριν ξεκινήσει το μηχάνημα. Επίσης γίνεται ορισμός της διαχείρισης της μνήμης ram/swap. Για να λειτουργούν όλα αυτά και στο μέλλον και να μην προκύπτουν συχνές βλάβες, ότι κάνει το σύστημα για να ξεκινήσει πρέπει αντίστροφα να το κάνει και στο τέλος για να σταματήσει. Ένα γιγαντιαίο κεφάλαιο του init που υποτιμάται από χρήστες και συχνά ακούγεται το “λίνουξ είναι, και να το βγάλεις απ’την μπρίζα δεν τρέχει τίποτα” … τρέχει … ναι μεν το ext μπορεί και διορθώνει τον εαυτό του καλύτερα από το ntfs, καλύτερα είναι να μην ασκούμε βία πάνω στους δίσκους μας.
Η συνολική αυτή λειτουργία για συντόμευση και περίληψη, προκύπτει στο να ξεκινήσει ένα πρόγραμμα που στην περίπτωση του s6 είναι το s6-svscan
PID TTY TIME CMD
1 ? 00:00:00 s6-svscan
Το s6-svscan βρίσκει από την διαδικασία init ένα υποφάκελο που δημιουργήθηκε ζωντανά στην εκκίνηση /run/66/scandir και μέσα σε αυτό τρέχει ότι του δώσεις. Το runit είναι πολύ παρόμοιο σε αυτό το απλοϊκό στάδιο αλλά τρέχει το ίδιο σαν pid1 και αν μείνει μόνο του δεν μπορεί να ξεκινήσει τίποτα, ούτε shutdown μπορεί να κάνει. To s6-svscan μπορεί να σταματήσει μόνο με την μπρίζα και με το ίδιο του τον δαίμονα που λέγεται s6-shutdown, αλλά αν σταματήσεις όλα τα πρόσες και μείνει μόνο του ξαναξεκινάει το σύστημα κανονικότατα.
Υπάρχει κάπου στο σύστημα ένα σημείο που βρίσκονται αυτά που λέγονται servicefiles, ένα για κάθε σέρβις, πχ /etc/runit/runsvdir/default ή στο 66 το /usr/lib/66/service. Συνδέοντας (ln -s) κάποιο από αυτά στο /run/66/scandir ή στο /run/runit… το service manager τα ξεκινάει. Του runit απλά είναι μια γραμμη που ορίζει την εκτέλεση του προγράμματος. Του 66 είναι υπό την παρακάτω μορφή που συμπεριλαμβάνει το περιβάλον:
cat /usr/lib/66/service/dbus
[main]
@ type = longrun
@ description = “dbus system daemon”
@ user = ( root )
@ maxdeath = 3
@ notify = 4
@ options = ( log env )
@ timeout-up=3000
[start]
@ build = auto
@ execute = (
s6-ipcserver-socketbinder – {socket_dir}/{socket_name}
foreground { dbus-uuidgen --ensure }
execl-cmdline -s { dbus-daemon ${cmd_args} }
)
[stop]
@ build = auto
@ execute = ( s6-rmrf {socket_dir}/{socket_name} )
[logger]
@ build = auto
@ backup = 3
@ maxsize = 1000000
@ timestamp = iso
[environment]
cmd_args=!–system --print-pid=4 --nofork --nopidfile --address=unix:path=/run/dbus/system_bus_socket
socket_dir=!/run/dbus
socket_name=!system_bus_socket
Yπάρχει και μια μεγάλη αδυναμία σε θέμα ασφάλειας αν κάτι δεν πάει καλά με το boot. Ας πούμε έχουμε ένα ssd δίσκο μόνιμα στη μπρίζα και καταγεγραμμένο στο /etc/fstab και το σύστημα ξεκινάει. Αν κάποιος το τραβήξει απ’την πρίζα το runit ξαφνιάζεται με το λάθος και πάει σε emergency mode που αυτόματα είναι root, χωρίς passw. Το 66 πάει στο μοναδικό tty το 12. Στο 12 μόνο σαν user μπορείς να μπεις, όχι σαν root, κάποιος δηλαδή κακόβουλος δεν μπορεί να ανακαλύψει εύκολα και το username και το pass. To tty12 στο 66 είναι από τις βασικές λειτουργείες του boot. Πάντα δηλαδή υπάρχει το αποκούμπι για διάγνωση.
Όταν τελειώσει το boot ξεκινάει να βρει το ενεργό “δέντρο” και τα άλλα δέντρα που στο καθένα από αυτά είναι καθορισμένα διάφορα service/daemons. Το βασικό είναι να έχεις ένα tty1 παραδοσιακά. Στα live του obarun υπάρχει πάντα το βασικό tree root. Σε περίπτωση που το μηχάνημα είναι server και έρχεστε σε επικοινωνία μέσω ssh τι χρειάζονται όλα τα άλλα; Χρειάζεται network, το sshd, κλπ.
Η δημιουργία tree είναι απλή.
% sudo 66-tree -ncE root
Δημιουργεί ένα (n)ew tree το οποίο είναι ©urrent (σημαίνει ότι όταν ενεργοποιήσεις ένα service χωρίς να ορίσεις tree πηγαίνει σε αύτο) και (Ε)nabled - ενεργοποιημένο.
% sudo 66-enable tty@tty1 tty@tty2
ενεργοποιεί το tty1 (με βάση το template tty@) και tty2
% sudo 66-tree -n net
% sudo 66-enable -t net -S dhcpcd ntpd sshd
Φτιάχνει ένα tree το net, ενεργοποιεί τα dhcpcd, ntpd, sshd, και τα ξεκινάει (S)tart.
Αν δούμε τώρα τι τρέχει
% 66-intree
θα μας δείξει το tree boot και τα service του, το tree root και τα tty του, το tree net και τα service του, τα pid τους, την κατάσταση τους, και το log για το καθένα.
Το s6 δεν είναι απαραίτητο να έχει συγκεντρωτικό log service για κάθε είδους service κρατάει ειδικό log μέσω του εργαλείου s6-log. Για κάποια, σαν τα tty δεν χρειάζεται log, για κάποιο είναι χρήσιμα. Όλα είναι σε μορφή text και κάτω από το κλάδο /var/log/66/service_name
Το 66 απλά κάνει το setup για το s6, δεν υπάρχει μετά την εκκίνηση εκτός κι αν δώσεις εντολή να αλλάξει κάτι. Το κάθε service στο s6/66 μπορεί να έχει διαμορφωμένο εξειδικευμένο περιβάλλον, κάτι του το runit δεν μπορεί να κάνει, απλά ξεκινάει και τρέχει ένα πρόγραμμα όπως το wpa_supplicant.
Γνωρίζετε τι κάνει το acpid, το dbus, το cupsd, και ένα σωρό διαόλοι που τρέχουν ακατάπαυστα σε ένα σύστημα σαν το ubuntu/mint/manjaro κλπ.; Πως τα ελέγχετε, πως κάνετε διάγνωση τι πήγε στραβά όταν το μόνο πράγμα που σας απομένει είναι ένα tty (και άν!); Το runit και ακόμα περισσότερο το 66 σας δίνει πλήρως τον έλεγχο και την διαμόρφωση του συστήματος και γρήγορη και εύκολη διάγνωση. Βέβαια αν δούμε το μοναδικό image/iso που παράγει επίσημα η arch και το ξεκινήσουμε, δεν τρέχει και πολλά πράγματα, είναι λιτό και σπαρτιάτικο. Απ’την στιγμή που κάνεις εγκατάσταση το openntp και το cups αυτά αυτόματα πέρνουν μπρος και δουλεύουν. κλπ κλπ. To systemd έχει αλυσιδοτά δεσμευμένα service και το ένα ξεκινάει το άλλο. Tου λες να σταματήσει κάτι και αυτόματα κάποιος άλλος δαίμονας το ξαναξεκινάει. Tρέχα γύρευε. Αν κάνει crash το Χ τρέχα γύρευε στην κυριολεξία να μάθεις τι πήγε στραβά και προκάλεσε το λάθος. Tα logs είναι σε περίεργη μορφή, όχι απλό τεξτ. Το systemd είναι σκουπιδιάρικο και σκουπιδοφάγος, ότι κι αν χαλάσει το ξαναξεκινάει χωρίς να δείνει σημασία τι τρέχει, γιατί κάτι σταμάτησε, και θεωρώντας ότι το σύστημα έχει απεριόριστους πόρους μπορεί να ξεκινάει ένα σπασμένο πρόγραμμα 30 φορές το λεπτό, να γράφει λογκ, και να το τρέχει έστω και για κλάσματα του δευτερολέπτου, ή μέχρι να γεμίσει ο δίσκος από άχρηστα log. Η χαρά του μαλάκα sys-admin δηλαδή. Σε κάποια στιγμή κλείνεις τα προγράμματα που τρέχεις όλη μέρα και κοιτάς το ram και έχει φλομώσει στο σκουπιδαριό, δεν έχεις πάρει χαμπάρι ότι κάτι τρέχει και που βα βρεις άκρη από το …!
Μια ωραία απεικόνιση του συστήματος σε κάθε στιγμή είναι το
% pstree -a
% sudo 66-intree root
% sudo 66-inservice -p14 dhcpcd
To πρώτο δίνει πληροφορίες για το tree root, το δεύτερο δίνει πληροφορίες για την κατάσταση του service dhcpcd και το -p14 του λέει να μας διαβάσει τις τελευταίες 14 γραμμές από το ειδικό log του dhcpcd.
Κάτι σαν ποδήλατο, μοτοσυκλέτα, αεροπλανοφόρο (στην ίδια σειρά),
