la produzione di ksplice è pronta?


15

Sarei interessato a sentire le esperienze della comunità serverfault con Ksplice in produzione.

Blurb veloce da Wikipedia:

Ksplice è un'estensione gratuita e open source del kernel Linux che consente agli amministratori di sistema di applicare patch di sicurezza a un kernel in esecuzione senza dover riavviare il sistema operativo.

e

Ksplice può, senza riavviare il kernel, applicare qualsiasi patch del codice sorgente che deve solo modificare il codice del kernel. A differenza di altri sistemi di aggiornamento a caldo, Ksplice prende come input solo un diff unificato e il codice sorgente del kernel originale e aggiorna correttamente il kernel in esecuzione, senza ulteriore assistenza umana. Inoltre, sfruttare Ksplice non richiede alcuna preparazione prima che il sistema sia stato avviato (ad esempio, non è necessario che il kernel in esecuzione sia stato compilato in modo speciale). Per generare un aggiornamento, Ksplice deve determinare quale codice all'interno del kernel è stato modificato dalla patch del codice sorgente.

Quindi alcune domande:

Come è stata la stabilità? qualche strano problema che hai riscontrato con la sua "patch live senza riavvio" del kernel? Panico del kernel o storie dell'orrore?

L'ho eseguito su alcuni sistemi di test e finora ha funzionato come pubblicizzato, ma sono interessato a ciò che altre esperienze di amministratore di sistema hanno avuto con Ksplice prima di andare "all in" e distribuirlo sui nostri server di produzione.

Quindi, qualcuno usa Kspice in produzione?

aggiornamento: hmm, non vedo alcuna vera attività su questa domanda dopo un paio d'ore (oltre ad alcuni voti positivi e favoriti). Forse per scatenare un po 'di attività, farò anche qualche altra domanda e vedrò se possiamo portare avanti questa discussione ...

"Se sei a conoscenza di Ksplice, c'è un motivo per cui non lo stai usando?"

"Senti il ​​suo bordo ancora troppo sanguinante, non provato o non testato?"

"Ksplice non si adatta bene al tuo attuale sistema di gestione delle patch?"

"Odi avere sistemi che hanno tempi di attività lunghi (e sicuri)?" ;-)


1
Bene, l'ho anche testato solo in una VM di prova Ubuntu 9.04. Ma finora funziona benissimo.
knweiss,

Risposte:


9

(In primo luogo, un disclaimer: lavoro per Ksplice.)

Lo usiamo sulla nostra infrastruttura di produzione, naturalmente, ma soprattutto, così fanno i nostri oltre 500 clienti aziendali (numero al 10 dicembre).

Un amministratore di sistema pone la stessa domanda a una mailing list di utenti di Red Hat Enterprise Linux e riceve una serie di risposte, alcune delle quali sono riportate di seguito:

Abbiamo eseguito Ksplice in produzione per alcuni mesi su una dozzina di host. Finora funziona come pubblicizzato.

e

Ho> 500 macchine sotto il mio controllo, di cui circa 445 sono collegate a uptrack (rhel 4 e 5). Abbiamo usato ksplice per bloccare alcuni exploit di root prima di avere la possibilità di riavviare le macchine. Dato che stiamo ancora testando, abbiamo comunque implementato il nuovo kernel, ma ho eseguito per settimane ksplice'd senza problemi.

Una preoccupazione espressa dalla gente non riguarda la stabilità, ma piuttosto la sua integrazione con gli strumenti di controllo e monitoraggio esistenti:

L'unico "gotcha" sull'uso di ksplice è che non sono ancora disponibili strumenti di controllo "ksplice-aware".

Come ci si potrebbe aspettare, questa è un'area in cui stiamo investendo molto.


Gente, sono nuovo qui, quindi fatemi sapere se non ho fatto bene e sono felice di sistemare le cose come necessario.
Wdaher,

5

Ho sentito parlare di Ksplice e all'epoca pensavo fosse una buona idea. Nessun tempo di inattività, nessun riavvio. Ma poi ho esaminato un po 'di più e ho avuto paura di provarlo.

