Αναζητώντας νέο init για το voidlinux| Μέρος Γ΄| Ενσωμάτωση: προκλήσεις & λύσεις

[mobinmob]

Στην προσπάθεια για ενσωμάτωση του 66 στο voidlinux, εμφανίστηκαν κάποιες προκλήσεις που έπρεπε να ξεπεραστούν. Οι κυριότερες ήταν:
α) η δημιουργία μιας μεθόδου αλλαγής μεταξύ των δύο init (runit/66) και προς τις δυο κατευθύνσεις,
β) ο τρόπος συγγραφής των frontends,
γ) η σχέση τους με τις runit services που υπάρχουν και
δ) ένα ομαλό σχέδιο μεταφοράς τους από την μία μορφή στην άλλη.


Μετάβαση σε άλλο init

Η αλλαγή init για τον χρήστη που το επιθυμεί μπορεί επιφανειακά να φαίνεται εύκολη. Αν κάποιος προσθέσει στο kernel commandline init=/διαδρομή/προς/init, απλά στην επόμενη εκκίνηση ο kernel θα επιλέξει το νέο init. Αυτό όμως είναι ημιτελές.
Κάθε init, πέρα από το binary/script το οποίο εκτελεί ο πυρήνας, έχει και μια σειρά μικρά εργαλεία δικά του - halt, reboot, poweroff, shutdown. Δεν μπορούν να συνυπάρχουν  τα εργαλεία διαφορετικών συστημάτων, καθώς βρίσκονται στην ίδια διαδρομή! Αν κάποιος εκκινήσει με νέο init όπως αναφέρεται παραπάνω, αλλά δεν έχει στο PATH τα σχετικά εργαλεία, τότε δεν θα μπορεί να κάνει τις αντίστοιχες ενέργειες με τον τρόπο που έχει συνηθίσει.
Το voidlinux έχει αλλάξει από systemd σε runit στο παρελθόν, αλλά δεν έχει κάποιον μηχανισμό για να   επιτρέπει την αλλαγή από ένα init σε άλλο εύκολα. Το artix, που διαθέτει τρία επίσημα υποστηριζόμενα init, υλοποιεί την αλλαγή έχοντας τα αρχεία που χρειάζονται σε διαφορετικά πακέτα, ενώ στο void αυτά συνυπάρχουν με τα βασικά runit scripts στο void-runit [1]. Για να δημιουργηθεί τέτοιος μηχανισμός, θα έπρεπε να γίνουν δεκτές από την ομάδα ανάπτυξης της διανομής αλλαγές στο πως πακετάρεται το runit και το void-runit, κάτι το οποίο, πέρα από δύσκολο, ήταν και κάτι για το οποίο δεν θα μπορούσε να περιμένω.
Έτσι επιχειρήθηκε (αρχικά από τον @teldra) να γίνει η αλλαγή αυτών των εκτελέσιμων κατά την εκκίνηση. Αυτό το σύστημα εξελίχθηκε λίγο και κατέληξε σε ένα service για το 66 και μία core-service για το runit. Αυτές ελέγχουν ποιο σύστημα τρέχει και αλλάζουν αυτόματα τα σχετικά εργαλεία κατά την εκκίνηση αν χρειάζεται. Είναι μια λύση που δουλεύει, αλλά δεν παύει να έχει προβλήματα. Μια καλύτερη λύση έχει δημιουργήσει ο @heliocat και περιμένει έγκριση [2] . Χρησιμοποιεί τον μηχανισμό των alternatives και τυποποιεί την διαδικασία σε μεγάλο βαθμό. Αν υιοθετηθεί επίσημα, θα γίνουν οι απαιτούμενες αλλαγές και στο boot-66serv PR [3].

Services

