Aktualisieren des Air-Gap-Modus der Appliance für sichere Malwareanalysen

Einleitung

Dieser Leitfaden beschreibt die Vorgehensweise zur Aktualisierung einer Secure Malware Analytics Appliance im Air-Gap-Modus.

Hinweis: Die Wartung von Geräten im Luftspaltmodus kann deren Effektivität beeinträchtigen. Berücksichtigen Sie vor dem Fortfahren den Kompromiss zwischen Sicherheit und Funktionalität.

Voraussetzungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse von Eingaben über die Befehlszeile in Windows- und Unix/Linux-Umgebungen
• Kenntnisse der Malware-Analyse-Appliance
• Kenntnisse des Cisco Integrated Management Controller (IMC)

Verwendete Komponenten

Cisco empfiehlt, sich mit den folgenden Themen vertraut zu machen:

• Windows 10- und Linux-basiertes Betriebssystem (Beispiel: CentOS, RedHat)
• RUFUS 2,17
• C220 M4, M510 und M520 M5, M610 und M620 M6 (Appliance-Modelle)

Die Informationen in diesem Dokument basieren auf Geräten in einer kontrollierten Laborumgebung mit Standardkonfigurationen. Wenn Ihr Netzwerk in Betrieb ist, gehen Sie vorsichtig vor, und verstehen Sie die möglichen Auswirkungen aller Befehle genau, bevor Sie fortfahren.

Hintergrundinformationen

Die meisten Appliances für sichere Malware-Analyse stellen eine Verbindung mit dem Internet her und verwenden den Online-Aktualisierungsprozess. Einige Appliances werden jedoch streng innerhalb interner Netzwerke gewartet (Air-Gap). Cisco empfiehlt diesen Ansatz nicht, da er die Effektivität verringert. Dieses Handbuch enthält den Offline-Aktualisierungsprozess für Benutzer, die Appliances mit Air-Gap-Funktion verwalten müssen.

Für Offline-Updates von Secure Malware Analytics stellt Cisco auf Anfrage Update-Medien zur Verfügung. Folgen Sie den in diesem Dokument beschriebenen Offline-Aktualisierungsschritten.

Medien: Aktualisierungsmedien für Airgap (offline) werden auf Anfrage vom Secure Malware Analytics Support bereitgestellt. Es handelt sich um eine ISO-Datei, die auf ein USB-Laufwerk oder eine HDD (mit ausreichender Größe) kopiert werden kann.

Größe:Die Größe der Update-Medien variiert je nach unterstützter Version und kann mit der Einführung neuer virtueller Systeme erheblich zunehmen. Aktuelle Versionen: die Größe beträgt ca. 30 GB einschließlich des Desync-Tools, die inkrementelle Updates für VM-bezogene Änderungen ermöglicht.

Upgrade-Bootzyklus: Jedes Mal, wenn das airgap-Aktualisierungsmedium gebootet wird, bestimmt es die nächste Version, auf die aktualisiert werden soll, und kopiert den mit dieser nächsten Version verknüpften Inhalt auf die Appliance. Eine bestimmte Version kann auch eine Paketinstallation initiieren, wenn für diese Version keine erforderlichen Prüfungen vorhanden sind, die ausgeführt werden müssen, während die Appliance ausgeführt wird. Wenn die Version solche Prüfungen enthält oder Teile des Aktualisierungsprozesses überschreiben, die solche Prüfungen hinzufügen könnten, gilt das Update erst, wenn sich der Benutzer bei OpAdmin anmeldet und das Update mit OpAdmin > Operations > Update Appliance aufruft.

 Vorinstallierungshaken: Je nachdem, ob bei diesem Upgrade bereits ein Hook vor der Installation vorhanden ist, führt es das Upgrade entweder sofort aus oder startet die Appliance erneut in den regulären Betriebsmodus, damit der Benutzer die übliche Verwaltungsoberfläche aufrufen und das Upgrade von Hand starten kann.

 Bei Bedarf wiederholen: Jeder dieser Medien-Bootzyklen führt somit nur einen Schritt hin zur endgültigen Zielversion ein Upgrade durch (oder bereitet sich auf ein Upgrade vor). Der Benutzer muss so oft booten wie nötig, um ein Upgrade auf die gewünschte Zielversion durchzuführen.