Le mie ragioni per evitarlo sono:

  • Il kernel di Linux è già molto complesso. Ksplice aumenta la complessità. Più complessità = più fallire.

  • Sarà sconsiderato sperimentare Ksplice su un server remoto in cui un guasto causerebbe lunghi tempi di inattività e costose riparazioni.

  • L'unico vantaggio nel mio caso sarebbe una statistica di uptime superiore.


2
+1 per aggiungere complessità. Alcuni minuti di downtime sono molto meglio che eseguire un intervento a cuore aperto sul kernel nel mezzo della produzione.
Urda,

4

Ho usato Ksplice sul mio server di casa (dove il tempo di attività non è critico ma è bello da avere). Non ho avuto alcun problema con esso - aggiornamenti occasionali tramite Apt al client, mai problemi con gli aggiornamenti del kernel stessi e nessuna instabilità (evidente).

Tuttavia, si applica il solito disclaimer "YMMV"! ;-)


1
+1 su questo, l'ho usato su un server non critico e ha funzionato egregiamente.
JamesHannah,

2

Ksplice è un'estensione del kernel open source, ma tieni presente che mentre il software è gratuito e disponibile per chiunque, è stato creato appositamente da e per un'azienda che gestisce le patch di Linux (anche chiamato "Ksplice"). Ksplice (la mod del kernel) è davvero utile solo se hai patch utilizzabili da ksplice per il tuo kernel, che probabilmente non vedrai mai se non hai un contratto di supporto con Ksplice (la società).

Quindi, mentre ksplice (lo strumento) è ragionevolmente maturo, è davvero rilevante solo se stai considerando di usare Ksplice (la società) per la gestione delle tue patch.


1

Buona domanda. La mia risposta iniziale sarebbe qualcosa del tipo "perché ne ho bisogno?"

Molto probabilmente no bisogno. Anche in una configurazione a cinque nove, la "manutenzione programmata" è spesso una clausola in uno SLA che consente questo tipo di downtime. Se si dispone di un'installazione HA, quindi passare al failover, installare il kernel su una casella, riavviare e ripetere sull'altra. Se non puoi permetterti nemmeno cinque minuti di downtime su una scatola, allora hai comunque bisogno di una configurazione di failover.

Sebbene sia una tecnologia innovativa, non vedo ancora molto pragmatico. Gli aggiornamenti di sicurezza del kernel sono necessari, ovviamente, e dovrebbero essere patchati al più presto, ma quanto tempo / sforzo / preoccupazione ti risparmia rispetto alla semplice installazione di un nuovo kernel e al riavvio? E se qualcosa va storto? Quanto tempo hai perso quindi ri-imaging del sistema, supponendo che sei abbastanza fortunato da avere un'opzione di ripristino di tipo PXE?

Inoltre, come menzionato sopra, sperimentare a distanza una tecnologia come questa potrebbe essere una catastrofe se si guasta su più server. Nel tuo test, stai usando lo stesso hardware esatto nel DC? Ciò che suona bene su una macchina potrebbe non essere bello su un'altra.

Solo i miei $ 0,02.


1
Sì, l'hardware nel mio banco di prova rispecchia la produzione.
faultyserver,

-1

È molto tempo fa, ma ciò che Ksplice può fare per te è molto ...

  • Maggiore sicurezza in quanto consente patch al volo senza tempi di inattività, questo può essere estremamente importante in ambienti altamente sensibili.

  • Stabilità migliorata in quanto consente patch al volo senza tempi di inattività, le cose possono migliorare mentre non è disponibile il tempo per un riavvio.

  • Prestazioni migliorate in quanto consente patch al volo senza tempi di inattività, applicando esattamente ciò di cui hai bisogno per ciò di cui hai bisogno.

  • Miglioramento dell'attività pro poiché consente patch al volo senza tempi di inattività, quindi è possibile impostare una farm di test per nuove patch calde mentre si torna facilmente a uno stato precedente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.