Newsgroup: it.comp.os.linux.sys
Titolo: Distribuzione per piccolo server

Salve a tutti, vorrei chiedervi un parere.
Ho una macchina Linux che fa da server samba, jabber, dhcp, ssh e poche
altre cose in un piccolo ufficio, niente di trascendentale, pochissime
porte (2-3) aperte all'esterno.
Al momento c'è una Mandrake 9.0, installata a suo tempo.
Ho usato la Mandrake perché è quella con cui ho più familiarità, e vorrei
continuare a usarla, aggiornando ora alla 10.0. Però... ho la sensazione
che "il meccanismo" di pacchetti e aggiornamenti mi stia un po' stretto.
Cerco di spiegarmi:
- aggiornamenti per la 9.0 non ne escono più, e quelli già usciti non sono
più reperibili (per lo meno, li ho cercati in un po' di mirror senza mai
trovarli, magari da qualche parte si trovano ancora), quindi si è
costretti ad aggiornare la distribuzione; a volte possono bastare i
sorgenti, ma non quando il software inizia a richiedere librerie e altro
software in versioni più nuove di quelle in tuo possesso, ed entri in un
circolo vizioso dal quale esci solo aggiornando l'intero sistema;
- non mi fido molto della procedura di aggiornamento 9.0 -> 10.0 (faccio
male?), quindi mi toccherebbe fare un backup delle configurazioni e
reinstallare tutto da zero;
- a volte si vorrebbe installare subito l'aggiornamento di un software per
qualche bugfix o miglioria di cui si ha bisogno, ma il pacchetto per la
distribuzione non è immediatamente disponibile; ad esempio, mi sembra che
l'ultimo pacchetto Mandrake di Samba risalga alla versione 3.0.2a, mentre
fin dall'8 maggio è disponibile su 
samba.org
 la 3.0.4.
Quindi mi chiedo: cosa è consigliabile fare, per evitare queste situazioni
in futuro?
Ci sono distribuzioni particolarmente curate per quanto riguarda la
pubblicazione e l'installazione di aggiornamenti?
Oppure l'unica soluzione sono i sorgenti? Rischio però di trovarmi in quel
"circolo vizioso" di cui parlavo prima, e quindi finire per dover
ricompilare tutte le componenti del sistema.
Grazie per eventuali consigli.
-- 
Ciao,
  Marco.
..."Have a Little Faith", Bill Frisell 1993

 ricompilare tutte le componenti del sistema.
Debian. (google is your friend, comunque... è tutto documentato)
Max

 ha scritto nel messaggio
news:6h91240t0l8w.1v...@40tude.net...
 > Debian. (google is your friend, comunque... è tutto documentato)
E come si fa a nno darti ragione?
Mi unisco al coro... Debian!
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004

 Debian. (google is your friend, comunque... è tutto documentato)
Uhm, sì, leggo che "A Debian goal is to provide a consistent upgrade path
and a secure upgrade process"... quindi la Debian risolve i problemi di
cui parlavo con un ottimo sistema di gestione e aggiornamento dei
pacchetti e della distribuzione? Non è neanche necessario ricorrere ai
sorgenti, generalmente?
Mi lascia un po' interdetto il fatto di dover usare una distribuzione
"testing", perché se non ho capito male la "stable" è ferma a parecchio
tempo fa...
Grazie.
-- 
Ciao,
  Marco.
..."Close To The Edge", Yes 1972

 parecchio tempo fa...
