[GELÖST] ifup/ifdown kann nicht gefunden werden

[tonibj82]

Hallo zusammen,

Vorweg, ich war viele Jahre (Lenny war meine letzte distri ^^) und will mich langsam aber zügig wieder ins System einarbeiten.

Ich muss ehrlich sagen, ich hatte Debian sorgenfreier in Erinnerung. angefangen von fehlenden Treibern (müssen erst für Bookworm kompeliert werden), über ISO Images die auf dem Notebook komplett abstürzen, bis hin zum jetzigen Thema, ifup/ifdown kann nicht gefunden werden.

Installiert ist es, auch reinstallieren (apt-get -o Dpkg::Options::='--force-confnew' install --reinstall ifupdown) vom Paket und auch vom "bash-completion" brachte keinen Erfolg.

lsb_release -a -d
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm

Aso und ich bin als root an dem System angemeldet.

Habt Ihr noch Ideen, was ich diesbezüglich noch tun kann?

Danke und Gruß,
Toni

[Meillo]

Code: Alles auswählen

dpkg -L <paketname>

zeigt dir alle Dateien an, die in einem Paket enthalten sind. Damit kannst du schauen, wo enthaltene Programme hininstalliert werden (um das mit $PATH abzugleichen), bzw. ob sich die erwarteten Programme ueberhaupt in dem Paket befinden.

[tonibj82]

dpkg -L ifupdown

Code: Alles auswählen

/.
/etc
/etc/default
/etc/default/networking
/etc/init.d
/etc/init.d/networking
/etc/network
/etc/network/if-down.d
/etc/network/if-down.d/resolved
/etc/network/if-post-down.d
/etc/network/if-pre-up.d
/etc/network/if-up.d
/etc/network/if-up.d/resolved
/etc/network/interfaces.d
/lib
/lib/ifupdown
/lib/ifupdown/settle-dad.sh
/lib/ifupdown/wait-for-ll6.sh
/lib/ifupdown/wait-online.sh
/lib/systemd
/lib/systemd/system
/lib/systemd/system/ifup@.service
/lib/systemd/system/ifupdown-pre.service
/lib/systemd/system/ifupdown-wait-online.service
/lib/systemd/system/networking.service
/lib/udev
/lib/udev/ifupdown-hotplug
/lib/udev/rules.d
/lib/udev/rules.d/80-ifupdown.rules
/sbin
/sbin/ifup
/usr
/usr/share
/usr/share/bug
/usr/share/bug/ifupdown
/usr/share/doc
/usr/share/doc/ifupdown
/usr/share/doc/ifupdown/NEWS.Debian.gz
/usr/share/doc/ifupdown/changelog.gz
/usr/share/doc/ifupdown/contrib
/usr/share/doc/ifupdown/contrib/ensureifup
/usr/share/doc/ifupdown/contrib/ifstate
/usr/share/doc/ifupdown/contrib/ifstate-check
/usr/share/doc/ifupdown/copyright
/usr/share/doc/ifupdown/examples
/usr/share/doc/ifupdown/examples/bridge
/usr/share/doc/ifupdown/examples/check-mac-address.sh
/usr/share/doc/ifupdown/examples/generate-interfaces.pl
/usr/share/doc/ifupdown/examples/get-mac-address.sh
/usr/share/doc/ifupdown/examples/network-interfaces
/usr/share/doc/ifupdown/examples/pattern-matching
/usr/share/doc/ifupdown/examples/pcmcia-compat.sh
/usr/share/doc/ifupdown/examples/ping-places.sh
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/ifupdown
/usr/share/man
/usr/share/man/man5
/usr/share/man/man5/interfaces.5.gz
/usr/share/man/man8
/usr/share/man/man8/ifup.8.gz
/sbin/ifdown
/sbin/ifquery
/usr/share/man/man8/ifdown.8.gz
/usr/share/man/man8/ifquery.8.gz

[rhHeini]

Versuchs mal mit

Code: Alles auswählen

~$ su -

statt einem einfachen su.

Ist eine Verschlimmbesserung durch Verschiebung von Paketen.

[tonibj82]

Danke das klappt.

Was , wann wie Häää????

steckt da eine Logik hinter oder ist das ein Bug oder wie soll man das verstehen?

Gibt es jetzt eine 2 Phasen root?

[rhHeini]

Nö, das ist gewollt. Lies mal in den Release Notes von Buster, seitdem haben wir diesen Schlunz. Uninformierte fallen immer wieder drauf rein.

Was das Problem ist? Mach mal den Versuch mit beiden Kommandos und einem folgenden

Code: Alles auswählen

echo $PATH

, dann siehst Du was los ist.

[Livingston]

Nö, das ist gewollt. Lies mal in den Release Notes von Buster, seitdem haben wir diesen Schlunz. Uninformierte fallen immer wieder drauf rein.

Oder genauer: Das ist das Standardverhalten von su und seit Buster hält sich auch Debian dran.

[rhHeini]

Oder genauer: Das ist das Standardverhalten von su und seit Buster hält sich auch Debian dran.

