Μια μικρή εισαγωγή στο OSTree

Σε αυτό το σύντομο σημείωμα θα μιλήσουμε για την τεχνολογία OSTree, μια τεχνολογία που θα αλλάξει τον τρόπο με τον οποίο αλληλεπιδρούμε με ένα σύστημα Linux αρκετά σύντομα, αν και αυτό είναι μια μεγάλη υπερβολή. Έχει ήδη αλλάξει τον τρόπο και πολλοί από εμάς την χρησιμοποιούμε ήδη, μόνο που δεν το ξέρουμε. Πως γίνεται αυτό και γιατί δεν την έχεις ακούσει; Απλό είναι η βάση που πατάει το flatpak. Επίσης διανομές όπως το Fedora Silverblue. Ας σηκώσουμε το καπάκι και ας δούμε λοιπόν τι ακριβώς είναι.

Τι είναι το OSTree;

Είχα γράψει για αυτό στο παρελθόν

Αν κάποιος καταλαβαίνει πως δουλεύει εσωτερικά το git μπορεί να καταλάβει και τον εσωτερικό τρόπο λειτουργίας του OSTree. Ουσιαστικά και τα δυο είναι σαν μια αποθήκη που κρατάει τις διαφορετικές εκδόσεις των αρχείων κάτω από ένα φάκελο. Και μπορούμε να επιστρέψουμε ανά πάσα στιγμή σε μια προηγούμενη έκδοση του δέντρου των φακέλων. Αυτό μπορεί να γίνει είτε σε επίπεδο όλου του συστήματος (όπως για παράδειγμα κάνουν διανομές όπως το EndlessOS ή το Fedora Silverblue) είτε σε επίπεδο μεμονωμένων εφαρμογών όπως κάνει ή τεχνολογία Flatpak.

Λίγη εξάσκηση με το τερματικό

Ας φτιάξουμε μια αποθήκη για τα αρχεία που θέλουμε

ostree –repo=myrepo init

και ας προσθέσουμε κάποια αρχεία (σε κάποιο άλλο κατάλογο)

mkdir tree
echo "Hello world!" > tree/hello.txt

Στην συνέχεια θα προσθέσουμε τον κατάλογο στην αποθήκη

ostree –repo=myrepo commit –branch=version1 tree/

Μπορούμε να σβήσουμε πλέον τα αρχικά αρχεία, και να δούμε τι υπάρχει στην αποθήκη

ostree –repo=myrepo refs
ostree –repo=myrepo ls version1
ostree –repo=myrepo cat version1 /hello.txt

επίσης μπορούμε να τα εξάγουμε σε κάποιον κατάλογο

ostree –repo=myrepo checkout version1 tree-checkout/

Μια χαρά δεν είμαστε με τα deb/rpm ;

Κάθε χρήστης έχει κάποια στιγμή πέσει σε μια προβληματική αναβάθμιση. Αλλά ακόμα και αν δεν υπάρχει κάποιο πρόβλημα εφόσον η αναβάθμιση ολοκληρωθεί, έχουμε την περίπτωση που δεν ολοκληρωθεί όπως για παράδειγμα σε μια διακοπή ρεύματος. Αν μιλάμε για κάποιο desktop μπορούμε να επέμβουμε, όπως επίσης και σε ένα server αν εξακολουθούμε να έχουμε δυνατότητα απομακρυσμένης σύνδεσης, αλλά δεν είναι οι μόνες περιπτώσεις. Τι γίνεται σε κάποιο embedded σύστημα όπως πχ σε ένα αυτοκίνητο;
Αν εγκαταστήσουμε μια εφαρμογή και δεν μας αρέσει πως την αφαιρούμε; Η μόνη λύση είναι η χρήση κάτι σαν το Timeshift ή να χρησιμοποιήσουμε τα snapshoots του συστήματος αρχείων, εφόσον είμαστε τυχεροί και αυτό υποστηρίζει μια τέτοια δυνατότητα. Το btrfs υποστηρίζει, αλλά οι περισσότεροι έχουμε ext4 που δεν. Αλλά αυτό είναι έξω από τον έλεγχο του διαχειριστή των πακέτων και είναι μια πολύ δραστική λύση. Και μπορούμε να επιστρέψουμε ένα βήμα μόνο πίσω κάθε φορά.

Δηλαδή αντικαθιστά τα deb/rpm ;

