Category: computer

enlightenment: suid setzen

axt

Nachdem in einem Forum-Thread bezeichnenderweise auch nach anderthalb Tagen statt einer Lösung für

“Enlightenment cannot successfully start the enlightenment_system service since it can’t become group root. Missing setuid bit?”

nur ein Link zu einem Bugreport (den ich auch längst gefunden gehabt habe) gepostet worden ist, habe ich mich unter dem Bugreport erbarmt. Das Problem an sich ist nicht neu (ist bei mir damals mit e17, e18, e19 auf Lubuntu oder siduction allerdings nicht aufgetreten), Lösungen in anderen Foren sind jedoch auch nicht wirklich existent. Eine vielleicht, freilich noch vor dem usrmerge, damit mit anderen Pfaden.

1
2

# chmod 4755 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys
# chmod 4755 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_system

Der launchpad.net-Editor ist im übrigen ein Grauen. Weder gibt es ersichtlich Codeblocks noch Link-Syntax (vielleicht wenigstens BBCode, habe ich aber nicht auch noch ausprobieren wollen, denn Vorschau und Editieren sind ebenfalls nicht möglich, dafür aber sinnfreie nicht verhinderbare harte Zeilenumbrüche trotz wesentlich breiterem Editor-Fenster). Paßt damit bestens zu Canonical/Ubuntu.

Paketquelle partner nicht in Jammy

axt

Kurzinfo für Ubuntu 22.04: Es gibt einen Vorschlag Steve Langaseks, die ohnehin seit Groovy leere Paketquelle partner (in Focal ist AFlash zu dessen mehr oder eher weniger Lebzeiten als letztes noch enthalten gewesen) zu schließen. Gegenmeinungen scheint es bislang keine zu geben…oder mit anderen Worten, interessiert keinen mehr. Im Einzelnen oder überhaupt.

Die Begründung ist allerdings schräg. Der Snap Store sei mittlerweile so ausgereift, daß dieser partner ersetzen könne. Was nichts über das aufblasende bis hin das Prinzip Linux-Paketverwaltung zerstörerische snap selbst aussagt…

Arch Linux 2022.01.01, Image in VBox nicht UEFI-faehig

axt

Um in einer VBox-VM statt im CSM-Mode (Compatibility Support Module, das UEFI verhält sich, als sei es ein BIOS) im UEFI-Mode zu booten, ist lediglich im “VM VirtualBox Manager” unter System → Motherboard → Extended Features “Enable EFI (special OSes only)” zu aktivieren. Alternativ in einem Terminal:

1

vboxmanage modifyvm "VM name" --firmware efi

Selbstverständlich muß das zu bootende Image so oder hybrid erstellt worden sein (ein installiertes System sowieso). Das einfache Bootmenu von Arch Linux erscheint dann wie folgt:

Nicht so beim aktuellen Image archlinux-2022.01.01-x86_64.iso. Die Arch-Einträge fehlen, schlicht da das Image in VBox-VMs im UEFI-Mode nicht boot-fähig ist. Nativ soll es OK sein.

Man kommt nur in die EFI Shell oder das rudimentäre UEFI-Menu. Änderungstests in letzterem oder im VM-Manager sind erfolglos. Andere UEFI-fähige Distributions-Images, bspw. ein mit isorespin.sh angepaßtes Lubuntu bootet anstandslos, ebenso Arch-Images davor.

Ursächlich soll systemd 250.1-1 sein, es gibt einen Bugreport dazu bei archlinux.org. So es so ist, müßte dann, da Upstream, jedoch einer bei systemd erstellt werden.

Erhärtet wird es, da ein User ein Image mit systemd 249.x erstellt hat, das entsprechend boot-fähig ist. Jener bietet es zwar zum Download an, ein OS-Image von irgendjemandem verändert, so nett es gemeint ist, würde ich jedoch nicht verwenden.

Ebensogut könnte es ein Zusammenspiel mehrerer Faktoren, d.h. mit VBox sein, würde also (auch) dorthin gehören. Freilich nutze ich prinzipiell die jeweils aktuelle Version, sprich Testbuilds, derzeit 6.1.31 (das letzte ist knapp 4 Wochen alt, jetzt könnte so langsam mal wieder was kommen, manchmal gibt’s 3 Versionen pro Woche). In besagten Threads wird 6.1.30 final verwendet.

