Onderwerp: Dedicated server reageert zeer slecht, traag en soms geen verbinding.

MMai dat klopt normaal staat de testmode standaard aan op 5 minuten.
Voor de zekerheid moet je altijd wel eerst controleren of die daadwerkelijk aanstaat.

Oorspronkelijk geplaatst door Herbert

Als je de root gegevens wilt afstaan dan mail me maar, ik kan wel even kijken dan.

Er werd hier boven gezegd dat je normaal de mensen hier kan vertrouwen, ik wil dat doen, ik wil ZEER GRAAG geholpen worden maar dan wil ik ook eerlijk geholpen worden, dat er geen misbruik wordt gemaakt.


Ik zal jou de gegevens door sturen naar je pm omdat je zo gewoonlijk vraagt dus ik denk wel zeker dat je zeker geen misbruik gaat maken.

Het is aan jezelf, je kan mij vertrouwen.
Je denk toch niet dat ik mijn naam/bedrijf te schande zet hier door misbruik.

Oorspronkelijk geplaatst door Herbert

Het is aan jezelf, je kan mij vertrouwen.
Je denk toch niet dat ik mijn naam/bedrijf te schande zet hier door misbruik.

Het is verzonden.

Hartelijk dank dat je dit wilt doen.

Work = Done

Even een vraagje nog aan iedereen, ik heb nooit met Debian gewerkt.
Hij staat in runlevel 2, runlevel 3 lijkt me toch normaal? linux=linux

Debian 5.0.1

Code:

server7:~# runlevel
N 2

Centos

Code:

[root@server1 ~]# /sbin/runlevel
N 3

Exact. Linux=Linux gaat zeker niet op als je CentOS vergelijkt met Debian.

Dit had ik zelf op kunnen zoeken maar het was al laat gisteren, en dit viel me gewoon op.
Zo leer ik ook ook weer wat.

En wat was het euvel ?

Oorspronkelijk geplaatst door mikeh

En wat was het euvel ?

Op die server is gewoon debian gezet en draaien maar.
Er was totaal niets aan de beveiliging gedaan.
CSF/LFD draait nu en dit houd al veel narigheid tegen.
Over de rest kan ik geen mededeling doen aan derden.
De log files zien er nu goed uit, ik zag geen rare dingen meer.
We horen het wel van de topic starter of er nog verdere problemen zijn.

Er waren toch nog problemen, ik meld ze maar even hier.
Poort 80 is na enkele uren dicht gaan zitten op die server.
In de messages.log staat:

Code:

Jul 15 12:30:28 dediXXX kernel: ip_conntrack: table full, dropping packet.
Jul 15 12:30:33 dediXXX kernel: printk: 9 messages suppressed.
Jul 15 12:30:33 dediXXX kernel: ip_conntrack: table full, dropping packet.

De ip_conntrack table staat vol, ik heb hem al verhoogd naar 65496 maar dat hielp niet.
In de httpd logfile staat:

Code:

::1 - - [15/Jul/2009:12:34:37 +0200] "GET / HTTP/1.0" 302 350 "-" "Apache/2.2.3
(Debian) PHP/5.2.0-8+etch13 (internal dummy connection)"

Verder is er geen ddos of wat ook aan de gang, al het andere draaid als een trein.
De firewall (CSF) is ook goed, poort 80 staat wel degelijk open.
Reboot helpt ook niet..
Ik zat eerst te denken aan antiloris hack, deze mod heb ik ook geinstalleerd maar dat was het ook niet.

Verder heb ik deze outputs nog:

wc -l /proc/net/ip_conntrack
63325 /proc/net/ip_conntrack

en deze:

Code:

dediXXX:/var/log/apache2# sysctl -a | grep conntrack
error: "Success" reading key "dev.parport.parport0.autoprobe3"
error: "Success" reading key "dev.parport.parport0.autoprobe2"
error: "Success" reading key "dev.parport.parport0.autoprobe1"
error: "Success" reading key "dev.parport.parport0.autoprobe0"
error: "Success" reading key "dev.parport.parport0.autoprobe"
error: "Operation not permitted" reading key "net.ipv6.route.flush"
net.ipv4.ip_conntrack_max = 65536
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_loose = 3
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_log_invalid = 0
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120

Wat kan dat zijn?

Ik dank Herbet voor zijn hulp, inderdaad het is gelijk dat Herbet zegt, ik kan geen verbinding krijgen tot de server via http://ip maar wel via WinSCP.


Bedankt Herbert en de andere!

Zoals je ziet is de ip_conntrack module geladen en raken zijn maximale connecties vol, hierdoor werkt poort 80 niet meer.

Je zou met netstat eens kunnen kijken hoe veel connecties er open staan, maar het kan goed dat dit allemaal legitieme connecties zijn.

Een firewall is niet per definitie nodig als alle services goed geconfigureerd zijn, als de machine simpel httpd, ssh, pop3, imap en smtp draait is een firewall niet direct nodig.

Zolang je MySQL dan maar laat binden aan 127.0.0.1 werkt het prima.

Wido ook zonder firewall doet die vreemd, dit had ik al getest.
Nadat ik de hele topic nog een keer gelezen heb bestond dit probleem al langer.
firewall of geen firewall dat maakt niet uit.
Zonder iets te hebben veranderd draait poort 80 nu weer, ook vreemd..

Wat staat er in de httpd error/access log en wat is de output van netstat -a | grep http ?
Heeft die doos overigens ook een hoge load/ dataverbruik ?