Newsgroup: it.comp.os.linux.sys
Titolo: Spamassassin high availability

Leggevo qui:
http://wiki.apache.org/spamassassin/BayesBitMe
che in una configurazione con MX multipli, lo spamassassin presente
sul MX con priorità più alta potrebbe ricevere più spam rispetto agli
altri, di conseguenza i baiesiani potrebbero essere sbilanciati ed
essere più aggressivi.
Una soluzione, secondo loro, è quella di sincronizzare i filtri
tramite procedure automatizzate, dal server MX con priorità inferiore
verso quello con priorità maggiore, oppure usare filtri baiesiani via
SQL con replica.
Il discorso fila.
MA:
usando MX con pari priorità, il server listato per secondo nei dns
*potrebbe* (potrebbe) ricevere più spam rispetto agli altri perchè gli
spammer lo scelgono volutamente (sperando di trovare un server meno
protetto) ma anche le mail legittime potrebbero transitare in quantità
maggiore rispetto ad una soluzione con parità differente. In questi
casi, come si potrebbe fare il merge dei baiesiani senza rischiare uno
sbilanciamento?
In una soluzione ad MX multipli con spamassassin multipli, come si può
gestire la sincronia dei baiesiani in maniera efficiente e sicura?

 protetto) 
non rispondo direttamente alla tua domanda su spamassassin, però ti 
faccio notare che in questo caso si utilizza un solo record MX a cui si 
associano 2 record A con indirizzi IP differenti; automaticamente 
verranno risolti in round robin (con possibilità di scalare): in questo 
modo è il DNS che "indirizza" le richieste tra i mailserver di pari 
peso, visto che un:
dig -t mx dominio.tld
ritornerà sempre e solo mail.dominio.tld
Ciao,
Manuel

 ritornerà sempre e solo mail.dominio.tld
Mmmm
Non vedo cosa cambi tra due MX di pari priorità o un mono-MX in round
robin...
il problema è lo stesso. Si rischia che i bayesiani siano sbilanciati
in base
allo spam ricevuto dai due server...
E la sfiga vuole che il primo server riceva solo mail buone ed il
secondo solo spam.
Tipo:
mail1 legittima => server1
mail2 spam => server2
mail3 legittiama => server1
mail4 spam => server2
Sono bilanciati, quindi fanno 'un po per uno' e la sfiga è sempre in
agguato.
Nella situazione di cui sopra (estremizzata solo per far capire di
cosa sto parlando) il server2
bloccherebbe il 99% delle mail perchè secondo lui ha ricevuto sempre
mail e le probabilità sono 99% spam e 1% ham
il primo, invece farebbe l'opposto, 99% buona, 1% spam...
Tra l'altro, guarda yahoo, ha MX di pari priorità
;; ANSWER SECTION:
yahoo.com
.		3722	IN	MX	1 
a.mx.mail.yahoo.com
.
yahoo.com
.		3722	IN	MX	1 
b.mx.mail.yahoo.com
.
yahoo.com
.		3722	IN	MX	1 
c.mx.mail.yahoo.com
.
yahoo.com
.		3722	IN	MX	1 
d.mx.mail.yahoo.com
.
yahoo.com
.		3722	IN	MX	1 
e.mx.mail.yahoo.com
.
yahoo.com
.		3722	IN	MX	1 
f.mx.mail.yahoo.com
.
yahoo.com
.		3722	IN	MX	1 
g.mx.mail.yahoo.com
.

 Il discorso fila.
Magari faccio un'osservazione scema, ma spamd non usa un socket tcp? 
Potresti far girare spamd su uno dei due server e interrogarlo anche 
dall'altro. Oppure usare un SQL active/active.

 gestire la sincronia dei baiesiani in maniera efficiente e sicura?
Mettendo i Bayes in un DB al quale accedono entrambi gli SpamAssassin...
Posso comunque far notare che, per gestire un Cluster HA ci sono soluzioni
un tantinello piu' indicate del doppio MX?
Tanto per dirne una: HeartBeat!
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

 gestire la sincronia dei baiesiani in maniera efficiente e sicura?