Einschränkungen

CIMC-Medien werden für Air-Gap-Updates nicht unterstützt.

Aufgrund von Lizenzbeschränkungen bei verwendeten Drittanbieterkomponenten sind Upgrade-Medien für 1.x-Versionen nach dem Ende der Lebensdauer der UCS M3-Hardware nicht mehr verfügbar. Daher ist es wichtig, dass die UCS M3-Appliances vor dem EOL ausgetauscht oder aktualisiert werden. 

Anforderungen

Migrationen: Wenn die Versionshinweise für die abgedeckten Versionen Szenarien umfassen, in denen eine Migration vor der Installation der nächsten Version zwingend erforderlich ist, muss der Benutzer diese Schritte befolgen, bevor er einen Neustart durchführt, um zu vermeiden, dass die Appliance in einen unbrauchbaren Zustand versetzt wird.

Hinweis: Insbesondere die erste Version 2.1.x, die neuer als 2.1.4 ist, führt mehrere Datenbankmigrationen aus. Es ist gefährlich, fortzufahren, bis diese Migrationen abgeschlossen sind. Weitere Informationen finden Sie im Migrationshinweis zur Threat Grid Appliance 2.1.5.

 Wenn die airgap-Upgrade-Medien ab einer Version vor 2.1.3 einen von der individuellen Lizenz abgeleiteten Verschlüsselungsschlüssel verwenden und daher für jede Appliance angepasst werden müssen. (Der einzige sichtbare Effekt für Benutzer besteht darin, dass Secure Malware Analytics für die Unterstützung von Originalversionen vor 2.1.3 die Lizenzen benötigt, die zuvor auf diesen Appliances installiert wurden, und die Medien auf den Appliances funktionieren, die nicht in der Liste aufgeführt sind, für die sie erstellt wurden.)

Ab Version 2.1.3 oder später sind die AirGap-Medien allgemein gehalten, und Kundeninformationen sind nicht erforderlich. 

Vorbereitungen

• Sicherung. Sie müssen eine Sicherung Ihrer Appliance in Betracht ziehen, bevor Sie mit der Aktualisierung fortfahren.
• Überprüfen Sie in den Versionshinweisen für die zu aktualisierende Version, ob Hintergrundmigrationen erforderlich sind, bevor Sie eine Aktualisierung auf die neuere Version planen.
• Überprüfen Sie die aktuelle Version Ihrer Appliance: OpAdmin > Betrieb > Einheit aktualisieren
• Lesen Sie den Versionsverlauf der Secure Malware Analytics-Appliance in der Suchtabelle Build Number/Version (Build-Nummer/Version), die in allen Threat Grid-Appliance-Dokumenten verfügbar ist: Versionshinweise, Migrationshinweise, Setup- und Konfigurationsleitfaden und Administratorhandbuch.

Aktualisieren einer Anwendung für sichere Offline-Malwareanalysen (Airgapped)

Erster Blick auf die verfügbare Air Gap Version auf dieser Seite: Suchtabelle für Appliance-Versionen

1. Erstellen Sie eine TAC-Support-Anfrage, um die Offline-Update-Medien zu erhalten. Diese Anforderung muss die Seriennummer der Einheit sowie die Build-Nummer der Einheit enthalten.

2. TAC Support liefert ein aktualisiertes ISO basierend auf Ihrer Installation.

3. Brennen Sie das ISO-Image auf einen bootfähigen USB-Anschluss. Beachten Sie, dass USB das einzige unterstützte Gerät/die einzige unterstützte Methode für Offline-Updates ist.

Namenskonventionen

Dies ist der aktualisierte Dateiname ex: TGA Airgap-Update 2.16.2-2.17.2

Dies würde bedeuten, dass dieses Medium für eine Appliance verwendet werden kann, auf der eine Mindestversion ausgeführt wird: 2.16.2 und aktualisieren Sie die Appliance auf Version: 2.17.2.

