Newsgroup: it.comp.os.linux.sys
Titolo: squirrelmail

allora, dopo aver risolto i problemi con courier-imap ho di lasciare
openwebmail a favore di squirrelmail, perché quest'ultima supporta
l'accesso al server imap e non la lettura diretta dei file.
Sembra funzionare tutto, ma non riesco a farlo andare in italiano. Ho
impostato la lingua nelle opzioni, ma rimane in inglese, come se
ricadesse su un default non trovando la lingua.
Per averlo in italiano devo installare qualcosa oltre al deb?

 ricadesse su un default non trovando la lingua.
stai usando la nuova 1.5, vero?
capita anche a me... con le versioni precedenti
funzionava invece. ho cercato un po' in giro senza trovare nulla...
attendo fiducioso la prox versione.
se trovi qualcosa fa un fischio :o)
ciao
Rob



mancano i file di internazionalizzazione, ma il ho visti nel cvs. adesos
provo a scaricarli.

 Per averlo in italiano devo installare qualcosa oltre al deb?
Non uso squirrel, ma sei sicuro di _avere_ il supporto alla lingua
italiana?
Perche` in woody_R0 c'era un baco nel pacchetto locales (ignorava la
selezione e non compilava i locales). Ora, anche installando il
pacchetto nuovo, o meglio, aggiornando, a volte ho visto macchine che
subivano questo baco (nell'upgrade io avrei forzato il reconfigure, ma
tant'e`).
Morale:
fatti un giro di dpkg-reconfigure -plow locales e verifica di aver
compilato le lingue che ti interessano (da parte mia en_US, e it_IT nei
due flavor).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
In the long run every program becomes rococo - then rubble.

 tant'e`).
sě sě, il baco del locale lo conosco eccome.
No, c'č unamezza chifezza nella squirrelmail, cioč non vengon inclusi i
file .po di internazionalizzazione. Li ho presi dal cvs, compilati e la
webmail č andata in italiano.
insomma, bruttina come cosa. Perň poi funziona perfettamente.

 webmail è andata in italiano.
ma usi sarge/sid o woody?? Nel server mio personale, (quello a praga) ho
woody e squirrelmail, di lingue ne ho a valanga e tutte funzionano.
Squirrelmail Version: 1:1.2.6-1.3, quella di default in woody.
ciao
Banana

 Squirrelmail Version: 1:1.2.6-1.3, quella di default in woody.
pyurtroppo sono woody per alcune necessità particolari. La cosa non mi
esalta moltissimo e spero che il rilascio di sarge sia vicino....

 esalta moltissimo e spero che il rilascio di sarge sia vicino....
IMHO e' meglio woody, almeno ci sono i security update.
Il rilascio di sarge comportera l'utilizzo di postfix2 che fino ad ora 
non ho nemmeno guardato... ok, che con apt si puo' fare tutto, ed anche
tenersi postifx alla versione 1, ma preferirei essere allineato
con il ramo stabile di debian... cmq sono solo quisquiglie :-))
CYA
Banana

 ho nemmeno guardato... ok, che con apt si puo' fare tutto, ed anche
Io sto traslando da postfix1 a postfix 2 in questi giorni.
Non ci sono grandi differenze, a parte il fatto che la patch di Kadlecsik
è ora inserita (con qualche modifica marginale) nella versione ufficiale e
che alcune scritture sono cambiate lievemente di sintassi...
Hola...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 con il ramo stabile di debian... cmq sono solo quisquiglie :-))
sai, alla fine ho pochi software aperti: postfix, apache, imap-ssl e forse
ldap-ssl, ma devo ancora decidere. Insomma, poca roba da tenere sotto
controllo.
Per quanto riguarda postfix2 penso che faranno come apache[1,2] e
bind[8,9], fornendo entrambe le versioni.

 che alcune scritture sono cambiate lievemente di sintassi...
sai dirmi con che versione si binda al server ldap? postfix1 usa la 2, io
vorrei usare la 3....

 vorrei usare la 3....
Spiacente, non uso ldap per cui non ci ho badato. Cmq, se smazzando nella
documentazione ci incoccio rispondo qui...


 bind[8,9], fornendo entrambe le versioni.
