Skip to content

WRT54GL-Firmware 4.30.17 considered harmful?

Ich nutze (bislang) für meine Netzanbindung noch einen guten alten WRT54GL, dem ich Anfang des Jahres die aktuelle Firmware 4.30.17 in der europäischen Version spendiert hatte, die - jedenfalls - den optischen Eindruck im Webinterface verändert bat (und natürlich auch einige Änderungen unter der Haube enthielt).

Bisher war ich damit ganz zufrieden - am Wochenende war allerdings plötzlich das WLAN weg: LED aus und kein Netz. Nachdem (aufgrund der unglücklichen Position des Telefon- und damit auch DSL-Anschlusses) alle Rechner ausschließlich drahtlos im Netz sind, war das etwas ungeschickt. Mehrfaches Stromlos-Machen blieb ergebislos. Auch ein Factory-Reset mit nachfolgendem Laden der (glücklicherweise gespeicherten) Config über einen flugs per Netzwerkkabel angeschlossenen Laptop half nicht weiter: keine LED, kein WLAN.

"WRT54GL-Firmware 4.30.17 considered harmful?" vollständig lesen

Mobiler Datenhunger

Vor rund zwei Jahren berichtete ich über meine früheren und derzeitigen mobilen Datentarife und tat in diesem Zusammenhang kund, dass mir jedenfalls für das Smartphone 500 MB monatlich ausreichen würden. Tatsächlich lag mein Bedarf in den Anfangszeiten der Smartphone-Nutzung bei 300 MB im Monat oder weniger, und 500 MB erschienen reichlich.

In den vergangenen Monaten wurde mir aber jeweils schon etliche Zeit vor Ende des Abrechnungszeitraums signalisiert, dass ich die Volumengrenze erreicht hätte - jedenfalls durch das Smartphone. Nahm ich anfangs noch an, dass das Gerät vielleicht etwas zu großzügig zähle, wurde mir später dann bewusst, dass die von mir oft beklagten langsamen Verbindungen möglicherweise Ausdruck der dann greifenden Drosselung sein könnten … Und tatsächlich, mein Anbieter benachrichtigt mich offenbar bei Überschreitung des gebuchten Volumens nicht, sondern drosselt dann schlicht.

Jetzt habe ich 1.000 MB im Monat frei. Mal sehen, wie lange das dann ausreichen wird. (Bisher habe ich trotz recht intensiver Nutzung im letzten halben Jahr als Nutzer der ÖPNV nie mehr als 800 MB erreicht. Das lässt zumindest mittelfristig ja hoffen.)

Wellenreiten 06/2016

Wer als “Websurfer” metaphorisch auf den Wellen des Netzes reitet, findet dabei zwar keine paradiesischen Inseln, manchmal aber immerhin ganz interessante Lektüre.

Im Juni 2016 kann ich u.a. folgende Fundstücke empfehlen und der werten Leserschaft ans Herz legen:

Tips, Tricks & Tech

"Wellenreiten 06/2016" vollständig lesen

Let's Encrypt - Updates

Im April hatte ich über Let’s Encrypt berichtet, den Dienst, der angetreten ist, das Ausstellen und die Installation von Zertifikaten zu vereinfachen.

Der Betrieb lief seitdem gut und zuverlässig, und nachdem jetzt mehr als 90 Tage vergangen sind, kann ich auch berichten, dass die automatische Erneuerung der Zertifikate vor ihrem Ablauf gleichermaßen zuverlässig funktioniert; bemerkt habe ich sie nur durch die Benachrichtigungs-E-Mail meines Cronjobs. Ich bin also weiterhin sehr zufrieden.

"Let's Encrypt - Updates" vollständig lesen

Wer zügig fahren will, fährt mit dem Zug.

Die Aufgabe: freitags nach der Arbeit nach Bremen, am Sonntag nach dem Frühstück zurück nach Stuttgart.

