Hallo Stefan,
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pmMich hats letzte Woche echt auf kaltem Fuß erwischt, dass euer Server gebrickt werden kann, wenn man ihn unbedarft falsch benutzt.
Wir wissen nicht ob der Server gebrickt ist. Du kannst Dich nicht anmelden, weil der Anmeldeservice nicht lädt, anderes kann durchaus funktionieren. In einem Log haben wir eine Warnung auf eine voll werdende Platte. Ob dies die Ursache ist, kann man nicht abschließend sagen, auch wenn es eine gewisse Wahrscheinlichkeit gibt.
Das "unbedarft falsch benutzt" ist etwas polemisch. Zum einen wissen wir nicht, was Ursache ist, zum anderen wäre ein - theoretisch denkbares - Vollschreiben durch eine Software im Docker Container nicht unbedarft, weil wir ausdrücklich und sehr explizit davor warnen und die Haftung dafür dann beim Nutzer ist.
Für alle Mitleser hier die Warnung, die automatisch eingeblendet wird (diese Warnung klappt erst nach Bestätigung ein):
Zusätzlich steht in der aufklappbaren Online Hilfe (vorletzter Absatz)
Von "unbedarft" kann nicht die Rede sein, es wird sehr klar darauf hingewiesen.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pmWir werden jetzt nicht mehr feststellen, ob irgendein 3 Jahre alter TestDocker die SDKarte vollgemacht hat oder es was anderes war.
Schicke uns das Gerät ein, dann sehen wir uns das an. Wir nehmen die Analyse kostenfrei vor, weil wir wollen das für uns wissen. Liegt der Fehler bei uns, reparieren wir den kostenlos, ansonsten kannst den Server dem Ersatzteillager spenden oder bekommst ihn zurück.
Ein Timberwolf Server ist - wie jedes andere IT-System - entweder Produktiv oder im Test.
Zu sagen, der eine Teil des Servers läuft produktiv und der andere Teil wäre nur im "Test", wenn dieser Teil technisch in der Lage ist, den produktiven Teil durch Übernutzung der Ressourcen zu stören, fällt nicht unter "Test". So wie es ein bisschen Schwanger auch nicht gibt.
Die Warnungen wurden glasklar gegeben. Wir bieten den Kunden diese Möglichkeit, weil es deren Server ist. Den dürften Sie benutzen wie sie möchten, das schließt eine Übernutzung der Ressourcen ein. Freie Fahrt für freie Bürger soweit das nur geht. Aber man muss dann auch Verantwortung übernehmen für sein handeln.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pmIch habe gelernt, dass ihr bei so einem fatalen Fehlerbild "Server Bricked":
Wir tun gar nichts.
Ein IT System benötigt zum Ausführen der Firmware ausreichend Hardware-Ressourcen. Wenn diese Ressourcen - aus welchem Grund auch immer - nicht mehr bestehen, ist eine vollständige Ausführung aller Funktionen nicht mehr möglich. Das gilt für jedes IT System. Es ist deshalb nicht bricked, sondern benötigt eben einen Experteneingriff.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pm- das Problem kennt, aber eure Systempartition nicht vor Überlauf schützt (oder einen Recovery Modus habt)
Das ist falsch.
1. Alle Server der Modellreihe 3500 (mithin seit Dezember 2021) sind gegen das Vollschreiben durch Container geschützt, weil wir hier das Systemdesign geändert haben (Container laufen im User Space). Ein Update der früheren Modellreihen war nicht möglich.
2. ALLE Server aller Modellreihen seit 2019 haben einen Recovery Modus, der Remote genutzt werden kann. Die Besitzer der wenigen Server (Baureihe 2xxx) von vor 2019 (das genau Datum habe ich jetzt nicht) die diesen Modus noch nicht hatten, wurden damals angeschrieben, dass sie den Server einsenden sollen und es eine kostenfreie Nachinstallation gibt, so dass auch diese diesen Recovery Modus haben. Dein Server sollte einen solchen Revocery Modus haben, der auch funktionieren dürfte, solange es keinen HW Defekt gibt.
Bitte behaupte doch nicht einfach etwas, nur aus der Vermutung heraus.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pm- ihr einen Push bekommt, wenn der Server kurz davor ist ein echtes Problem zu haben und daraus aber nichts macht, um den Kunden/das System zu schützen.
Haben wir - mehrmals übrigens - erwogen und immer wieder hintenangestellt.
Technisch können die Timberwolf Server dringende Meldungen des Betriebssystems in ein zentrales Log auf unseren Servern schreiben. Damit würde sich erkennen lassen, wenn eine neue Firmware z.B. "faul" wäre, weil plötzlich überall die CPU-Nutzung massiv ansteigt. Aber es sind halt Betriebssystem-Logs und wer soetwas schonmal gesehen hat, der weiß, dass da auch schonmal hunderte Warnmeldungen hintereinander im Sekunden-Abstand kommen können. Das kann man nicht so einfach an die Kunden rausschreiben.
Man müsste also schon sehr intelligent filtern, damit die Kunden keine Mailflut bekommen. Dabei ist aber die Frage, wie oft informiert man? Sendet man ein "Warnung aufgehoben" E-Mail wenn der Fehler weg ist. Wann warnt man erneut? Soll man einen Bestätigungs-Button ins E-Mail einbaut, damit man weniger erneute Warnungen schickt?
Und wenn man damit anfängt, dann erwarten die Kunden, dass man sie vor allem schützt. Also auch bei Übertemperatur? Kann nerven, wenn es halt warm ist dort und die Temperatur immer um 2K um eine Schwelle schwankt.
Das ist dann nicht mehr nur ein Script, sondern schon aufwändiger und dann muss man prüfen, dass diese Prüfungen laufen.
Kurz, wir sind auf Implementierungskosten in der Größenordnung eines hohen vierstelligen bis unteren fünfstelligen Betrag für die Einrichtung gekommen und einen jährlichen Aufwand im unteren vierstelligen Bereich.
Auf 15 Jahre hochgerechnet also durchaus ein ansehnlicher Betrag. Und für was? Für etwa ein Inzident pro Jahr über die gesamte Flotte. Mit stark fallender Tendenz, denn die Probleme sind vor allem mit Edomi-Container aufgetreten (wegen dessen Buslogs und täglichen Backups ohne automatischem Management seitens Edomi) und den alten Servermodelle die einen immer geringeren Anteil an der Flotte haben.
Ein solcher finanzieller Aufwand für diese geringe Anzahl von Vorkommnissen ist schwer begründbar. Nicht weil wir das nicht machen würden, sondern weil uns das nicht bezahlt wird.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pmIch wünsche dem nächsten Nutzer mit ähnlichem Fehlerbild der sich deutlich intensiver auf den Timberwolf eingelassen hat, dass elabnet hier prozessual oder SW-seitig nachbessert.
Ist 2021 bereits passiert. Die Modellreihe 3500 hat einen weitgehenden Schutz gegen Überschreibung der Platte.
Ohnehin werden alle anderen schreibenden Prozesse automatisch gemanaged. Es ist nicht möglich, mit Zeitserien, Buslogs, Dr.Modus-Monitoring und sonstigen Logs den Server vollzuschreiben, weil diese Daten automatisch gekürzt werden, weit bevor es knapp würde.
Zudem haben wir mit der letzten Firmware ein Ressourcenmonitoring eingebaut, dass die Daten in eine Zeitserie schreibt. Man kann sich damit selbst i Grafana einen Alarm setzen:
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pmSowas kann RICHTIG böse ins Auge gehen und dann sitzt du da mit gebricktem Server
Unsinn.
Der Server schützt sich selbst vor Übernutzung von Ressourcen seiner Prozesse und Funktionen im Rahmen seiner Firmware.
Im Falle eines Überschreibens durch Docker liegt eine Übernutzung der Ressourcen vor und kein normaler Betrieb. Wer mit seinem (Verbrenner-Schalt-Auto) im zweiten Gang 80 auf der Autobahn fährt, nutzt das Getriebe auch nicht mehr mit der vorgesehenen Geschwindigkeit für diese Schaltstufe. Ist auch nicht der Hersteller schuld.
Wenn jemand irgendeine Software installiert, welche die Ressourcen übernutzt, dann liegt das nicht nur in der Freiheit des Nutzers, sondern auch in dessen Verantwortung. Es obliegt ihm, die von ihm gewählte oder von ihm geschriebene Software sorgfältig auszuwählen für die zur Verfügung stehenden technischen Ressourcen und den Betrieb zu managen.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pma.k.a gebricktes Haus bei deinem 1.000€ Server und bekommst Ehestress, wenn du vielleicht noch elabnet Anleihen für weitere 1.000€ gekauft hast.
Für den Ehestress können wir nichts. Jedes technische Gerät kann ausfallen.
Wer sich bei seinem Timberwolf Server seine Platte überschreibt und einen Wartungsvertrag bei uns hat (oder ein Unterstützer ist), der krakeelt nicht im Forum herum, sondern meldet sich bei uns. Er bekommt dann Dateien für einen "Rescue-Stick" und den steckt er in den Server ein und bootet diesen. Auf dem Rescue-Stick ist die Anweisung an das Rescue System (befindet sich auf der unabhängigen Rescue Partition) dass ein Rescue VPN zu uns aufgebaut werden soll. Dann verbinden wir uns und nach ein paar Minuten löschen wir - nach Rücksprache mit dem Kunden - das entsprechenden Docker Volume, starten neu und alles läuft wieder.
Wir haben damit einen Service, den kein anderer Hersteller auf dem Markt bietet. Wir lassen unsere zahlenden Kunden selbstverständlich nicht im Stich.
bluegaspode hat geschrieben: ↑Mo Dez 15, 2025 5:22 pmOder lustige Haftungsfragen als Systemintegrator .
Das ist Quatschjura. Niemand haftet irgendwie "lustig" weil ein technisches Gerät ausfällt. Egal ob das die KNX Spannungsversorung ist, ein Aktor, ein Glastaser, ein GIRA Homeserver oder ein Timberwolf Server. Allenfalls während der Gewährleistung muss es nach den gesetzlichen Regeln ersetzt oder repariert werden, sofern es ein Fehler ist, der bei der Übergabe schon im Gerätes vorhanden war. Bei der Auslieferung gibt es keine Docker Container die irgendwas anstellen. Und wenn ein Integrator darüber hinaus Garantien gibt, dann hat er ein zweites Gerät im Lager und uns auf Kurzwahl.
Lieber Stefan, ich möchte Dich auf die Forenregeln hinweisen. Die oberste Regel ist, dass wir hier wohlwollend miteinander umgehen. Das ist mit Behauptungen und Vorwürfen, die nicht der Realität entsprechen, nicht gegeben.
Nebenbei ist das Zeitverschwendung für alle Beteiligten und sagt am Ende mehr über Dich aus, als über uns.
Bleib doch bitte beim Sachthema. Dein Server geht nicht mehr, was bedauerlich ist. Auf Deine Meldung im Forum von Montag kurz vor Mitternacht, wurde am Folgetag um kurz vor Neun reagiert, also in unter einer Stunde bei regulärer Arbeitszeit und Du wurdest gebeten, ein Ticket zu eröffnen.
Gegen Mittag haben wir dann schon eine erste Diagnose geliefert, damit waren dann drei Mitarbeiter mit dem Fall beschäftigt und es sind damit schon Kosten von kalkulatorisch etwa 150.- EUR aufgelaufen. Unser Bemühen findet in Deinem Vortrag keinerlei Wertung, womit Deine Kritik nicht nur unangemessen, sondern auch einseitig ist.
Ein bisschen mehr Fairness wäre nicht unangebracht. Wir wollten wirklich helfen.
Und gleich noch auf Dein zweites Nachtreten:
bluegaspode hat geschrieben: ↑So Dez 21, 2025 12:00 amDie Kondition ist, dass ich ins Risiko gehe ob Elabnet der Meinung ist, dass dieser Fehler durch mich verursacht wurde oder durch Elabnet.
Wie soll es auch anders gehen? Es ist Dein Server. Er gehört Dir mit allen Funktionen und Problemen. Wie beim Haarfön, der Mikrowelle und dem Kühlschrank auch. Reparaturen nach Ende der Gewährleistung sind nunmal in der Regel vom Kunden zu tragen. Wer das nicht möchte, kann einen Service-Vertrag abschließen.
bluegaspode hat geschrieben: ↑So Dez 21, 2025 12:00 amWenn elabnet der Meinung ist, es ist mein Fehler kostet.... Ich habe die Hinweise von Stefan weiter oben wie 'ist evtl einer deiner Docker Container' und 'du hast die Notification nicht gesehen' so interpretiert, dass das eher als Fehler bei mir und weniger als möglicher Serienfehler in elabnets Softwarestack gesehen wird.
Das ist Deine Interpretation. Tatsächlich wissen wir nicht, was hier Sache ist.
Es war in der Vergangenheit nur so, dass wenn die Platte vollgeschrieben war (die wenigen Male, wo das passiert ist), dann war es ein Docker Container (zu 90% Edomi). Was bei Deinem Server vorliegt, wissen wir nicht. Dass wir im zentralen Log einen Hinweis auf knappen freien Speicher gefunden haben, muss nicht die Ursache sein, es mag ja auch ein Überspannungsschaden sein (der dauert nur Millionstel Sekunden, das bekommt man nicht mit) oder der Flash ist ausgefallen (rein theoretisch, gab es noch nie, wir haben extra Industrial Grade pSLC verbaut).
In diesem Jahr gab es einen Kunden mit einem 6 Jahre alten Server, dessen Installation defekt war. Wir haben festgestellt, dass dies auf einem uralten Fehler in der Software beruht, den wir vor fünf Jahren schon gefixed haben. Der Kunde hat nur nie ein Update installiert (sieht man auch selten). Auch kein Wartungsvertrag, die Garantie also vor vier Jahren abgelaufen. Jetzt hätten wir schon sagen können, dass es in der Pflicht des Kunden ist, regelmäßige Updates einzuspielen (und das entspricht auch der Rechtsprechung). Trotzdem haben wir hier auf Kulanz erkannt und nichts berechnet, weil das war damals unser Fehler. Leider berichtet über sowas kein Kunde.
Dass Du uns nicht vertraust, ist Deine Entscheidung.
bluegaspode hat geschrieben: ↑So Dez 21, 2025 12:00 amFormal finde ich es verständlich dass für ein Gerät außerhalb der Wartung ein Preis aufgerufen wird (und die potentiellen Kosten sind in der Mail transparent dargestellt worden).
Die 199€ waren es mir dann aber nicht wert.
Damit wäre es immer noch weniger als der Wiederverkaufswert. Weil 350er sind wegen des PBMs darin nachgefragt, weil wir derzeit keine PBMs mehr bauen.
bluegaspode hat geschrieben: ↑So Dez 21, 2025 12:00 amIch bin halt nur betrübt, dass es keine Möglichkeit der eigenen Rettung gibt, z. B sowas wie ein 'Rescue Mode' oder Zugriff auf die Docker Volumens per SSH wenn die Wahrscheinlichkeit gegeben ist, dass diese die Platte voll machen.
Es gibt einen Rescue Mode. Dieser ist Wartungsvertragskunden vorbehalten zur Nutzung durch unsere Experten. Wir können kein Root rausgeben damit die Kunden selbst am System herumfummeln, weil das ist sehr komplex. Das ist bei moderner Technik auch nicht mehr möglich. Ich habe bei meinem ersten Auto noch die Zündkerzen selbst gewechselt und am Vergaser geschraubt. Bei meinem Tesla rufe ich - falls was wäre - die Experten an, die sich dann remote mit dem Auto verbinden und ggfls. die Software fixen. Man schraubt bei modernen Produkten nicht mehr selbst - weil das Spezialwissen dafür fehlt.
Diejenigen die Docker nutzen, können sich auf dem Timberwolf Server einen SSH-Docker einrichten, diesem alle Docker Volumes mit zuweisen und könnten dann darauf per SSH zugreifen und Ihre Volumes warten, selbst wenn man sich am Hauptsystem nicht mehr anmelden kann. Aber das muss man sich dann halt auch so einrichten, das obliegt dem Nutzer selbst. Es gibt auch eine Anleitung im Forum dafür. Hast Du halt nicht gemacht, was ok ist, aber es ist auch nicht unsere Schuld.
Ich finde es unfair, im Falle eines Problemes alle möglichen Ansprüche zu stellen, deren Erfüllung man vorher nicht finanziert hätte. Der Server kostet eben 1.000.- EUR und nicht 4.000 EUR um sämtliche Wünsche abzudecken. Es ist leicht, sich in der Phantasie vorzustellen, was man alles gerne hätte, dass in einem technischen System alles eingebaut ist. In der Realität ist das limitiert, weil auch der Preis limitiert sein soll.
Sei bitte Fair mit uns.
lg
Stefan
