Moderatore: Staff
ilyapunov ha scritto:3 motivi. Come detto:
1) sicurezza --> vedi bug di vmsplice del 2.6.17 (local root exploit...mi sembra un buon motivo).
2) prestazioni --> vedi migliorie alla vm nel trunk del 2.6.25.
3) generiche ottimizzazioni e correzioni di bug?
ripeto ancora una volta, il tempo per farlo magari è lo stesso, ma non è la stessa cosa.lyapunov ha scritto:Scaricare una patch per correggere un bug, oppure scaricare l'ultima patch del kernel per portarlo da .17 a .18 per correggere quel bug la differenza mi sembra davvero irrisoria.
IMHO naturalmente.
E' perchè ha poco senso? Sarà solo una questione di punti di vista, ma i server mi sembrano degli oggetti statici più che dinamici. Non voglio dire che sia un errore abilitare il supporto ai moduli, ma mi sembra esagerato dire che ha poco senso non averlo.masalapianta ha scritto:....difatti su macchine server ha poco senso usare un kernel che non supporti i moduli...
perche' una volta che sul modulare hai disabilitato CAP_SYS_RAWIO e CAP_SYS_MODULE, a livello di sicurezza i due approcci si equivalgono, mentre a livello di praticita' vince nettamente il modulare; questo perche':spina ha scritto:E' perchè ha poco senso? Sarà solo una questione di punti di vista, ma i server mi sembrano degli oggetti statici più che dinamici. Non voglio dire che sia un errore abilitare il supporto ai moduli, ma mi sembra esagerato dire che ha poco senso non averlo.masalapianta ha scritto:....difatti su macchine server ha poco senso usare un kernel che non supporti i moduli...
Spina...Visto che il kernel controlla il networking del vostro computer, è importante che sia molto sicuro e non venga compromesso. Per evitare alcuni dei recenti attacchi via rete dovreste tentare di mantenere aggiornato il vostro kernel....
. . "aggiornare" non significa necessariamente utilizzare l'ultima release disponibile, ma anche patchare la medesima release con i vari aggiornamenti di sicurezzaspina ha scritto:Dal Linux Security HOWTO:
...Visto che il kernel controlla il networking del vostro computer, è importante che sia molto sicuro e non venga compromesso. Per evitare alcuni dei recenti attacchi via rete dovreste tentare di mantenere aggiornato il vostro kernel....
io temo che tu non abbia ben chiaro cosa sia programmare, i bug, a meno che tu non stia scrivendo hello world, vanno di pari passo col codice, il fatto che tu sia un bravo programmatore non significa che il tuo codice e' esente da bug e, tirando in ballo il discorso del kernel linux, una delle maggiori critiche rivolte all'andamento che ha preso lo sviluppo negli ultimi anni e' proprio che si tende a scrivere codice e rilasciarlo in fretta e furia per via degli interessi che molte aziende, che finanziano lo sviluppo, hanno nel vedere supportato il loro hardware o questa o quella feature che serve a loro; non a caso negli ultimi anni sono usciti un sacco di bug del kernel (molti dei quali riguardavano problemi di sicurezza che permetttevano di scalare i privilegi da locale); quindi buona norma e' usare release non recentissime del kernel, facendo il backporting dei fix, questa non e' una mia idea personale ma lo standard de facto in ambiente enterprise, se ci vuoi credere bene, altrimenti io stanotte dormo bene lo stesso:Edit: Comunque mi fate morire, pensate alla scenetta:"Linus, è vero che se installo il kernel current sono meno sicuro?". Cosa cavolo volete che vi risponda? Si, tanto noi il nostro lavoro non lo sappiamo fare?
una delle cose buone dello scritto, rispetto al parlato e' che se non hai capito puoi sempre rileggere con calma, ti consiglio di farlospina ha scritto:Bho, masalapianta, sarà l'ora tarda, sarà che hai aperto tante parentesi, ma io non ci ho capito molto.
che e' appunto modularePrima cerchi di spiegare perchè il kernel modulare è meglio di quello statico, e poi dici che tanto tutti usano quelli delle distribuzioni.
e' esattamente quello che faccio ioCioé, il ragionamento che fanno le distribuzioni non è proprio quello che fai tu,
no, loro lo fanno modulare perche' e' piu' pratico e perche' non e' necessario fare un kernel gigantesco compilato staticamente con tutte le funzionalita' possibili (le architetture c'entrano come i cavoli a merenda in questo caso; infatti le distro offrono n versioni del medesimo kernel modulare, uno per ogni architettura; difatti il fatto che un kernel sia modulare non significa che possa girare indifferentemente su sparc o x86); la prima delle due motivazioni e' quella che ho esposto nell'altro postloro lo fanno modulare solo perchè non sanno su che architettura andrà a finire il kernel
slackware in ambiente enterprise e' praticamente inesistentePer quanto riguarda i kernel stabili, non so se vi ricordate ma anche l'ultima release della Slackware aveva il kernel current dell'epoca.
e' la stessa cosaE' ovvio che il passaggio dal 2.4 al 2.6 doveva essere lento, ma mi permetterete di dire che non è la stessa cosa.
io temo che tu non abbia ben chiaro cosa si intende per architettura (che e' quella del processore e non l'insieme di tutto l'hardware della macchina); e torno a dire che a meno che tu non abbia 500 macchine identiche (impossibile se non parliamo di cluster per calcolo parallelo o render farm), e'verosimile che con kernel monolitici, in caso di aggiornamento tu debba ricompilare se non 500 kernel, un numero che gli si avvicina moltoAncora, se ho 500 macchine con la stessa architettura e voglio modificare qualcosa al kernel, lo ricompilo solo una volta e non 500, ma forse non ho capito che volevi dire.
supponevi male, e no, non lo si fa per divertimento ma perche' richiestoE infine, è vero che sui kernel modulari si può lanciare modprobe, laddove su un kernel statico senza supporto per i moduli non si può, ma è proprio per questo che ho detto che i server mi sembrano "statici", supponevo cioè, che non ci si divertisse a fare modprobe, ma che lo si lasciasse in pace a fare il proprio lavoro.
Markus77, dimentichi chemarkus77 ha scritto:lol lol lol lol lol lollyapunov ha scritto:Ma la finite di prendervela con Mario?. E' il secondo attacco nel giro di pochi giorni e la cosa non mi sta bene visto che considero Mario (e chiedo scusa se lo chiamo per nome) come una persona dalla quale imparare molto e che rispetto grandemente visto la sterminata competenza.
E spero che questo non generi un flame.
Chiedo anticipatamente scusa a Paoletta, Luci0 e tutti i moderatori.
mi hai fatto scompisciare dal ridere dai.. imparare molto ?' si come funzionavano i vecchi Unix AT&T System V
e le R3 e R4
Certo se leggi bene quello che consiglia è di usare root come user di non usare crittografie moderne, perchè non servono, e nessun tipo di precauzione contro attacchi, infatti, chi ti viene a cercare nel mondo cosi vasto di internet ?? in tanti ani passati a gestire macchine 24/365 non ha avuto mai intrusioni, forse perchè all epoca erano in 4 gatti su internet.. E poi, se ci fai caso, lui risponde solo quando pensa che l user sia inferiore a lui.
Altrimenti, perchè ongi volta che masalapianta, per esempio gli fa notare che dice una cavolata, e succede spesso, non gli risponde ?? dammi retta, se vuoi imparare, prendi lezioni da altri e non da lui.
Si, ma sei tu che escludi una delle due interpretazioni, non io.masalapianta ha scritto:...
"aggiornare" non significa necessariamente utilizzare l'ultima release disponibile, ma anche patchare la medesima release con i vari aggiornamenti di sicurezza
Da linux.html.itFondata nel 1992 da Patrick Volkerding, Slackware è la più vecchia sopravvissuta distribuzione GNU/Linux. E' molto sicura, stabile ed è spesso raccomandata per le installazioni server...
quindi, se l'ultima Slackware ha il kernel corrente dell'epoca, dovrebbe voler dire che Pat riteneva quel kernel current quantomeno sicuro......spero.Slackware è stata una delle primissime distribuzioni a comparire sulla scena del mondo OpenSource (è presente fin dall'Aprile del 1993)....Risulta anche un'ottima scelta sui server, grazie alla fama di distribuzione sicura che ha saputo farsi col passare degli anni...
ancora...Tuttavia, a causa della frammentazione in molti file, l'uso dei moduli può essere fonte di errori....
Effettivamente ho usato il termine architettura in maniera errata quando ti parlavo di distribuzioni, quello che volevo dire è che le distribuzioni offrono i kernel modulari perchè non sanno su quale hardware andrà a finire, e non per i motivi pratici 1) e 2) che spieghi nell'altro post....Le distribuzioni GNU/Linux tendono a fornire agli utilizzatori un kernel modulare per usi generali....
Intanto non è così impossibile, visto che quando un azienda compra dei PC, li compra in massa e tutti dalla stessa casa prodruttrice (con la quale generalmente ha un contratto), e tutti identici. Poi, se hai architetture diverse, devi compilare tante volte il kernel per quante architetture hai, semplicemente perchè se hai compilato il kernel per x86, non puoi portarlo sulla macchina sparc, ma questo discorso vale sia per i kernel modulari sia per quelli non modulari. Cioè, supponiamo che io ho tre macchine con architetture diverse, se voglio pathcare il kernel per correggere un bug, allora lo devo fare su tutte e tre le macchine e devo ricompilare il kernel su tutte e tre le macchine. Se invece le macchine sono tutte e tre uguali, mi basta farlo su una e ricompilare il kernel una volta....ma a prescindere dal fatto che il kernel sia modulare o no.masalapianta ha scritto:...e torno a dire che a meno che tu non abbia 500 macchine identiche (impossibile se non parliamo di cluster per calcolo parallelo o render farm), e'verosimile che con kernel monolitici, in caso di aggiornamento tu debba ricompilare se non 500 kernel, un numero che gli si avvicina molto...
, mi piace discutere, tutto qui.
