Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

So überprüfen wir die Stabilität der Software


Seit einigen Tagen suchen wir nach einem Problem in der Baustatik, das sich nur dann manifestiert, wenn man eine ganze Weile mit dem Programm arbeitet. In diesem speziellen Fall handelt es sich um einen Fehler der vor ein paar Tagen bei unseren Testcases aufgefallen war. Das bietet mir die Möglichkeit, mal ein paar Informationen über einen Teil unseres Testverhaltens zu veröffentlichen.

Nachdem ja mehrere Personen an mehreren Standorten an der Baustatik arbeiten, müssen wir irgendwie sicherstellen, das die Veränderungen am Programm nicht dazu führen, das plötzlich andere Ergebnisse herauskommen. Um das zu tun haben wir einen speziellen Server, auf dem einmal pro Nacht eine “aktuelle” Version der Baustatik hergestellt wird. Diese “aktuelle” Version (Das ‘nightly Build’) wird aus allen aktuellen Quelltexten hergestellt und enthält also alle Änderungen, die im Laufe des Tages vorgenommen wurden.

Mit dieser Version rechnen wir dann Testdateien durch, und vergleichen die Ergebnisse der Berechnungen mit Referenzergebnissen aus früheren Berechnungen: Die dürfen sich nicht unterscheiden, sonst ist irgendwas falsch gelaufen. Dazu braucht es natürlich eine ganze Reihe an Dateien – zur Zeit sind das bei uns circa 3500 Stück.

Dabei bietet es sich natürlich an, auch den Verlauf zu protokollieren und auszuwerten. Der Verlauf der Testläufe sieht dann beispielsweise so aus:

image

Wie man schnell sieht, gab es am 18. ein kleines Problem, das dann in den Folgetagen ein großes Problem wurde: Plötzlich wurden nur noch 1000 Dateien berechnet – in allen anderen Fällen gab es einen Programmabsturz. Das ist natürlich nicht tragbar – und Dank unserer Protokolle konnten wir heute auch eine weitere Kurve erstellen: Die enthält den Verlauf der verbrauchten Handles, nach Typ sortiert. (Handles sind eine ‘knappe’ Systemresource, und darum protokollieren wir den Verbrauch an Handles durch die Baustatik auch mit.)

Und diese Kurze sah so aus:

image

Schnell zu sehen: Irgend eine Änderung am Programm zwischen dem 16. und dem 19. führt dazu, das das Programm riesige Mengen an (in diesem Fall) GDI-Handles verbraucht.

Und das ist auch der Grund für den Absturz: Irgendwann bekommt man keine mehr von Windows, und dann gibt es Programmabstürze, weil zum Beispiel Menüs oder Bitmaps nicht mehr angezeigt werden können.

Nachdem wir von allen Änderungen wissen, wer Sie wann durchgeführt hat, brauchten wir nur nach den Änderungen im nun bekannten Zeitraum zu sehen – und hatten das Problem dann auch schnell eingekreist und gelöst. (Davon gehe ich zumindest aus, ein Kollege führt gerade einen manuellen Test durch um das zu bestätigen – normalerweise geht das natürlich automatisch.)

Lange Rede kurzer Sinn: Praktisch, wenn man nicht nur die Testfälle durchrechnet, sondern dabei auch gleich noch das allgemeine Verhalten der Software protokolliert.


Ein kleines Problem mit den automatischen Updates der Baustatik


Die Baustatik ist schon seit geraumer Zeit mit einem Mechanismus für automatische Updates ausgestattet. In den meisten Fällen muss man als Anwender nichts weiter tun, und arbeitet doch immer mit der aktuellsten Version.

image

Wir wir heute festgestellt haben, gilt das für einen speziellen Fall nicht – der betrifft nur wenige Kunden, und das ist auch der Grund, weshalb wir das nicht früher bemerkt haben: Wenn man keinen Work&Cash Vertrag hat, sondern die Software ein bisschen altmodisch gekauft hat, dann gibt es zu dem Kaufvertrag im allgemeinen auch einen Wartungsvertrag, und der kann natürlich ablaufen.

Bei den automatischen Updates spielen nun diverse Dinge zusammen: Zunächst mal prüft das Programm, ob eine gültige Lizenz vorliegt. Ist das nicht der Fall, dann wird die aktuelle Lizenz automatisch von unserem Server heruntergeladen – es gibt also auch automatische Updates für die Lizenzen. Wenn das erledigt ist und dann eine gültige Lizenz vorliegt, wird überprüft, ob es eine neue Programmversion gibt. Ist das der Fall und handelt es sich um eine Work&Cash Lizenz, wird das Update einfach heruntergeladen und installiert. Handelt es sich um eine Kauflizenz wird nur dann eine neue Version heruntergeladen, wenn die noch durch den Wartungszeitraum abgedeckt ist.

Soweit, so gut: Nun ist aber eine Kauflizenz auch dann eine gültige Lizenz, wenn der Wartungszeitraum abgelaufen ist: Man kann das Programm also verwenden, nur neue Versionen können eben nicht installiert werden.

Jetzt also nochmal auf Schritt eins schauen: Neue Lizenzen werden nur dann heruntergeladen, wenn die vorliegende nicht gültig ist. Eine Kauflizenz mit abgelaufenen Wartungsvertrag ist aber gültig – also wird keine neue heruntergeladen. Und danach wird dann kein Update heruntergeladen, eben weil der Wartungszeitraum laut vorliegender Lizenz abgelaufen ist. Sad smile

Wir ändern das. Smile


SSL–warum “sichere” Webseiten


Unser Webauftritt ist schon seit Jahre per SSL "gesichert" - aber was soll das eigentlich? Der Inhalt unserer Webseite ist ja nicht gerade geheim.

Kurze Antwort: Das ganze dient dem Schutz der Besucher – Es ist eigentlich unverantwortlich, Webseiten ohne SSL zu veröffentlichen.

Etwas längere Antwort: Wenn eine Website per SSL geschützt ist, dann hat das für den Besucher keine besonderen Auswirkungen: Der Browser zeigt in der Adresszeile zwar ein spezielles zusätzliches Symbol an, aber sonst ändert sich nichts. (Das Symbol sieht in jedem Browser blöderweise anders aus.)

image

Im Hintergrund passieren aber spannenden Dinge, und die haben damit zu tun, wie die Daten vom Server an den Browser (und auch vom Browser an den Server) übertragen werden: Die werden auf eine spezielle Art verschlüsselt.

Nun wird man sich fragen: Wieso eigentlich? Immerhin handelt es sich um Daten einer Webseite, und die ist ohnehin öffentlich verfüg- und einsehbar. Warum also sollte man deren Daten verschlüsseln – und dann auch nur im Transit, also während die Daten vom Server zum Browser unterwegs sind?

Die Antwort darauf verblüfft: Das passiert, damit niemand diese Daten ändern kann. Klingt nicht besonders überzeugend – denn wie sollte irgendwer diese Daten ändern, und ehrlich gesagt: Warum sollte irgendwer ein Interesse daran haben, dem Besucher unserer Webseite andere Daten zu liefern als die, die wir eigentlich liefern wollen. Klar – man könnte dann die Text ändern die der Browser anzeigt, nur: Warum?

Zunächst mal: Wie könnte man die Daten ändern? Das ist dankbarerweise einfach erklärt: Die vom Webserver gelieferten Daten durchlaufen multiple Computer, bis sie beim Browser des Besuchers angekommen sind. Dazu gehören die Router, die direkt vor dem Server stehen, die Rechner des Internetproviders des Besuchers und zuletzt der Router und der eigentliche Computer des Besuchers. Auf all diesen Systemen läuft Software die die Daten transportiert – und diese Software kann diese Daten tendenziell auch verändern. Soweit ist das ganze einleuchtend: Jeder, der die Daten zwischenzeitlich im Besitz hat, kann die auch verändern.

Stelle sich die Frage nach dem Warum. In der Theorie könnte sich ein Witzbold den Spaß machen, und einfach alle „a“s durch „b“s ersetzen – nur darum geht es nicht. Denn leider sind Witzbolde in den betrachteten Situationen nicht unterwegs – Kriminelle aber schon. Und die verändern keine Buchstaben, sondern fügen den Transportierten Daten gerne Schadsoftware hinzu: So enthält dann eine harmlos wirkende Webseite von einem Hersteller dem man vertraut plötzlich ein Programm das den eigenen Rechner angreift. Und zwar nicht, weil der vertraute Hersteller dieses Programm von seinem Server tatsächlich ausliefert, sondern weil das vom Angreifer „unterwegs“ in die Daten reingeschmuggelt wird.

Klingt nach Science Fiction oder James Bond? Passiert aber tatsächlich – und zwar täglich. Von Angreifern übernommene Router sind keine theoretischen Gedankenspiele, sondern ganz normale Praxis.

Und genau da setzt SSL an: Weil die Daten verschlüsselt sind können Sie auch von Außenstehenden nicht verändert werden – und darum können diese Angreifer auch keinen Schadcode hinzufügen, denn auch das Hinzufügen von Daten ist natürlich eine Änderung.

Lange Rede kurzer Sinn: SSL verschlüsselte Webseiten schützen den Besucher davor, willkürlichen Angriffen ausgesetzt zu werden. Dass die transportierten Daten dabei von Dritten nicht lesbar sind, ist nur ein netter Nebeneffekt.

Mein Rat: Nicht SSL-verschlüsselte Webseiten grundsätzlich meiden.


Was soll der Empfänger-Hinweis im Newsletter?


In allen Newsletter-Emails die wir versenden steht ein Hinweis in dieser Art:

Die bei uns registrierte Adresse des ursprünglichen Empfängers dieser eMail lautet: Mail-Adresse

Bei “Mail-Adresse” steht natürlich eine eMail-Adresse. Wofür ist das gut? Schließlich liest man die Mail ja gerade selbst, und darum ist einem wohl auch bekannt, wer man ist. Und wer darum der Empfänger ist.

Das sollte man zwar annehmen, aber so einfach ist das leider nicht. Wie praktisch alles im Zusammenhang mit eMail ist die Sache manchmal ein bisschen verzwickter. In diesem Fall hat unser Hinweis einen ganz konkreten und einfach zu erklärenden Grund: Viele Menschen ändern Ihre Mail-Adressen häufiger und lassen sich die eMails dann vom alte Account an den neuen weiterleiten. Eine Mail wird also an “a@domain.de” geschickt und von dort aus automatisch an “b@domain2.de” weitergeschickt. Und von dort aus vielleicht noch ein weiteres Mal. Und nochmal…

Und nochmal.

Sowas gibt es nicht oft, aber es kommt vor. In unserem Fall ein paarmal pro Jahr.

Und in solchen Fällen passiert dann gerne folgendes: Der Leser will den Newsletter nicht mehr. Vom Mail-Client aus gesehen ist dem Leser klar: Sein Mail-Account ist “b@domain2.de”. Unter diesem Account wurde die Mail dann auch letztlich empfangen. Also geht man auf unsere Newsletter-Seite und meldet sich mit diesem Mail-Account vom Newsletter ab.

Nur funktioniert das nicht: Unsere Webseite hat ja nur die Mail-Adresse “a@domain.de” – von der Weiterleitung können wir ja nichts wissen. Also wird beim nächsten ankommenden Newsletter geflucht: Die bösen Menschen bei D.I.E. lassen einen nicht “raus”. Nur: Das stimmt nicht, man muss aber wissen, an welche Adresse wird den Newsletter versendet haben, wenn man sich abmelden will.

Und dafür ist der oben genannte Hinweis da. Smiley


Was soll der Empfänger-Hinweis im Newsletter?


In allen Newsletter-Emails die wir versenden steht ein Hinweis in dieser Art:

Die bei uns registrierte Adresse des ursprünglichen Empfängers dieser eMail lautet: Mail-Adresse

Bei “Mail-Adresse” steht natürlich eine eMail-Adresse. Wofür ist das gut? Schließlich liest man die Mail ja gerade selbst, und darum ist einem wohl auch bekannt, wer man ist. Und wer darum der Empfänger ist.

Das sollte man zwar annehmen, aber so einfach ist das leider nicht. Wie praktisch alles im Zusammenhang mit eMail ist die Sache manchmal ein bisschen verzwickter. In diesem Fall hat unser Hinweis einen ganz konkreten und einfach zu erklärenden Grund: Viele Menschen ändern Ihre Mail-Adressen häufiger und lassen sich die eMails dann vom alte Account an den neuen weiterleiten. Eine Mail wird also an “a@domain.de” geschickt und von dort aus automatisch an “b@domain2.de” weitergeschickt. Und von dort aus vielleicht noch ein weiteres Mal. Und nochmal…

Und nochmal.

Sowas gibt es nicht oft, aber es kommt vor. In unserem Fall ein paarmal pro Jahr.

Und in solchen Fällen passiert dann gerne folgendes: Der Leser will den Newsletter nicht mehr. Vom Mail-Client aus gesehen ist dem Leser klar: Sein Mail-Account ist “b@domain2.de”. Unter diesem Account wurde die Mail dann auch letztlich empfangen. Also geht man auf unsere Newsletter-Seite und meldet sich mit diesem Mail-Account vom Newsletter ab.

Nur funktioniert das nicht: Unsere Webseite hat ja nur die Mail-Adresse “a@domain.de” – von der Weiterleitung können wir ja nichts wissen. Also wird beim nächsten ankommenden Newsletter geflucht: Die bösen Menschen bei D.I.E. lassen einen nicht “raus”. Nur: Das stimmt nicht, man muss aber wissen, an welche Adresse wird den Newsletter versendet haben, wenn man sich abmelden will.

Und dafür ist der oben genannte Hinweis da. Smiley


So funktionieren die automatischen Updates


Die Baustatik verfügt über einen Mechanismus, mit dem das Programm automatisch immer auf dem neuesten Stand gehalten wird. Nachdem wir im allgemeinen jeden Monat ein Update (Update-Protokoll ) veröffentlichen, ist das eine ganz praktische Sache.

Dabei gibt es 2 Modi bei den automatischen Updates:

a) Die Installation erfolgt mit Interaktion des Anwenders
b) Die Installation erfolgt zu 100% vollautomatisch: Die neue Version ist “einfach da”

Die erste Geschmacksrichtung kommt immer dann zum Zuge, wenn wir im Rahmen der Installation auch neue Systemvoraussetzungen installieren müssen. Das ist nur selten der Fall, nämlich im wesentlichen, wenn wir auf unserer Seite die Entwicklungswerkzeuge upgedatet haben. Der zweite Fall ist der “normale” – damit werden die meisten Updates verteilt.

Die Sache funktioniert im Wesentlichen so: Auf den Workstations, auf denen unsere Software installiert ist, wird auch ein Windows-Dienst namens “BaustatikUpdateService” installiert. Dieser Dienst verbraucht praktisch keine Ressourcen, da er nahezu immer “schläft”. Circa zweimal pro Tag wacht er aber auf und tut folgendes:

  • Er ermittelt die Version der aktuell lokal installierten Baustatik
  • Er überprüft mit Hilfe unseres Webservers, ob dieser eine neuere Version vorliegen hat.
  • Wenn es eine neuere Version gibt, wird das zugehörige Installationspaket heruntergeladen, und in einem bestimmten Ordner gespeichert. (Es sei denn, das ist zuvor schon geschehen.)
  • Wenn es sich um ein Update mit Geschmacksrichtung ‘A’ handelt, stellt der Dienst dann seine Arbeit ein. Beim nächsten Start der Baustatik findet diese ihrerseits das bereits lokal vorliegende Update und bietet es zur Installation an.
  • Bei einem Update mit Geschmacksrichtung ‘B’ überprüft der Dienst dann, ob die Baustatik gerade betrieben wird. Ist das der Fall, wartet er bis zum nächsten Wachzyklus.
  • Ist die Baustatik nicht in Betrieb, ersetzt der Dienst alle zugehörigen Dateien durch ihre neuen Versionen: Beim nächsten Start der Baustatik ist diese dann upgedatet.

Darum wurden die Downloads angehalten


Seit dem letzten Update verwenden wir ein neues Installationsprogramm. Nachdem das installieren von Software deutlich komplizierter ist, als man vielleicht meinen würde, ist das von unserer Seite aus eine “große” Änderung – und auch eine, die wir nur sehr ungern vornehmen: Der Kunde sieht praktisch keinerlei Veränderung oder Vorteile, gleichzeitig macht die Sache aber sehr viel Arbeit.

Im vorliegenden Fall ging aber einfach kein Weg an dieser Änderung vorbei: Wir hätten die zwar noch ein bisschen aufschieben können, durchgeführt werden musste sie aber.

Wie dem auch sein mag: Bei der Einführung des neuen Installationsprogrammes ging zunächst mal alles glatt: Das war so problemlos, das man eigentlich gleich hätte wissen müssen, das irgendwas nicht stimmt Smiley

Und es stimmte auch prompt etwas nicht: Normalerweise sind ca. 25% aller Baustatik-Installationen innerhalb von 2 Tagen nach der Veröffentlichung eines Updates auch auf dem neuesten Stand. (Innerhalb der nächsten 3-4 Wochen sind dann im allgemeinen nahezu alle Installationen upgedatet.). Der Grund für die schnelle Reaktion sind dabei die automatischen Updates.

Bei der Veröffentlichung des letzten Updates passierte das nicht. Es gab zwar ein paar manuelle Updates, aber der automatische Mechanismus reagierte gar nicht. Nachdem einen ganzen Tag lang keinerlei Updates installiert waren, haben wir die Sache natürlich untersucht - und auf den ersten Blick konnten wir keinerlei Probleme feststellen. Erst mit einem Testsystem auf dem wir manuell die Vorgängerversion installierten und dann Schritt für Schritt den Update-Prozess begutachteten kam es raus: Der Prozess für die automatischen Updates stellt sicher, das wir nicht zufällig “fremde” Software installieren – und um das zu tun, geschehen mehrere Dinge mit den runtergeladenen Dateien. Und eines dieser Dinge ist eine Überprüfung, ob es sich denn auch um das erwartete Programmpaket “DIE Anwendungen” handelt. Im neuen Installationspaket stand da aber dummerweise “D.I.E. Anwendungen” – also mit Punkten. Resultat: Das Update wurde nicht angeworfen. Trauriges Smiley

Daraufhin haben wir die Downloads angehalten, und zunächst mal das Problem mit dem “falschen” Namen gelöst. Dazu brauchte es aber auch eine neue Programmversion, und beim Test der Installation von dieser kam dann raus: Wenn man versucht eine mit dem neuen Installer vorgenommene Installation durch eine neuere Version zu ersetzen, geht das nicht. Das war natürlich schon vorher getestet worden, ist aber beim ersten Test aus unklaren Gründen nicht aufgefallen.

Blöde Sache – und auch der Grund wieso die Updates noch immer nicht gehen: Wird sind noch immer dabei, das Installationsprogramm entsprechend zu korrigieren. Ich nehme an, das das im Laufe des Tages aber geklärt sein wird und darum wird die “richtige” neue Version vermutlich morgen veröffentlicht und die Downloads werden dann auch wieder freigeschaltet.

Wer die Version 147 manuell heruntergeladen und installiert hat, der muss diese leider vor der Installation der nächsten Version manuell deinstallieren. Zum Glück betrifft das nicht viele Anwender. Wen es doch betrifft: Sorry, mein Fehler.


Das monatliche Update kommt nicht an–Warum ?


Wir haben einen kleinen Satz an Telemetriedaten, mit denen wir versuchen, die automatische Updates zu verbessern. In den letzten Monaten hat damit eigentlich alles prima funktioniert – aber übers Wochenende habe ich ein kleines Problem entdeckt: Offenbar ist es so, das wir eine kleine Gruppe an Kunden mit eher schlechter Internetverbindung haben. Die Sache sieht so aus: Der BaustatikUpdateService überprüft in regelmäßigen Abständen, ob die installierte Version der Baustatik älter ist als die verfügbare, und wenn das so ist, lädt er die Installationsdateien für die aktuelle Version herunter. Der Umgang dieser Dateien unterscheidet sich: Es können ein paar hundert KB sein, es können aber auch ca. 200 MB sein – und das letzte Update war etwa in diesem Umfang.

Der BaustatikUpdateService gibt allerdings zur Zeit auf, wenn der Download länger als 100 Sekunden dauert – und einige Kunden haben Internetverbindungen, bei denen das letzte Update eben nicht in 100 Sekunden heruntergeladen werden kann. Ergebnis: Der Update-Vorgang bricht ab und es gibt am nächsten Tag einen neuen Versuch. Im allgemeinen ist die Internetverbindung bis dahin aber nicht besser – und die automatischen Updates klappen dann eben nicht.

Sie können leicht überprüfen, ob das auch bei Ihnen der Fall ist: Wenn auf Ihrem Rechner noch eine ältere Version als 140 läuft, dann ist die Change groß Smiley

In diesem Fall: Einfach das Update manuell aus dem Download-Bereich herunterladen und installieren. Ab dem nächsten Update ist das korrigiert: Ab März sollte der BaustatikUpdateService also auch mit langsamen Internetverbindungen funktionieren.