RHEL, apache, tomcat en Planet Internet

[Verwijderd]

Hallo,

Ik heb een raar probleem met Planet Internet.

Sommige klanten van ons die via PI/WXS verbinding maken komen niet op onze website. Ze kunnen wel connectie maken maar kunnen geen data inladen die in een subdir staat. Dus /index.html werkt wel maar /test/index.html werkt weer niet.

Ik verwacht dat het aan de instellingen van apache ligt maar ik kan niets vinden. Het vreemde is dat bij alle andere providers het wel perfect werkt (versatel, chello, telenet,... ) we hebben trouwens ook klanten die via planet connectie maken waarbij wel alles prima werkt. Maar vanaf 62.131.248.1xx werkt het bv niet. Ik ben bij die klant terplaatse geweest met mijn eigen laptop en heb buiten alle firewalls en dergelijke om connectie proberen te maken maar dat werkte niet. Als dat nu de enige klant was dan zou het niet zo erg zijn maar we krijgen steeds meer klachten binnen.

Ik vermoed dat het probleem hem zit in de communicatie van de transparent proxy servers en onze webserver. Ik verwacht ook dat het met een instelling op te lossen is want de klanten met dit probleem kunnen normaal surfen op een willekeurige andere website.

Ik hoop dat er mensen zijn die dit probleem herkennen en me kunnen helpen een website te maken die voor iedereen bereikbaar is.
Het gaat trouwens om de volgende website: http://www.pics-united.com als je meer ziet dan alleen een blauwe balk dan werkt het prima. Als er mensen zijn waavoor de site niet bereikbaar is dan zou ik dat heel graag willen weten.

server specs: RHEL3 SMP
Apache/2.0.49
Apache Tomcat/4.1.30

[Verwijderd]

1) mogen we svp het relevante stukje uit je httpd.conf zien? (eg, heb je er geen gekke rewrite of ACL rules oid in?)
2) zelfde verhaal voor logfiles
3) je had het over proxy's. Waar staan die proxy's (aka, staan die onder jouw beheer?). Zit er (wellicht zonder dat je het doorhebt) nog andere proxy-achtige hard/software tussen de klant en jou? Heb je mischien een situatieschets. (of meest ideaal, heb je de configuratie van die proxy's met eventuele logs?)

Overigens doet je site het hier probleemloos (zowel vanuit xs4all als vanuit tweakdsl)

[ Voor 14% gewijzigd door Verwijderd op 04-05-2004 15:51 ]

[DiedX]

idd. Zonder een opsomtopic te willen worden: XS4ALL zonder proxy werkt perfect!

[0siris]

ik kan er met Planet gewoon bij met w3m ...
_{verder niets nuttigs te melden, sorry}

[Verwijderd]

Doe een een cat op /proc/sys/net/ipv4/tcp_ecn.

Deze zou op 0 moeten staan.

Kun je instellen in /etc/sysctl.conf:

code:

# Controls explicit congestion notification
net.ipv4.tcp_ecn = 0

Of je doet "echo 0 > /proc/sys/net/ipv4/tcp_ecn"

[Verwijderd]

[b]Deze zou op 0 moeten staan.

Kun je instellen in /etc/sysctl.conf:

code:

# Controls explicit congestion notification
net.ipv4.tcp_ecn = 0

Of je doet "echo 0 > /proc/sys/net/ipv4/tcp_ecn"

Daar staat een inderdaad een 0

code:

# cat /proc/sys/net/ipv4/tcp_ecn
0

[Verwijderd]

Verwijderd schreef op 04 mei 2004 @ 15:50:
1) mogen we svp het relevante stukje uit je httpd.conf zien?
2) zelfde verhaal voor logfiles
3) je had het over proxy's. Waar staan die proxy's

natuurlijk kan je mijn instellingen zien:

1) Er draaien verschillende websites op deze server die we uit elkaar houden met virtualhosts
dit is de vhost instelling van pics-united.com als je iets anders verwacht laat het dan ff weten.

code:

<VirtualHost *:80>
   ServerAdmin [e-mail]
   DocumentRoot "/usr/local/apache/www.pics-united.com"
   ServerName pics-united.com
   serverAlias www.pics-united.com
   ErrorLog /usr/local/apache/logs/pu-error_log
   CustomLog /usr/local/apache/logs/pu-access_log combined

    <Directory "/usr/local/apache/www.pics-united.com">
     Options +FollowSymLinks
     AllowOverride All
    </Directory>

  
   Alias /awstatscss "/usr/local/awstats/wwwroot/css/" 
   Alias /awstatsicons "/usr/local/awstats/wwwroot/icon/" 
   ScriptAlias /awstats/ "/usr/local/awstats/wwwroot/cgi-bin/" 
   # 
   # This is to permit URL access to scripts/files in AWStats directory. 
   # 
   <Directory "/usr/local/awstats/wwwroot"> 
   Options None 
   AllowOverride None 
   Order allow,deny 
   Allow from all 
   </Directory>
