Betriebssysteme

dpkg und Status "deinstall"

26. Juli 2020 · Betriebssysteme · andreas · Kein Kommentar

Beim gelegentlichen Erstellen der Liste aller installierten Pakete mit “dpkg –get-selections” ist mir aufgefallen, daß ein paar Pakete mit dem Status “deinstall” angezeigt werden, z.B.

python3.7 install python3.7-minimal install qemu-kvm deinstall qemu-system-common deinstall qemu-system-x86 deinstall qt5-gtk-platformtheme:amd64 install

Diese waren zum größten Teil Überbleibsel von Experimenten mit virutellen Maschinen, in deren Verlauf ich “virt-manager” installiert und anschließend mittels “apt purge …” wieder vom System entfernt habe, inklusive anschließendem “apt autoremove”.

Warum sind die Pakete offensichtlich noch vorhanden und werden von einem “autoremove” nicht entfernt? Ein Blick in die man-Page brachte leider nicht die erhoffte Erleuchtung:

deinstalliere Das Paket ist zur Deinstallation ausgewählt (d.h. wir wollen alle Dateien außer den Konfigurationsdateien entfernen).

Im englischen Debian-Forum findet sich eine plausible Erklärung , zwar aus 2009, aber sie passt:

… this means that all package files have been selected for removal except the configuration files.

sowie

If there is no configuration, cache files or whatever to be removed, then the package will be completely removed and not left in ‘c’ (deinstall) state.

Dependencies that were installed automatically are never purged by default (if not uninstalled manually, using the purge command).

Das erklärt, warum manche Pakete noch im Status “deinstall” vorhanden waren:

Der “virt-manager” war weg, weil mittels “apt purge …” deinstalliert. Alle Depencencies ohne Konfigurationsdatei(en) waren ebenfalls weg, gelistet wurden noch die Reste, bei denen zwar die Pakete entfernt wurden, nicht aber die Konfigurationen.


Internet-Zugriff für Sublime Text unter Debian unterbinden

15. Mai 2020 · Betriebssysteme · andreas · Kein Kommentar

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.

Weiterlesen


Zeitsynchronisierung mit systemd

27. April 2020 · Betriebssysteme · andreas · Kein Kommentar

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.

/etc/systemd/timesyncd.conf
[Time] NTP=zeitserver.local FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org RootDistanceMaxSec=5 PollIntervalMinSec=32 PollIntervalMaxSec=2048

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

$ sudo systemctl restart systemd-timesyncd.service

Anschließend kann die Konfiguration des Diensts mittels

$ timedatectl status Local time: Mo 2020-04-27 21:19:40 CEST Universal time: Mo 2020-04-27 19:19:40 UTC RTC time: Mo 2020-04-27 19:19:40 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no

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

$ timedatectl set-ntp true

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

$ timedatectl timesync-status Server: 1.2.3.4 (zeitserver.local) Poll interval: 1min 4s (min: 32s; max 34min 8s) Leap: normal Version: 4 Stratum: 4 Reference: AF0149C Precision: 1us (-21) Root distance: 31.249ms (max: 5s) Offset: -1.759ms Delay: 1.972ms Jitter: 0 Packet count: 1 Frequency: +17,237ppm

oder mit Hilfe von

$ timedatectl show-timesync SystemNTPServers=zeitserver.local FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org ServerName=zeitserver.local ServerAddress=1.2.3.4 RootDistanceMaxUSec=5s PollIntervalMinUSec=32s PollIntervalMaxUSec=34min 8s PollIntervalUSec=2min 8s NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=4, Precision=-21, RootDelay=17.333ms, RootDispersion=18.478ms, Reference=AF0149E, OriginateTimestamp=Mon 2020-04-27 21:05:29 CEST, ReceiveTimestamp=Mon 2020-04-27 21:05:29 CEST, TransmitTimestamp=Mon 2020-04-27 21:05:29 CEST, DestinationTimestamp=Mon 2020-04-27 21:05:29 CEST, Ignored=no PacketCount=2, Jitter=329us } Frequency=1353001

Update Google Pixel von LineageOS 16 auf 17.1

19. April 2020 · Betriebssysteme · andreas · Kein Kommentar

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:

$ sudo fastboot boot lineage-17.1-20200418-recovery-sailfish.img ... FAILED (remote: dtb not found)

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

$ fastboot flash boot lineage-17.1-20200418-recovery-sailfish.img

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:

$ adb sideload lineage-17.1-20200418-nightly-sailfish-signed.zip

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.

$ adb sideload open_gapps-arm64-10.0-pico-20200418.zip

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.

$ adb sideload Magisk-v20.4.zip

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.


Ordner in Nautilus mittels Drag & Drop öffnen

16. April 2020 · Betriebssysteme · andreas · Kein Kommentar

Ist es ein Bug oder ein Feature? Beim Verschieben von Dateien in Ordnerstrukturen wird mitten im Drag & Drop-Vorgang nach kurzer Zeit in den Zielordner gewechselt, was gerade bei größeren Aufräumaktionen zu vielen unnötigen Mausklicks führt.

Die zuständige Funktion in Nautilus nennt sich “open-folder-on-dnd-hover” und kann mittels dconf an- und ausgeschaltet werden:

In neueren Versionen des GNOME-Desktops (ab 3.34) kann die Funktion auch direkt im “Optimierungen”-Werkzeug konfiguriert werden.