Die Alternatives Problematik.

[weedy]

Hi,

ich installierte kürzlich libvirt-bin und stellte fest, dass daraufhin die netcat-alternative (nc) sich von /bin/nc.traditional auf /bin/nc.openbsd geändert hatte.

Daraufhin funktionierten einige meiner Scripte nicht mehr, die einfach nc verwendeten. Ok, mein Fehler, ich muss wohl in der Zukunft immer checken, ob eine Alternativierung pro genutztem Tool vorliegt und dann das entlinkte Binary direkt nutzen, also in dem Fall /bin/nc.traditional statt nc.

Nun ist das Alternatives-System ja darauf ausgelegt, dass sich der User das Tool installiert, welches er lieber nutzen möchte (was nun durch die Installation von nc.openbsd verändert wurde, was ich eigentlich nicht möchte). Aber zum eigentlichen Problem: mir kam der Verdacht, dass sich libvirt-bin selber nur auf nc statt nc.openbsd beziehen könnte, da die Entwickler von libvirt-bin und die Maintainer bei Debian möglicherweise ganz unterschiedliche Leute sind.

Tatsächlich fand ich dazu folgendes:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=538799

D.H. mit anderen Worten: setze ich oder eine andere Installation nc zurück von .openbsd auf .traditional oder auf eine weitere Alternative, würde libvirt-bin nicht mehr funktionieren.

Nun ist es so, dass alle anderen Pakete ähnliche Probleme haben könnten.

Eine Lösung könnte darin bestehen, das Alternatives-System pro User zu realisieren. Oder pro Lib. Dann wäre das Problem nie aufgetaucht.

Sind vieleicht Überlegungen bekannt, die Alternatives zu reformieren?

Oder gibt es vieleicht schon eine andere Lösung für das allgemeine Problem?

Gruß

[TRex]

Keine "systemweite" oder gar globale Lösung, aber ich hab ein ~/bin (manchmal auch .bin) und das liegt in meinem Pfad. Würde ich nun alternatives pro user haben wollen, dann stünden die Symlinks dazu (von mir erstellt) da drin. Hätte ich da ein systematisches Pattern, hätte ich dafür irgendwo update-user-alternatives in meinem Pfad liegen.

Wenn du eine debian-weite Diskussion dazu (oder eine Änderung herbeiführen) möchtest, würde ich nen bugreport an dpkg adressieren, welches update-alternatives beinhaltet und auf eine konstruktive Lösung hoffen.

[KBDCALLS]

Mit welcher Version ? Und welcher Distri?

Habs mal spaßeshalber installiert. Und das hat update-alternatives ausgespukt.

Code: Alles auswählen

root@tatjana:/home/matthias# update-alternatives --config  nc
Es gibt 3 Auswahlmöglichkeiten für die Alternative nc (welche /bin/nc bereitstellen).

  Auswahl      Pfad                 Priorität Status
------------------------------------------------------------
* 0            /bin/nc.openbsd       50        automatischer Modus
  1            /bin/nc.openbsd       50        manueller Modus
  2            /bin/nc.traditional   10        manueller Modus
  3            /bin/nc6              50        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein:

Vorher wie nachher

[rendegast]

Identische Parameter nc.openbsd / nc.traditional

Code: Alles auswählen

-C
-h
-i delaysecs
-l
-n
-p port
-q quitsecs
-r
-s source
-t
-u
-v
-w timeout
-z

Du könntest Deine Skripte vielleicht dahingehend abändern.

Oder eine Weiche einbauen, Merkmal zBsp.

Code: Alles auswählen

$ nc -h
OpenBSD netcat (Debian patchlevel 1.105-7)

<->

Code: Alles auswählen

$ ./nc.traditional -h
[v1.10-41]

[weedy]

Keine "systemweite" oder gar globale Lösung, aber ich hab ein ~/bin (manchmal auch .bin) und das liegt in meinem Pfad. Würde ich nun alternatives pro user haben wollen, dann stünden die Symlinks dazu (von mir erstellt) da drin. Hätte ich da ein systematisches Pattern, hätte ich dafür irgendwo update-user-alternatives in meinem Pfad liegen.

Wenn du eine debian-weite Diskussion dazu (oder eine Änderung herbeiführen) möchtest, würde ich nen bugreport an dpkg adressieren, welches update-alternatives beinhaltet und auf eine konstruktive Lösung hoffen.

Mir ist da eine Idee gekommen. Am sichersten wäre es, wenn man einen eigenen nc-Stub baut und bei den Alternatives für nc einträgt. Und immer, wenn nc gestartet wird, bekommt der User eine Mail oder eine Info auf anderem Wege und dann kann man entscheiden, welches der nc-Varianten verwendet werden soll.

Bei awk ist das ja quasi egal, weil alle awk-Varianten (gawk, mawk, nawk) semantisch bis auf wenige Zusatzfeatures exakt gleich sind. Daher störrt es nicht wenn sämtliche Programme plötzlich ein anderes kompatibles awk verwenden. Aber dummerweise sind die nc-Versionen nicht ohne weiteres austauschbar.

Gut, der nc-Stub jedenfalls könnte also entweder den User fragen oder die Stacktrace analysieren und anhand der Stacktrace herausfinden ob einem spezifischen Programm eine nc-Variante zugewiesen worden ist. Oder anhand übergebener Parameter herausfinden, ob eine Zuweisung zu einer der nc-alternativen eindeutig ist.

Die Stacktrace könnte vieleicht mit pstack gemacht werden, wenn endlich mal eine 64-Bit-Version existiert - interessanterweise ist das Package zwar im 64bit Repository und 64bit kompiliert, funktioniert aber nur mir 32bit Programmen laut Manpage.

Oder man verwendet sysdig, aber, das ist wohl Overkill.

Am einfachsten wäre sicher ein selbstgebastelter Cache der Prozess-Hierarchie aus /proc.

Oder eine ganz andere Variante wäre, dass man für ein Binary immer eine voreingestellte festgelegte Pfadvariable hat. Da könnte dann nc pro Programm immer auf das richtige zeigen, indem pro Programm ein spezieller Binärpfad durchlaufen wird vor den Standard-Binärpfaden.

Am besten wäre es, wenn man die Alternatives als execve-Stub realisiert hätte, dann wäre die Flexibilität grenzenlos. Das Debugging aber auch, denn dann ist es noch schwerer, rauszufinden, welches Programm denn nun welches andere Programm überhaupt aufgerufen hat.

Gruß