L'applicazione di patch e l'aggiornamento dei sistemi è un passaggio fondamentale per ridurre i possibili vettori di attacco contro la tua infrastruttura. Quando ci sono sistemi nel tuo ambiente che non sono aggiornati con le patch, potrebbero esserci vettori di attacco di cui non sei a conoscenza e che potrebbero influenzare l'intera organizzazione. Tuttavia, quali passaggi hai in atto quando un evento di patching non va come previsto?
[ Ai lettori è piaciuto anche: proteggere un sistema Linux ereditato ]
Ad esempio, le dipendenze potrebbero non essere soddisfatte, potrebbero esserci versioni non corrispondenti tra i686 e x86_64 RPM, le nuove versioni del pacchetto potrebbero non funzionare come previsto o qualcos'altro potrebbe andare storto. Quando qualcosa va storto, è importante avere un piano su come procedere. Ciò ridurrà il livello di stress e garantirà che tutti coloro che lavorano sull'attività sappiano cosa stanno facendo le altre persone.
Test patch
Durante l'applicazione delle patch, è importante prima testare le patch in un ambiente di test che corrisponde al tuo ambiente di produzione . Se si testano le patch su hardware diverso, con versioni software diverse o con carichi di lavoro o processi diversi rispetto all'ambiente di produzione, non vi è alcuna garanzia che i risultati del test di patch riflettano ciò che accadrà in produzione. Una volta che hai un ambiente di test in cui puoi verificare che un determinato pacchetto di patch debba essere installato, ridurrai notevolmente le possibilità di problemi durante l'installazione degli aggiornamenti.
Patch fallite
Se gli aggiornamenti non vengono installati, la prima cosa da fare è acquisire qualsiasi output sulla console o nei log. Potrebbe essere semplicemente la copia di un file di registro in una posizione separata o potrebbe essere la copia del testo visualizzato sullo schermo della console. A seconda di come è stata tentata l'applicazione delle patch, potresti voler provare a eseguire nuovamente gli aggiornamenti, questa volta con l'output dettagliato abilitato. Una volta ottenuto l'output dell'errore, vorrai vedere eventuali differenze tra il tuo ambiente di test e quello che hai in produzione. È inoltre necessario verificare che tutte le patch siano state applicate durante il test e che nessuna patch o errore sia stato perso accidentalmente. Un elemento essenziale da controllare è l'elenco degli RPM installati sul server di prova da confrontare con le versioni nel server di produzione.
Ad esempio, sul server di produzione:
# rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'| sort &> /tmp/rpm-qa.prod.output.txt
Puoi quindi confrontarlo con l'output raccolto sul tuo server di test nel suo /tmp/rpm-qa.dev.output.txt .
Dovresti anche verificare che sia disponibile yum i repository sono gli stessi su entrambi i sistemi. Puoi farlo in tre semplici passaggi.
Per prima cosa, svuota la cache:
# yum clean all
# rm /var/cache/yum/* -rf Quindi, aggiorna il gestore delle iscrizioni:
# subscription-manager refresh
Terzo, elenca i repository in yum con il -v argomento in modo da poter visualizzare informazioni aggiuntive come il repodate e il numero di pacchetti nei repository:
# yum repolist -v Nell'esempio seguente, esamineremo rhel-8-for-x86_64-appstream-rpms repository utilizzato da un client sul mio server Red Hat Satellite:
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision: 1605844838
Repo-updated : Thu 19 Nov 2020 11:02:03 PM EST
Repo-pkgs : 13,502
Repo-size : 31 G
Repo-baseurl : https://opendemo.usersys.redhat.com/pulp/repos/opendemoorg/Library/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 1 second(s) (last: Wed 31 Dec 1969 07:00:00 PM EST)
Repo-filename: /etc/yum.repos.d/redhat.repo Le linee chiave qui sono repo-id , aggiornato repo , pacchetti repo e repo-baseurl . Se i miei sistemi di test e produzione mostrano informazioni diverse per i loro repository a monte, è possibile che le dipendenze non vengano soddisfatte o che qualcos'altro possa fallire. In tal caso, dovresti indagare sul motivo per cui i sistemi visualizzano informazioni diverse.
Altre impostazioni
Si supponga che i sistemi di test e produzione abbiano gli RPM previsti e gli stessi repository, ma l'applicazione delle patch continua a non funzionare. In tal caso, altre possibili cause potrebbero essere un'impostazione di sicurezza applicata in modo errato, spazio su disco insufficiente o forse autorizzazioni utente errate. Per esaminarli, controlla i log come /var/log/messages , /var/log/secure e /var/log/audit/audit.log potrebbe essere utile, oltre a usare il comando df -h per controllare lo spazio su disco. Inoltre, i clienti Red Hat possono aprire un ticket di supporto per ricevere assistenza nella risoluzione del problema.
[ Corso online gratuito:panoramica tecnica di Red Hat Enterprise Linux. ]
Concludi
Esistono molte possibili cause per le patch che non vengono installate correttamente, ma essere in grado di confrontare l'ambiente di test con l'ambiente di produzione renderà la risoluzione dei problemi molto più semplice. Configurazioni, dipendenze, carichi di lavoro e repository dovrebbero essere tutti gli stessi nei due ambienti.