Einschränkungen

• CIMC-Medien werden für Air-Gap-Updates nicht unterstützt.
• Aufgrund von Lizenzbeschränkungen bei verwendeten Drittanbieterkomponenten sind Upgrade-Medien für 1.x-Versionen nach dem Ende der Lebensdauer der UCS M3-Hardware nicht mehr verfügbar. Daher ist es wichtig, dass die UCS M3-Appliances vor dem EOL ausgetauscht oder aktualisiert werden.

Linux/MAC - ISO-Download

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Ein Linux-Rechner mit Internetzugang, um die ISO-Datei herunterzuladen und das bootfähige USB-Installationslaufwerk zu erstellen.
• Die Anweisungen zum Herunterladen von Airgap werden vom Secure Malware Analytics Support bereitgestellt.
• GO-Programmiersprache. Herunterladen
• Die .caibx Indexdatei (enthalten in der vom TAC Support bereitgestellten ZIP-Datei).
• Desync Tool (in der vom Secure Malware Analytics Support bereitgestellten ZIP-Datei enthalten).

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf einem Linux-basierten Betriebssystem (Beispiel: CentOS, RedHat). 

Die Informationen in diesem Dokument basieren auf Geräten in einer kontrollierten Laborumgebung mit Standardkonfigurationen. Wenn Ihr Netzwerk in Betrieb ist, gehen Sie vorsichtig vor, und verstehen Sie die möglichen Auswirkungen aller Befehle genau, bevor Sie fortfahren.

Konfigurieren

Installieren der GO-Programmiersprache

# wget https://go.dev/dl/go1.23.1.linux-amd64.tar.gz
# tar -xzf go1.23.1.linux-amd64.tar.gz
# mv go /usr/local

Führen Sie diese drei Befehle nach der Installation aus, falls der Befehl desync nicht fehlschlägt.

# export GOROOT=/usr/local/go
# export GOPATH=$HOME/Projects/Proj1
# export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

Sie können die GO-Version wie folgt überprüfen:

# go version

ISO mit dem Desync-Befehl herunterladen

Schritt 1. Kopieren Sie den Inhalt der Zip-Datei von Secure Malware Analytics Support einschließlich der desync.linux und .caibx Datei in das gleiche Verzeichnis lokal auf dem Computer.

Schritt 2. Wechseln Sie in das Verzeichnis, in dem Sie die Dateien gespeichert haben:

Beispiel:

# cd MyDirectory/TG

Schritt 3: Führen Sie den Befehl pwd aus, um sicherzustellen, dass Sie sich im Verzeichnis befinden.

# pwd

Schritt 4. Sobald Sie sich im Verzeichnis befinden, das den Befehl desync.linux und die Datei .caibx enthält, führen Sie den Befehl Ihrer Wahl aus, um den Download-Prozess zu starten.

Anmerkung: Dies sind die Beispiele für verschiedene ISO-Versionen. Bitte lesen Sie die Datei .caibx aus der Anleitung von Secure Malware Analytics Support.

Für Version 2.16.2 bis 2.17.2 ISO:

# desync extract -k -s s3+https://s3.amazonaws.com/sma-appliance-airgap-update airgap-update-2.16.2ag-2.17.2.caibx airgap-update-2.16.2ag-2.17.2.iso

Für Version 2.4.3.2 bis 2.5 ISO:

# desync extract -k -s s3+https://s3.amazonaws.com/threatgrid-appliance-airgap-update airgap-update-2.4.3.2-2.5.caibx airgap-update-2.4.3.2-2.5.iso

Für Version 2.5 bis 2.7.2ag ISO:

# desync extract -k -s s3+https://s3.amazonaws.com/threatgrid-appliance-airgap-update airgap-update-2.5-2.7.2ag.caibx airgap-update-2.5-2.7.2ag.iso

Sobald der Download beginnt, wird eine Statusleiste angezeigt.

