Warmes Licht dringt aus dem Stalltor. Mehr kann ich in der stock-dunklen Landschaft nicht erkennen, die vor meinem Bahnfenster vorbei huscht. Passt ja zu Weihnachten irgendwie. Ich versuche meinen biblischen Vergleich in einen Tweet zu fassen, um der Welt diese gute Botschaft zu verkünden. Die Welt ist aber nicht erreichbar. Seit der ersten Generation Mobilfunk hat sich in diesem Teil von Schleswig-Holstein niemand die Mühe gemacht, neue Antennen zu montieren.

Statt der Stationen an denen heute ohnehin niemand ein- und aussteigt, sollte der Zugführer lieber durchsagen, wenn wir wieder ins Internet einfahren. Auch diese Idee kann ich nicht twittern. Kein Netz und vor dem Fenster ist alles schwarz. Ich wende mich wieder meiner Podcast-App zu. Dort kann ich zuhören wie sich Katja und Henning vom Tech&Tonic-Podcast langsam mit ihrem Interviewgast betrinken. Die haben es gut.

Ich bekomme eine Nachricht. Weihnachtsgrüße von einem Kollegen. Wir sind gerade mal wieder im Internet. Ich grüß zurück und schau, ob ich unseren nächsten Termin auch richtig im Kalender habe. Das Internet reicht gerade noch, meine Facebook-Timeline zu aktualisieren. Dann sind wir wieder aus dem Internet herausgefahren. Ich verschieben das Liken und Teilen auf später.

Der Schaffner kommt vorbei, ich reiche ihm mein Smartphone mit dem Barcode für mein Online-Ticket. Dann bereite ich ein paar Weihnachtsgrüße vor, die ich verschicke, als wir wieder kurz durchs Internet fahren. Katja und Hennings Gesprächsführung wird kreativer. Kurz vor meinem Ziel verschicke ich meine vorbereiteten Weihnachtsgrüße.

Am Bahnhof holen mich meine besten Freunden aus Schultagen ab. Am Tag vor Weihnachten treffen wir uns immer in unserer Heimatstadt. Auch das hat etwas Biblisches. Das zu twittern fällt mir aber nicht mehr ein. Wir setzen uns an den Tresen, wie wir das immer machen, in der Kneipe, in die wir immer gehen. Ich glaube, dort gibt es kaum Handy-Empfang. Aber das ist echt egal, wenn alles Wichtige gerade hier passiert.

Diese Kolumne ist zuerst bei shz.de erschienen.

Dass es bei Cyanogen Inc. nicht so läuft, wie geplant, das ist dem aufmerksamen Techie mittlerweile sicher auch bekannt. Es gab Umstrukturierungen und Entlassungen. Noch im Oktober wollte man neu durchstarten, den Herstellern ein offenes und modulares Android-Betriebssystem für ihre Smartphones bieten. Hat anscheinend nicht geklappt, denn schon im November musste man Büroschließungen und Kündigungen kommunizieren. Nun die letzte Nachricht. Aus Gründen der Konsolidierung von Cyanogen werden man alle Dienste und Cyanogen-unterstützte Nightly Builds bis zum 31.12.2016 eingestellt haben. Nicht betroffen sind der Quellcode und das Open Source-Projekt, womit es weiterhin möglich ist, dass wir alten Smartphones mit dem CyanogenMod wieder neues Leben einhauchen können.

Unser Feed-Sponsor:

Banner

The wider community asked us open source GitLab pages. Inspired by the holiday-spirit we're happy to bring GitLab Pages to the Community Edition (CE) of GitLab.

GitLab Pages allows you to host static websites straight from GitLab, with any kind of static site generator. For instance, my personal website is hosted through GitLab Pages on GitLab.com using my favorite static site generator Middleman (see the source here). Even our documentation site is also fully built on GitLab Pages. Until today, GitLab Pages was exclusive to the Enterprise Edition of GitLab.

When we chose to limit this functionality to EE, we did so based on the reasoning that small teams wouldn’t be interested in this functionality. We thought it met our stewardship criteria that it was more relevant for organizations that have more than 100 potential users.

We thought that small teams would use the option of using GitLab.com (which runs EE) for free. Or that they would set up only one website which is easy to do manually.

Yet, more than a hundred people voted and discussed bringing GitLab Pages to our open-source MIT-licensed Community Edition (CE). We’re always willing to reconsider our decisions and the passionate messages we received were more than enough reason to do so. Of course, for GitLab Inc. this is also a business decision. When we decide to bring a feature from EE to CE, this lowers the relative value of EE and therefore the potential of selling subscriptions. Subscriptions allows us to keep investing in new features, packaging, bugfixing and performance improvements.

In this case, I’m happy to announce that we will be bringing GitLab Pages to the Community Edition. We’ll do this at the earliest convenience, most likely with GitLab 8.16 on January 22nd.

We’re very fortunate that the wider community keeps us sharp. It’s our hope that in the new year, you will continue to support, guide, criticize, and contribute to GitLab.

Want to give Pages a try? Read our documentation here.

Happy holidays!

Seit ein paar Jahren lasse ich meine Server von Uptimerobot.com überwachen. Kürzlich habe ich entdeckt, dass der Monitoring-Service mittlerweile auch öffentliche schaltbare Statusseiten anbietet. Daher habe ich meine selbst gebastelte Statusseite abgeschaltet und wollte stattdessen das schönere Angebot von Uptimerobot nutzen. Die Statusseiten sind über Adressen nach dem Schema stats.uptimerobot.com/<ID> erreichbar, also z.B. https://stats.uptimerobot.com/rk3R0IDJq. Die Adressen sind schlecht zu merken. Viel lieber hätte ich etwas einfacheres, wie z.B. status.trashserver.net. Deshalb kann man die Statusseite auch mit einer eigenen Domain betreiben, indem man im DNS-Record für die jeweilige Domain auf den Uptimerobot-Server verweist. Allerdings schließt das HTTPS aus, denn Uptimerobot müsste dann die Zertifikate für meine Domain besitzen. Aber auch dafür habe ich eine Lösung gefunden:

Was die Einstellungen bei Uptimerobot angeht, belasse ich alles beim alten. Damit die Benutzer nicht die lange URL mit der ID eingeben müssen, habe ich mittels Nginx einen Proxy-Server aufgesetzt, der Anfragen an status.trashserver.net direkt an https://stats.uptimerobot.com/rk3R0IDJq weiterleitet und das Ergebnis zurückliefert. Mit der folgenden Konfiguration kann man dann auch auf die Angabe der ID in der URL verzichten:

server {
    server_name status.trashserver.net;

    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate /etc/myssl/...;
    ssl_certificate_key /etc/myssl/...;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass https://stats.uptimerobot.com/rk3R0IDJq/;
        proxy_redirect off;
    }

    location ~ ^/(.+) {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass https://stats.uptimerobot.com;
        proxy_redirect off;
    }
}