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.
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 (https://twrp.me/lg/lgnexus5x.html)
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 (https://archive.org/download/lineage-migration-official-to-unofficial/lineage-migration-official-to-unofficial.zip)
get the build of your choice from https://sourceforge.net/projects/razorloves-lineage/files/bullhead/
install with TWRP, make sure to put the patch first but it’s fine to do it in one go
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
The guys over at lineageos.org 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.
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.
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 http://packages.icinga.com/debian 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.
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.
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