To voidlinux περιλαμβάνει περίπου 500 service scripts για το runit. Για το 66 υπήρχαν λίγα frontends από το obarun, αλλά αυτά δεν αποτελούσαν απαραίτητα λύση, ενώ ήταν εξαιρετικής ποιότητας και δοκιμασμένα. Ο λόγος είναι πως το obarun βασίζεται στο arch και μεταφέρει σε μεγάλο βαθμό τις πολιτικές του όσον αφορά την συμπεριφορά των services, οι οποίες προφανώς δεν είναι πάντα ίδιες με το voidlinux. Επίσης, από ένα σημείο και μετά, το obarun χρησιμοποιεί module services με τρόπο που θα ήταν ανοίκειος σε κάποιον που χρησιμοποιούσε void.
Πολύ νωρίς πήρα την απόφαση να υλοποιηθούν frontends με τρόπο που δεν θα ξένιζε τους χρήστες του void, οπότε δεν μπορούσα να υιοθετήσω άκριτα τα αντίστοιχα του obarun. Αρχικά, η μετατροπή ήταν πρακτικά αντιγραφή των runit scripts στο πεδίο @execute των ομώνυμων frontends και η συμπλήρωση των υπολοίπων πεδίων κατάλληλα. Στην συνέχεια, λόγω προοδευτικής εξοικείωσης με το σύστημα και την execline τα περισσότερα scripts ξαναγραφήκαν σε αυτήν, ενώ έγιναν δυο βελτιώσεις: όσοι daemons μπορούν να στέλνουν logs σε stdout/stderr – αντί του syslog -  πλέον το κάνουν και σε κάποια frontends έγιναν αλλαγές για καλύτερη κατά τη γνώμη μου λειτουργία. Για το πρώτο, αρκεί τις περισσότερες φορές μια επιλογή – switch. Φαίνεται ότι για την αλλαγή στο logging υπάρχει ενδιαφέρον και από την διανομή, οπότε κάποιες από τις αλλαγές ενδέχεται να ενσωματωθούν στα runit scripts.
Αυτή τη στιγμή υπάρχουν στο αποθετήριο void-66-services  περίπου 120 frontends – το “περίπου” οφείλεται στο ότι δεν έχει υπάρξει έκδοση με όλα και κάποια βρίσκονται σε στάδιο δοκιμών.
Ένα ζήτημα που έπρεπε να αντιμετωπιστεί ήταν η αδειοδότηση των frontends. Εξ’ αρχής στο repo υπήρχε υλικό που προερχόταν από ή βασιζόταν σε κώδικα από το s6-rc και το obarun (με άδεια χρήσης ISC) και από τα void-packages (με άδεια χρήσης BSD-2-Clause). Επέλεξα να χρησιμοποιήσω την δεύτερη άδεια για την συλλογή, με στόχο να είναι εύκολη η ενσωμάτωση στο void-packages  αν αποφασιστεί κάτι τέτοιο, αλλά και σε οποιαδήποτε άλλη διανομή, ενώ παράλληλα υπάρχουν σε ξεχωριστό αρχείο και οι άλλες άδειες αφού αυτό απαιτείται.

Πακετάρισμα και τεκμηρίωση

Η προσπάθεια για πακετάρισμα του boot-66serv ξεκίνησε από τον @zenfailure [4], συνεχίστηκε από τον @teldra [5] και κατέληξε στα δικά μου χέρια. Το template όμως για το πακετάρισμα ήταν μόνο σε ένα PR και θα απαιτούσε κάποια προσπάθεια από όσους ήταν αρκετά περίεργοι για να το δοκιμάσουν. Έτσι, δημιουργήθηκε το void-66 repo [6] στο codeberg που περιέχει πακέτα για τα boot-66serv, void-66-services, scandir-66serv.
Κάτι αντίστοιχο έγινε για τις βασικές ρυθμίσεις του νέου init. Για να στηθεί θα έπρεπε να δημιουργηθούν κάποια trees και να ενεργοποιηθούν σε αυτά υπηρεσίες, αλλά αυτό δεν θα μπορούσε να γίνει κατά την εγκατάσταση.
Γράφτηκε λοιπόν ένα απλό και μικρό script (66boot-initial-setup) [7] που δημιουργεί τα αναγκαία trees (boot, default και runit), ενεργοποιεί services και δημιουργεί ένα symlink για πρόσβαση στο αρχείο ρυθμίσεων του boot@system, ενώ ένα έγγραφο που περιγράφει την διαδικασία προστέθηκε στο void-66-services [8].

