Wicd - warum nicht in testing / stretch

[wckl]

Hallo,
ich hatte wicd als Netzwerk-Manager installiert.
Leider ist wicd nicht mehr in testing enthalten.

Mit wicd hatte ich bezüglich der Verwaltung der Verbindungen über Kabel oder Funk keine Probleme, mit Network-Manager ständig. Ich habe den Eindruck, Network-Manager kommt mit den neuen System-Verwaltungen nicht mehr zurecht.

Wicd ist in unstable enthalten - warum nicht in testeing?

Vielen Dank.
wckl

[KBDCALLS]

Da steht der Grund

• https://packages.qa.debian.org/w/wicd/n ... 3907Z.html

[wckl]

Und das kann nicht behoben werden?

[eggy]

Doch sicher:
a) Bugreport lesen
b) schauen ob für den Fehler Upstream bereits ein Patch besteht oder er behoben ist (gemeldet wurde er, den Launchpad-Link findet Du im Bugreport)
c.I) falls ja: warten bis das Paket in sid getestet wurde und nach testing kommt
c.II) falls nein: Fehler finden (z.B. durch Vergleich des Codes der Vorversionen, siehe Beschreibung in Launchpad), Fehler beheben, Patch für Fehler an Upstream senden, Debianbugreport aktualisieren und weiter bei b)

Es muss halt jemand machen.

[wckl]

Dummerweise kann ich es eben nicht

[KBDCALLS]

Das könnte schierig werden , das Paket ist orphaned/verwaist. Also kümmert sich keiner drum.

[dirk11]

Das ist schlecht. Ich setze auch auf wicd, weil es besser als network-manager ist, kann derlei Änderungen aber auch nicht vornehmen.

[eggy]

Das könnte schierig werden , das Paket ist orphaned/verwaist.

Zumindest ein DD bietet Sponsoring/Team-Upload an: https://bugs.debian.org/cgi-bin/bugrepo ... bug=801253
Also sind wir wieder bei "Es muss halt jemand machen."

[dirk11]

Also sind wir wieder bei "Es muss halt jemand machen."

Ja. Das bedingt aber "es muß halt jemand können". Und ich kann es mangels Wissen und Zeit nicht.

[Blackbox]

Ich setze auch auf wicd

Vielleicht willst du dir ja einmal Intels connman bzw. connman-ui anschauen ?
Weiterhin gibt es auch connman-vpn

[dirk11]

Ich setze auch auf wicd

Vielleicht willst du dir ja einmal Intels connman bzw. connman-ui anschauen ?
Weiterhin gibt es auch connman-vpn

Wäre das in Zukunft eine Alternative? Meine einzige Bedingung ist, daß vor Beendigung einer WLAN-Verbindung ein script ausgeführt werden kann (anders gesagt: _vorher_ muss ein nfs-mount umountet werden) und das LAN dem WLAN bevorzugt wird, sprich wenn ein LAN-Kabel eingesteckt wird, soll die WLAN-Verbindung zugunsten LAN gekappt werden. wicd kann das, network-manager nicht.

[catdog2]

Wäre das in Zukunft eine Alternative? Meine einzige Bedingung ist, daß vor Beendigung einer WLAN-Verbindung ein script ausgeführt werden kann (anders gesagt: _vorher_ muss ein nfs-mount umountet werden)

Kann der NM.

und das LAN dem WLAN bevorzugt wird, sprich wenn ein LAN-Kabel eingesteckt wird, soll die WLAN-Verbindung zugunsten LAN gekappt werden. wicd kann das, network-manager nicht.

Wird man wohl ein paar Zeilen skripten müssen, aber sollte sich lösen lassen.

//edit:
Nur so am Rande, noch netter ist übrigens die Verbindung nicht zu kappen sondern Wlan und Kabel in ein Bond device zu packen, wenn die im selben Netz sind kann man dann hin und her wechseln ohne laufende Verbindungen zu töten. Selbst sowas lässt sich mit nem zugegeben etwas dreckigen skript realisieren: http://paste.debian.net/423417/ (Leider kann der NM nativ kein bond mit wlan Geräten und mit dem neueren teaming Treiber hatte es nicht geklappt als ich das gebaut hab).
So ganz generell gesehen hat sich der NM wirklich gemacht, lässt sich u.a. mittlerweile auch ganz schön per Kommandozeile bedienen.

[rendegast]

Bei dem bug-report 816076, der Ursache für die Maßnahme,
wundert mich doch die Aufregung des Posters über den Fehler eines testing/unstable-Pakets.

Und wenn jemand testing/unstable fern-remote verwendet,
sollte er/sie doch ein entsprechendes fallback eingerichtet haben.






Bei mir hat ein Upgrade wicd 1.7.2->1.7.4 in einer jessie-VM deren

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet dhcp

und eine laufende ssh-Verbindung nicht beeinträchtigt.
Der Maintainer konnte den Fehler des Bug-Posters halt nachstellen.

Weiterhin konnte ich die Verbindung gar nicht killen
- 'ifdown eth0'
- 'ifconfig eth0 down'
sogar mal das Netzwerkkarten-Modul entladen
- 'modprobe -vr e1000' (das durfte wicd wohl nicht machen)
Die Fähigkeiten von systemd und ssh erhielten die Verbindung.
----------
Okay, bei ein bischen Herumspielen in wicd-curses, meines Glaubens ohne Konfigurationsänderung, ist eth0 doch dekonfiguriert worden.
ssh-Verbindung war weg und die Konsolensitzung ausgeloggt.
'ifdown eth0; ifup eth0' war die VM wieder online.

[dirk11]

Wäre das in Zukunft eine Alternative? Meine einzige Bedingung ist, daß vor Beendigung einer WLAN-Verbindung ein script ausgeführt werden kann (anders gesagt: _vorher_ muss ein nfs-mount umountet werden)

Kann der NM.

und das LAN dem WLAN bevorzugt wird, sprich wenn ein LAN-Kabel eingesteckt wird, soll die WLAN-Verbindung zugunsten LAN gekappt werden. wicd kann das, network-manager nicht.

Wird man wohl ein paar Zeilen skripten müssen, aber sollte sich lösen lassen.

Seit wann kann NM das? Ich bin vor einigen Jahren gewechselt, weil er genau das nicht konnte.

//edit:
Nur so am Rande, noch netter ist übrigens die Verbindung nicht zu kappen sondern Wlan und Kabel in ein Bond device zu packen, wenn die im selben Netz sind kann man dann hin und her wechseln ohne laufende Verbindungen zu töten. Selbst sowas lässt sich mit nem zugegeben etwas dreckigen skript realisieren: http://paste.debian.net/423417/ (Leider kann der NM nativ kein bond mit wlan Geräten und mit dem neueren teaming Treiber hatte es nicht geklappt als ich das gebaut hab).
So ganz generell gesehen hat sich der NM wirklich gemacht, lässt sich u.a. mittlerweile auch ganz schön per Kommandozeile bedienen.

Bond-Device klingt interessant. Momentan klappt das auch so, weil z.B. dnsmasq (ebenso wie bind9) in der Lage ist, eine IP für mehrere MAC zu reservieren, so bekommt das Laptop via LAN und WLAN immer dieselbe IP. Aber erst machste mich heiß auf Bond-Device, um dann im nächsten Satz zu schreiben, daß NM das nicht kann...