non sarebbe una idea sbagliata, pero' ad oggi e' presente solo postfix
2, o almeno cosi mi sembra :-)
Banana



accipicchia, lo sai che ci ho dato occhio e che effettivamente ho su
postfix 2.qualcosa? beh, è funzionato tutto come prima.

 controllo.
No, hai poche macchine, che e` diverso.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Company slogan: The Mandatory Beatings Will Continue Until Morale Improves.

 Mi si perdoni il francesismo: sto cazzo, Ottavio.
ma scusa, siamo daccordo che woody sarebbe meglio. Ma su quella macchina
purtroppo ho bisogno di alcuni software più aggiornati per farci girare
delle applicazioni particolari, cui _non_ posso rinunciare.
In più mi deve erogare alcuni servizi pubblici, nello specifico ssh,
smtp, imap-ssl e apache con e senza ssl. Sono poche porte aperte,
seleziono i programmi che mi danno la maggiore sicurezza, ho un sistema di
controllo di accesso ai servizi che ho sviluppato e testato nel corso
degli ultimi mesi e secondo me va bene lo stesso. Apache1 è ben rodato,
postifx2 è sviluppato bene e spero anche l'imap-ssl (sono passato da
uw-imapd a courier proprio perché sembra fornire una maggiore
afifdabilità). Se proprio uscisse il baco non tappato fermerei il
servizio fino all'arrivo del fix, che comunque, proprio perché è testing
non dovrebbe metterci anni ad arrivare.
Cazzo ho 5 porte aperte, tengo sotto controllo quotidianamente la
macchina, cosa altro c'è da fare? Tenerla spenta?
Hai ragione quando dici che woody è meglio, che hai i fix e che il lavoro
di manutenzione è minore, anch'io ceco di tenere il maggior numero
di macchine allineat con la stable, però se ti trovi davanti ad una
scelta binaria o così o niente cosa fai? Non voglio usare i backport su
un server, che per esperienza funzionicchiano, ma non sono affidabili e
tendono a diventare rapidamente obsoleti, magari ancora con bachi aperti.

 non dovrebbe metterci anni ad arrivare.
Scusa se mi inserisco, ma il tuo discorso mi pare un po' troppo legato ai
servizi pubblici, e perdi un po' di vista il fatto che la macchina non è
attaccabile solo in conseguenza di una vulnerabilità di quelli..
Ci sono anche tutte le librerie sulle quali quei servizi si appoggiano,
che sono molto più difficili da mantenere monitorate, oppure i programmi
esterni da loro richiamati ecc...
Proprio per esigenze come la tua esiste backports.org... Avere sw recente
ma mantenendo le dipendenze verso la woody stable...
'ao...


 ma mantenendo le dipendenze verso la woody stable...
permettimi di farti notare che quando fai un backport di programmi e/o
librerie ti porti dietro tutti gli stessi problemi delle librerie di
testing, solo che hai mezze dipendenze da una parte e mezze dall'altra.
A me sembra solo un gran casino....

 testing, solo che hai mezze dipendenze da una parte e mezze dall'altra.
No...
Sono package realizzati mantenendo le dipendenze dalle librerie di stable
e si portano dietro le librerie nuove solo ed esclusivamente se non è
possibile farne a meno. E il disclaimer di 
backports.org
 lo dice chiaro e
tondo:
Backports are recompiled packages from testing (mostly) and unstable (in a
few cases only, e.g. security updates), so they will run without new
libraries (wherever it is possible) on a stable Debian distribution.
Che non mi pare proprio la stessa roba di "tantovale mettere testing"...


         (0x400d7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
tipico esempio di pam e formattazione di melma...


 tendono a diventare rapidamente obsoleti, magari ancora con bachi aperti.
In quei rari casi, i backport li faccio io e li seguo.
Per ora, cmq, sono sempre riuscito a non usare backport (se non per
tempi molto brevi), e a non mettere testing/unstable su un server.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
For every complex problem, there is an answer that is short, simple and wrong.

 brevi), e a non mettere testing/unstable su un server.
fortunato. ma per esempio una volta a me è stato chiesto di mettere su
macchine con zope e prodotti specifici, che girano con solo con
l'ultimissimo python e un mare di librerie astruse. Ricompilare il python
di debian non è un giochino banale, per esempio..... Se ci metti anche
altre librerie diventi cretino e la manutenzione si complica terribilmente.
per il resto comunque siamo concordi.

 di una testing, da questo punto di vista...
ok, allora (ma non è il mio caso) prendi e fa girare l'ultima versione di
zope su una woody senza ritrovarti quasi di fatto una testing.
e cosa fai se esce un baco su un pacchetto di cui usi il backport e che
quindi ha una versione più evoluta di quella che butta fuori security?

 quindi ha una versione più evoluta di quella che butta fuori security?
Accade che, avendo configurato sources.list per usare i package di
backports, avrai tutto aggiornato alla security tranne quello che arriva
dai repository di backports. Almeno fino a che non esce l'aggiornamento su
backports.
Ma se esce una vulnerabilità su openssl sfruttabile da apache, e il
backport usa openssl come so, sei già col culo parato da security :-D
Sia chiaro, non c'è polemica, ma è solo per dire che non è proprio "la
stessa cosa"...
Se backports esiste (e se i maintainer dei singoli package sono di solito
gli stessi di stable) un motivo c'è...
Ciao e buon lavoro 
PS: per la cronaca, uso anche io alcune macchine testing in produzione, ma
preferisco non averle mai esposte al pubblico ludibrio... ;-)


 per il resto comunque siamo concordi.
Ma si. Non mi preoccupo di te, ma di chi, leggendo, magari traeva
conclusioni affrettate/errate. Gli upload sono _diversi_ da i security.
Enormemente.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Windows, another fine product from the folks who gave us edlin.

 soci, incide).
ma se $librerie ti servono per far girare $programmi che servono per la
tua tesi di laurea ti fai condizionare, eccome :-)

 La differenza e` una macchina sfondata oppure no.