Non usando i bayes che nel 2008 rappresentano solo CPU sprecata.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 Non usando i bayes che nel 2008 rappresentano solo CPU sprecata.
Scusate se mi allaccio qui per una domanda.
Ho disattivato anche io da ormai un annetto i bayesiani, soprattutto 
perche` amministro un server che riceve normali mail in una ventina di 
lingue diverse, quindi il rischio di falsi positivi era troppo alto.
Ora ho disattivato anche le DNSBL perche` alcuni server sono stati chiusi 
e ho rischiato di perdere posta.
Sono rimasto col solo greylisting, che fa un discreto lavoro, ma gli 
spammer si stanno attrezzando, e le truffe bancarie/paypal passano che e` 
un piacere.
Voi cosa usate?
Grazie.

 Voi cosa usate?
Metti anche SPF! E riattiva le DNSBL (usando qualche Server buono). E
mettici un buon antivirus! :)


 le truffe bancarie/paypal passano che e` un piacere.
Clamav un po' di phishing lo becca, ad esempio.

 spammer lo scelgono volutamente (sperando di trovare un server meno
Hai degli esempi? Anche i MX a pari priorita' vengono generalmente
presentati in round robin, quindi non ha senso parlare di "listato
prima" e "listato dopo". Non ci dovrebbe essere nessuna asimmetria
nella distribuzione del traffico.
Fabio

 Tanto per dirne una: HeartBeat!
Gli MX scalano in maniera pressochè orizzontale semplicemente
aggiungendo record e server.
Usare HeartBeat, è IMHO una inutile complicazione.

 mantenuti in sync tra loro (es. con meccanismi di replica);
Esatto, il mio era una semplificazione.
Anche il graylisting avrebbe lo stesso problema.
finchè i nodi sono due, implementare un MASTER-MASTER per il db non
dovrebbe
essere un problema.
Ma in caso di 3, 4 o più nodi?

 nella distribuzione del traffico.
Nessun esempio.
Mi è venuto il dubbio leggendo quel wiki di cui sopra.
Però posso provare a formulare un esempio qui:
server 1 => MX1
server 2 => MX2
tutti con pari priorità, quindi in round-robin.
Tu mandi una mail legittima, e prendi il primo server.
Tizio manda una mail di spam e prende il secondo server (causa round-
robin)
Caio manda una mail legittima e riprende il primo server
Sempronio manda spam e prende il secondo server.
Il secondo server riceverà solo spam, il primo solo mail legittime.
(è una esemplificazione volutamente estremizzata)
Così facendo eventuali bayesiani si sbilancerebbero in quanto un
server riceverebbe
il grosso dello spam ed uno il grosso delle mail legittime..
Ma anche se così non fosse, il punto sarebbe un altro: come
sincronizzare
graylist, baysiani, filtro XYZ tra 2 o più MX?

 come sincronizzare graylist, baysiani, filtro XYZ tra 2 o più MX?
per spamassassin c'è un'apposito comando per esportare ed importare i 
filtri; per il graylisting dipende da cosa usi, ma alla fine o è un file 
oppure un dump di database.
E' come per i db: se la sorgente dati non è univoca la situazione si fa 
girgia. Quindi un solo db per spamassassin, un solo db per greylisting, 
ecc.. con le dovute precauzioni (deve essere HA altrimenti si ferma 
tutto il tuo sistema di posta)
Anche perchè c'è un'altra questione: come fai a stabilire da quale 
server replicare i dati verso tutti gli altri?
Per spamassassin (ammesso che funzioni) potresti esportare tutti i db 
dai mailserver, importarli ogni notte in uno spamassassin a parte da cui 
ri-esporti il db, ripulisci il db di tutti gli spamassassin sui 
mailserver e ci ficchi dentro il dump ottenuto dal server a parte.
Boh ma vale la pena?
Ciao,
Manuel

 Boh ma vale la pena?
Se devi mettere in piedi più di 2 MX (non è il mio caso) una soluzione
la *devi*
trovare per forza. Ero curioso di sapere quale soluzione adottare e
come
implementarla. A titolo informativo.

 Usare HeartBeat, è IMHO una inutile complicazione.
Guarda, HighAvailability vuol dire: UNO lavora, l'ALTRO si gratta la
pancia finche' il primo non schiatta.
Quello che vuoi fare tu si chiama semmai LoadBalancing. E anche in questo
caso ritengo che esistano soluzioni molto piu' idonee.
Se bastasse veramente mettere piu' MX-Record, pensi veramente che molti
programmatori e anche grosse ditte investirebbero tempo e denaro per
soluzioni Cluster LoadBalancing? :)


 E la greylist in sola lettura non va...