Der Plan: die Bahn. - Befragt, warum ich denn nicht stattdessen fliegen wolle, verwies ich auf den Vorteil einer Bahnfahrt, jedenfalls in der 1. Klasse: bequeme Sitze und einige Stunden Gelegenheit zum Arbeiten, statt ständig warten zu müssen für vergleichsweise kurze Zeitabschnitte und dann auf dem Flug eingeklemmt in engen Sitzen zu hocken. Und was soll auf einer solchen Bahnreise schon groß schiefgehen?

"Wer zügig fahren will, fährt mit dem Zug. " vollständig lesen

Wellenreiten 05/2016

Wer als “Websurfer” metaphorisch auf den Wellen des Netzes reitet, findet dabei zwar keine paradiesischen Inseln, manchmal aber immerhin ganz interessante Lektüre.

Im Mai 2016 kann ich u.a. folgende Fundstücke empfehlen und der werten Leserschaft ans Herz legen:

Tips, Tricks & Tech

Sicher im Netz

"Wellenreiten 05/2016" vollständig lesen

SSB: "Netz 2016"

Logo Netz 2016Im Rahmen des bundesweit nicht völlig unbekannten Projekts “Stuttgart 21” ergeben sich auch im Betrieb der - teilweise unterirdisch verkehrenden - Stuttgarter Stadtbahn Veränderungen: eine unterirdische Haltestelle liegt nämlich den künftigen Gleisen des künftigen Tiefbahnhofs im Weg und muss daher verlegt werden. Diese Haltestelle “Staatsgalerie” ist eine nicht ganz unwichtige Haltestelle: direkt vor (bzw. hinter) ihr liegen nämlich die beiden großen Knotenpunkte des Stadtbahnnetzes, die Haltestellen “Hauptbahnhof” und “Charlottenplatz”; mindestens eine der beiden wird von jeder Stadtbahnlinie berührt. An der Haltestelle “Staatsgalerie” verzweigt sich das Netz also, bzw. es läuft zusammen, je nachdem, aus welchem Blickwinkel man das betrachtet.

Im Rahmen der erwähnten Baumaßnahmen und der Verlegung der Haltestelle wird ab Mai 2016 zunächst einmal die Verbindung von der Staatsgalerie in Richtung Charlottenplatz für - geplant - 15 Monate unterbrochen, und danach dann die Verbindung in Richtung Hauptbahnhof für einen vermutlich längeren Zeitraum. Während der 15monatigen ersten Bauphase wird also die Ost-West-Verbindung durch Stuttgart (Linien U1, U2, U4) an einem zentralen Punkt unterbrochen (bzw. umgeleitet).

Diese nicht unerhebliche Beeinträchtigung kann man natürlich auch positiv zu verkaufen versuchen: als “Netz 2016” - immerhin wird zugleich auch die Verlängerung der U12 nach Dürrlewang eingeweiht, es ergeben sich also nicht nur negative Veränderungen. Lustig aber in jedem Fall das Logo des “neuen Netzes 2016”: die durchgezogene hellblaue Linie ist nämlich die Kennfarbe der verlängerten Linie U12 im Liniennetzplan, und die drei unterbrochenen Linien sind in den Kennfarben der U1, U2 und U4 gehalten. Humor hat man also. :-)

Einzelheiten zu den Änderungen und den neuen Liniennetzplan gibt es auf der Website “netz2016.de” - wo auch sonst?

#s9ycamp2016

Vergangenes Jahr war es mir zu meiner Freude möglich, am ersten Treffen der Serendipity-Community im Linuxhotel in Essen teilzunehmen. Dieses Jahr mangelte es leider an der Zeit, aber es scheint wieder eine schöne und produktive Zusammenkunft geworden zu sein.

Man liest von Arbeiten an der Verbesserung der Infrastruktur des Projekts, dem vielleicht bald bevorstehenden Relaunch der doch arg altbackenen Webseiten (den wir letztes Jahr geplant hatten und der mittlerweile ganz offensichtlich erfolgreich umgesetzt wurde), einem Code of Conduct und der Arbeit an Serendipity 2.1, möglicherweise mit Unterstützung für PHP 7.x.

