Qmail e relay: varie ed eventuali

Girare tutte le mail verso uno smarthost

Inserire nel file /var/qmail/control/smtproutes la riga seguente:

:indirizzo_o_nome_server_remoto

Tutta la posta verra' spedita tramite il server indicato.

Girare tutte le mail per un dominio specifico verso uno smarthost 

Inserire nel file /var/qmail/control/smtproutes la riga seguente:

nome_dominio:indirizzo_o_nome_server_remoto

Tutta la posta per il dominio nome_dominio verra' spedita tramite il server indicato.

Postfix e relay: varie ed eventuali

Vediamo qualche trucco per risolvere alcune situazioni di relay con postfix:

1. Come configurare postfix per usare un relay host (smarthost) remoto
2. Consentire a postfix di accettare posta in relay da ip address specifici.
3. Come ritrasmettere (relay) mail per domini specifici (ad esempio quelli locali)
4. Come configurare i domini virtuali in postfix

 
1. Come configurare postfix per usare un relay host (smarthost) remoto

Ipotizziamo che usiate Linux e il vostro provider sta filtrando il traffico sulla porta 25, impedendoti di fatto di spedire la posta direttamente dalla vostra macchina.
L'unica possibilita' in questi casi e' configurare il vostro mailserver per girare tutta la vostra posta in uscita attraverso il server del provider.
Con postfix questo e' molto semplice.

in /etc/postfix/main.cf, settate la variabile:

relayhost = smtp.yourisp.com

poi rilanciate postfix:

/etc/init.d/postfix restart

2. Consentire a postfix di accettare posta in relay da ip address specifici.

Per default, postfix consente il relay (ricezione e reinvio verso un destinatario remoto) anonimo solo ai computer della proria rete. Potete aggiungerer uno o piu' IP address che dopo il riavvio di postfix verranno considerati come IP "virtuosi" da cui puo' essere accettata posta in relay.

In /etc/postfix/main.cf cambiare:

mynetworks = 127.0.0.0/8

in

mynetworks = 127.0.0.0/8, 192.168.0.1/24, 62.35.x.x/30, x.x.x.x

 Ovvero una lista di ip address (sia sottoreti che singoli host) separati da virgole. 

3. Come ritrasmettere (relay) mail per domini specifici (ad esempio quelli locali)
 
Potete utilizzare il file /etc/postfix/transport con il seguente formato

somedomain.com     smtp:[10.0.0.1]:25

otherdomain.com    smtp:10.0.0.2:25 

ovvero:
dominio_per_cui_fare_relay    smtp:ip_server_remoto:porta








La versione con l'IP address racchiuso tra [] disabilita la verifica del record MX relativa al dominio in questione.

N.B. Verificare che in /etc/postfix/main.cf ci sia la riga seguente:

transport_maps = hash:/etc/postfix/transport

N.B. dopo ogni modifica al file /etc/postfix/transport lanciare il comando seguente:

postmap hash:/etc/postfix/transport

4. Come configurare i domini virtuali in postfix

/etc/postfix/virtual e' un file di testo dove specificare i domini e gli utenti per cui accettare le email. Ogni dominio virtuale dovrebbe cominciare con una singola linea contenente il nome del dominio.
Le righe seguenti definiscono gli indirizzi del dominio da gestire.
Le mail saranno consegnate agli utenti locali indicati sulla destra (come nell'esempio seguente). La clausola @nomedominio consente di recapitare tutte le altre mail all'utente indicato (catchall).
Potete gestire piu' di un dominio in questo file, basta ripeterne la struttura mostrata qui sotto:

dominio.com        this-text-is-ignored
postmaster@dominio.com     postmaster
address1@dominio.com     utentelocale1
address2@dominio.com     utentelocale2
@dominio.com        utentelocale1

This e-mail address is being protected from spambots. You need JavaScript enabled to view it This e-mail address is being protected from spambots. You need JavaScript enabled to view it This e-mail address is being protected from spambots. You need JavaScript enabled to view it Dovete dire a postfix dove cercare queste mappature per gli alias virtuali. La direttiva corretta si trova nel file /etc/postfix/main.cf e dice a postfix di usare la versione hash del file appena creato. Il file hash non viene creato  finche' non lanciate il comando "postmap virtual" come vedremo piu' avanti.

Il /etc/postfix/main.cf deve contenere la seguente riga

virtual_alias_maps = hash:/etc/postfix/virtual

Avendo modificato il file main.cf, dovete riavviare il demone postfix. Il secondo comando aggiorna la mappatura degli alias virtuali. Dovete rilanciare il comando postmap ogni volta che modificate il file /etc/postfix/virtual.

postfix reload

postmap /etc/postfix/virtual

Ora provate a recapitare una mail agli indirizzi del dominio virtuale. Se ci fossero problemi, verificate i log relativi al server di posta. e controllate che i due comandi precedenti siano stati eseguiti.

Installazione Dovecot IMAP server

sudo apt-get install dovecot-imapd

Modifiche a /etc/dovecot/dovecot.conf:

1) verificare la linea che inizia con protocols, di norma deve essere:

protocols = imap imaps

