Das geht ganz einfach, wenn man sich vowes (kürzlich aktualisierter) Liste bedient:
Quelle: Updated list of impolite Twitter spammers
Montag, 1. August 2016
Das geht ganz einfach, wenn man sich vowes (kürzlich aktualisierter) Liste bedient:
Quelle: Updated list of impolite Twitter spammers
Montag, 1. August 2016
Als Apple im Frühjahr 2016 das iPhone SE vorstellte, war für mich klar, dass ich mich (endlich) so rasch als möglich von meinem in die Jahre gekommenen iPhone 5s trennen würde.
Das Datum des Verkaufsstarts in der Schweiz war bald nach Apples Ankündigung bekannt (der 29. März 2016), doch wann genau das Gerät über den Apple Online Store bestellbar sein sollte war mir nicht klar (mittlerweile weiss ich es: 9 Uhr morgens, Schweizer Zeit).
Kurzerhand richtete ich mir am Tag vor dem angekündigten Verkaufsstart deshalb auf Pingdom einen Check auf die Produkteseite im Apple Store ein. Pingdom ist ein Dienst, der die Verfügbarkeit einer Web-Site alle 5 Minuten prüft und verfügt als „Bonus“ die Möglichkeit, nach einem String in der HTML-Antwort des Web-Servers zu suchen.
Im vorliegenden Fall machte ich mir die Möglichkeit eines „Transaction Checks“ zu Nutze, mit welchem man konkret definieren kann, welches DOM-Element welchen Text beinhalten sollte.
Ich erfasste die Parameter und konfigurierte, dass mich Pingdom alarmieren sollte, wenn der Text
Derzeit nicht verfügbar
nicht mehr auf der Seite iPhone SE 64 GB Silber angezeigt würde (was ich als Indiz wertete, dass die Bestellfunktion nun aktiviert war).
Der Check sah in der Pingdom-Oberfläche folgendermassen aus:
Als DOM-Element machte ich li.as-purchaseinfo-dudeinfo-deliverymsg aus.
Fertig! Und tatsächlich, kurz nach 9 Uhr morgens am 30. März 2016 erhielt ich den Alarm direkt auf mein Smartphone.
Tags: Apple Online Store, iPhone SE, Online Store, Pingdom
Labels: Apple
Sonntag, 17. Juli 2016
(Aktualisiert am 21. November 2021; Auszahlungsdatum der diesjährigen Nebenkosten ergänzt)
Seit Juni 2012 lebe ich mit Stephanie in unserer ersten gemeinsamen Mietwohnung — es handelt sich zudem auch um mein erstes richtiges Mietverhältnis. Das sind nun bereits vier sechs neun lehrreiche Jahre …
Abgesehen davon, dass man der Hausverwaltung ständig hinterherrennen muss (aktuelle Beispiele: Austausch Leuchtstoffröhre im öffentlichen Teil des Kellers; seit einem Jahr vergessene, aus dem Boden herausragende Eisenstangen vom Rückbau der Parkplätze vor dem Haus; jährlich wiederkehrend verstopfte Dachkännel) stört mich als ordnungsliebenden Schweizer Bünzli vor allem der Modus für die Rückerstattung der Nebenkostenabrechnungen.
Im 2012 unterzeichneten Vertrag steht:
Soweit nichts anderes vereinbart worden ist, erstellt die Vermieterin jährlich eine detaillierte Gesamtabrechnung, […]
Ursprünglich ging ich davon aus, dass „jährlich“ bedeutet, dass die Abrechnung per Ende Kalenderjahr erfolgt. Irrtum! Aus Sicht des Vermieters endet die Rechnungsperiode jeweils am 30. April (ich gehe davon aus, dass dieses Datum das Ende der Heizperiode signalisiert). Aus juristischer Sicht wohl zulässig, da im Vertrag nicht explizit steht „zum Ende des Kalenderjahres“.
Gute zweieinhalb Monate nach Ende der Rechnungsperiode (Mitte Juli) erhalten wir dann jeweils die Abrechnung (es muss extrem aufwändig sein, so eine Abrechnung zu erstellen):
Der Vermieter verspricht, Beträge zu unseren Gunsten Ende August an uns zu überwiesen — Nachzahlungen von unserer Seite gab es in den vier sechs Jahren notabene noch nie:
Während der Vermieter sich für die Auszahlung des Überschusses nach der Abrechnung noch einmal eineinhalb Monate Zeit lässt, wäre man als Vermieter gezwungen, Differenzen („Saldo zu unseren Gunsten“) innert 30 Tagen zu begleichen:
[…] wobei Unterschiede zugunsten oder zulasten des Mieters innert 30 Tagen nach Vorlage der Abrechnung auszugleichen sind.
Schöne asymmetrische Ausführung von Vertragsbestimmungen.
Doch jetzt kommt der eigentliche Hammer — wann trifft das Geld tatsächlich ein? Ich habe nachgeschaut:
| 14. Oktober 2013 | 535.05 CHF |
| 25. September 2014 | 724.80 CHF |
| 2. November 2015 | 693.35 CHF |
| 26. August 2016 | 582.25 CHF |
| 25. Juli 2017 | 573.40 CHF |
| 4. September 2018 | 551.10 CHF |
| 27. September 2019 | 565.55 CHF |
| 29. September 2020 | 519.90 CHF |
| 26. August 2021 | 457.50 CHF |
Zusammengefasst:
| 30. April | Ende Rechnungsperiode |
| Mitte Juli | Erhalt Brief Nebenkostenabrechnung |
| 30. August | versprochene Überweisung des Überschusses |
| Ende Juli-Anfang November | effektive Überweisung des Überschusses |
Im derzeitigen Tiefzinsumfeld fallen in den fünf bis sechs Monaten zwischen Abrechnung und Auszahlung zum Glück kaum Zinsgewinne an. Störend ist es aber allemal, und festigt in mir die Abneigung gegenüber Liegenschaftsverwaltungen wie auch Miethäuserbesitzer.
Tags: Kritik, Mieter, Nebenkosten, Nebenkostenabrechnung, Vermieter
Labels: Leben, Schweiz
Mittwoch, 29. Juni 2016
Nach einigem Üben habe ich es geschafft, einen iCalendar-Feed in Microsoft Outlook 2010 auf der Arbeit zu integrieren. Hier das finale Layout, welches keine Fehlermeldungen mehr produziert:
BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:foursquare Check Ins X-WR-TIMEZONE:Europe/Amsterdam CALSCALE:GREGORIAN PRODID:-//eMeidi.com//foursquare2ics 0.32//EN BEGIN:VTIMEZONE TZID:Mad X-LIC-LOCATION:Europe/Amsterdam BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:5772a5d6498eef051c12ed37@domain.tld DTSTART;TZID=Mad:20160628T182910 DTEND;TZID=Mad:20160628T183410 DTSTAMP:20160629T190304Z SUMMARY:Bahnhof Bern LOCATION:Bahnhof Bern COMMENT: END:VEVENT BEGIN:VEVENT UID:577297d6488e883164f01dd4@domain.tld DTSTART;TZID=Mad:20160628T172926 DTEND;TZID=Mad:20160628T173426 DTSTAMP:20160629T190304Z SUMMARY:Zürich Hauptbahnhof LOCATION:Zürich Hauptbahnhof COMMENT: END:VEVENT ... END:VCALENDAR
Wichtig war:
Tags: Calendar, Feed, Google Calendar, iCalendar, ICS, Microsoft, Microsoft Outlook 2010, Outlook, Outlook 2010
Labels: IT
Mittwoch, 29. Juni 2016
Vor einigen Monaten wurde ich durch die Ankündigung einer Preiserhöhung beim schwedischen Pingdom aufgeschreckt und sah mich deshalb etwas genauer auf dem Markt für Web-Site-Monitoring herum.
Fündig wurde ich beim us-amerikanischen StatusCake, welches kostenloses Monitoring einer unlimitierten Zahl an Web-Sites bietet — sofern man damit leben kann, das Checks nur alle fünf Minuten erfolgen. Im Nu hatte ich um die 50 Tests eingerichtet — von SSH, OpenVPN, PPTP über ordinäres HTTP/S bis hin zu Dashboards, welche Laufzeitdaten zusammenziehen und mich mittels von 200 abweichenden HTTP-Codes bei Problemen warnen.
Das Monitoring funktionierte wunderprächtig, bis Hostpoint letzte Woche damit begann, von Apache 2.2 auf Apache 2.4 zu migrieren:
Apache Update
21.06.2016, 00:00 Uhr – 31.07.2016, 00:00 Uhr
Wir aktualisieren derzeit auf sämtlichen Server die Apache Version von 2.2 auf 2.4. Dieses Update ist grösstenteils transparent, nur in den unten aufgeführten Szenarien muss eine Anpassung vorgenommen werden. Für das Update wird es eine Unterbrechung von wenigen Sekunden geben.
HTTP/2
Neu Unterstützen wir mit Apache 2.4 das Protokoll HTTP/2. Dieses steigert die Effizienz bei der Kommunikation zwischen Browser und Server: Mehr Durchsatz, mehr Parallelität, weniger Latenz. Vor allem moderne web-2.0-typische Webseiten mit vielen kleinen Resourcen profitieren davon. Voraussetzung für HTTP/2 ist eine TLS geschützte Verbindung (SSL Zertifikat). Dieses steht dank FreeSSL all unseren Kunden zur Verfügung.
…
Quelle: Hostpoint – Statusseite
Wahrscheinlich seit der Migration auf die neue Web-Server-Version meldete StatusCake für jede meiner bei Hostpoint gehosteten Web-Sites Folgendes:
Die konkreten Ausfallzeiten sind:
Zuerst dachte ich mir: Klarer Fall, da hat Hostpoint geschludert.
Ich kontaktierte dementsprechend deren Support am 28. Juni um 14:51 Uhr, um 17:22 Uhr erhielt ich die fachkundige Antwort von Jonas. Mittels eines Auszugs aus dem Domain Log legte er mir glaubwürdig dar, dass die StatusCake Probes den Server der Bibliothek Neuenegg bis heute alle fünf Minuten anpingen:
... 107.170.219.46 - - [28/Jun/2016:16:45:57 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" 107.170.227.23 - - [28/Jun/2016:16:51:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" 217.148.43.202 - - [28/Jun/2016:16:56:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" 37.235.48.42 - - [28/Jun/2016:17:01:29 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" 46.101.110.32 - - [28/Jun/2016:17:06:37 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" ...
Eine manuelle Kontrolle meinerseits zeigte, dass dies auch bei allen anderen oben genannten Servern der Fall war.
Der Web-Server antwortet auf die HTTP/1.1-Anfrage mittels des HTTP-Codes 200 und liefert 8770 Bytes an Daten zurück. Ein kurzer Test mit wget von soeben zeigt, dass das durchaus hinkommt (wget erhält „nur“ 8697 Bytes zurück, also ca. 100 Bytes weniger — dies auf Grund einer Anpassung im Inhalt der Homepage; sprich: vernachlässigbar):
$ wget bibliothek-neuenegg.ch --2016-06-29 19:34:30-- http://bibliothek-neuenegg.ch/ Auflösen des Hostnamens »bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)« … 217.26.52.30 Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:80 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently Platz: https://bibliothek-neuenegg.ch/ [folgend] --2016-06-29 19:34:31-- https://bibliothek-neuenegg.ch/ Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK Länge: nicht spezifiziert [text/html] Wird in »»index.html«« gespeichert. index.html [ <=> ] 8,49K --.-KB/s in 0s 2016-06-29 19:34:31 (49,4 MB/s) - »index.html« gespeichert [8697]
Nun gut. Dementsprechend stellte ich alle wichtigen Infos zusammen, die einem Second-Level-Supporter nützlich erscheinen könnten und kontaktierte am selben Tag um 19:09 Uhr Schweizer Zeit den Support von StatusCake. Dan antwortete mir am folgenden Tag um 11:07 Uhr morgens, ging aber wie von us-amerikanischem Support-Personal gewohnt überhaupt nicht auf mein Anliegen ein. Stattdessen erhielt ich wohl einen Knowledge-Base-Artikel als Standardantwort:
We use a large global network of testing servers, it’s looking to me like you may need to whitelist our IPs on these servers, you can grab our full lists here – https://www.statuscake.com/kb/knowledge-base/what-are-your-ips/
9 Minuten später hatte ich ihm bereits geantwortet (wenn man einen Supporter schon mal „dran“ hat, sollte man ihn nicht mehr gehen lassen): Ich wies ihn darauf hin, dass die Apache Access Logs zeigen, dass die Server alle fünf Minuten Besuch von der Probe bekämen, Whitelisting also definitiv nicht das Problem sei.
Um 15:43 Uhr schrieb mir Dan zurück:
Had a look into this one. The only thing I can see that might be causing this is the introduction of HTTP/2, we don’t currently support this and will be giving a down result for any HTTP/2-only enabled sites.
Immerhin schien er die Status-Seite von Hostpoint aufgerufen und dort gelesen zu haben, dass HTTP/2 eingeführt wurde. Das wäre durchaus ein Ansatz, doch wieso taucht die Probe dann mit HTTP/1.1 in den Logs auf? Ich habe Dan zurückgeschrieben, doch bis jetzt ist noch keine weiterführende Antwort eingetrudelt. Ich bleibe dran!
In der Zwischenzeit kam mir nun auch noch die Idee, dass der Web-Server vielleicht auf Grund des StatusCake User-Agents plötzlich meint, dass die Gegenseite fähig ist, HTTP/2 zu sprechen — und die Verbindung auf HTTP/2 upgradet.
Mit meinem lokal installierten wget probierte ich es aus:
$ wget --server-response --user-agent="Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" https://www.bibliothek-neuenegg.ch/ --2016-06-29 19:47:56-- https://www.bibliothek-neuenegg.ch/ Auflösen des Hostnamens »www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)« … 217.26.52.30 Verbindungsaufbau zu www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden. HTTP-Anforderung gesendet, auf Antwort wird gewartet … HTTP/1.1 200 OK Date: Wed, 29 Jun 2016 17:47:56 GMT Server: Apache/2.4 X-Powered-By: PHP/7.0.7 Set-Cookie: PHPSESSID=dbneu9nses8n52ge8i4esj72b1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Upgrade: h2,h2c Connection: Upgrade, Keep-Alive X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Keep-Alive: timeout=5, max=100 Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 Länge: nicht spezifiziert [text/html] Wird in »»index.html«« gespeichert. index.html [ <=> ] 8,49K --.-KB/s in 0s 2016-06-29 19:47:56 (30,9 MB/s) - »index.html« gespeichert [8697]
Wie man sieht antwortet der Hostpoint-Server brav mit HTTP/1.1 200 OK (wget spricht KEIN HTTP/2; hätte der Server also — nicht-standardkonform notabene — mit HTTP/2 geantwortet, hätte wget mir einen Fehler angezeigt.).
Heute (1. Juli 2016) trudelte kurz nach 11 Uhr morgens eine neue Nachricht zu meinem eigentlich als geschlossen geglaubten Support-Ticket bei Hostpoint ein: Jessica nahm Bezug auf meinen kürzlich veröffentlichten Blog-Artikel und teilte mir mit, dass die Angelegenheit intern noch einmal genauer angeschaut worden war. Sie war es, welche mir in diesem E-Mail den entscheidenden Hinweis gab:
StatusCake scheint NodeJS zu verwenden. Dieses hat einen Bug, wenn Apache einen Upgrade Header mitschickt. Dies ist HTTP-Konform und ist so korrekt.
Sie können die Details in folgendem Threads nachlesen:
NodeJS unable to make https requests when h2 enabled in Apache 2.4.18 #73
http: do not emit `upgrade` on advertisement #4337
Hostpoint hatte mit ein wenig Recherche herausgefunden, dass ältere Versionen von NodeJS HTTP/HTTPS-Verbindungen zu Web-Servern abbrechen, wenn dieser mit einer HTTP/2-Upgrade-Anforderung antwortet. Und irgendwie hatte Hostpoint weiter bemerkt, dass StatusCake höchstwahrscheinlich NodeJS für die Abfragen einsetzt.
Klasse, genau solches Debugging liebe ich an meinem Beruf so sehr — und umso mehr freut es mich, wenn sich Dienstleister in einen Bug verbeissen und alles tun möchten, um diesen zu beheben.
Ich bedankte mich bei Jessica und wendete mich anschliessend gleich Dan von StatusCake zu.
Da ich von Dan seit meiner Rückmeldung nichts mehr gehört hatte, antwortete ich erneut auf sein letztes Mail und beschrieb ihm auf Englisch die von Hostpoint vermutete Ursache hinter dem Problem. Ich hatte ehrlich gesagt nicht viel Hoffnung, dass ich jemals wieder von StatusCake hören würde (Kunde, der (noch) keinen Umsatz generiert, und mit komischen Problemen nervt) — doch ich täuschte mich auch hier.
Um 11:35 Uhr ging meine Anfrage an Dan raus, um 11:44 Uhr (innert 9 Minuten!) lag bereits seine Antwort in der INBOX. Und dieses Mal nichts aus der Büchse, sondern eine tatsächlich auf meine Anfrage Bezug nehmende Antwort.
Dies wahrscheinlich aus verschiedenen Gründen:
Dan schrieb mir:
[…] this has been escalated to our engineers. We are working on this and we will have it sorted asap, it’s a big job so you’ll appreciate that the resolution will not be instant. Sorry if I wasn’t great at troubleshooting this at first – the results we were seeing did not make sense.
Dann warten wir also geduldig, bis StatusCake ihre NodeJS-Installation upgegradet hat …
Tags: Bug, Down, Error, Fehler, Github, Hostpoint, HTTP, HTTP/2, NodeJS, StatusCake, Upgrade, wget
Labels: IT, Web
Freitag, 24. Juni 2016
Da nehme ich offenbar erfolgreich an einem Wettbewerb teil, doch die re-designte Web-Site meldet irgendwie doch einen Fehler:
Mal schauen, ob ich trotzdem gewonnen habe.
Tags: Die Mobiliar, Re-Design, Usability, UX
Labels: Web
Freitag, 24. Juni 2016
Seit einigen Tagen — ich vermute seit der WWDC-Keynote und somit dem Entscheid Apples, Standard-Applikationen auf iOS deinstallierbar zu machen — zeigt mir iTunes 12.4 beim Aktualisieren folgende nervige Fehlermeldung an:
Schlau werde ich daraus aber leider nicht …
Tags: Find My Friends, iTunes
Labels: Apple
Donnerstag, 23. Juni 2016
Comodo bietet kostenlose S/MIME-Zertifikate an, die die Authentizität einer E-Mail-Adresse belegen.
Heute habe ich bemerkt, dass mein letztes Jahr im Mai erstelltes Zertifikat abgelaufen ist, weshalb ich mich daran gemacht habe, ein neues Zertifikat zu lösen.
Leider gab es auf der Homepage des Produkts ein Stolperstein: Klicke ich (heute am 23. Juni 2016) auf den Button Sign Up, erhalte ich einen HTTP 400er zu Gesicht:
Diesen Fehler umgeht man, indem man die anzuspringende URL etwas kürzt und auf einer Seite landet, die dem Design nach noch aus dem letzten Jahrhundert zu stammen scheint:
Application for Secure Email Certificate
Nachdem man die Angaben wahrheitsgetreu ausgefüllt hat (das Revocation-Passwort sicher ablegen; es könnte ein ungerades Mal nützlich erscheinen), erhält man nach wenigen Minuten ein E-Mail, welches einen Link enthält, mit welchem man die Datei CollectCCC.p7s herunterladen kann.
Nach einem Doppelklick wird die Datei in die OS X Keychain eingelesen. Ich wähle dazu die Login-Keychain. Soweit so gut.
Um das Zertifikat in Mail.app unter iOS zu installieren und zu verwenden, muss man es im Format .p12 aus der Keychain exportieren. Hierzu öffnet man unter OS X die Keychain.app und selektiert unter Category „Certificates“:
Nun müssen folgende drei Elemente ausgewählt werden, damit das Zertifikat sauber mit allen Elementen aus der Keychain exportiert und in die iOS Profiles importiert werden kann:
Damit der Export des Private Keys klappt, wird man ganz am Schluss noch nach dem OS X Login-Passwort gefragt:
Anschliessend mailt man sich die soeben erstellte Datei auf die eigene E-Mail-Adresse, öffnet das E-Mail in Mail.app und klickt auf die .p12-Datei. Jetzt wählt man Install, gibt den iPhone-PIN ein und danach das Passwort, mit welchem man den Zertifikatbaum geschützt hat. Schlussendlich taucht das Zertifikat unter Profiles auf. Wenn man das Zertifikat nachträglich noch einmal anschauen möchte, findet man es unter Settings > General > Profiles.
Damit nun ausgehende E-Mails signiert (oder gar verschlüsselt) werden können, muss das Zertifikat noch mit dem betreffenden Mail-Account verknüpft werden: Settings > Mail, Contacts, Calendars > %Name des Mail-Accounts% > Account > Advanced:
S/MIME aktiviert man, Sign aktiviert man auch, wobei unterhalb des Schalters unter „CERTIFICATES“ das soeben aufgeführte Zertifikat aufgeführt sein und links mit einem Gutzeichen versehen sein sollte.
Tags: Comodo, Export, iOS, Keychain, Mail.app, p12, p7s, S/MIME
Labels: Uncategorized
Mittwoch, 15. Juni 2016
Heute fand per Post ein gebrauchter Avocent DSR1031 IPKVM-Switch den Weg zu mir nach Hause. Ich werde den IP-fähigen KVM-Switch im Elternhaus installieren, um im Notfall einen Linux-Server fernsteuern zu können.
Erste Ernüchterung bereits umgehend bei der Verbindung auf die IP-Adresse des Switches: Leider ist das von Acovent auf dem KVM-Switch verbaute Zertifikat im letzten Jahr abgelaufen:
Als erstes aktualisierte ich das Firmware des Geräts auf Version 03.07.01.20, welche ich von der Web-Site des Herstellers heruntergeladen hatte (ich musste den FTP-Link manuell in CyberDuck einfügen; der Download mittels Web-Link klappte partout nicht).
Leider löste dies die Problematik des abgelaufenen Zertifikats nicht — so viel zu Hersteller-Support im SSL/TLS-Umfeld.
Anschliessend musste ich auf Firefox ausweichen, um ein Verbindungsfile hinter einem Link namens „KVM Session“ unter einem vom Vorbesitzer erfassten Device herunterzuladen — Safari zeigte einen Download an, die Datei fand sich aber nicht im Download-Ordner.
Der Klartext der heruntergeladenen Datei zeigte, dass es sich um ein sogenanntes Java Network Launch Protocol JNLP-File handelt:
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for Java Video Viewer Application -->
<jnlp spec="1.0+" codebase="http://10.0.1.227/webstart2">
<information>
<title>Video Session Viewer</title>
<vendor>Avocent</vendor>
<description>Video Session Viewer</description>
<description kind="short">Video Viewer</description>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.5+"/>
<jar href="avctVideo.jar"/>
<jar href="avctVM.jar"/>
<nativelib href="avctWin32Lib.jar"/>
<nativelib href="avmWin32Lib.jar"/>
<nativelib href="avctLinuxLib.jar"/>
<nativelib href="avmLinuxLib.jar"/>
<nativelib href="avctSolarisLib.jar"/>
<nativelib href="avmSolarisLib.jar"/>
<nativelib href="avctMacOSXLib.jar"/>
<nativelib href="avmMacOSXLib.jar"/>
<nativelib href="jpcscdll.jar"/>
<nativelib href="jpcscso.jar"/>
</resources>
...
Diese Datei startet man folgendermassen:
$ javaws -verbose kvm.cgi
Leider erhielt ich mit J2SE Version 8 Update 91 folgende Fehlermeldung zu Gesicht:
Nach einigen Recherchen im Internet fand ich im Support-Forum des Herstellers im Beitrag „AutoView 3016 Java network connect error“ die Lösung.
In der Datei /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/java.security müssen zwei Parameter für den Umgang mit verschlüsselten Verbindungen angepasst werden:
... #jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024 jdk.certpath.disabledAlgorithms= ... #jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768 jdk.tls.disabledAlgorithms= ...
Danach klappte die Verbindungsaufnahme:
Leider habe ich so meine Java-Installation extrem unsicher gemacht. Die Browser-Plugins habe ich seit längerem allesamt deaktiviert, was das Risiko etwas senkt.
Mittlerweile habe ich — selbstverständlich mittels Internet-Resourcen — herausgefunden, wie man die Java-Einstellungen ausschliesslich nur für einen bestimmten Prozess abändert. Hierzu habe ich mir ein Script geschrieben, mit welchem ich den Avocent Viewer starten kann:
#!/bin/bash ... SCRIPTDIR="/path/to/script/dir" ... JAVAWS=$(which javaws) JNLP="$SCRIPTDIR/kvm.jnlp" JAVASECURITY="$SCRIPTDIR/java.security" # http://stackoverflow.com/questions/1047154/java-webstart-options CMD="$JAVAWS -J\"-Djava.security.properties=$JAVASECURITY\" $JNLP &" echo $CMD eval $CMD echo "" exit 0
Im Verzeichnis, in welchem das Bash-Script liegt, habe ich eine Kopie der oben genannten Datei java.security abgelegt und die Anpassungen an der lokalen Kopie vorgenommen (die globale Datei java.security führt nur die sicheren Ciphers auf). Den Pfad zur lokalen Datei übergebe ich Java Web Start mittels einer Kommandozeile -J, in welcher eine Java-Argument verschachtelt ist -D.
Tags: Avocent, DSR1031, DSView, Error, Fehler, Java, javaws, Security, SSL, TLS
Labels: IT