Als Texteditor ist hier Sublime Text in der lizenzierten Version im Einsatz.

Es ist aus meiner Sicht vollkommen legitim, daß ein Lizenzinhaber gelegentlich überprüft, ob die zugewiesene Lizenz noch gültig ist. Sublime Text führt diese Online-Überprüfung aber nach jedem Start durch, was im Hinblick auf die Privatsphäre suboptimal ist - letzendlich geht es im Rahmen der erworbenen Lizenz die Entwickler nichts an, ob der Editor fünfzig mal am Tag oder um drei Uhr nachts gestartet wird.

Eine Diskussion mit dem Thema “Sublime Text calling home to license.sublimehq.com on every start?” im offiziellen Sublime Text-Forum hat leider zu keinem greifbaren Ergebnis geführt. Da auch die Sales FAQ nicht verlangt, daß das Programm nach Hause telefonieren darf / kann / soll / muss, ist eine anwendungsbezogene Sperrung des Netzwerk-Zugriffs eine naheliegende Option.

Vollständigen Beitrag lesen

Sofern ein Linux-System systemd verwendet muß zum Abgleich der Systemzeit – sofern dieses nicht als Zeitserver für andere Systeme arbeiten sollen – kein ntp mehr insalliert werden.

Es reicht die Anpassung der Datei “/etc/systemd/timesyncd.conf” in welcher dann in der Zeile “NTP=” der gewünschte Zeitserver eingetragen wird.

Nach Änderung der Datei wird der Dienst “systemd-timesyncd.service” neu gestartet - das war’s.

Anschließend kann die Konfiguration des Diensts mittels

überprüft werden. Wird der Status des “NTP service” als “inactive” angezeigt, so ist ein

notwendig, um die Synchronisation zu aktivieren. Detaillierte Informationen erhält man entweder über

oder mit Hilfe von

Vor wenigen Tagen wurde LineageOS 17.1 veröffentlicht - Zeit auf die aktuelle Version zu wechseln und hierbei gleich neue Lineage Recovery auszuprobieren. Der in LineageOS eingebaute Updater erkennt zwar, daß eine neue Version vorliegt, kann das Update aber nicht manuell durchführen.

LineageOS

Die sehr kurz gehaltene Upgrade-Doku spart leider aus, daß man das Lineage Recovery nicht wie bisher für TWRP empfohlen mittels “fastboot boot …” direkt starten kann, denn dann erscheint lediglich eine Fehlermeldung:

Ein Blick in die Installations-Doku zeigt, daß die Lineage Recovery installiert werden soll:

Anschließend kann die Recovery gestartet werden (Power & Volume down) und über die Menüpunkte “apply update” / “apply from adb” empfangsbereit gemacht werden. Die eigentliche Installation des Updates ist unspektakulär:

GApps (optional)

Die Dokumentation weist darauf hin, daß es wichtig ist, den Zustand bzgl. eventuell verwendeter GApps beizubehalten, d.h. wenn welche installiert waren, müssen sie vor dem ersten Start des Betriebssystems aktualisiert werden.

Hierzu wird die Recovery erneut gestartet und bereit zum Datenempfang gemacht, dann kann das Paket installiert werden.

Root

Das bisher für LineageOS 16 angebotene “addonsu” ist aus technischen Gründen leider nicht mehr erhältlich

… our usual provided AddonSU zip to enable root access for the user is no longer feasible

weshalb auf Alternativen wie Magisk ausgewichen werden muss.

… if you want root for apps, flash magisk zip in recovery. Just don’t flash it during initial lineage install, as it’s known to cause bootloop if you do.

Wichtig ist, Magisk nicht zusammen mit LineageOS zu installieren, ob hier ein erneuter Start der Recovery reicht oder ein Systemstart erfolgen sollte, ist nicht ganz klar. Die Installation erfolgt analog zu LineageOS bzw. den GApps am sinnvollsten nach einem Systemstart.

Nacharbeiten

Nach der Installation kam von Magisk keine Aufforderung von AFWall+ zum Erhalt von Root-Rechten. Nach einem weiteren Reboot kam dann aber die erwartete Aufforderung.

Der Captive-Portal-Check lief trotz übernommener AFWall+-Einstellungen immer auf einen Verbindungsfehler, die Liste der Freigaben musste noch um “[1073] Network Stack, com.android.server.NetworkPermissionConfig” erweitert werden, ansonsten wurde dauerhaft das “X” beim Verbindungsstatus angezeigt und einige Apps haben erst gar nicht versucht, sich mit dem Internet zu verbinden.

Sollte nach der Installation von xrdp die Verbindung nur als root funktionieren und für alle anderen Benutzer verweigert werden, so hilft ein Eingriff in die Datei “/etc/X11/Xwrapper.config”: In der Zeile

den Wert von “console” auf “anybody” ändern.

Nach dem Update eines Microsoft Server 2008R2 (über den Umweg Server 2012) auf Server 2016 funktionierte der Zugriff auf eine WebDAV-Ressource nicht mehr und wurde mit einem Systemfehler 67 “Der Netzwerkname wurde nicht gefunden” beendet.

Nachdem vor dem Update alles funktionierte, musste der Fehler irgendwo beim Client liegen und wurde zunächst in den Netzwerkeinstellungen gesucht, aber sowohl “nslookup” als auch “ping” lieferten die zu erwarteten Ergebnisse und der Internet Explorer konnte sich auch probemlos verbinden.

Letztendlich führte die Suche nach einer Lösung zum Microsoft Knowledgebase-Artikel “Using the WebDAV Redirector” und dort im Abschnitt “Troubleshooting the WebDAV Redirector” zum entscheidenden Hinweis:

When attempting to map a drive to a WebDAV site, you receive the following error:

System error 67 has occurred.

The network name cannot be found.

This can be caused by one of the following conditions:

…
You have not installed the WebDAV Redirector on your client system.

…

Beim Update wurde offensichtlich die Installation der bisher zuständigen “Desktopdarstellung” nicht in die nun zuständigen Teilpakete aufgelöst.

Nach der Installation des Features “WebDAV Redirector” über den Servermanager und einen damit verbundenen Reboot funktionierte der Zugriff auf die Quelle wieder wie erwartet.