io usavo sqlgrey che rimane in ascolto su porta TCP: i vari mailserver 
ci si collegano ed utilizzano tutti lo stesso db.. quindi almeno per lui 
non ci sono problemi.
Continuo a non capire la questione della sola lettura..
Ciao,
Manuel

 Continuo a non capire la questione della sola lettura..
Supponendo di usare postgrey con tabelle su DB, una replica
tradizionale sarebbe formata
da un server MASTER (rw) e tanti server SLAVE (ro)
Quindi MX1 = MASTER, MX2,3,4,5,N = SLAVE
Quando uno slave riceve una mail, deve poter scrivere nel db, cosa che
non può fare essendo 'slave' (o meglio, nel caso lo facesse, il master
non sarebbe più sincronizzato).
O si fanno repliche multimaster (e non è molto bello in quanto le
complicazioni aumentano all'aumentare del numero di server replicati)
oppure ?!

 amici...
Aggiungo, le greylist si potrebbero anche non sincronizzare tra i vari
MX... Il problema sono i vari filtri antispam.
Però, come suggerito da CtRiX, togliendo i bayes si dovrebbe risolvere
il problema
o meglio, togliendo le varie autowhitelist e l'autolearning dei bayes
si dovrebbe
risolvere il problema in quanto potrei sempre e comunque alimentare i
bayesiani su un
server di appoggio (non connesso ad internet e che quindi non riceve
mail) per
poi importarli in egualmodo su tutti i vari MX.
Così facendo, i bayes sono attivi e sono sempre sincronizzati dato che
li alimento
io per primo...
Quindi due problemi risolti, ma potrebbero esserci altre complicazioni
che non mi vengono in mente?

> amici...
per sqlgrey non devi SINCRONIZZARE nulla: lui ascolta sulla tcp e quindi N MX
mandano le richieste ad un solo server
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
F:	When into a room I plunge, I
	Sometimes find some VIOLET FUNGI.
	Then I linger, darkly brooding
	On the poison they're exuding.
		-- The Roguelet's ABC

> amici...
per sqlgrey non devi ridondare nulla: lui ascolta sulla tcp e quindi N MX 


 Clamav un po' di phishing lo becca, ad esempio.
Si`, clamav ce l'ho gia` installato, mi ero dimenticato di dirlo.
Bye.

 filtraggio DNSBL le hai tolte del tutto così risparmi fatica eh :P ?
Mea culpa! :)
Siamo in un periodo di migrazione di server da una farm a un'altra, e ho 
qualche decina di casini in piedi. Piuttosto che rischiare il blocco delle 
mail ho preferito disattivarli finche` non avro` il tempo materiale di 
darci un'occhiata e selezionare dei server decenti da usare.
E' molto meno grave che arrivi un po' di SPAM in piu`, piuttosto che vada 
perso un paio di messaggi di lavoro. :)
Bye.

 nella distribuzione del traffico.
Del traffico lecito no. Dello spam, sì abbondantemente.
Ragioni molteplici (che non so se sia il caso di eviscerare qui), ma 
fintantochè hai più server su IP separati, è facile trovarsi con lo spam 
che si concentra solo su uno di questi.
Il che non è nemmeno male: se quello dovesse anche esser saturo, i 
mailserver leciti "si spostano" automaticamente sui mailserver ancora 
disponibili. i Bot no.

 non sarebbe piů sincronizzato).
no no una cosa del genere non la prendo nemmeno in considerazione.
Un solo DB con qualche sistema HA č l'unica soluzione che mi viene in mente
Ciao,
Manuel

 di replica (mi viene in mente Oracle)
Oppure mysql
-- 
g4b0, linux user n. 369000
http://gabo.homelinux.com

= 3) lo farei direttamente
in DNS salvo particolari esigenze (traffico fortemente sbilanciato su
un MX in particolare ed in tal caso, tale MX potrebbe 'non reggere')
Ma il discorso di questo thread è un altro... Torniamo IT...

 Oppure mysql
Come, ad esempio?
Io conosco la replica master-master-master-master-.... ad anello, con
ID 'sfasati'.
MySQL1 inserisce con ID1,
MySQL2 inserisce con ID2
e così via. In questo modo i campi auto-increment saranno sempre 'a
posto'.
Esistono repliche differenti su MySQL?

 mandano le richieste ad un solo server
Non è vero:
sqlgrey da qualche parte si salverà il suo database con le triple no?
Quel database, sul primo MX avrà determinati record, sul secondo ne
avrà altri.
Bisogna fare il merge.
Fare come dici te è una soluzione, ma se ti va giù il server con
SQLGrey sei a piedi.
In tal caso: come ridondare SQLgrey? Torniamo punto a capo....

 Un solo DB con qualche sistema HA è l'unica soluzione che mi viene in mente
Io sto cercando di capire quale sia il "qualche sistema HA" del
database.
Preferibilmente evitando una replica multimaster su MySQL che mi fa
rabbrividire...
Eventualmente esportare i database (non mysql) dei vari sqlgrey,
spamassassin etc su un GFS o simili?

 disponibili. i Bot no.
Scusa, ma in che modo 'si spostano' ?
Il roundrobin non gestisce il carico quindi non vedo come faccia a
sapere se
un nodo è carico oppure meno.
A meno che per "si spostano" tu non intedessi uno spostamento
manuale... In tal
caso il mio discorso cade.

 un nodo è carico oppure meno.
Infatti non lo sa. Sa solo che il delivery è fallito e quindi ritenta 
con l'altro MX.
Semplice ed efficace.

 In tal caso: come ridondare SQLgrey? Torniamo punto a capo....
mi riferivo alla sincronizzazione, per la ridondanza 2 server in master/slave
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Baker's First Law of Federal Geometry:
	A block grant is a solid mass of money surrounded on all sides
by governors.

 Semplice ed efficace.
Si, è il mio cervello che ultimamente non è tanto allenato.
:)

 mi riferivo alla sincronizzazione, per la ridondanza 2 server in master/slave
Ma lo slave è in sola lettura.
Se ti va giù il master, le greylist come le aggiorni?
Puoi accedere allo slave ma come ci scrivi?

 Puoi accedere allo slave ma come ci scrivi?
ok.. in ha, in quello che vuoi.. ma  cosě hai dribblato il problema della 
sincronizzazione.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
F u cn rd ths u cnt spl wrth a dm!

 sincronizzazione.
Sto appunto cercando di capire quale sia il metodo migliore,
oggigiorno, per
avere MX multipli con le stesse greylist, filtri etc, senza avere
SPOF.
Pura curiosità, perchè ad oggi tecnicamente non lo saprei fare, e mi
stavo chiedendo come
poterlo fare...

 Ma il discorso di questo thread è un altro... Torniamo IT...
Appunto, vedi sopra: UN DB UNO e non centomila e hai risolto il tuo
problema senza colpo ferire! :)


 problema senza colpo ferire! :)
Ok, quindi MySQL senza replica ma in heartbeat o come caspista si
scrive.
Come copi il DB in tempo reale dal server A al server B senza usare
una replica e
senza avere corruzione dei dati?
Tanto se ti schiatta il master, non puoi dire: Ue, aspettate, devo
sincronizzare il db...
La macchina ti è già morta e l'altra deve essere già li.
In replica non hai di sti problemi in quanto ogni insert/update/ecc
viene replicata
real-time sulle altre.
Con heartbeat?

 che si concentra solo su uno di questi.
Sai benissimo che, nonostante la fonte, non mi accontentero' mai di far 
mio questo assunto come dogma :-) Dove posso saperne di piu'?
Fabio
PS: ovviamente le mie considerazioni partono dal presupposto che i due,
    o piu', RR siano stati introdotti contemporaneamente e ospitino dei
    servizi che abbiano lo stesso modello di interazione con il client.

 Sempronio manda spam e prende il secondo server.
Questo puo' succedere se ricevi 4 mail. Se ne ricevi 4 milioni, potra' 
succedere ancora, ovviamente, ma in quel caso ti consiglierei d'andare
subito alla piu' vicina ricevitoria perche' e' arrivato il tuo momento
per puntare forte su qualcosa :-)
Fabio

 avvenga sul serio
Non te lo puo' GARANTIRE... ma il calcolo delle probabilita' e' un buon 
alleato :-)
Considera che il mio intervento, in ogni caso, riguardava la differenza
di distribuzione che ci potrebbe essere tra i round robin di A e di MX,
non entravo nel merito dell'efficacia della rotazione dei RR al fine di
distribuire il carico. 
Fabio

     servizi che abbiano lo stesso modello di interazione con il client.
In questo caso sicuramente hai una situazione più bilanciata che nel 
caso di un inserimento non contemporaneo, per ovvie ragioni.
Ma facciamo una breve descrizione del fenomeno:
- sappiamo che svariati spammer utilizzano spamware per direct-to-mx
- sappiamo che questi spamware spesso usano meccanismi di cache per i
   lookup anzichè effettuare risoluzione MX
Viene da sè che qualsiasi assunto basato sulla distribuzione statistica 
teoricamente uniforme effettuata dall'infrastruttura DNS viene meno, 
dato che non è più implicata nella fase di lookup...
Passiamo all'osservazione empirica.
Prendi questi due grafici qui:
http://www.bofhland.org/spam/mta1.png
http://www.bofhland.org/spam/mta2.png
E' abbastanza palese come le mail di "provenienza lecita" (ovvero con un 
MTA dall'altra parte) si distribuiscano in pratica uniformemente tra i 
due, mentre lo spam da direct-to-mx tenda a bersagliare solamente uno 
dei due.
Sono due MX con la stessa priorità, entrambi in funzione da almeno 6 
anni (ma forse anche di più, dovrei domandare a chi a memoria storica: 
io non c'ero...) durante i quali non hanno mai cambiato IP.
Il primo dei due sicuramente in origine era da solo.
Dato che però la gran parte dei domini che vi sono attestati non erano 
presenti a quel tempo (se non in numero irrisorio rispetto a quelli 
gestiti ora), che in origine vi fosse un solo MX dovrebbe essere irrisorio.
Dirò di più. Tra i domini gestiti da quei due MX ce n'è uno che da solo 
cuba ~ 250K spam/die di media (con picchi a 400K):
http://www.bofhland.org/spam/cliente.png
'sto dominio è arrivato su questi sistemi solamente pochi mesi fa 
(esattamente dal giorno in cui iniziano i dati sul grafico), ovvero 
*molto tempo* dopo il "raddoppiamento" degli MX, e quindi gli eventuali 
lookup degli MX preesistenti dal lato dello spammer di certo non hanno 
alcun peso.
Tuttavia, se vado a vedere come si distribuisce lo spam diretto a questo 
dominio tra i due MX di cui sopra, trovo che va -come tutto il resto- 
quasi tutto verso il primo MTA.
L'unica spiegazione è che lo spammer effettui una qualche sorta di 
ordinamento dei record ottenuti via DNS, che lo porta a privilegiare 
pedissequamente un MX in luogo dell'altro. Quale che sia il meccanismo 
che sta alla base, la distribuzione "globale" dello spam tra i due 
sistemi pare attestare che tale meccanismo è assai diffuso e che agisce 
univocamente.
Se poi è vero, come pare, che oltre il 90% dello spam in circolazione 
priviene dalle stesse botnet non è che questa uniformità di 
comportamento mi stupisca più di tanto...

 Ok.. e se "casca" IL sistema dove gira sqlgrey :) ?
infatti, ritagliando un pò il thread, il succo è questo:
A >> Se lo mettessi in ascolto solo su un singolo server, quel server
A >> diventerebbe uno SPOF.
M > infatti nel mio messaggio vevo scritto:
M > con le dovute precauzioni (deve essere HA altrimenti si ferma tutto 
il tuo sistema di posta)
ciao,
Manuel

 metter su un sistema HA, vorrà bene investirci qualche soldino... no ?
Certo, stavo solo cercando di capire le 'best-practise'...

 dato che il round robin DNS non è quello che ti serve :)
Il trade off e' sui costi e disponibilita'. Ci sono moltissimi casi
in cui farlo via dns potrebbe comunque essere un buon compromesso e
la "disquisizione su massimi sistemi" sarebbe quella necessaria per
giustificare il load balancer. 
Fabio

 giustificare il load balancer. 
Se posso dir la mia: dato che il 99% di quel che si distribuisce in 
maniera non uniforme è composto da spam inviato da spamware in 
direct-to-mx, si tratta di stabilire cosa si vuol ottimizzare.
Se l'obiettivo è ottimizzare la consegna delle mail "normali", il 
bilanciamento via MX è abbondantemente sufficiente: se anche il server 
più bersagliato dovesse saturare, il protocollo SMTP è autonomo nello 
spostare la consegna su altro MX.
Se invece l'obiettivo è soddisfare ogni singola richiesta, comprese 
quelle provenienti da oggetti che *non sono* MTA, allora il 
bilanciamento ha un senso...
Tutto IMHO.

 comportamento mi stupisca più di tanto...
Si', questo potrebbe essere uno dei fattori piu' rilevanti: la legge
dei grandi numeri puo' valere per la posta legittima. Lo spam viene,
invece, da poche sorgenti i cui diversi algoritmi di scelta degli MX
potrebbero introdurre variabili non aleatorie. 
E' anche interessante osservare (vedi altro ramo del thread) che per
i delivered (aka: sorgenti legittime) la distribuzione e' abbastanza 
uniforme sui due MX.
Fabio

 dato che il round robin DNS non è quello che ti serve :)
Ecco, un caso in cui il bilanciatore puo' fare sicuramente la differenza 
e' in caso di pesante spamrun da una botnet: se l'algoritmo di selezione 
del MX univoco, durante lo spamrun il carico potrebbe concentrarsi su un
solo MX.
Comunque, in effetti dai grafici di skull pare evidente la distribuzione
diversa dello spam (non di traffico legittimo). Il rapporto tra i valori
di picco e le medie sono piu' alti per mta1: potrebbe essere un indizio,
forse, a suffragio di quanto sopra (che so... magari c'e' qualche botnet
che ordina gli MX alfabeticamente :-).
Fabio

 uniforme sui due MX.
Nota che probabilmente sarebbe anche assolutamente uniforme, se non 
fosse per il fatto che alcuni dei domini ospitati (pochi) sono esclusi 
da filtraggio al pari degli account di servizio (abuse, postmaster), il 
che di fatto "alza un po'" il numero di mail accettate da mta1 e 
spiegherebbe la lieve differenza nelle medie.

 Perchè voglio la ridondanza al 100%
E allora ti metti un database qualsiasi in cluster active-passive.
(tipo, per dirne una, una soluzione heartbeat+drbd)

 Solo dsbl che sia degna di nota.
Boh: anche in quel caso, è chiuso solo il webserver, ma la struttura di 
mirror è ancora perfettamente in piedi, per quanto in assenza del sito 
la zona sia stata svuotata.
Ovvero: non blocca nulla, ma di certo non perdi posta.
Punterei più alla questione ORDB, ma se uno non bada alla configurazione 
dei suoi mailserver per 3 anni, IMHO se la va a cercare...

 (tipo, per dirne una, una soluzione heartbeat+drbd)
A quel punto non si fa prima con le repliche?
Va giù il master allora lo slave si autopromuove...

 slave si autopromuove...
Anche, ma mi pareva che di quella soluzione si fosse già discusso.

 Anche, ma mi pareva che di quella soluzione si fosse già discusso.
Be, avrei preferito evitare.
Però tra la replica di mysql o mettere in piedi drbd + heartbeat,
preferisco la replica di mysql, almeno è nativa.
Meno programmi = meno configurazioni = meno cose che potrebbero
rompersi (e che ovviamente si romperanno tutte insieme) = meno
problematiche in caso di emergenza con 10000 persone con il fiato sul
collo.

 metter su un sistema HA, vorrà bene investirci qualche soldino... no ?
sembra la pubblicità di piccolo e soffice: se non paghi non va, vero?
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH