Sonntag, 17. April 2016
Mein ehemaliger Arbeitgeber Liip erhält regelmässig mediale Aufmerksamkeit — sei es, wenn das Unternehmen wieder einmal einen der begehrten Best of Swiss Web (BOSW) Award gewinnt, aber auch für ihre moderne Unternehmensführung (auf deutsch bei der NZZ), die gelebte Nachhaltigkeit sowie bezüglich der Vorbildsfunktion beim Vaterschaftsurlaub.
Da fährt man am Feierabend wie üblich im Intercity von Zürich nach Bern, und plötzlich poppt einem diese spannende SSID ins Auge:
Well played!
Sonntag, 17. April 2016
Ganz einfach — entweder man verwendet einen Button (siehe den unten verlinkten Artikel), oder aber eine Tastenkombination:
Shift+F3
Tags: Capitalize, Grossschreibung, Kapitälchen, Kleinschreibung, Lowercase, Microsoft, Uppercase, Word
Labels: IT
Sonntag, 17. April 2016
Kürzlich blubberte wieder einmal eine längst fällige Pendenz an die Oberfläche meiner Aufmerksamkeit: Seit langem wollte ich unserem netzwerkfähigen Xerox Phaser 3250DN Laserdrucker den maximalen RAM-Ausbau gönnen.
Gemäss dem Benutzerhandbuch (S. 28 mit der Produktenummer, S. 44 mit der Installationsanleitung) kann ein zusätzliches 128 MB RAM-Modul in den Drucker eingebaut werden; Total stehen dann 160 MB RAM zur Verfügung. Das Modul trägt die offizielle Xerox-Produktenummer 098N02195.
Leider scheinen sich die Web-Shops da draussen nicht ganz einig zu sein, um was für ein RAM-Modul es ich handelt:
Suchen wir das Modul auf Toppreise.ch, erschlägt es einem fast: Das günstigste Angebot beginnt bei 150 CHF (Techmania). Für 128 MB RAM aus dem letzten Jahrzehnt schon gerade etwas viel.
Ich besann mich deshalb auf mein Lager an ausgemusterten RAM-Bausteinen auf dem Estrich. Darunter waren nämlich auch einige SODIMMs, d.h. RAM-Module, die verkürzt sind und so für den Einsatz in Laptops gedacht sind (und offenbar Laserdrucker). Nach einer kurzen Suche stand ich bald wieder vor dem Drucker, öffnete das RAM-Türchen an der Seite und versuchte, die Module einzubauen. Durch die Einbuchtung am RAM-Modul wird sichergestellt, dass man nur ein tatsächlich kompatibles Modul einbauen kann.
Mehrere Male passten die Module wegen abweichender Einbuchtungen physisch nicht in den RAM-Slot hinein. Doch beim letzten Modul, als ich die Hoffnung bereits aufgegeben hatte, klappte es dann wie durch ein Wunder:
Um was für ein Modul handelt es sich?
Leider erkennt der Drucker nur deren 128MB RAM — aber 160MB sind ja mehr als genug, da das Gerät bisher mit mickrigen 32MB auskommen musste:
Tags: 098N02195, 3250DN, Apacer, DDR2, PC133, Phaser, RAM, SDRAM, SODIMM, Xerox, Xerox Phaser 3250DN
Labels: IT
Samstag, 2. April 2016
Vor einigen Tagen habe ich mich entschieden, mein MacBook Air (Late 2010) komplett platt zu machen und OS X El Capitan darauf zu installieren.
Nach der Neuinstallation musste ich auch alle meine MacPorts-Packages neu installieren. Leider gab es Probleme bei der Installation des Pakets monit:
$ sudo port install monit Password: ---> Computing dependencies for monit ---> Configuring monit Error: Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log Error: org.macports.configure for port monit returned: configure failure: command execution failed Please see the log file for port monit for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port monit failed
Ein Blick in /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log zeigte folgende detailliertere Fehlermeldung:
...
:info:configure checking for static SSL support... disabled
:info:configure checking for SSL support... enabled
:info:configure checking for SSL include directory... Not found
:info:configure
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
:info:configure
:info:configure Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1" && ./configure --prefix=/opt/local
:info:configure Exit code: 1
:error:configure Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
:error:configure org.macports.configure for port monit returned: configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
while executing
"portconfigure::configure_main org.macports.configure"
("eval" body line 1)
invoked from within
"eval $procedure $targetname"
:info:configure Warning: targets not executed for monit: org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
:notice:configure Please see the log file for port monit for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log
Der relevante Teil des Logs:
... :info:configure Couldn't find your SSL header files. :info:configure Use --with-ssl-incl-dir option to fix this problem or disable :info:configure the SSL support with --without-ssl ...
MacPorts openssl war aber installiert und die Header-Files fanden sich im Pfad /opt/local/include/openssl. Den Pfad hatte ich mit einer Suche nach ssl.h ausgemacht.
Nach mehr als einer Stunde Google-Suche war ich immer noch nicht weiter. Da kam mir der Geistesblitz: Das configure-Script von monit wird die SSL-Headers wohl im Standardverzeichnis suchen. Offenbar gibt es dieses Verzeichnis nicht, weshalb die Installation scheitert … wenn ich aber herausfinde, wie das Standardverzeichnis lautet, kann ich dieses mit einem Symlink auf das MacPorts-Verzeichnis umbiegen und die Installation sollte durchlaufen.
Gesagt, getan. Als erstes startete ich in einem Terminal-Fenster die Installation von monit:
$ sudo port install monit
In einem zweiten Tab führte ich dann folgenden Befehl aus, um alle Zugriffe auf das Dateisystem zu loggen:
$ sudo fs_usage
Nachdem das Tab mit dem MacPorts-Befehl wieder „bash“ als Titel anzeigte, stoppte ich fs_usage mit Ctrl-C. Anschliessend kopierte ich den ganzen Text in eine Textdatei, speicherte diese auf dem Desktop ab und begann, den Text zu greppen.
Ganz am Schluss der Aktivitäten kam heraus:
... 18:17:53 stat64 /usr/include/sys/_pthread/_pthread_key_t.h 0.000008 clang 18:17:53 stat64 /usr/include/sys/_types/_fsblkcnt_t.h 0.000008 clang 18:17:53 stat64 /usr/include/sys/_types/_fsfilcnt_t.h 0.000008 clang 18:17:53 stat64 /opt/local/include 0.000013 clang 18:17:53 stat64 /usr/local/include 0.000005 clang 18:17:53 stat64 /usr/local/include 0.000004 clang 18:17:53 stat64 /Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include 0.000013 clang 18:17:53 stat64 .app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include 0.000007 clang 18:17:53 stat64 /usr/include 0.000005 clang
/usr/local/include tönte vielversprechend nach einem Standardpfad … und Bingo:
$ cd /usr/local/include -bash: /usr/local/include: No such file or directory
Tönt wie ein Volltreffer. Dann versuchen wir es doch einmal damit:
$ sudo mkdir /usr/local/include $ cd /usr/local/include $ sudo ln -s /opt/local/include/openssl .
Alles bereit für den Versuch? Dann los — et voilà:
$ sudo port install monit ---> Computing dependencies for monit ---> Configuring monit ---> Building monit ---> Staging monit into destroot ---> Creating launchd control script ########################################################### # A startup item has been generated that will aid in # starting monit with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo port load monit ########################################################### ---> Installing monit @5.12.1_1 ---> Activating monit @5.12.1_1 ---> Cleaning monit ---> Updating database of binaries ---> Scanning binaries for linking errors ---> No broken files found.
Die Jungs von homebrew haben die Problematik übrigens direkt im config-File gefixt, und zwar mit dem Parameter --with-ssl-dir, welches auf den openssl-Pfad zeigt:
...
def install
system "./configure", "--prefix=#{prefix}",
"--localstatedir=#{var}/monit",
"--sysconfdir=#{etc}/monit",
"--with-ssl-dir=#{Formula["openssl"].opt_prefix}"
system "make", "install"
(share/"monit").install "monitrc"
...
Quelle: homebrew/monit.rb at master
Tags: Header, Headers, include, MacPorts, monit, OpenSSL, port install, port install monit, ssl.h
Labels: Apple, IT
Sonntag, 20. März 2016
Damit der Ookla Speedtest bei mir sauber funktioniert, habe ich mir ein Benutzerkonto angelegt und folgende Einstellungen gemacht:
Von grösster Wichtigkeit ist es, folgenden Server als Standardserver auszuwählen:
Winterthur [CH] - Init 7
(Gemäss dem HTML-Quellcode handelt es sich um den Server mit der Ookla-ID 3026)
Nur so testet man die theoretisch verfügbare Geschwindigkeit zwischen dem eigenen Router, der Telefonzentrale, in welche das Fiber- respektive das Kupferkabel führt, und dem ISP-internen Netzwerk.
Auf der Test-Oberfläche ist dann der Button „BEGIN TEST. YOUR PREFERRED SERVER“ zu wählen:
Noch einfacher geht es für uns Linux-Geeks von der Kommandozeile. Ein findiger Zeitgenosse scheint das Ookla Speedtest-Protokoll reverse engineered und seine Erkenntnisse in einem Python-Script zusammengefasst zu haben.
Nachdem man das Script heruntergeladen und ausführbar gemacht hat, misst man die Geschwindigkeit zum Init7/Fiber7-Speedtest-Server folgendermassen:
$ ./speedtest-cli --server 3026 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Init7 (Switzerland) Ltd. (85.195.234.162)... Hosted by Init 7 (Winterthur) [117.24 km]: 3.615 ms Testing download speed........................................ Download: 584.35 Mbit/s Testing upload speed.................................................. Upload: 498.04 Mbit/s
Tags: Bandbreite, Durchsatz, Fiber7, FTTH, Gbps, Geschwindigkeit, Gigabit, Init7, ISP, Mbps, Ookla, Performance, Speed, Speedtest, speedtest-cli, Winterthur
Labels: IT
Sonntag, 20. März 2016
Ende Januar 2016 wurde unsere Wohnung mit Fiber to the Home (FTTH) von Fiber7 (einer Tochter von Init7) erschlossen. Das konkurrenzlos günstige Angebot umfasst eine symmetrische 1 Gbit/s-Anbindung für weniger als 65 CHF pro Monat.
Die Verbindung zum Internet stelle ich mit einem Asus RT-AC66U und dem optischen Wandler TP-Link MC220L her. Auf dem Asus RT-AC66U lief bis letzte Woche DD-WRT mit dem Release r26332 vom 22. Februar 2015.
Da ich mich beim Besuch der Elektriker von BKW ISP AG dazu entschied, den OTO im Wohnzimmer installieren zu lassen (die Alternative wäre das Büro gewesen), stellte sich mir das Problem, dass ich bis vor kurzem die maximale ISP-Geschwindigkeit nicht testen konnte: In der Stube betreibe ich einige Multimedia-Geräte wie den TV, den Apple TV sowie einen UniFi AP-PRO. Nur der UniFi WLAN-Access Point verfügt über einen Gigabit-Ethernet-Port — doch mit dem Access Point lässt sich die maximale Performance des Internetanschlusses nur schlecht testen.
Ein Geschwindigkeitstest mit der von Fiber7 empfohlenen Apple TV-App Ookla Speedtest zeigte Durchsätze von annähernd 100 MBit/s — sowohl für den Up- wie auch Downstream. Durchaus realistisch, wenn man bedenkt, dass der Apple TV nur mit einer Fast Ethernet-Schnittstelle ausgestattet ist.
Erst als ich von Digitec das lange vergriffene Wirewin Netzwerkkabel (25m, Weiss, STP, Kat. 6, Flachband) Kabel geliefert bekam, konnte ich das Büro direkt mit einem Cat 6-Netzwerkkabel erschliessen. Ich schaffte es, das Kabel der Fussleiste entlang und unter zwei Türleisten hindurch zu verlegen und so die zwei Gigabit-Switches TP-LINK SG1016D (Büro) und ZyXEL GS1100-8HP (Stube, mit PoE) miteinander zu verbinden.
In der Zwischenzeit verwendete ich ein Powerline-Produkt namens Devolo dLAN 500 duo+, um Stube und Büro über die Stromverkabelung zu verbinden. Der Frevel an der Sache: Ganze 50 MBit/s brachte ich so über die Leitung.
Nun also waren der Mac mini und der iMac mit Gigabit-Ethernet an den Internet-Router angebunden. Voller Spannung startete ich den ersten von Init7 gehosteten Ookla Speedtest vom Mac mini aus — und erhielt mehrmals in der Folge folgende Messwerte zu Gesicht:
Was zum Teufel? Verkauft mir Fiber7 vielleicht nur ein Zehntel des angepriesenen Durchsatzes?
Um das Problem einzugrenzen, teste ich als erstes das soeben verlegte Netzwerkkabel: Auf dem Mac mini startete ich iperf im Server-Modus:
$ iperf -s
Dann ging ich ins Wohnzimmer und verband einen Toshiba-Laptop mit integriertem Gigabit-Port an den Switch im TV-Schrank und lud mir iperf in der Version 2.0.5-3 auf den Rechner. Ich öffnete eine Kommandozeile und führte folgenden Befehl aus:
$ iperf -c 10.1.2.3
Der Mac mini zeigte darauf folgende Durchsätze an:
------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------ [ 4] local 10.1.2.3 port 5001 connected with 10.1.2.4 port 56432 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 721 MBytes 604 Mbits/sec ...
Am Ethernet-Kabel von der Stube ins Büro konnte es also definitiv nicht liegen.
Ich schloss den Laptop per Kabel direkt an den Router an und führte den Oookla-Geschwindigkeitstest erneut durch: Auch hier wieder der „mickrige“ Durchsatz in der Grössenordnung von Fast Ethernet (100 Mbit/s). Lag das Problem allenfalls am Geschwindigkeitstest, bspw. am Server von Fiber7?
Ich machte mich auf die Suche nach einem im Internet verfügbaren iperf-Server und wurde auf der iperf-Web-Site fündig: Public iPerf3 servers. Ich wählte debit.k-net.fr, installierte auch noch iperf 3 und führte dann den Test aus:
$ iperf -c debit.k-net.fr
Auch bei dieser Aktion kam ich nicht nur annähernd in die Nähe der erwarteten 1 Gbit/s. Somit war für mich bewiesen, dass das Problem zwischen Router und dem ISP liegen musste. Doch wo genau?
Langsam aber sicher wuchs in mir das Misstrauen gegenüber der Frickelware DD-WRT. Was, wenn die Open Source-Firmware die Performance des Routers einbrechen liess?
Ich informierte mich im Netz über die offizielle Firmware des Routers und durfte erfreut feststellen, dass das letzte Update kürzlich, am 28. Januar 2016, veröffentlicht worden war. Nach einer kurzen Recherche stiess ich auch auf die vom User „Merlin“ modifizierte Version der Firmware. Ich entschied mich, den Firmware-Wechsel zu wagen und zog Asuswrt-Merlin in der Version RT-AC66U_380.57_0 dem offiziellen Firmware von Asus vor.
Bevor ich aber das Vorhaben startete, entschied ich mich angesichts eines im April bevorstehenden Routerwechsels zwei Funktionalitäten vom Router weg auf einen Linux-Server zu verlagern: Den DHCP-Server sowie ein OpenVPN Site-to-Site-VPN zu meinem Elternhaus. Wie ich erst zu dem Zeitpunkt realisierte, gehört solche Funktionalität nicht auf einen Consumer-Router, sondern auf einen schicken, kleinen Linux-Server (Intel NUC), welcher ein „anständiges“ Linux, ausreichend Speicherplatz und Subversion-Anbindung möglich macht.
Wie in einem Artikel auf DD-WRT beschrieben, setzte ich den Router über das DD-WRT auf die Werkseinstellungen zurück. Anschliessend lud ich über das Web-Interface die Firmware (.trx) auf den Router und wartete den Transfer sowie die Installation ab. Der Router kam problemlos hoch und erschien nun mit der neuen, standardmässigen Oberfläche.
Nach einem erneuten NVRAM-Reset funktionierte auch die Konfiguration: Das NVRAM voller DD-WRT-Variablen wurde beim Rücksetzen nämlich irgendwie nicht gelöscht und überschritt plötzlich das maximal mögliche Volumen von 65 KB, weshalb die Routeroberfläche subtile Fehlfunktionen und Fehlermeldungen aufwies.
Nachdem ich die Konfiguration des Routers abgeschlossen hatte, führte ich voller Spannung den nächsten Speedtest durch. Hatte sich der Aufwand, der mich fast das gesamte Wochenende gekostet hatte, gelohnt?
Beruhigt lehnte ich mich in den Bürosessel zurück und feierte innerlich der Beginn des nächsten Breitbandzeitalters.
Tags: Asus, Asuswrt, Asuswrt-Merlin, DD-WRT, Fiber, Fiber7, FTTH, Init7, RT-AC66U
Labels: IT
Mittwoch, 2. März 2016
Seit Ende Januar 2016 ist unsere Wohnung mit 1 GBit/s FTTH von Fiber7 gesegnet. Ich betreibe dazu einen Asus RT-AC66U-Router mit DD-WRT an einem TP-LINK MC220L. Vereinfacht gesagt wandelt das TP-LINK-Gerät die Lichtsignale vom OTO herkommend in elektrische Ethernet-Signale um.
Bei der Aufschaltung unseres Anschlusses musste ich zwei Dinge beachten:
Einerseits spricht der TP-LINK MC220L ausschliesslich mit Gigabit-Ethernet-Anschlüssen. Zu Testzwecken wollte ich einen uralten Apple AirPort Express an den Wandler anschliessen, doch auf Grund des 100 MBit/s-Ethernet-Ports des AirPorts war kein Uplink zu finden. Zum Glück erfuhr ich recht schnell von diesem „Feature“.
Andererseits erstellte ich mir aus dem Online verfügbaren PDF-Handbuch des Wandlers folgenden Screenshot, um die LEDs zu deuten:
Die Verbindung funktioniert (bei mir), wenn die LEDs PWR, LINK FX sowie LINK TP ständig leuchten und die LED TP RX entweder ebenfalls ständig leuchtet oder zumindest blinkt.
Tags: Fiber, Fiber7, FTTH, Init7, LED, LEDs, MC220L, OTO, TP-LINK
Labels: IT
Mittwoch, 2. März 2016
Als ich gestern meine lokale Oracle Java-Installation aktualisieren wollte, stutzte ich einige Sekunden, als mir die Software-Firewall Little Snitch folgende Warnung anzeigte:
Erst als ich mir die Details zum Internet-Host anzeigen liess, beruhigte sich mein Puls wieder: Die IP-Adresse 77.109.137.184 gehört zum Akamai CDN, scheint aber früher einmal für m2.feiwei.tv registriert gewesen zu sein. Ich nahm das Risiko auf mich und erlaubte die temporäre Freigabe von Verkehr zu diesem Internet-Host.
Tags: Akamai, feiwei.tv, Firewall, Java, Little Snitch, Sicherheit
Labels: IT
Freitag, 5. Februar 2016
Mit Blick auf den Mitte Januar 2016 bestellten Glasfaser-Anschluss von Fiber7 habe ich mich entschieden, das heimische WLAN aufzurüsten (nicht zuletzt, weil ich den Router wegen des Glasfaseranschlusses in der Stube nicht am selben Ort betreiben möchte wie den Wireless Access Point). Hierzu habe ich die WLAN-Funktionalität meines Asus RT-AC66U deaktiviert und mir danach einen Ubiquiti UniFi AP-Pro n450 angeschafft, mitsamt eines PoE-Switches von TP-Link.
Eine Besonderheit des UniFi-Access Points ist es, dass er selber keine Web-Oberfläche zur Konfiguration anbietet, wie es Consumer-Geräte sonst tun (auch eine Router-Funktionalität sucht man vergebens). Stattdessen benötigt man den sog. UniFi Controller, eine auf Java und MongoDB basierende Software, die auf einem Rechner im heimischen LAN installiert werden muss. Die Software muss übrigens nicht ständig laufen — wenn man die Konfiguration des APs abgeschlossen hat, benötigt der AP keine ständige Verbindung mehr zum Controller. Ich entschied mich gegen diese Lösung, da ich den Controller jederzeit zugriffsbereit und funktionstüchtig haben möchte — man weiss ja nie. Ausserdem zeichnet die Software in dem Modus Vitalparameter des APs und der WLAN-Netzwerke auf.
Zuerst hatte ich den UniFi Controller auf meiner „Workstation“, einem Mac mini, installiert, welcher ständig läuft. Da mir dabei nie wirklich wohl war, entschied ich mich, den alten Raspberry Pi 1 auszugraben und den Controller darauf zu installieren. Das ist insofern etwas weniger trivial als bei einem x86-Server, weil die ARM-CPU andere Softwarepakete benötigt (insbesondere MongoDB). Ich habe es dank Anleitungen im Internet trotzdem hingekriegt (das Material wird dereinst zu einem eigenständigen Blog-Artikel verwurstet). Da ich anschliessend auch Smokeping auf dem Raspberry Pi installierte und mir die Performance zur Generierung der RRDtool-Graphen überhaupt nicht mehr reichte, entschied ich mich diese Woche, auf einen (gebrauchten) Intel Next Unit of Computing NUC DC3217IYE zu migrieren. Mitkommen sollte auch der UniFi Controller.
Da ich das Spielchen bereits einmal gemacht hatte, hier die im Grunde recht triviale Anleitung (Kurzfassung):
Soweit so gut. Als nächstes muss man sich per SSH auf den Access Point verbinden — bei mir völlig ohne Interaktion, da ich den Access Point mit meinem SSH Public Key ausgestattet habe:
$ ssh unifi
Anschliessend startet man das CLI des lokalen Management Utility:
# mca-cli
Dort gibt man folgenden Befehl ein:
$ set-inform http://10.0.1.12:8080/inform
Wechselt man nun in den Browser zur Web-Oberfläche des neuen UniFi-Controllers, leuchtet WLAN grün — der Access Point wurde in der Zwischenzeit erkannt.
Voila, that’s it!
PS Eins: In Anleitungen im Netz liest man gelegentlich, dass man den AP im Web-GUI noch „adoptieren“ und danach noch einmal den set-inform-Befehl ausführen müsse — bei mir klappte dies auch ohne.
PS Zwei: Der alte UniFi-Controller lief unter 4.7.6, der neue läuft unter 4.8.12. Beim Import der Backup-Konfiguration gab es keine Probleme.
Tags: Debian, mca-cli, Migration, Raspberry Pi, set-inform, SSH, Ubiquiti, UniFi, UniFi Controller
Labels: IT
Freitag, 11. Dezember 2015
Seit dem 4. Dezember kann man seine bei Cyon gehosteten Web-Sites mit HTTPS-Verschlüsselung ausliefern. Wenige Stunden nach der Freischaltung dieser Funktionalität hatte ich alle meine Web-Sites mit ein paar Klicks in my.cyon einem kostenlosen HTTPS-Zertifikat von Let’s Encrypt ausgestattet. Ab dem Zeitpunkt konnten manuell verschlüsselte Verbindungen aufgebaut werden.
Damit die Web-Sites standardmässig über HTTPS ausgeliefert werden und Verbindungsversuche über HTTP automatisch nach HTTPS umgeleitet werden, erfasste ich im wwwroot jeder Domain folgenden Eintrag in die .htaccess:
...
RewriteEngine On
RewriteCond %{HTTPS} =off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]
...
Via: Wie kann ich Besucher meiner Website auf SSL und HTTPS umleiten?
Heute nun aber die nächste Herausforderung: Eine selber geschriebene Web-Applikation soll auf dem Produktionsserver (bei Cyon) alle Anfragen auf HTTPS umleiten, während in der Entwicklungsumgebung nur HTTP verwendet wird.
Auch dies biegt man über einige mod_rewrite-Anweisungen .htaccess so hin, dass man dieselbe .htaccess sowohl in der Entwicklungs- als auch in der Produktionsumgebung verwenden kann:
...
RewriteEngine On
RewriteRule .* - [E=ENVIRONMENT:dev]
RewriteCond %{SERVER_NAME} subdomain.domain.tld$
RewriteRule .* - [E=ENVIRONMENT:prod]
RewriteCond %{ENV:ENVIRONMENT} prod
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
...
Via: Local .htaccess environment conditionals, HTTPS example
Es empfiehlt sich zudem, das verwendete Protokoll durch die Applikation überprüfen zu lassen und Assets, die von anderen Web-Sites geladen werden (bspw. Google-Schriften), ebenfalls mit HTTPS anzusprechen. Sonst kriegt man bei Firefox kein grünes Schloss in der URL-Leiste und Safari weigert sich, die Schriften über eine unsiche
Labels: IT
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |
You are currently browsing the archives for the IT category.