Hallo,
seit kurzem fügt mein Server bei nicht vorhandenen Domains bzw AAAA-Records die Search-Domain aus der resolv.conf automatisch an.
Dies ist problematisch, da bei Domains, welche nur per IPv4 erreichbar sind, zu meinem Server aufgelöst werden.
Auch ein Entfernen der search-domain aus der resolv.conf hat leider nicht geholfen.
Was kann ich machen, damit wieder unknow-host beim ping6 etc. zurückgegeben wird ?
Ich nutze https://www.ispprotect.de/
Wunder darf man natürlich nicht erwarten.
Es hat aber schon einige Einbrüche bei mir gefunden.
Ich habe seit gestern Nacht das Problem, das mein Server längere Reaktionszeiten hat und stellenweise CPU-Loads > 100.
Im Kernel-Log habe ich folgende Meldungen:
[sched_delayed] sched: RT throttling activated
INFO: rcu_sched self-detected stall on CPU
BUG: soft lockup - CPU#4 stuck for 22s! [php-cgi:27722] - mehrmals mit Unterschiedlichen CPUs / Tasks (mysql, etc.)
Ein Neustart hat kurz geholfen bis wieder die Meldung [sched_delayed] sched: RT throttling activated im Log aufgetaucht ist
Ticket [NC#2017010610002828] ist eröffnet, jedoch noch keine Antwort (wurde nur an die Fachabteilung weitergeleitet)
Die Planungen sind hier noch nicht ganz abgeschlossen. Es soll allerdings eine Version mit Grundgebühr geben, über die die Softwareentwicklung und der Support bezahlt werden. Dafür kosten dann die Domains nur ca. 1,20 Euro / Jahr.
Steht inzwischen fest wie hoch die Grundgebühr sein wird?
Werden die anderen Domains für Reseller dann auch günstiger ?
Und wie sieht es mit einer Laufzeitübernahme aus (bei einigen TLDs bezahle ich beim Transfer für ein Jahr, welches an das alte Expire-Datum bei der NIC angehangen wird)
Danke - Ich habe nur durch Facebook von der SE erfahren und da stand zum Upgrade nichts.
20 Euro ist mir das Upgrade dann doch nicht wert - und bis auf die IO-Leistung reicht der VPS 50 dicke.
Gilt die Aussage immer noch, da ja heute die VPS SE vorgestellt wurde und der VPS 50 nicht mehr auf der Homepage steht ?
Oder wird es auch davon eine Neuauflage geben (eventuell mit Update-Möglichkeit vom alten VPS 50)
Edit: Man sollte auch komplett lesen 
- Bleibt nur noch die Frage nach der Upgrade-Möglichkeit ?
Hallo Felix,
danke für die ausführliche Erklärung.
Bei einer 12 Kern Maschine liegt also das Limit von Steal bei 36%
und damit meine 33% (immer bezogen auf 1200%) im Toleranz Bereich den ich akzeptieren muss ?
Ja, bin ich.
Meiner hat aber auch 12 Kerne 
Hallo,
wieso habe ich eigentlich trotz dedizierte CPU-Kerne Steal-Werte (stellenweise 33%).
Die Kerne gehören mir doch alleine ?!?
Gerade nochmal in die Sperrmail geguckt
Treshold Bandwidth: 175 MBit/s
Sum Bytes: 134.79 GByte/300s (3.59 GBit/s)
Wird hier nicht zu früh gesperrt. Mir stehen doch 5 Gbit/s zur Verfügung ?
Leider nein ...
Guten Tag,
eine IP-Adresse kann nicht geändert werden. Diese ist fest an den Server gebunden.
[...]
Mit freundlichen Grüßen
Felix Preuß
Hallo,
nachdem unser Server bereits am 31.10. um 21:10 unter einem UDP Angriff Stand ging es gerade zum zweiten Mal los.
Wieder ein UDP Angriff:
Direction: IN
Destination IP: xxxx
Treshold Packets: 30000 packets/s
Sum Packets: 107429000 packets/300s (358096 packets/s)
Sum Bytes: 134.79 GByte/300s (3.59 GBit/s)
Src IP Addr:Port Dst IP Addr:Port Proto Packets Bytes
185.39.161.152:53 -> xxx:4444 UDP 750 1.1 M
185.39.161.152:53 -> xxx:4444 UDP 750 1.1 M
46.29.79.59:0 -> xxx:0 UDP 2750 3.8 M
185.171.60.2:0 -> xxx:0 UDP 1000 1.5 M
95.78.232.174:53 -> xxx:4444 UDP 1000 1.5 M
88.135.232.123:0 -> xxx:0 UDP 3250 4.4 M
131.100.248.1:53 -> xxx:4444 UDP 250 375000
.
.
.Nach zwei Minuten ist dann die zweite Mail gekommen, dass der Angriff zu groß geworden ist, und die IP gesperrt wird (obwohl die 5 GBit/s noch nicht erreicht wurden ?)
Sum Bytes: 134.79 GByte/300s (3.59 GBit/s)
Der Server ist erst seit dem 18.10.2016 im Einsatz. Bei alten Anbieter hatten wir nie Schwierigkeiten mit DDoS.
Auf eine Supportanfrage NC#2016110610003168 ob der Angriff eventuell nicht uns gilt, sondern dem Vorbesitzer der IP können wir aus Datenschutzgründen keine Antwort bekommen.
Der Angriff ging beide Male genau 45 Minuten (bzw. die Sperrung)
Welche Möglichkeiten haben wir nun noch ?
Nicht unbedingt: https://www.netcup.de/bestellen/produkt.php?produkt=1360
Ist nur die Frage, ob man hier auch die Best-Price Garantie nutzen kann...
Hallo,
ich hole das Thema nochmal nach oben, da ich das gleiche Problem habe.
Meine /etc/network/interfaces (hier ohne IP-Adressen)
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).auto lo
iface lo inet loopbackauto eth0
iface eth0 inet static
address
netmask 255.255.252.0
broadcast
gatewayiface eth0 inet6 static
address
netmask 64
gateway fe80::1
post-up ip -6 route add default via fe80::1 dev eth0
Nach dem Neustart habe ich jedoch immer noch bei ip -6 route show
default via fe80::1 dev eth0 proto ra metric 1024 expires 1653sec hoplimit 64
Nach dem ip -6 route add default via fe80::1 dev eth0 auf der Console ist alles richtig. Nur ich möchte das gerne automatisch haben.
Hallo,
trotz KVM würde ich sagen, der verlinkte Thread zählt immer noch:
Du hast nur VCores und keine dedizierte Kerne, die nur für dich da sind.
Bei dem normalen Root-Server M SSD v6 (ohne a), würde meine Meinung nach nichts dagegen sprechen.
Hallo,
bitte den Post nicht verkehrt verstehen, weil er sehr kritisch wird. Ich habe dem G6 Server M mit SSD und SLA+ und bin voll damit zufrieden.
Was der EX4 oder auch EX10 nicht beinhaltet ist ein DVD-Laufwerk, eine dauerhafte und kostenlose Remote-Konsole, die Möglichkeit ohne Softwareinstallation Snapshots anzufertigen, diese zu im- oder exportieren usw..
Was brauche ich davon im laufenden Betrieb. Für die Einrichtung mag ja ein DVD Laufwerk praktisch sein, aber wird dann nicht mehr benötigt.
Das gleiche gilt für die Recovery Console. Hilfreich bei der Einrichtung aber wird dann hoffentlich nicht benötigt. Wenn doch ist der Server instabil und das kann ich nicht gebrauchen. Snapshots gehen sowieso nicht, da die Festplatte angeblich zu voll (weil defragmentiert ist).
Dann bieten die neuen Root-Server noch 99,9% garantierte Mindestverfügbarkeit und eine sehr gute Netzanbindung, auch zur Deutschen Telekom.
Gegen der Netzanbindung kann ich nichts sagen. Die war damals (neben den Preis und der guten Kritiken) der Grund zu wechseln. Die 99,9 % habe ich mit 0,99 Aufpreis für SLA+ auch bei meinen Server.
Ich bleibe dabei, die G7 ist ein Rückschritt und Preiserhöhung.
9,99 Euro bei 12 Monaten für einen G6 M mit 150 GB SSD, 8 GB RAM, 2 dedizierte CPU Kerne wäre als G7 würdig. Die SLA 99,9 % kann dann gerne wie jetzt mit 1,99 Euro im Monat berechnet werden.
Wie versprochen, hier ein Benchmark vom RS 8000 in der SSD-Variante:
Entweder lese ich den Benchmark verkehrt oder der RS 8000 ist unterm Strich langsamer als ein EX4 mit Festplatte (inzwischen nicht mehr im Programm) eines Mitbewerbers:
BYTE UNIX Benchmarks (Version 5.1.3)
System: srv1: GNU/Linux
OS: GNU/Linux -- 2.6.32.59-grsec -- #3 SMP Thu May 10 09:17:28 CEST 2012
Machine: x86_64 (unknown)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6824.0 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 5: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 6: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
CPU 7: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
17:21:03 up 427 days, 21:54, 1 user, load average: 1,18, 0,80, 0,59; runlevel 2
------------------------------------------------------------------------
Benchmark Run: Mo Mai 23 2016 17:21:03 - 17:50:34
8 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 43427246.8 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4251.5 MWIPS (11.1 s, 7 samples)
Execl Throughput 3380.1 lps (29.5 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1506357.6 KBps (30.1 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 428914.3 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2913393.0 KBps (30.0 s, 2 samples)
Pipe Throughput 3012926.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 167720.5 lps (10.0 s, 7 samples)
Process Creation 12801.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 6293.0 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 4370.5 lpm (60.0 s, 2 samples)
System Call Overhead 4814086.2 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 43427246.8 3721.3
Double-Precision Whetstone 55.0 4251.5 773.0
Execl Throughput 43.0 3380.1 786.1
File Copy 1024 bufsize 2000 maxblocks 3960.0 1506357.6 3803.9
File Copy 256 bufsize 500 maxblocks 1655.0 428914.3 2591.6
File Copy 4096 bufsize 8000 maxblocks 5800.0 2913393.0 5023.1
Pipe Throughput 12440.0 3012926.4 2422.0
Pipe-based Context Switching 4000.0 167720.5 419.3
Process Creation 126.0 12801.5 1016.0
Shell Scripts (1 concurrent) 42.4 6293.0 1484.2
Shell Scripts (8 concurrent) 6.0 4370.5 7284.2
System Call Overhead 15000.0 4814086.2 3209.4
========
System Benchmarks Index Score 1996.4
------------------------------------------------------------------------
Benchmark Run: Mo Mai 23 2016 17:50:34 - 18:22:17
8 CPUs in system; running 8 parallel copies of tests
Dhrystone 2 using register variables 162830877.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 30802.3 MWIPS (9.9 s, 7 samples)
Execl Throughput 31834.9 lps (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1176153.7 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 340081.3 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 7943310.6 KBps (30.0 s, 2 samples)
Pipe Throughput 12440069.6 lps (10.0 s, 7 samples)
Pipe-based Context Switching 2897152.7 lps (10.0 s, 7 samples)
Process Creation 102977.8 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 39741.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 5421.5 lpm (60.1 s, 2 samples)
System Call Overhead 10649284.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 162830877.4 13952.9
Double-Precision Whetstone 55.0 30802.3 5600.4
Execl Throughput 43.0 31834.9 7403.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 1176153.7 2970.1
File Copy 256 bufsize 500 maxblocks 1655.0 340081.3 2054.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 7943310.6 13695.4
Pipe Throughput 12440.0 12440069.6 10000.1
Pipe-based Context Switching 4000.0 2897152.7 7242.9
Process Creation 126.0 102977.8 8172.8
Shell Scripts (1 concurrent) 42.4 39741.5 9373.0
Shell Scripts (8 concurrent) 6.0 5421.5 9035.8
System Call Overhead 15000.0 10649284.1 7099.5
========
System Benchmarks Index Score 7128.3Bei der Festplatte ist er natürlich langsamer:
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 23934 MB in 2.00 seconds = 11979.33 MB/sec
Timing buffered disk reads: 440 MB in 3.01 seconds = 146.12 MB/sec
hdparm -tT --direct /dev/sda
/dev/sda:
Timing O_DIRECT cached reads: 562 MB in 2.00 seconds = 280.66 MB/sec
Timing O_DIRECT disk reads: 314 MB in 3.01 seconds = 104.33 MB/secVielen Dank. Der Traceroute sieht nun viel besser aus
1 * * *
2 be10-101.gra-g1-a9.fr.eu (2001:41d0::1eb) 0.861 ms 1.082 ms 2.081 ms
3 * * *
4 gw6-decix.ffm.netcup.net (2001:7f8::3:3a4:0:1) 14.554 ms 14.538 ms 14.513 ms
5 (mein Server)
Nur schade, dass mein Ticket scheinbar nicht richtig gelesen wurde 
Hallo,
ich besitze eine kleinen Server beim großen französischen Serveranbieter. Dieser wird als Backup-Server und Monitoring von meinem Netcup-Server genutzt.
Sporadisch bekomme ich von diesem Meldungen, dass mein Netcup-Server über IPv6 nicht erreichbar ist.
Der Traceroute sieht dann wie folgt aus:
1 * * *
2 be10-101.gra-g1-a9.fr.eu (2001:41d0::1eb) 0.702 ms 0.941 ms 1.144 ms
3 be100-1199.fra-1-a9.de.eu (2001:41d0::299) 9.362 ms 9.345 ms 9.328 ms
4 decix2-gw.hetzner.de (2001:7f8::616c:0:2) 9.089 ms 9.112 ms 9.095 ms
5 core12.hetzner.de (2a01:4f8:0:3::f6) 22.072 ms 22.093 ms 22.088 ms
6 juniper1.rz2.hetzner.de (2a01:4f8:0:3::be) 11.985 ms 12.168 ms 11.959 ms
7 * * *
8 * * *
9 * * *
10 * * *
Auffällig hierbei ist das Routing über Hetzner.
Vom Support NC#2016051810003835 habe ich die Rückmeldung bekommen, dass ich den Server im Rettungssystem fahren soll und dann nochmal testen. Da der Ausfall aber immer nur ein paar Minuten ist, ist mir dies nicht möglich. Glaube auch nicht, dass es an meinem Server liegt.
Zum Vergleich das Routing, wenn der Server erreichbar ist:
1 * * *
2 be10-101.gra-g1-a9.fr.eu (2001:41d0::1eb) 1.677 ms 2.230 ms 2.072 ms
3 be100-1199.fra-1-a9.de.eu (2001:41d0::299) 8.900 ms 8.848 ms 9.330 ms
4 decix2-gw.hetzner.de (2001:7f8::616c:0:2) 9.127 ms 9.110 ms 9.085 ms
5 core11.hetzner.de (2a01:4f8:0:3::1e) 12.043 ms core12.hetzner.de (2a01:4f8:0:3::f6) 11.992 ms 12.109 ms
6 juniper2.rz2.hetzner.de (2a01:4f8:0:3::3a) 12.266 ms juniper1.rz2.hetzner.de (2a01:4f8:0:3::2e) 12.150 ms juniper1.rz2.hetzner.de (2a01:4f8:0:3::be) 12.192 ms
7 gw6-hetzner2.nbg.netcup.net (2a01:4f8:0:e060::6) 23.781 ms 23.730 ms 17.530 ms
8 (mein Server)
Hat einer eine Idee, wie ich weiter vorgehen kann (der Support vom französischen Anbieter wird darauf nicht reagieren, weil mein Server ohne SLA vermietet wird)
Stefan
Habe nun den Fehler gefunden:
Der Server hat die Default-Route verloren (ip -6 route add default via fe80::1 dev eth0)
Wie konnte das passieren? Bisher war das noch nie der Fall.
Auf das Ticket kam nur die Antwort
Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.