Το προφίλ μας στο Google Plus
0

openSUSE VPS: Μεθοδικό πέρασμα στο Leap 42.2

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

Περί τα μέσα του Νοεμβρίου κυκλοφόρησε το openSUSE Leap 42.2 κι αρκετοί που τρέχαμε το 42.1 αρχίσαμε τους σχεδιασμούς: αξίζει τη φασαρία η καθαρή εγκατάσταση του 42.2 ή μήπως μια αναβάθμιση στη νέα έκδοση είναι αρκετή; Αν το σκεφτούμε λίγο, γρήγορα συνειδητοποιούμε ότι κάθε προσέγγιση έχει τα θετικά και τ’ αρνητικά της.

Αναλυτικότερα, με την εκ νέου εγκατάσταση βρισκόμαστε μ’ ένα φρέσκο και πεντακάθαρο σύστημα. Μετά όμως ίσως δαπανήσουμε αρκετό χρόνο, προκειμένου να επαναφέρουμε το όποιο backup αλλά και για να βεβαιωθούμε ότι οι επιλογές και οι προτιμήσεις μας ισχύουν *και* στο καινούργιο περιβάλλον.

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

Υπάρχει και μια ενδιάμεση προσέγγιση, την οποία προτείνεται ν’ ακολουθούμε ειδικά αν στο σύστημά μας το /home είναι προσαρτημένο σε ξεχωριστή κατάτμηση. Πιο συγκεκριμένα, στον installer του openSUSE λέμε ότι θέλουμε να διαμορφώσει (format) όλα τα διαμερίσματα, εκτός από εκείνο του /home. Πραγματοποιούμε μ’ αυτό τον τρόπο μια καθαρότατη εγκατάσταση, αλλά επειδή τα αρχεία ρυθμίσεων του χρήστη ή των χρηστών είναι κάτω από το /home βεβαιωνόμαστε ότι οι εφαρμογές θα είναι ρυθμισμένες όπως ακριβώς θέλουμε. Βεβαίως, τα αρχεία ρυθμίσεων των υπηρεσιών, που βρίσκονται κάτω από το /etc, θα τα επαναφέρουμε από το backup μας.

Σημείωση. Σε κάθε περίπτωση, είναι νομίζουμε προφανές ότι πριν την εγκατάσταση ή την αναβάθμιση οφείλουμε να έχουμε φροντίσει για ένα καλό backup. Αν μάλιστα μιλάμε για VM ή για VPS, τότε και η λήψη ενός επίκαιρου snapshot προτείνεται ενθουσιωδώς.

Ορμώμενοι από πρόσφατη περιπέτεια που είχαμε μ’ ένα VPS στη Hetzner, δείχνουμε στη συνέχεια τη διαδικασία αναβάθμισης από το openSUSE Leap 42.1 στο 42.2. Θα εργαστούμε από τη γραμμή εντολών του λειτουργικού κι όχι μέσα από το περιβάλλον (γραφικών) του YaST. Παρεμπιπτόντως, αναλόγως του VPS provider ίσως έχουμε δυνατότητα *μόνο* για την πρώτη προσέγγιση, δηλαδή για αναβάθμιση από τη γραμμή εντολών.

Σημείωση. Αν κι απευθυνόμαστε κυρίως σε κατόχους VPS με openSUSE Leap 42.1, η διαδικασία που παρουσιάζουμε εφαρμόζεται παρόμοια και σε τυπικά PCs ή VMs — πάντα με openSUSE. Ας τονιστεί εξάλλου ότι η συγκεκριμένη μέθοδος αναβάθμισης δουλεύει χωρίς προβλήματα μόνον όταν *δεν* παρεμβάλλεται κάποια έκδοση μεταξύ αυτής που τώρα βρισκόμαστε κι εκείνης που θέλουμε να φτάσουμε.

Προετοιμασία VPS και μια τρύπα στο νερό
Συνδεόμαστε στον απομακρυσμένο host με το openSUSE Leap 42.1 και φροντίζουμε ώστε το λειτουργικό να είναι ενημερωμένο. Αρχικά πληκτρολογούμε:

sub0@vatnajokull:~> sudo zypper ref
sub0@vatnajokull:~> zypper lu

