Newsgroup: it.comp.os.linux.sys
Titolo: Servizi con feedback lentissimo

Ciao!
Vi vorrei fare una domanda tecnica anche se forse, ahime', non riesco
restringervi il campo del problema...comunque ci provo.
Ho una piccola rete (sconnessa da Internet) di macchine Linux 2.4.24
distro Debian 3.0.r2. La prima fa da server con vari servizi (web, ftp,
telnet, ssh, dns, etc.), la seconda da firewall con IPTABLES e la terza
da client.
Il problema è che, con o senza firewall attivato, dal client ottengo dei
feedback lentissimi da parte dei servizi che girano sul server: della
serie che dopo l'autenticazione del wu-ftpd per ottenere l'output di un
ls devo attendere dei minuti!!!
Come gia' detto non so che altre indicazioni darvi...se avete domande
saro' naturalmente felice di aiutarvi ad aiutarmi :)
GRazie
-- 
Roar! By Polar 
Dedicato a chi insegue un sogno nella vita.
Ai tenaci, ai testardi e agli ostinati.   
A chi cade e si rialza, a chi ci prova sempre e a chi non molla mai.

 GRazie
-- 
Signature automatica inserita a mano.
Unv nccran qrpbqvsvpngb yn zvn svezn.
In God we trust, all others we monitor 
(National Security Agency)

Domanda forse banale, i nomi come li risolvi??
Li risolvo con il DNS (BIND 9) presente sul server. Comunque i problemi
si riscontrano anche usando direttamente gli indirizzi IP.


 problemi si riscontrano anche usando direttamente gli indirizzi IP.
I problemi di lentezza in autenticazione sono dovuti solitamente a due
fattori:
risoluzione della zona inversa per l'ip del client e/o eventuale drop
delle richieste ident...
i miei due cent...
-- 
the Skull says:
+---------------------------------------------------------------------+
 We are Pentium of Borg. Division is futile. You will be approximated.

i miei due cent...
Ti ringrazio


 ls devo attendere dei minuti!!!
č probabilmente il dns che va in timeout.
Senti, come gestisci la zona di reverse?

 preciso?
Puo` essere,  ma anche  no.  Di solito  alcuni servizi  possono essere
configurati[1] per fare  una richiesta identd al client  per sapere il
nomeutente  sul client  che ha  iniziato la  connessione.  Se  c'e` un
server identd aperto  sul client rispondera` alla richiesta  e la cosa
funzionera` velocemente.  Se la porta e` chiusa da rfc lo stack tcp/ip
del  client deve  rispondere  con un  tcp  rst e  la cosa  funzionera`
velocemente lo stesso.
Se lo stack tcp/ip del cliet non e` standard e non risponde, oppure se
il firewall droppa il pacchetto uscente verso la 113 del client oppure
se il client stesso ha  un firewall che droppa queste richieste allora
il server dovra` attendere che scada il timeout...
So che non  sono stato molto chiaro, ma spero tu  mi abbia compreso lo
stesso :-)
[1] Non  e` detto  che sia  il server configurato  in questo  modo, se
passa  da tcpwrappers  e`  hosts.allow o  hosts.deny  che puo`  essere
configurato in modo da interrogare il server identd del client.
-- 
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]

I miei due cent :-)))
Ho avuto una situazione abbastanza simile recentemente e dopo innumerevoli
tentativi per isolare il problema sono giunto ad un cavo cat.5 balordo!
Prova a fare un semplice ping verso il server.
Poi massacralo con un ping -f -i0 -s50000
Sulla mia rete 100mbit con hub 3com, un pc i586 Linux e un pc i686 Windows
non ho pacchetti persi. Col sopracitato cavo balordo, si inchiodava con
pacchetti superiori ai 1000byte
Alex.
-- 
___________________________________________________________
a p bertolini
(
www.webwarrior.org
)

stesso :-)
Sei stato chiaro :)
Comunque, non e' neppure un problema di AUTH/IDENT
Grazie


è probabilmente il dns che va in timeout.
Ho reimpostato il resolv.conf e ho stoppato il dns ma non cambia nulla.
Non e' un problema di risoluzione dei nomi, almeno credo.


Poi massacralo con un ping -f -i0 -s50000
Ne ha persi solo il 4%. Credo quindi che non sia neppure questo.
Grazie


Polar <
po...@polenord.org
 > roars:
[cut]
Grazie a tutti per i vostri consigli ma ahime' non ho ancora risolto.
Un altro indizio prima di riformattare il server: ad esempio se mi
connetto in telnet, il client mi visualizza dopo l'inserimento di login
e password:
[TLS Negotiation]
oppure
[SSL Inizialising]
Qualche idea?
Grazie ancora per il vostro supporto! :)


 Non e' un problema di risoluzione dei nomi, almeno credo.
Lo e', lo e'... (IMHO) o reverse, o auth droppato.
Come l'hai reimpostato il resolv.conf?
Per fungere come vorresti, probaibilmente non
vi dev'essere nessuna riga "nameserver".
Altrimenti, qualunque dns gli metti...
Poi forse, ma ne dubito, potrebbe entrare in gioco anche nswitch.conf.
bye G.L.
-- 
- Renaissance, aka Gian Luca Sole -
Cit. « E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
                                         (Woody Allen)

Poi forse, ma ne dubito, potrebbe entrare in gioco anche nswitch.conf.
...impostare qui "hosts,bind"
Grazie


 ...impostare qui "hosts,bind"
No, quello e' il file host.conf.       ;-)
hosts:	files dns


 Non e' un problema di risoluzione dei nomi, almeno credo.
reverse, non resolv!
al 99% è che riesce a risolvere 
prova.pippo.com
 -> 192.168.0.1 ma non 
riesce a fare 192.168.0.1 -> 
prova.pippo.com

 nameserver 127.0.0.1
A 'sto punto Domanda spiccia, da rispondere con si' o no:          ;-)
Se il problema si verifica da un client nella lan, dimmi se nel tuo
dns e' definita la zona diretta e inversa che specifica:
<nome.dominiolocale_client> ==>> <ip_client>  e  <ip_client> ==>> 
<nome.dominiolocale_client>
N.B.: mi riferisco ad un *domino locale* per la lan, che avrai 
naturalmente definito
se non vuoi pasticciare con /etc/hosts, non al tuo dominio vero.


 roars:
[cut]
Ho ricompilato il kernel e ora tutto funziona perfettamente.
Vi ringrazio tutti per tutti i vostri suggerimenti :)


 Vi ringrazio tutti per tutti i vostri suggerimenti :)
Se e' lecito, cosa non andava?


Se e' lecito, cosa non andava?
E' piu' che lecito visti tutti gli aiuti che mi hai dato. 
Purtroppo la risposta e': non lo so :-( Ossia ricompilando il kernel la
lentezza nel feedback e' sparita ma non ho capito perche'...forse
qualche modulo della gestione del sottosistema di rete.