Anmerkung: Die Download-Geschwindigkeit und die Größe der Upgrade-Medien in Ihrer Umgebung können sich auf die Zeit für die ISO-Erstellung auswirken.
Bitte vergleichen Sie das MD5 der heruntergeladenen Datei mit dem verfügbaren Paket, das vom Support zur Verfügung gestellt wird, um die Integrität des heruntergeladenen ISO zu überprüfen.

Nach Abschluss des Downloads werden die ISOs im gleichen Verzeichnis erstellt.

Schließen Sie den USB-Stick an den Computer an, und führen Sie den Befehl dd aus, um das bootfähige USB-Laufwerk zu erstellen.

# dd if=airgap-update.iso of=/dev/<MY_USB> bs=64M

<MY_USB> ist der Name Ihres USB-Sticks (lassen Sie die spitzen Klammern weg).

Legen Sie das USB-Laufwerk ein, und schalten Sie die Einheit ein, oder starten Sie sie neu. Drücken Sie auf dem Cisco Bootbildschirm die F6-Taste, um das Startmenü aufzurufen.

Tipp:
Führen Sie den Download außerhalb der Geschäftszeiten oder außerhalb der Geschäftszeiten aus, da dies die Bandbreite beeinträchtigen kann.
Um das Werkzeug zu stoppen, schließen Sie entweder das Terminal oder drücken Sie Strg+c/Strg+z.
Um fortzufahren, führen Sie den gleichen Befehl aus, um den Download fortzusetzen.

Windows - ISO-Download

Installieren der GO-Programmiersprache

1. Die erforderliche GO-Programmiersprache herunterladen. Installieren von https://golang.org/dl/ In meinem Fall wähle ich die empfohlene Version aus. Starten Sie den CMD neu und testen Sie mit
   
   

   Schließen Sie den CMD-Befehl run, und öffnen Sie ihn erneut, um Folgendes zu überprüfen:

   go version

   

   ISO mit dem Desync-Befehl herunterladen

2. Installieren Sie DESYNC Tool. Nach der Ausführung des Befehls werden Sie eine Reihe von Download-Aufforderungen bemerken. Etwa nach 2-3 Minuten sollte der Download erfolgen.
   

   go install github.com/folbricht/desync/cmd/desync@latest

   In case desync is not working using above command then change directory to C drive and run this command: 
   
   git clone https://github.com/folbricht/desync.git
   
   

   

   Anmerkung: Wenn der Befehl git nicht funktioniert, können Sie Git hier herunterladen und installieren: https://git-scm.com/download/win

   Führen Sie dann die folgenden beiden Befehle nacheinander aus:
   
   

   cd desync/cmd/desync
   
   go install

   

    

3. Navigieren Sie zu   go — > bin Standort. Zum Beispiel C:\Users\<Benutzername>\go\bin und dort bereitgestelltes TAC kopieren/einfügen .caibx Indexdatei.
   
4. (Verifizieren) Wechseln Sie zurück zur CMD-Eingabeaufforderung, navigieren Sie zum Ordner go\bin, und führen Sie die Download-Befehle aus. Sie sollten sofort sehen, dass der Download fortgesetzt wird. Warten Sie, bis der Download abgeschlossen ist. Sie sollten jetzt die gesamte ISO Datei am gleichen Speicherort wie die zuvor kopierte .caibx Indexdatei
   

   \$HOME/go/bin/desync extract -k -s s3+https://s3.amazonaws.com/sma-appliance-airgap-update airgap-update-2.16.2ag-2.17.2.caibx airgap-update-2.16.2ag-2.17.2.iso
   

   

   Für die Erstellung dieser spezifischen Wiederherstellung USB ist es wichtig, Rufus Version 2.17 zu verwenden, da es Ihnen ermöglicht, wesentliche dd-Optionen zu verwenden. In diesem Repository finden Sie alle RUFUS-Versionen.

   

    

Einheit über USB booten

1. USB einstecken, die Appliance neu zu starten, und drücken Sie schnell F6 auf dem Cisco Startbildschirm, um das Startmenü aufzurufen.
   
