von heise.de:
Quote2. Update: Die Entdecker weisen darauf hin, dass der Patch die Lücke keineswegs schließt; die eingefügten Sicherheitsvorkehrungen ließen sich einfach umgehen. Den besten Schutz bietet derzeit der Einsatz von Filterregeln
von heise.de:
Quote2. Update: Die Entdecker weisen darauf hin, dass der Patch die Lücke keineswegs schließt; die eingefügten Sicherheitsvorkehrungen ließen sich einfach umgehen. Den besten Schutz bietet derzeit der Einsatz von Filterregeln
Falls es um den Volkserver1000 geht, kann ich dir die zusenden sobald ich wieder zuhause bin. Habs mir abgespeichert, da ich schon öfter die Erfahrung gemacht hab, dass die später nicht mehr einsehbar sind
Bei mir steht da auch nicht mehr wenn ich mysql neustarte. Liegt evtl am Loglevel.
Wenn keine Fehlermeldungen auftauchen und du danach zur Datenbank verbinden kannst, ist alles in Ordnung.
Danke für die Antwort. An den Support habe ich mich zeitgleich zur Erstellung dieses Threads schon gewendet, aber noch keine Antwort erhalten.
Im Moment sind die Probleme ohnehin auch wieder deutlich zurückgegangen, allerdings wechselte das schon die ganzen letzten Tage zwischen "alles bestens" und "fast nichts geht mehr", daher bin ich da nicht allzu optimistisch.
Der Server Load ist übrigens minimal, und viel Traffic bekommt der Server auch nicht. Die Probleme müssten also eigentlich mindestens den Host betreffen und nicht nur meinen Vserver. Ein Neustart ändert an der Situation auch nichts.
Edit: Jetzt ist eine Antwort da. Mein Server wurde auf einen Node für traffic-intensive vServer verschoben. Der Rest ist dann wohl in der Tat mit dem Support zu klären.
Hallo,
laut Statusseite http://www.netcup-status.de/ gab es ja vor ein paar Tagen einen DDOS Angriff; das Problem soll aber gelöst sein.
QuoteStatus
wurde behoben
Der Ausfall wurde erfolgreich behoben. Bei Fragen wenden Sie sich bitte an unseren Support
Aktuell liegt eine Störung am gw01 vor. Dadurch kommt es zu Paketverlusten im gesamten Netzwerk.
Das Problem ist bekannt und wir arbeiten auf Hochtouren an der Problembeseitigung.
Update: Das Problem war ein eingehender DDoS-Angriff. Wir konnten den Angriff abwehren.
Leider ist die Situation seitdem nicht viel besser geworden. Die Verbindung ist sehr langsam, oft kommt es auch zu Verbindungsabbrüchen. Das melden sowohl die Nutzer meiner Seiten, als auch externe Monitoringdienste; zudem merkt man es auch daran, dass meine Datenbankreplikation auf einen externen Server alle paar Minuten bis Stunden abbricht.
QuoteDisplay Moretalion@td:~$ traceroute caldron.de
traceroute to caldron.de (78.46.117.60), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.739 ms 1.137 ms 1.494 ms
2 rdsl-wprt-de01.nw.mediaways.net (213.20.58.3) 20.463 ms 23.191 ms 25.568 ms
3 xmws-wprt-de02-chan-18.nw.mediaways.net (62.53.159.246) 28.725 ms 31.142 ms 34.111 ms
4 rmwc-essn-de02-gigaet-4-0-0.nw.mediaways.net (195.71.252.69) 38.445 ms 40.678 ms 59.525 ms
5 rmwc-dsdf-de02-xe-1-0-3-0.nw.mediaways.net (195.71.212.229) 65.364 ms 65.914 ms 66.097 ms
6 rmwc-dsdf-de01-xe-1-1-0-0.nw.mediaways.net (195.71.242.209) 66.269 ms rmwc-dsdf-de01-chan-1-0.nw.mediaways.net (62.53.190.97) 25.807 ms 39.397 ms
7 rmwc-frnk-de01-chan-3-0.nw.mediaways.net (195.71.254.145) 39.695 ms 39.896 ms 40.071 ms
8 xmws-frnk-de07-chan-0.nw.mediaways.net (213.20.249.202) 40.404 ms 41.220 ms 44.381 ms
9 decix-gw.hetzner.de (80.81.192.164) 49.822 ms 54.214 ms 58.355 ms
10 hos-bb1.juniper1.rz6.hetzner.de (213.239.240.238) 68.955 ms 71.447 ms 74.593 ms
11 gw01-hetzner.netcup.net (78.47.244.254) 76.993 ms 79.406 ms 49.609 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
talion@td:~$ ping caldron.de
PING caldron.de (78.46.117.60) 56(84) bytes of data.
64 bytes from caldron.de (78.46.117.60): icmp_seq=2 ttl=54 time=11888 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=3 ttl=54 time=11554 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=4 ttl=54 time=11799 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=5 ttl=54 time=11419 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=6 ttl=54 time=11702 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=7 ttl=54 time=11932 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=8 ttl=54 time=11595 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=9 ttl=54 time=11878 ms
64 bytes from caldron.de (78.46.117.60): icmp_seq=10 ttl=54 time=11466 ms
[...]
64 bytes from caldron.de (78.46.117.60): icmp_seq=126 ttl=54 time=11610 ms
^C
--- caldron.de ping statistics ---
137 packets transmitted, 125 received, 8% packet loss, time 146559ms
rtt min/avg/max/mdev = 680.540/10844.554/12223.821/2282.216 ms, pipe 13
Pings auf meine nicht-Netcup-Server Antworten schnell (ca. 30ms), daher würde ich behaupten, dass es nicht an meiner Verbindung liegt. Die Ergebnisse bestätigen sich, wenn ich traceroute von externen Diensten wie von http://www.traceroute.org ausführe.
Geht es auch anderen Nutzern so? Kann jemand von Netcup die Probleme bestätigen und sagen, ob bereits etwas daran getan wird? Das geht jetzt schon seit Tagen so.
Freundliche Grüße,
Hannes
Das ist kein Fehler oder Problem, sondern nur ein Standard-Check. Ein Problem gab es nur, falls danach Meldungen dieser Art auftauchen: "Table 'xyz' is marked as crashed and should be repaired"
Seit kurzem kann man Backups von einem Vserver auch auf einem anderen Vserver wieder herstellen. Ich habs noch nicht getestet und weiß auch nicht, wie sich das verhält, wenn z.b. die Festplatten unterschiedlich groß sind, aber prinzipiell wär vermutlich auch eine Möglichkeit für dich.
Die API Beschreibung ist unter Netcup VCP Webservice – netcup Wiki erklärt
Da gibts einen Typo: "ESTABLISGED" FilterObject.
Schön fände ich noch, wenn man Firewallregeln direkt auf mehreren vServern anlegen/löschen könnte, soll heißen addFirewallRule und Co. müssten vserverName[] akzeptieren. Geht natürlich auch so, aber würde API-calls sparen.
QuoteFirewall: Kommentare für Firewallregeln sind nun möglich
Sehe ich das richtig, dass man den Kommentar nicht über die API angeben kann? Das wäre hilfreich, denke ich.
Edit: Wenn ich im VCP Regeln zur Firewall hinzufüge, wird die Firewall-Tabelle doppelt angezeigt statt ersetzt. Das war bisher glaub ich nicht so
Edit2: Ich stelle gerade fest, dass das nur gilt, wenn man port range falsch angibt, nämlich mit x-y statt x:y
Edit3: Ich hab den Button zum Löschen einer Regel im VCP erst etwas suchen müssen, bis ich festgestellt hab, dass man, um eine deaktivierte Regel zu löschen, erst auf "Aktivieren", dann auf "Deaktivieren", dann auf "Löschen" klicken muss, weil der Button zwischen diesen Zuständen toggelt. Ist das so gedacht? Ein zusätzlicher Button wäre praktischer.
"Solche Sachen" ist unter anderem alles, was mit Direktzugriff aufs net interface zu tun hat. Daher kannst du weder sowas wie snort oder tcpdump/wireshark nutzen, noch iptables (nur über VCP) oder routing angelegenheiten.
Weitere Einschränkungen gibts z.b. beim Setzen von Prozessprioritäten oder Zugriff auf die systemclock.
Ich verwende ossec, ein sehr flexibel konfigurierbares IDS, das vorwiegend Logs analysiert und auf Probleme/Angriffe auch aktiv reagieren kann (und denyhosts gut ersetzen kann).
Sowas würd ich dem Support direkt schreiben bzw. anrufen, da ist das Kundenforum nicht so der richtige Ort.
Edit: Zu langsam. Wenn du kein lokales Backup hast, hast du vielleicht eins übers VCP gemacht? Das könntest du selbst herstellen ohne den Support zu brauchen.
Hallo,
kann mir jemand folgenden Graph deuten?
CPU-Nutzung laut /proc/stat auf vServer Neptun
cpu-month.png
Ich habe dort kein Performanceproblem, bin aber irritiert, weil sich die CPU-Nutzung seit anderthalb Wochen nicht mehr auf 100% (bzw. 2400% bei 24 CPUs) addiert. Wenn die CPU weder idle ist, noch im Kernel oder User mode arbeitet oder auf irgendwas wartet, was tut sie dann? Und vor allem, warum erst seit kurzem? So ein Bild hab ich auf keinem anderen vserver, und vorher wars auch bei diesem nicht so.
Handelt es sich dabei evtl um die steal time der Virtualisierung, die in der 8. Spalte von /proc/stat stehen könnte, aber immer 0 ist?
Grüße,
Hannes
Versuchs evtl mal in einem Cyrus-Supportforum/mailingliste, irgendwas in der Art wirds wohl geben.
Oder nimm dovecot statt cyrus, dann könnte ich dir vielleicht helfen
Könnte eine .htaccess mit nicht erlaubten Kommandos oder so sein
Inodes waren auch noch reichlich frei.
Ich werds einfach mal weiter beobachten. Davor lief der Server fast 2 Jahre ohne Probleme
Danke für den Hinweis. Laut Monitoring ist immer reichlich RAM (und der komplette swap) frei gewesen. Zudem müsste der OOM-killer eigentlich erst diverse andere Kandidaten killen, bevor er sich sowas wie rsyslogd vornimmt.
Hallo,
hat jemand eine Idee, woran es liegen kann, wenn rsyslog auf einmal nicht mehr funktioniert?
Mir ist gegen 11 Uhr aufgefallen, dass die letzte syslog-Meldung (egal ob /var/log/syslog oder messages oder mail.log oder ...) um kurz vor 10 Uhr war, also eine Stunde lang nichts passiert. Ein Test mit logger bestätigte, dass das nicht mit rechten Dingen zuging. Leider habe ich neugestartet ohne vorher zu prüfen, ob der rsyslog Prozess überhaupt noch lief. Jetzt läuft es wieder problemlos, aber sowas sollte ja nicht nochmal passieren - kennt jemand das Problem?
Es gab keine Fehlermeldung, sondern einfach nur keinerlei Meldungen mehr. Es waren zu jedem Zeitpunkt noch einige GB Speicher frei. Der Logrotate cron war schon gegen 1 Uhr gelaufen, logrotate dürfte damit also nichts zu tun haben. An der Debian Squeeze Standardkonfiguration für rsyslog habe ich nichts verändert. Google hat mir bisher keine brauchbare Erklärung geliefert.
rsyslogd 4.6.4, compiled with:
FEATURE_REGEXP: Yes
FEATURE_LARGEFILE: Yes
FEATURE_NETZIP (message compression): Yes
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
Atomic operations supported: Yes
Runtime Instrumentation (slow code): No
Danke schonmal.
Grüße,
Hannes
Wenn ich das eintrage, erhalte ich folgende Fehler:
QuoteDisplay More
Get:1 http://debian.netcup.net squeeze Release.gpg [1,672 B]
Ign http://debian.netcup.net/debian/ squeeze/contrib Translation-en
Ign http://debian.netcup.net/debian/ squeeze/contrib Translation-en_US
Ign http://debian.netcup.net/debian/ squeeze/main Translation-en
Ign http://debian.netcup.net/debian/ squeeze/main Translation-en_US
Ign http://debian.netcup.net/debian/ squeeze/non-free Translation-en
Ign http://debian.netcup.net/debian/ squeeze/non-free Translation-en_US
Get:2 http://debian.netcup.net squeeze-updates Release.gpg [836 B]
Ign http://debian.netcup.net/debian/ squeeze-updates/contrib Translation-en
Ign http://debian.netcup.net/debian/ squeeze-updates/contrib Translation-en_US
Hit http://security.debian.org squeeze/updates Release.gpg
Ign http://security.debian.org/ squeeze/updates/contrib Translation-en
Ign http://security.debian.org/ squeeze/updates/contrib Translation-en_US
Ign http://security.debian.org/ squeeze/updates/main Translation-en
Ign http://security.debian.org/ squeeze/updates/main Translation-en_US
Ign http://security.debian.org/ squeeze/updates/non-free Translation-en
Ign http://security.debian.org/ squeeze/updates/non-free Translation-en_US
Ign http://debian.netcup.net/debian/ squeeze-updates/main Translation-en
Ign http://debian.netcup.net/debian/ squeeze-updates/main Translation-en_US
Ign http://debian.netcup.net/debian/ squeeze-updates/non-free Translation-en
Ign http://debian.netcup.net/debian/ squeeze-updates/non-free Translation-en_US
Hit http://security.debian.org squeeze/updates Release
Get:3 http://debian.netcup.net squeeze-proposed-updates Release.gpg [836 B]
Ign http://debian.netcup.net/debian/ squeeze-proposed-updates/contrib Translation-en
Ign http://debian.netcup.net/debian/ squeeze-proposed-updates/contrib Translation-en_US
Ign http://debian.netcup.net/debian/ squeeze-proposed-updates/main Translation-en
Ign http://debian.netcup.net/debian/ squeeze-proposed-updates/main Translation-en_US
Hit http://security.debian.org squeeze/updates/main i386 Packages
Ign http://debian.netcup.net/debian/ squeeze-proposed-updates/non-free Translation-en
Ign http://debian.netcup.net/debian/ squeeze-proposed-updates/non-free Translation-en_US
Get:4 http://security.debian.org squeeze/updates/contrib i386 Packages [674 B]
Get:5 http://debian.netcup.net squeeze Release [107 kB]
Hit http://security.debian.org squeeze/updates/non-free i386 Packages
Get:6 http://debian.netcup.net squeeze-updates Release [113 kB]
Get:7 http://debian.netcup.net squeeze-proposed-updates Release [128 kB]
Get:8 http://debian.netcup.net squeeze/main Sources [4,541 kB]
Get:9 http://debian.netcup.net squeeze/contrib Sources [40.8 kB]
Get:10 http://debian.netcup.net squeeze/non-free Sources [73.4 kB]
Ign http://debian.netcup.net squeeze/main i386 Packages
Ign http://debian.netcup.net squeeze/contrib i386 Packages
Ign http://debian.netcup.net squeeze/non-free i386 Packages
Ign http://debian.netcup.net squeeze-updates/main i386 Packages
Ign http://debian.netcup.net squeeze-updates/contrib i386 Packages
Ign http://debian.netcup.net squeeze-updates/non-free i386 Packages
Ign http://debian.netcup.net squeeze-proposed-updates/main i386 Packages
Ign http://debian.netcup.net squeeze-proposed-updates/contrib i386 Packages
Ign http://debian.netcup.net squeeze-proposed-updates/non-free i386 Packages
Ign http://debian.netcup.net squeeze/main i386 Packages
Ign http://debian.netcup.net squeeze/contrib i386 Packages
Ign http://debian.netcup.net squeeze/non-free i386 Packages
Ign http://debian.netcup.net squeeze-updates/main i386 Packages
Ign http://debian.netcup.net squeeze-updates/contrib i386 Packages
Ign http://debian.netcup.net squeeze-updates/non-free i386 Packages
Ign http://debian.netcup.net squeeze-proposed-updates/main i386 Packages
Ign http://debian.netcup.net squeeze-proposed-updates/contrib i386 Packages
Ign http://debian.netcup.net squeeze-proposed-updates/non-free i386 Packages
Err http://debian.netcup.net squeeze/main i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze/contrib i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze/non-free i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze-updates/main i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze-updates/contrib i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze-updates/non-free i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze-proposed-updates/main i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze-proposed-updates/contrib i386 Packages
404 Not Found
Err http://debian.netcup.net squeeze-proposed-updates/non-free i386 Packages
404 Not Found
Fetched 5,008 kB in 1s (2,771 kB/s)
W: Failed to fetch http://debian.netcup.net/debia…n/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…b/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…e/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…n/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…b/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…e/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…n/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…b/binary-i386/Packages.gz 404 Not Found
W: Failed to fetch http://debian.netcup.net/debia…e/binary-i386/Packages.gz 404 Not Found
E: Some index files failed to download, they have been ignored, or old ones used instead.
Edit: Das gilt seltsamerweise nur auf dem V(olk)server1000, wohingegen es auf dem vServer Neptun problemlos funktioniert. Woran liegts, hat jemand eine Idee?
Wenn ein Fehler auftritt, sollte der im syslog zu finden sein. Wenn das nicht reicht um das Problem zu lösen, könntest du webalizer mal von Hand starten und nach Fehlermeldungen Ausschau halten.
Ich verstehe nicht so richtig, worauf ihr hier hinaus gehen wollt. Auch wenn man MySQL von Hand stopt und startet wird von MySQL folgende Standard-Meldungen kommen: "Checking for corrupt, not cleanly closed and upgrade needing tables.."
Das darf man nicht als Fehler interpretieren, dass ist nur eine Standard-Aussage von MySQL.
Von der Meldung rede ich nicht, mir gehts um
QuoteJan 24 14:39:26 caldron mysqld: 120124 14:39:26 [ERROR] /usr/sbin/mysqld: Table xyz is marked as crashed and should be repaired
Hallo,
mein Vserver läuft nach dem Neustart wg des Kernelupdates problemlos, nur mysql beschwert sich wieder über crashed tables. Das passiert auch nach einem Neustart/Stop im VCP jedes Mal. Offensichtlich wird mysql dabei brutal gestoppt statt sauber beendet. Ich vermute, dass das einfach daran liegt, dass mysql beim regulären Stoppen eine Weile braucht, bis es wirklich beendet ist. Nach der freundlichen Aufforderung zum Beenden kommt dann vermutlich zu schnell ein 'kill -9'.
Kann man das irgendwie ändern, außer mysql so zu konfigurieren, dass es ständig flusht? Die eigentlich Frage ist vermutlich: Kann man die Wartezeit verlängern, die die VCP-Shutdown-Funktionalität den Prozessen zwischen SIGTERM und KILL lässt?
Grüße,
Hannes