Attenzione che quello che su Debian si intende con "testing" e
"unstable" non corrisponde all'idea generale che ne hanno altre
distribuzioni... Diciamo che il discorso è legato non solo alla
"stabilità" dei pacchetti ma anche al numero di aggiornamenti
disponibili... in breve, per quel che posso capirne io, la stable è una
distro con pacchetti ultratestati che vengono aggiornati solo molto
raramente, o per ragioni di sicurezza. Ciò significa che va bene se vuoi
fare una macchina in cui, quando lanci l'upgrade, ti suggerisca
automaticamente solo i pacchetti che è davvero indispensabile
aggiornare. La unstable è esattamente l'opposto, va bene per una
macchina su cui vuoi avere sempre l'ultima release disponibile di ogni
pacchetto. Ovviamente ogni giorno ci sono molti upgrade disponibili, e
questo su un server può essere problematico. Personalmente io che amo
vivere pericolosamente uso la testing sui server, che ha anche un
bellissimo net installer, che è una via di mezzo ed ha un kernel recente
e non ha problemi con le periferiche non troppo standard (schede a 1GB,
controller particolari ecc.). Per macchine chiave o per stare piu
tranquilli, invece, la stable è un'ottima scelta anche se ovvimente devi
utilizzare un tipo di sistema piu datato e hai una scelta di pacchetti
piu limitata. 
saluti
ale

 piu limitata. 
Infatti è questo che mi lascia interdetto: "Note that 'testing' does not
get the timely security updates from the security team".
In sostanza sembra che la scelta da fare sia la seguente:
Vuoi una macchina sicura? Usa la stable.
Vuoi una macchina aggiornata? Usa la testing.
Ma se uno vuole una macchina sicura E aggiornata?
Per esempio, io con questo aggiornamento del server vorrei passare da
Samba 2.x a 3.x, e quindi dovrei usare la testing. Però non mi piace molto
l'idea che la testing non garantisca la disponibilità rapida di fix per
eventuali problemi di sicurezza...
Per lo meno, questo è quanto scritto sul sito. Poi, nella realtà, può
anche darsi che gli aggiornamenti per la sicurezza vengano pubblicati
quasi istantaneamente la maggior parte delle volte... Voi che già la
usate, cosa potete dirmi al riguardo?
-- 
Ciao,
  Marco.
..."Red", King Crimson 1974

 
diciamo che avere un sistema sempre aggiornato e sicuro è impossibile,
perché richiederebbe un lavoro enorme ed istantaneo da parte dei
rilasciatori dei pacchetti di sicurezza. non si puo infatti pensare che
un pacchetto appena rilasciato sia anche sicuro. solo il software maturo
ha dei criteri di sicurezza legati ad una sua "storia" di buchi e patch.
cmq esiste un servizio di aggiornamento security anche per le
non-stable, anche se ovviamente non sono seguite come la stable.
personalmente, sui server che utilizzo, la sicurezza è un topic che
prende il 50% circa dell'importanza, e la testing, su sistemi non
sottoposti ad attacchi seri e discretamente firewallata, mi fa stare
relativamente tranquillo. Non credo che le altre release facciano di
meglio, anzi... questa distinzione netta sta tutta dalla parte della
grande serietà dei rilasci debian. 
Certo, se dovessi fare una macchina che ritenessi MOLTO critica, userei
la stable, anche perche su una macchina del genere i servizi sarebbero
ridotti all'osso.
ciao
ale

 usate, cosa potete dirmi al riguardo?
che forse puoi valutare la via di mezzo: avere stable e usare i backports
solo per quello che ti serve.
Ammesso e non concesso che in backports ci sia tutto quello che ti serve...
-- 
cat: .signature: No such file or directory

 sottoposti ad attacchi seri e discretamente firewallata, mi fa stare