2. Navigieren Sie zu dem USB-Laufwerk, das die Aktualisierung enthält, und drücken Sie die Eingabetaste, um eine Option auszuwählen.
   
   

   Das Aktualisierungsmedium bestimmt die nächste Version im Aktualisierungspfad und kopiert den Inhalt für diese Version auf die Appliance. Die Appliance führt das Upgrade entweder sofort aus oder führt einen Neustart in den regulären Betriebsmodus durch, sodass Sie OpAdmin aufrufen und das Upgrade manuell starten können.

   Sobald der ISO-Bootvorgang abgeschlossen ist, starten Sie die Secure Malware Analytics-Appliance wieder in den Betriebsmodus.

   Melden Sie sich bei der Benutzeroberfläche des Portals an, und prüfen Sie, ob Warnungen bezüglich eines sicheren Upgrades usw. vorliegen, bevor Sie fortfahren.

3. Navigieren Sie zur OpAdmin-Schnittstelle, und wenden Sie die Updates an, wenn sie nicht während des Neustarts automatisch angewendet wurden: OpAdmin > Betrieb > Einheit aktualisieren HINWEIS: Der Aktualisierungsvorgang umfasst zusätzliche Neustarts als Teil des Updates, das von den USB-Medien erstellt wird. Sie müssen z. B. die Schaltfläche Reboot (Neustart) auf der Installationsseite verwenden, nachdem Updates installiert wurden.
   Wiederholen Sie den Vorgang bei Bedarf für jede USB-Version.

So finden Sie das richtige /dev-Gerät

Mit dem USB immer noch nicht an den Endpunkt angeschlossen führen Sie den Befehl "lsblk | grep -iE 'disk|part'.

xsilenc3x@Alien15:~/testarea/usb$ lsblk | grep -iE 'disk|part'
sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   128M  0 part
└─sda2        8:2    0 931.4G  0 part /media/DATA
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   650M  0 part
├─nvme0n1p2 259:2    0   128M  0 part
├─nvme0n1p3 259:3    0 114.1G  0 part
├─nvme0n1p4 259:4    0   525M  0 part /boot
├─nvme0n1p5 259:5    0   7.6G  0 part [SWAP]
├─nvme0n1p6 259:6    0  38.2G  0 part /
├─nvme0n1p7 259:7    0  62.7G  0 part /home
├─nvme0n1p8 259:8    0  13.1G  0 part
└─nvme0n1p9 259:9    0   1.1G  0 part
xsilenc3x@Alien15:~/testarea/usb$

 Nachdem der USB-Stick angeschlossen wurde.

xsilenc3x@Alien15:~/testarea/usb$ lsblk | grep -iE 'disk|part'
.sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   128M  0 part
└─sda2        8:2    0 931.4G  0 part /media/DATA
sdb           8:16   1   3.7G  0 disk
└─sdb1        8:17   1   3.7G  0 part /media/xsilenc3x/ARCH_201902  <--------- not observed when the USB was not connected
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   650M  0 part
├─nvme0n1p2 259:2    0   128M  0 part
├─nvme0n1p3 259:3    0 114.1G  0 part
├─nvme0n1p4 259:4    0   525M  0 part /boot
├─nvme0n1p5 259:5    0   7.6G  0 part [SWAP]
├─nvme0n1p6 259:6    0  38.2G  0 part /
├─nvme0n1p7 259:7    0  62.7G  0 part /home
├─nvme0n1p8 259:8    0  13.1G  0 part
└─nvme0n1p9 259:9    0   1.1G  0 part
xsilenc3x@Alien15:~/testarea/usb$

Dies bestätigt, dass das USB-Gerät in /dev "/dev/sdb" ist.

Weitere Möglichkeiten zur Bestätigung, nachdem der USB-Stick angeschlossen wurde:

Der Befehl dmesg liefert einige Informationen. Nachdem der USB angeschlossen wurde, führen Sie den Befehl dmesg aus. | grep -iE 'usb|attached'.

