Beiträge von lulatsch66

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.

Zitat von aPollO

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.

Zitat von aPollO

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.

Zitat von aPollO

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.

Zitat von maiestro

... Hoffe das bleibt so. Wäre jetzt noch interessant was da von Seiten netcup geändert wurde...

Zitat von [netcup] Lars S.

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.

Zitat von aPollO

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!

Zitat von [netcup] Lars S.

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.

Zitat von H6G

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:

• hat jemand schon mal mit dem Hochsetzen von 'kernel.watchdog_thresh' per sysctl experimentiert?
• das o.g. Script zum Ausschalten per CCP bzw. SCP/API ... was genau bringt das? Längere Uptime, weil dann nicht so schnell wieder ein Reboot passiert?

• kann sich jemand erklären, warum bei dem "netz" Cluster s.o. die Reboots erst jetzt angefangen haben (nach 3 Monaten)? Bei m.E. gleicher Konfiguration.

• Hat jemand Aussagen zum Support dazu (außer "Proxmox wird nicht unterstützt"), also z.B. "passiert nur mit zfs" oder "Debian 10 + proxmox manuell installieren"?
• Ideen, wie man an die Kernel-Ausschriften kommt, rsyslog z.B. o.ä.?

Vielen Dank schon mal für eure Antworten.

Falko

Zitat von gab3

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.