Newsgroup: it.comp.os.linux.sys
Titolo: affiancamento di un server di posta...

Situazione: un server di posta più o meno tradizionale (serve qualche 
centinaio di utenti, SMTP+IMAP+POP3+LDAP+antivirus) linux based su cui 
bisogna fare un po' di lavoretti di aggiornamenti software, 
installazioni, ecc.
Vorrei cercare di farlo senza causare eccessive interruzioni di 
servizio, e mi sembra che l'unica sia usare un serveruccio temporaneo e 
fare il gioco dei tre barattoli all'insaputa (o quasi) degli utenti.
Peccato che cominciando a fare un po' di pianificazioni mi rendo conto 
che la cosa non è proprio banale: al di là delle configurazioni software 
che sono facili da replicare, allineare le mailbox può presentare 
qualche grana (perdere messaggi non è un'opzione, ovviamente).
Qualche suggerimento per la strategia da seguire?
-- 
Fabrizio "Hermooz" Ermini

 Vorrei cercare di farlo senza causare eccessive interruzioni di 
Lo fai durante i week-end o di notte quando gli utenti non usano troppo
la mail, se il server e' off-line la posta viente tenuta in coda e
nessuno se ne accorge.
1. sii rapido
2. sii silenzioso
3. non fare cazzate.
Davide
-- 
Gates' Law: Every 18 months, the speed of software halves. 
   -- From a Slashdot.org post

 3. non fare cazzate.
...e fin qui non ci piove :-)
Solo che vorrei cercare invece di fare le cose con calma e non 
compromettere il mio tempo libero (non sono in missione per conto di 
Dio, sono solo uno smanettone prezzolato :-))
E poi la cosa ha anche uno scopo secondario: alla fine del giro, il 
serverino usato come "swap" dovrebbe rimanere come possibile muletto da 
rimettere su al volo in caso di guasto della macchina principale. In 
quel caso ovviamente non si può pretendere di garantire una continuità 
di servizio, ma mi basterebbe consentire alcune funzionalità di base 
(tipo l'SMTP e la webmail, insomma).
-- 
Fabrizio "Hermooz" Ermini

 Dio, sono solo uno smanettone prezzolato :-))
Una via ci sarebbe, se per te risulta applicabile:
portare preventivamente lo spool della posta in un mountpoint NFS.
Questo ti consente di lavorare su una macchina parallela accedendo allo 
stesso identico spool. Quando la macchina nuova č adeguatamente testata, 
cambi solo l'ip e la metti al posto della vecchia.
Nel caso, sospendi il servizio per il tempo necessario a spostare lo 
spool da NFS e riportarlo in una partizione locale...
-- 
cat: .signature: No such file or directory

 spool da NFS e riportarlo in una partizione locale...
Hm. Non avevo mai considerato di usare NFS per una spool dir; ora che mi 
ci hai fatto pensare, ci ho messo mente locale e in effetti NORMALMENTE 
non mi parrebbe una buona idea, ma per fare un giochino del genere può 
essere un toccasana :-)
Ora ci rimugino un po' e vedo come organizzare la cosa...
bye!
-- 
Fabrizio "Hermooz" Ermini

 essere un toccasana :-)
Ho più server ridondati che usano in parallelo lo stesso spool via NFS, 
per circa 50GB di spool. Perchè non sarebbe una buona idea?


 essere un toccasana :-)
