Wer seine Webseiten auf SSL umstellt, kennt das Problem: eingebundene Bilder, Grafiken, CSS- oder Javascript-Dateien werden hier und dort noch über HTTP aufgerufen, was entweder zu Warnmeldungen im Browser über Mixed Content führt (“Teile dieser Seite sind nicht sicher.”) - oder dazu, dass die “unsicher” eingebundenen Teile nicht nachgeladen werden, mit unschönen Aspekten, wenn Teil des CSS oder des Javascripts plötzlich fehlen.
Das Problem lässt sich natürlich mit einer Volltext-Suche (bspw. nach http:) angehen, aber gerade bei datenbankgestützten Webapplikationen (wie Blogs und CMS) mag der SSL-Check von Jitbit hilfreich sein, der kostenlos bis zu 200 Einzelseiten überprüft.
(Gefunden bei Leitmedium.)
Das Usenet ist zunehmend in die Bedeutungslosigkeit zurückgefallen - ironischerweise sind die zugrundeliegenden Formate und Protokolle heutzutage aber klarer spezifiziert als das zu seinen Hochzeiten der Fall war. NNTP, das Übermittlungsprotokoll mit der größten Verbreitung, war recht gut definiert, erst in RFC 977 von 1986 und dann zwanzig Jahre später in RFC 3977; außerdem kann man den INN wohl als eine Referenzimplementation betrachten.
Mit dem Nachrichtenformat war es da schon schwieriger: Auf RFC 850 von 1983 folgte RFC 1036 von 1987, der während der Blütezeit des Usenets niemals aktualisiert wurde, obschon es bereits 1993 einen Entwurf für einen Nachfolger gab, den sog. “Son-of-1036” (der erst 2010 als historisches Dokument in Form von RFC 1849 veröffentlicht wurde). Der De-Facto-Standard war dann letztlich “Son-of-1036” mit weitgehend ungeschriebenen Modifikationen aus der Implementierungspraxis, während die USEFOR working group der IETF sich unendlich lange vergeblich mit der Erstellung einer Spezifikation abmühte. Als Ende 2009 dann endlich RFC 5536 “Netnews Article Format” veröffentlicht wurde (der zusammen mit RFC 5537 “Netnews Architecture and Protocols” ein umfassendes Kompendium zur Implementation von Newsservern, -readern und allen möglichen anderen Tools rund um das Usenet bzw. Netnews darstellt), waren die großen Zeiten des Usenets bereits Vergangenheit.
"Der Injection-Date:-Header" vollständig lesen
Demletzt stolperte ich über eine unbekannte MAC-Adresse im lokalen Netz - wie sich dann herausstellte, hatte ein Nexus 5x plötzlich eine neue MAC-Adresse für seine WLAN-Schnittstelle.
Die vorige Adresse begann mit dc:0b:, dem Smartphone-Hersteller LG Electronics zugeordnet; die neue Adresse lautete 00:A0:C6:EB:5C:6F, zugeordnet dem Chiphersteller Qualcomm. Und es scheint sich dabei um eine ganz spezifische MAC-Adresse zu handeln, quasi einen Default, der unter bestimmten, nicht ganz klaren Umständen gesetzt wird, wie man nach einer Google-Recherce - neben viel Spekulationen und Unsinn, wie üblich - einem Bericht im Nexus-Help-Forum entnehmen kann.
Ein Reboot hat das Phänomen beseitigt.
Hat ein Mitleser ähnliche Erfahrungen gemacht oder kann das Auftreten des Phänomens eingrenzen? Potentiell kann das mit mehr als einem Nexus 5x im WLAN etwas unschön werden, wenn es zu dieser Änderung kommt, weil sich dann MAC-Kollisionen ergeben …
Man munkelt, dass insbesondere Google eingehende E-Mails unterschiedlich streng filtert, je nachdem, ob sie per IPv6 oder per IPv4 eingeliefert werden.
Google selbst deutet das in seinen Bulk Senders Guidelines durch den Abschnitt Additional guidelines for IPv6 an, und ich hatte verschiedentlich den Eindruck, dass E-Mail, die ich an Adressaten bei Google (GMail, Hosting, …) versende, dort jedenfalls nicht in der Inbox landet. Für Mails an GoogleGroups - die u.a. Mailinglisten mit einem Webinterface und Webarchiv darstellen - kann ich das sogar positiv belegen: versende ich E-Mails über IPv6 nach dort, werden sie zwar lt. Logfile angenommen, dann aber offensichtlich ausgefiltert. Jedenfalls erscheinen sie nie in der GoogleGroup, auch nach mehreren Versuchen und mehreren Tagen nicht. Versende ich dieselbe Mail aber über IPv4, trifft sie binnen Sekunden ein.
"Exim: Mailauslieferung über IPv4 erzwingen" vollständig lesen
phpMyAdmin verwende ich seit über einem Jahrzehnt, um bequem auf die Datenbanken auf meinen verschiedenen Webspaces zugreifen zu können (und diesen Zugriff ggf. auch anderen Nutzern zu ermöglichen). Dabei nutze ich der Einfachheit halber das jeweilige Debian-Paket - je mehr Webapplikationen nicht gesondert aktualisiert werden müssen, desto besser.
Die Standardinstallation hat - aus meiner Sicht - allerdings einen Nachteil: sie macht phpMyAdmin für alle vhosts verfügbar, d.h. unter allen auf dem Server gehosteten “Domains” aufrufbar. Manchmal mag das praktisch sein, wenn man bspw. so für jeden Kunden scheinbar “sein” phpMyAdmin mitliefert; mir gefällt das aber nicht so gut, und sei es nur, weil phpMyAdmin (wie jede verbreitete Webapplikation) regelmäßig “angegriffen” wird (sprich: Bots rufen die URL auf und suchen nach Schwachstellen oder versuchen, das Passwort zu erraten). Lieber würde ich phpMyAdmin nur unter einer “Domain” - einem vhost aufrufbar machen.
"phpMyAdmin nur für einen vhost einbinden" vollständig lesen
Ein Jahr nach dem letzten Distributions-Upgrade stand für meinen heimischen Server das Upgrade auf Debian Stretch an, das (wie immer) allein durch Download und Installation einige Zeit in Anspruch nahm, diesmal aber auch ungewohnt viele manuelle Eingriffe erforderte.
"Von Jessie zu Stretch" vollständig lesen
Nanoc nutze ich schon mehr als drei Jahre zur Erzeugung verschiedener Websites; aber wie das so ist bei verschiedenen und zudem historisch gewachsenen Installationen, je mehr und je komplexer man ein Werkzeug einsetzt, desto größer ist der Angang bei notwendigen Änderungen. Und so habe ich das Upgrade auf Nanoc 4 - über dessen Beta ich damals bereits berichtete - dann auch gut zwei Jahre vor mir hergeschoben.
Nunmehr werden aber endlich alle meine Präsenzen mit Nanoc 4 erzeugt.
"Nanoc: Upgrade von 3.x auf 4.x" vollständig lesen
Vor über zwei Jahren hatte ich im Rahmen einer “Blogparade” über die von mir genutzten Webapplikationen berichtet - und bei einem Rückblick muss ich feststellen, dass sich da kaum etwas verändert hat.
"Webspace-Inventar 2017" vollständig lesen
Alle paar Monate wieder turnt ein - weniger rücksichtsvoller - Crawler vorbei und spidert sich zügig durch alle Einträge meines Blogs. Damit brachte er meinen bisherigen Server gerne an den Rand seiner Leistungsfähigkeit, durfte dieser doch für jeden Link einen php-cgi-Prozess starten. Man merkte das recht schnell an den steigenden Antwortzeiten, und auch interaktiv auf der Shell machte sich die steigende load bemerkbar. Am Ende blieben meist einige php-cgi-Prozesse übrig, die man dann manuell mittels kill entsorgen durfte. (Vielleicht lag auch hier das eigentliche Problem, dass nämlich die genutzten Ressourcen nicht wieder freigegeben wurden. Hinter die Einzelheiten bin ich nie so recht gekommen.)
Die brandneue Maschine hingegen sollte durch FastCGI und massenhaft RAM sowie schnelle SSDs einem solchen Ansturm (auch bei weiterer Verwendung des doch eher schwergewichtigen Apachen) besser gewachsen sein - dachte ich mir. Bis eines Freitagmorgens die E-Mails des Monitoring-System eingingen, die mir mitteilten, dass der Webserver nicht mehr auf Anfragen reagiert. Gar nicht mehr.
"Webserver-Tuning" vollständig lesen
Mein Nanoc-Filter für die juristische Vernetzungsfunktion von dejure.org steht nun in der Version 1.2 zur Verfügung und ist damit - endlich - auch mit der aktuellen Nanoc-Version 4.x kompatibel.
"nanoc-dejure 1.2 released" vollständig lesen
Es gibt zwar nicht sehr viele “eigene” git-Repositories, an denen außer mir noch andere mitentwickeln, aber einige doch schon, zumindest potentiell; und ungeachtet dessen bereitet es mir auch als bloße Spielerei Freude, wenn ich zumindest die Möglichkeit anbieten kann, per Mail über neue Commits zu informieren.
Bisher habe ich das mit dem “eingebauten” - quasi im Lieferumfang befindlichen - Script post-receive-email gelöst, das allerdings optisch altbacken daherkommt und v.a. kein Diff mitliefert. Oft habe ich nach Alternativen geschaut und bin dabei immer wieder über git-commit-notifier gestolpert, das aber irgendwie[tm] bei mir nicht recht laufen wollte.
"git-commit-notifier" vollständig lesen
2014 habe ich mich - mit dem Relaunch dieses Blogs - nach 11 Jahren erstmals ein wenig mit der Community rund um s9y beschäftigt und den einen oder anderen einfachen Bugreport oder Pull Request eingeworfen oder mich im Forum beteiligt.
2015 hat sich der Kontakt - nach dem persönlichen Kennenlernen beim #s9ycamp2015 - intensiviert, ohne dass ich dazu gekommen wäre, mich auch näher mit s9y zu beschäftigen.
2016 habe ich - animiert und betreut durch onli - immerhin einige kleine Änderungen in Plugins vorgenommen; sehr viel Zeit für s9y war in diesem Jahr ohnehin nicht.
"Aufnahme ins Serendity-Entwickler-Team" vollständig lesen
Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …
Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.
"systemd-Unit für srsd unter Debian " vollständig lesen
Ich weiß gar nicht, wie lange ich schon Firefox als Webbrowser verwende - ein Jahrzehnt sicherlich, vermutlich länger. In letzter Zeit bin ich aber zunehmend unzufrieden: nicht nur, dass es mit einigen Webseiten (vor allem “Webapps”) Schwierigkeiten in der Darstellung bzw. Bedienung gibt, das Ding ist vor allem unerträglich lahm und fühlt sich furchtbar behäbig an geworden - und nein, ich habe nicht Hunderte Tabs offen, auch nicht Dutzende, sondern allenfalls mal ein Dutzend.
Auf meinem Desktoprechner (Win7, i7-3770, 8 GB RAM, SSD für die Systempartition mit Programmverzeichnis) benötigt der aktuelle Firefox 54.0.1 rund 7 Sekunden für den Start (vom Anklicken des Icons bis zur Anzeige des leeren Tabs mit den Icons der am meisten aufgerufenen Seiten). Chrome braucht rund 2 Sekunden. Wenn ich Twitter aufrufe, benötigt Firefox gut 18 Sekunden, bis er die Seite so weit geladen hat, dass ich in der Timeline zügig scrollen kann. Chrome braucht 5 Sekunden.
"Firefox und Chrome" vollständig lesen
Wie man mit Let’s Encrypt ganz einfach an SSL-Zertifikate kommt, hatte ich bereits vor mehr als einem Jahr geschildert - mittlerweile übrigens ganz einfach, denn in Debian stretch ist der Let’s Encrypt-Client (der jetzt certbot heißt) nativ dabei und bringt jetzt auch einen fertigen Cronjob mit.
Aber darum soll es heute gar nicht gehen, sondern vielmehr um die Frage, wie man Let’s Encrypt verwenden kann, wenn die entsprechende Webpräsenz mit einem einfachen Passwortschutz - der basic access authentication oder kurz Basic-Auth - versehen ist. Jeder kennt vermutlich das Popup, das nach Benutzerkennung und Passwort fragt; eine nicht sehr elegante, aber dafür mit praktisch keinem Aufwand verbundene Lösung, die zudem alle Dateien in allen Verzeichnissen der Präsenz schützt, nicht nur Scripts, sondern auch - bspw. - Bilder.
"Let's Encrypt und Basic-Auth" vollständig lesen