doas, das kleine sudo

sudo (Akronym für “substitute user do” und nicht falsch “superuser do”) sollte jeder Linux-User kennen, auch wenn der eine oder andere administrative Tätigkeiten vielleicht doch mit root-Account durchführt.

devil geht in seinem Blogpost auf doas (“do as”), adaptiert von OpenBSD, ein.

In den Debian-, Ubuntu-, Fedora-Repositories liegt es nicht, auch nicht in Ubuntu-PPAs, wohl aber als opendoas in den Arch-Repositories. Upstream-URL linkt auf einen Fork eines anderen seit Jahren nicht mehr angefaßten github-Repos. Beim Fork passiert seit 9 Monaten aber auch nichts mehr. Das muß die eine sagenumwobene Software sein, die absolut fehlerlos und nicht verbesserbar ist.

Wie auch immer, ich hab’s eben mal spaßeshalber (verwenden werde ich’s nicht) aus https://github.com/Duncaen/OpenDoas in einer noch herumliegenden LBionic-VM kompiliert, aber im letzten Schritt des bekannten “Dreisatzes” Ubuntu-typisch mit checkinstall statt “make install” (ist auch unter Debian möglich). So erhält man ein .deb-File.

Wer’s unter Ubuntu(-Derivaten)/Debian selbst ausprobieren möchte:

  1. Installation zum Kompilieren nötiger Pakete:
    1
    
    sudo apt install build-essential checkinstall git byacc

    Es ist darauf zu achten, tatsächlich byacc zu installieren, mit btyacc bricht make mit errors ab.

  2. Clonen des Source Codes aus dem git-Repository mit der Tiefe 1:
    1
    
    git clone git://github.com/Duncaen/OpenDoas --depth 1
  3. Ins Verzeichnis wechseln:
    1
    
    cd OpenDoas/
  4. Der “Dreisatz”:
    1
    2
    3
    
    ./configure
    make -j2
    sudo checkinstall -D --install=no --backup=no --maintainer=user --pkgname=opendoas

    “-j 2” steht für 2 dafür zu verwendende Kerne, man könnte stattdessen bspw. auch “-j $(nproc)” für saemtliche setzen oder die Option auch weglassen. Das Ganze hier ist aber dermaßen klein, da genügt auch ein “halber”. ;)

    Gäbe es bereits ein Paket namens opendoas in der Distribution, sollte man das eigene anders benennen (z.B. mit einem kurzen Zusatz) oder eine höhere Version setzen. Das nur als generellen Nebenhinweis, falls man auch andere Pakete kompilieren will.

  5. Installation:
    1
    
    sudo dpkg -i opendoas
  6. Sich selbst bzw. den gerade eingeloggten User der Konfigurationsdatei hinzufügen:

    1
    
    echo "permit :$USER" | sudo tee /etc/doas.conf

    Statt der Variable $USER kann man natürlich den Usernamen direkt einsetzen, auch einen anderen, der fürderhin doas-berechtigt sein soll.

    Ein testweises “doas nano” funktioniert, manpage, sofern während der Kompilierung nicht abgewählt, auch:

    1
    
    man doas

snap oder richtig

Wie gesagt, als Stichwortgeber taugt jenes Forum noch…

Wer Ubuntu fährt, sollte aufpassen, welche Pakete bzw. woher er diese installiert. Bemängelt wird vom Hilfesuchenden, er fände keinen Download für das PlugIn, um aus gimp heraus xsane zu starten.

Nebenbei, unter arch ist es ein separates Paket namens xsane-gimp. Etwas in der Art gibt es in den Ubuntu-Repositories nicht (mehr), das Plugin jedoch noch sehr wohl. In Sekunden findet man heraus, es ist Bestandteil des Pakets xsane.

Nun behauptet er, sowohl gimp als auch xsane installiert zu haben. Das glaube ich ihm sogar, nur hat er sehr wahrscheinlich nicht die .deb-Pakete aus den Ubuntu-Repositories installiert. Ich meine dabei nicht vordergründig .deb aus Fremdquellen wie PPAs, sondern das unsägliche Canonical-Eigengewächs snap. Dieses Zeug integriert sich eben nicht ordentlich ins System, es ist nicht “nur” Gift für das Paketsystem, die Interaktion ist nicht wirklich gegeben. snap-Pakete sind Fremdkörper.

Also sprach Zarathustra:

sudo apt purge snapd

snap-Pakete fliegen damit ebenfalls ‘raus (sie würden ohne den Daemon ja auch nicht mehr laufen), entsprechende .deb-Pakete müssen bei Bedarf installiert werden.

Hier kommt der Ubuntu-User freilich an den Punkt, daß manche/immer mehr in Ubuntu gar nicht mehr angeboten werden (sollen), prominentes Beispiel seit 18.10 ist chromium, ausgerechnet. Canonical will das immer mehr umbauen. Ubuntu? Auch andere Mütter haben schöne Linux-Töchter. Oder sagen wir besser schönere, keine absichtlich mißgestalteten. Und auch nicht solche alten (gimp in Ubuntu 20.04 “LTS” und dem gerade erst erschienenen 20.10 → 2.10.18, aktuell ist seit 3 Wochen 2.10.22, das wird in releaseten Ubuntu-Versionen auch nicht hochgehievt).

Btw., es gibt auch kein Paket “xsane-doc”, die doc-Files liegen als .html im Paket xsane-common (unter arch im Paket xsane), das bei der Installation von xsane automatisch als Abhängigkeit mitinstalliert wird. Einfach mal selbst suchen, statt vorsetzen lassen wollen. Unter Linux setze ich das voraus.

Nachtrag 2020-10-29: Eben noch mal obig verlinkten Forum-Thread gecheckt, was da so den Tag nach meinem Blogpost geschrieben worden ist. Tja, sag ich doch. ]:-)

Ubuntu: snap verhindern

Von Anbeginn bedient sich Linux Mint an Ubuntu (Mint-User faseln seit jeher etwas von “dem besseren Ubuntu”, um zeitgleich in ubuntuusers.de Support zu verlangen, was entsprechende Sympathiewerte…einbringt).

Man könnte sagen, endlich gibt Mint Ubuntu nun etwas zurück, ungewollt und indirekt.

Der Reihe nach. Mint sperrt die Installation von Paketen des unsäglichen Canonical-Eigengewächses snap, indem der Daemon snapd nicht nur nicht vorinstalliert ist, sondern dessen Installation verhindert wird. Diverse Websites wollen nun ausgerechnet diese positive Entscheidung aushebeln, indem sie groß und breit erklären, wie man eine bestimmte Datei löscht. Meine Güte!

So versteigt sich omg!ubuntu in “Nemo as a super user”, um dort das File zu löschen. Ein grafischer Filemanager mit root-Rechten wird dann auch noch als “the good ol’ fashioned way”, die gute altmodische Art, verkauft.

Was steht nun drin und kann man’s nicht erst recht in Ubuntu(-Derivaten) setzen?

Mit einem Editor schreibt man in ein File “/etc/apt/preferences.d/nosnap.pref”:

Package:	snapd
Pin:		release a=*
Pin-Priority:	-10

Mit “sudo apt purge snapd” wird der Daemon gepurget, mit “sudo apt update” aktualisiert man Paketquellen und Paketquelleninhalte.

Sollte man nun snapd wieder installieren wollen, pff, meldet z.B. synaptic unerfüllte Abhängigkeiten, apt erzählt dagegen etwas von “E: Package ‘snapd’ has no installation candidate”.

Über die Nachteile dieses snap-Craps, das wie andere dieser gegenseitig konkurrierenden App-Systeme bestehende Linux-Paket-Management-Systeme konterkariert, muß man sich nicht mehr groß auslassen. In Foren fällt auf, daß unbedarfte User gar nicht merken, ob sie da gerade ein .deb oder so einen Müll, der sich auch nicht sauber ins System integriert, sprich nicht oder nicht vollständig mit anderer Software interagiert, installieren. Fällt bei fehlendem snapd flach.

Das Wesentliche, was dann unter Ubuntu nicht mehr installiert werden kann, weil es schlicht für nach 18.04 nicht mehr in den Repositories liegt (mit fadenscheiniger Begründung seitens Canonicals), ist freilich chromium. Man könnte in den sauren closed-source-Apfel beißen und chrome installieren…oder einfach zu einer vernünftigen Linux-Distribution greifen.

Neo2 unter Xubuntu

Man (also ich, grin) löst bekanntlich gern IT-Probleme anderer. Als Stichwortgeber dazu kann uude sehr vereinzelt noch herhalten (dessen Forum ist ansonsten längst nicht mehr auf absteigendem Ast, sondern schlichtweg im Loch, muß nur noch wer zuschaufeln, das einstmals gute Wiki verödet auch nur noch).

Ein User kann das sehr spezielle Keyboard-Layout Neo2 unter Xubuntu 20.04 nicht laden, weder live noch im installierten System. Bereits für XBionic hat er dazumal einen Bugreport verfaßt gehabt.

Read more “Neo2 unter Xubuntu”

Lubuntu 20.04 Focal Fossa torrent

Der Tradition halber die Kurzinfo: Heute im Laufe des Tages wird Lubuntu 20.04 freigegeben.

Torrent für Lubuntu Focal Fossa:

Die erste “LTS”-Version mit LXQt und nur noch x86_64. Spätestens mit EoS von LBionic in einem Jahr ist Schluß mit LXDE (zumindest als fertiges Image) und x86_32. Für Rechner (hauptsächlich Notebooks und Netbooks) mit x86 ohne 64-bit-Erweiterung (Pentium M bis Core Duo, eine ganze Reihe Atom) dürfte es sich dann quasi bis auf Debian erledigt haben. Letzteres wäre aber auch jetzt schon sinnvoll, lehnt man diesen snap-Unsinn Canonicals ab, insbesondere, wenn man Chromium (was es für Ubuntu und -Derivate eben seit Eoan nur noch als snap gibt) nutzen will. Man muß ja nicht das langsam wieder einstaubende stable nehmen, den sid-Treibsand auch nicht, sondern kann testing installieren.

Wer auf halbwegs zeitgemäßer Hardware permanent aktuell fahren will, nutzt sowieso sinnvollerweise eine Rolling Release Distribution, eine echte, versteht sich.

Update 2020-08-06: Link auf Point Release 1 gesetzt.

Bodhi Linux…Gruss aus der Gruft

Möglicherweise denkt der Eine oder Andere, ich hätte einen uralten Bodhi-Linux-Blogpost ‘rausgekramt. Tatsächlich ist nach langem Siechtum und einem dortigem Fahnehochhalten-Artikel letzten Juni heute Bodhi Linux 5.1.0 released worden.

Symptomatisch: je weniger Manpower, desto mehr Versionen.

Bodhi Linux setzt bekanntlich auf Ubuntu Long Term Sleeping auf, hier also 18.04. Wenn dessen offizielle Flavors wie Lubuntu EoS erreicht haben, also in 1 Jahr, ist automatisch Schluß mit x86_32. Wozu dann jetzt noch eine solche Bodhi-Version?

Read more “Bodhi Linux…Gruss aus der Gruft”

VBox: shared clipboard in v6.1.4

In VirtualBox v6.1.4 funktioniert das shared Clipboard zwischen Linux-Host und Linux-Guests nicht (paste ist ausgegraut). Genaugenommen bereits seit VBoxGuestAdditions_6.1.3-135994.iso, zumindest habe ich das Fehlverhalten dort schon bemerkt gehabt, es aber für’s Erste mit dem zu der Zeit gerade neu installierten Host mit anderer Linux-Distribution in Verbindung gebracht. Ursächlich sind aber tatsächlich die GA. Seit 9 Tagen gibt es auch Bugreport und Diskussion(en), wie dem zu begegnen wäre.

Es sind auch wirklich nur die GA, d.h. man kann 6.1.2, die vorige Final, installieren, sicherlich auch ein 6.1.3er dev-build vor obiger Version, so man noch hat.

Seit nicht mal einer Stunde gibt es (endlich wieder) ein aktuelles trunk dev-snapshot (VBoxGuestAdditions_6.1.97-136310.iso), so eine typische Versionsnummer .97 dafür. Damit funktioniert Linux-Host <> Linux-Guest wieder einwandfrei. VirtualBox-6.1.97-136310-Linux_amd64.run muß man nicht installieren.

Lieber mögliche neue Bugs als sichere alte Bugs. ;-)

Update: Statt des Snapshots kann seit 2020-03-04 das jeweils aktuelle 6.1.5er Testbuild verwendet werden.

VBox: stuttering in yt

VMs in VBox eignen sich für wirklich vieles, aber nicht gerade für yt. In Firefox (und wohl auch Chromium) starten Videos nicht wirklich, es wird scheinbar ewig gebuffert. Man muß mehrfach stoppen und starten, bis es weiter geht…ein wenig.

(Nicht nur) in diesen Browsern gibt es unter Linux keine Hardware-Unterstützung durch die GPU, geplant ist bislang auch nichts (nicht mal im closed source Chrome). D.h., das Rendering hat die CPU in Software zu übernehmen. In nativen Linux-Installationen macht sich das nicht bis kaum bemerkbar, so man nicht gerade eine Schippe Sand als CPU hat. In VBox-VMs allerdings eben schon, zumal die GPU-Treiber VBoxSVGA und VMSVGA dahingehend auch nicht die stärksten sind.

In altägyptischen Flash-Zeiten hat es mal den Workaround gegeben, per Rechtsklick (oder auch kleiner Konfigurationsdatei) im Video HW-Unterstützung zu deaktivieren, also das, was eh nicht da ist. Flash, ohnehin nie für Videos gedacht, ist aber tot (und nein, solchen Dreck installieren wir auch nicht, User ohne Plan aus einem bestimmtem Forum), mithin auch diese Einstellmöglichkeit.

Das problematische OpenGL in Hardware ausknipsen hilft bei diesem Fehlerbild auch nicht. Auch nicht, den Original-Firefox zu verwenden statt des Kompilats der jeweiligen Linux-Distribution (in debian gibt es gerade mal ein Problem, was so umgehbar ist). Alles bereits ausprobiert.

In Fx’ “about:config” gibt es mehrere Probanden, die zu testen wären. Ohne die Ursache zu kennen, ist das aber eher ein trial & error. Defaults eines frischen Profils bringen auch nichts.

Nun hat das Ganze früher mal ohne zu stottern funktioniert. Da es für mich aber keine Priorität hat (ja, das gibt es, User ohne Plan aus einem bestimmtem Forum), bin ich dem bislang nicht nachgegangen.

Um zum Punkt zu kommen, yt streamt in VP8/VP9. Eine Hardware-Unterstützung gibt es dafür bisher kaum, wohl aber für H.264. Als Linux- und OSS-Verfechter würde man natürlich lieber ein freies Format verwenden, an der Stelle muß man abwägen.

Allein Codecs installiert zu haben, genügt nicht. Dem Browser muß gesagt werden, daß er H.264 verwenden, d.h. von yt anfordern soll. Gibt’s sicherlich auch eine Möglichkeit unter “about:config”, denn etwas anderes wird das Fx-Add-on h264ify auch nicht verändern. Als Quickfix mag es genügen – und es funktioniert einwandfrei.

Btw., wenn man ein Add-on zum Ändern des User Agents installiert hat, kann man auch eine brauchbare Kombination aus OS und Browser ermitteln, dann wird H.264/mp4 gestreamt und man braucht nichts extra.

VirtualBox: libvpx5, libvpx6

virtualbox.org bietet derzeit Ubuntu-deb-Pakete nur für die letzten “LTS”-Versionen an. Üblicherweise sind diese auch für die normalen Versionen dazwischen nutzbar, sofern Abhängigkeiten erfüllt werden. So hat man VBox 6.0.14 für Bionic auch unter Cosmic und Disco installieren können. In Eoan schlägt dies allerdings fehl, da “libvpx5 (>= 1.6.0)” durch libvpx6 ersetzt worden ist.

Möglichkeiten – oder, nicht und:

  • Manuelle Installation von libvpx5 aus Disco in Eoan:
    1
    2
    
    wget http://archive.ubuntu.com/ubuntu/pool/main/libv/libvpx/libvpx5_1.7.0-3_amd64.deb
    sudo dpkg -i libvpx5_1.7.0-3_amd64.deb

    Updates dafür gibt es so natürlich keine, man muß sich selbst darum kümmern. Vor allem sollte man diese Geschichte nicht vergessen und sie wirklich nur als temporäre Sache sehen und libvpx5 bei nicht-mehr-Nutzung wieder purgen.

  • Für Eoan gibt’s 6.0.14-dfsg mit der Abhängigkeit “libvpx6 (>= 1.6.0)” in den Ubuntu-Repositories. Bis Ubuntu wie üblich wieder abgehängt wird, kann man diese Version installieren, vorher aber tunlichst die virtualbox.org-Version deinstallieren.
  • Alternativ zu deb-Paketen kann man .run installieren (für Updates gilt dasselbe). Benötigt man Testbuilds (bspw. ist VBox 6.0.15-134529 mit Kernel 5.4-rc7 im Host kompatibel), kommt man sowieso nicht umhin.

Update 2019-12-11: VBox 6.1.0 liegt auch als .deb für Eoan vor, d.h. dort ist libvpx5 keine Abhängigkeit.

Lubuntu 19.10 Eoan Ermine torrent

Kurz notiert: Heute im Laufe des Tages wird Lubuntu 19.10 freigegeben.

Torrent für Lubuntu Eoan Ermine:

(Ja, bei cdimage.ubuntu.com schafft man immer noch kein https.)

Ein weiteres Stück entfernt Canonical Ubuntu von dem, was Linux ausmacht. chromium ist mit hanebüchener Begründung nur noch als snap verfügbar, nicht mehr als .deb über die Paketverwaltung.

Der Codename für das April nächsten Jahres erscheinende Ubuntu 20.04, wieder Long Term Sleeping, lautet Focal Fossa.