</VirtualHost>

2) aan de logfiles kan je niets zien. Bij die persoon die alleen de blauwe balk (is een deel van de site) ziet zie je in de access log een goede entry en voor de pagina's die hij niet ziet krijg ik ook niets in de error log.

3) Het proxy verhaal heb ik misschien niet helemaal duidelijk neergeschreven.
We draaien zelf geen proxy (dus ook geen log) en de mensen die er niet op komen hebben dat zelf lokaal ook niet draaien. Na verschillende zoekopdrachten ben ik zo goed als zeker dat planet internet transparent proxies heeft draaien. Omdat PI de enige schakel is tussen de computers verwacht ik dus dat het probleem tussen hun 'proxy' servers en onze server zit.

Ik heb trouwens al wat mail naar hun support gestuurd maar daar heb ik nog geen antwoord op gekregen.

[CyBeR]

Verwijderd schreef op 04 mei 2004 @ 17:51:
[...]


3) Het proxy verhaal heb ik misschien niet helemaal duidelijk neergeschreven.
We draaien zelf geen proxy (dus ook geen log) en de mensen die er niet op komen hebben dat zelf lokaal ook niet draaien. Na verschillende zoekopdrachten ben ik zo goed als zeker dat planet internet transparent proxies heeft draaien. Omdat PI de enige schakel is tussen de computers verwacht ik dus dat het probleem tussen hun 'proxy' servers en onze server zit.

Ik heb trouwens al wat mail naar hun support gestuurd maar daar heb ik nog geen antwoord op gekregen.

Bullshit. PI draait geen transparante proxies. Bovendien kan ik met PI-ADSL gewoon bij je website komen. Al draaide PI wel transparante proxies, dan nog zouden ze dat alleen buiten hun eigen netwerk doen. Daarbinnen levert het juist extra bandbreedtegebruik op.

[Verwijderd]

CyBeR schreef op 04 mei 2004 @ 18:14:
[...]


Bullshit. PI draait geen transparante proxies. Bovendien kan ik met PI-ADSL gewoon bij je website komen. Al draaide PI wel transparante proxies, dan nog zouden ze dat alleen buiten hun eigen netwerk doen. Daarbinnen levert het juist extra bandbreedtegebruik op.

Ik zit ook niet binnen het PI netwerk maar op het versatel netwerk en 90% van onze PI klanten hebben geen problemen het gaat dus om hoge uitzonderingen. Maar die wel heel erg vervelend zijn. Ik hoop eigenlijk dat er iemand van jullie is die geen connectie kan maken.

Transparant proxies zijn heel lastig om te ontdekken de meeste providers hebben ze draaien maar maken dit niet openbaar.

Als er trouwens iemand een methode kent om zeker te weten of er een transparent proxy dan zou ik dat ook graag weten.

Volgens een forum kan je naar het REMOTE_ADDR kijken
http://cgi.cybox.com/printenv.cgi
maar in diezelfde post staat ook dat een server dit kan neppen.

[frim]

heb je geprobeerd om alle bestanden in 1 dir te zetten en die aan te roepen (1keertje in de rootdir, en een keertje in een subdir)?

Uit deze regel

Ze kunnen wel connectie maken maar kunnen geen data inladen die in een subdir staat. Dus /index.html werkt wel maar /test/index.html werkt weer niet.

lijkt het toch echt een probleem van jouw kant. Probeer anders eens een 5MB file oid te downloaden vanaf die lokaties, en kijk of die wel aankomt.

Hebben jullie meerdere servers? Kan het niet toevallig aan 1 bepaalde server liggen? Iig is het wel heel raar. kijk anders eens of er niks raars in de .htaccess van die dirs staat.

[CyBeR]

Verwijderd schreef op 04 mei 2004 @ 18:37:
[...]

Transparant proxies zijn heel lastig om te ontdekken de meeste providers hebben ze draaien maar maken dit niet openbaar.

Natuurlijk niet. Als je transparent proxies draait ben je niet goed bezig als ISP.

Als er trouwens iemand een methode kent om zeker te weten of er een transparent proxy dan zou ik dat ook graag weten.

Volgens een forum kan je naar het REMOTE_ADDR kijken
http://cgi.cybox.com/printenv.cgi
maar in diezelfde post staat ook dat een server dit kan neppen.

Theoretisch mogelijk, maar heel moeilijk. Zeker om dat kosteneffectief te doen bij een grote ISP. Als je er bij een ISP ter grootte van PI nog profijt uit wilt halen (als in, minder bandbreedte in hoeven kopen zonder performanceverlies) met geintjes zodat de opvragende host dezelfde lijkt, zit je aan een oplossing die meer kost dan 'ie oplevert.

[Compusmurf]

Via mijn verbinding werkt het ook niet, ik gebruik fol Wide Open. Verder met de probleemoplossing kan ik je niet helpen

[Verwijderd]

Gezien de tests die je gedaan hebt, lijkt het mij niet dat het probleem in je server zit. Je config geeft daar ook geen aanleiding toe.