Runit

Το πρόβλημα την μετάβασης από τις runit services στα 66 frontends παρέμενε όμως. Δεν είναι εύκολο να δοκιμαστούν 500 services στο νέο σύστημα ώστε να εξασφαλιστεί η απροβλημάτιστη λειτουργία τους. Όσο διαρκεί η μετατροπή, θα έπρεπε να υπάρχει τρόπος να χρησιμοποιήσει κάποιος και τις υπόλοιπες υπηρεσίες. Η λύση βρέθηκε όταν ο @teldra έγραψε ένα frontend που απλά έτρεχε ένα runit supervision tree πάνω στο 66 -όταν ακόμα δεν υπήρχαν  frontends για το void. Έτσι, μπορούσε κάποιος να εκκινεί με τις υπηρεσίες του boot@ και στην συνέχεια να χρησιμοποιεί τις υπηρεσίες του runit. Το frontend αρχικά υλοποιήθηκε για να καλεί το script /etc/runit/2 του πακέτου void-runit. Εξελίχθηκε σημαντικά [9] και αποτελεί μια αξιόπιστη λύση, που μπορεί να χρησιμοποιηθεί για την συντριπτική πλειοψηφία των runit run scripts.

Μια ενδιαφέρουσα… εκκίνηση

Μετά από ένα χρόνο και πλέον ενασχόλησης, είμαι μάλλον περισσότερο πεπεισμένος για το πόσα καλή επιλογή είναι το 66 για ένα σύγχρονο σύστημα linux. Τα προβλήματα που εμφανίστηκαν έχουν αντιμετωπιστεί σε μεγάλο βαθμό και ενώ σίγουρα μένει αρκετή δουλειά, κάτι που ξεκίνησε σαν απλό πείραμα φαίνεται να προχωρά ικανοποιητικά. Υπάρχει εξαιρετική συνεργασία με το upstream και βοήθεια, ενώ οι μελλοντικές εξελίξεις στο ίδιο το 66 (αλλά και στο s6-rc) αναμένονται πολύ ενδιαφέρουσες. Θεωρώ ότι στην προσπάθεια αυτή έμαθα πολλά και νομίζω είναι δύσκολο να ευχαριστήσω επαρκώς τους ανθρώπους με τους οποίους συνεργάστηκα - περισσότερο τους Eric Vidal, @teldra, @flexibeast και @zenfailure.

Υπάρχει όμως κάτι ακόμα που πιστεύω ότι πρέπει να διευκρινιστεί. Τα πιο σημαντικά κατά τη γνώμη μου χαρακτηριστικά του 66 έχουν διατυπωθεί στο προηγούμενο άρθρο της σειράς. Όμως έχουν τόσο σημασία αυτά, όσο και ο τρόπος που υλοποιούνται καθώς και το πως αυτός μπορεί να επεκταθεί για να αποκτήσει ένα σύστημα βασισμένο σε process supervision περισσότερες δυνατότητες. Αυτό ελπίζω να αναλυθεί σε μια νέα μικρή σειρά άρθρων.

__________________________________
[1] https://github.com/void-linux/void-runit
[2] https://github.com/void-linux/void-packages/pull/29115
[3] https://github.com/void-linux/void-packages/pull/25743
[4]  https://github.com/void-linux/void-packages/pull/21142
[5] https://github.com/void-linux/void-packages/pull/23122
[6] https://codeberg.org/mobinmob/void-66
[7] https://github.com/void-linux/void-packages/blob/ec7b534a8ce82b6eeb3f184094b2c0a1dacc7c7d/srcpkgs/boot-66serv/files/66boot-initial-setup
[8] https://github.com/mobinmob/void-66-services/blob/master/conf/void-66-conf.md
[9] https://github.com/void-linux/void-packages/blob/ec7b534a8ce82b6eeb3f184094b2c0a1dacc7c7d/srcpkgs/boot-66serv/files/runit