Topic: servizio masq

[vgsangiuliano]

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

Code: [Select]

vi /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/90mirkocontenente una serie di regole del tipo

Code: [Select]

/sbin/iptables -A INPUT -p tcp --dport 4662 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 4672 -j ACCEPTecc. ecc. per tutte le porte di cui avevo bisogno, poi ho fatto

Code: [Select]

/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
/etc/init.d/masq restartNon contento ho riavviato lo sme, l'output di

Code: [Select]

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

Code: [Select]

/etc/e-smith/db ?
Non mi sembra il caso di rimuovere brutalmente il file masq in

Code: [Select]

/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

Code: [Select]

/etc/rc.d/init.d mettendo come prima operazione da fare un bel

Code: [Select]

service masq stop, però non mi sembra elegante.
Grazie

[Stefano]

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

[vgsangiuliano]

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

Code: [Select]

config show mldonkeyottengo

Code: [Select]

mldonkey=service
    access=public
    status=enabled
ciò non significa che è tutto ok?

[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

Code: [Select]

config show mldonkeyottengo

Code: [Select]

mldonkey=service
    access=public
    status=enabled
ciò non significa che è tutto ok?

prova:
- togliere il tuo fragment
- usare la sintassi [1]

Code: [Select]

config setprop mldonkey TCPPorts x,y,z,k

- a dare un

Code: [Select]

signal-event remoteaccess-update

- far ripartire mlnet e verificare con

Code: [Select]

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

[vgsangiuliano]

Dunque Stefano ecco quello che ho fatto:
il pacchetto rpm di mldonkey in questione è

Code: [Select]

sme-mldonkey-1.1-7pre3.i386.rpmSu 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

Code: [Select]

90InboundTCP50Mldonkey nella directory

Code: [Select]

\etc\e-smith\templates\etc\rc.d\init.d\masq il contenuto di questo fragment è

Code: [Select]

#-----------------------------------------
# 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

Code: [Select]

signal-event post-upgrade e

Code: [Select]

signal-event rebootsi ha

Code: [Select]

Enabling IP masquerading: Bad argument `udp'
Bad argument `udp'
Try iptables --help for more informationmentre rimuovendo il fragment in questione l'errore non si presenta.
Ho usato il tuo

Code: [Select]

config setprop mldonkey TCPPorts x,y,z,k e sembra funzionare.
Ti terrò informato.
Grazie come sempre