Debian webserver niet bereikbaar; hoe oorzaak achterhalen?

[XchangeVisions]

Vandaag tot de ontdekking gekomen dat m'n webserver niet bereikbaar was.
Dit is een VPS met Debian 6.0.6 en Plesk Panel 11.0.9.
In het 'VPS admin panel' van de ISP was de status 'running' en schijnbaar nergens een probleem.
De webserver is in principe alleen via SSH bereikbaar maar Plesk heeft ook root rechten en kan dus ook wijzigingen doorvoeren.

Inmiddels een (harde) herstart uitgevoerd en ik heb al wat in log bestanden zitten speuren.
In de auth/syslog is de laatste entry 'Apr 5 15:39:01' van een reguliere CRON taak.
De server was dus al even offline. Dat ik het nu pas opmerk komt doordat de webserver een hobbyproject is en ik daar dan ook niet elke dag/week mee bezig ben.

Iemand tips/advies naar log bestanden of onderdelen die ik door kan nemen om zo meer details te achterhalen?

Het kan uiteraard een (niet te herleiden) probleem vanuit de hardware geweest zijn wat deze 'vastloper' heeft veroorzaakt, echter van de ISP kan ik geen meldingen terugvinden.

[Room42]

Heeft de server een eigen externe adres, of hangt er nog een firewall tussen? Is er een firewall geconfigureerd op de server?

Luistert er wel een proces op poort 80 of 443 (zie netstat -anp | grep LISTENING)?

[XchangeVisions]

Room42 schreef op maandag 15 april 2013 @ 22:05:
Heeft de server een eigen externe adres, of hangt er nog een firewall tussen? Is er een firewall geconfigureerd op de server?

Luistert er wel een proces op poort 80 of 443 (zie netstat -anp | grep LISTENING)?

De server heeft een eigen adres.
Via Plesk is de firewall ingesteld. (o.a. geen FTP en email)

Na de herstart kon ik via SSH inloggen en is ook de website weer bereikbaar.
Via [netstat -a] wordt zowel naar www als ook https geluisterd.
Met [netstat -anp | grep LISTENING] zie ik geen 80 of 443...


Edit: in het log bestand van Plesk komt met enige regelmaat een 'failed login attempt' naar voren op het controlepaneel. Dit lijkt mij niet heel bijzonder en iets wat elke Plesk gebruiker heeft, het is immers een standaard gebruikersnaam en poortnummer die je voor plesk-panel moet gebruiken.
SSH is niet via een wachtwoord login bereikbaar, FTP staat uit en naast de Plesk gebruiker ben ik de enige gebruiker.

[ Voor 24% gewijzigd door XchangeVisions op 15-04-2013 22:29 ]

[Hero of Time]

Check /var/log/messages, /var/log/syslog, /var/log/kern.log en /var/log/auth.log of secure.log. Daar zal vast wel wat in staan.

[XchangeVisions]

Hero of Time schreef op maandag 15 april 2013 @ 22:43:
Check /var/log/messages, /var/log/syslog, /var/log/kern.log en /var/log/auth.log of secure.log. Daar zal vast wel wat in staan.

Als ik de log bestanden bekijk dan kan ik daar weinig bijzonders terugvinden.

Laatste entry in /syslog:
[ /USR/SBIN/CRON[9439]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete) ]

Deze CRON taak wordt regelmatig uitgevoerd en normaal gesproken na +/- 5 minuten opgevolgd door een volgende taak. Voorafgaand is nog een update van drweb gelogd.

De laatste aanpassing in de kern.log was ergens in februari geweest.

[Room42]

XchangeVisions schreef op maandag 15 april 2013 @ 22:20:
[...]

Met [netstat -anp | grep LISTENING] zie ik geen 80 of 443...

[...]

Sorry, het moest LISTEN zijn

[XchangeVisions]

Room42 schreef op maandag 15 april 2013 @ 23:56:
[...]

Sorry, het moest LISTEN zijn

Aha, vandaar.
Via [netstat -anp | grep LISTEN] is zichtbaar dat zowel naar poort 80 als 443 geluisterd wordt.


Ik ben inmiddels weer wat meer in de materie gedoken.
Er schijnt een reeds opgeloste bug te zijn die een kernel panic kan veroorzaken bij een uptime van 200+ dagen. Dit is van toepassing op Debian x64 met kernel versies voor 2.6.32-45 (Linux 2.6.32-50)
In mijn geval draait Debian met kernel 2.6.32-5-amd64 en was de server 201 dagen online.
Hiermee zou de bug dus een mogelijke oorzaak kunnen zijn.