Mehr darüber bei …

Wellenreiten 04/2016

Wer als “Websurfer” metaphorisch auf den Wellen des Netzes reitet, findet dabei zwar keine paradiesischen Inseln, manchmal aber immerhin ganz interessante Lektüre.

Im April 2016 kann ich u.a. folgende Fundstücke empfehlen und der werten Leserschaft ans Herz legen:

Tips, Tricks & Tech

"Wellenreiten 04/2016" vollständig lesen

Open Graph Protocol und Twitter Cards

Die sozialen Netzwerke - Facebook, aber auch Twitter - besetzen zunehmend den Platz, den bisher andere, offenere Dienste eingenommen habe. Auf Twitter wird diskutiert; Facebook dient sowieso als allgemeine Informationsquelle, Veröffentlichungsplattform, Diskussions- und Kommunikationsmedium, zum Spielen pp. Das ist - glücklicherweise - nicht jedermanns Sache, aber unstrittig ist wohl, dass beide Netzwerke Reichweite haben und auch schaffen können.

Es ist also grundsätzlich keine schlechte Idee, Verweise auf aktuelle Beiträge, bspw. im eigenen Blog, auch dort zu veröffentlichen, was den RSS- oder Atom-Feed nicht ersetzt, ihn aber ergänzen kann. Tweets und Facebook-Posts kann man leicht und ohne Medienbruch an die eigenen Leser weitergeben (Retweet, Sharing), positiv hervorheben und - für die eigene Leserschaft - kommentieren. Ich vermute, dass manch einer RSS gar nicht mehr kennt oder nutzt und auch Blogs allein auf Facebook oder Twitter folgt. Kein Wunder also, dass aktuelle Blogsysteme über Plugins verfügen, die neue Beiträge auf Twitter und/oder Facebook veröffentlichen können (hat Serendipity eigentlich ein Plugin für Facebook?), und sonst hilft oft IFTTT (If this, then that) weiter.

In gleicher Weise kann man aber natürlich auch Hinweise auf andere Seiten aus dem eigenen Webangebot veröffentlichen bzw. - im Jargon der Sozialen Netzwerke - diese Seiten teilen, manuell oder automatisiert: ein neues Tutorial, die Ankündigung einer Tagung oder eines Vortrags, die Einladung zur Mitgliederversammlung oder zum Stammtisch, oder was auch immer von Interesse für andere auf dem jeweiligen Kanal sein könnte und nicht in einem Blogeintrag steckt. Wer das schon ausprobiert hat, wird sich vermutlich darüber gewundert haben, wie es anderen gelingt, diese Ankündigungen mit einem Teaser und einem passenden Bild zu versehen - oder etwas verstört irgendein kleines Icon von der betreffenden Seite plötzlich verzerrt in Übergröße als Vorschaubild wiedergesehen haben (gerne genommen: der stilisierte Briefumschlag, der eine Mailadresse kennzeichnet - oder gar ein Zählpixel). Woran liegt das, und wie macht man das richtig?

Der Schlüssel zur Antwort findet sich in einem Kommentar zu einem älteren Blogeintrag: das Open Graph protocol.

"Open Graph Protocol und Twitter Cards" vollständig lesen

PHP-FPM - jetzt mit mod_proxy_fcgi

Vergangene Woche hatte ich darüber berichtet, wie man - unter Debian Jessie - PHP-FPM mit mod_fastcgi installieren kann. In den Kommentaren hatte Sven mir dann nachfolgend erläutert, wie sich die Einbindung einfacher und besser über mod_proxy_fcgi lösen lässt, vorausgesetzt, man hat (wie in Debian Jessie) einen Apache 2.4 vor sich.

Da mir das ebenfalls vorzugswürdig erscheint, beschreiben ich in der Folge nunmehr diese Variante.

"PHP-FPM - jetzt mit mod_proxy_fcgi" vollständig lesen

