Ho usato FreeBSD per circa 5 anni - server / desktop - e ho avuto la tendenza a prendere il mio aggiornamento apt-get / yum tutto ciò che mi accompagna (io gestisco anche le caselle Debian / RHEL / Cent - lo so, io sapere ... dovrebbe essere più esigente indipendentemente dalla piattaforma). Quindi di solito è un:

portsnap fetch
portsnap update
portmanager -u

Per i porti

A volte seguito da un:

freebsd-update fetch
freebsd-update install

Per il sistema ... ecc. Quindi ripulisci eventuali pasticci in seguito ... se si verificano.

Questo, mi rendo conto, è un modo abbastanza eccessivo di non fare BSD per fare le cose. Qual è la tua filosofia per le tue scatole BSD? Esegui una portaudit / portversion - controlla l'output e aggiorna (fai deinstallare ... ecc.) Dopo un'attenta valutazione?

Sono abbastanza nuovo per OpenBSD, lo confesso. Mi vedo a supportare l'albero delle porte, eseguire lo script "non aggiornato", quindi aggiornare solo le porte critiche --- ma lasciando solo il kernel / i binari e aggiornando ogni sei mesi. Patch / ricompila / ricostruisci kernel, binari --- perché?

Qual è un approccio conservativo per i servizi critici (ragionevolmente critico - questa non è una banca o un ospedale) per le scatole di BSD? Stai usando un approccio simile sui tuoi box Linux? In genere non tocco il kernel su nessun server a meno che un avviso di sicurezza non abbia colpito il terrore nella mia anima.

Sì, ci sono documenti e libri a bizzeffe - cosa fai veramente la gente? Supponendo che conosciamo le basi: qual è la saggezza? I casi d'uso / gli ambienti e gli scenari variano, così come la posta in gioco / le parti interessate / gli utenti. I libri e le pagine man descrivono strumenti e usi, ma mancano di un'applicazione pratica. Consiglia un libro se ne conosci uno che lo copre!

Grazie per aver letto!

Bubnoff

Conclusioni ~ Grazie a tutti coloro che hanno avuto il tempo di rispondere a questo post. La mia strategia nel complesso è ora quella di seguire le mailing list per entrambi i BSD ed essere più selettivo / esigente con l'aggiornamento rispetto a quanto non fossi in passato.

FreeBSD ~ Portaudit è una buona risposta. Con le mailing list e gli audit diligenti, penso che questo funzionerà bene qui. È interessante la diversa enfasi sulle porte tra OpenBSD e FreeBSD.

OpenBSD ~ Seguirà la mailing list e utilizzerà gli strumenti del pacchetto (pkg_info e pkg_add -u) dove ritenuto critico. Aggiornamenti: sembra che tu debba aggiornare almeno una volta all'anno. Supportano la versione più recente più una parte posteriore, quindi al momento sono 4.8 e 4.7.

Grazie ancora.

Assicurati di controllare le porte installate per i pacchetti vulnerabili ogni tanto: portaudit -Fda

Non sono sicuro che esista un "modo BSD" specifico per fare questo tipo di cose. Tutto si riduce a sapere cosa viene aggiornato e testato: cose generiche di amministratore di sistema. Fortunatamente, freebsd-update e portsnap rendono il "sapere cosa" abbastanza banale.

Ma, dal momento che hai chiesto dettagli, quando ho raccolto un gran numero di macchine FreeBSD, erano tutti nodi in un cluster. Le macchine indipendenti non sarebbero così diverse da questa, ma immagino che potresti renderlo vagamente 'devops' come per i tuoi servizi di produzione. Alla fine, è sempre una buona idea avere ambienti di test e produzione separati.

Nella situazione del cluster:

• Ogni macchina ha montato / usr / src , / usr / obj e / usr / doors tramite NFS.
• A seconda del budget, è possibile disporre di una macchina di gestione temporanea / generazione o designare un nodo del cluster come nodo di gestione temporanea / generazione.
• Il nodo di gestione temporanea aveva una copia diversa di / usr / doors
• Il nodo di gestione temporanea aggiornerebbe src-all e porti-all tramite cvsup ogni notte
• Nel caso di un aggiornamento necessario, il nodo staging verrebbe prelevata dal rotazione e buildworld , installworld e portupgrade sarebbe gestita.
• Il nodo di gestione temporanea verrà testato a fondo.
• / usr / doors verrebbe scambiato sull'host NFS
• Ogni nodo di cluster verrebbe ruotato fuori conduzione installworld e portupgrade , testato e quindi ruotato indietro in.

Ovviamente, questo era sia nel caso di un aggiornamento del sistema che delle porte, ma la procedura era abbastanza simile aggiornando solo i pacchetti o il sistema.

Se questo viene fatto con due macchine, ognuna può alternarsi come produzione o messa in scena, o semplicemente aggiornare la produzione dalla messa in scena.

Puoi tenere traccia delle modifiche dai log di cvs e verificare se hai ottenuto aggiornamenti specifici in / usr / src / UPDATING e / usr / doors / UPDATING , entrambi i quali vengono automaticamente aggiornati da cvsup .

