ElabNET Technik Forum

Guten Tag,

Wenn es Ernst gemeint ist mit Sicherheit vs Forum, dann Forum und/oder Nachrichtendienst streichen und Sicherheit dem Vortritt geben.
Enrico

Hallo,

ich denke, das größte Problem dzt. ist die lange Zeit zwischen den Patches, was wohl der extrem umfangreichen Erweiterung der Funktionalität geschuldet ist. Insofern denke ich, wenn dann mal die V4 endgültig draußen ist, werden die Hauptversionen auch wieder regelmäßiger kommen.

Für mich persönlich ist es sehr wichtig, ein stabiles System zu haben, worauf ich mich verlassen kann. Diskussionen mit meiner Frau, warum jetzt plötzlich dies und jenes nicht mehr funktioniert, brauche ich echt nicht.
Insofern: Software Patch erst nach ausgiebigem Feldtest.

Wirklich extrem kritische Dinge, habt ihr auch sicher besser am Schirm, als ich. Vor allem, weil ihr ja die interne Architektur des TWS kennt, ich nicht.

Und noch eine Anmerkung, was ich immer wieder denke:
Aufgrund des Forums und der extremen Kundennähe, werden hier auch ganz andere Maßstäbe angesetzt. Ich habe zwar kein Konkurrenzprodukt im Einsatz, allerdings kann ich mir gut vorstellen, dass es dort mit Updates, oder gar Upgrades, auch nicht besser aussieht. Ist allerdings nur eine Einschätzung.

LG
Marcus

Bin auch für erst nach ausgiebigen Feldtest.

OT: Ich nutze Openmediavault v3 im LAN. Da habe ich früher regelmäßig die Updates eingespielt. Bis mir ein Update mit Änderungen an einem Dienst die Konfig zerschossen hat. Das hat mich ungeplant ein Wochenende gekostet den Fehler zu finden und zu beheben. Danach hab ich aufgehört den zu patchen.

Bitte fokussiert Stabilität. Ich will bei Updates diese bedenkenlos durchführen können.

Hallo Enrico,

zoonuser hat geschrieben: ↑Do Mär 21, 2024 9:52 amWenn es Ernst gemeint ist mit Sicherheit vs Forum, dann Forum und/oder Nachrichtendienst streichen und Sicherheit dem Vortritt geben.

Danke. Ja, ist ernst gemeint, die Betreuung hier ist sehr aufwändig und teuer und wir würden wohl schon 25% mehr Entwickeln können, wenn wir diese Kosten hier nicht hätten. Brauchen andere Hersteller auch nicht. Aber das Forum ist vielen Kunden sehr wichtig.

Wobei das mit der Sicherheit eine zweischneidige Sache ist. Der Timberwolf Server ist nicht unsicher, es wird ein bischen viel in die Verfügbarkeit von Security Patches hineininterpretiert und ein Security Scanner sagt beim Scannen vom TWS, dass das Betriebssystem "veraltet" ist (was angesichts der Patches und dem - je nach TWS Modell - neuen Kernel so gar nicht stimmt, auch deshalb, weil wir aktuelle Patches beziehen).

Zudem ist es auch nicht immer so, dass das jeweils aktuellste OS stets die beste Wahl ist. Weil wenn wir erstmal auf die neueste OS-Version upgedatet haben (was im Labor schon seit einem Jahr läuft) werden manche merken, dass womöglich ältere Software im dann neuen Docker unter neuem Kernel mit neuster CLIB womöglich nicht mehr läuft, wenn z.B. der Autor dieser Software vor zwei Jahren sein Projekt eingestellt hat. Umgekehrt läuft aber womöglich allerneueste Software nicht mehr im heutigen Docker. Mit der allerneuesten Software man bekommt etwas gutes, aber manchmal verliert man auch die Rückwärtskompatibilität zu älteren Komponenten und die Stabilität kann mangels Reife gefährdet sein. Weil das gute an old-old-stable ist das super ausgereifte stable daran.