Strange things are happening

Nach über einem Jahrzehnt habe ich dieser Tage mal wieder einen Eggdrop installiert und konfiguriert - einen IRC-Bot, für diejenigen, denen letzteres mehr sagt als ersteres. Das ist ganz praktisch, denn u.a. loggt der Bot einen Channel mit, so dass sich aus dem Log ebenso lustige wie unsinnige bunte Statistiken erzeugen lassen, und zum anderen kann er mir morgens das Logfile des letzten Tages mailen, damit ich nichts wichtiges verpasse: FOMO at its best. (Wobei ich gestehen muss, seit Jahren nicht mehr in die Mails hineingeschaut zu haben, aber nun gut.)

"Strange things are happening" vollständig lesen

Das "Erraten" geheimer URLs

Ab und an hat man als Nutzer den Wunsch, ein Dokument, ein Bild oder eine andere Datei mit Freunden, Bekannten oder Kollegen zu teilen. Dafür lassen sich mittlerweile Cloud-Speicherdienste wie Dropbox, Google Drive oder auch Microsofts OneDrive nutzen, die nicht nur Dateien speichern, sondern auch zwischen verschiedenen Rechnern synchronisieren und für Dritte abrufbar machen können. Zumindest früher war es hingegen üblich (und ist vielleicht auch jetzt noch hier und da verbreitet), einfach den eigenen Webspace für diese Zwecke zu nutzen, also die Datei hochzuladen und den Adressaten die URL bzw. den Link mitzuteilen.

Security by obscurity

Gar nicht so selten wurde dabei - und wird auch weiterhin bei den Cloud-Diensten - darauf gesetzt, dass schon niemand den richtigen Dateinamen wird erraten können, so dass auf Zugriffskontrollen (im einfachsten Falle per .htaccess-Datei des Webservers oder vergleichbaren Mechanismen) verzichtet wird. Gerade bei den Cloud-Diensten ist eine Zugriffskontrolle oft auch nur möglich, wenn jeder Nutzer selbst über einen Account bei diesem Dienst verfügt, was nicht immer der Fall ist. Diese Vorgehensweise stellt natürlich ein kalkuliertes Risiko dar, geht aber meistens wohl gut - wenn man die simple Vorsichtsmaßnahme beachtet, seinem Webserver zu verbieten, Verzeichnisinhalte anzuzeigen, und wenn die URL nicht auf irgendeine Weise Dritten - insbesondere einer Suchmaschine - bekannt wird. Letztere Gefahr sollte man nicht unterschätzen; führt bspw. aus dem zu teilenden Dokument ein Hyperlink zu anderen Inhalten, übermittelt der Browser die “geheime” URL in der Regel als Teil des Referer-Headers. Als böse Falle können sich auch Webserver-Zugriffsstatistiken erweisen, die ungeschützt im Netz stehen, oder auch Browser und deren Add-Ins, die zu welchem Zweck auch immer die Adressen der besuchten Webseiten bzw. -dokumente an Dritte übermitteln, oder Proxy-Server, oder ungesicherte WLANs, oder … Insgesamt erscheint das Risiko jedoch überschaubar.

Wirklich problematisch allerdings wird es, wenn die “geheime” URL sich erraten oder durch simples Ausprobieren erreichen lässt. Und dieses Problem haben - prinzipbedingt - die beliebten URL-Verkürzer wie bit.ly, goo.gl und Co.

"Das "Erraten" geheimer URLs" vollständig lesen

Goodbye, Greenmeadow!

1996 habe ich das erste Mal eigene Seiten ins Netz gestellt (wir wollen nicht darüber reden, welchen Inhalts oder welchen Aussehens).

2000 habe ich die ersten Gehversuche mit PHP gemacht.

2002 habe ich das erste Mal einen Server gemietet.