Όχι δεν είναι ένας διαχειριστής πακέτων, είναι απλά μια αποθήκη που δεν ξέρει τι περιέχει και ποιες έχουν τα αρχεία που περιέχει μεταξύ τους. Αυτό είναι η δουλεία ενός διαχειριστή πακέτων.
Αλλά μπορεί να κάνει ένα διαχειριστή πακέτων πολύ ποιο εύχρηστο. Αντί να αλλάζει απλά τα αρχεία στον δίσκο, μπορεί να φτιάξει πρώτα μια νέα δεντρική δομή, που να επικαλύπτει το παλιό σύστημα αρχείων και να κάνει τις αλλαγές εκεί. Στην συνέχεια να αντικαταστήσει το παλιό σύστημα αρχείων με το καινούργιο. Έτσι το παλιό σύστημα μένει απείραχτο, και οι αλλαγές θα γίνουν με την μία και όχι σταδιακά. Αντί να κάνεις αναβάθμιση των πακέτων κάνεις αναβάθμιση όλης της διανομής. Και δεν απαιτεί κάποιο ειδικό σύστημα αρχείων όπως πχ το btrfs. Πραγματικά φοβερό !

Με το OSTree το σύστημα των αρχείων κάτω από το /usr είναι μόνο για ανάγνωση, κανείς ούτε ο root δεν έχει λόγο να το πειράξει, άρα είναι εύκολο να ελεγχθεί και αν κάποιο κακόβουλο πρόγραμμα κατάφερε να το πειράξει. Μόνο οι κατάλογοι /etc και `/var’ υπάρχει λόγος να πειραχτούν. Κατά κάποιο τρόπο μοιάζει με τον τρόπο που λειτουργεί ένας server στο cloud. Το σύστημα των αρχείων μένει σταθερό πάντα και απλά ανεβαίνει σε κάποιο server αν αυξηθεί η ζήτηση. Οι αποθήκες για τα δεδομένα είναι εξωτερικές.

Άλλες τεχνολογίες

Οι χρήστες του Mint χρησιμοποιούν το Timeshift και οι χρήστες του SuSE το snapper σε btrfs. Αλλά δεν είναι μια ιδανική λύση όπως είδαμε, θα πρέπει με κάποιο τρόπο να κρατήσεις το /home και κάποιους άλλους καταλόγους εκτός. Το Timeshift με χαρά θα αντικαταστήσει και τα περιεχόμενα του /etc για παράδειγμα. Και αλλιώς θα χρησιμοποιήσουν τις δυνατότητες του btrfs τα δυο εργαλεία με ασύμβατους μεταξύ τους τρόπους. Και αν θέλεις docker με Timeshift απλά ατύχησες.

ChromiumOS updater εδώ έχουμε δυο διαφορετικές κατατμήσεις, οι αναβαθμίσεις θα συμβούν σε άλλη κατάτμηση. Μετά την επανεκκίνηση το σύστημα θα χρησιμοποιήσει την δεύτερη κατάτμηση. Μεγάλη σπατάλη χώρου και καθόλου βολικό. Το Ubuntu δουλεύει σε ένα παρόμοιο σχήμα αν και με λίγο λιγότερους περιορισμούς. Οι διανομές Clear Linux και NiXOS χρησιμοποιούν παρόμοιες τεχνολογίες. Το Conda έχει κάποιες ομοιότητες στην χρήση των hardlinks.

Docker/Balena To Docker λειτουργεί με επίπεδα, σαν ένα ρυζόχαρτο σε ένα τεχνικό σχέδιο, όπου πάνω μπορούν να προστεθούν αλλαγές χωρίς να πειράξεις το αρχικό σχέδιο. Ένα μειονέκτημα είναι πως δεν μπορείς να κάνεις έλεγχο για κάποιο μεμονωμένο αρχείο, και προσωπικά πάντα ενοχλούσε την αισθητική μου αυτή η λύση.

Συμπεράσματα

Το Linux αλλάζει και γίνεται ποιο σταθερό και ποιο ασφαλές μέρα με την μέρα. Ανεξάρτητα αν μας αρέσουν αυτές οι αλλαγές, ή μάλλον καλύτερα για να ξέρουμε και να έχουμε γνώμη αν μας αρέσουν αυτές οι αλλαγές, θα πρέπει να γνωρίζουμε κάποια πράγματα για το ποιες είναι αυτές και τι σκοπό εξυπηρετούν. Έχω δει για παράδειγμα χρήστες που να κατηγορούν το flatpak γιατί δεν παρέχει καλή απομόνωση των εφαρμογών και ταυτόχρονα να παραπονιούνται για το ότι η απομόνωση που παρέχει δεν τους βολεύει :grin:. (Η απομόνωση των εφαρμογών αξίζει να μελετηθεί σε μελλοντικά αρθράκια)

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

Update

O Will Thompson από την ομάδα του Endless OS κάνει μια ανάλυση του αναφερόμενου και του πραγματικού χώρου στον δίσκο με το OS Tree. Το Enless OS ερχετε μαζί με 58 εφαρμογές Flatpak σε 13 διαφορετικά runtimes.

https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

Διαβάστε

4 «Μου αρέσει»

Ερωτησεις:

Εαν καταλαβα καλα… το OSTree ειναι σαν εναν επιπροσθετο στρωμα (overlay) επανω απο ενα βασικο συστημα (Αν δεν το εχω καταλαβει καλα για ξαναεξηγησε αν γινεται σε παρακαλω).

Αν το εχω καταλαβει καλα μεχρι εδω οκ.

Αν θελουμε ομως πχ να κανουμε ενα apt-get dist-upgrade για να κανουμε update ολο το συστημα με το OSTree επανω…αυτο γινεται;

Η το OSTree περιπλεκει περισσοτερο τετοιες διαδικασιες;

Και μετα το dist-upgrade πως αφομοιωνονται οι αλλαγες επανω στο OSTree;

Πρεπει να στισουμε στο δικτυο μας και OSTree server για να κραταμε τετοιες αλλαγες;

Μηπως αντι για κατι σαν το OSTree θα ηταν καλητερο να δωθει η δυνατοτητα στο ext4 να υποστιριξει snapshots με τα καταλληλα εργαλεια και snapshots που να ειναι και καταλληλα για embedded συστηματα αλλα και για Desktop;

Sorry για τις απορειες. Με καθε καινουργια τεχνολογια πρεπει να γινονται ομως τετοιες ερωτησεις.

Είναι ακριβώς όπως το git. Ένας κώδικας ενός προγράμματος είναι ουσιαστικά μια δομή με αρχεία μέσα σε καταλόγους. Όταν τραβήξεις τις αλλαγές από ένα αποθετήριο (πχ το github) , είτε θα τις φέρεις όλες είτε δεν θα τι φέρεις. Όταν πας να τις εφαρμόσεις είτε αυτές θα εφαρμοστούν είτε όχι. Σε καμία περίπτωση δεν θα έχεις μισές αλλαγές. Επίσης μπορείς να έχεις σε δυο διαφορετικούς καταλόγους δυο διαφορετικές εκδόσεις του ίδιου προγράμματός.

Το πρώτο γνωστό Linux το Slackware δεν είχε καν διαχειριστή για πακέτα, απλά είχε μια σειρά από αρχεία tgz σε δισκέτες και απλά τα αποσυμπίεζες. Ούτε δυνατότητα να δεις αν κάποιο αρχείο άλλαξε ούτε δυνατότητα για εξαρτήσεις και αν θέλεις να φτιάξει ένα πακέτο απλά θα συμπιέσεις κάποια αρχεία. Απο την άλλη σήμερα πόσος κόσμος ξέρει να πακετάρει και να φτιάξει ένα δικό του deb; Το apt έχει πέραν κάθε αμφιβολίας πειπλέξει κατά πού τέτοιες διαδικασίες.
Σε ένα άλλο παράδειγμα σαφώς είναι ποιο πολύπλοκο να έχεις undo/redo σε κάποιο πρόγραμμα από το να μην έχεις. Όταν βγήκαν τα γραφικά προγράμματα εργασίας έπρεπε κάθε προγραμματιστής να μάθει το πως. Αλλά δεν άξιζε τον κόπο;
Αλλά τα παραπάνω είναι “εσωτρερική” πολυπλοκότητα. Εμένα με απασχολεί περισσότερο η “εξωτερική πολυπλοκότητα” τι βλέπω όχι σαν προγραμματιστής, αλλά σαν χρήστης του συστήματος. Και ένα undo/redo έμαθα αμέσως τι κάνει και πως να το αξιοποιήσω. Ένα apt update και ένα flatpak update δεν έχει κάποιοα νοητική διαφορά. Και ιδανικά μια μέρα θα έχω ένα gui με ένα μόνο κουμπάκι.
Ένα δέντρο του OSTree είναι ένα κανονικό δέντρο αρχείων. Δεν έχω καμία ένδειξη πως είναι κάτι τέτοιο, όταν κάνεις ls όποιος τσεκάρει τους σκληρούς σύνδεσμους να σηκώσει το χέρι.

Όπως ακριβώς το git θέλεις κάποιον server για να κάνεις το οτιδήποτε; Όχι. Μπορείς να τρέξει τις εντολές του άρθρου και να δεις ακριβώς τι συμβαίνει. Αλλά δεν θα πάρεις μια εγκατάστασή και θα την γυρίσεις σε OSTree μόνος σου. Θα ξεκινήσεις με μια διανομή που θα έχει εξαρχής χτιστεί πάνω στο OSTree.

Θα κάναμε τότε την μισή δουλεία. Η μάλλον ούτε το 50% γιατί έχουμε πάνω απο 100 συστήματα αρχείων είτε τοπικά είτε απομακρυσμένα, κατανεμημένα ή όχι, ιστορικά κλπ. Σε πόσα από αυτά θα πρέπει να προστεθεί υποστήριξη; Το OsTree απαιτεί μόνο υποστήριξη για “σκληρούς συνδέσμους”
Επίσης θα πρέπει να φτιαχτεί και να επιβληθεί μια προδιαγραφή που δεν υπάρχει. Σε μια οικοδομή κάποιες εσκαφές τις κάνεις με εσκαφέα, κάποιες με το χέρι και κάποιες με κουταλάκι (αρχαιολογία) τα snapshoots είναι ο εσκαφέας πολύ χοντροκομένη λύση. Δες και εδώ την παράγραφο για " Combining dpkg/rpm + (BTRFS/LVM)" όπου κάνει μια τεχνική ανάλυση.

Υπάρχουν 3 λύσεις για το πρόβλημα. Τα snapshoost, τα overlays του docker και το OSTree. To τελευταίο κατά την γνώμη μου φέρνει τις λιγότερες αλλαγές και είναι ποιο συμβατό με τον παλιό τρόπο. Απλά στο τέλος έχεις ένα σύνηθες απλό σύστημα αρχείων.

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

1 «Μου αρέσει»

Update: Και μόλις έπεσα σε ένα project που θα μπορούσε να ωφεληθεί από το OStree. Δυστυχώς δεν το επέλεξαν με αποτέλεσμα να να μην δουλεύει με ext4

https://www.phoronix.com/scan.php?page=news_item&px=Reflink-For-Wine-Patches

OK. Τωρα… ας πουμε πχ οτι ο χρηστης κανει install ενα προγραμμα, και ταυτοχρονα κανει edit ενα αρχειο στο LibreOffice.

Οπως το καταλαβαινω το OSTree περνοντας σαν βαση μια Debian-based διανομη θα πρεπει να κραταει τις αλλαγες στο:

  • /usr/{s}bin και /{s}bin καθως και /opt για να δει τι μπαινει και τι βγαινει με το καθε commit
  • /var/apt/ για να κραταει τις αλλαγες στην βαση των πακετων του apt γιατι σε περιπτωση που πας ενα commit πισω αυτες οι αλλαγες πρεπει να γυρισουν πισω στην πριν-το-commit κατασταση τους.
  • /home/ για οτι φακελους με στοιχεια των χρηστων θα πρεπει να κρατησει
  • /etc/ για αρχεια ρυθμισεων συστηματος
  • /lib για οτι βιβλιοθηκες μπουν και πρεπει να γυρισουν πισω.

Μαζι με τις αλλαγες στο /home που θα γυρισει στην προηγουμενη κατασταση (αφου ενα πισογυρισμα στο commit θα γυρισει τα παντα πισω) και ο χρηστης θα χασει τις αλλαγες στο αρχειο που επεξεργαζοταν στο LibreOffice.

Συμφωνα με την περιγραφη σου παραπανω (το η φερνεις ολες τις αλλαγες επανω η δεν τις φερνεις)… μηπως δεν ειναι η καταλληλη λυση το OSTree για αυτο το σεναριο καθημερινης χρησης;

Εαν δεν καταλαβα κατι εξηγησε το μου γιατι δεν το πολυπιανω το OSTree. Και αν μπορεις να δωσεις ενα παραδειγμα καθημερινης χρησης ισως με βοηθησει να δω το σε τι βοηθαει ακριβως το OSTree.

To flatpak είναι ένα καθημερινό παράδειγμα χρήσης του OSTree. Κάθε εφαρμογή είναι σε ένα δικό της δέντρο (Το flatpak χρησιμοποιεί και άλλες τεχνολογίες, δεν είναι το OSTree). Το Fedora SilverBlue είναι ένα παράδειγμα χρήσης σε επίπεδο όχι εφαρμογής, αλλά ολόκληρης διανομής. Το gnome continious[1] ένα άλλο. Η χρήση του είναι καθημερινή για πολύ κόσμο.

Αν το LibreOffice είναι σε Flatpak μπορεί να καταλάβει αν τρέχει μια παλαιότερη έκδοση και να ξεκινήσει αναβάθμιση. Μιας και οι ρυθμίσεις (κατάλογοι /etc και /var) είναι εκτός όπως προφανώς και το /home τίποτα δεν θα επηρεαστεί. Ας δούμε το ίδιο σενάριο με την κλασσική μέθοδο. Ενώ δουλεύεις σε ένα αρχείο κάνεις αναβάθμιση του LibreOffice. Η αναβάθμιση θα αντικαταστήσει τα αρχεία στον δίσκο [2] και κάποια χρονική στιγμή στον δίσκο θα υπάρχει μια μίξη από αρχεία της παλιάς και της καινούργιας έκδοσης. Αν αυτή την στιγμή καλέσεις για πρώτη φορά μια λειτουργία από ένα plugin ή βιβλιοθήκη θα έχεις κατάρρευση του προγράμματός και απώλεια των δεδομένων [3]. Αν οι πανικόβλητος χρήστης πατήσει το RESET θα έχουμε καταστροφή της βάσης δεδομένων του apt και το LibreOffice δεν θα λειτουργεί. Τα γραφικά εργαλεία πάνω στο apt συνήθως δεν βοηθούν και θα πρέπει να γράψεις μαγικά στο τερματικό, μαγικά που θα σου πει κάποιος από εδώ μέσα. Αλλά κάπως πρέπει να βγάλουμε και εμείς το ψωμί μας :smiley:

Αν κάτω απο το apt έχεις ostree (κάτι δυνατό με rpm αυτή την στιγμή πρακτικά) η εγκατάσταση θα γίνει σε άλλο κατάλογο. Δεν θα διαγραφεί και δεν θα αλλάξει κανένα αρχείο. Η αλλαγή μεταξύ των εκδόσεων θα είναι πάντα atomic. Μπορείς ενώ δουλεύεις το αρχείο με την παλιά έκδοση να ξεκινήσεις δουλεία με ένα δεύτερο αρχείο με την νέα έκδοση. Και οι δυο εκδόσεις θα υπάρχουν στον δίσκο σαν πραγματικά αρχεία και όχι σαν “inode φαντάσματα” [2].

[1] GNOME Continuous is a service that incrementally rebuilds and tests GNOME on every commit. The need to make and distribute snapshots for this system was the original inspiration for ostree.

[2] Αλλά μια αντικατάσταση δεν αλλάζει τα περιεχόμενα ενός αρχείου όσο αυτό είναι ανοικτό. Το νέο αρχείο μπαίνει σε ένα νέο inode και έχεις ένα ορφανό inode που δεν έχει καταχώρηση σε κανένα κατάλογο και θα διατραφεί αυτόματα. Αυτό το χαρακτηριστικό ο χωρισμός του ονόματος του αρχείου απο τα δεδομένα του αρχείου είναι που κάνει τις αναβαθμίσεις στο Linux τόσο καλές. Η έλλειψη του είναι εμφανής στα Windows που μπορεί να θέλουν και 4 reboot για μια αναβάθμιση.

[3] Κάτι που μου έχει συμβεί στον Firefox ουκ ολίγες φορές όταν είχε αναβαθμιστεί αυτόματα και χρησιμοποιούσα πρώτη φορά το flash. Σήμερα ο Firefox κάνει έλεγχο για αυτό το σενάριο και σου ζητά να τον επανεκκινήσεις (με OSTree δεν θα είχε κανένα πρόβλημα)

1 «Μου αρέσει»

A post was split to a new topic: Πως δουλεύει εσωτερικά το git

O Will Thompson από την ομάδα του Endless OS κάνει μια ανάλυση του αναφερόμενου και του πραγματικού χώρου στον δίσκο με το OS Tree. Το Enless OS ερχετε μαζί με 58 εφαρμογές Flatpak σε 13 διαφορετικά runtimes.

https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

Let’s compare the 20.08 and 21.08 versions of the freedesktop runtime:

wjt@camille:~$ du -sh /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/20.08
674M	/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/20.08
wjt@camille:~$ du -sh /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08
498M	/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08
wjt@camille:~$ du -sh /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/20.08 /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08
674M	/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/20.08
385M	/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08
wjt@camille:~$ echo $(( 498 - 385 ))                                                                                                                                       
113

113 MB (out of 498 MB for the smaller, more up-to-date 21.08 runtime) is shared between these two runtimes.