Μεταξύ των διαθέσιμων updates για το openSUSE του VPS μας, συμπεριλαμβανόταν και νέα έκδοση του πυρήνα.

Φρεσκάρισμα των αποθετηρίων του openSUSE Leap 42.1 (1) και προβολή των πακέτων για τα οποία υπάρχει νεότερη έκδοση (2). Μεταξύ αυτών συμπεριλαμβάνεται και το πακέτο με τον πυρήνα του συστήματος (3).

Φρεσκάρισμα των αποθετηρίων του openSUSE Leap 42.1 (1) και προβολή των πακέτων για τα οποία υπάρχει νεότερη έκδοση (2). Μεταξύ αυτών συμπεριλαμβάνεται και το πακέτο με τον πυρήνα του συστήματος (3).

Η αναβάθμιση των πακέτων ξεκινά με ένα

sub0@vatnajokull:~> sudo zypper patch

Γενικά, όταν έχουμε αναβάθμιση του πυρήνα τότε αμέσως μετά χρωστάμε κι ένα reboot.

Μετά την αναβάθμιση του πυρήνα οφείλουμε να επανεκκινούμε το σύστημα -- και μάλιστα το συντομότερο δυνατόν.

Μετά την αναβάθμιση του πυρήνα οφείλουμε να επανεκκινούμε το σύστημα — και μάλιστα το συντομότερο δυνατόν.

Πριν όμως το κάνουμε είναι πολύ καλή ιδέα να ρίχνουμε και μια ματιά στα μυνήματα που έχουν εμφανιστεί στο τερματικό.

Κατά την αναβάθμιση του πυρήνα προέκυψε πρόβλημα με τη ρύθμιση του bootloader, ο οποίος στο openSUSE είναι ο GRUB2. Το μήνυμα λάθους ήταν επεξηγηματικό και μπροστά στα μάτια μας, αλλά δεν το προσέξαμε.

Κατά την αναβάθμιση του πυρήνα προέκυψε πρόβλημα με τη ρύθμιση του bootloader, ο οποίος στο openSUSE είναι ο GRUB2. Το μήνυμα λάθους ήταν επεξηγηματικό και μπροστά στα μάτια μας, αλλά δεν το προσέξαμε.

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

Μετά το reboot απλά χαζεύαμε τα μηνύματα της διαδικασίας επανεκκίνησης στη web VNC console που προσφέρει ο VPS provider. Παρατηρήστε την έκδοση του πυρήνα στο μήνυμα καλωσορίσματος, ακριβώς πάνω από το login prompt: είναι η 4.1.34-33. Μάλιστα. Πιθανώς δεν θα θυμόσαστε ποια είναι η νέα έκδοση του πυρήνα που θα έπρεπε να έχουμε, έτσι δεν είναι; Βρείτε τη στα προηγούμενα screenshots. Αλλά γιατί να σας παιδεύουμε; Σας λέμε από εδώ ότι είναι η 4.1.36-38. Αντί λοιπόν για τη νέα έκδοση του πυρήνα είχαμε ακόμη την παλιά -- ή τουλάχιστον αυτό φανέρωνε το μήνυμα στην κονσόλα. Μήπως όμως επρόκειτο για λάθος μήνυμα; Θα έπρεπε να συνδεθούμε στο λογαριασμό του χρήστη μας και να ελέγξουμε.

Μετά το reboot απλά χαζεύαμε τα μηνύματα της διαδικασίας επανεκκίνησης στη web VNC console που προσφέρει ο VPS provider. Παρατηρήστε την έκδοση του πυρήνα στο μήνυμα καλωσορίσματος, ακριβώς πάνω από το login prompt: είναι η 4.1.34-33. Μάλιστα. Πιθανώς δεν θα θυμόσαστε ποια είναι η νέα έκδοση του πυρήνα που θα έπρεπε να έχουμε, έτσι δεν είναι; Βρείτε τη στα προηγούμενα screenshots. Αλλά γιατί να σας παιδεύουμε; Σας λέμε από εδώ ότι είναι η 4.1.36-38. Αντί λοιπόν για τη νέα έκδοση του πυρήνα είχαμε ακόμη την παλιά — ή τουλάχιστον αυτό φανέρωνε το μήνυμα στην κονσόλα. Μήπως όμως επρόκειτο για λάθος μήνυμα; Θα έπρεπε να συνδεθούμε στο λογαριασμό του χρήστη μας και να ελέγξουμε.