Het probleem dat ik hier thuis heb, is een redirect-probleem, omdat ik voor mijn eigen webserver een redir krijg naar het adres van mijn router en die kent die pagina niet. (Als ik uit mijn lan kom. Vanaf buiten werkt het wel goed.)
Als in dit geval jouw klanten (deels) hetzelfde domein gebruiken, kan dat redirect-problemen opleveren.

Als dat nog geen duidelijkheid biedt, probeer dan eens een connectie op te zetten naar je webserver met behulp van telnet. Vraag dan de pagina op en kijk wat de response is. Aangezien dit iets is wat nergens een cache heeft, weet je ook zeker dat er geen filter / dns-cache of een browser-cache problemen oplevert.

[Verwijderd]

Verwijderd schreef op 06 mei 2004 @ 21:04:
Het probleem dat ik hier thuis heb, is een redirect-probleem, omdat ik voor mijn eigen webserver een redir krijg naar het adres van mijn router en die kent die pagina niet. (Als ik uit mijn lan kom. Vanaf buiten werkt het wel goed.)
Als in dit geval jouw klanten (deels) hetzelfde domein gebruiken, kan dat redirect-problemen opleveren.

Kan je dit wat beter uitleggen? Ik kan het niet helemaal volgen.

Verwijderd schreef op 06 mei 2004 @ 21:04:
Als dat nog geen duidelijkheid biedt, probeer dan eens een connectie op te zetten naar je webserver met behulp van telnet. Vraag dan de pagina op en kijk wat de response is. Aangezien dit iets is wat nergens een cache heeft, weet je ook zeker dat er geen filter / dns-cache of een browser-cache problemen oplevert.

Ja dat zal ik inderdaad eens proberen. Het is wel jammer dat ik hier niet zomaar een verbinding heb waar ik mee kan spelen.
Een browser cache is het in elk geval niet, want ik met mijn eigen laptop die overal prima werkt, lukt het daar ook niet.

[Verwijderd]

Een http-get op www.domein.com levert je de beginpagina op. (index.html of dat wat in je webserver-conf hebt staan)

Een http-get op www.domein.com/dir levert je een redirect op naar /dir/ (<-- let op de slash!) Vervolgens vraagt je browser www.domein.com/dir/ op en je swerver stuurt weer de index.html zoals boven.

Het probleem wat ik nu heb, en dat komt door mijn interne netwerk is het volgende:

http-get mijnserver/usage (bijvoorbeeld)
Omdat mijn server zich presenteert als server.domein.com en niet als mijnserver, krijg ik op mijn verzoek een redirect terug naar server.domein.com/usage/ ( let weer op de slash )

Nu ontstaat het probleem dat de resolving nu verkeerd gaat omdat mijn domein zowel intern als extern bestaat en mijn browser (in het interne netwerk) nu verkeerd resolved en het verzoek stuurt naar een andere plaats. (in mijn geval kom ik uit op mijn adsl-router. En die webinterface kent mijn usage-statistieken niet)

Als jij nu bij je klanten intern een dns hebt die (een deel van) hetzelfde domein gebruiken, kan het dus zijn dat je een redirect krijgt naar een verkeerde server die iets verkeerd terug geeft.

Als je dus met telnet (ik gebruik liever netcat) deze tests uithaalt op het netwerk, kun je meteen alle headers mee teruglezen. tcpdump / ethereal of een andere "sniffer" op het netwerk kan dan ook veel helpen.

Is dit iets duidelijker ?

[Verwijderd]

Is dit iets duidelijker ?

Ja bedankt!!! het is al een heel stuk duidelijker.

Het probleem is bij mij niet helemaal hetzelfde want eigenlijk gaat het om deze url
http://www.pics-united.com/pu/servlet/pu.Get?pagina=index

Als applicatie server gebruik ik tomcat die via connector-JK2 met apache praat.
Tomcat zelf draai ik op poort 8080 maar deze poort is voor de buitenwereld afgesloten. Apache moet dus al het verkeer voor Tomcat intern redirecten.

Daar zou het dus aan kunnen liggen maar de volgende url waar totaal geen redirect plaats vind doet het ook niet

http://www.pics-united.co...over/images/capture_1.gif

Maar ik denk wel dat je helemaal gelijk heb om dit probleem eens goed met telnet te bekijken. Met een beetje geluk kan ik dan een aantal dingen uitsluiten zoals (transparent proxies ed. ) Ik zal nog eens een afspraak met een klant maken waar het niet werkt.

Bedankt voor het meedenken!!!

[Verwijderd]

Er is momenteel een kleine update.

Onze klant heeft een nieuwe modem gekregen en nadien konden ze zonder problemen op onze site. Samen met de nieuwe modem hebben ze ook een nieuw IP adres gekregen waardoor ze via andere routers onze site benaderen.

Ik denk dus niet dat het probleem hiermee opgelost is maar deze klant kan nu in elk geval op onze site en daar was het ons tenslotte om te doen.