Website extreem traag; wat eraan te doen?

[BartB.]

Sinds enkele dagen is mijn website extreem traag, wat zo'n beetje inhoudt dat elke pagina er gemiddeld zo'n 20 seconden over doet om te laden. Voorheen heb ik hier nooit last van gehad, en zeker geen drie dagen achter elkaar, want zo lang heb ik inmiddels al last van 't probleem.

De website is dedicated gehost bij LeaseWeb en uiteraard heb ik ook al contact met hun support gehad, maar die lijkt er weinig aan te kunnen doen. Het netwerk is volgens hen in orde dus daar ligt het probleem niet, maar het zou mogelijk kunnen liggen aan een probleem met de software op onze server. Hier zouden ze naar kunnen kijken, maar aangezien dat me zo'n 25 euro per kwartier gaat kosten wil ik daar liever niet te snel aan beginnen.

Is er hier iemand aanwezig die er toevallig verstand van heeft en wellicht weet wat ik er zelf aan zou kunnen doen? Omdat de website zó ontzettend traag is lijkt het wel alsof er ergens iets continu geloopt wordt of iets dergelijks, maar hoe is dit te controleren? Iemand wellicht nog andere suggesties?

Enige hulp wordt zeer op prijs gesteld in ieder geval.

[McKaamos]

Beetje meer info over je server misschien?
Linux? Windows? heb je een uitdraaitje van een performance meter progsel? Of anders misschien een uitdraaitje van de lopende processen met alle nodige attributen? (RAM usage, CPU usage, swapspace etc)

[ Voor 35% gewijzigd door McKaamos op 05-03-2007 14:10 ]

[Outerspace]

Heb je teveel zut in je code staan en/of content? Met welke browser is het traag? Zowel Opera als Firefox, Internet Explorer, Safari e.d.? Daarnaast is het inderdaad weinig informatie die je ons beschikbaar stelt

[LuCarD]

Outerspace schreef op maandag 05 maart 2007 @ 14:11:
Heb je teveel zut in je code staan en/of content? Met welke browser is het traag? Zowel Opera als Firefox, Internet Explorer, Safari e.d.? Daarnaast is het inderdaad weinig informatie die je ons beschikbaar stelt

Is hij alleen traag vanaf jouw verbinding of ook vanaf andere locaties?

[BartB.]

't Gaat om een Linux server.

De site is verder overal traag, met iedere browser. Hierover al opmerkingen/klachten gekregen van bezoekers, dus het probleem móet wel bij onze server liggen.

McKaamos, wat voor programmaatje zou ik kunnen draaien om de performance te testen? Heb er vrij weinig ervaring mee zoals je waarschijnlijk al merkt.

Edit: Oh ja, het ligt niet aan de code van de website in ieder geval... We draaien op dit moment ruim 3,5 jaar op dezelfde code en zoals ik al aangaf zijn daar nooit eerder problemen mee geweest. 't Vreemde is ook dat de problemen van het ene op het andere moment begonnen, zonder dat we ergens iets hebben aangepast.

[ Voor 32% gewijzigd door BartB. op 05-03-2007 14:21 ]

[McKaamos]

BartB. schreef op maandag 05 maart 2007 @ 14:17:
't Gaat om een Linux server.

De site is verder overal traag, met iedere browser. Hierover al opmerkingen/klachten gekregen van bezoekers, dus het probleem móet wel bij onze server liggen.

McKaamos, wat voor programmaatje zou ik kunnen draaien om de performance te testen? Heb er vrij weinig ervaring mee zoals je waarschijnlijk al merkt.

op de console van Linux gewoon "top" intikken.
Ik neem aan dat je shell access hebt, dus dan zou je met PuTTY even in kunnen loggen en dan "top" intikken. Dan kopieer je de tekst even in een [ code] [/ code] blok hier op het forum.

[BartB.]

"Top" levert me dit op:

code:

