Update or not update?
Qualche giorno fa stavo cercando su internet ispirazione per risolvere un problema quando mi sono imbattuto in questo post contenente una frase che mi ha fatto riflettere:
I did a hugest mistake on my it-career…
I only wanted to upgrade ntp package on all servers which i administrate. Simple task, huh?
I run this command:
[…]
And some servers (several hundred!!!) was fully upgraded!!! Of course it is very high impact for business… Because some server was never updated several years…
Server, nel post mi riferisco principalmente a questi, mai aggiornati in diversi anni?
Ora, dalla fine dell’università, oltre una decade per intenderci, ho lavorato sempre nella stessa azienda, forse non ho l’esperienza di infrastrutture molto più complesse o diverse ma … mai aggiornati in diversi anni mi pare un approccio un po’ discutibile.
Se da un certo punto di vista si applica la regola d’oro “funziona? non lo toccare” dall’altro un sistema non aggiornato è un sistema più vulnerabile; non solo, con il passare del tempo si accumulano tutti quei rischi (perché ce ne sono) legati all’aggiornamento.
Vuoi che un audit del sistema forzi a fare l’aggiornamento per via delle patch di sicurezza, piuttosto che un banale errore come scritto sopra, o banalmente una risoluzione delle dipendenze per l’aggiornamento di un qualsiasi pacchetto causi una valanga, saremmo potenzialmente in una brutta situazione.
Pensate semplicemente se i 2 problemi menzionati nell’articolo su Amazon Linux fossero comparsi nello stesso momento della più recente e invasiva patch di sicurezza di log4j rilasciata da Amazon Linux 2 che di fatto andava a sostituire log4j all’interno del sistema.
Vero che ci sono backup e snapshot (viva le macchine virtuali) però a livello personale non credo sia l’approccio migliore, proviamo a vederne qualcun’altro.
Aggiornamenti automatici
Da un punto di vista della sicurezza questo è sicuramente l’approccio migliore tuttavia, per mia conoscenza di yum-cron, se saltasse fuori un problema, lo farebbe ovunque nel giro di una giornata quindi sugli ambienti di produzione o mission critical non è proprio l’approccio migliore. Gli aggiornamenti automatici hanno un gran senso su server non mission critical tipo ambienti interni di sviluppo o pre-produzioni, eccetera perché aiutano ad anticipare i problemi su macchine più critiche. In ogni caso un configuration manager o dei banali script che controllano la configurazione sono sempre utili, prima che l’aggiornamento resetti i file di configurazione ai valori di default.
Aggiornamenti manuali periodici – “La virtù sta nel mezzo”
Si potrebbe banalizzare semplicemente come: aggiorniamo le macchine una volta al mese, oppure in base al periodo desiderato.
In realtà io approccio la cosa in maniera più organizzata:
– uno script che gira mensilmente parsa l’output di yum-check update e mi notifica via email i pacchetti disponibili per l’aggiornamento, oramai sappiamo che l’aggiornamento di certi pacchetti ha effetti sulla configurazione, ad esempio aggiornare sudo resetta i permessi di /etc/sudoer, l’aggiornamento di clamd cambia il parametro di restart, eccetera
– gli ambienti di sviluppo interno hanno aggiornamenti automatici
– si aggiornano prima gli ambienti di pre-produzione
– il giorno dopo (o qualche giorno dopo) si aggiornano gli ambienti più critici sul presupposto che non siano usciti altri aggiornamenti nel frattempo, altrimenti la giostra ricomincia.
Extrema ratio
Nella speranza di fare la cosa più giusta sono capitato su questo post e nei commenti si suggeriva di generare una lista di aggiornamenti smanacciando l’output di yum list updates:
[root@cent7 ~]# pkgs=`yum -q list updates 2>&1 | tail -n+2 | awk '{print $1 "|" $2}' | sed 's/\.[^.]*|\(.*\:\)*/-/' | tr "\n" " "`
e di generare un comando con parametri per aggiornare solo quei pacchetti a quella versione con yum update-to:
[root@cent7 ~]# echo "yum update-to $pkgs" yum update-to dbus-1.10.24-13.el7_6 dbus-libs-1.10.24-13.el7_6 java-1.8.0-openjdk-1.8.0.242.b08-1.el7 java-1.8.0-openjdk-headless-1.8.0.242.b08-1.el7 tzdata-java-2019c-1.el7 unzip-6.0-21.el7
Un po’ hardcore ma la cosa ha assolutamente senso. No, non l’ho mai provato.
Conclusioni
Non credo ci sia un approccio giusto o uno sbagliato, ce ne sono diversi, io ho provato a passarli in rassegna tutti evidenziando debolezze e punti di forza. Certo devono esserci motivi molto molto forti per non applicare le patch di sicurezza per non perturbare l’ambiente, ma l’idea che l’inaspettato scoperchi il vaso di pandora è una cosa che mi terrorizza. E ora la domanda: voi come fate e perchè? Avete voglia di raccontarlo nei commenti?
Fonte: http://www.marcosbox.org/2022/01/update-or-not-update.html
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