Ich fürchte, ich habe da noch eine unschöne Nachricht für Dich. Es wird nach heutiger Erkenntnis (ändert sich vielleicht noch) das Upgrade auf ein aktuelles OS voraussichtlich für 3xx/9xx nicht geben, weil es für das dort verbaute Prozessormodul keine passende OSS mehr gibt. Bedeutet in der ganzen Kette der technischen Abhängigkeiten damit auch kein neueres Grafana usw. Eben alles was Open Source ist. Sorry, tut uns leid. Wirklich. Ärgert uns selbst. Wir haben damals das beste verbaut, was auf dem Markt verfügbar war. Dass es dafür fünf Jahre später dafür keine OSS Updates mehr gibt, war nicht vorherzusehen. Tut mir leid für Dich und alle anderen Betroffenen. Und bevor das falsch verstanden wird, es betrifft nicht die Software von uns, also neue Funktionsmodule usw. weil hier haben wir die Abhängigkeiten selbst im Griff und können das auch passend entwickeln. Aber eben den OSS Anteil und die Zusammenarbeit damit, das wird knirschen. Deswegen bieten wir ja auch die Migrationsaktion auf das aktuelle Modell 3500 mit dem großen Preisnachlass. Wir bauen damit eine Brücke für die Kunden mit den entsprechenden älteren Architekturen.

lg

Stefan

Hallo Marcus,

mclb hat geschrieben: ↑Do Mär 21, 2024 10:00 amAufgrund des Forums und der extremen Kundennähe, werden hier auch ganz andere Maßstäbe angesetzt.

Richtig. Einfach weil man weiß, dass der Hersteller zuhört, wird - in allen Bereichen - eine große Anzahl Wünsche geäußert. In der Summe sind diese zuviel, das geht zusammen gar nicht, weil, Verzeihung, bezahlt wird uns das alles in Summe nicht. Also muss man priorisieren und das bringt uns dann Ärger ein, weil halt manche Wünsche zurück gestellt werden müssen. Thats live. There is no free meal.


Ich bekomme immer wieder Unverständnis über die Kosten unserer Wartungsverträge. Tatsächlich können wir für EINEN Monatsbeitrag eines Kunden gerade mal EINE (vielleicht auch zwei) produktive Programmzeilen pro Monat bezahlen. Und eine Programmzeile ist halt gar nichts. Die meisten haben keine Vorstellung, wie teuer Softwareentwicklung ist.

Zudem leisten wir ja auch einen sehr intensiven Support. Ein aktuelles Beispiel, dass ihr vielleicht mitgelesen habt. Es gibt zwei (vielleicht sind es auch drei und ich habe es gerade nicht im Kopf) Kunden, die hatten ein Problem mit der Cloud-Verbindung. Wir haben uns also auf den Server verbunden und festgestellt. dass die Kunden einen limitierten Netzwerkanschluss haben. Daraufhin haben wir drei Patches entwickelt. Einen für die Cloudverbindung auf der Seite des TWS Servers (anderes Timing, mehr Keep-Aliive, Optimierung Paketgröße damit wir das "Carrier Grade NAT" des Providers nicht "überfordern"). Dann einen Patch für die Cloudseite, damit das dann auch passt und mit einem dritten Patch haben wir die Benutzeroberfläche um die Anzeige eines Protokolls der Verbindung erweitert, damit wir für weitere Arbeiten daran eine Grundlage haben. Das ganze hat kalkulatorisch einen ordentlichen vierstelligen Betrag gekostet und war letztlich dann nur für den einen Kunden, weil der zweite hat seinen Provider rund gemacht, er hatte nämlich eine eigene IPv4 Adresse bestellt und die wurde versehentlich vom Provider wegkonfiguriert. Es war nicht mal unser Fehler, aber wir hatten die Kosten. Ich bin mit sehr sicher, so einen Support mit Patches binnen weniger Tage gibt es nirgendwo in der Branche.