23569 apache    15   0 26216  17m  10m S  2.7  1.7   0:01.49 httpd
23673 apache    15   0 25496  16m  10m S  0.3  1.7   0:01.17 httpd
24758 apache    15   0 25352  16m  10m S  0.3  1.6   0:00.12 httpd
24836 root      16   0  7256 2208 1784 S  0.3  0.2   0:00.03 sshd
24884 root      16   0  2632  964  748 R  0.3  0.1   0:00.02 top
    1 root      16   0  2620  460  428 S  0.0  0.0   0:17.36 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:04.38 ksoftirqd/0
    3 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 events/0
    4 root       8 -10     0    0    0 S  0.0  0.0   0:00.00 khelper
    5 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 kacpid
   19 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
   29 root      15   0     0    0    0 S  0.0  0.0  10:06.37 pdflush
   30 root      15   0     0    0    0 S  0.0  0.0  10:45.52 pdflush
   32 root      14 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
   20 root      15   0     0    0    0 S  0.0  0.0   0:00.00 khubd
   31 root      15   0     0    0    0 S  0.0  0.0   6:17.04 kswapd0
  106 root      25   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
  188 root      15   0     0    0    0 S  0.0  0.0   0:37.82 md3_raid1
  190 root      15   0     0    0    0 S  0.0  0.0   0:00.08 md1_raid1
  192 root      15   0     0    0    0 S  0.0  0.0   1:21.37 md2_raid1
  193 root      15   0     0    0    0 S  0.0  0.0   0:00.01 md0_raid1
  194 root      15   0     0    0    0 S  0.0  0.0  27:55.75 kjournald
 1043 root       6 -10  1692  356  352 S  0.0  0.0   0:00.00 udevd
 1317 root      15   0     0    0    0 S  0.0  0.0  12:12.29 kjournald
 1822 root      15   0  3388  564  476 S  0.0  0.1   6:48.80 syslogd
 1826 root      16   0  2848  436  384 S  0.0  0.0   0:00.00 klogd
 1852 rpc       16   0  3096  548  492 S  0.0  0.1   0:00.00 portmap
 1871 rpcuser   15   0  3012  676  596 S  0.0  0.1   0:00.00 rpc.statd
 1882 root      16   0  2736  436  384 S  0.0  0.0   0:03.19 mdadm
 1911 root      16   0  5360  820  788 S  0.0  0.1   0:02.23 rpc.idmapd
 1978 root      15   0  2480  612  460 S  0.0  0.1   0:08.91 smartd
 1987 root      20   0  3256  412  408 S  0.0  0.0   0:00.00 acpid
 2072 root      15   0  2540  728  648 S  0.0  0.1   0:16.91 xinetd
 2081 root      16   0  1704  280  216 S  0.0  0.0   0:07.56 da-popb4smtp
 2114 root      16   0  2428  448  424 S  0.0  0.0   0:00.00 gpm
 2179 root      16   0  4048  684  628 S  0.0  0.1   0:47.85 crond
 2200 xfs       16   0  4532  616  584 S  0.0  0.1   0:00.02 xfs
 2217 daemon    16   0  2080  564  524 S  0.0  0.1   0:00.11 atd
 2226 dbus      16   0  3244 1000  924 S  0.0  0.1   0:00.09 dbus-daemon-1
 2235 root      16   0  7688 1744  840 S  0.0  0.2   0:42.60 hald
 2375 root      15   0  1932  324  320 S  0.0  0.0   0:00.00 mingetty
 2376 root      19   0  2532  324  320 S  0.0  0.0   0:00.00 mingetty
 2377 root      19   0  1868  324  320 S  0.0  0.0   0:00.00 mingetty
 2378 root      16   0  1652  324  320 S  0.0  0.0   0:00.00 mingetty
 2379 root      15   0  1980  324  320 S  0.0  0.0   0:00.00 mingetty
 2380 root      15   0  2432  324  320 S  0.0  0.0   0:00.00 mingetty