xsilenc3x@Alien15:~/testarea/usb$ dmesg | grep -iE 'usb|attached'
[842717.663757] usb 1-1.1: new high-speed USB device number 13 using xhci_hcd
[842717.864505] usb 1-1.1: New USB device found, idVendor=0781, idProduct=5567
[842717.864510] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[842717.864514] usb 1-1.1: Product: Cruzer Blade
[842717.864517] usb 1-1.1: Manufacturer: SanDisk
[842717.864519] usb 1-1.1: SerialNumber: 4C530202420924105393
[842717.865608] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[842717.866074] scsi host1: usb-storage 1-1.1:1.0
[842718.898700] sd 1:0:0:0: Attached scsi generic sg1 type 0
[842718.922265] sd 1:0:0:0: [sdb] Attached SCSI removable disk  <-------
xsilenc3x@Alien15:~/testarea/usb$

Der Befehl fidsk liefert Informationen über die Größe, die verwendet werden können, um zu bestätigen: sudo fdisk -l /dev/sdb.

xsilenc3x@Alien15:~/testarea/usb$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 3.7 GiB, 4004511744 bytes, 7821312 sectors  <-------
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x63374e06

Device     Boot Start    End Sectors  Size Id Type
/dev/sdb1  *        0 675839  675840  330M  0 Empty
/dev/sdb2         116   8307    8192    4M ef EFI (FAT-12/16/32)
xsilenc3x@Alien15:~/testarea/usb$

Anmerkung: Denken Sie daran, die USB-Einbindung aufzuheben, bevor Sie den Befehl "dd" ausführen.

Bestätigen Sie, dass das USB-Gerät aus dem Beispiel eingebunden ist.

xsilenc3x@Alien15:~/testarea/usb$ sudo mount -l | grep -i sdb
/dev/sdb1 on /media/xsilenc3x/ARCH_201902 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) [ARCH_201902]

Um die Bereitstellung des USB-Geräts aufzuheben, verwenden Sie sudo umount /dev/sdb1.

xsilenc3x@Alien15:~/testarea/usb$ sudo umount /dev/sdb1

Überprüfen Sie erneut, ob das Gerät nicht als "montiert" wahrgenommen wird.

xsilenc3x@Alien15:~/testarea/usb$ sudo mount -l | grep -i sdb

status=progress-Option

oflag=sync- und status=progress-Optionen im Befehl dd.

Beim Schreiben mehrerer Datenblöcke liefert die Option "status=progress" Informationen über die aktuellen Schreibvorgänge. Dies ist nützlich, um zu bestätigen, ob der Befehl "dd" derzeit in den Seitencache schreibt. Sie kann verwendet werden, um den Fortschritt und die gesamte Zeit in Sekunden aller Schreibvorgänge anzuzeigen.

Wenn "dd" nicht verwendet wird, liefert es keine Informationen über den Fortschritt, sondern nur die Ergebnisse der Schreibvorgänge, bevor "dd" zurückgegeben wird:

[rootuser@centos8-01 tga-airgap]$ dd if=/dev/zero of=testfile.txt bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 5.03493 s, 1.7 GB/s
[rootuser@centos8-01 tga-airgap]$ 

Bei Verwendung werden die Echtzeitinformationen zu den Schreibvorgängen jede Sekunde aktualisiert.

[rootuser@centos8-01 tga-airgap]$ dd if=/dev/zero of=testfile.txt bs=1M count=8192 status=progress
8575254528 bytes (8.6 GB, 8.0 GiB) copied, 8 s, 1.1 GB/s <----------------
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 8.03387 s, 1.1 GB/s
[rootuser@centos8-01 tga-airgap]

Anmerkung: In der offiziellen Dokumentation für den TGA Offline Upgrade Prozess lautet der Befehl, der informiert wird: dd if=airgap-update.iso of=/dev/<MY_USB> bs=64M

Nach einigen Tests wird das folgende Beispiel beobachtet.

Sobald eine Datei von 10MB mit "dd" mit dem Gerät /dev/zero erstellt wurde.

1M x 10 = 10M (10240 kB + vorherige Systemdaten in Dirty File Page Caches = 10304 kB —> dies wird im Dirty Page Cache am Ende von "dd" wahrgenommen).

