Danke fürs Teilen!
Leute, die (zusätzlich) IPv6 verwenden, könnten das Skript vermutlich einfach duplizieren und die folgenden Zeilen entsprechend anpassen (ohne Gewähr - ich hab das Skript nur kurz überflogen):
Vielen Dank an alle, funktioniert bei mir ebenfalls gut.
Anbei die für IPv6 angepasste Variante.
Stelle auch gerade fest, dass eine meiner failover-ips - mit sehr vielen Domains, die ich nicht einfach mal alle im DNS ändern kann - seit 7:30 komplett weg ist. D.h. auf keinen Server geroutet. Nach dem Versuch, per script auf einen anderen Server zu routen - keine Änderung.
Dann im SCP versucht: es kommt die 5 min Meldung.
Nach 5 min nächster Versuch - es kommt "Entschuldigung, das sollte nicht passieren" ... Ein Serverfehler ist aufgetreten. Nächste 5 min - routing auf anderen Server hat diesmal funktioniert.
Letzte Woche oder vor 14 Tagen hing der root server komplett um dieselbe Zeit mit einer Meldung auf der Konsole mit vielen 000 ... die leider nicht besser lesbar war, so dass nur "erzwungen neustarten" geholfen hat.
Schreibe jetzt an den Support ... finde das aber grad nicht mehr lustig.
Also würde ich empfehlen, ebenso die »neumodischen« DoT/DoH-Settings im Auge zu behalten bzw. zu deaktivieren.
Stimmt, danke. Sollten wir vor dem nächsten Versuch mal checken.
Vorkasse bzw. PayPal nutzen.
Danke für die schnelle Antwort.
Wie genau machen wir das? Die Bestellungen wurden ja seitens Netcup storniert,
bevor überhaupt eine Rechnung zu sehen war. Also es scheiterte damals an der Verifizierung des Neukunden-Accounts,
jetzt sind wir gar nicht so weit gekommen.
Wie das mit GeoIP passieren konnte, ist mir auch noch schleierhaft. Wir schauen aber mal, was da beim Internet-Anschluss so für Adressen auftauchen.
Dass es da seitens Netcup dann kein besseres Verfahren gibt in so einem Fall, wenn sich der Neukunde direkt beim Support meldet ...
na wenn ich mehr weiß betr. Internet-Anschluss / IPs mache ich vielleicht doch von mir aus nochmal ein Ticket auf.
VG
Hallo zusammen,
eine Kundin (Verein, RAin) möchte einen Webhosting 2000 Tarif bestellen, diese Woche haben wir es wieder beim Sonderangebot versucht.
Jedes Mal wird sie mit anderen Meldungen abgewiesen, beim ersten Mal vor ein paar Monaten:
>> wir freuen uns Sie als Kunden bei netcup begrüßen zu dürfen. Anbei erhalten Sie Ihre Zugangsdaten zum netcup CCP
und dann 2 Tage später:
>> Unser Verifizierungsanbieter hat Ihre Nachweise abgelehnt. Da wir aus datenschutzrechtlichen Gründen
>> keinen Zugriff auf Ihre gespeicherten Daten haben, müssen wir Ihre Bestellung hiermit ablehnen.
Da war es der Unterschied bei der Verifizierung, dass die angegebene Büro-Adresse nicht mit der Adresse auf dem Ausweis übereingestimmt hat.
Support hat dann siehe oben erklärt, sie könnten nicht auf die gespeicherten Daten zugreifen, das Angebot sei nicht mehr gültig usw.
Dieses Mal kam eine komische Meldung im Browser (irgendwas mit Warenkorb und keine ID drin o.ä.), aber eine Mail, dass das Produkt bestellt sei.
Dann aber heute:
>> vielen Dank für Ihre Bestellung.
>> Wir mussten diese aus Sicherheitsgründen stornieren, da die
>> Bestellung über eine IP aufgegeben wurde, die nicht mit Ihrem
>> Wohnsitzland übereinstimmte.
>> Sollten Sie ein VPN benutzen, bitten wir Sie diesen während des
>> Bestellvorgangs zu deaktivieren.
Verwendung von VPN o.ä. ist nicht bekannt, aber das prüfe ich nochmal.
Das ist doch wohl ein schlechter Witz. Bisher war ich immer gerne bei Netcup und habe auch Kunden weiter empfohlen.
Wenn wir jetzt wieder beim Support nachfragen, sind wir wieder bei der Meldung von oben.
Gibt es irgendwo eine Anleitung/FAQ, was bei einer Neukunden-Bestellung zu beachten ist?
Jemand Tipps, wie das beim nächsten Versuch problemlos funktionieren kann?
Support könnte ich zwar auch von meinem Account aus kontaktieren, aber es geht ja hier um Neue Kundin.
Vielen Dank schon mal für Ideen
Falko
Nachdem das Problem in NCSUP-301557 am 30.1. behoben wurde, funktioniert es heute wieder nicht.
Und wegen des Ausfall vom SCP kann ich auch die Failover-IPs im SCP nicht manuell umschalten.
Bin gespannt, ob die API wieder funktioniert, wenn der Ausfall behoben ist.
Hallo zusammen,
nachdem meine API Scripts nach obigem Schema am 16.1.24 definitiv noch funktioniert haben, bekomme ich seit gestern nur noch zur Antwort:
<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"><faultcode>S:Server</faultcode><faultstring>validation error</faultstring></S:Fault></S:Body></S:Envelope>Ist das nur bei mir so, oder habt ihr ähnliche Probleme?
Danke schon mal!
Falko
Du kannst '-v' oder '-vv' usw. verwenden.
Ansonsten schau dir mal deployer an, damit kannst du alles auch komplett hin schaufeln, ohne auf dem Server unbedingt composer aufzurufen.
Ich brauche eine Nachfolge für mein aktuelles System bis zum 03.01. und dachte ich würde bei Netcup fündig. Klingt mir aber irgendwie sehr Risiko behaftet und nicht stabil.
Dieser Thread ist ja gerade dazu da, dieses Problem zu klären. Und wie es aussieht, ist das Problem auch geklärt. Und betrifft ja ausschließlich den Fall, wenn Proxmox bzw. ein Proxmox Kernel im Spiel ist.
Abgesehen davon ist das schon sehr sportlich, wenn du bis zum 3.1.22 deinen Umzug fertig haben möchtest. Hängt natürlich vom Umfang ab.
Da bin ich wohl wo anders besser aufgehoben wo ich weiß das es auch funktioniert.
Wo bekommt man denn sonst noch virtuelle Systeme auf KVM-Basis mit dedizierten Cores? Wo Proxmox im Cluster funktioniert ... Ich kenne das sonst nur mit Hardware-basierten Maschinen.
Wenn man's wenigstens für nen Monat oder auch zwei auf monatlicher Abrechnung belassen kann zum test und wenns stabil ist auf jährlich umstellen. Oder geht das?
Ja, geht beides soweit ich weiß. Entweder mit Zufriedenheitsgarantie, wie DerRené schon schrieb, oder nur einen Monat Laufzeit.
Ich hab hier auch noch ein paar Systeme mit 12 Monaten Laufzeit und verschiedenen Kündigungsfristen, die ich vielleicht los werden möchte.
Schreib mir am besten PM - was genau für eine Ausstattung du suchst. Dann könnten wir das per Inhaberwechsel übergeben, wenn was passt.
... Hoffe das bleibt so. Wäre jetzt noch interessant was da von Seiten netcup geändert wurde...
Danke für eure Unterstützung!
Würde mich auch sehr interessieren, was genau zu dem Problem mit den G9 und den proxmox-kerneln geführt hat. 
Gibts denn Jemand der LXC Problemlos mit Proxmox bet Netcup am laufen hat oder ist das Generell ein Ding der Unmöglichkeit? Oder gibts gute Alternativen zu Proxmox? Ich könnte mir auch Vorstellen LXC unter Debian 11 manuell zu verwenden, also ohne eine GUI wie Proxmox, aber lieber wäre es mir eigentlich wenns "einfach" und "klicki bunti" ist, bin generell faul.
Ja, habe zwei Proxmox Cluster (einer pve6, einer pve7 mit [noch] mixed pve6). Wenn dich Details interessieren -> neuer thread und ping mich gern an.
Idee war: failover-IPs hängen an lxc mit haproxy, switchen per HA, die backend-lxc können entsprechend nach Belieben zwischen den nodes verschoben werden.
Das funktioniert(e) grundsätzlich auch ... bis mehr und mehr G9-nodes die Resets zeigten.
Vom Netcup support am 21.6.21:
"... aus dem log kann ich herauslesen, das Sie proxmox benutzen. In Kombination mit unserem Kernel, proxmox und Debian kann es zu Umständen zu reboots kommen.
Ich kann Ihnen empfehlen, das Standart-Image direkt von Debian zu beziehen und die Situation noch zu beobachten. Sollte es dennoch zu diesen Reboots kommen, können Sie sich gerne an uns wenden. "
Daher hab ich mir etliche G8/Intel ertauscht, die das Problem nicht haben, und kündige die G9 nach und nach wieder. Aufgrund obiger Aussage und den anderen Beobachtungen hier im thread hatte ich nicht damit gerechnet, dass Netcup das doch noch löst.
Nun ist ja hier durch den thread Bewegung in die Sache gekommen, ich hatte meine G9 nodes alle am 15.12. aus-/eingeschaltet und seitdem auch keine ungebührlichen Resets mehr beobachtet. Was ich jetzt weiter mit den G8/G9 mache, muss ich mir überlegen. Das ganze Problem hat sehr viel Zeit und letztlich auch Geld gekostet. Wäre schön, es gäbe eine Kulanz-Regelung, dass man ggf. eher als Laufzeit kündigen kann oder so, da das Problem ja jetzt offiziell bestätigt ist.
HA-Modus: hab ich aktuell aus, weil da dann auch die G8 reboots gemacht hatten. Das würde ich aber nochmal in Ruhe testen, wenn die Resets in absehbarer Zeit nicht wieder auftreten.
Hallo Lars,
vielen Dank für die Aktion!
Bitte lasst uns dazu in jedem Fall folgendes zukommen:
- Euren vServer-Namen
...
- Zeitpunkte, zu denen das Problem aufgetreten ist...Danke für eure Unterstützung!
Idee:
Wollt ihr vielleicht eine extra Mailadresse (oder speziellen Betreff)
einrichten für standardisierte Infos zu den Resets?
vNNNN Datum/Uhrzeit kernel
und vielleicht die jeweilige Ticket-Nummer (oder eine spezielle nur dafür).
Dann könnt ihr das auch automatisiert auswerten und korrelieren ...
Viele Grüße
Falko Trojahn
Alternativ gibt es ja auch gitlab.com z.B., oder irgendwo selber auf eigene Seite ist sicherlich auch eine Möglichkeit.
Wenn du dich bei einem der Dienste angemeldet und ein Projekt angelegt hast, genügt im Grunde git für den Zugriff von lokal.
Sieht auf jeden Fall interessant aus.
Könntest du evtl. kurzs schreiben, warum der Quellcode (noch) nicht öffentlich ist?
Ok, verstehe, vielen Dank für eure Antworten.
Bleibt für mich die Theorie, dass bei meinem "netz" Cluster bisher alle nodes auf neueren Hostsystemen waren/sind, und dann nur die eine Maschine auf einen älteren/anderen Host verschoben wurde, der die Reboots (= Ryzen-Bug?) hat ... Die anderen vom "soft" Cluster und der RS Superuser mit pve7 könnten entsprechend alle auf älteren sein. Klingt das plausibel? Wenn ja, müsste der Support das doch eigentlich zuordnen können ...
Kernel sind bei mir alles 5.4.x, auf pve7 ist 5.11.22 - entsprechend aktuell. Demnach bringt upgrade auf 5.11 bei pve6 auch nix. Nur Wechsel auf G8 ... und den RS Superuser wieder zurückgeben, da noch innerhalb 30 Tage. Den nutze ich im Moment nur zum pve7-Experimentieren, weil ich dort das private network mit lxc noch nicht hinbekommen habe - anderes Thema.
Ich glaube es geht schon wieder los.
Ich habe wieder resets, trotz neuerem Kernel...
Hallo zusammen,
nachdem ich immer mit Hoffnung auf Lösung auch schon eine Weile mitgelesen habe, hier mal meine Erfahrungen zum Thema.
Vielleicht finden wir ja doch irgendwann einen Zusammenhang ...
Ich betreue z.Z. 2 Cluster mit jeweils 3 Nodes mit Proxmox 6.4, ich nenn die jetzt mal "soft" und "netz" zur Unterscheidung.
Verbunden sind die jeweils per cloudVlan M und CloudVlan free.
Da ich nur container brauche, hab ich auch kein vmx Flag dazu gebucht. HA-setup mit Failover-IPs, was unterm Strich
nicht viel Sinn macht, wenn jetzt mehr Reboots auftreten als bei normaler Nutzung (auch wenn's trotzdem flexibler ist).
Bei "netz" sind 2x RS4000 G9 und ein VPS 100 -> da gab es bis zum 20.9. keine unvorhergesehenen Reboots. Gar keine.
Bei "soft" sind 2x RS4000 G9 und ein RS2000 G8 (auch der hat sich, obwohl Intel, schon mal alleine rebootet).
Hinzugekommen ist jetzt noch ein RS Superuser vom 21.9., dort hab ich Proxmox 7 aktuell vom iso installiert. Da ging es mit
Reboots am 26.9. und 28.9. los - bin dort allerdings noch innerhalb der 30 Tage, würde den gern als PBS mit nur 1-2 container nutzen.
Fragen:
Vielen Dank schon mal für eure Antworten. 
Falko
Ich plane aber demnächst noch mindestens auf tripwire und RKHunter zu setzen, denn clamAV ist schon langsam und ressourcenlastig.
maldetect hat mir immer ganz gut beim Analysieren von (fremden) infizierten Servern geholfen.
Es kann mit clamAV zusammenarbeiten und in mod_security2 integriert werden, um den eigenen Server zu schützen.
Wenn es Befall gibt, dann meist innerhalb von einzelnen vhosts - vorausgesetzt diese sind z.B. mit suexec sauber getrennt. Wenn ein Eindringling bereits root Zugriff hatte, muss man den Server sowieso neu aufsetzen.
Um unbefugte Änderungen an vhosts schnell zu erkennen/zu beheben, nutze ich je nach Arbeitsweise des Nutzers gern git - ein einfaches "git status" zeigt dann, was sich (ggf. unerwünscht) geändert hat und kann mit "git stash" behoben werden; natürlich erspart das nicht die Suche nach dem Einfallstor bzw. der Sicherheitslücke etc. Das macht natürlich nur Sinn, wenn der Nutzer bei erwünschten Änderungen immer zeitnah commits macht - und wenn die .gitignore sinnvoll eingestellt ist. Weil oben WordPress erwähnt wurde: VersionPress ist dein Freund.
Systemseitig finde ich btrfs snapshots ganz sinnvoll - a) backups lassen sich mit btrfs send/receive beschleunigen, b) ein Vergleich zwischen zwei Snapshots ist ohne großen Aufwand möglich, c) zurück auf einen vorherigen Stand geht relativ schnell. Voraussetzung ist, dass man sinnvoll subvolumes anlegt, also von System und Nutzdaten/Cache/vhosts entsprechend einzeln copy-on-write Snapshots anlegen (und wieder aufräumen) kann.
Ungewöhnliche Aktivitäten lassen sich natürlich auch mit entsprechendem Monitoring erkennen, nagios/icinga2/zabbix z.B. Aber auch einfache scripts können helfen zu erkennen, wenn z.B. smtp logins aus ungewöhnlichen ip-Bereichen kommen bzw. plötzlich viele Mails über einen Account verschickt werden. Nicht immer muss ein Server-Einbruch dahinter stehn, es genügen zu einfache Passwörter oder per lokalem Befall bei einem Benutzer ergaunerte Mail-/Ftp-Zugangsdaten. Ssh sollte eh nur per key ... wurde ja oben schon genannt.