29329 apache    16   0  3772 1164  848 S  0.0  0.1   8:20.76 vi
 7051 nobody    16   0  6304 1068  884 S  0.0  0.1   0:00.40 directadmin
  421 root      16   0  8808 2144 1716 S  0.0  0.2   0:00.00 cupsd
 2426 mail      16   0  8592 1828 1524 S  0.0  0.2   0:00.06 exim
 2502 named     22   0 36272 3048 2208 S  0.0  0.3   0:00.00 named
 2538 ftp       16   0  2532 1236  840 S  0.0  0.1   0:00.00 proftpd

Als ik 'm sorteer op memory of cpu gebruik (dacht dat dat met SHIFT M/SHIFT P was? correct me if I'm wrong) laat hij weinig bijzonders zien... Geen uitschieters.

[LuCarD]

McKaamos schreef op maandag 05 maart 2007 @ 14:21:
[...]

op de console van Linux gewoon "top" intikken.
Ik neem aan dat je shell access hebt, dus dan zou je met PuTTY even in kunnen loggen en dan "top" intikken. Dan kopieer je de tekst even in een [ code] \[/ code] blok hier op het forum.

Als je geen shell access hebt maar wel FTP en PHP. Dan zou je dit nog kunnen installeren.
http://phpsysinfo.sourceforge.net/

En dan even kijken naar de Load Averages en Memory Usage

code:

29329 apache    16   0  3772 1164  848 S  0.0  0.1   8:20.76 vi

Ben geen *NIX expert, maar zie ik het nu goed. Draait de apache user vi?

[ Voor 13% gewijzigd door LuCarD op 05-03-2007 14:26 ]

[McKaamos]

LuCarD schreef op maandag 05 maart 2007 @ 14:24:
[...]


Als je geen shell access hebt maar wel FTP en PHP. Dan zou je dit nog kunnen installeren.
http://phpsysinfo.sourceforge.net/

En dan even kijken naar de Load Averages en Memory Usage

code:

29329 apache    16   0  3772 1164  848 S  0.0  0.1   8:20.76 vi

Ben geen *NIX expert, maar zie ik het nu goed. Draait de apache user vi?

Ziet er inderdaad raar uit...
Bovenste apache user met httpd heeft een load van 2.7, veel meer als de andere 2 die er onder staan. Ik ben helaas niet zo erg thuis in wat nou nette load is, maar dat getal is hoog vergeleken met de rest... misschien dat daar iets niet klopt? Zou kunnen verklaren dat de webserver zo traag is iig.

[BartB.]

Ben geen *NIX expert, maar zie ik het nu goed. Draait de apache user vi?

Vreemd inderdaad; was mij niet opgevallen... Heb dat proces nu gekilld in ieder geval, maar dit lijkt me niet echt de veroorzaker van het probleem, of is dat wel mogelijk?

Bovenste apache user met httpd heeft een load van 2.7, veel meer als de andere 2 die er onder staan.

Die 2.7 is van de CPU usage... Zie daar wel vaker dat soort loads, vaak maar voor 1 sec, waarna ie weer verdwijnt. (of bedoelde je dit niet?)

[BartB.]

Inmiddels de server gereboot in de hoop dat dat nog wel zou helpen, maar ook dat heeft helaas niets opgeleverd...

Ik heb geen idee waar het nog aan zou kunnen liggen. Ik zie geen extreem veel verbruikende processen, in ons dataverbruik zijn geen hoge pieken te zien (integendeel)... Kortom niets wat erop wijst dat de site zo ontzettend traag zou moeten zijn.

Zou 't te maken kunnen hebben met bijvoorbeeld een bot-aanval of iets in die richting? Al lijkt het me dat ik dan toch op z'n minst een grote piek in het datagebruik zou moeten zien.

[McKaamos]

BartB. schreef op maandag 05 maart 2007 @ 14:34:
[...]

Vreemd inderdaad; was mij niet opgevallen... Heb dat proces nu gekilld in ieder geval, maar dit lijkt me niet echt de veroorzaker van het probleem, of is dat wel mogelijk?


[...]
Die 2.7 is van de CPU usage... Zie daar wel vaker dat soort loads, vaak maar voor 1 sec, waarna ie weer verdwijnt. (of bedoelde je dit niet?)