[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && dd if=/dev/zero of=testfile.txt bs=1M \
count=10 status=progress && cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                92 kB
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0138655 s, 756 MB/s
Dirty:             10304 kB <----- dirty page cache after "dd" returned | data still to be written to the block device
1633260775 <---- epoch time
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10372 kB
1633260778
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10380 kB
1633260779
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10404 kB
1633260781
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10412 kB
1633260782
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10424 kB
1633260783
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10436 kB
1633260785
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                 0 kB  <--- data in the dirty page cache flushed = written to the block device
1633260786 <---- epoch time
[rootuser@centos8-2 testarea]$
```

1633260786 - 1633260775 = 11 seconds

Anmerkung: Nachdem der Befehl "dd" zurückgegeben wurde, war der Schreibvorgang auf das Blockgerät nicht abgeschlossen, sondern 11 Sekunden nach der Rückgabe.
Wenn dies der "dd"-Befehl bei der Erstellung des bootfähigen USB mit dem TGA ISO, UND ich hatte den USB vom Endpunkt entfernt, bevor diese 11 Sekunden = ich hätte eine beschädigte ISO in der bootfähigen USB.

Erläuterung:

Blockierungsgeräte ermöglichen einen gepufferten Zugriff auf Hardwaregeräte. Dies bietet eine Abstraktionsebene für Anwendungen, wenn mit Hardwaregeräten gearbeitet wird.

Blockierungsgeräte ermöglichen einer Anwendung das Lesen/Schreiben von Datenblöcken unterschiedlicher Größe. Diese Read()/Writes() wird auf die Seitencaches (Puffer) und nicht direkt auf das Blockgerät angewendet.
Der Kernel (und nicht die Anwendung, die den Lese-/Schreibvorgang ausführt) verwaltet die Verschiebung der Daten von den Puffern (Seiten-Caches) zu den Blockgeräten.

Daher:

Die Anwendung (in diesem Fall "dd") hat keine Kontrolle über die Leerung der Puffer, wenn sie nicht angewiesen wird.

Die Option "oflag=sync" erzwingt synchrones physikalisches Schreiben (durch den Kernel), nachdem jeder Ausgabeblock (durch "dd" bereitgestellt) im Seiten-Cache platziert wurde.
oflag=sync beeinträchtigt die "dd"-Leistung im Vergleich zur Nichtverwendung der Option; aber wenn sie aktiviert ist, stellt sie sicher, dass nach jedem write()-Aufruf von "dd" ein physisches Schreiben auf das Blockgerät erfolgt.

Test: Mit der Option "oflag=sync" des Befehls "dd" zur Bestätigung aller Schreibvorgänge mit den schmutzigen Seitencachedaten wurde bei der Rückgabe des Befehls "dd" Folgendes durchgeführt:

[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && dd if=/dev/zero of=testfile.txt bs=1M \
count=10 oflag=sync status=progress && cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                60 kB
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0841956 s, 125 MB/s
Dirty:                68 kB <---- No data remaining in the dirty page cache after "dd" returned
1633260819
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                36 kB
1633260821
[rootuser@centos8-2 testarea]$

Es verbleiben keine Daten vom Schreibvorgang im Cache der unsauberen Seite.
Der Schreibvorgang wurde durchgeführt, bevor (oder zum gleichen Zeitpunkt) der Befehl "dd" zurückgegeben wurde (nicht 11 Sekunden nach dem vorherigen Test).
Jetzt bin ich sicher, dass nach dem Befehl "dd" gab es keine Daten im Dirty Page Cache in Bezug auf den Schreibvorgang = keine Probleme in der bootfähigen USB-Erstellung (wenn die ISO-Prüfsumme richtig ist).

Anmerkung: Berücksichtigen Sie dieses Flag (oflag=sync) des Befehls "dd", wenn Sie an dieser Art von Fall arbeiten.

Bootreihenfolge für Festplattenlaufwerke für Offline-Upgrades

Anforderung:

Wir müssen sicherstellen, dass die HDD mit der Option "DD" formatiert wird, die jedes verfügbare Tool verwendet, und die Medien sollten anschließend auf das Laufwerk kopiert werden. Wenn wir diese Formatierung nicht verwenden, können wir diese Medien nicht lesen.

Sobald wir die Medien auf der Festplatte/USB mit der "DD"-Formatierung geladen haben, müssen wir diese an die TGA-Appliance anschließen und das Gerät neu starten.

Dies ist der Standardbildschirm zur Auswahl des Startmenüs. Wir müssen "F6" drücken, um das Gerät zu booten und das Boot-Medium auszuwählen.

Sobald das Gerät unsere Eingabe erkennt, wird es aufgefordert, in das Boot-Auswahlmenü zu wechseln.

Dies ist die Eingabeaufforderung, die sich zwischen verschiedenen TGA-Modellen unterscheiden kann. Idealerweise würden wir die Option sehen, mit dem Boot-Medium (Upgrade-Dateisystem) aus diesem Menü selbst zu booten, aber wenn es nicht gesehen wird, müssen wir uns in der "EFI Shell" anmelden.

 

Sie müssten "ESC" drücken, bevor das Skript "startup.sh" beendet wird, um in die EFI-Shell zu wechseln. Sobald wir uns bei der EFI Shell anmelden, würden wir feststellen, dass die in diesem Fall erkannten Partitionen 3 Dateisysteme sind: fs0:, fs1:, fs2.

Wichtig

Identifizieren des richtigen Dateisystems:

• Wie im obigen Screenshot gezeigt, können Sie sehen, dass "fs0:" das einzige Medium ist, das "USB" in seinem Pfad hat, und daher können wir sicher sein, dass dieses Dateisystem das Boot-Medium enthalten würde (Upgrade-Dateisystem).

Bei fehlenden Dateisystemen:

• Wenn nur fs0: und fs1: sind verfügbar und es gibt kein fs2:, überprüfen Sie, ob das Boot-Medium (Upgrade-Dateisystem) im dd-Modus geschrieben wurde und erfolgreich verbunden ist.
• Boot-Medien (Upgrade-Dateisystem) sollten immer eine niedrigere Anzahl als die Wiederherstellungsmedien aufweisen und immer nebeneinander angeordnet sein. es ist, ob das USB-Laufwerk am Anfang des Endes ist, das sich wahrscheinlich ändern wird (also, ob es die vordere Position bei fs0 einnimmt: oder die Rückposition bei fs2:) muss identifiziert werden
• In diesem Fall ist im Screenshot unten die richtige ".efi"-Datei, wie sie sich unter der "\efi\boot"-Partition befindet und die Namenskonvention "bootx64.efi" hat

 

Um das Gerät im Boot-Medium (Upgrade-Dateisystem) zu booten, müssen wir die Datei "bootx64.efi" ausführen:

fs0:\efi\boot\bootx64.efi

Zu Ihrer Referenz haben wir die Inhalte der anderen Dateisysteme sowie unten angezeigt:

fs1: Dies ist das Haupt-Boot-Dateisystem.

fs2: Dies ist das Boot-Dateisystem des Recovery-Image.

Verschiedene Anweisungen:

Um das richtige Dateisystem zu überprüfen, das das gemountete Boot-Medium enthält. Wir können dies tun, indem wir die verschiedenen Dateisysteme durchsuchen und die ".efi"-Bootdatei überprüfen

Anmerkung: Die Reihenfolge der eigentlichen Boot-Medien (Upgrade-Dateisystem), die in diesem Fall "fs0:" ist, kann auch mit anderen Geräten variieren.
Der Name und der Pfad können variieren, aber in allen modernen Bildern sollte dies der gleiche sein.

Checkliste, die helfen kann, das richtige Boot-Medium zu finden (Upgrade-Dateisystem):

• Wenn der Root eines Dateisystems "vmlinuz-appliance" enthält, ist dies nicht das Boot-Medium (Upgrade-Dateisystem).
• Wenn der Root eines Dateisystems "meta_contents.tar.xz" enthält, ist dies nicht das Boot-Medium (Upgrade-Dateisystem).
• Wenn ein Dateisystem nicht "efi\boot\bootx64.efi" enthält, ist es nicht das Boot-Medium (Upgrade-Dateisystem).