LineageOS – Ein erster Blick

Ich bin seit gut 2 Wochen auf LineageOS unterwegs, nachdem ich vorher schon lange CyanogenMod benutzt habe.

Im Einsatz ist es auf einem Samsung Galaxy Note 10.1 2014 LTE (lt03lte) und einem LG G4 (h815), bei beiden läuft es bisher ohne großen Problemen.

Anfangs hat et etwas gedauert, bis ich auf der Homepage http://lineageos.org/ die Firmware gefunden habe: Community –> Wiki –> devices list. Noch ist das Wiki recht leer, aber nach und nach füllt es sich. Als Anleitung gibt es häufig noch Links zu den archivierten Cyanogen-Wiki-Pages.

Inzwischen geht es auch einfacher über https://download.lineageos.org/

Auf dem Note 10.1 läuft soweit alles Rund, nicht mal die Amazon Prime App hat Probleme gemacht 🙂 Auf dem G4 gibt es noch eine Macke, die ich schon unter Cyanogen hatte: Die Kamera ist recht Zickig, egal ob die Google oder Cyanogen Version. Bilder mit Blitz sind häufig trotz Auslösen einfach nur schwarz und die App hängt sich häufig auf. Ich hoffe, hier wird es noch Besserung geben. Die Kamera des G4 ist eigentlich verdammt gut, wäre schade drum.

Jetzt fehlt nur noch eine passende Version für mein HTC HD2 sowie Motorola Atrix, das werden aber wohl Träume bleiben. Die Geräte sind einfach schon zu alt, schwer da noch passende Kernel Treiber zu bekommen.

Ich bin gespannt wie es weiter geht, hoffe auf eine lange Zukunft.

PS: Wenn jemand über die Update-App ein Update geladen hat uns es dann im Recovery sucht, der Pfad ist (Stand 16.02.2017) /data/data/org.lineageos.updater/app_updates.

WordPress, nginx, htaccess, Plesk…

Ich teste derzeit das eine oder andere Hosting-System, so natürlich auch Plesk.

Bisher gefällt mit das System sehr gut und die Preise sind auch in Ordnung.

Angenehm finde ich die Möglichkeiten, für einzelne vServer unterschiedliche PHP Versionen zu nutzen und auch ein nginx als Proxy vorzuschalten.

Allerdings gibt es genau hier ein Problem in Verbindung mit WordPress:
Nutzt man Permelinks, funktionieren diese nicht. Die .htaccess Datei, welche der Apache nutzen würde, wird von dem nginx nicht ausgewertet wenn dieser als PHP Interpreter genutzt wird.

Ein Workaround für WordPress ist es, für alle vServer die Direktiven zu ändern, was für mich einfach keine Option ist, da es hier nur um einen Bruchteil aller Sites, auf dem WordPress überhaupt genutzt wird, geht. Alternativ gibt es dort noch ein nginx-Config-Snippet, was bei mir aber auch nicht sauber funktioniert hat. Es waren beispielsweise alle CSS Files nicht mehr erreichbar und das Design total im Eimer.

Die Lösung ist eine Anpassung den Snippets:

if (!-e $request_filename)
{
rewrite ^/(.+)/$ /index.php last;
}

Einzutragen unter Plesk > Domains > domain.tld > Einstellungen für Apache & nginx > Zusätzliche nginx-Anweisungen.
Damit funktioniert es bei mir mit drei WordPress Installationen sauber, ohne alle anderen vServer zu beeinflussen.

Nachtrag:
Nachteil hierbei, der mir aufgefallen ist: Ein Zugriff auf die von Plesk erstellten AWstats/Webalizer Statistiken ist für diese Domain/Subdomain nicht mehr möglich, da auch diese URL umgeschrieben wird.

UBNT Unifi mit SSL und fhem auf dem RaspberryPi

Anleitungen, Unifi auf dem Raspberry zum laufen zu bringen gibt es inzwischen wie Sand am Meer. Ich stelle meinen aktuellen Weg ebenfalls Online.

Basis-Installation:

echo "deb http://www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti" > /etc/apt/sources.list.d/ubnt.list

apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50

apt-get update

apt-get install unifi -y

Dann sollte die Standard-Instanz vom MongoDB noch deaktiviert werden, da diese nicht genutzt wird und nur eh schon knappe Ressourcen frisst. Außerdem werden die Journal-Dateien auf 128M statt 1GB pro File, und maximal 512MB in Summe, festgelegt:

echo "ENABLE_MONGODB=no" | sudo tee -a /etc/mongodb.conf > /dev/null

echo "smallfiles = true" | sudo tee -a /etc/mongodb.conf > /dev/null

service mongodb restart

Damit ist der Unifi Controller einsatzbereit.

UBNT Unifi mit SSL und fhem auf dem RaspberryPi weiterlesen

Canonical Landscape

Lange habe ich nach einer einfachen Möglichkeit gesucht, meine Linux Hardware- und Container-Systeme elegant zentral zu verwalten.
Unter dem Begriff verwalten fasse ich dabei zusammen:

  • Sichtung der Verfügbarkeit/Erreichbarkeit
  • Infos zu den wichtigsten Werten (HDD, CPU, RAM) und Konfiguration (IP etc)
  • Updates, Verfügbarkeit und ausrollen
  • Skripte triggern
  • Software installieren

Zufällig bin ich dabei auf Canonical’s Landscape gestoßen und dachte erst, es wäre ein reiner Cloud-Service und nur für Abonementen.

Dem ist aber nicht so, es gibt neben der Cloud auch eine OnPremise Version und es werden ohen gesonderter Lizenz auch ein paar Maschinen unterstützt:

  • 10 Computer nativ installiert
  • 50 Container (LXD,…)

Neben dem erfüllen meiner oben genannten Anforderungen ist außerdem eine Anbindung an MaaS (Machine as a Service, PXE Maschinen Deployment von Canonical, auch sehr geil), OpenStack und Juju vorhanden. Canonical Landscape weiterlesen

Storefront SSON – nur ohne Kaviza

Letzte Woche hatte ich einige Probleme dabei einen Storefront 2.6 für das Single Sign-On zu konfigurieren, weder für den Receiver (schneller Abbruch), noch für den Receiver for Web (Endloses Laden nach dem Klick) wollte es funktionieren.

Es gab weder im Eventlog des Servers, noch des Clients eine Fehlermeldung oder irgend etwas wo man hätte ansetzen können. Ich habe zwischenzeitlich sogar die Webservices des Storefront neu erstellen lassen aus Verzweifelung.

Die Erlösung brachte dann ein neuer Store, welcher anders konfiguriert war: Im sonst genutzten stand als Delivery Controller die XenDesktop 7.6 Farm drin, natürlich mit „TrustRequestsSentToTheXML = True“, sowie die alte Kaviza / VDI in a Box Umgebung drin. Solange die Kaviza Umgebung mit angesprochen wird scheint es keine Rückmeldung auf die XML Service Anfragen des Storefront dorthin zu geben mit welcher Umgegangen werden kann und auch kein Timeout im Storefront selber. Ist hingegen nur XenApp und/oder XenDesktop konfiguriert klappt es sofort.

Also falls jemand sich über endlose Anmeldevorgänge wundert und SSON mit einem Kaviza Cluster dahinter laufen hat: Im betreffenden Store das Kaviza mal raus nehmen oder ein zweiten ohne bauen.