Συνδεθήκαμε (μέσω SSH) στο λογαριασμό του χρήστη μας στο VPS και πληκτρολογήσαμε uname -a. Όχι. Δεν είχαμε το νέο πυρήνα. Η διαδικασία της αναβάθμισής είχε αποτύχει. Ή μπορεί και να είχε πετύχει, αλλά ο bootloader εξακολουθούσε να φορτώνει τον προηγούμενο πυρήνα. Όπως και να 'χε, τον καινούργιο πυρήνα δεν τον χρησιμοποιούσαμε.

Συνδεθήκαμε (μέσω SSH) στο λογαριασμό του χρήστη μας στο VPS και πληκτρολογήσαμε uname -a. Όχι. Δεν είχαμε το νέο πυρήνα. Η διαδικασία της αναβάθμισής είχε αποτύχει. Ή μπορεί και να είχε πετύχει, αλλά ο bootloader εξακολουθούσε να φορτώνει τον προηγούμενο πυρήνα. Όπως και να ‘χε, τον καινούργιο πυρήνα δεν τον χρησιμοποιούσαμε.

Από το μήνυμα λάθους που αρχικά αποτύχαμε να προσέξουμε, φαινόταν ότι το πρόβλημα δεν αφορούσε στην ίδια την εγκατάσταση του πυρήνα αλλά στη ρύθμιση του bootloader. Πιο συγκεκριμένα, το θέμα ήταν στη γραμμή 9 του αρχείου /etc/default/grub. Με δικαιώματα root ανοίξαμε το αρχείο και “σχολιάσαμε” τη συγκεκριμένη γραμμή. Σε άλλες πέντε εγκαταστάσεις του openSUSE που συντηρούμε, η γραμμή αυτή δεν υπάρχει στο /etc/default/grub. Η παρουσία της στο VPS μάς κάνει να πιστεύουμε ότι οφείλεται σε misconfiguration, π.χ., λόγω κάποιας αλλαγής που επιχειρήσαμε να κάνουμε με το YaST κι απέτυχε να εφαρμοστεί.

Η συγκεκριμένη γραμμή στο /etc/default/grub ήταν εκεί λόγω κάποιου misconfiguration, αντί όμως να τη διαγράψουμε σκεφτήκαμε ότι είναι ασφαλέστερο να τη 'σχολιάσουμε'.

Η συγκεκριμένη γραμμή στο /etc/default/grub ήταν εκεί λόγω κάποιου misconfiguration, αντί όμως να τη διαγράψουμε σκεφτήκαμε ότι είναι ασφαλέστερο να τη “σχολιάσουμε”.

Όπως αναφέρεται στην αρχή του /etc/default/grub, μετά από κάθε αλλαγή στο αρχείο πρέπει να δίνουμε ένα grub2-mkconfig -o /boot/grub2/grub.cfg (με δικαιώματα root). Αμέσως μετά πληκτρολογούμε και sudo reboot, ώστε να βεβαιωθούμε ότι ο bootloader λειτουργεί σωστά.

Φροντίσαμε ώστε οι αλλαγές στο /etc/default/grub να ληφθούν υπόψη και, απ' ό,τι φάνηκε στα μηνύματα στο τερματικό, αυτή τη φορά ο bootloader εντόπισε τη νέα έκδοση του πυρήνα. Για να βεβαιωθούμε ότι όλα ήταν πλέον καλά, επανεκκινήσαμε το σύστημα.

Φροντίσαμε ώστε οι αλλαγές στο /etc/default/grub να ληφθούν υπόψη και, απ’ ό,τι φάνηκε στα μηνύματα στο τερματικό, αυτή τη φορά ο bootloader εντόπισε τη νέα έκδοση του πυρήνα. Για να βεβαιωθούμε ότι όλα ήταν πλέον καλά, επανεκκινήσαμε το σύστημα.

