Newsgroup: it.comp.os.linux.sys
Titolo: Errore tra sibling squid

Salve a tutti.
situazione:
Proxy A - RH 7.0; Squid 2.3stable4; ipchains; ip 10.10.10.4
squid configurato per il transparent proxy con relativa regola di
ipchains per il redirect della 80 sulla 8080.
Proxy B - Slack 8.1; Squid 2.5stable2; iptables; ip 172.17.1.4
squid configurato "normalmente" (non transparent)
i due proxy sono in sibling tra loro ma il proxy B riesce ad accedere
alla cache del proxy A sia come ICP query sia come TCP per il GET, ma il
proxy A non riesce ad accedere al proxy B come TCP GET.
Fa le query, ne ottiene risposta e quando c'è il cache hit logga nel
cache.log un errore (2003/05/12 11:43:28| TCP connection to proxyB/8080
failed) e dopo 7 o 8 messaggi così mi considera DEAD il sibling con il proxy B
I rispettivi firewall sono aperti su tutte le porte da ip del proxy A a
ip del proxy B e viceversa. Ho verificato le acl ma sono uguali tra i
due, e nelle faq di squid non ho trovato niente che sia sembrato d'aiuto.
L'unica cosa che mi viene in mente è il tipo di get che effettua il proxy
A essendo in transparent.
Come posso fare a rendere il sibling bidirezionale eliminando gli errori
di DEAD sibling ?
Grazie in anticipo
Ron

 di DEAD sibling ?
Paiono errori di instradamento/connettivita`.
Hai provato a fare telnet e/o traceroute dall'uno all'altro?
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
Beam me up, Scotty!

 e/o traceroute dall'uno all'altro?
Intanto ti ringrazio per la risposta, non speravo più nell'intervento
esterno. Io ho già esaurito tutte le prove e i test che mi venivano in
mente e MRs. google oramai mi risponde sempre le stesse cose.
Cmq nelle prove fatte ho eseguito il telnet dal Proxy A al Proxy B ed
entro normalmente, qui nasce un'altro dubbio però: io per provare da
telnet ho digitato un "GET 
http://www.kernel.org
" e in risposta ho
ricevuto la pagina d'errore di squid ( quella che dice che non sono
autorizzato .......).
Per scrupolo ho verificato le acl http_access e icp_access ma sono tutte
ok. Ho inserito un'acl di prova con l'ip schietto del proxy B sullo squid
del proxy A ma il risultato è sempre quello.
Ogni suggerimento/idea è ben accetto perchè sono veramente alla frutta.
Ron

 Ron
 
Ma nei log quali IP ti viene mostrato come non accettato? Quell'ip è
quello che ti aspetti (e quindi abilitato nelle acl?
-- 
Roberto Tagliaferri Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Il paese da dove veniva non era un paese di geni.
	Loro lo chiamavano computer umano perchè sapeva contare fino a 20.
	Nudo fino a 21

 quello che ti aspetti (e quindi abilitato nelle acl?
Giro parte del cache.log del proxy A (ip 128.1.1.22):
 
2003/05/12 17:36:28| Restarting Squid Cache (version 2.3.STABLE4)...
2003/05/12 17:36:28| FD 5 Closing HTTP connection
2003/05/12 17:36:28| FD 7 Closing ICP connection
2003/05/12 17:36:28| Cache dir '/home/squid' size remains unchanged at 256000 KB
2003/05/12 17:36:28| DNS Socket created on FD 1
2003/05/12 17:36:28| Adding nameserver 128.1.1.2 from squid.conf
2003/05/12 17:36:28| Adding nameserver 128.1.1.3 from squid.conf
2003/05/12 17:36:28| Accepting HTTP connections at 128.1.1.22, port 8080, FD 5.
2003/05/12 17:36:28| Accepting ICP messages at 128.1.1.22, port 3130, FD 7.
2003/05/12 17:36:28| WCCP Disabled.
2003/05/12 17:36:28| Configuring Sibling proxyB/8080/3130
2003/05/12 17:36:28| Loaded Icons.
2003/05/12 17:36:28| Ready to serve requests.
2003/05/12 17:36:28| Configuring Sibling proxyC/8080/3130
2003/05/12 17:45:14| Detected DEAD Sibling: proxyC/8080/3130
2003/05/13 08:39:30| TCP connection to proxyB/8080 failed
2003/05/13 08:39:34| TCP connection to proxyB/8080 failed
2003/05/13 08:39:34| TCP connection to proxyB/8080 failed
2003/05/13 08:39:43| TCP connection to proxyB/8080 failed
2003/05/13 08:40:03| TCP connection to proxyB/8080 failed
2003/05/13 08:40:05| TCP connection to proxyB/8080 failed
2003/05/13 09:25:43| TCP connection to proxyB/8080 failed
2003/05/13 09:25:44| TCP connection to proxyB/8080 failed
2003/05/13 09:25:49| TCP connection to proxyB/8080 failed
2003/05/13 09:25:49| TCP connection to proxyB/8080 failed
2003/05/13 09:25:49| Detected DEAD Sibling: proxyB/8080/3130
2003/05/13 10:10:02| ftpTimeout: timeout in SENT_PASV state
2003/05/13 12:20:11| urlParse: Illegal character in hostname 'www.hobbycountry,it'
2003/05/13 14:00:43| sslReadServer: FD 16: read failure: (104) Connection reset by peer
2003/05/13 14:01:41| sslReadServer: FD 26: read failure: (104) Connection reset by peer
2003/05/13 14:01:42| sslReadServer: FD 38: read failure: (104) Connection reset by peer
i due dns (128.1.1.2 e 128.1.1.3) sono dns interni e non pubblici e
risolvono correttamente il nome per proxyB, cmq ho provato anche con l'ip
diretto nel tag cache_peer di squid conf.
Il proxyA raggiunge correttamente il proxyB con le query UDP ma quando ha
un CACHE_HIT e deve recuperare il dato con il TCP logga l'errore per poi
dare il DEAD sibling.
Spero di non aver ommesso niente di importante.
Ron
P.S. Scusare per il post lungo.

 autorizzato .......).
Hai dimenticato di specificare il protocollo.
La sintassi corretta e`:
GET 
http://www.kernel.org/
 HTTP/1.0
<invio><invio>
Prova a fare questa verifica da una macchina all'altra e viceversa.
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
To every Ph.D. there is an equal and opposite Ph.D.
		-- B. Duggan

 dare il DEAD sibling.
Siamo sicuri che il proxyB sia in ascolto alla porta 8080?
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
A bit of talcum
Is always walcum
		-- Ogden Nash

 Siamo sicuri che il proxyB sia in ascolto alla porta 8080?
 
si si
Ron

 Prova a fare questa verifica da una macchina all'altra e viceversa.
 
Tnk's 1000, ora provo poi ti sò dire.
Ron

 per caso qualche link sottomano ?
E` standard HTTP. Puoi controllare su qualsiasi mirror dei documenti
RFC. Ora come ora pero` purtroppo non ricordo i numeri esatti. Prova a
cercare con google le parole "HTTP 1.1 RFC IETF Chapter".
Inoltre dei sibling possono parlare fra di loro anche in ICP (sempre
standard, puoi cercare "ICP RFC IETF Chapter") o molto raramente in HTCP.
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
I'm frequently appalled by the low regard you Earthmen have for life.
		-- Spock, "The Galileo Seven", stardate 2822.3

 cercare "ICP RFC IETF Chapter") o molto raramente in HTCP.
 
Tnk's a lot.
-- 
__________________________________
So many women, and so little time!