Was mich ärgert ist, dass es dann, wenn Kritiker meinen uns die Leviten lesen zu müssen, weil wir eine Anforderung nicht erfüllt haben, diese Dinge (und andere Goodies) stets unerwähnt lassen und auch in die Bewertung nicht miteinbeziehen. So, als hätte unser Service und Patches selbst für Einzelfälle überhaupt keinen großen Wert. Weil wir könnten auch einfach ins Handbuch schreiben, dass man eben einen vollwertigen IPv4 (ja, demnächst auch IPv6) Anschluss benötigt und fertig, dann hätte der eine Nutzer eben Pech gehabt. Aber so agieren wir nicht, wir kümmern uns nach Möglichkeit auch um viele der Einzelfälle, weil es die Software besser und kompatibler zur Welt macht, Positiv zugerechnet wird es uns augenscheinlich nicht. Wir haben deshalb auch entschieden, dass diejenigen ohne Wartungsvertrag einen solchen Support künftig nicht mehr bekommen. Weil eine Hand wäscht die andere.

mclb hat geschrieben: ↑Do Mär 21, 2024 10:00 amIch habe zwar kein Konkurrenzprodukt im Einsatz, allerdings kann ich mir gut vorstellen, dass es dort mit Updates, oder gar Upgrades, auch nicht besser aussieht. Ist allerdings nur eine Einschätzung.

Einfach mal googlen nach "Sicherheitsupdate Loxone" oder in Verbindung mit einem anderen Hersteller. Ich habe nüscht gefunden.

Bei Loxone ist es ohnehin schwer das zu beurteilen, weil die haben nach meinem Kenntnisstand ein eigenes OS entwickelt. Der Miniserver der ersten Generation, von dem eine ordentliche fünfstellige Anzahl in Verteilungen eingebaut ist, kann noch nicht mal TLS (und wird es auch nie können, weil der Prozessor das nicht schafft). Andere, wie Doorbird, mussten ihre HTTP-API extra umbauen, dass man die auf unverschlüsselt stellen kann, damit man diese Miniserver mit der Doorbird verbinden kann.

Oder schaut mal, auf welchem Stand die Smartserver-Produkte anderer Hersteller wie Gira, Hager, Jung, Merten usw. laufen.

Aber bei uns gibt es eine Diskussion, weil wir die Patches für ein öffentlich bekanntes, gut erforschtes und Code-reviewtes Stock Debian Betriebssystem erst nach einem Feldtest für alle freigeben, damit es keine Überraschungen mit der Stabilität gibt. Wobei jeder die Patches auch gleich haben kann und dafür eben den Insider Club bucht. Ja, der kostet Geld, weil die Betreuung hier intensiv ist und wir dann auch ggfls. gebrickte Server wieder in Ordnung bringen müssen.

lg

Stefan

Hallo zusammen,
bisher bin ich ein eher passiv mitlesender Part, zudem mein TWS z.Z. noch im Karton schlummert und darauf wartet in die KNX Verteilung unseres Neubaus integriert zu werden.
Ich kenne demnach die gesamten "Vorgeschichten" und "Aufreger" die einige Nutzer hier umtreibt nur durch die Lektüre im Forum. Manches mehr, maches weniger gut nachvollziehbar. Aber ich denke, dass mit release der V4 durch kürzere Intervalle der Updates vielen schon geholfen ist. Aber das nur am Rande, darum geht es ja hier primär gar nicht.

Eigentlich finde ich das System von Primär- und Insiderversionen gut. Erinnert mich sehr an AVM oder iOBroker. Wer ein gut getestetes System bevorzugt bleibt auf der Primärversion, wer neue Features ausprobieren will mit dem Risiko, dass es evtl. irgendwo auch haken kann, wählt eine Beta/Insiderversion. Ich bin leider immer gerne bereit mich mit neuen Features zu beschäftigen und dafür auch mal Probleme und Neukonfigurationen in Kauf zu nehmen (auch wenn man meinen sollte, irgendwann mal etwas draus zu lernen wenn mal was schief läuft ). Zumal man hier im Forum gut informiert wird was Stabilität und Probleme anbetrifft.

Gerade dieses Forum erachte ich als ein nicht zu unterschätzendes und herausragendes Merkmal von ElabNet. Natürlich kostet das Geld und Stefan sicher auch die ein oder anderen Nerven - dir und dem Team heirfür übrigens meinen herzlichen Dank - aber man kann sich hier austauschen und findet schnell Hilfe durch User aber eben auch durch das Team!!! Bieten eben nicht viele Firmen an. Ich muss zugeben, dass ich nicht sicher bin, ob ich ohne diese Forum und die oben genannten Vorteile, den TWS angeschafft hätte.

Im übrigen gehe ich davon aus, das ElabNet sehr wohl über die Wichtigkeit und Notwendigkeit von Security-Updates weiß. Ich als "interessierter Laie" muss mich da schon auf die entsprechenden Firmen verlassen. Allerdings sollte sich ElabNet nicht jedes "Layer 8 Problems" annehmen müssen. Es sollte allen klar sein, dass man den TWS nicht bzw. nur über ein VPN nach außen hin öffnet und in meinem internen Netzwerk sind viele potenzielle Risiken irrelevant und es reicht mir, wenn diese in einen nächsten Release gefixt werden.

Lange Rede kurzer Sinn:
Ich finde es eigentlich gut wie es bisher (für mich) läuft und weiterhin angedacht und kommumiziert wurde:

- Sicherheit vor Bugs
d.h. fortführen der Primär- (getestet und sicher) und Insidervierionen (neue Features und Bugfixes, dafür evtl. nicht ganz stable)

- kürzere Updateintervalle (evtl. dann nicht mir so vielen neuen Features)

- das Forum als Anlaufstelle, Austauschmöglichkeit und nicht zu verachtende Representationsmöglichkeit erhalten
(auch wenn ich hier am ehesten Abstriche machen würde, wenn es um Kosten vs Sicherheit gehen würde)

VG
Jörn

Hallo Jörn,

danke.

minjor hat geschrieben: ↑Do Mär 21, 2024 11:29 am- kürzere Updateintervalle (evtl. dann nicht mir so vielen neuen Features)

ich denke auch, dass das viele dann entspannen wird. Anstatt einem sehr großen Laib Bot nach einundeinhalb Jahren wird es künftig viele kleine Brötchen über die Zeit geben.

Wir haben verstanden, dass die Kunden mehrmals im Jahr auf Update drücken und was neues bekommen wollen und setzen das dann auch um. Umfang dann kleiner (wobei wir mit steigenden Stückzahlen schon das Team erweitern wollen).

lg

Stefan

Hallo Stefan

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Danke Yves, Chris für Euren Beitrag

aber, Verzeihung, ist Themaverfehlung.

Sorry aber dann hast Du zwar gelesen aber nicht verstanden, was wir geschrieben haben.


Wenn ich das hier lese:

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Glaubt ihr denn wirklich, dass wir das technisch nicht hinbekommen, aber alles andere was wir zaubern bekommen wir schon hin?

und dann das hier:

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Wenn ich nachher die Entwickler anrufe und sage, stoppt die Arbeit am Ausrollen der IP9 heute, wir pflegen jetzt sofort alle Security Patches ein und geben diesen Stand nächste Woche als V4 für alle raus, dann haben wir nächste Woche auch eine V4 für alle.

dann passt das nicht zusammen! Ich habe geschrieben, dass derartiges nur durch automatisiertes Testen machbar ist. Ich habe auch geschrieben, dass etwas falsch läuft, wenn dafür die Entwicklung still steht und genau das propagierst Du ja damit! "Lasst alles fallen, wir machen jetzt Patching", was dann bis nächste Woche dauert. Das kann es natürlich nicht sein und genau deswegen soll, nein muss, soetwas ganz einfach immer dazu gehören.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Glaubt ihr wirklich, ihr müsstet uns erklären, wie wichtig Security Patches sind? Uns? Ihr kennt doch den Werdegang von ElabNET, wir haben 20 Jahre NUR Security gemacht und das Patchen von Sicherheitslücken war unser Business. Was soll es also, auf uns einzureden, als wenn wir das nicht begreifen würden?

Ja und warum machst Du es dann nicht mehr?

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Die KONKRETE FRAGE war, welchen Preis die Kunden bereit sind dafür zu bezahlen.

Die konkrete Antwort war: Keinen!

Das System up2date zu halten, gehört einfach dazu. Dafür muss man den Kunden nicht auf den Ohren herumreiten.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Konkret in Geld aber auch in potentiellen Stabilitätsproblemen. Und auf letzteres gibt hier niemand eine konkrete Antwort, obwohl ich genau danach gefragt habe.

Was erwartest Du denn hier für eine Antwort? Es wird sich niemand dafür bereit erklären, ein instabiles System in Kauf zu nehmen. Aber genau das ist eben das Problem des Lieferanten und nicht des Kunden.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Wollt Ihr das beim Timberwolf Server haben? Akzeptiert Ihr, dass es durch einen schnellen Patch zu einem Ausfall von einzelnen Leistungsmerkmalen kommen kann? Oder, wenn es ganz Dumm läuft auch der Server gebrickt ist, weil der neue Patch leider die Zeitumstellung zweimal im Jahr nicht mitbekommt oder fehlerhaft umsetzt, so dass alle Timer in der Logik nun um eine Stunde versetzt laufen? Weil das ist der Drawback für schnelle Bereitstellung.

Siehe oben. Meine Intention und mein Vorschlag war ein Lösungsansatz für dieses Problem...

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am 1. Wir KÖNNEN Patches schnell ausrollen. Noch am nächsten Tag, das ist kein Thema

Darum geht's nicht und genau das habe ich ausführlich beschrieben. Genau an dieser Stelle kannst Du aber intern ansetzen und das ganze Prozedere verbessern.

Noch ein Beispiel aus meinem Umfeld: Wir aktualisieren mittlerweile _alle_ Dependencies vollautomatisch. Das heisst, sobald es eine neue Version einer Library oder was auch immer gibt, wird vollautomatisch ein Branch angelegt, auf diesem Branch die Dependency aktualisiert und damit der Testlauf gestartet. Wenn das alles grün ist, gibt es einen PullRequest, um den Change auf den Master zu bringen. Dabei sind wir sogar soweit gegangen, dass gewisse Dependencies vollautomatisch auf den Master gemerged werden, da gibt es nichtmal einen PR dazwischen. Seitdem das so läuft, ist der Wartungsaufwand für die benötigten Abhängigkeiten etc. pp. nahezu auf 0 gesunken resp. beschränkt sich auf das Approval der PRs und ggf. einem Check der Releasenotes. Eben weil es vollautomatisch geht, weil es vollautomatisch getestet wird und weil es jetzt nichts besonderes mehr ist.

Natürlich hat das am Anfang recht derbe Nebeneffekte gehabt aber diese lösen sich in Wohlgefallen auf, wenn das ganze System erstmal auf einem aktuellen Stand ist und all die technischen Schulden abgebaut sind. Genau dann entspannt sich der Wartungsaufwand und das ist es auch, was Chris mit "weniger Druck im Kessel" meint.

Der springende Punkt ist dabei die Testabdeckung und somit ist auch schnell klar, dass es eine Gewichtung braucht, wie weit man das treiben will. Genau hier tritt auch zutage, dass es bei einem Gerät wie dem TW unmöglich ist, sämtliche Konstellationen vollumfänglich zu testen, eben weil das Gerät so viel kann und unterstützt.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am 2. Wir sind auch dafür, weil uns IT-Security sehr nahe liegt

3. ABER wir waren bisher der Annahme, dass Rock-Solid-Stabilität Euch WICHTIGER ist

Das eine schliesst das andere nicht aus!

Nochmal: Ich habe nichts von irgendwelchen Schnellschüssen geschrieben! Ich habe einen Ratschlag gegeben, wie Du aus dem Dilemma der Delivery-Zeiträume vs. der gewünschten Stabilität heraus kommst.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Wir verdienen kein Geld, weil wir ALLES ausgeben für Entwicklung und Support. Es gibt keinen anderen Topf. Also müssen wir was streichen.

Hör doch bitte endlich mal auf mit dem "wir müssen was streichen". Du propagierst ständig, dass ihr agil entwickelt. Dann kannst Du auch nicht irgendwelche Versprechungen machen, mit welcher Version welches Feature kommt! Damit wirst Du niemals aus der Erklärungsnot heraus kommen, warum es nun doch wieder länger dauert.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am testweise läuft Buster bei uns im Labor schon seit einem Jahr auf Testservern, es ist nicht so, dass wir nicht schon längst mit internen Tests angefangen haben).

Ernsthaft? Buster-LTS ist in drei Monaten EOL und eine Extended-LTS gibt's davon nicht. Bullseye wird wohl im Juli diesen Jahres EOL werden, womit das auch nicht wirklich eine Option ist. Und damit sind wir bei Bookworm, released Mitte letzten Jahres.

StefanW hat geschrieben: ↑Do Mär 21, 2024 9:08 am Aber dafür müssen wir was anderes weglassen. Sagt mir doch bitte, was wir dafür streichen sollen:

Gar nichts weglassen sondern
a) die Prioritäten anders setzen resp. so anwenden, wie Du es oben hinsichtlich der ElabNET-Gene schreibst
b) weniger releasebezogen (!) ankündigen sondern eine offene Roadmap propagieren
c) gezielt Werbung machen

Sorry Yves,

Unserer Ansicht nach haben wir beim Timberwolf Server eine Software, die mit unzähligen fremden Geräten und extrem unterschiedlichen Konfigurationen arbeitet und wir hatten bisher den Anspruch, dass diese absolut ohne jedes falsche Zucken funktionieren muss. Das lässt sich nicht mit Unit-Tests vollständig erschlagen, weil es nicht alleine darum geht, ob Software grundsätzlich miteinander funktioniert und die Dependencies beachtet werden, sondern ob es das auch im Feld mit den fremden Geräten auch mit der wildesten Konfiguration tut.

Wir haben ein Konzept, wie wir Patches und den Rollout neuer Software umsetzen, der absolut super funktioniert. Ein Kunde kann ohne jedes Wissen bei einer Hauptversion auf Upgrade drücken und muss sich keinerlei Sorgen machen. Aus guten Erwägungen finden wir dafür ausgiebige Feldtests hilfreich.

Mit Buster habe ich mich verschrieben, wir sind seit einem Jahr beim Testen von Bullseye und jetzt Bookworm. Zuviele Versionen, die mit B anfangen.

Klar kann man der Meinung sein, dass es den Kunden völlig egal sein kann, wie wir das alles lösen. Kein Problem, schaffen wir schon. Auch kostenlos.

Bisher war unser Ansatz, dass wir mit den Kunden in einer Lösungsgemeinschaft auf partnerschaftlichen Ebene zusammenarbeiten. Zur Partnerschaft gehört, dass man die Belange der anderen Seite versteht und versucht zu berücksichtigen. Wenn Euch unsere Belange egal sind "seht doch zu wie ihr das auf die Reihe bekommt" dann werden wir uns darauf einstellen.

Und mit

starwarsfan hat geschrieben: ↑Do Mär 21, 2024 12:28 pm a) die Prioritäten anders setzen resp. so anwenden, wie Du es oben hinsichtlich der ElabNET-Gene schreibst
b) weniger releasebezogen (!) ankündigen sondern eine offene Roadmap propagieren
c) gezielt Werbung machen

machst Du uns zu einem der anderen Hersteller mit einem eher konträren Kunden - Hersteller Verhältnis.

Gut setzen wir die Prio auf Security Fixes und alle zwei Jahre neues OS, kein Problem. Weil muss ich mir echt nicht dauernd vorhalten lassen. Klar lassen wir dafür anderes weg, weil kostenlos ist das für uns halt nicht.

Offene Roadmap haben wir schon. Nix releasebezogen ankündigen? Wir meine schon, dass es gut ist, dass wir uns mit den Kunden über die Reihenfolge abstimmen, weil es durchaus die Freiheit der Entscheidung gibt, was Euch als nächstes wichtig ist. Können wir auch lassen. Aber dann sind wir genauso autistisch wie andere Hersteller. Ob das so gut ist?

Stefan

Hi

Konkret auf die Frage von Stefan: Für mich passt es wie es bis anhin war (mit der grossen Absicht von Euch nach der V4 auch kürzere Zyklen zu haben). Sicherheit ist wichtig ohne Frage. Aber hier bin ich halt auch als Endkunde gefordert (sprich VPN, überlegen was ich alles wie ans Netz hänge). Ich habe da bei ElabNet ein gutes Gefühl.

Gruss
Dani