Be' sě in effetti anche nel mio caso non si tratta di una macchina
critica, come dicevo. Perň preferirei non trascurarla troppo, e in base
alle FAQ di Debian invece si direbbe che la sicurezza della testing sia
totalmente ignorata ("Q: How is security handled for testing and unstable?
A: The short answer is: it's not.").
Tuttavia, SE (questo me lo potete dire voi) l'esperienza indica che
comunque, quando viene scoperto un bug in un programma, e di conseguenza
viene pubblicata una nuova versione dagli sviluppatori, il relativo
pacchetto Debian per la testing appare entro un paio di settimane o giů di
lě, ci si puň stare.
La cosa che mi preoccupa č che, in base a quella FAQ, il nuovo pacchetto
per la testing potrebbe anche non essere mai pubblicato. Ma mi sembra
strano. Dico bene?
Grazie a tutti per le preziose indicazioni.
-- 
Ciao,
  Marco.
..."Relayer", Yes 1974

 sembra strano. Dico bene?
Mai e` una parola grossa. Mal che vada prima o poi testing diventa stable
e quindi l'aggiornamento lo trovi li`.
Certo che puo` succedere che nessuno segnali il bug o che il pacchettatore
non lo venga a sapere o che la nuova versione corregga un bug ma ne
introduca altri, ecc. ecc.
Bye.

 Grazie a tutti per le preziose indicazioni.
prego, tanto la decisione e la responsabilità sono tue! ;)
-- 
Franco (togli TOGLIMI se vuoi rispondermi)
"Certo bisogna farne di strada / da una ginnastica d'obbedienza /
fino ad un gesto molto più umano / che ti dia il senso della violenza /
però bisogna farne altrettanta / per diventare così coglioni / da non
riuscire più a capire / che non ci sono poteri buoni"       F. De André

 Ma se uno vuole una macchina sicura E aggiornata?
E` una contraddizione in termini.
Se ci pensi, e` facile rispondersi sul perche`.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Debian GNU/Linux: because size DOES matter.

 rilasciatori dei pacchetti di sicurezza. 
Non e` un problema di "enormita`" del lavoro.
E` un problema di tempo, e di "ampia base installata di prova, nel tempo".


 stable + backports.
Gusti. Io sono della famiglia "quello che non c'e` non si rompe", e "if
work, don't fix it".
Certo, se i backport "davvero necessari" sono la meta del sistema, tanto
vale... ma se sono la meta del sistema, IMHO, non si ha vita lunga come
sysadmin, o le esigenze sono fallaci/mal calibrate/si e` schiavi da
developer che non sanno fare il loro lavoro.


 developer che non sanno fare il loro lavoro.
Concordo appieno con Maurizio.
E aggiungo che č inutile fare discorsi filosofici che lasciano il tempo che
trovano.
La debian la si apprezza quando la si conosce usandola.
Non quando si legge qualcosa su internet o sul sito ufficiale.
Amministro diverse macchine e le uniche cose che non uso da stable sono
alcuni demoni esposti e aperti.
Ad esempio apache + php che mi ricompilo e "pitono" a mio uso e consumo.
Problemi ? Nessuno.
Massimo

 schiavi da developer che non sanno fare il loro lavoro.
hai letto che parlavo di "90%"?


 hai letto che parlavo di "90%"?
Ho letto. Tu forse, non completamente. La mia posizione (opinione,
preferenza), sul perche` testing non e` preferibile ai backport e` che
se sono pochi, non vale la pena di avere tanta roba potenzialmente (o
futuribilmente) broken/brokeable, perche` lo scopo di testing, non e`
"una stable piu` aggiornata" ma "prepariamo la prossima stable".
Se i pacchetti backport sono tanti che ti senti di dire "vabbe,
unofficial, per unofficial, meglio gli official di testing" allora,
rivedi quanto lasciato quotato.
Che poi testing, nella maggior parte della sua vita, vada benissimo, ne
sono certo <g> e contento. Che sia "un buon consiglio", molto meno.
PS:
La dialettica "server di importanza A, server di importanza B..." ecc.
mi pare poco utile alla discussione. Quello che e` una considerazione
d'uso personale, non trova un necessario corrispettivo in quello che fa
debian. Non mi risulta che ci sia stable, stable-quasi,
stable-trannemail, testing, testing-hard...
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Life would be so much easier if we could just look at the source code.

 Se ci pensi, e` facile rispondersi sul perche`.
Vabbe' dai, sii buono. ;)
Naturalmente intendevo qualcosa tipo "aggiornata e dotata di tappi per
tutte le falle di sicurezza note fino a quel momento".
Poi è ovvio che niente è mai sicuro al 100% (e già mi vedo qualcuno
controbattere anche a questo, ma su, passatemela O:-)).


 vale... ma se sono la meta del sistema, IMHO, non si ha vita lunga come
Ho capito solo dopo aver letto i tuoi messaggi seguenti che intendevi
"metà" invece di "meta"... giusto? :)
No, in effetti pensandoci è veramente poca roba, e anche cose abbastanza
importanti (tipo Samba), che suppongo saranno sempre disponibili in breve
tempo in caso fosse necessario.
Quindi ora tendo a stable+backports (peccato che io abbia appena finito di
masterizzare i due DVD della testing :-P), ma mi rimane un dubbio che sto
per esprimere nella risposta a Franco...
-- 
Ciao,
  Marco.
..."Crac!", Area 1975

 per oggettivi problemi di pacchettizzazione o di dipendenze o, più
Ecco, anche se tu stavi parlando di testing, questa è la cosa che più mi
preoccupa di stable+backports: l'impossibilità (o notevole difficoltà) di
aggiornare o installare qualcosa a causa di dipendenze e simili.
Proprio pochi giorni fa volevo provare Zope e Plone sulla Mandrake 9.0...
alla fine ho lasciato perdere. Anche scaricando i sorgenti di vecchie
versioni, non sono riuscito a trovare una combinazione funzionante, fra
versioni di Plone, di Zope, di Python, di glibc...
Sulla Debian testing non credo avrei avuto problemi, ma sulla stable?
Dovrò scaricarla e provare.
-- 
Ciao,
  Marco.
..."This Land", Bill Frisell 1994

 aggiornare o installare qualcosa a causa di dipendenze e simili.
Quello che trovi in backports è compilato per stable, quindi ha le
dipendenze all'interno di stable; quando questo non è possibile (perchè
si appoggia librerie che stable non ha, per esempio) se le tira dietro da
solo.
Per assurdo, è più probabile che ci siano problemi di dipendenze in
testing che non in backports...
Hola.


 testing che non in backports...
/me masterizza i 7 CD di Debian Stable.
Già che ci sono ringrazio per i suggerimenti anche le persone alle quali
non ho risposto, come Thorin e Alessandro (al quale va anche un "ben
ritrovato" ;)).
-- 
Ciao,
  Marco.
..."Homogenic", Björk 1997

 /me masterizza i 7 CD di Debian Stable.
Se posso darti un consiglio finale (e se non e` troppo tardi) conviene 
che ti scarichi una mini-iso di installazione via rete ed il resto del 
sistema lo installi (appunto) via Internet:
http://www.debian.org/CD/netinst/
-- 
Vincenzo

 che ti scarichi una mini-iso di installazione via rete ed il resto del 
Grazie ma č troppo tardi, sta per finire il settimo CD. :)
Comunque per iniziare a conoscerla un po' preferisco avere tutto a
disposizione, no problem. Mi dispiace solo che non esista ancora il DVD
della stable.
-- 
Ciao,
  Marco.
..."Grace", Jeff Buckley 1994

 della stable.
Volendo ci sono le immagini jigdo in beta, ma della 3.0r0, da aggiornare
poi via rete alla r2.
Bye.

 Volendo ci sono le immagini jigdo in beta, ma della 3.0r0, da aggiornare
Dove sono?
E... riguardo alla data di pubblicazione della prossima stable: se non ho
capito male le news che ho trovato in giro, si parla del 2005, giusto?
-- 
Ciao,
  Marco.
..."A Passion Play", Jethro Tull 1973

 ho capito male le news che ho trovato in giro, si parla del 2005, giusto?
Sembra di si`, ma io spero che accelerino un po'... :/
Bye.

 Sembra di si`, ma io spero che accelerino un po'... :/
Si vocifera anche che ci si possa arrivare per settembre/ottobre, ma come
sempre con debian, faranno uscire solo quando son convinti che tutto sia
ok, il che potrebbe voler dire una data a caso nei prossimo 12 mesi...