Als die 2.7 blijft staan klopt het niet voor zover ik weet.

Trouwens, kan je op afstand zien of je RAID array goed is? In je proceslijst zie ik nl dat er raid tools draaien.
Een degraded RAID array kan ook veel snelheid kosten namelijk. (afhankelijk van het RAIDlevel)

[fre0n]

Laat een 'netstat -pla' nog iets bijzonders zien misschien?

In welk netwerk staat de server?

[ Voor 23% gewijzigd door fre0n op 05-03-2007 15:56 ]

[CyBeR]

LuCarD schreef op maandag 05 maart 2007 @ 14:24:
[...]

code:

29329 apache    16   0  3772 1164  848 S  0.0  0.1   8:20.76 vi

Ben geen *NIX expert, maar zie ik het nu goed. Draait de apache user vi?

Dat is idd verdacht. Kijk eens in je /tmp dir of je niet wat leuke files hebt. Veel haxx0r scriptkiddies vermommen hun spullen als standaard commando's zoals vi.

Check ook even de executable path van dat proces:

code:

ls -l /proc/29329/exe

Voorbeeld:

code:

marco@mailsrv01:~$ ls /proc/$$/exe -l
lrwxrwxrwx 1 marco marco 0 2007-03-05 15:59 /proc/17800/exe -> /bin/bash

[BartB.]

Als die 2.7 blijft staan klopt het niet voor zover ik weet.

Nee, ze verdwijnen altijd na een seconde weer, dus daar ligt het probleem niet.

Trouwens, kan je op afstand zien of je RAID array goed is? In je proceslijst zie ik nl dat er raid tools draaien.
Een degraded RAID array kan ook veel snelheid kosten namelijk. (afhankelijk van het RAIDlevel)

Poeh... Voor zover ik weet kan ik dat niet op afstand zien. Gaat dus lastig worden om dat zelf te controleren.

Laat een 'netstat -pla' nog iets bijzonders zien misschien?

In welk netwerk staat de server?

Eerlijk gezegd heb ik geen enkel idee waar ik op moet letten als ik netstat -pla uitvoer; zou ik je anders het resultaat hiervan even kunnen PM-en of iets dergelijks?


Edit: CyBeR, dat proces had ik (op aanraden van weer iemand anders) gekilld en op dit moment is er geen apacheuser meer die vi draait...

[ Voor 8% gewijzigd door BartB. op 05-03-2007 16:31 ]

[CyBeR]

BartB. schreef op maandag 05 maart 2007 @ 16:25:
[...]
Poeh... Voor zover ik weet kan ik dat niet op afstand zien. Gaat dus lastig worden om dat zelf te controleren.

man mdadm

Edit: CyBeR, dat proces had ik (op aanraden van weer iemand anders) gekilld en op dit moment is er geen apacheuser meer die vi draait...

Oef, verdachte dingen moet je nooit kilen voor je weet wat 't is. Nu dat proces weg is kun je namelijk niet meer zien wat 't was.

[ Voor 37% gewijzigd door CyBeR op 05-03-2007 16:32 ]

[tijntjethf]

Probeer anders eens een speedtestje, door eerst met wget ergens een 100mb.bin ofzo weg te trekken, en daarna hem weer naar je pc te downloaden.. kijken of dat wel snel gaat..

[BartB.]

Oef, verdachte dingen moet je nooit kilen voor je weet wat 't is. Nu dat proces weg is kun je namelijk niet meer zien wat 't was.

Dat besef ik me nu ook ja... Maar daar is 't nu te laat voor.

Volgende keer beter dan maar, als ie nog terugkomt tenminste.

@tijntjethf: dat heb ik al geprobeerd... Heb een bestand van ongeveer 10 MB proberen te downloaden, en daarbij haalde ik mijn maximale snelheid. (oftewel 1 mb per sec, aangezien mijn verbinding thuis niet sneller gaat dan dat)

[DukeBox]