Από τα μηνύματα στο τερματικό ήμασταν βέβαιοι ότι αυτή τη φορά ο bootloader είχε λάβει υπόψη την παρουσία του νέου πυρήνα. Βεβαιωθήκαμε με μια επανεκκίνηση.

Αυτή τη φορά ο GRUB2 φόρτωσε τη νεότερη έκδοση του πυρήνα. Όλα καλά!

Αυτή τη φορά ο GRUB2 φόρτωσε τη νεότερη έκδοση του πυρήνα. Όλα καλά!

Από τη στιγμή που έχουμε ένα πλήρως ενημερωμένο σύστημα με το openSUSE Leap 42.1, είμαστε έτοιμοι να αναβαθμιστούμε στο 42.2. Πριν προχωρήσουμε, όμως, αν ο VPS provider παρέχει δυνατότητα για snapshots τότε προτείνεται *ενθουσιωδώς* να δημιουργήσουμε ένα.

Το openSUSE Leap 42.1 στο VPS μας είναι πλήρως ενημερωμένο και είμαστε πανέτοιμοι για το άλμα προς το Leap 42.2 (no pun intended). Έχουμε πάρει και το snapshot μας, οπότε ακόμη και στην περίπτωση που επιφέρουμε το Χάος χωρίς καμία ελπίδα για μείωση της Εντροπίας, απλά θα επαναφέρουμε το snapshot και η Τάξη θα επανέλθει στον κόσμο μας.

Το openSUSE Leap 42.1 στο VPS μας είναι πλήρως ενημερωμένο και είμαστε πανέτοιμοι για το άλμα προς το Leap 42.2 (no pun intended). Έχουμε πάρει και το snapshot μας, οπότε ακόμη και στην περίπτωση που επιφέρουμε το Χάος χωρίς καμία ελπίδα για μείωση της Εντροπίας, απλά θα επαναφέρουμε το snapshot και η Τάξη θα επανέλθει στον κόσμο μας.

Σημείωση. Το πόσο εμφατικά προτείνουμε τη λήψη snapshot, δύσκολα μπορούμε να σας το μεταδώσουμε. Θα σας πούμε μόνο ότι στις πρώτες μας δοκιμές, όταν το πρόβλημα με το /etc/default/grub εκδηλώθηκε στο τελευταίο στάδιο της αναβάθμισης του Leap 42.1 στο 42.2 και (φυσικά) αποτύχαμε να το προσέξουμε, το σύστημα δεν μπορούσε καν να ξεκινήσει. Αν δεν είχαμε snapshot θα μας περίμενε ένα όχι και τόσο ευχάριστο απόγευμα, ασφυκτικά γεμάτο με διαδικασίες *εκ νέου* εγκατάστασης :/

Άλμα στο 42.2 από τη γραμμή εντολών
Το σχέδιο δράσης έχει ως ακολούθως:

  • Βήμα 1. Σημειώνουμε από πού έρχονται τα πακέτα για το OSS (Open Source Software) repository καθώς και για το repository με τις αναβαθμίσεις — πάντα του Leap 42.1.
  • Βήμα 2. Αφαιρούμε όλα τα υπάρχοντα repositories ανεξαιρέτως.
  • Βήμα 3. Προσθέτουμε δύο νέα repositories για τα πακέτα OSS του λειτουργικού και τις αντίστοιχες αναβαθμίσεις, τα οποία όμως αφορούν στο Leap 42.2.
  • Βήμα 4. Φρεσκάρουμε τα νέα repositories.
  • Βήμα 5. Αναβαθμίζουμε το λειτουργικό με βάση τα νέα repositories.
  • Βήμα 6. Ελέγχουμε τυχόντα αρχεία ρυθμίσεων που σκοπίμως δεν τροποποιήθηκαν αλλά υπάρχει και νέα έκδοσή τους.

Βήμα 1. Ας δούμε τη λίστα με όλα τα repositories, πληκτρολογώντας zypper lr.

Η λίστα με τα αποθετήρια της εγκατάστασής μας *πριν* από την αναβάθμιση. Μας ενδιαφέρουν μόνο δύο: εκείνο με τα πακέτα OSS για το openSUSE Leap 42.1, καθώς και το άλλο με τις όποιες διαθέσιμες αναβαθμίσεις.

