Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Terminänderung für den Münchner Anwenderstammtisch


Der Termin für den nächsten Münchner Anwenderstammtisch hat sich verschoben. Neuer Termin: Montag, 10.07., ab 19:30 im Wirtshaus Maxvorstadt. Auch am neuen Termin ist natürlich jeder willkommen und natürlich haben wir auch wie immer einen kleinen Rechner dabei, um aufgetretene Fragen direkt vor Ort zu klären.

DSC_4261


Raodshow Wien–Nachlese


Am Dienstag dieser Woche fand die erste Veranstaltung unserer Roadshow 2017 in Wien statt. Die kleine aber interessierte Gruppe nahm an mehreren Vorträgen rund um die Baustatik teil – bei den hohen Temperaturen in zum Glück ganz gut klimatisierten Räumen. Hier noch ein paar Bilder (Qualität etwas merkwürdig, habe wohlmit der Kamera irgendwas nicht richtig gemacht )

WP_20170619_18_12_02_Pro WP_20170619_21_25_45_Pro WP_20170620_10_04_35_Pro

Son einen Fernseher will ich übrigens auch Smile.

Die nächsten Termine sind erst in ein paar Wochen und die Anmeldung ist noch geöffnet. Alle Details finden sich hier.


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


Die SPAM-Menge wird langsam lächerlich


Wir verwenden als eMail Server das Programm MDaemon von alr-n und ich bin damit auch sehr zufrieden. Einer der Gründe dafür ist die Qualität der SPAM-Abwehr: Ein einmal im Monat eine SPAM-Email durchkommt bin ich so verwundert, dass ich eigentlich immer erstmal einen Blick auf die Server-Konfiguration werfe – denn eigentlich kommt nie eine durch.

Aus völlig anderen Gründen habe ich heute ebenfalls auf den Server geschaut und bin dabei darüber gestolpert:

image

Etwa 94% aller eingehenden eMail heute wurden durch den “Dynamic Screen” Mechanismus als SPAM blockiert. Wir haben noch ein paar andere Mechanismus – und zusammen ergab das dann folgendes: Über 97% aller eMails, die man heute an uns zustellen wollte waren unerwünschte Reklame. Neues Rekordhoch, wie ich vermute. Eine SPAM-Nachricht ca. alle 45 Sekunden – ich drücke allen die Daumen, die eine etwas schlechtere SPAM-Abwehr haben.


Die Baustatik und Windows-Benutzerprofile mit Roaming


Eine Möglichkeit der Softwareverwaltung unter Windows besteht daraus, das man die Software auf einem Server installiert, und die Benutzer dann per Remote-Zugriff mit der Software interagieren lässt. Dabei gibt es dann noch verschiedene Spielarten. Eine davon ist die, das der entfernt angemeldete Benutzer ein virtuelles eigenes Windows bekommt, das auf dem Server betrieben wird. Das hat den Effekt, das der sich der Benutzer im Prinzip von einem beliebigen Rechner am Server anmelden kann, und immer die gleiche Softwareumgebung erhält. Das ist natürlich schön, lässt aber die Frage offen, wo die verschiedenen Programmeinstellungen bleiben, die man vornehmen kann. (Die eigentlichen Eingabedaten müssen in solchen Fällen im Allgemeinen auf einem Serverlaufwerk abgelegt werden.)

Für die Programmeinstellungen können mehrere Orte verwendet werden und zwei davon sind der “local” und der “roaming” Ordner. Die Baustatik speichert bisher alle Einstellungen im “local” Ordner. Nun gab es eine Kundeninstallation, bei der dieser Ordner im Rahmen des Abmeldevorgangs immer wieder gelöscht wurde – das deshalb, weil der Kunde mehrere solcher Server einsetzt und wohl schlicht den Plattenplatz sparen wollte. (Möglicherweise sollten auch die Anwender nicht verwirrt werden, wenn Sie nicht bei jedem Anmelden die gleichen Softwareeinstellungen vorfinden – der genau Grund dafür ist mir etwas unklar.)

Jedenfalls ist das für den Betrieb der Baustatik einfach nicht förderlich, das man bei jeder Sitzung immer wieder die Grundeinstellungen des Programms vorfindet: Die in der letzten Sitzung vorgenommenen Einstellungen wurden beim letzten Abmelden ja entfernt. Um für solche Umgebungen eine Lösung anbieten zu können, kann die Baustatik ab dem nächsten Update ihre Einstellungen auch im “roaming” Ordner speichern. Wenn man das möchte, ist das einfach zu bewerkstelligen, allerdings anders, als man erwarten würde: Diese Einstellung kann man schlecht im normalen Optionsfenster der Baustatik vornehmen – die dort vorgenommenen Einstellungen würden ja ebenfalls beim nächsten Abmelden entfernt.

Statt dessen erfolgt diese Einstellung über eine Signaldatei: Man muss im Ordner %ProgramData% ( Bei einem aktuellen deutschen Windows ist das der Ordner c:\ProgramData ) eine leere Datei mit dem Namen baustatik.useroaming anlegen. Danach wird nicht mehr der “local” Ordner fürs speichern von Optionen verwendet.


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.