Draait er een database op ? Zo ja, kun je daar es een integrety check op draaien ?

[fre0n]

netstat -pla geeft alle actieve verbindingen weer die je server heeft en alle services met netwerktoegang. Wellicht staan hier verdachte zaken in. Dump daarvan is dus waardevol in dit geval.

[ Voor 30% gewijzigd door fre0n op 05-03-2007 16:47 ]

[LuCarD]

Aan de hand van welke log files bepaal jij de dataverbruik? Zijn dat lokale logfiles?

Als je bezoek hebt gehad van een haxxor dan kunnen deze gemakkelijk vervalst worden.

Misschien is het verstandig om te kijken of er niet een rootkit is geinstalleerd., vroeger had je daar een mooie tool voor chkrootkit of zo iets.... ( ik doe al bijna een 3 jaar niks meer met *nix, dus mijn kennis is een beetje outdated )

[fre0n]

RKhunter is een leuke scanner hiervoor. Gratis te halen op www.rootkit.nl

[BartB.]

Draait er een database op ? Zo ja, kun je daar es een integrety check op draaien ?

Er draaien 3 MySQL databases op... Zou graag checken of daar iets mee aan de hand is, maar ook hier heb ik weer geen idee over hoe ik dat aan zou moeten pakken. Overigens worden alle SQL-queries op welke pagina dan ook uitgevoerd in hooguit 0,1 seconde... Mocht er een probleem met de database zijn, lijkt het me dat dit getal veel hoger uit zou komen.

Aan de hand van welke log files bepaal jij de dataverbruik? Zijn dat lokale logfiles?

Via een 'self service center' van LeaseWeb is het dataverbruik te checken, deze zijn betrouwbaar. Ik zit deze op moment van schrijven nog eens te bekijken trouwens, en zie nu ineens wél een flinke piek in het verbruik. Ik vermoed nu dus dat m'n website gewoon het doelwit is van een bot-aanval. Zal zometeen even een screenshot posten van 't grafiekje.

[ Voor 11% gewijzigd door BartB. op 05-03-2007 16:56 ]

[EnigmA-X]

Lijkt er idd op dat je last hebt van wat spul dat niet op je server thuis hoort. Het kan vrij eindeloos worden om dit via een forum te bespreken, er zijn zo'n beetje 1001 mogelijkheden én oplossingen.

Mijn advies: regel iemand die het voor een kratje bier voor je fixt (of op zijn minst er naar kijkt om te bekijken hoe serieus je probleem is). Als je er zelf niet zo heel veel verstand van hebt kan zoiets best lang duren...

[DukeBox]

BartB. schreef op maandag 05 maart 2007 @ 16:55:
[...]
Er draaien 3 MySQL databases op... Zou graag checken of daar iets mee aan de hand is, maar ook hier heb ik weer geen idee over hoe ik dat aan zou moeten pakken. Overigens worden alle SQL-queries op welke pagina dan ook uitgevoerd in hooguit 0,1 seconde... Mocht er een probleem met de database zijn, lijkt het me dat dit getal veel hoger uit zou komen.

Makkelijkste is phpmyadmin, maar ook via de console kun je de check commando's geven. Meestal is 'per' table het makkelijkste, minder impact en je weet dan waar (welke table) het evt. probleem zit.
Een corrpute index wil ook wel je website extreem traag maken.

Overigens, heb je ook statische websites ? zo ja.. zijn die ook traag ?

Wat betreft je dataverkeer,
Anders gebruik je ethereas om te kijken WAT voor verkeer er binnen/uit komt. D

[BartB.]

Overigens, heb je ook statische websites ? zo ja.. zijn die ook traag ?

Statische pagina's laden net zo sloom, dus blijkbaar ligt het niet aan de database(s)...

Grafiekje van dataverbruik van de afgelopen week. (hoop dat de afbeelding het hier doet, hij is gehost op imageshack)




Vreemd is dus dat er rond zondag een gigantische piek is te zien, terwijl de problemen zich sinds vrijdagavond voordoen. Hoe dan ook is de piek bij zondag natuurlijk ook niet gezond...