<cut>
Perdonate se mi intrometto nel bel mezzo del discorso; 
un piccola riflessione personale.
Inanzitutto sono d'accordo con Maurizio: la scelta nell'uso di software
del ramo testing, piuttosto che stable, non è vincolato tanto dalle
maggiori features che mi da, ma piu' che altro dalla possibilità di
mantenerlo monitorato ad aggiornato costantemente...
La domanda da farsi, è: mi conviene espormi a dei rischi per avere
i vantaggi che sto cercando 
Ho una macchina o forse due: faccio anche a meno di testing.
Scarico i sorgenti e li ricompilo; 
considerazione opinabile, lo so' ma è tanto per capirci. 
Quando inizi ad avere una montagna di macchine da seguire
la cosa si complica è rischia di diventare ingestibile e
pericolosa.
Ho visto macchine bucate, solo perchè gli amministratori non avevano
piu' tempo a disposizione per gestire gli aggiornamenti dei software:
ridicolo, ma purtroppo verità. 
Credo che l'idea del pacchetto precompilato (.deb o .rpm che sia) nasca
fondamentalmente per dare una gestione probabilmente meno curata o se
preferiamo adattata, ma decisamentre piu sicura e veloce.
Tuttavia voglio sollevare una contradizione (forse una delle uniche) che
invita a pensare un po tutti. In special modo chi utilizza Woody
come distro di produzione (io compreso)
Per chi ricorderà, l'estate trascorsa, venno scoperto un bug in
Postfix (non ricordo perfettamente i dettagli).
Lasciamo stare il fatto in se, direi anche dell'tutto accettabile dato il
numero di bug generalmente scoperti in Postfix: pochissimi; 
(se non erro erano 2 anni che non se ne vedeva uno) 
Si trattava comunque di problemi legati alla versione `1` di postfix,
mentre era già stata rilasciata da tempo la `2`.
Pochi giorni dopo su BUGTRAQ appare un messaggio di `Wietse`,
che IMHO non fa una piega ed ecco che si eleva la contraddizione: 
crediamo di utilizzare del software piu' sicuro, solo perchè piu' vecchio
e di conseguenza piu' rodato; di fatto pero' non è sempre vero.
Per chi non avesse letto il messaggio lo ripropongo qui sotto. 
Ciao Clust
### 
Subject: Postfix: old bugs keep coming back
Bugs happen. Perhaps more unusual is that the two problems reported
today by Michal Zalewski were fixed nine or more months ago and
that the fixed code has been publically available all that time.
 