Voor zover ik weet wordt een kernel-panic alleen op het scherm getoond waarbij ook niks wordt gelogd?
Het lijkt mij dat het systeem immers niets meer kan verwerken, dus ook geen log regel.

Ik ga de zoektocht maar staken zonder dat een duidelijk aanwijsbare reden is achterhaald.
Maar uiteraard ga ik nu wel de kernel upgrade doorvoeren en is dit (voor mij) weer een typisch gevalletje van 'je leert een product pas echt waarderen als je het gaat repareren'.

[degroot]

Mag ik vragen waar je VPS gehost word?
Ik heb nl. zelf al 2x hetzelfde meegemaakt , bij Strato. Na herstart was hij nog steeds neit bereikbaar. Heb toen maar backup terug gezet van dag ervoor.

[XchangeVisions]

degroot schreef op woensdag 17 april 2013 @ 10:07:
Mag ik vragen waar je VPS gehost word?
Ik heb nl. zelf al 2x hetzelfde meegemaakt , bij Strato. Na herstart was hij nog steeds neit bereikbaar. Heb toen maar backup terug gezet van dag ervoor.

De VPS wordt gehost door PC Extreme.
Misschien niet de goedkoopste maar ik zit er al jaren en ben zeer tevreden.

[Thc_Nbl]

Doe eens iptables -nL | egrep "80|443"
Heb je zo iets als dit als output.

iptables -nL | egrep "80|443"
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:443

[Osiris]

Thc_Nbl schreef op vrijdag 19 april 2013 @ 10:31:
Doe eens iptables -nL | egrep "80|443"
Heb je zo iets als dit als output.

iptables -nL | egrep "80|443"
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:443

a) Waarom? Het probleem is immers al 'ontdekt' hoogst waarschijnlijk;
b) Mag hopen dat dat commando niet die output geeft Why for fucks sake UDP-verkeer op poort 80 en 443 accepteren?

[Thc_Nbl]

Die kernel bug, is onzin.. sorry dat ik het zeg, die is allang opgelost in debian, staat los van dit probleem.
Ik heb tientalen debian servers draaien, en heb deze melding nog nooit gezien vandaar nog mijn melding.

De laatste debian kernel is. 2.6.32-48 en niet 2.6.32-50 trouwens.,

en die udp gebruik ik ergens voor, sorry dat had in dit voorbeeld er niet bij gemogen. .. scherp.

[XchangeVisions]

Thc_Nbl schreef op vrijdag 19 april 2013 @ 10:46:
Die kernel bug, is onzin.. sorry dat ik het zeg, die is allang opgelost in debian, staat los van dit probleem.
Ik heb tientalen debian servers draaien, en heb deze melding nog nooit gezien vandaar nog mijn melding.

De laatste debian kernel is. 2.6.32-48 en niet 2.6.32-50 trouwens.,

Voor wat ik van de releases begrijp heeft Debian een afwijkende 'kalender' t.o.v. de releases vanuit de Linux-kernel community. In Linux versie 32-50 is de bug opgelost en die kernel-update is met Debian versie 32-45 ook voor stable uitgerold. De huidige Debian versie is inderdaad 32-48, welke inmiddels ook op de server draait. Maar goed, ik heb er niet voor gestudeerd dus corrigeer me als ik fout zit.

De/een verklaring 'bug' vind ik ook nog steeds lastig om te accepteren, Debian heeft mij nog nooit een (niet aan mijzelf te relateren) kernel-panic gegeven. Maar omdat ik verder niets geen aanwijzingen kan vinden over fouten of problemen is dat (tot nu toe) de enige reden die ik kan verzinnen. De server zat duidelijk in een 'hang-up' of 'freeze', en doordat ik de kernel-panic output niet heb gezien zal ik er waarschijnlijk nooit achterkomen wat de exacte oorzaak is geweest.

Thc_Nbl schreef op vrijdag 19 april 2013 @ 10:31:
Doe eens iptables -nL | egrep "80|443"

De output voor iptables is een stuk 'rijker' aan regels, maar deze zijn allen correct en tevens juist. (Plesk gebruikt standaard nogal wat extra poorten voor bijv. plesk-http(s) en tomcat).
Toch bedankt voor de hint, ik had al in o.a. de apache configuratie bestanden gekeken naar wijzigingen maar in de iptables was ik nog niet geweest.