[BartB.]

Hierbij nog het resultaat van netstat -pla waar fre0n om vroeg.

code:

<knip>

[ Voor 97% gewijzigd door BartB. op 05-03-2007 19:39 ]

[BartB.]

Ahh het probleem is gevonden.

Erg raar, maar het lag aan een .htaccess in de root van onze server. Via deze .htaccess hebben we een kleine twee weken geleden een host uit Saudi-Arabië geblokkeerd die werd gebruikt door een spambot die teveel verkeer genereerde, maar dit leverde nu dus problemen op.

Vreemd is wel dat de eerste problemen pas ruim een week na die blokkering optraden, maar na zojuist verschillende tests uitgevoerd te hebben is het wel duidelijk dat het hieraan lag.

Iedereen die in dit topic gereageerd heeft ontzettend bedankt voor het meedenken!

[LuCarD]

Gewoon uitnieuwsgierigheid, wat stond er dan in de .htaccess dat het systeem zo traag maakte?

[Nimoleda]

LuCarD schreef op dinsdag 06 maart 2007 @ 09:06:
Gewoon uitnieuwsgierigheid, wat stond er dan in de .htaccess dat het systeem zo traag maakte?

*Aj is ook nieuwsgierig

[BartB.]

't Was één regeltje dat problemen opleverde:

deny from .jed.isu.net.sa

Niet meer, niet minder. Op zich lijkt me hier niets mis mee, maar toch... mét bovenstaande regel erin is de site weer niet vooruit te branden, terwijl hij het zonder prima doet.

[CyBeR]

Ik gok zomaar dat dat komt door DNS lookups.

[Coach4All]

yep, deny werkt meestal alleen lekker met ipnummers / ipblokken.

[LuCarD]

BartB. schreef op dinsdag 06 maart 2007 @ 14:18:
't Was één regeltje dat problemen opleverde:

deny from .jed.isu.net.sa

Niet meer, niet minder. Op zich lijkt me hier niets mis mee, maar toch... mét bovenstaande regel erin is de site weer niet vooruit te branden, terwijl hij het zonder prima doet.

hhhmmm dat is een bekende open proxy

[BartB.]

Coach4All schreef op dinsdag 06 maart 2007 @ 14:29:
yep, deny werkt meestal alleen lekker met ipnummers / ipblokken.

Probleem is dus dat er niet echt één bepaald IP te blokkeren valt... Als dat zou kunnen had ik natuurlijk voor die optie gekozen.

Maar goed, die regel is er nu uit en het loopt weer lekker. Dat beetje extra dataverkeer per maand neem ik dan maar voor lief.

[McKaamos]

BartB. schreef op dinsdag 06 maart 2007 @ 17:22:
[...]

Probleem is dus dat er niet echt één bepaald IP te blokkeren valt... Als dat zou kunnen had ik natuurlijk voor die optie gekozen.

Maar goed, die regel is er nu uit en het loopt weer lekker. Dat beetje extra dataverkeer per maand neem ik dan maar voor lief.

ja of je traced het IP even terug en zet dat IP op deny in je htaccess....
Ik zie niet in waarom 1 specifiek IP niet te blocken is... het is maar 1 host, toch?

[ Voor 8% gewijzigd door McKaamos op 06-03-2007 23:29 ]

[Verwijderd]

De laatste tijd heb ik ook dit soort probleem gaande op beide websites, die ik host. Bij m'n vorige host was het namelijk zo dat deze "timeouts" veroorzaakt waren door andere users die dan via MySql de server goed belaste, dat is ook de reden waarom ik verhuisd ben.

De afgelopen dag, is er niets anders dan een rare storing. Alle output van de server slaat erg hoog maar er kan niet achterhaald worden waarom. Ik denk dat ik met 50.000 hits aan 3 dagen opzich niet al te hoog lig. Ook zou het gebruik van 2 fora's , niets mogen uitmaken met de load van de machine.