Number one was fixed as the accidental side effect of a code reorg.
Number two was fixed by an explicit bugfix (not thought to be
security related at the time).  Unfortunately, number two did not
feature in Michal's draft advisory that I worked off last week;
I'd happily have fixed some technical inaccuracies in his text.
 
This episode is a reminder that bugs don't necessarily go away even
when they are fixed.  Once the source code goes out the door you
no longer control what happens with it. The result is that people
can discover old fixed bugs in "brand-new" software.
 
This phenomenon is far from new. As someone told me in private
email, Robert Morris Sr. lamented that he personally had fixed some
of the security bugs in the UNIX utilities back in the late '70's,
but they were still being exploited almost 20 years later.
 
       Wietse
###
 

 I'd happily have fixed some technical inaccuracies in his text.
Eh.
La scelta di debian, e non solo di debian, praticamente tutte le
maggiori distribuzioni utilizzavano in quel momento, quella versione del
software, si veda:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0468
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0540
non il problema.
Hai corretto un baco "involontariamente". Un'altro l'hai corretto ma
nessuno ha detto che era un security related. L'avessero fatto, il
pacchetto sarebbe stato aggiornato allora.
Stimo Wietse come una divinita`, ma anche lui dice delle fesserie. In
questo caso, IMHO, lo fa.
Se invece guardi i changelog di postfix, noti come giustamente, molte
releaese cambiano, aggiustano, modificano anche radicalmente il
software. Questo e` "inaccettabile" in un ambiente di produzione, per
cui c'e` poco da dire. Non e` credibile ne pensabile dire a XX utenti:
"la vostra posta oggi non funziona, ma vedrete che domani ci sara` un
bugfix".
Infine le sue lamentele sono fuori luogo: due bug di security, sono
stati corretti uno per caso, l'altro senza dare informazione. Dovessi
puntare il dito verso un "colpevole", non sceglierei le distribuzioni.
Infine: software bugfree non esiste. Pero` che questo venga utilizzato
come modo per complicarsi la vita, in un ambiente dove e` _fondamentale_
il funzionamento e le poche (nulle) sorprese, mi sembra poco furbo.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Each snowflake is different, collect the entire set.

 il funzionamento e le poche (nulle) sorprese, mi sembra poco furbo.
Condivido a pieno le tue riflessioni e sono contento di ribadire che,
anch'io come te e tante altre persone, ho fatto una scelta ben precisa:
utilizzo la versione in WOODY, e rimango in ascolto per la prossima
release di Debian.
Una filosofia che mi piace, soprattutto se l'attuale release mi fornisce
tutto cio' di cui ho bisogno.
Altrimenti... 
./configure
make && make install
 
il tutto condito da occhi sempre puntati su mailling-list e log file :)
Piccola avventura conclusiva che si riallaccia al discorso fatto fin qui!
Titolo: ...a volte la fortuna... !
Circa un mese fa, mi sono rivolto proprio qui per un problema con Postfix
e latenze mostruose del sistema di cleanup, nel controllo di messaggi con
allegati. Piu' che altro, la spedizione dei messaggi era eterna.
Se ricordi una mano mi venne data proprio da te :o)
Dopo mille ricerche, vengo a scoprire che postfix non centra nulla 
(ma chi aveva dubbi)! 
Il kernel `bf24` non supporta nativamente le schede
di rete con chipset 8139 "D", risultato:
una LAN (da 100 Mbs teorici) va a 10 arghhhh !
Scarico un Kernel aggiornato (2.4.23), ricompilo, e finalmente ottengo
delle prestazioni decenti.
Fatalità vuole che pochi giorni dopo... alcuni server Debian
vengono compromessi (per fortuna senza pericoli per le repository), e
dopo ulteriori ricerche si scopre una falla nei Kernel Linux sino
alla vers. 2.4.22.
Ma guarda te che fortuna: avevo proprio upgradata alla 2.4.23  ;)
Notte *Clust*