2005 fand der letzte Relaunch meiner Homepage statt (jaja, das Grauen!); zugleich habe ich dieselbe und mein 2003 begonnenes, in diesem Zusammenhang auf Serendipity umgestelltes Blog auf einen im Verlauf des Jahres neu angemieteten, gebrauchten und daher (für damalige Verhältnisse und meine finanziellen Möglichkeiten) recht gut ausgestatteten Server umgezogen: Greenmeadow.

"Goodbye, Greenmeadow!" vollständig lesen

PHP-FPM mit Debian Jessie

Statische Webseiten sind nett (und durchaus wieder im Kommen), aber zumindest für manche Zwecke sind dynamisch generierte Seiten und die auf diese Weise ermöglichte Interaktivität doch dann besser oder gar notwendig. Facebook, bspw., würde sich als statische Seite dann doch eher schwierig gestalten.

Die Welt dynamischer Webseiten

Scriptsprachen

Dynamisch generierte Seiten bedingen, dass beim Aufruf einer Webseite nicht nur eine auf dem Server abgelegte Datei angezeigt wird, sondern dass ein Programm dort läuft, das die Ausgabe mehr oder weniger live generiert. Das hat ganz andere Implikationen für die Sicherheit des Servers, denn nunmehr läuft dort von außen erreichbarer Code, der schlimmstenfalls noch durch die Nutzer selbst aufgespielt werden kann. Nicht jeder, der seine ersten Gehversuche mit Scripts macht, hat dabei auch Fragen der IT-Sicherheit ausreichend im Blick - um das Problem einmal stark verharmlosend zu beschreiben. Gerade PHP hat nicht den Ruf, zumindest in den ersten Jahren seiner Entwicklung großes Gewicht auf das Fördern oder gar Erzwingen sicherer Praktiken gelegt zu haben, und viele lern(t)en es vor allem als eine Art Templating-Sprache kennen, die man irgendwie in seine HTML-Seiten einbettet, um ihnen damit eine erweiterte Funktionalität zu verleihen, ohne dabei groß an Konsequenzen zu denken (schuldig, euer Ehren!).

Rechteprobleme

Besondere Schwierigkeiten kommen hinzu, wenn mehr als ein Benutzer auf dem Server Scripts nutzen will. Denn wenn der Webserver bzw. der von diesem gestartete Interpreter das Script ausführen will, muss er es lesen können. Dann muss er aber - logischerweise - auch die Scripts aller anderen nutzer lesen können, was bedeutet, dass Nutzer A ein Sript schreiben kann, mit dem er sich die Scripts von Benutzer B anzeigen lassen kann, samt aller dort gespeicherten Informationen (Datenbankpassworte usw.), ebenso wie Dateien, die Benutzer B anlegt. Und wenn das Script irgendwelche Dateien anlegt (man denke an hochgeladene Bilder), dann werden diese Dateien unter der Nutzerkennung des Webservers angelegt, so dass der Benutzer dann keinen vollen Zugriff darauf hat. Das ist alles etwas unschön, weshalb man schon bald die Möglichkeit geschaffen hat, Scripts (sei es Perl, sei es Python, sei es PHP) unter der Benutzerkennung des jeweiligen Nutzers laufen zu lassen, dem das Script “gehört”.

suexec und suphp

Das schafft zwar andere Probleme, insbesondere im Bereich der Performance, denn nun kann ein Webserverprozess nicht mehr beliebig viele Scripts in parallelen Threads abarbeiten, weil diese ja vielleicht verschiedenen Nutzern gehören, so dass für jedes Script ein neuer Interpreter-Prozess gestartet werden muss, aber es ist doch in der Regel vorzugswürdig.

Für Scripts, die über die CGI-Schnittstelle (ja, ich weiß, das “I” steht schon für “Interface”) gestartet werden, stellt suexec die entsprechende Funktionalität bereit. Für PHP tat das traditionell suphp. suphp gibt es aber in Debian Jessie nicht mehr. Was also tun?

Als Lösung bietet sich PHP-FPM an.

"PHP-FPM mit Debian Jessie" vollständig lesen
tweetbackcheck