Η δημιουργία μιας εφαρμογής δημιουργίας αντιγράφων ασφαλείας που λειτουργεί σε οποιαδήποτε διανομή δεν είναι εύκολη δουλειά. Για να διασφαλίσετε ότι το Veeam Agent για Linux λειτουργεί σε διανομές από το Red Hat 6 και το Debian 6, έως το OpenSUSE 15.1 και το Ubuntu 19.04, πρέπει να λύσετε μια σειρά προβλημάτων, ειδικά αν σκεφτείτε ότι το προϊόν λογισμικού περιλαμβάνει μια λειτουργική μονάδα πυρήνα.
Το άρθρο δημιουργήθηκε με βάση υλικά από ομιλία στο συνέδριο .
Το Linux δεν είναι απλώς ένα από τα πιο δημοφιλή λειτουργικά συστήματα. Ουσιαστικά πρόκειται για μια πλατφόρμα με βάση την οποία μπορείς να φτιάξεις κάτι μοναδικό, κάτι δικό σου. Χάρη σε αυτό, το Linux έχει πολλές διανομές που διαφέρουν ως προς το σύνολο των στοιχείων λογισμικού τους. Και εδώ προκύπτει ένα πρόβλημα: για να λειτουργήσει ένα προϊόν λογισμικού σε οποιαδήποτε διανομή, πρέπει να λάβετε υπόψη τα χαρακτηριστικά του καθενός.
Διαχειριστές πακέτων. .deb έναντι .rpm
Ας ξεκινήσουμε με το προφανές πρόβλημα της διανομής του προϊόντος σε διαφορετικές διανομές.
Ο πιο τυπικός τρόπος διανομής προϊόντων λογισμικού είναι να τοποθετήσετε το πακέτο σε ένα αποθετήριο, έτσι ώστε ο διαχειριστής πακέτων που είναι ενσωματωμένος στο σύστημα να μπορεί να το εγκαταστήσει από εκεί.
Ωστόσο, έχουμε δύο δημοφιλείς μορφές πακέτων: rpm и deb. Αυτό σημαίνει ότι όλοι θα πρέπει να στηρίξουν.
Στον κόσμο των πακέτων deb, το επίπεδο συμβατότητας είναι εκπληκτικό. Το ίδιο πακέτο εγκαθίσταται και λειτουργεί εξίσου καλά τόσο στο Debian 6 όσο και στο Ubuntu 19.04. Τα πρότυπα για τη διαδικασία δημιουργίας πακέτων και εργασίας με αυτά, που ορίζονται στις παλιές διανομές του Debian, παραμένουν σχετικά στο νέο Linux Mint και στο βασικό λειτουργικό σύστημα. Επομένως, στην περίπτωση του Veeam Agent για Linux, αρκεί ένα πακέτο deb για κάθε πλατφόρμα υλικού.
Όμως στον κόσμο των πακέτων στροφών οι διαφορές είναι μεγάλες. Πρώτον, λόγω του γεγονότος ότι υπάρχουν δύο εντελώς ανεξάρτητοι διανομείς, η Red Hat και η SUSE, για τους οποίους η συμβατότητα είναι εντελώς περιττή. Δεύτερον, αυτοί οι διανομείς έχουν κιτ διανομής από αυτούς. υποστήριξη και πειραματικό. Δεν υπάρχει ανάγκη για συμβατότητα ούτε μεταξύ τους. Αποδείχθηκε ότι τα el6, el7 και el8 έχουν τα δικά τους πακέτα. Ξεχωριστό πακέτο για το Fedora. Πακέτα για τα SLES11 και 12 και ένα ξεχωριστό για το openSUSE. Το κύριο πρόβλημα είναι οι εξαρτήσεις και τα ονόματα πακέτων.
Πρόβλημα εξάρτησης
Δυστυχώς, τα ίδια πακέτα συχνά καταλήγουν με διαφορετικά ονόματα σε διαφορετικές διανομές. Παρακάτω είναι μια μερική λίστα με τις εξαρτήσεις του πακέτου veeam.
Για το EL7:
Για το SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- θρυαλλίδες
- αρχείο-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc + + 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Ως αποτέλεσμα, η λίστα των εξαρτήσεων είναι μοναδική για τη διανομή.
Αυτό που χειροτερεύει είναι όταν μια ενημερωμένη έκδοση αρχίζει να κρύβεται κάτω από το παλιό όνομα πακέτου.
Παράδειγμα:
Το πακέτο έχει ενημερωθεί στο Fedora 24 καταγγέλλει από την έκδοση 5 έως την έκδοση 6. Το προϊόν μας κατασκευάστηκε με την έκδοση 5 για να διασφαλίσει τη συμβατότητα με παλαιότερες διανομές. Για να χρησιμοποιήσω την παλιά 5η έκδοση της βιβλιοθήκης στο Fedora 24, έπρεπε να χρησιμοποιήσω το πακέτο ncurses-compat-libs.
Ως αποτέλεσμα, υπάρχουν δύο πακέτα για το Fedora, με διαφορετικές εξαρτήσεις.
Ακόμη πιο ενδιαφέρον. Μετά την επόμενη ενημέρωση διανομής, το πακέτο ncurses-compat-libs με την έκδοση 5 της βιβλιοθήκης αποδεικνύεται ότι δεν είναι διαθέσιμη. Είναι ακριβό για έναν διανομέα να σύρει παλιές βιβλιοθήκες σε μια νέα έκδοση της διανομής. Μετά από κάποιο χρονικό διάστημα, το πρόβλημα επαναλήφθηκε στις διανομές SUSE.
Ως αποτέλεσμα, ορισμένες διανομές έπρεπε να εγκαταλείψουν τη ρητή εξάρτησή τους από ncurses-libsκαι διορθώστε το προϊόν έτσι ώστε να μπορεί να λειτουργεί με οποιαδήποτε έκδοση της βιβλιοθήκης.
Παρεμπιπτόντως, στην έκδοση 8 του Red Hat δεν υπάρχει πλέον πακέτο meta Πύθων, που αναφερόταν στο παλιό καλό python 2.7. υπάρχει python2 и Πύθων3.
Εναλλακτική λύση για τους διαχειριστές πακέτων
Το πρόβλημα με τις εξαρτήσεις είναι παλιό και είναι προφανές εδώ και καιρό. Απλά θυμηθείτε την κόλαση του Dependency.
Για να συνδυάσετε διάφορες βιβλιοθήκες και εφαρμογές, ώστε να λειτουργούν όλες σταθερά και να μην έρχονται σε σύγκρουση - στην πραγματικότητα, αυτή είναι η εργασία που προσπαθεί να λύσει οποιοσδήποτε διανομέας Linux.
Ο διαχειριστής πακέτων προσπαθεί να λύσει αυτό το πρόβλημα με έναν εντελώς διαφορετικό τρόπο. Ζωηρός από το Canonical. Η κύρια ιδέα: η εφαρμογή εκτελείται σε ένα sandbox απομονωμένο και προστατευμένο από το κύριο σύστημα. Εάν μια εφαρμογή απαιτεί βιβλιοθήκες, παρέχονται με την ίδια την εφαρμογή.
Flatpak σας επιτρέπει επίσης να εκτελείτε εφαρμογές σε sandbox χρησιμοποιώντας κοντέινερ Linux. Χρησιμοποιείται επίσης η ιδέα του sandbox AppImage.
Αυτές οι λύσεις σας επιτρέπουν να δημιουργήσετε ένα πακέτο για οποιαδήποτε διανομή. Σε περίπτωση που Flatpak η εγκατάσταση και η εκκίνηση της εφαρμογής είναι δυνατή ακόμη και χωρίς τη γνώση του διαχειριστή.
Το κύριο πρόβλημα είναι ότι δεν μπορούν να εκτελεστούν όλες οι εφαρμογές σε sandbox. Μερικοί άνθρωποι χρειάζονται άμεση πρόσβαση στην πλατφόρμα. Δεν μιλάω καν για ενότητες πυρήνα, που εξαρτώνται αυστηρά από τον πυρήνα και δεν ταιριάζουν στην έννοια του sandbox.
Το δεύτερο πρόβλημα είναι ότι οι διανομές που είναι δημοφιλείς στο εταιρικό περιβάλλον από την Red Hat και το SUSE δεν περιέχουν ακόμη υποστήριξη για Snappy και Flatpak.
Από αυτή την άποψη, το Veeam Agent για Linux δεν είναι διαθέσιμο καθόλου .
Για να ολοκληρώσω την ερώτηση σχετικά με τους διαχειριστές πακέτων, θα ήθελα να σημειώσω ότι υπάρχει μια επιλογή να εγκαταλείψουμε εντελώς τους διαχειριστές πακέτων συνδυάζοντας δυαδικά αρχεία και ένα σενάριο για την εγκατάστασή τους σε ένα πακέτο.
Μια τέτοια δέσμη σάς επιτρέπει να δημιουργήσετε ένα κοινό πακέτο για διαφορετικές διανομές και πλατφόρμες, να πραγματοποιήσετε μια διαδραστική διαδικασία εγκατάστασης, πραγματοποιώντας την απαραίτητη προσαρμογή. Τέτοια πακέτα για Linux έχω συναντήσει μόνο από το VMware.
Πρόβλημα ενημέρωσης
Ακόμα κι αν επιλυθούν όλα τα ζητήματα εξάρτησης, το πρόγραμμα μπορεί να εκτελείται διαφορετικά στην ίδια διανομή. Πρόκειται για ενημερώσεις.
Υπάρχουν 3 στρατηγικές ενημέρωσης:
- Το πιο απλό είναι να μην ενημερώνεστε ποτέ. Ρύθμισα τον διακομιστή και τον ξέχασα. Γιατί να ενημερώσετε εάν όλα λειτουργούν; Τα προβλήματα ξεκινούν την πρώτη φορά που επικοινωνείτε με την υποστήριξη. Ο δημιουργός της διανομής υποστηρίζει μόνο την ενημερωμένη έκδοση.
- Μπορείτε να εμπιστευτείτε τον διανομέα και να ρυθμίσετε τις αυτόματες ενημερώσεις. Σε αυτήν την περίπτωση, μια κλήση στην υποστήριξη είναι πιθανό αμέσως μετά από μια ανεπιτυχή ενημέρωση.
- Η επιλογή της μη αυτόματης ενημέρωσης μόνο μετά την εκτέλεση σε δοκιμαστική υποδομή είναι η πιο αξιόπιστη, αλλά δαπανηρή και χρονοβόρα. Δεν μπορούν όλοι να το αντέξουν οικονομικά.
Εφόσον διαφορετικοί χρήστες χρησιμοποιούν διαφορετικές στρατηγικές ενημέρωσης, είναι απαραίτητο να υποστηρίζεται τόσο η πιο πρόσφατη έκδοση όσο και όλες οι προηγούμενες εκδόσεις. Αυτό περιπλέκει τη διαδικασία ανάπτυξης και δοκιμών και προσθέτει πονοκεφάλους στην ομάδα υποστήριξης.
Ποικιλία πλατφορμών υλικού
Οι διαφορετικές πλατφόρμες υλικού είναι ένα πρόβλημα που αφορά κυρίως τον εγγενή κώδικα. Τουλάχιστον, πρέπει να συλλέγετε δυαδικά αρχεία για κάθε υποστηριζόμενη πλατφόρμα.
Στο έργο Veeam Agent for Linux, δεν μπορούμε ακόμα να υποστηρίξουμε κάτι παρόμοιο με αυτό το RISC.
Δεν θα σταθώ λεπτομερώς σε αυτό το θέμα. Θα περιγράψω μόνο τα κύρια προβλήματα: τύπους που εξαρτώνται από την πλατφόρμα, όπως π.χ size_t, στοίχιση δομής και σειρά byte.
Στατική ή/και δυναμική σύνδεση
Αλλά το ερώτημα είναι "Πώς να συνδεθώ με βιβλιοθήκες - δυναμικά ή στατικά;" αξίζει να συζητηθεί.
Κατά κανόνα, οι εφαρμογές C/C++ στο Linux χρησιμοποιούν δυναμική σύνδεση. Αυτό λειτουργεί εξαιρετικά εάν η εφαρμογή έχει κατασκευαστεί ειδικά για μια συγκεκριμένη διανομή.
Εάν η εργασία είναι να καλύψετε διάφορες διανομές με ένα δυαδικό αρχείο, τότε πρέπει να εστιάσετε στην παλαιότερη υποστηριζόμενη διανομή. Για εμάς, αυτό είναι το Red Hat 6. Περιέχει gcc 4.4, το οποίο ακόμη και το πρότυπο C++11 δεν υποστηρίζει .
Δημιουργούμε το έργο μας χρησιμοποιώντας gcc 6.3, το οποίο υποστηρίζει πλήρως την C++14. Φυσικά, σε αυτήν την περίπτωση, στο Red Hat 6 θα πρέπει να έχετε μαζί σας το libstdc++ και τις βιβλιοθήκες boost. Ο ευκολότερος τρόπος είναι να συνδέσετε με αυτά στατικά.
Αλλά δυστυχώς, δεν μπορούν να συνδεθούν όλες οι βιβλιοθήκες στατικά.
Πρώτον, οι βιβλιοθήκες συστήματος όπως π.χ libfuse, libblkid είναι απαραίτητο να γίνει δυναμική σύνδεση για να διασφαλιστεί η συμβατότητά τους με τον πυρήνα και τα modules του.
Δεύτερον, υπάρχει μια λεπτότητα με τις άδειες.
Η άδεια GPL σας επιτρέπει βασικά να συνδέετε βιβλιοθήκες μόνο με κώδικα ανοιχτού κώδικα. Το MIT και το BSD επιτρέπουν τη στατική σύνδεση και επιτρέπουν τη συμπερίληψη βιβλιοθηκών σε ένα έργο. Ωστόσο, το LGPL δεν φαίνεται να έρχεται σε αντίθεση με τη στατική σύνδεση, αλλά απαιτεί την κοινή χρήση των αρχείων που είναι απαραίτητα για τη σύνδεση.
Γενικά, η χρήση δυναμικής σύνδεσης θα σας αποτρέψει από το να χρειαστεί να παρέχετε οτιδήποτε.
Δημιουργία εφαρμογών C/C++
Για να δημιουργήσετε εφαρμογές C/C++ για διαφορετικές πλατφόρμες και διανομές, αρκεί να επιλέξετε ή να δημιουργήσετε μια κατάλληλη έκδοση του gcc και να χρησιμοποιήσετε cross-compilers για συγκεκριμένες αρχιτεκτονικές και να συναρμολογήσετε ολόκληρο το σύνολο των βιβλιοθηκών. Αυτό το έργο είναι αρκετά εφικτό, αλλά αρκετά ενοχλητικό. Και δεν υπάρχει καμία εγγύηση ότι ο επιλεγμένος μεταγλωττιστής και οι βιβλιοθήκες θα παρέχουν μια λειτουργική έκδοση.
Ένα προφανές πλεονέκτημα: η υποδομή είναι πολύ απλοποιημένη, αφού ολόκληρη η διαδικασία κατασκευής μπορεί να ολοκληρωθεί σε ένα μηχάνημα. Επιπλέον, αρκεί να συλλέξετε ένα σύνολο δυαδικών αρχείων για μια αρχιτεκτονική και μπορείτε να τα συσκευάσετε σε πακέτα για διαφορετικές διανομές. Έτσι κατασκευάζονται τα πακέτα veeam για το Veeam Agent για Linux.
Σε αντίθεση με αυτήν την επιλογή, μπορείτε απλά να προετοιμάσετε μια φάρμα κατασκευής, δηλαδή πολλά μηχανήματα για συναρμολόγηση. Κάθε τέτοιο μηχάνημα θα παρέχει τη συλλογή εφαρμογών και τη συναρμολόγηση πακέτων για μια συγκεκριμένη διανομή και μια συγκεκριμένη αρχιτεκτονική. Σε αυτή την περίπτωση, η συλλογή πραγματοποιείται χρησιμοποιώντας τα μέσα που προετοιμάζονται από τον διανομέα. Δηλαδή, το στάδιο της προετοιμασίας του μεταγλωττιστή και της επιλογής βιβλιοθηκών εξαλείφεται. Επιπλέον, η διαδικασία κατασκευής μπορεί εύκολα να παραλληλιστεί.
Υπάρχει, ωστόσο, ένα μειονέκτημα σε αυτήν την προσέγγιση: για κάθε διανομή εντός της ίδιας αρχιτεκτονικής, θα πρέπει να συλλέξετε το δικό σας σύνολο δυαδικών αρχείων. Ένα άλλο μειονέκτημα είναι ότι τόσο μεγάλος αριθμός μηχανών πρέπει να συντηρηθεί και πρέπει να διατεθεί μεγάλος χώρος στο δίσκο και RAM.
Αυτός είναι ο τρόπος με τον οποίο μεταγλωττίζονται τα πακέτα KMOD της μονάδας πυρήνα veeamsnap για διανομές Red Hat.
Ανοίξτε την υπηρεσία κατασκευής
Συνάδελφοι από το SUSE προσπάθησαν να εφαρμόσουν κάποια μέση λύση με τη μορφή μιας ειδικής υπηρεσίας για τη σύνταξη εφαρμογών και τη συναρμολόγηση πακέτων - .
Ουσιαστικά, είναι ένας hypervisor που δημιουργεί μια εικονική μηχανή, εγκαθιστά όλα τα απαραίτητα πακέτα σε αυτήν, μεταγλωττίζει την εφαρμογή και χτίζει το πακέτο σε αυτό το απομονωμένο περιβάλλον, μετά το οποίο απελευθερώνεται η εικονική μηχανή.
Ο προγραμματιστής που εφαρμόζεται στο OpenBuildService θα καθορίσει πόσες εικονικές μηχανές μπορεί να εκκινήσει για βέλτιστη ταχύτητα δημιουργίας πακέτων. Ο ενσωματωμένος μηχανισμός υπογραφής θα υπογράψει τα πακέτα και θα τα ανεβάσει στο ενσωματωμένο αποθετήριο. Το ενσωματωμένο σύστημα ελέγχου έκδοσης θα αποθηκεύσει το ιστορικό αλλαγών και εκδόσεων. Το μόνο που μένει είναι απλώς να προσθέσετε τις πηγές σας σε αυτό το σύστημα. Δεν χρειάζεται καν να ρυθμίσετε μόνοι σας τον διακομιστή, μπορείτε να χρησιμοποιήσετε έναν ανοιχτό.
Υπάρχει, ωστόσο, ένα πρόβλημα: μια τέτοια θεριζοαλωνιστική μηχανή είναι δύσκολο να χωρέσει στην υπάρχουσα υποδομή. Για παράδειγμα, δεν απαιτείται έλεγχος έκδοσης· έχουμε ήδη τους δικούς μας για πηγαίους κώδικες. Ο μηχανισμός υπογραφής μας είναι διαφορετικός: χρησιμοποιούμε έναν ειδικό διακομιστή. Δεν χρειάζεται επίσης αποθετήριο.
Επιπλέον, η υποστήριξη για άλλες διανομές - για παράδειγμα, το Red Hat - υλοποιείται μάλλον κακώς, κάτι που είναι κατανοητό.
Το πλεονέκτημα μιας τέτοιας υπηρεσίας είναι η γρήγορη υποστήριξη για την επόμενη έκδοση της διανομής SUSE. Πριν από την επίσημη ανακοίνωση της κυκλοφορίας, τα πακέτα που είναι απαραίτητα για τη συναρμολόγηση αναρτώνται σε δημόσιο αποθετήριο. Μια νέα εμφανίζεται στη λίστα με τις διαθέσιμες διανομές στο OpenBuildService. Επιλέγουμε το πλαίσιο και προστίθεται στο σχέδιο κατασκευής. Έτσι, η προσθήκη μιας νέας έκδοσης της διανομής γίνεται σχεδόν με ένα κλικ.
Στην υποδομή μας, χρησιμοποιώντας το OpenBuildService, συγκεντρώνεται όλη η ποικιλία των πακέτων KMP της μονάδας πυρήνα veeamsnap για διανομές SUSE.
Στη συνέχεια, θα ήθελα να σταθώ σε ζητήματα ειδικά για τις ενότητες του πυρήνα.
πυρήνα ABI
Οι μονάδες πυρήνα του Linux έχουν ιστορικά διανεμηθεί σε μορφή πηγής. Γεγονός είναι ότι οι δημιουργοί του πυρήνα δεν επιβαρύνονται με την ανησυχία της υποστήριξης ενός σταθερού API για μονάδες πυρήνα, και ειδικά σε δυαδικό επίπεδο, που αναφέρεται περαιτέρω ως kABI.
Για να δημιουργήσετε μια ενότητα για έναν πυρήνα βανίλιας, χρειάζεστε οπωσδήποτε τις κεφαλίδες αυτού του συγκεκριμένου πυρήνα και θα λειτουργήσει μόνο σε αυτόν τον πυρήνα.
Το DKMS σάς επιτρέπει να αυτοματοποιείτε τη διαδικασία δημιουργίας μονάδων κατά την ενημέρωση του πυρήνα. Ως αποτέλεσμα, οι χρήστες του αποθετηρίου Debian (και των πολλών συγγενών του) χρησιμοποιούν μονάδες πυρήνα είτε από το αποθετήριο του διανομέα είτε μεταγλωττισμένες από την πηγή χρησιμοποιώντας DKMS.
Ωστόσο, αυτή η κατάσταση δεν ταιριάζει ιδιαίτερα στον τομέα των Επιχειρήσεων. Οι διανομείς αποκλειστικού κώδικα θέλουν να διανείμουν το προϊόν ως μεταγλωττισμένα δυαδικά αρχεία.
Οι διαχειριστές δεν θέλουν να διατηρήσουν τα εργαλεία ανάπτυξης σε διακομιστές παραγωγής για λόγους ασφαλείας. Οι διανομείς Enterprise Linux όπως η Red Hat και η SUSE αποφάσισαν ότι μπορούσαν να υποστηρίξουν σταθερό kABI για τους χρήστες τους. Το αποτέλεσμα ήταν πακέτα KMOD για Red Hat και πακέτα KMP για SUSE.
Η ουσία αυτής της λύσης είναι αρκετά απλή. Για μια συγκεκριμένη έκδοση της διανομής, το API του πυρήνα είναι παγωμένο. Ο διανομέας δηλώνει ότι χρησιμοποιεί τον πυρήνα, για παράδειγμα, 3.10, και κάνει μόνο διορθώσεις και βελτιώσεις που δεν επηρεάζουν τις διεπαφές του πυρήνα, και τα modules που συλλέγονται για τον πρώτο κιόλας πυρήνα μπορούν να χρησιμοποιηθούν για όλα τα επόμενα χωρίς εκ νέου μεταγλώττιση.
Η Red Hat ισχυρίζεται ότι είναι συμβατή με kABI για τη διανομή σε όλο τον κύκλο ζωής της. Δηλαδή, η συναρμολογημένη ενότητα για το rhel 6.0 (κυκλοφορία Νοεμβρίου 2010) θα πρέπει επίσης να λειτουργεί στην έκδοση 6.10 (έκδοση Ιουνίου 2018). Και αυτό είναι σχεδόν 8 χρόνια. Φυσικά, αυτό το έργο είναι αρκετά δύσκολο.
Έχουμε καταγράψει αρκετές περιπτώσεις όπου η μονάδα veeamsnap σταμάτησε να λειτουργεί λόγω προβλημάτων συμβατότητας kABI.
Αφού η λειτουργική μονάδα veeamsnap, που μεταγλωττίστηκε για το RHEL 7.0, αποδείχθηκε ότι δεν ήταν συμβατή με τον πυρήνα από το RHEL 7.5, αλλά φορτώθηκε και ήταν εγγυημένο ότι θα διακόψει τον διακομιστή, εγκαταλείψαμε εντελώς τη χρήση της συμβατότητας kABI για το RHEL 7.
Επί του παρόντος, το πακέτο KMOD για το RHEL 7 περιέχει ένα συγκρότημα για κάθε έκδοση έκδοσης και ένα σενάριο που φορτώνει τη λειτουργική μονάδα.
Η SUSE προσέγγισε το έργο της συμβατότητας kABI πιο προσεκτικά. Παρέχουν συμβατότητα kABI μόνο σε ένα service pack.
Για παράδειγμα, η κυκλοφορία του SLES 12 πραγματοποιήθηκε τον Σεπτέμβριο του 2014. Και το SLES 12 SP1 ήταν ήδη τον Δεκέμβριο του 2015, δηλαδή έχει περάσει λίγο περισσότερο από ένα χρόνο. Παρόλο που και οι δύο εκδόσεις χρησιμοποιούν τον πυρήνα 3.12, δεν είναι συμβατές με το kABI. Προφανώς, η διατήρηση της συμβατότητας kABI για μόλις ένα χρόνο είναι πολύ πιο εύκολη. Ο ετήσιος κύκλος ενημέρωσης λειτουργικής μονάδας πυρήνα δεν πρέπει να προκαλεί προβλήματα στους δημιουργούς λειτουργιών.
Ως αποτέλεσμα αυτής της πολιτικής SUSE, δεν έχουμε καταγράψει κανένα πρόβλημα με τη συμβατότητα kABI στη μονάδα μας veeamsnap. Είναι αλήθεια ότι ο αριθμός των πακέτων για το SUSE είναι σχεδόν μια τάξη μεγέθους μεγαλύτερος.
Patches και backports
Αν και οι διανομείς προσπαθούν να εξασφαλίσουν τη συμβατότητα με το kABI και τη σταθερότητα του πυρήνα, προσπαθούν επίσης να βελτιώσουν την απόδοση και να εξαλείψουν τα ελαττώματα αυτού του σταθερού πυρήνα.
Ταυτόχρονα, εκτός από τη δική τους «εργασία για τα σφάλματα», οι προγραμματιστές του εταιρικού πυρήνα Linux παρακολουθούν τις αλλαγές στον πυρήνα της βανίλιας και τις μεταφέρουν στον «σταθερό» τους.
Μερικές φορές αυτό οδηγεί σε νέα .
Στην τελευταία έκδοση του Red Hat 6, έγινε ένα λάθος σε μια από τις μικρές ενημερώσεις. Αυτό οδήγησε στο γεγονός ότι η μονάδα veeamsnap ήταν εγγυημένη ότι θα καταρρεύσει το σύστημα όταν κυκλοφόρησε το στιγμιότυπο. Έχοντας συγκρίνει τις πηγές του πυρήνα πριν και μετά την ενημέρωση, ανακαλύψαμε ότι έφταιγε το backport. Μια παρόμοια διόρθωση έγινε στην έκδοση 4.19 του πυρήνα βανίλιας. Απλώς αυτή η επιδιόρθωση λειτούργησε καλά στον πυρήνα της βανίλιας, αλλά κατά τη μεταφορά της στο "σταθερό" 2.6.32, προέκυψε πρόβλημα με το spinlock.
Φυσικά, όλοι έχουν πάντα λάθη, αλλά άξιζε να σύρετε τον κωδικό από το 4.19 στο 2.6.32, ρισκάροντας τη σταθερότητα;.. Δεν είμαι σίγουρος...
Το χειρότερο είναι όταν το μάρκετινγκ εμπλέκεται στη διελκυστίνδα μεταξύ «σταθερότητας» και «εκσυγχρονισμού». Το τμήμα μάρκετινγκ χρειάζεται ο πυρήνας της ενημερωμένης διανομής να είναι σταθερός, αφενός, και ταυτόχρονα να είναι καλύτερος σε απόδοση και να έχει νέα χαρακτηριστικά. Αυτό οδηγεί σε περίεργους συμβιβασμούς.
Όταν προσπάθησα να δημιουργήσω μια ενότητα στον πυρήνα 4.4 από το SLES 12 SP3, με έκπληξη βρήκα τη λειτουργικότητα από τη vanilla 4.8 σε αυτό. Κατά τη γνώμη μου, η υλοποίηση μπλοκ εισόδου/εξόδου του πυρήνα 4.4 από το SLES 12 SP3 μοιάζει περισσότερο με τον πυρήνα 4.8 από την προηγούμενη έκδοση του σταθερού πυρήνα 4.4 από το SLES12 SP2. Δεν μπορώ να κρίνω ποιο ποσοστό κώδικα μεταφέρθηκε από τον πυρήνα 4.8 στο SLES 4.4 για το SP3, αλλά δεν μπορώ καν να ονομάσω τον πυρήνα τον ίδιο σταθερό 4.4.
Το πιο δυσάρεστο σε αυτό είναι ότι όταν γράφετε μια ενότητα που θα λειτουργούσε εξίσου καλά σε διαφορετικούς πυρήνες, δεν μπορείτε πλέον να βασίζεστε στην έκδοση του πυρήνα. Πρέπει επίσης να λάβετε υπόψη τη διανομή. Είναι καλό που μερικές φορές μπορείτε να εμπλακείτε σε έναν ορισμό που εμφανίζεται μαζί με νέα λειτουργικότητα, αλλά αυτή η ευκαιρία δεν εμφανίζεται πάντα.
Ως αποτέλεσμα, ο κώδικας γίνεται κατάφυτος από περίεργες οδηγίες συλλογής υπό όρους.
Υπάρχουν επίσης ενημερώσεις κώδικα που αλλάζουν το τεκμηριωμένο API του πυρήνα.
Συνάντησα τη διανομή 5.16 και εξεπλάγην όταν είδαμε ότι η κλήση lookup_bdev σε αυτήν την έκδοση του πυρήνα άλλαξε τη λίστα των παραμέτρων εισόδου.
Για να το συγκεντρώσω, έπρεπε να προσθέσω ένα σενάριο στο makefile που ελέγχει εάν η συνάρτηση lookup_bdev έχει παράμετρο μάσκας.
Υπογραφή ενοτήτων πυρήνα
Ας επιστρέψουμε όμως στο θέμα της διανομής πακέτων.
Ένα από τα πλεονεκτήματα του σταθερού kABI είναι ότι οι μονάδες πυρήνα μπορούν να υπογραφούν ως δυαδικό αρχείο. Σε αυτήν την περίπτωση, ο προγραμματιστής μπορεί να είναι σίγουρος ότι η μονάδα δεν έχει καταστραφεί κατά λάθος ή δεν έχει τροποποιηθεί σκόπιμα. Μπορείτε να το ελέγξετε με την εντολή modinfo.
Οι διανομές Red Hat και SUSE σάς επιτρέπουν να ελέγξετε την υπογραφή της μονάδας και να τη φορτώσετε μόνο εάν το αντίστοιχο πιστοποιητικό είναι καταχωρημένο στο σύστημα. Το πιστοποιητικό είναι το δημόσιο κλειδί με το οποίο έχει υπογραφεί η ενότητα. Το διανέμουμε σε ξεχωριστή συσκευασία.
Το πρόβλημα εδώ είναι ότι τα πιστοποιητικά μπορούν είτε να ενσωματωθούν στον πυρήνα (οι διανομείς τα χρησιμοποιούν) είτε πρέπει να εγγραφούν στη μη πτητική μνήμη EFI χρησιμοποιώντας ένα βοηθητικό πρόγραμμα mokutil. Χρησιμότητα mokutil Κατά την εγκατάσταση ενός πιστοποιητικού, απαιτείται επανεκκίνηση του συστήματος και, ακόμη και πριν από τη φόρτωση του πυρήνα του λειτουργικού συστήματος, ζητά από τον διαχειριστή να επιτρέψει τη φόρτωση ενός νέου πιστοποιητικού.
Επομένως, η προσθήκη ενός πιστοποιητικού απαιτεί φυσική πρόσβαση διαχειριστή στο σύστημα. Εάν το μηχάνημα βρίσκεται κάπου στο σύννεφο ή απλώς σε ένα απομακρυσμένο δωμάτιο διακομιστή και η πρόσβαση γίνεται μόνο μέσω του δικτύου (για παράδειγμα, μέσω ssh), τότε θα είναι αδύνατη η προσθήκη πιστοποιητικού.
EFI σε εικονικές μηχανές
Παρά το γεγονός ότι το EFI υποστηρίζεται από καιρό σχεδόν από όλους τους κατασκευαστές μητρικών πλακών, κατά την εγκατάσταση ενός συστήματος, ο διαχειριστής μπορεί να μην σκέφτεται την ανάγκη για EFI και μπορεί να είναι απενεργοποιημένος.
Δεν υποστηρίζουν όλοι οι hypervisors EFI. Το VMWare vSphere υποστηρίζει EFI ξεκινώντας από την έκδοση 5.
Το Microsoft Hyper-V απέκτησε επίσης υποστήριξη EFI ξεκινώντας με το Hyper-V για Windows Server 2012R2.
Ωστόσο, στην προεπιλεγμένη διαμόρφωση αυτή η λειτουργία είναι απενεργοποιημένη για μηχανές Linux, πράγμα που σημαίνει ότι το πιστοποιητικό δεν μπορεί να εγκατασταθεί.
Στο vSphere 6.5, ορίστε την επιλογή Ασφαλής Εκκίνηση είναι δυνατή μόνο στην παλιά έκδοση της διεπαφής ιστού, η οποία εκτελείται μέσω Flash. Η διεπαφή ιστού στο HTML-5 είναι ακόμα πολύ πίσω.
Πειραματικές κατανομές
Και τέλος, ας εξετάσουμε το ζήτημα των πειραματικών διανομών και διανομών χωρίς επίσημη υποστήριξη. Από τη μία πλευρά, τέτοιες διανομές είναι απίθανο να βρεθούν στους διακομιστές σοβαρών οργανισμών. Δεν υπάρχει επίσημη υποστήριξη για τέτοιες διανομές. Επομένως, παρέχετε αυτά. Το προϊόν δεν μπορεί να υποστηριχθεί σε μια τέτοια διανομή.
Ωστόσο, τέτοιες διανομές γίνονται μια βολική πλατφόρμα για τη δοκιμή νέων πειραματικών λύσεων. Για παράδειγμα, εκδόσεις Fedora, OpenSUSE Tumbleweed ή Unstable του Debian. Είναι αρκετά σταθερά. Έχουν πάντα νέες εκδόσεις προγραμμάτων και πάντα νέο πυρήνα. Σε ένα χρόνο, αυτή η πειραματική λειτουργία μπορεί να καταλήξει σε ένα ενημερωμένο RHEL, SLES ή Ubuntu.
Επομένως, εάν κάτι δεν λειτουργεί σε μια πειραματική διανομή, αυτός είναι ένας λόγος για να καταλάβετε το πρόβλημα και να το λύσετε. Πρέπει να είστε προετοιμασμένοι για το γεγονός ότι αυτή η λειτουργία θα εμφανιστεί σύντομα στους διακομιστές παραγωγής των χρηστών.
Μπορείτε να μελετήσετε την τρέχουσα λίστα των επίσημα υποστηριζόμενων διανομών για την έκδοση 3.0 . Αλλά ο πραγματικός κατάλογος των διανομών στις οποίες μπορεί να λειτουργήσει το προϊόν μας είναι πολύ ευρύτερος.
Προσωπικά, με ενδιέφερε το πείραμα με το Elbrus OS. Μετά την οριστικοποίηση της συσκευασίας veeam, το προϊόν μας εγκαταστάθηκε και λειτουργούσε. Έγραψα για αυτό το πείραμα στο Habré in .
Λοιπόν, η υποστήριξη για νέες διανομές συνεχίζεται. Περιμένουμε να κυκλοφορήσει η έκδοση 4.0. Το Beta πρόκειται να εμφανιστεί, γι' αυτό προσέχετε !
Πηγή: www.habr.com