All posts by admin

moving to unofficial lineageOS …

I’m still using a somewhat dated nexus 5x with lineageOS 15.1 (based on android 8.1.0).

But sadly even lineageOS dropped support for the device several months back.

Now what?

After pondering about if for quite a while, since the phone is still perfectly fine and has enough hardware for everything I want to do, considering buying a pixel 4a and running stock, or since lineageOS is not available giving CalyxOS a try i decided to look into unofficial builds first.

There are still unofficial builds of lineageOS for nexus 5x around with current patch levels … but wiping didn’t seem very fun. Luckily you don’t need to.

Here’s the cheat sheet:

  • make sure TWRP isn’t too old (3.2.x needed, i updated to current just in case (
  • make a backup just in case using TWRP
  • get the updates to your phone (either download there or just copy over)
    • little patch to switch to unofficial (
    • get the build of your choice from
  • install with TWRP, make sure to put the patch first but it’s fine to do it in one go
  • $profit

Microsoft Teams is a security nightmare

Filetransfer with Teams apparently works by uploading the file to a OneDrive connected to a SharePoint connected to an AzureAD. Files are kept untill infinity (or untill your Quota runs out). Don’t ask.

The best thing is:

  • share file.txt with user A
  • forget about it (as i said, by default that could be years later)
  • share file.txt with user B
  • see the following dialog (german version, it says cancel/keep both/overwrite)

  • choose “overwrite”, mind you that is the default here
  • now user A (you remeber the one from way back) can download the file again and gets the new version probably intended only for user B
  • bang your head against the wall

lineageOS 15.1, Internet of unpatchable Things

The guys over at are busy rolling out 15.1 builds (that is android 8.1) and even provide builds for my somewhat aged Nexus 4 (reminder: from 2012) so i still get the “new stuff” and security updates for that device.

There were discussions about IoT devices and making regulations so manufacturer of devices are require to at least provide security updates for a certain timeframe but sadly no regulation was passed so far.

IMHO we need to enforce security updates for 5 Years for most devices lime IoT for smart home, smartphones etc … having manufacturers put a label on the box with the timeframe where he will provide software updates and security updates should have a good chance at getting manufacturers to compete with longer timeframes, reducing the number of devices that gets thrown out simply because they are not secury anymore.

Just to give another example:

@work we had a video conferencing system. Of course that was outdated after a few years, but was technically still working ok. Just a small hitch: No security updates from the vendor without maintenance contract, and after just 5 years no updates whatsoever since the product was EOL. Let me remind you, that is something that needs to be online to be useable, and is publicly reachable. And not cheap at all that thing was over 10k €.

It should be illegal for devices that require to be online not to provide security updates for free, and for a reasonable timeframe considering the price range the device is in.


icinga2 #2 – some lessons learned

I’ll insert a post here that explains a few lessons learned (usually quite some time down the road) so you can avoid things I did wrong and figured out a lot later.

make sure everything you set up is working properly before plowing on

Particularly, check the History section if you icinga2web to see if you got unexpected amounts of state changes (check flapping as nagios used to call it) and notifications (if you have set up some already). If you don’t and you have some issue there that is only a monitoring issue not some host or service with an actual problem, all your historical data will be moot. So doing overviews and reports “something for the boss” later on over that data will not produce anything useful.

decive how you name your hosts and services and stick to it

For one renaming hosts also messes with statistics you might wand to do later on, also you want to keep things tidy and orderly. Even worse if you add your data to some other tool for long-term statistics, then even the display name might get used.

You might want to ponder a bit if you use IPs, Hostnames or fully-qualified DNS-Names for your “Host address”-field, “Hostname” (intenal identifier of the host) and/or Display name.

Some general “state the obvious” about that

  • display name shoud have some description added if your hostnames are not descriptive enough to tell you at a glance what that host is/what’s running on that host
  • using DNS names for “Host address” obviously will fail if your DNS is broken. so you need to use some IPs for very basic infrastructure like your DNS.

My take was to use FQDNS for most things, sometimes add info to that for a Hostname. And have basic network devices, virtualization servers, storage etc. with IP as “Host address” so I can see what is broken if my DNS fails.

I ended up with a bit of a mix though, and at least in parts cleaning it up would make my historical data useless so currently i’m not sure if I ever will.

Feel free to comment on that strategy 😀


icinga2 #1 – installing

The first thing i had to figure out was how to go about installing the whole thing.

Our envorionment is basically completely virtualized, so creating a new monitoring-VM from my favourite debian template only took a few minutes.

Luckily I figured out really soon there is such a thing as director for icinga (see and that

a) it seems a good idea to use it

b) it’s probably best do do everything with it, so no manual configuration at all

After looking a bit I found an install guide that explained (most importantly for me) how to clean up the default icinga2 config so you can actually start with director with a clean canvas. It’s for cent OS but that hardly matters, you only need to add the apt source (deb icinga-stretch main) and install icinga2 and icinga2web packages. Then pick up the guide with the cleanup of the stock config and adding the director.

icinga2 + icinga director

I’ve been using icinga2 with icinga director for over a year now to rebuild our monitoring. Old one was nagios3, but i didn’t bother migrating anything old since we were moving over to new server hardware and in the process re-creating basically all VMs in use, partly for license reasons partly just to clean up and upgrade installations.

So i set up icinga2 and kept adding the new things to it as we build them, slowly moving away from the old nagios3.

I want to start a small series of blog entries about how i went with my setup since icinga guides especially when it comes to using director are rather sparse, so other ppl might find it useful.

Stay tuned.


Ich habe schon seit Version 6 ein ownCloud laufen … mit jeder Version ging das update etwas runder aber etwas “treten” war eigentlich immer nötig.

Mit dem chaos im Projekt und dem nextcloud-Fork habe ich erstmal abgewartet und mich jetzt aber für nextcloud entschieden.

Gründe: Mehr community, fokus auf läuft runder und schöne updates, wirkt alles etwas besser grade auf mich.

Ausgangssituation: ownCloud 9 in einem meiner Webs im ISPConfig.

Freundlicherweise gibt es eine Liste der Migrationspfade … erster versuch: nextcloud installer reinwerfen und einfach updater benutzen. Das wollte nicht so wirklich bei mir kann auch an dem web drumrumliegen oder die Dateisystemrechte waren vorher etwas schief … next try: manuelle Migration (lies: alles bis auf daten und config löschen, neue files hinwerfen) auf nextcloud 10, updater anwerfen.

Gab ein paar Fehler wegen Dateisystemrechten, in dem Web eingesperrt war das auch bisher ab und zu etwas mit treten verbunden. Aber gibt da kleine scripte die das gradeziehen. Und schon ging der updater auf v11 😀

Aktuell muss man scheinbar immer noch die plugins calendar und contacts reaktivieren, die sollen aber auf dauer in core integriert werden.


Mitlerweile werdens alle wissen die es interessiert:

Cyanogenmod wurde effektiv zum Jahreswechsel beendet da die Firma dahinter wegfiel und wird nun als lineageOS als reines community-projekt weiter betrieben.

Da mein Nexus 4 (mako) von Google nur Android 5.1.1 (letztes update Oktober 2016 oder so) hat und nie mehr was bekommen wird war back-to-stock keine option. Es lief schon länger mit cyanogenmod 13.1 aber ohne security updates konnte ich das auch nicht lange so lassen.

Daher großer update-Tag ..

CM 13.1 > CM 14 > lineageOS 14 experimental > lineageOS 14 nightly

Dazu muss man wissen:

Bei gleicher Version kann man mit einem lineageOS experimental build versuchen von cyanogenmod zu wechseln OHNE alles neu einrichten zu müssen.

Side-note: “nightly” ist zumindest aktuell ein “weekly” 😀

Sobald es offiziell stabile builds gibt scheint der Plan zu sein wöchentlich updates/security fixes zu bringen.

Update lief gut bis ich von experimental auf nightly wechseln wollte, ein Schritt bei dem ich eigentlich dachte kann am wenigsten passieren. Hat in einem pseudo bootloop geendet, es hat nur noch das recovery (twrp) gebootet und gar kein android mehr.

Da es etwa später abends war hab ich dann stock -> twrp + lineageOs nightly gemacht und es halt doch neu eingerichtet. Mittlerweile habe ich gelernt, dass

  • bootloop per twrp terminal oder adb mit einem dd-einzeiler gefixt werden kann
  • das allerneuste twrp für den updater nötig ist damit es automagisch startet
  • die ersten lineageOS nightlies häufig korrupt ankommen (wie auch immer das passiert)

Das lineageOS vom 13.2. ging da ich mittlerweile TWRP habe wie erwartet:

Downloaden, starten, abwarten, (unlock), abwarten, fertig.