Wer jetzt Arch Linux in einer VBox-VM mit UEFI installieren will (mit CSM gibt es kein Problem), kann 2021.12.01 heranziehen – hat dann natürlich erheblich zu aktualisieren, was bei arch durch permanente Updates aber ohnehin der Fall ist – oder mit 2022.01.01 in der EFI Shell folgendes aufrufen:

1

FS1:\EFI\BOOT\BOOTx64.EFI

Das installierte System scheint keine UEFI-Boot-Probleme mit aktuellem systemd in VBox-VMs zu haben.

Update 1: Zwischenzeitlich ist upstream ein Bugreport für systemd erstellt worden.

Update 2: Der Commit boot: Fix readdir_harder() on VirtualBox für systemd ist 2022-01-10 Spätabend hinzugefügt worden, Arch Linux liefert systemd 250.2-2 damit in testing bereits aus. Das Februar-Image sollte dann dahingehend problemlos boot-fähig sein.

Update 2022-01-18: Die heutige (eigentlich vom 13.) Final VBox 6.1.32 löst zwar das Problem, Arch Linux 2022.01.01 zeigt im UEFI-Mode das vollständige Menu und kann folgerichtig booten. Jedoch bringt VBox 6.1.33-149396 das Problem zurück.

Update 2022-02-01: archlinux-2022.02.01-x86_64.iso funktioniert dahingehend korrekt.
FYI: Das wenige Stunden zuvor von testing nach extra gewanderte archinstall 2.3.1 ist enthalten.

pdf, finale Ungleichheit

axt

Das Portable Document Format ist entwickelt worden, um ein finales Dokument zu erhalten, das in jedem OS in jedem pdf-Viewer gleich aussieht, ebenfalls gedruckt. Es ist wie gesagt ein Endprodukt, es soll nicht editierbar sein (was User offensichtlich nie verstehen werden). Daß Drittanbieter Bastelprogramme anbieten, ändert daran nichts.

In 3 Jahrzehnten ist freilich immer weiter angeflanscht worden, so daß es nicht nur den einen Standard, die eine Version gibt. Bspw. für Archivierung sollte PDF/A (in Unterversionen), ISO 19005, gewählt werden, absichtlich unteres Level.

Hybrid-PDF kann man bei der Erstellung (LibreOffice) wählen, um in einem .pdf-File sowohl PDF als auch ODF zu speichern. Das .pdf-File wird damit durch Trickserei editierbar, man braucht nicht separat .odt bzw. .ods zu speichern. Natürlich ist dabei die Filesize größer. Wenn das File weitergegeben werden und nicht editierbar sein soll, darf man das selbstverständlich nicht hybrid speichern (eher exportieren).

Sind Forms eingebettet, kann ein solches pdf-File als ausfüllbares Formular verwendet werden. Dazu genügt ein pdf-Viewer.

Read more “pdf, finale Ungleichheit”

Streams in vlc abspielen

axt

Streams einer bekannten Videoplattform sind dafür vorgesehen, im Browser zu laufen. Um darüber hinausgehendes zu verhindern, werden ständig neue technische Rafinessen ersonnen (man denke nur an Fragmentierung des Videos, separate Audiospuren etc.).

vlc hat man bis vor geraumer Zeit durch Aufruf des Stream-URLs noch nutzen können. Derzeit stockt die Wiedergabe jedoch aller paar Sekunden – unbrauchbar. In Foren wird nach Lösungen gefragt. Tips, man solle doch smplayer nehmen (ohnehin nur ein Frontend für mplayer oder mpv), verkennen, daß dieser selbst derartige Streams gar nicht abrufen kann, sondern sich eines bekannten Zusatz-Tools bedient.

Ich betone, es soll ausschließlich um die Wiedergabe des temporär nur dafür im Cache gehaltenen Streams gehen. Also das, was ein Browser auch nur macht, aber ein Player technisch besser könnte, wenn ihm kein Bein gestellt wird (die Systembelastung ist merklich geringer, insbesondere unter Linux, dort haben Browser i.d.R. keine wirkliche Hardware-Beschleunigung).

vlc nutzt für Quellen entsprechende Playlists, eine Art Profile. Arch-based sind sie unter “/lib64/vlc/lua/playlist/” abgelegt, in debian-basierten Systemen unter “/usr/lib/x86_64-linux-gnu/vlc/lua/playlist/”. Default sind es .luac-Files. Es werden jedoch nicht nur Kompilate, also Binaries, erkannt, sondern auch .lua-Files.

Man benötigt keine neue vlc-Version (auch ein 4.0er nightly-snap soll nicht helfen), man kann das entsprechende .luac-File durch ein .lua-File (logscherweise raw) ersetzen.

In einer Arch-basierten Distribution ist das Problem damit behoben, ebenso in einer LFocal-VM (dort hat es bisher gar nicht abgespielt werden können), in einer Debian-testing-VM stockt es noch. Es sind unterschiedliche vlc-Versionen. Generell funktioniert es also – derzeit – wer es wirklich braucht (für mich ist es lediglich eine interessante technische Problemstellung gewesen), müßte in letzterem weitersuchen, bspw. Konfigurationen (VM, vlc,…) vergleichen.

LXQt: Shortcuts ohne Funktion

axt

Wenn Tastenkombinationen keine Reaktion mehr zeigen, merkt man erstmal, wie sehr man selbst darauf baut. LXQt-Shortcuts funktionieren nicht mehr (wenn nicht mal über ctrl+alt+t ein Terminal gestartet werden kann, was ich hier ständig mache, ist das schon hart, hrr).

Sobald der Desktop aufgebaut ist, erscheint folgende Message:

lxqt-panel
Removable media/devices manager: Global shortcut 'X86Eject' cannot be registered

Ich untersuche das Problem seit Freitag (da ist es erstmals aufgetreten, testing ist in einer hier installierten arch-basierten Distribution prinzipiell aktiviert). Es ist irrelevant, welcher Window Manager genutzt wird (openbox, xfwm4). Zwischenzeitlich habe ich schon angenommen gehabt, ich hätte die Ursache gefunden bzw. zumindest einen Workaround.

lxqt-globalkeysd kann nicht gestartet werden. Dies kann man sehen unter:

LXQt Configuration Center → Session Settings → Basic Settings → Global Keyboard Shortcuts

An der Stelle kann man den Dienst starten, freilich überlebt dieser keinen Reboot oder Relogin.

Unter

LXQt Configuration Center → Autostart → Application Autostart → LXQt Autostart

habe ich “lxqt-globalkeysd” mit “Wait for system tray” als Workaround hinzugefügt. Hilft allerdings nicht zuverlässig. Im Moment funktioniert’s, was nicht daran liegen muß.

Zum Thema kann man fast nichts finden. Vor 5 Jahren ist das Fehlerbild schon mal aufgetreten (nicht bei mir, ich habe damals LXDE genutzt). Damals soll geholfen haben:

PCmanFM → Preferences → Volume → disable “Mount removable media automatically whe they are inserted” und disable “Show available options for removable media when they inserted”

Ist hier aber auch nicht einwandfrei reproduzierbar.

⚠ Ventoy: Verdacht auf Malware #3

axt

Nachdem die letzten Versionen auf Virustotal wieder steigende Funde verzeichnet haben, 1.0.59 steht bei 4/60, schießt ventoy 1.0.60 mit bislang 13/60 (!) Scannern durch die Decke.

Ich werde mich nicht erneut an den Programmierer wenden, nur um dummes Zeug lesen zu müssen. Das Programm an sich ist in seiner Art Spitze, es wird stetig ausgebaut, aber verbietet sich durch sowas, genauer, der Programmierer selbst deklariert es mit seinen Ausflüchten, die ein massives technisches Unverständnis erkennen lassen, als potentiell gefährlich und eben nicht einsetzbar.

Nun schlagen derzeit die Scanner bei Windows-Versionen wieder massiv an, bei Linux-Versionen noch nicht. Es ist freilich die Frage, wie die Scanner auf Virustotal überhaupt Linux-Software testen – Funde hat es durchaus schon gegeben – wie dies zu bewerten ist. Wenn jedoch ein Programmierer derart sorglos und luschig arbeitet, muß man es insgesamt annehmen. Und Code für jeweilige OS wird er auch nicht komplett und getrennt neu schreiben, sondern möglichst in einem OS multiOS kompilieren und im LAN kopieren.

Es sei ausdrücklich vor dem Einsatz von ventoy gewarnt.

Ventoy: grafisches Frontend

axt

Bisher ist ventoy unter Linux nur in einer Shell nutzbar. Das ist auch ausreichend und hat damit durchaus einen nerdigen Charme. ;-) Mit Version 1.0.52 wird nun auch ein grafisches Frontend, das der Windows-Version sowohl in Funktionen als auch Aussehen gleicht (Screenshot auf LXQt/Openbox/Mikachu in einer VM), mitgeliefert.

Btw., auch, wenn ich nicht mehr Ventoy: Verdacht auf Malware #2 aktualisiere, ich lasse selbstverständlich weiterhin jede Linux- und Windows-Version scannen. Sollte sich wieder etwas diesbzgl. ereignen (nur dieser malaysische MaxSecure, quasi nebenan, 1/62, meckert für die Windows-Version nach wie vor), wird dies kundgetan.

OpenWRT, aktuelle Version flashen

axt

Mit Freigabe von OpenWRT 21.02.0 am 2021-09-04 habe ich diese geflasht. Bereits bei den RCs habe ich mich selbstverständlich über Änderungen informiert (ja, ich lese Changelogs), so daß ich mich nicht lange habe aufhalten brauchen.

Mir geht es an dieser Stelle um das Flashen an sich (das selbstredend generell auf eigenes Risiko vorgenommen wird, aber das sollte jedem klar sein). Das Flashen innerhalb einer OpenWRT-Hauptversion ist stets in wenigen Minuten erledigt. Browser gestartet, möglicherweise störende Add-ons wie NoScript deaktiviert, eingeloggt, .bin ausgewählt, 2x bestätigt, es wird geflasht und der Router automatisch rebootet. Man kommt wieder auf die Login-Site, unten kann man bereits die geflashte Firmware-Version sehen.

Das sysupgrade.bin kann man ohnehin nur von der vorherigen Version 19.07.8 aus verwenden, nicht nur, was die Übernahme der Konfiguration betrifft.

Nun ist es jedoch ein ziemlicher Sprung…und es dauert und dauert…es bleibt der übliche Text stehen, man solle um Gotteswillen nicht vom Strom trennen etc. Logisch. Beobachtet man die Aktivitäten der LEDs, kann man freilich davon ausgehen, Flashen und Reboot sind längst passiert. Nur diesmal bekommt’s der Browser eben nicht mit, manuell reloaden will man auch nicht wirklich.

Kurzer Test mit einem Smartphone über WLAN, Internet liegt an, Router arbeitet also. Nun gut, anderen Browser auf dem Rechner gestartet, ich kann mich in OpenWRT einloggen, aktuelle Version.

OK, dann mal den zum Flashen verwendeten Browser reloaden. Meckert kurz des Zertifikats wegen (zum Einen habe ich in Fx https strikt eingestellt, zum Anderen ist dahingehend in OpenWRT etwas geändert worden), schafft’s aber dann doch.

Ich hab’s wissen wollen, dasselbe File nochmal geflasht (natürlich ändert das nichts). Das geht dann wie gewohnt schnell.

Man sollte im übrigen die Konfiguration durchgehen – es ist eben einiges dazugekommen (WPA3) und/oder verändert worden (1, 2) – speichern und natürlich wieder extern sichern.

Update 2021-10-26: OpenWRT 21.02.1 (Changelog)
Update 2022-02-17: OpenWRT 21.02.2 (Changelog)

Thunderbird: Feeds ohne Zertifikat

axt

Thunderbird in aktueller Version (derzeit 89.0b4) zieht keine RSS-Feeds von unsicheren URLs, also http ohne s, mehr. Möglicherweise kann man dies für eine Übergangszeit ähnlich wie in Fx über einen Eintrag in user.js rücksetzen, aber darum soll es hier nicht gehen (drin ist drin, gilt global und wird vergessen).

In erster Linie dürfte das Feeds betreffen, die man seit Jubeljahren bezieht. D.h., hier prüft man, ob Feeds nicht längst über https ziehbar sind. Das “s” im URL dazuschreiben, funktioniert nicht. Man entfernt den Feed (die Nachrichten bleiben erhalten) und fügt den Feed mit nun https hinzu.

Feeds ohne secure sollte es nun so langsam nicht mehr geben. Stimmt bei https aber das Zertifikat nicht, zieht Tb auch nichts.

feed subscriptions

Das Beispiel rglinuxtech.com ist nur über http erreichbar, aber Feeds gibt’s so eben nicht mehr. Über https funktioniert es nicht, da das eingebundene Zertifikat nicht darauf, sondern auf dessen Hoster pipeten.co.uk ausgestellt worden ist.

Über “Add Exception” gelangt man auf folgenden Requester:

Read more “Thunderbird: Feeds ohne Zertifikat”