Η λίστα με τα αποθετήρια της εγκατάστασής μας *πριν* από την αναβάθμιση. Μας ενδιαφέρουν μόνο δύο: εκείνο με τα πακέτα OSS για το openSUSE Leap 42.1, καθώς και το άλλο με τις όποιες διαθέσιμες αναβαθμίσεις.

Τα Debug και Source repositories δεν μας ενδιαφέρουν. Από τα υπόλοιπα, εστιάζουμε την προσοχή μας στα repositories με ονόματα openSUSE-Leap-42.1-Oss και openSUSE-Leap-42.1-Update. Για καθένα εξ αυτών μπορούμε να πάρουμε περισσότερες πληροφορίες, ώστε να βρούμε τις online διευθύνσεις των πακέτων που περιλαμβάνουν. Δείτε το screenshot που ακολουθεί.

Από πού προέρχονται τα πακέτα των δύο repositories που μας ενδιαφέρουν; Διαφορετικά: Ποιες είναι οι online διευθύνσεις των αντίστοιχων αποθετηρίων; Μπορούμε να τις μάθουμε πανεύκολα -- και γρήγορα.

Από πού προέρχονται τα πακέτα των δύο repositories που μας ενδιαφέρουν; Διαφορετικά: Ποιες είναι οι online διευθύνσεις των αντίστοιχων αποθετηρίων; Μπορούμε να τις μάθουμε πανεύκολα — και γρήγορα.

Ας σημειώσουμε κάπου τις ακόλουθες δύο αντιστοιχίες:

openSUSE-Leap-42.1-Oss -->
http://mirror.hetzner.de/opensuse/distribution/leap/42.1/repo/oss

openSUSE-Leap-42.1-Update -->
http://mirror.hetzner.de/opensuse/update/leap/42.1/oss

Βήμα 2. Προκειμένου να αφαιρέσουμε όλα τα υπάρχοντα repositories, αρκεί να πληκτρολογήσουμε sudo zypper rr 1 2 3 4 5 6 7 8 9 10.

Αφαίρεση όλων των αποθετηρίων του Leap 42.1 με χρήση του εργαλείου zypper (και φυσικά με δικαιώματα διαχειριστή συστήματος). Το rr αποτελεί συντομογραφία του removerepo και στο παράδειγμα ακολουθείται από τους αύξοντες αριθμούς όλων των υπαρχόντων repositories.

Αφαίρεση όλων των αποθετηρίων του Leap 42.1 με χρήση του εργαλείου zypper (και φυσικά με δικαιώματα διαχειριστή συστήματος). Το rr αποτελεί συντομογραφία του removerepo και στο παράδειγμα ακολουθείται από τους αύξοντες αριθμούς όλων των υπαρχόντων repositories.

Το Leap 42.1 χωρίς *κανένα* αποθετήριο :/ Παράξενο θέαμα, ε; Πράγματι είναι παράξενο -- και την ίδια στιγμή είναι το πρώτο ουσιαστικό βήμα για την αναβάθμιση στο Leap 42.2.

Το Leap 42.1 χωρίς *κανένα* αποθετήριο :/ Παράξενο θέαμα, ε; Πράγματι είναι παράξενο — και την ίδια στιγμή είναι το πρώτο ουσιαστικό βήμα για την αναβάθμιση στο Leap 42.2.

Βήμα 3. Θέλουμε τώρα να προσθέσουμε δύο νέα repositories για πακέτα OSS και τις αναβαθμίσεις τους, αλλά για το openSUSE Leap 42.2. Χρειαζόμαστε τα αντίστοιχα URLs κι αυτά είναι ίδια μ’ εκείνα που πριν λίγο σημειώσαμε, μόνο που στη θέση του 42.1 υπάρχει το 42.2. Οι προσθήκες επιτυγχάνονται πληκτρολογώντας, διαδοχικά:

