Koozali.org: home of the SME Server
Other Languages => Italiano => Topic started by: vgsangiuliano on February 26, 2009, 08:40:53 PM
-
Ciao a tutti eccomi di nuovo qui.
Volevo chiedere una cosa:
c'è un modo per dire a sme che non voglio all'avvio che venga attivato il servizio masq/firewall?
Ho lo sme in questione dietro m0n0wall in dmz sul quale gira mldonkey.
Tutte le regole di m0n0 ed il NAT sono ok poichè se spengo masq e testo le porte di mldonkey è tutto in regola.
Se attivo masq invece ho il famigerato id basso su mldonkey e ciò è male.
Ho provato anche a creare un custom template con
vi /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/90mirko
contenente una serie di regole del tipo
/sbin/iptables -A INPUT -p tcp --dport 4662 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 4672 -j ACCEPT
ecc. ecc. per tutte le porte di cui avevo bisogno, poi ho fatto
/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
/etc/init.d/masq restart
Non contento ho riavviato lo sme, l'output di iptables -L
mi fa vedere tutte le mie belle porte aperte, ma mldonkey fallisce il test delle porte, come detto prima se stoppo masq e restarto mldonkey il test delle porte è ok.
Quindi tornando alla mia domanda iniziale c'è modo di non far partire il servizio masq all'avvio?
Devo smanettare nel db di sme sotto /etc/e-smith/db
?
Non mi sembra il caso di rimuovere brutalmente il file masq in /etc/rc.d/init.d
o sbaglio?
E per ultimo, visto che comunque c'è m0n0wall a fare da firewall e lo sme in questione se ne sta in dmz, non è un problema se elimino l'avvio di masq?
Ovviamente la soluzione che ho trovato è stata quella di modificare lo script di avvio di mldonkey in /etc/rc.d/init.d
mettendo come prima operazione da fare un bel service masq stop
, però non mi sembra elegante.
Grazie
-
ciao
il server è in modalità "server only"?
se si, il masq di fatto fa nulla.. l'importante è che comunque dichiari il servizio come visibile dall'esterno..
come? lascio a te il "compito per casa" :-)
Ciao e buon lavoro
Stefano
-
si lo sme è in server only, ed anche io pensavo che il fw fosse disattivato. Se il servizio non fosse accessibile dall'esterno perchè disabilitando masq funziona tutto?
PS Stefano magari sbaglio ma se do
config show mldonkey
ottengo
mldonkey=service
access=public
status=enabled
ciò non significa che è tutto ok?
-
si lo sme è in server only, ed anche io pensavo che il fw fosse disattivato. Se il servizio non fosse accessibile dall'esterno perchè disabilitando masq funziona tutto?
PS Stefano magari sbaglio ma se do
config show mldonkey
ottengo
mldonkey=service
access=public
status=enabled
ciò non significa che è tutto ok?
prova:
- togliere il tuo fragment
- usare la sintassi [1]
config setprop mldonkey TCPPorts x,y,z,k
- a dare un
signal-event remoteaccess-update
- far ripartire mlnet e verificare con
netstat -napt | grep mlnet
iptables -L | grep 46
se il servizio è in ascolto correttamente e se iptables ha le regole
Ciao
Stefano
[1] naturalmente TCPPorts e/o UDPPorts alla bisogna
-
Dunque Stefano ecco quello che ho fatto:
il pacchetto rpm di mldonkey in questione è sme-mldonkey-1.1-7pre3.i386.rpm
Su una macchina virtuale Sme 7.4 ho installato tale pacchetto e sostituito il binario mlnet con una versione più recente ricompilata. Il servizio si avvia.
Ho notato che l'rpm va ad aggiungere il file 90InboundTCP50Mldonkey
nella directory
\etc\e-smith\templates\etc\rc.d\init.d\masq
il contenuto di questo fragment è
#-----------------------------------------
# settings used by mldonkey server
{
package esmith;
use esmith::config;
use esmith::util;
use esmith::db;
my $edb = esmith::ConfigDB->open;
unless ($edb)
{
$edb = esmith::ConfigDB->create;
}
my $status = $edb->get_prop('mldonkey', 'status') || 'disabled';
my $access = $edb->get_prop('mldonkey', 'access') || 'private';
my $servermode = $edb->get_prop('masq', 'status') || 'disabled';
if ($status eq 'enabled' && $access eq 'public' && $servermode eq 'enabled')
{
$OUT .= " adjust_tcp_in 4661 ACCEPT \$NEW_InboundTCP\n";
$OUT .= " adjust_tcp_in 4662 ACCEPT \$NEW_InboundTCP\n";
$OUT .= " adjust_udp_in 4665 ACCEPT \$NEW_InboundUDP\n";
$OUT .= " adjust_udp_in 4666 ACCEPT \$NEW_InboundUDP\n";
}
}
Premesso che tale fragment sembra non essere corretto perchè al riavvio del server dopo i classici signal-event post-upgrade
e signal-event reboot
si ha
Enabling IP masquerading: Bad argument `udp'
Bad argument `udp'
Try iptables --help for more information
mentre rimuovendo il fragment in questione l'errore non si presenta.
Ho usato il tuo config setprop mldonkey TCPPorts x,y,z,k
e sembra funzionare.
Ti terrò informato.
Grazie come sempre