linux user group brescia

On Mon, 3 Nov 2003, Maurizio Paolini wrote:
>> From: Vernia Damiano <melkor.x a tiscali.it>
>>[...]
>> > telnet localhost 110
>> > mi dà comunque "connection refused"
>> > (il firewall è disattivato).
>> 	Ti da' "connection refused" anche senza firewall, se il serizio
>> non viene fatto partire.
>>> Michele mi consiglia di installare un pop3 non nella rh73 stessa.
>> 	Se ne usi uno della RH73 dovrebbe mettere le righe giuste al posto
>> giusto per xinetd. A quel punto devi solo cambiare la righina dove dice di
>> disabilitare il servizio (perche' RH l'installa, ma devi "autorizzare" tu
>> a manina xinetd a farlo partire).
>Su una RH 'standard' con pop3 che funziona, dovresti avere il seguente
>output con il comando 'chkconfig':
># chkconfig --list | grep pop3
>        ipop3:  on

 Non conosco RH, ma sulla mia SuSE8.0 il comando qui sopra non restituisce

ipop3: on

 mentre ho invece

xinetd	0:off	1:off	2:on	3:on	4:off	5:on	6:off

 e se digito:

lcoianiz a home:~> telnet home 110
Trying 192.168.10.4...
Connected to home.
Escape character is '^]'.
+OK POP3 home.coianiz.it v2001.78 server ready
quit
+OK Sayonara
Connection closed by foreign host.

 quindi ipop3d funziona "lo stesso" in quanto Xinetd capisce cosa deve far
partire, come daemon, dalla sua configurazione (v. mail precedenti).

>questo istruisce xinetd ad ascoltare sulla porta 110 e ad avviare il
>demone giusto /usr/sbin/ipop3d che ovviamente deve esistere;

 Il fatto che vedi "ipop3d: on" mi sembra più il segno di un daemon always
on e non gestito da Xinetd/Inetd (ma magari su RH le cose non stanno così).

>ma naturalmente esistono altre opzioni (vedi mail di morriz).
>Se tutto questo e' OK e ancora non ti funziona opterei per un problema
>di firewall.

 C'è anche un'altra possibilità che però, se ben ricordo, non è attiva per
default, se in /etc/xinetd.conf si usa il parametro "onlyfrom" per limitare
il range di indirizzi che possono raggiungere i servizi:

	[...]
defaults
{
        log_type        = FILE /var/log/xinetd.log
        log_on_success  = HOST USERID EXIT DURATION
        log_on_failure  = HOST USERID ATTEMPT RECORD
        only_from       = ::ffff:192.168.10.1 ::ffff:192.168.10.4
	...
}

 Il parametro only_from, definito in "default" serve probabilmente meglio
per limitare la fruizione dei servizi all'interno di intranet, mentre (IMHO)
andrebbe spostato nella configurazione dei servizi stessi, in caso di
apertura del server verso l'esterno (es. "telnetd only_from intranet",
posto di utilizzarlo, mentre ftpd più "libero").

 Fatto sta che se digito:

lcoianiz a home:~> telnet localhost 110
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

 perchè l'only_from mi limita, mentre:

lcoianiz a home:~> telnet home 110
Trying 192.168.10.4...
Connected to home.
Escape character is '^]'.
+OK POP3 home.coianiz.it v2001.78 server ready
quit
+OK Sayonara
Connection closed by foreign host.

 In Xinetd ho dovuto definire gli indirizzi "permessi" come IPv6: questo
l'ho scoperto leggendo il log di xinetd: autorizzando indirizzi IPv4 non
c'era verso di attivare i servizi, mentre usando IPv6 Xinetd capiva quello
che doveva far passare e cosa bloccare.
(btw: l'only_from NON sostituisce il firewall)

>Un altro possibile controllo e':
># fuser 110/tcp
>che ti dice quale processo e' in ascolto sulla porta 110, dovrebbe segnalarti
>un processo che se poi vai a vedere dovrebbe essere xinetd.

 Anche qui: ho l'impressione che usi ipop3d come daemon stabile e non
lanciato da Xinetd/Inetd: se non ho connessioni POP3 attive al momento e
lancio fuser non mi riporta niente, mentre se lancio un telnet aprendo una
sessione:

home:~ # fuser 110/tcp
110/tcp:              2359

 e

home:~ # ps ax | grep 2359 | grep -v grep
 2359 ?        S      0:00 ipop3d -s

 come penso sia corretto.

>chiaro che poi dovresti provare a fare un "telnet localhost 110"
>e vedere se le connessioni vengono accettate e se ti risponde un vero
>server pop3.
>mp

 Una cosa molto utile è, comunque, l'analisi di /var/log/xinetd.log :-)

	Ciao,
		Luca