Ik zag dat je wel toegang had tot SSH, dus ik neem aan dat het hier gaat om een Dedicated bak. Is dit overigens alleen met je eigen site?

[McKaamos]

"twee fora" of "twee forums"
Niet "twee fora's"

[BartB.]

McKaamos schreef op dinsdag 06 maart 2007 @ 23:29:
[...]

ja of je traced het IP even terug en zet dat IP op deny in je htaccess....
Ik zie niet in waarom 1 specifiek IP niet te blocken is... het is maar 1 host, toch?

Een kleine greep uit de hosts die ik terugvind in m'n statistieken van vorige maand:

cache1-2.jed.isu.net.sa
cache3-2.jed.isu.net.sa
cache2-2.jed.isu.net.sa
cache9-1.jed.isu.net.sa
cache10-1.jed.isu.net.sa

Lijkt me dus niet dat er één bepaald IP-adres te blokkeren valt... Of ik blijf telkens aan het blokkeren natuurlijk. Bovendien gaat het hier om een spambot die het comment-gedeelte van onze nieuwsdienst volspamde onder telkens andere IP-adressen. (dat spamprobleem is mbv een captcha code overigens al opgelost, maar dat weerhoudt de bot er natuurlijk niet van om alsnog extreem vaak de site te bezoeken en daarmee extra verkeer te genereren)

[Verwijderd]

Is bannen op hostname niet iets voor jou

[Verwijderd]

code:

fabio@acetyl ~ $ host cache1-2.jed.isu.net.sa
cache1-2.jed.isu.net.sa has address 212.138.64.171
fabio@acetyl ~ $ host cache3-2.jed.isu.net.sa
cache3-2.jed.isu.net.sa has address 212.138.64.173

Weet niet hoor, maar al die hosts vallen in 1 IP range, die je gewoon helemaal kan bannen.
Zie RIPE:
inetnum: 212.138.64.0 - 212.138.70.255
netname: ISU-6
descr: Internet Service Unit ISU
country: SA

[soulrider]

Verwijderd schreef op woensdag 07 maart 2007 @ 14:52:

code:

fabio@acetyl ~ $ host cache1-2.jed.isu.net.sa
cache1-2.jed.isu.net.sa has address 212.138.64.171
fabio@acetyl ~ $ host cache3-2.jed.isu.net.sa
cache3-2.jed.isu.net.sa has address 212.138.64.173

Weet niet hoor, maar al die hosts vallen in 1 IP range, die je gewoon helemaal kan bannen.
Zie RIPE:
inetnum: 212.138.64.0 - 212.138.70.255
netname: ISU-6
descr: Internet Service Unit ISU
country: SA

regeltje:
deny from 212.138.64.*

en ze blijven wrs weg
(met nog een paar anderen uit de netwerk, maar ik vermoed dat ze de enigsten daarvan zijn)

[McKaamos]

Verwijderd schreef op woensdag 07 maart 2007 @ 14:45:
Is bannen op hostname niet iets voor jou

Dat deedtie dus, en dat wordt rete traag vanwege de DNS lookups.

[Verwijderd]

McKaamos schreef op woensdag 07 maart 2007 @ 17:36:
[...]

Dat deedtie dus, en dat wordt rete traag vanwege de DNS lookups.

Ah thanks voor uitleggen

[McKaamos]

Verwijderd schreef op woensdag 07 maart 2007 @ 17:44:
[...]


Ah thanks voor uitleggen

you're welcome

[BartB.]

soulrider schreef op woensdag 07 maart 2007 @ 16:41:
[...]


regeltje:
deny from 212.138.64.*

en ze blijven wrs weg
(met nog een paar anderen uit de netwerk, maar ik vermoed dat ze de enigsten daarvan zijn)

Dat zou inderdaad moeten helpen.

En ach, die paar verdwaalde Saudi-Arabiërs die nu ook onbedoeld geblokkeerd worden moeten maar op zoek gaan naar een andere provider.

Nogmaals thanks voor alle reacties iedereen.