sub0@vatnajokull:~> sudo zypper ar -n 'openSUSE Leap 42.2 OSS' \
http://mirror.hetzner.de/opensuse/distribution/leap/42.2/repo/oss \
'Leap422 OSS'
sub0@vatnajokull:~> sudo zypper ar -n 'openSUSE Leap 42.2 OSS Updates' \
http://mirror.hetzner.de/opensuse/update/leap/42.2/oss \
'Leap422 OSS Updates'

Προσθήκη δύο νέων repositories για τα πακέτα OSS και τις αναβαθμίσεις τους, για το openSUSE Leap 42.2. Η εντολή ar αποτελεί συντομογραφία του addrepo και με την παράμετρο -n καθορίζουμε το όνομα του νέου repository. Ακολουθεί η online διεύθυνσή του και μετά ένα συνώνυμο (alias). Το συνώνυμο ενδέχεται να είναι μια συντομότερη εκδοχή του ονόματος, αν και όχι απαραίτητα.

Προσθήκη δύο νέων repositories για τα πακέτα OSS και τις αναβαθμίσεις τους, για το openSUSE Leap 42.2. Η εντολή ar αποτελεί συντομογραφία του addrepo και με την παράμετρο -n καθορίζουμε το όνομα του νέου repository. Ακολουθεί η online διεύθυνσή του και μετά ένα συνώνυμο (alias). Το συνώνυμο ενδέχεται να είναι μια συντομότερη εκδοχή του ονόματος, αν και όχι απαραίτητα.

Βήμα 4. Πριν χρησιμοποιήσουμε τα νέα repositories πρέπει να φρεσκάρουμε την τοπική cache με τις πληροφορίες που τα αφορούν. Αυτό γίνεται πολύ πιο εύκολα απ’ όσο ακούγεται, συγκεκριμένα αρκεί να πληκτρολογήσουμε

sub0@vatnajokull:~> sudo zypper ref

Βήμα 5. Έφτασε η ώρα για το πέρασμα στο Leap 42.2, χρησιμοποιώντας τα δύο repositories που μόλις προσθέσαμε. Πρώτα θα κατεβάσουμε *όλα* τα νέα πακέτα RPM και μετά θα τα εγκαταστήσουμε, οπότε ξεκινάμε δίνοντας:

sub0@vatnajokull:~> sudo zypper dup --download-only

Αντί να κατεβαίνουν πακέτα και να εγκαθίστανται όπως φτάνουν, προτιμήσαμε να τα κατεβάσουμε πρώτα *όλα* μαζί. Στο παράδειγμά μας, το συνολικό μέγεθος του download ανέρχεται στα 386 περίπου gigabytes.

Αντί να κατεβαίνουν πακέτα και να εγκαθίστανται όπως φτάνουν, προτιμήσαμε να τα κατεβάσουμε πρώτα *όλα* μαζί. Στο παράδειγμά μας, το συνολικό μέγεθος του download ανέρχεται στα 386 περίπου gigabytes.

Πρακτικά, η προηγούμενη εντολή κατεβάζει όλα τα νέα πακέτα χωρίς να κάνει τίποτε άλλο. Για την αναβάθμιση αυτή καθ’ αυτή γράφουμε:

sub0@vatnajokull:~> sudo zypper --no-refresh dup

Η διαδικασία θα χρειαστεί λίγο χρόνο για να ολοκληρωθεί — στην περίπτωσή μας περισσότερο απ’ όσο χρειάστηκε το download.

Ώρα για αναβάθμιση στο openSUSE Leap 42.2! Όλα τα νέα πακέτα έχουν ήδη κατέβει, οπότε τώρα η διαδικασία θα προχωρήσει ομαλότερα και βεβαίως θα ολοκληρωθεί γρηγορότερα.

Ώρα για αναβάθμιση στο openSUSE Leap 42.2! Όλα τα νέα πακέτα έχουν ήδη κατέβει, οπότε τώρα η διαδικασία θα προχωρήσει ομαλότερα και βεβαίως θα ολοκληρωθεί γρηγορότερα.

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

Η διαδικασία της αναβάθμισης μόλις ολοκληρώθηκε. Όπως βλέπετε και στο screenshot, στο τερματικό μας δεν υπάρχει κάποιο μήνυμα λάθους.

Η διαδικασία της αναβάθμισης μόλις ολοκληρώθηκε. Όπως βλέπετε και στο screenshot, στο τερματικό μας δεν υπάρχει κάποιο μήνυμα λάθους.

Κάντε μια επανεκκίνηση κι ανοίξτε μια κονσόλα VNC, ώστε να δείτε το μήνυμα καλωσορίσματος πάνω από το login prompt. Θα παρατηρήσετε ότι βρισκόσαστε στο openSUSE Leap 42.2.

Μετά την αναβάθμιση στο Leap 42.2 επανεκκινούμε το λειτουργικό και στη web VNC console που μας παρέχεται βλέπουμε τα μηνύματα του boot. Το ξεκίνημα ολοκληρώνεται χωρίς μηνύματα λάθους και, απ' ό,τι υποδηλώνει το μήνυμα πάνω από το login prompt, βρισκόμαστε στο openSUSE Leap 42.2!

Μετά την αναβάθμιση στο Leap 42.2 επανεκκινούμε το λειτουργικό και στη web VNC console που μας παρέχεται βλέπουμε τα μηνύματα του boot. Το ξεκίνημα ολοκληρώνεται χωρίς μηνύματα λάθους και, απ’ ό,τι υποδηλώνει το μήνυμα πάνω από το login prompt, βρισκόμαστε στο openSUSE Leap 42.2!

Αν ο VPS provider δεν προσφέρει κονσόλα VNC, κάντε SSH login στο απομακρυσμένο σύστημα, εγκαταστήστε το εργαλείο lsb-release (αν δεν είναι ήδη εγκατεστημένο) και δώστε lsb_release -a. Καλωσορίσατε στο ολοκαίνουργιο λειτουργικό σας!

Άλλη μια επιβεβαίωση ότι βρισκόμαστε στο ολοκαίνουργιο Leap 42.2, αυτή τη φορά από το εργαλείο lsb_release.

Άλλη μια επιβεβαίωση ότι βρισκόμαστε στο ολοκαίνουργιο Leap 42.2, αυτή τη φορά από το εργαλείο lsb_release.

Βήμα 6. Κατανοούμε ότι βιάζεστε ν’ αρχίσετε τους πανηγυρισμούς και τα πάρτυ, παρακαλούμε όμως, περιμένετε λίγο ακόμα. Έχετε αλήθεια αναρωτηθεί τι ακριβώς συμβαίνει με τα αρχεία ρυθμίσεων εφαρμογών και υπηρεσιών, κάθε φορά που έχουμε αναβάθμιση; Το αρχείο /etc/ssh/sshd_config του OpenSSH, για παράδειγμα, είναι σχεδόν βέβαιο πως το έχουμε τροποποιήσει. Όταν λοιπόν κατά τη μετάβαση από το Leap 42.1 στο Leap 42.2 αναβαθμίζεται κι ο OpenSSH server (από την έκδοση 1.93 στην 1.98), τι γίνεται με το τροποποιημένο από εμάς sshd_config; Μήπως αντικαθίσταται από το αντίστοιχο αρχείο της νέας έκδοσης, οπότε οφείλουμε να επαναφέρουμε ξανά τις ρυθμίσεις μας από το backup που έχουμε; Όχι ακριβώς. Στην πραγματικότητα, η στρατηγική διαχείρισης των αρχείων ρυθμίσεων έχει ως ακολούθως:

  • Αν ένα αρχείο ρυθμίσεων δεν έχει τροποποιηθεί από τον διαχειριστή του συστήματος, τότε απλά αντικαθίσταται από το αντίστοιχο αρχείο της νέας έκδοσης.
  • Αν ένα αρχείο ρυθμίσεων έχει τροποποιηθεί από τον διαχειριστή του συστήματος και η αρχική εκδοχή του αρχείου είναι διαφορετική από το αντίστοιχο αρχείο στη νέα έκδοση, τότε στο τροποποιημένο αρχείο προστίθεται η κατάληξη .rpmorig ή .rpmsave κι εγκαθίσταται και το αρχείο της νέας έκδοσης.
  • Αν στο αρχείο SPEC του νέου πακέτου που εγκαθίσταται υπάρχει η ετικέτα noreplace, το αρχείο ρυθμίσεων της παλιάς έκδοσης παραμένει ως έχει κι εγκαθίσταται και το αντίστοιχο της νέας έκδοσης, αλλά με την κατάληξη .rpmnew.

Μετά από την αναβάθμιση του λειτουργικού συστήματος αξίζει να αναζητήσουμε αρχεία με καταλήξεις .rpmorig, .rpmsave ή .rpmnew. Προς τούτο, βολικό είναι το εργαλείο rcrpmconfigcheck. Αναλόγως των ευρημάτων μας ίσως απλά σβήσουμε απευθείας τα όποια αρχεία .rpmorig, .rpmsave, .rpmnew έχουμε, ίσως συγχωνεύσουμε αλλαγές μας σε νέα αρχεία και μετά διαγράψουμε τα παλιά. Παρεμπιπτόντως, με το εργαλείο diff είναι πολύ εύκολο να συγκρίνουμε τα περιεχόμενα δύο αρχείων και να εντοπίζουμε τις διαφορές τους.

Μετά την αναβάθμιση στο Leap 42.2 βλέπουμε ότι υπάρχουν τρία αρχεία ρυθμίσεων τα οποία αξίζει να προσέξουμε λίγο. Το sshd_config, παρεμπιπτόντως, είναι ένα από τα αρχεία που πάντα τροποποιούμε (απαγόρευση απομακρυσμένου login στο λογαριασμό του root, απαγόρευση authentication με βάση το password, authentication μόνο με βάση τα κλειδιά SSH).

Μετά την αναβάθμιση στο Leap 42.2 βλέπουμε ότι υπάρχουν τρία αρχεία ρυθμίσεων τα οποία αξίζει να προσέξουμε λίγο. Το sshd_config, παρεμπιπτόντως, είναι ένα από τα αρχεία που πάντα τροποποιούμε (απαγόρευση απομακρυσμένου login στο λογαριασμό του root, απαγόρευση authentication με βάση το password, authentication μόνο με βάση τα κλειδιά SSH).

Χρήση του diff για τον εντοπισμό των διαφορών μεταξύ των αρχείων sshd_config και sshd_config.rpmnew.

Χρήση του diff για τον εντοπισμό των διαφορών μεταξύ των αρχείων sshd_config και sshd_config.rpmnew.

Αναβάθμιση συστήματος desktop, από τη γραμμή εντολών
Όπως ήδη αναφέραμε, με εντελώς παρόμοιο τρόπο μπορούμε να εργαστούμε προκειμένου ν’ αναβαθμίσουμε ένα σύστημα desktop με openSUSE Leap 42.1. Σε σχέση με τη διαδικασία αναβάθμισης του VPS, με το desktop υπάρχουν δύο μόνο σημεία που χρειάζονται προσοχή:

  • Πέρα από τα repositories OSS και OSS Updates της έκδοσης 42.2, θα χρειαστεί να προσθέσουμε και τα repositories Non OSS και Non OSS Updates — πάντα της έκδοσης 42.2.
  • Μετά την αναβάθμιση του λειτουργικού κατά πάσα πιθανότητα θα χρειαστεί να προσθέσουμε και τα όποια έξτρα repositories χρησιμοποιούσαμε προηγουμένως (και κατά νου έχουμε κυρίως το Packman repository).

Περισσότερες λεπτομέρειες δεν θα παραθέσουμε, είμαστε βέβαιοι ότι δεν τις χρειαζόσαστε.

Αν η έξοδος του εργαλείου diff σας φαίνεται κάπως δυσνόητη, εντοπίστε τις διαφορές μεταξύ δύο αρχείων καταφεύγοντας στην εφαρμογή ονόματι meld. Αν το meld δεν είναι ήδη παρόν στο σύστημά σας, εγκαταστήστε το με το zypper.

Αν η έξοδος του εργαλείου diff σας φαίνεται κάπως δυσνόητη, εντοπίστε τις διαφορές μεταξύ δύο αρχείων καταφεύγοντας στην εφαρμογή ονόματι meld. Αν το meld δεν είναι ήδη παρόν στο σύστημά σας, εγκαταστήστε το με το zypper.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων