Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Warum Sie uns auch sehr große Dateien schicken können


Diese Frage kam in letzter Zeit häufiger mal auf: Ein Kunde wunderte sich, warum er uns eine sehr große Baustatik-Datei schicken konnte – die war etwas größer als 70 MB – obwohl doch der Firmen Email-Server auf eine maximale Größe von 20 MB eingestellt ist und größerer Email-Anhänge verweigert.

Die Datei wurde dabei mit dem bekannten Mechanismus der Baustatik verschickt: Also über den Befehl "Dokument versenden" im Datei-Menü.

Unser Trick: Ganz einfach, wir versenden die Dokumente nicht per Email. Smile

Statt dessen passiert folgendes: Die Baustatik kommuniziert mit unserem Webserver ( eigentlich mit: https://services.die.de ) und transferiert die Daten des Dokumentes (natürlich verschlüsselt) direkt an unseren Server.

Unser Webserver speichert das Dokument dann in verschlüsseltem Zustand und schickt dann von sich aus dem in der Baustatik ausgewählten Empfänger eine Mail mit den ebenfalls in der Baustatik vorgenommenen Angaben. Diese Mail wird natürlich über unseren Mail-Server verschickt.

Der Mailserver des Kunden kommt hingegen an keiner Stelle zum Zuge – und darum ist der Versand von Dokumenten durch die Baustatik nicht irgendwelchen Maximalgrößen unterworfen. Einfache Sache, eigentlich….


Änderung unserer Download-URL


Wenn Sie ein Update, ein Demo oder eine Hochschulversion von uns herunterladen – oder wenn der Baustatik-Update-Dienst das für Sie automatisch tut – dann wurden die Daten bisher von einem Server namens “downloads.die.de” heruntergeladen. Das ist ab sofort anders. Der neue Name lautet “diesoftware.blob.core.windows.net”.

Warum ist das so, und wieso der komische Name?

Die Sache ist etwas kompliziert, und darum muss ich für die Erklärung auch ein bisschen ausschweifen. Als Internet Infrastruktur verwenden wir Microsoft Azure. Dort betreiben wir zum Beispiel den Webserver der unsere normale Webseite ausliefert und auch den zweiten für die Blogs: Von dem haben Sie den Text erhalten, den Sie gerade lesen.

Eine weitere Komponente die wir von Azure nutzen ist der “Blob” Storage – dort liegen alle sonstigen Dateien, die Sie von uns herunterladen können. Also zum Beispiel die aktuelle Version des Baustatik Installationsprogramms, die Updates für die Baustatik, das Archiv aller alten Baustatik Versionen und diverse weitere Programme, die Sie von uns herunterladen können.

Der echte Name dieses Blob-Servers lautet “diesoftware.blob.core.windows.net”. Über einen DNS-Eintrag machen wir diesen Server unter dem Name “downloads.die.de” verfügbar – einfach darum, damit wir unseren Domänen-Namen “die.de” im Server-Namen verwenden können.

Nun ist es so, das uns die Sicherheit unserer Kunden am Herzen liegt, und darum verwenden wir bei jeglicher Kommunikation im Web SSL. (Was das genau bedeutet hatte ich hier schon mal beschrieben.). Seitens Azure ist das auch kein Problem bei “normalen” Webservern wie www.die.de – darum sehen Sie in der Adressleiste auch immer ein https vor dem www.die.de, oder aber ein vom Browser eingeblendetes Schloss. Bei den Blob-Storage Servern geht das aber leider nicht – zumindest nicht im Zusammenhang mit sogenannten “Custom domains”. Das bedeutet: Man kann zwar SSL verwenden, aber nur dann, wenn man den “echten” Server-Namen verwendet, aber eben nicht, wenn man den “eigenen” Namen will. Microsoft sagt schon seit geraumer Zeit, das das mal möglich sein soll – aber auch nach mehreren Jahren gibt es da noch immer keinen konkrete Zeitplan.

Wir wollten nun aber nicht länger auf SSL verzichten – und darum ist es notwendig, das wir ab sofort den “echten” Servernamen verwenden.

Mit anderen Worten: Wir haben uns entschieden in Zukunft auf den “schönen” Namen zu verzichten und lieber den “sicheren” zu verwenden.


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.