Leider. Ist aber in keinster Weise benutzerfreundlich. Der sinnvolle Standard-Fall darf doch nicht nur durch optionale Parameter erreichbar sein. Sieht man ja was dabei herauskommt. Nach 4 Jahren immer noch jede Menge Anwender die reintappen.
Das ist so eine Entscheidung bei der Linux und Debian sich keinen Gefallen getan haben.

[Meillo]

Oder genauer: Das ist das Standardverhalten von su und seit Buster hält sich auch Debian dran.

Leider. Ist aber in keinster Weise benutzerfreundlich. Der sinnvolle Standard-Fall darf doch nicht nur durch optionale Parameter erreichbar sein.

Mag sein. Es ist aber auch nicht benutzerfreundlich, wenn sich Programme unter Debian anders verhalten als unter anderen Unixen. Entscheidend ist zudem die Rueckwaertskompatiblitaet. (Darum muss man beispielsweise bei `diff' immer `-u' angeben und bei `du' sowas wie `-m' oder `-h'.)

`su' war halt immer schon so wie es jetzt wieder ist. Du kannst das in den Manpages von `su' von verschiedenen Unix-Versionen nachlesen. Z.B. in der 7th Edition -- die erste Version, die das Environment in der Manpage erwaehnt: http://man.cat-v.org/unix_7th/1/su

Zudem: `su -l' ist konsistent mit `sh -l'. Mit `-l' bekommt man eine Login-Shell mit frischem Environment, geaendertem Working-Directory, usw. Ohne `-l' hast du zwar eine neue Shell (unter anderem User), aber sonst ist alles erstmal gleich. Das macht IMO Sinn ... auch wenn Unix-Systeme auf dem Desktop heute typischerweise anders genutzt werden als Server frueher und daher die User heute gerne andere Defaults haetten.

[rhHeini]

Verstehe zwar die Argumente, aber manchmal muss man auch alte Zöpfe abschneiden und was neu machen.

[halo44]

Damit ich den Pfad zu Root-Befehlen su (ohne -) anwenden kann setze ich in der /etc/login.defs die Option "ALWAYS_SET_PATH yes" im Bereich "default PATH settings" ein.

Ist dagegen etwas einzuwenden? Gibts dazu Gegenargumente?

Gruß H.

[rhHeini]

Ich hatte den Eindruck gewonnen dass das nicht mehr funktioniert. Grad nochmal gecheckt in einer VM mit Testing wo ich da noch nicht rumgeschraubt hatte: mit dem Eintrag wird der Pfad auf den superuser-Pfad gesetzt, aber ich stehe in meinem home-Directory. Das mag ich gar nicht als root.

[tobo]

Damit ich den Pfad zu Root-Befehlen su (ohne -) anwenden kann setze ich in der /etc/login.defs die Option "ALWAYS_SET_PATH yes" im Bereich "default PATH settings" ein.

Ist dagegen etwas einzuwenden? Gibts dazu Gegenargumente?

Der empfohlene/offizielle Weg ist über /etc/default/su:
https://wiki.debian.org/EnvironmentVariables#Using_su

Update advice on ALWAYS_SET_PATH to use /etc/default/su (Closes: #905564)

[rhHeini]

Funktioniert beides was den $PATH angeht. Aber beides lässt den Pfad des Terminals im User-Home. Und das ist für mich ein NoGo.

Nebenbei gesagt, die allermeisten die 'neintappen lesen keine Readme's, keine Release Notes, ....

[tobo]

Man bleibt nicht im $HOME stehen, sondern im $PWD und das ist ja auch weitestgehend logisch, wenn sich nur $PATH zum ursprünglichen Verhalten ändert. Das ist dann halt so, wie es früher war. Wer das braucht oder will, der sollte es so machen, wie die Debian-Leute es vorschlagen...

[cosinus]

Nebenbei gesagt, die allermeisten die 'neintappen lesen keine Readme's, keine Release Notes, ....

Liest du denn immer von jedem Update die Releasenotes des entsprechenden neues Pakets?

[rhHeini]

Man bleibt nicht im $HOME stehen, sondern im $PWD und das ist ja auch weitestgehend logisch, wenn sich nur $PATH zum ursprünglichen Verhalten ändert.

Ist richtig, Du hast natürlich Recht. Ich starte in meinen VMs halt immer ein User-Terminal, das sich dann halt in meinem Home-Dir befindet. Auf meiner Workstation hab ich mir einen Starter gebastelt der ein root-Terminal in /root aufmacht um den su - Kladderadatsch zu umgehen.

Liest du denn immer von jedem Update die Releasenotes des entsprechenden neues Pakets?

Sicherlich nicht von jedem Paket. Aber bei neuen Releases mach ich das. Auch wenn ich das schon als Testing hatte und dadurch viele Fallstricke bereits kenne. Hab schon zu viele Überraschungen erlebt zwischen Sarge und Trixie.

[halo44]

Man bleibt nicht im $HOME stehen, sondern im $PWD ...

Das ist genau das, was ich will. Im Pfad, den ich z.B. im Dateimanager mittels "Terminal hier öffnen" gewählt habe, mit Root-Rechten arbeiten.

Gruß H.