Non vedo proprio perche' **NORMALMENTE** non sarebbe una buona idea...
Quando hai tante E-Mail e tanti Server che le beccano, e' l'unica via
percorribile!
Noi abbiamo ben 6 MailStores (e ne verranno aggiunti altri 4 per
completare la ridondanza [aka: le E-Mail vengono salvate su due server,
cosi' se uno passa a miglior vita, c'e' l'altro]).
E' l'unico modo per far si che i 3 MailServer e i 6 PopServer riescano a
vedere le E-Mail!
Nel tuo caso (sicuramente hai MOLTO meno domini del nostro sistema!), puoi
anche fare cosi':
1) Installi DRBD su entrambe le macchine
2) Installi HeartBeat su entrambe le macchine
3) Fai in modo che le E-Mail vengano salvate sulla partizione DRBD
4) Metti in funzione la seconda macchina
5) Appena spegni la prima, Heartbeat capisce la cosa, monta la partizione
DRBD e avvia i vari demoni (Sendmail/postfix, etc), e prende l'IP del
sistema di E-Mail (ovvio! Entrambe le macchine hanno un IP, e c'e' poi un
IP "virtuale" che e' quello del MailServer e che verra' usato a RunTime
dalla macchina che **IN QUEL MOMENTO** e' primary)
Da quel momento in poi, le E-Mail verranno salvate sul secondo Server.
Quando riaccenderai il primo la partizione DRBD verra' sincronizzata (e
mantenuta sincrona ad ogni cambiamento).
A quel punto, hai un sistema ridondante di MailServer (e non solo E-Mail,
se vuoi!). Quando un Server, per un motivo o per l'altro, va giu', l'altro
"sale su" (scusa il gioco di parole).
Sembra complicato, ma in realta' e' decisamente veloce da mettere in piedi!
Noi lo usiamo per gestire i due Server "MailOut", ossia quelli che
spediscono le E-Mail dei nostri clienti in giro per il mondo. La coda di
Postfix e' sul disco DRBD e quando uno dei Server si schianta, l'altro
prende la palla e nemmeno un'E-Mail della coda viene persa!
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 prende la palla e nemmeno un'E-Mail della coda viene persa!
Questa mi interessa.
O, meglio, mi interesserebbe applicata al discorso mailstore.
Volevo provarla, ma la prospettiva "prestazioni in I/O" mi inquieta un 
poco. Mi racconti un po' la tua esperienza in merito, plis?


 
Mi spiego meglio, ovviamente in tre righe non era comprensibile quello 
che intendevo: un setting con maildrop comune e più server che fanno da 
front-end presuppone le seguenti cose, correggimi se sbaglio:
- L'affidabilità del sistema che da da maildrop (storage) deve essere 
almeno indicativamente superiore a quelle dei server front end 
(altrimenti si peggiora l'affidabilità complessiva, introducendo un PoF 
aggiuntivo)
- Il sistema in questione deve essere opportunamente protetto (dato che 
NFS non è il massimo in termini di sicurezza) e quindi in genere sta in 
una zone a lui dedicata
Il MIO setting è basato su un singolo server la cui affidabilità è quel 
che è (alimentazione ridondata e RAID 5 sono gli unici lussi), ma le 
macchine che ho a disposizione per usare come maildrop sono anche 
peggio, con l'unica notabile eccezione del DBMS server, che pero' è bene 
lasciarlo continuare a fare il suo lavoro senza rompergli troppo i 
coglioni ;-)
Quindi la mia considerazione sottintendeva che normalmente non ho 
granchè da guadagnare ad esportare il maildrop su un'altro server, e 
anzi forse qualcosa da perdere in termini di affidabilità. Ma per un 
passaggio temporaneo è ovviamente un altro discorso.
Bye!
-- 
Fabrizio "Hermooz" Ermini

 percorribile!
Vedi risposta a Skull. In realtà sono pienamente d'accordo (e non vedo 
come non esserlo ;-)), il mio commento era relativo a setup 
completamente diversi.
Cmq grazie per il commento, ogni esperienza in più in tal senso è sempre 
ben accetta (quando riusciremo a convincere i clienti a spendere qualche 
lira in più per i loro sistemi... torneranno utili :-))



QUale aggiornamenti devi fare? Un cambio radicale di sistema o solo upgrade?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.

 
abbastanza radicale: da RH 7.3 a SUSE SLES. Per questo stimo che mi ci 
vorrà un po'...