Se non usi cvsup (e oggigiorno c'è meno motivo per farlo) dovrai solo trovare un altro modo per tenere traccia degli aggiornamenti che desideri. Puoi inviare un elenco di modifiche che freebsd-update vuole apportare a te stesso e tenere d'occhio la pagina degli errori di sicurezza.

Filosofia dell'aggiornamento di OpenBSD

Questo è il mio approccio per l'aggiornamento di OpenBSD

Rimani aggiornato su patch / release di sicurezza per:

• BASE (ovvero le cose che il team di sviluppatori OpenBSD mantiene nel loro albero dei sorgenti)
• Pacchetti / porte (ovvero applicazioni software installate nella parte superiore di BASE)

Procedure di aggiornamento:

• Stessa versione del sistema operativo
• Nuova versione del sistema operativo

BASE

un. Segui le relative mailing list : guardo i digest giornalieri di squish.net, nonché la direzione generale indicata sulle mailing list di Tech e Misc.

b. Seguire i siti Web / le mailing list relativi agli annunci di sicurezza relativi a Unix.

c. Mantenere una copia CVS locale dell'uso di cvsync

d. Crea versioni STABILI da quanto sopra

Quando vengono pubblicati gli aggiornamenti di sicurezza, valutiamo l'effettivo problema di sicurezza con il profilo dei computer con quella versione del sistema operativo / vulnerabilità. Se la vulnerabilità è rilevante, passiamo attraverso la "stessa procedura di aggiornamento della versione".

Pacchetti / Porte

È più difficile tenere traccia degli aggiornamenti di sicurezza per porte / pacchetti, ma se è abbastanza critico per essere sulla nostra infrastruttura, è abbastanza importante tenere traccia in modo simile a BASE.

• Entra nella mailing list per l'applicazione specifica (è nostra responsabilità tenere sotto controllo le modifiche a monte, indipendentemente dal progetto OpenBSD.)

• Accedere alle liste di distribuzione di sicurezza si trova come CERT che pubblica i risultati delle vulnerabilità su app ecc.

Le procedure di aggiornamento

Ovviamente compilare e testare la procedura di installazione su hardware separato (o VM) prima di eseguirla sui computer di produzione. Fortunatamente per noi, abbiamo host ridondanti per molte cose e possiamo quindi implementare con tempi di inattività minimi dei servizi. Poiché OpenBSD supporta un'ampia gamma di hardware, possiamo implementare apparecchiature di livello server per le nostre macchine primarie e desktop di fascia bassa come nostri host ridondanti (o semplicemente costruiamo un box temporaneo da compilare per la macchina principale durante il ciclo di aggiornamento).

Le nostre procedure di aggiornamento dipendono fortemente dall'utilizzo del sistema di porte / pacchetti per software non BASE. I due host in cui installiamo il software dal sorgente sono un problema da aggiornare tra gli aggiornamenti di versione del sistema operativo.

Stesso aggiornamento del sistema operativo

Per il sistema operativo BASE, continuiamo ad avere successo semplicemente installando i nuovi binari rispetto a quelli vecchi. Preferibilmente, eseguiamo il backup di tutti i file di configurazione / dati del sistema operativo e delle applicazioni, formattare e reinstallare il sistema operativo con patch e reinstallare i pacchetti (conservando i dati originali)

Nei nostri host OpenBSD distribuiti (30+) ed esperienza, il backup della configurazione e dei dati non è difficile. Per i nostri firewall, tutti i dati si trovano nei file di configurazione e di registro.

Per porte / pacchetti - dove le modifiche sono semplici, modifichiamo la nostra porta e costruiamo il pacchetto da quello. Avere una porta aggiornata semplifica il processo sopra.

Nuovo aggiornamento del sistema operativo

Tra le versioni del sistema operativo, installiamo tutto dallo sketch.

Sono sicuro che c'è abbastanza documentazione là fuori per il processo, ma essenzialmente costruiamo una macchina di riferimento con la stessa configurazione del sistema da "sostituire". Passare attraverso gli stessi test richiesti prima di distribuire l'host.

Effettuiamo il backup della configurazione dall'host di riferimento e installiamo OpenBSD sull'host di produzione, ripristinandone la configurazione "verificata" (eseguendo nuovamente gli stessi test di convalida in seguito).

Per OpenBSD, almeno:

• i pacchetti sono il prodotto finale del sistema portuale; ci dovrebbe essere poco, se del caso, è necessario correre con le porte.
• -release e -stable è (principalmente) congelato nel tempo, con alcuni aggiornamenti di volta in volta.
• -corrente viene regolarmente aggiornato. Se hai davvero bisogno di pacchetti aggiornati, questa è la strada da percorrere.
• rimanere coerenti: i sistemi -release / -stable si attaccano ai pacchetti -release / -stable ...

Faq 15, tutto su porte e pacchetti

Se non ci sono problemi di sicurezza o bug che ostacolano la funzionalità, lascialo in pace. Verifica la disponibilità di aggiornamenti ogni 3-6 mesi in modo da non rimanere troppo indietro, ma altrimenti lascia da solo le cose.

Se non è rotto, non aggiustarlo.

Preferisco utilizzare portupgradeper l'aggiornamento delle porte e farlo solo quando assolutamente necessario , ad esempio quando viene rilevata una vulnerabilità nella porta o sono necessarie nuove funzionalità.

Per quanto riguarda l'aggiornamento del sistema, di solito ricostruisco da fonti con make buildworld. Non ho mai avuto problemi con questo approccio.