2) valorizzare la variabile mail_location a seconda della configurazione richiesta. Nel mio caso e' una installazione Maildir con layout filesystem (le mailbox sono cartelle del filesystem e possono contenere messaggi e sottocartelle, ovvero altre mailbox):

mail_location = maildir:~/Maildir:LAYOUT=fs

Riavviare dovecot con il comando:
sudo /etc/init.d/dovecot restart

Avahi? No grazie, preferisco un rabarbaro

Credo di aver capito la ragione di certi strani comportamenti che avevano afflitto il networking di certi server debian utilizzati per l'ultimo corso. La colpa potrebbe, accetto eventuali smentite, essere di avahi che su un server pare sia di troppo (ma 'ndo avahi?).

Per star tranquillo ho provato a disabilitarlo sul mio server (mi impediva ad esempio di eseguire rsnapshot su server remoti tramite ssh):

/etc/init.d/avahi-daemon stop
sudo update-rc.d -f avahi-daemon remove

se volete riattivarlo al boot successivo lanciate il comando:

sudo update-rc.d -f avahi-daemon defaults

Dibattito: raid1 o raid5

Un post un po' diverso dal solito, invece che spiegare qualcosa propongo un dibattito per approfondire un argomento di cui parlavo in questi giorni con alcuni amici e colleghi:

La situazione finale dovrebbe essere un piccolo file server, basato su una scheda Intel DG35EC, Debian Lenny e 1 terabyte di storage, dischi SATA II collegati al controller della scheda madre e raid gestito da md. La macchina dovrebbe mantenere un vmware server con relative VM e un po' di backup di altre macchine della rete.

Il problema su cui apro la discussione e' la seguente:

Conviene installare 2 dischi da 1TB in raid 1 o 3 dischi da 500 MB in raid5? La spesa per l'hardware sarebbe la stessa per entrambe le configurazioni.

Non siate timidi, partecipate con i vostri consigli, le vostre esperienze, le vostre intuizioni e magari qualche sfrombolone, l'importante e' che i commenti siano in tema :)

(per ora saro' imparziale e non rivelero' come la penso)

LTSP: ipconfig: eth0: SIOCGIFINDEX: No such device

Il progetto LTSP (Linux Terminal Server Project) consente di utilizzare dei thin-client collegati in rete a un server linux debitamente preparato.

Potete usare thin-client veri e propri o utilizzare un PC, anche vecchio, purche' possa eseguire il boot da rete e abbia una scheda video gestita da linux.

• Che vantaggi abbiamo con questa configurazione?
• Possiamo utilizzare come client dei PC altrimenti obsoleti
• Non e' richiesto che il client abbia un disco rigido, quindi meno dati sparsi, meno rischi di rottura, meno calore generato dai client, maggiore protezione dei dati conservati sul server (che in quanto tale si ritiene ridondato, backuppato e quindi piu' sicuro)

Purtroppo puo' capitare, eseguendo il boot da rete di ricevere questo errore:
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
/init: .: 1: Can't open /tmp/net-eth0.conf
[] Kernel panic - not syncing: Attempted to kill init!

Questo perche' probabilmente il modulo relativo alla scheda di rete installata sul client non e' presente nel kernel scaricato dalla rete.

Vediamo quindi come aggiungere un driver al kernel distribuito dal server LTSP (nell'esempio faro' riferimento al modulo sis190 relativo alle schede ethernet 190 prodotte dalla SiS):

Loggarsi come amministratore sul server LTSP
Aggiungere al file /opt/ltsp/i386/etc/initramfs-tools/modules il nome del modulo richiesto, in questo caso sis190
Se esiste il file /opt/ltsp/i386/usr/share/initramfs-tools/hook-functions, aggiungere il nome del driver alla linea contenente i riferimenti alle altre schede come nell'esempio seguente:
da

r8169 s2io sis900 skge slhc smc911x starfire \

a

r8169 s2io sis900 skge slhc smc911x starfire sis190 \

Eseguire i comandi seguenti:

chroot /opt/ltsp/i386 update-initramfs -u
ltsp-update-kernels

Sul mio server in questa fase ricevo qualche errore secondario, pero' il driver viene installato correttamente.

VMware server: la macchina virtuale non vede periferiche usb???

Verificare se nella definizione della macchina virtuale e' compreso il controller USB. In caso contrario aggiungerlo dall'apposita funzione della console di manutenzione.

Selezionando la macchina virtuale dovrebbe esserci un pulsante relativo al sistema USB:


Piu' in dettaglio:


Cliccandolo dovrebbe apparire un menu:


su cui selezionare le periferiche USB da associare alla macchina virtuale corrente.
Ora la macchina virtuale dovrebbe essere in grado di utilizzare le perferiche selezionate.

dovecot non parte al boot?

Dovecot e' un server di posta che gestisce caselle di tipo mbox e Maildir.

Se lanciando

/etc/init.d/dovecot start

il server non va in esecuzione, ma parte correttamente se vi limitate a digitare il comando

dovecot

dovete fare una piccola modifica al file di configurazione /etc/dovecot/dovecot.conf:

La linea che comincia con #protocols deve essere decommentata rimuovendo il carattere '#'

Spiegazione

Secondo le istruzioni, le righe commentate sul file di configurazione mostrano i valori di default, quindi non e' necessario decommentarle se vogliamo mantenere quei valori.

Purtroppo il file /etc/init.d/dovecot, che si occupa di eseguire il server dovecot al boot, cerca la linea protocols non prceduta dal carattere '#', se non la trova, la procedura di esecuzione viene interrotta.

SMTP: tin.it e virgilio.it

Per indirizzi nomeutente@tin.it -> smtp.tin.it

Per indirizzi nomeutente@virgilio.it -> out.virgilio.it

Virgilio puo' utilizzare anche il server di tin.it

dhcp_probe: scopriamo i server DHCP sulla nostra rete

E a che vi serve? Voi sapete benissimo quali sono i DHCP sulla vostra rete....

Beh non e' detto....qualche "simpaticone" potrebbe essersi intrufolato e avervi installato il suo DHCP server che darebbe informazioni errate ai vostri client indirizzandoli verso angoli oscuri della rete. Il tutto ovviamente per carpirvi informazioni.

Bene, c'e' un bel software per SUN che rileva eventuali server DHCP illegali (rogue DHCP servers), si chiama dhcp_probe, e' stato sviluppato all'universita' di Princeton e lo trovate QUI.

Dicevo che e' un software per SUN pero' (e la trovate nella home page del progetto) e' stata scritta una patch che ne consente la compilazione sotto Linux.

Vediamo come fare per compilare il pacchetto su sistemi Ubuntu Linux, posizioniamoci nella directory dove teniamo i sorgenti da compilare:

cd /usr/local/src

Scarichiamo il programma:

Scarichiamo la patch per compilarlo in Linux:

Scompattiamo il pacchetto contenente i sorgenti:

tar xzvf dhcp_probe-1.2.1.tar.gz

Applichiamo la patch:

patch -p0 < dhcp_probe-1.2.1-weppelman-1.diff.txt

Ora se vivessimo in un mondo perfetto, basterebbe digitare:

./configure;make;make install

per compilare e installare il programma.

Purtroppo, almeno oggi su Ubuntu Gutsy alla vigilia del rilascio di Ubuntu Heron, sono necessarie due librerie. La prima, libpcap, la installiamo agevolmente con il seguente comando:
sudo apt-get install libpcap-dev
La seconda, libnet, dobbiamo ricompilarla in quanto le manca una funzione fondamentale per il funzionamento del nostro programma. Vediamo come fare:

cd /usr/local/src
apt-get source libnet1-dev
cd libnet-1.1.2.1

sudo gedit src/libnet_cq.c

Aggiungere queste linee a fine file:

u_int32_t
libnet_cq_end_loop()
{

if (! clear_cq_lock(CQ_LOCK_WRITE))
{
return (0);
}
l_cqd.current = l_cq;
return (1);
}

sudo gedit include/libnet/libnet_functions.h

Aggiungere queste linee a fine file:

u_int32_t
libnet_cq_end_loop();

A questo punto bisogna ricompilare il pacchetto libnet:

dpkg-buildpackage

Questo comando generera' in /usr/local/src (o piu' in generale nella directory dove tenete i sorgenti) due pacchetti deb:

libnet1_1.1.2.1-2build1_i386.deb
libnet1-dev_1.1.2.1-2build1_i386.deb

Che andiamo a installare con il comando:

sudo dpkg -i libnet1_1.1.2.1-2build1_i386.deb libnet1-dev_1.1.2.1-2build1_i386.deb

A questo punto possiamo riprovare a compilare il pacchetto dhcp_probe come a inizio post, quindi:

cd /usr/local/src/dhcp_probe-1.2.1
./configure
make
make install
cp extras/dhcp_probe.cf.sample /etc/dhcp_probe.cf

Possiamo poi lanciare il programma con questa linea di comando:

dhcp_probe -f -d 11 eth0

Aggiornamento ora/data su Perfectone IP300/IP301

Il telefono IP301 distribuito da Eutelia (e il suo gemello marcato Perfectone IP300) hanno problemi nell'aggiornamento automatico di data e ora se utilizzate il server proposto da Eutelia.

Potete invece usare i server NTP dell'Istituto Nazionale di Metrologica:

193.204.114.232
193.204.114.233

Con questi server impostati in Phone Setting -> SNTP Sttings -> Primary Server e Phone Setting -> SNTP Sttings -> Primary Server nell'interfaccia di amministrazione del vostro telefono IP, all'accensione del telefono (e a ogni successivo riavvio) otterrete un quasi istantaneo aggiornamento di data e ora.

NB: ricordatevi di settare la corretta Time Zone (per l'Italia GMT + 1)

Exchange: attivare i log sul protocollo SMTP

Per abilitare il log aprire Exchange System Manager e selezionare:

Administrative Groups -> First Administrative Group -> Servers -> VOSTROSERVER -> Protocols -> SMTP -> Default SMTP Virtual Server -> General



Di norma i log possono essere situati nella cartella %systemroot%\system32\logfiles.