Deep Dive: Junos-Upgrade: Dateisystem ist voll - Teil 2

Liebe Leserinnen und Leser, bitte beachten Sie, dass dieser Blog schon etwas älter ist und sich daher Inhalt, Erkenntnisse und Aussagen geändert haben können, da Produkte, Dienstleistungen und Technologien ständig weiterentwickelt werden.

Bevor Sie mit dem Lesen beginnen, empfehlen wir den Teil 1 von «Deep Dive: Junos Upgrade: Dateisystem ist voll» zu lesen.

Wir haben noch mehr Zeit investiert, um heraus zu finden, wie diese Probleme am besten gelöst werden können. Wir möchten betonen, dass die meisten der hier beschriebenen Methoden Teil der Best Practices von Juniper für die Durchführung eines Junos-Upgrades sind, zu denen es (noch?) keine KB-Einträge gibt. Sie zielen hauptsächlich darauf ab, die Arbeit zu erledigen und das Upgrade abzuschliessen und sollten nur als letztes Mittel eingesetzt werden, wenn der offizielle Ansatz nicht genutzt werden kann. Es ist möglich, dass die aktuelle Junos-Installation während des Prozesses beschädigt wird. Ihr Gerät wird dadurch nicht beschädigt, aber falls das Verfahren fehlschlägt, müssen Sie wahrscheinlich beim Geräts sein, um es wiederherstellen zu können. In der Folge kann ein Reboot des Geräts oder eine USB-Neuinstallation notwendig werden.

Corner Case Virtuelles Chassis

Es gibt ein interessantes Corner-Case-Szenario bei der Durchführung eines Upgrades von virtuellen Chassis auf EX2300 und EX3400. Wenn das Upgrade auf dem Master-RE durchgeführt wird, werden die Junos-Packages als mchassis-install.tgz dupliziert und sollten auf die anderen Komponenten übertragen werden, damit sie zur Installation des entsprechenden Junos-Images darauf verwendet werden können. Diese Datei wird immer im Ordner /var/tmp abgelegt (und vom Installationsskript gesucht). Wenn wir also nicht auf allen Komponenten zusätzlichen Speicherplatz zur Verfügung haben, wird das Upgrade fehlschlagen. Der benötigte Speicherplatz ist ungefähr doppelt so gross wie das Ziel-Image (mchassis-install.tgz-Datei plus Platz zum Extrahieren des Inhalts).

Error: not enough space to unpack /var/tmp/mchassis-install.tgz

Da die Datei bereits nach /var/tmp/ verschoben wurde, bedeutet dies, dass wir zusätzlichen Speicherplatz haben, um das Upgrade durchzuführen - allerdings nicht doppelt so viel. Um diesen kleinen Rückschlag zu überwinden, können wir die in Teil 1 beschriebene Methode verwenden und modifizieren, um tmpfs zum Speichern des Images zu nutzen. Der einzige Unterschied besteht darin, dass wir jetzt mit einem VC arbeiten, was auf den Ansatz hinausläuft, ein Upgrade jeder Komponente unabhängig von ihrem lokalen tmpfs durchzuführen, aber die Option des Neustarts während des Installationsprozesses nicht zu berücksichtigen! Weshalb das? Weil wir den VC mikrosegmentieren, wenn wir auf die Junos-Versionsinkongruenz stossen und die fehlerhaften Komponenten in einen inaktiven Zustand versetzt werden. Mit anderen Worten, wir werden jede Komponente einzeln aktualisieren, überprüfen, ob alle die gewünschte ausstehende Version haben (show version | match "fpc|pending") und dann alle Komponenten gleichzeitig neu laden. Das klingt doch nicht zu gefährlich, oder? Aber warum wird empfohlen, diese Methode nur als letzten Ausweg zu verwenden? Es ist möglich, dass Ihr VC dabei beschädigt wird, und in einem solchen Fall müssen Sie einige Zeit investieren, um ihn wiederherzustellen, wenn aus irgendeinem Grund eine Komponente (oder der Master) nicht mit der neuen Version bootet. Es kann aber auch noch einiges mehr schief gehen, zum Beispiel wenn eine Komponente das Upgrade nicht durchführt oder wenn während des Upgrades der Strom plötzlich ausfallen sollte etc.

Manchmal ist nicht der Speicherplatz das Problem, sondern die Tatsache, dass die Datei mchassis-install.tgz nicht ordnungsgemäss an alle Komponenten verteilt wurde. Das ist der Fall, wenn der folgende Fehler angezeigt wird:

/usr/libexec/ui/package: /var/tmp/mchassis-install.tgz: no such file

In diesem Fall können wir versuchen, die Datei manuell vom Master zur betroffenen Komponente zu kopieren, natürlich in das Verzeichnis /var/tmp.

Abgelaufene Packages

Wenn alles, was Sie versucht haben, fehlgeschlagen ist und Sie wirklich kein USB-Stick-Upgrade durchführen wollen, gibt es noch eine letzte Möglichkeit, die Sie anwenden können. Sie befinden sich dann in der Situation, dass das Bereinigen von /var/tmp, das Entfernen aller /var/logs und die Systembereinigung nicht genug Speicherplatz für ein System-Upgrade ergeben haben. Wo ist also der letzte Ort, an dem Sie nachsehen und versuchen können, Speicherplatz freizugeben? Sie können versuchen, alle veralteten Packages in /package/db zu entfernen. Zunächst einmal sollten Sie nach allen Packages suchen, die von einer früheren Installation stammen. Wie bei allem, was mit "Junosy" zu tun hat, gibt es eine einfache und eine harte Methode, dies zu tun.

Einfache Methode

Es gibt einige Befehle, um dies von der freeBSD-Shell aus zu tun (natürlich eingeloggt in der Shell als root).

root@sw1:RE:0% pkg setop rm previous
root@sw1:RE:0% pkg delete old

Natürlich wird dies nicht von allen Plattformen unterstützt, sollte aber auf der EX2300/EX3400 verfügbar sein.

Komplizierte Methode

Wenn wir uns vormachen wollen, dass wir mehr Kontrolle darüber haben sollten, was wir entfernen, können wir dies manuell tun. Zunächst können wir alle Packages entfernen, die mit nicht verwendeten Junos-Versionen in Verbindung stehen. Dies ist jedoch gefährlich und sollte daher auf eigenes Risiko erfolgen. Wie bereits erwähnt, kann es vorkommen, dass sich im Ordner /package/db/ einige veraltete Packages befinden. Dies lässt sich schnell feststellen, wenn man sich die Junos-Version der gespeicherten Packages ansieht. Aus der folgenden Ausgabe geht hervor, dass sich hier Packages für die beiden Junos-Versionen befinden: 17.4R2-S9 und 17.4R2-S8.

nootnoot@mx1> file list /packages/db/
 
/packages/db/:
jail-runtime-x86-32-20190825.5ca39af_builder_stable_11/
jail-runtime-x86-32-20191203.fa5e90e_builder_stable_11/
jdocs-x86-32-20191004.131922_builder_junos_174_r2_s8/
jdocs-x86-32-20200130.100427_builder_junos_174_r2_s9/
jfirmware-x86-32-17.4R2-S8/
jfirmware-x86-32-17.4R2-S9.1/
jpfe-X-x86-32-20191004.131922_builder_junos_174_r2_s8/
jpfe-X-x86-32-20200130.100427_builder_junos_174_r2_s9/
jpfe-X960-x86-32-20191004.131922_builder_junos_174_r2_s8/
jpfe-X960-x86-32-20200130.100427_builder_junos_174_r2_s9/
jpfe-common-x86-32-20191004.131922_builder_junos_174_r2_s8/
jpfe-common-x86-32-20200130.100427_builder_junos_174_r2_s9/
jpfe-wrlinux-x86-32-20191004.131922_builder_junos_174_r2_s8/
jpfe-wrlinux-x86-32-20200130.100427_builder_junos_174_r2_s9/
jsd-x86-32-17.4R2-S8-jet-1/
jsd-x86-32-17.4R2-S9.1-jet-1/
jsdn-x86-32-17.4R2-S8/
jsdn-x86-32-17.4R2-S9.1/
<-- output truncated -->

Natürlich wäre es zu einfach, wenn die Junos-Versionen in den Packages einheitlich geschrieben wären, also müssen wir nach zwei Formaten suchen:

• 174_r2_s8
• 17.4R2-S8

Als erstes können wir also alle Packages entfernen, die den obigen Formaten entsprechen:

find /packages/db -type d -name "*174_r2_s8*" -exec rm -rf {} \;
find /packages/db -type d -name "*17.4R2-S8*" -exec rm -rf {} \;

Dies betrifft nicht alle Packages, da Betriebssystem-Packages keine Junos-Version in ihrem Namen haben und wir andererseits das Problem haben, dass es mehrere Kopien der gleichen Packages für dieselbe Junos-Version gibt. Um herauszufinden, welche Packages bleiben können und welche entfernt werden sollten, können wir den Befehl "show version" verwenden.

nootnoot@sw1> show version
fpc0:
--------------------------------------------------------------------------
<...>
JUNOS OS Kernel 32-bit  [20191022.14c2ad5_builder_stable_11]
JUNOS OS libs [20191022.14c2ad5_builder_stable_11]
JUNOS OS runtime [20191022.14c2ad5_builder_stable_11]
JUNOS OS time zone information [20191022.14c2ad5_builder_stable_11]
JUNOS py extensions [20191115.190104_builder_junos_182_r3_s2]
JUNOS py base [20191115.190104_builder_junos_182_r3_s2]
JUNOS OS crypto [20191022.14c2ad5_builder_stable_11]
JUNOS network stack and utilities [20191115.190104_builder_junos_182_r3_s2]
<...>
 
{master:0}
nootnoot@sw1> show version | match 20191022.14c2ad5_builder_stable_11 | count
Count: 6 lines
 
{master:0}
nootnoot@sw1> file list /packages/db/ | match 20191022.14c2ad5_builder_stable_11 | count
Count: 6 lines

Auf dieser Grundlage können wir auf eine sichere Art und Weise alle Packages entfernen, die derzeit nicht verwendet werden. In manchen Fällen kann dies etwa 300 MB Platz pro Paketbündel bringen.

Unlink-Option

Einige Leute sind besorgt über die Option "unlink" des Upgrade-Verfahrens, da dieser Befehl in der Vergangenheit hauptsächlich auf den MX-Routern oder SRX-Firewalls verwendet wurde und nicht Teil eines Upgrade-Zyklus auf den EX-Switches war. Dieser Befehl wurde in der Version 18.1 eingeführt und wir vermuten, dass er seit Version 18.2 als Standardoption auf den EX2300/EX3400-Switches verwendet wird.  Wir interpretieren dies folgendermassen:

nootnoot@sw1> request system software add /tmp/my-perfect-image.tgz unlink no-copy  
setting unlink by default.

Dies ist der einzige ungefährliche Teil dieses Beitrags, aber ich möchte trotzdem sagen: Die Verwendung der obigen Anleitung erfolgt auf eigenes Risiko.