Univention Bugzilla – Bug 8994
Network-Manager als Ersatz für ifplugd
Last modified: 2009-12-21 08:46:48 CET
Der Network-Manager ist ein DBUS-Service, der Festnetz sowie WLAN automatisch erkennen und konfigurien kann. Einerseits übernimmt er zusammen mit hald die Aufgabe vom ifplugd und zusätzlich gibt es für den Desktop (KDE oder GNOME) ein kleines Programm, dass den Status anzeigt und es ermöglich WLAN-Konfiguration zu speichern, so dass automatisch eine Verbindung hergestellt werden kann. Für die Desktopanbindung muss der Benutzer in der lokalen Gruppe netdev sein. Die Skripte, die der ifplugd momentan ausführt (gdm, nscd, mount unter /etc/ifplugd/action.d) wenn der Status der Netzverbindung sich ändert können von dem NetworkManager (evtl mit leichten Anpassungen) auch ausgeführt werden (im /etc/NetworkManager/dispatcher.d/ abzulegen)
Zusätzlich müsste auf einem Mobile Client das Skript /usr/share/univention-mobile-client/check_connection angepasst werden. Evtl wäre es sogar besser dies auch als ein Network-Manager-Dispatcher Skript zu schreiben.
Zusätzlich muss bei der Verwendung des NetworkManager das Template für /etc/network/interfaces angepasst werden: Der NetworkManager kontrolliert nur Interfaces die dort nicht mit einer Koonfiguration eingetragen sind. Also sollte der Typ per Config Registry auf dhcp gesetzt werden, dann sollte nichts eingetragen werden.
network-manager depended auf dhcpd, welches dhcp3-client benötigt; daher muss vor dem Einsatz des network-managers Bug 10841 behoben sein.
Created attachment 1137 [details] optional use network-manager Die Skripte, die sonst über den ifplugd gestartet wurden, sind jetzt in /etc/network/if-(up|down).d abgelegt und können so vom Network Manager und vom ifplugd verwendet werden. Zusätzlich wir das Skript check_connection bei Änderung des Status eines Netz-Interefaces gestartet. Die Abhängigkeiten von univention-(mobile|managed)-client wurden angepasst, so dass ifplugd oder network-manager verwendet werden kann.
Gebaut ist diese Erweiterung im desktop-experimental Scope Patch: patches/univention-server/2.1-0-0-ucs/3.0.0-1-desktop-experimental/00_support-nm.patch
Ich habe den Bug in den Desktop-Bereich geschoben. Allerdings sollten auch die Serversysteme berücksichtigt werden. In UCS 2.3 ist derzeit die 0.7er Version gebaut. knetworkmanager wurde ebenfalls aktualisiert.
Da hat sich anscheinend was geändert im network-manager: 0.6.4-6.2.200710211523 /usr/share/doc/network-manager/README.Debian : Only devices that are *not* listed in /etc/network/interfaces or which have been configured "auto" and "dhcp" (with no other options) are managed by NM. 0.7.1-1.6.200905062158 /usr/share/doc/network-manager/README.Debian : Devices listed in /etc/network/interfaces _will_ be managed by NetworkManager unless the ifupdown system-config-setting is enabled and is setup to run in "Unmanaged mode". [...] Unmanaged mode will make NetworkManager not touch any wired/wireless device matching an interface name configured in /etc/network/interfaces. Vermutlich muss das Template für /etc/network/interfaces und /etc/NetworkManager/nm-system-settings.conf angepasst werden. Derzeit wird in /etc/network/interfaces immer "iface ethX inet [dhcp|static]" geschrieben und solange interfaces/eth%s/networkmanager nicht auf 'no' gesetzt wird, wird auch "auto ethX" eingetragen. Da derzeit in den nm-system-settings "managed=false" gesetzt ist, kümmert sich der NM theoretisch nicht mehr um die Interfaces. Dummerweise kann man jetzt wohl managed nicht pro Interface setzen, was die Abbildung der alten ifplugd Logik erschwert?
Wenn wir NetworkManager für Serversysteme einsetzen, sollten wir verstehen, wie wir per dbus-send den Status der Interfaces abfragen und ändern können, sonst kämpfen wir ggf. am NetworkManager vorbei oder gegen ihn. Mir ist z.B. noch nicht klar, wie man NM_DEVICE_STATE und NM_DEVICE_STATE_REASON aus dem Teil herauslesen und interpretieren muss. Die API hat sich mit 0.7 anscheinend auch nochmal geändert. Was ich herausgefunden habe, ist dass das Teil per 'dhcdbd' wieder dhclient aufruft, und zwar mit '-sf nm-dhcp-client.action'. Dieses action binary ersetzt /sbin/dhclient-script und liest so die Antworten von dhclient wieder in den nm-dhcp-manager ein. Ziel dieses Verfahrens scheint zu sein, dass es egal ist, ob man dhclient oder dhcpcd verwendet, in beiden Fällen landet die Antwort bei nm-dhcp-manager. Leider kann man sich dadurch nicht mehr einfach in das dhclient-script reinhängen, um mitzubekommen, ob dhclient etwas sinnvolles zurückgeliefert hat. Ideal wäre hier meiner Meinung nach, wenn man ein Script beim NetworkManager registrieren könnte um über State-Änderungen informiert zu werden. Sonst weiß man nicht wann man pollen soll, um auf Fehler zu reagieren.
(In reply to comment #8) > Ideal wäre hier meiner Meinung nach, wenn man ein Script beim NetworkManager > registrieren könnte um über State-Änderungen informiert zu werden. Sonst > weiß man nicht wann man pollen soll, um auf Fehler zu reagieren. Dafür gibt es den NetworkManagerDispatcher. Dieser wird allerdings, soweit ich weiss nur bei "positiven" Ereignissen aufgerufen. Also sowas wie 'if-preup', 'if-up', 'if-down' und 'ifpostdown'. Diese Möglichkeit nutzen wir auch auf den Clients. Die Skripte dafür liegen unter /etc/network/if-(up|pre-up|down|post-down).d/ Da der NetworkManager im Fehlerfall von DHCP einen Fallback auf ZeroConf macht, gibt es (zumindest bei meinen Tests) immer eine Adresse (Siehe Bug #12130 Comment #2). Anhand des Subnetzen kann man erkennen, dass diese von ZeroConf kommt.
Die resolv.conf sollte vom Network Manager so geschrieben werden, dass nameserver/option/timeout ausgewertet wird, siehe svn/patches/dhcp3/2.2-0-0-ucs/3.0.4-13/54_scripts_linux.patch.
Vielleicht kann man statt der if-up.d Scripte zur Reaktion auf dhclient Antworten auch die /etc/dhcp3/dhclient-exit-hooks.d/ verwenden. Dort liegt bei mir z.B. dhcdbd, welches wieder per dbus-send quasi das ganze erhaltene Environment an com.redhat.dhcp zurückmeldet. Das Environment enthält da auch noch alle Sachen, die der DHCP Server geliefert hat, wohingegen man in den ip-up.d Scripten nur die notwendigsten Infos (IFACE, METHOD) erhält. Folgendes bekam ich z.B. wenn ich einfach eine Datei mit 'env > /tmp/dhclient.env' in das Verzeichnis gelegt habe: old_subnet_mask=255.255.255.0 old_domain_name_servers=192.168.0.3 192.168.0.46 old_broadcast_address=192.168.0.255 old_expiry=1248879329 old_filename=pxelinux.0 new_subnet_mask=255.255.255.0 new_domain_name=knut.univention.de new_ip_address=192.168.0.159 new_network_number=192.168.0.0 interface=eth0 reason=BOUND old_dhcp_message_type=5 new_expiry=1248922544 new_dhcp_lease_time=43200 new_dhcp_server_identifier=192.168.0.12 new_routers=192.168.0.240 dhc_dbus=31 new_domain_name_servers=192.168.0.3 192.168.0.46 old_dhcp_server_identifier=192.168.0.46 new_dhcp_message_type=5 old_ip_address=192.168.0.159 old_dhcp_lease_time=43200 new_broadcast_address=192.168.0.255 new_filename=pxelinux.0 old_network_number=192.168.0.0 old_routers=192.168.0.240 old_domain_name=knut.univention.de
Die Verwendung der Skripte im DHCP-Client wären sicherlich die schönere Lösung, allerdings ist der Aufwand für die Kontrolle des NetworkManager über Dbus deutlich höher. Es ist auch nicht klar, ob der NetworkManager die volle Konfiguration von extern überhaupt erlaubt. Daher werden wir jetzt doch die Alternative wählen und in dem Skript vom NetworkManagerDispatcher auf eine ZeroConf-Adresse prüfen und dann ggf. die notwendigen Anpassungen vornehmen.
Die Unterstützung für den Network Manager ist jetzt in das Paket univention-network-manager ausgelagert. Der Network Manager ist so konfiguriert, dass er sich nur um Interface mit DHCP Konfiguration kümmert. Alle statischen Interfaces werden wie zuvor behandelt. Für den Fall, dass per DHCP keine Antwort kommt gibt es einen Fallback Mechanismus. Dabei wird aus den Variablen interfaces/<interface>/fallback/* die Konfiguration gelesen und an den Network Manager weitergegeben. Zusätzlich gibt es noch die Variable fallback/gateway. Wenn es eine Antwort per DHCP gab, kann über die UCR Variable networkmanager/dhcp/options/fallback definiert werden, ob fehlende Informationen aus der lokalen Konfiguration ergänzt werden sollen. Voreingestellt ist die Variable auf 'no'. Folgende Optionen können aus der lokalen Konfiguration ergänzt werden: - nameserver - hostname - domainname - gateway - domain search Der Network Manager ist jetzt global aktiviert und ersetzt wenn vorhanden den ifplugd.
root@omar:/# apt-get install -s network-manager-gnome network-manager Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: network-manager: Recommends: dnsmasq-base but it is not installable Breaks: network-manager-gnome (< 0.7~~) but 0.6.6-4.2.200904091602 is to be installed E: Broken packages
Das GNOME Frontend sowie die Erweiterungen für VPNC und OpenVPN lassen sich jetzt auch installieren.
Es gibt hier noch ein Problem, dass mir beim meinem Update aufgefallen ist: Das Skript /etc/network/if-up.d/05* ruft check_connection auf. Das wiederum ruft die Skripte vom NetworkManagerDispatcher auf. Der wiederrum ruft die Skripte in /etc/network/if-up.d/ ... somit bekommen wir hier eine Schleife. Das muss erkannt werden.
check_connection prüft, ob es schon läuft und beendet sich dann gegebenfalls sofort wieder.
Update Test auf amd64: Selecting previously deselected package network-manager. dpkg: regarding .../network-manager_0.7.1-1.7.200909102157_amd64.deb containing network-manager: package uses Breaks; not supported in this dpkg dpkg: error processing /var/cache/apt/archives/network-manager_0.7.1-1.7.200909102157_amd64.deb (--unpack): unsupported dependency problem - not installing network-manager Selecting previously deselected package univention-network-manager.
Ich hab die Breaks Zeile einfach im control File entfernt. Paket baut gerade neu.
Der Network Manager funktioniert auf einem Basissystem nicht richtig. Nach dem Boot bekomme ich erst eine IP, wenn ich dbus neu starte.
> Der Network Manager funktioniert auf einem Basissystem nicht richtig. Nach dem > Boot bekomme ich erst eine IP, wenn ich dbus neu starte. Das war ein Problem der Basissystem Installation.(In reply to comment #20)
Einen sehr ähnlichen Zustand wie an Bug #15967 habe ich auf einem Master mit DHCP Option: Als der externe DHCP-Server zufällig nicht erreichbar war (VM aus), hat der NetworkManager kein Fallback für das Interface konfiguriert. ifconfig zeigt eth0 ohne IPv4 Adresse an, nm-tool zeigt es als 'disconnected' an. route zeigt weder eine route für eth0 noch eine default route an. Es existiert keine Datei /tmp/nm-env, was darauf hinweist, das /usr/lib/NetworkManager/nm-dhcp-client.action bisher nicht durch dhclient aufgerufen wurde. Auch im daemon.log ist keine Meldung von dhclient, dafür aber von nm-system-settings: --------------------------------------------------------------------------- Nov 10 14:37:28 beta3 NetworkManager: <info> starting... Nov 10 14:37:38 beta3 nm-system-settings: Error getting hardware address for /org/freedesktop/Hal/devices/net_00_0c_29_46_dc_01: (4) Did n ot receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the repl y, the reply timeout expired, or the network connection was broken. --------------------------------------------------------------------------- Dann habe ich die VM des externen DHCP Servers wieder resumed und etwas gewartet. Network-manager machte von sich aus keinen neuen dhclient Versuch. /etc/init.d/network-manager restart nimmt dann kurzzeitig das device down, startet aber ebenfalls dhclient nicht. Erst die Befehle /etc/init.d/network-manager stop; killall nm-system-settings; /etc/init.d/network-manager start brachten das gewünschte Ergebnis: --------------------------------------------------------------------------- Nov 10 14:52:04 beta3 NetworkManager: <info> starting... Nov 10 14:52:12 beta3 nm-system-settings: nm_sysconfig_connection_init: error creating PolicyKit context: (unknown) (-1): (unknown) Nov 10 14:52:12 beta3 nm-system-settings: Added default wired connection 'Auto eth0' for /org/freedesktop/Hal/devices/net_00_0c_29_46_dc_0 1 Nov 10 14:52:12 beta3 NetworkManager: <info> (eth0): new Ethernet device (driver: 'pcnet32') Nov 10 14:52:12 beta3 NetworkManager: <info> (eth0): exported as /org/freedesktop/Hal/devices/net_00_0c_29_46_dc_01 Nov 10 14:52:12 beta3 NetworkManager: <info> (ttyS1): ignoring due to lack of mobile broadband capabilties Nov 10 14:52:12 beta3 NetworkManager: <info> (ttyS0): ignoring due to lack of mobile broadband capabilties Nov 10 14:52:17 beta3 NetworkManager: <info> (eth0): device state change: 1 -> 2 Nov 10 14:52:17 beta3 NetworkManager: <info> (eth0): bringing up device. Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): preparing device. Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): deactivating device (reason: 2). Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): carrier now ON (device state 2) Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): device state change: 2 -> 3 Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) starting connection 'Auto eth0' Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): device state change: 3 -> 4 Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started... Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting... Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): device state change: 4 -> 5 Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful. Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete. Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started... Nov 10 14:52:18 beta3 NetworkManager: <info> (eth0): device state change: 5 -> 7 Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Beginning DHCP transaction. Nov 10 14:52:18 beta3 dhclient: Internet Systems Consortium DHCP Client V3.1.1 Nov 10 14:52:18 beta3 dhclient: Copyright 2004-2008 Internet Systems Consortium. Nov 10 14:52:18 beta3 dhclient: All rights reserved. Nov 10 14:52:18 beta3 dhclient: For info, please visit http://www.isc.org/sw/dhcp/ Nov 10 14:52:18 beta3 dhclient: Nov 10 14:52:18 beta3 NetworkManager: <info> dhclient started with pid 5934 Nov 10 14:52:18 beta3 NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. Nov 10 14:52:26 beta3 dhclient: Listening on LPF/eth0/00:0c:29:46:dc:01 Nov 10 14:52:26 beta3 dhclient: Sending on LPF/eth0/00:0c:29:46:dc:01 Nov 10 14:52:26 beta3 dhclient: Sending on Socket/fallback Nov 10 14:52:26 beta3 NetworkManager: <info> DHCP: device eth0 state changed (null) -> preinit Nov 10 14:52:30 beta3 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 Nov 10 14:52:30 beta3 dhclient: DHCPOFFER from 10.200.8.43 Nov 10 14:52:30 beta3 dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Nov 10 14:52:30 beta3 dhclient: DHCPACK from 10.200.8.43 Nov 10 14:52:39 beta3 NetworkManager: <info> DHCP: device eth0 state changed preinit -> bound Nov 10 14:52:39 beta3 NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP Configure Get) scheduled... Nov 10 14:52:39 beta3 NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP Configure Get) started... Nov 10 14:52:39 beta3 NetworkManager: <info> address 10.200.8.60 Nov 10 14:52:39 beta3 NetworkManager: <info> prefix 24 (255.255.255.0) Nov 10 14:52:39 beta3 NetworkManager: <info> gateway 10.200.8.1 Nov 10 14:52:39 beta3 NetworkManager: <info> nameserver '10.200.8.43' Nov 10 14:52:39 beta3 NetworkManager: <info> domain name 'univention.de' Nov 10 14:52:39 beta3 NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled... Nov 10 14:52:39 beta3 NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP Configure Get) complete. Nov 10 14:52:39 beta3 NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) started... Nov 10 14:52:39 beta3 dhclient: bound to 10.200.8.60 -- renewal in 20211 seconds. Nov 10 14:52:40 beta3 NetworkManager: <info> Clearing nscd hosts cache. Nov 10 14:52:40 beta3 NetworkManager: <info> (eth0): device state change: 7 -> 8 Nov 10 14:52:40 beta3 NetworkManager: <info> Clearing nscd hosts cache. Nov 10 14:52:40 beta3 NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS. Nov 10 14:52:40 beta3 NetworkManager: <info> Activation (eth0) successful, device activated. Nov 10 14:52:40 beta3 NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete. Nov 10 14:52:41 beta3 named[4398]: received control channel command 'reconfig' Nov 10 14:52:41 beta3 named[4398]: loading configuration from '/etc/bind/named.conf.proxy' Nov 10 14:52:41 beta3 named[4398]: max open files (1024) is smaller than max sockets (4096) Nov 10 14:52:41 beta3 named[4398]: using default UDP/IPv4 port range: [1024, 65535] Nov 10 14:52:41 beta3 named[4398]: using default UDP/IPv6 port range: [1024, 65535] Nov 10 14:52:41 beta3 named[4398]: listening on IPv4 interface eth0, 10.200.8.60#53 Nov 10 14:52:41 beta3 named[4398]: reloading configuration succeeded Nov 10 14:52:41 beta3 named[4398]: any newly configured zones are now loaded Nov 10 14:52:46 beta3 ntpdate[6029]: no servers can be used, exiting --------------------------------------------------------------------------- ifconfig zeigt IPv4 Adresse, route zeigt network und default route und nm-tool sagt 'State: connected', und dhclient läuft vom NetworkManager mit folgenden Argumenten gestartet: /sbin/dhclient -d -sf /usr/lib/NetworkManager/nm-dhcp-client.action \ -pf /var/run/dhclient-eth0.pid -lf /var/lib/dhcp3/dhclient-eth0.lease \ -cf /var/run/nm-dhclient-eth0.conf eth0 Mein Vorschlag wäre, nm-system-settings im network-manager stop script mit zu stoppen. Das scheint nach einer aufschlussreichen Diskussion auch die Meinung der aktuellen NM-Entwickler zu sein: http://www.mail-archive.com/networkmanager-list@gnome.org/msg12504.html Patch hier: http://www.mail-archive.com/networkmanager-list@gnome.org/msg13600.html
network-manager ist mit 02_nm-system-settings_stop.patch neu gebaut.
So wie in dem von Arvid beschrieben Fall: Auf aktuellen 2.3 Master Systemen (per DHCP installiert), i386 sowie amd64, funktioniert der Fallback nicht, wenn der dhcp-Server nicht erreichbar ist (VM suspended). Allerdings ist die /tmp/nm-env vorhanden. Die ucr Variablen für interfaces/fallback wurden allerdings richtig gesetzt, auch die interfaces/eth0/address z.B. ist noch vom System gesetzt.
Hier kamen wohl zwei/drei Dinge zusammen: * Das Fallback Script stieg mitten im FAILED handling aus, weil ein None Wert in os.environ geschrieben wurde. * ucr.get('gibtsnicht') liefert neuerdings None, auf meinem UCS 2.2 Notebook liefert es noch einen leeren String. * Der dhclient Prozess scheint beim Booten mit 'timout'=40 sec zu lange zu brauchen und wird dann von NetworkManager beendet, wodurch dann das Fallback Script nicht mehr ausgeführt wird. (Sieht man daran, dass reason=PREINIT in /tmp/nm-env ewig stehen bleibt). Vermutlich liegt das daran, dass dhclient beim reboot eine Anzahl von 'reboot' Sekunden versucht, die alte Adresse wieder zu bekommen bevor es den normalen 'timeout' startet. Ich habe jetzt mal reboot in der dhclient.conf fest auf 5 gesetzt (standard ist 10) und 'timeout von 40 auf 30 reduziert. Bei timeout=35 sagte NetworkManager dass dhclient merh als 45 sec benötigt hat, das Fallback Script war aber trotzdem ausgeführt.
Ich mache den Bug mal wieder auf. Wir hatten heute Abend bei den internen Updates einige Probleme mit dem NetworkManager, dbus & Co. Unter anderem konnte visdalen nicht gestartet werden, da dbus auch nach mehreren Minuten nicht durch war. Nach einem init=/bin/sh und dem Entfernen der rc2.d-Skripte von dbus, hal und network-manager bootete dieser schnell und einfach durch. Mein Eindruck ist, dass wir auf dem Server mit dem NetworkManger absolut keinen Vorteil haben und dort besser weiterhin den ifplugd verwendet sollten. Wenn wir den Server als dhcp-client verwenden, dann gewinnen wir vermutlich etwas durch den NetworkManager, aber nicht so viel, als dass sich aktuell der Aufwand lohnt. Ich sehe hier vor allem einen sehr sehr hohen Aufwand dies robust zu bekommen. Auf Managed und Mobile Clients können und sollten wir den NetworkManager zum Default machen.
Bei der Neuinstallation von bertil gestern Abend aufgetreten: Installiert per DHCP, IP erfolgreich bekommen (192.168.0.156). Nach reboot IP aus falschem Netz empfangen (172.16.0.X), also wollte ich die IP statisch eintragen - sobald ich ein ucr set interfaces/eth0/address="192.168.0.156" gesetzt hatte, wurde, nach Einsicht von ucr search interfaces, die Variable automatisch wieder mit der falschen IP überschrieben. interfaces type wurde vorher ebenfalls auf static geändert. Ein manuelles Anpassen der /etc/resolv.conf brachte den gleichen Effekt: Sie wurde direkt wieder mit den alten, falschen Werten überschrieben.
Wir werden den Network-Manager jetzt wieder aus allen Systemrollen bis auf Managed und Mobile Client entfernen und auf den ifplugd wechseln Bei den Clients wird noch geprüft, ob dort der Network Manager weiterhin verwendet werden soll.
(In reply to comment #28) > Bei den Clients wird noch geprüft, ob dort der Network Manager weiterhin > verwendet werden soll. Mit einer kleinen Korrektur in univention-network-manager sind beschriebene Probleme nicht mehr aufgetaucht. Daher wir der NM jetzt beim Mobile und Managed Client weiterhin verwendet.
Bitte durchtesten: * Managed und Mobile Clients. * amd64 und i386 * Updates bei Systemen, die vorher eine dynamische Netzwerkkonfigurationen hatten * Updates bei Systemen, die vorher eine statische Netzwerkkonfigurationen hatten * Neuinstallationen von Systemen mit dynamischen Netzwerken * Neuinstallationen von Systemen mit Netinstaller * Neuinstallationen von Systemen mit statischen Netzwerken
Folgendes Verhalten auf dem Managed Client (i386). * passwd Cache ist nicht aktiviert * bei disc. des Netzwerk werden die methods Variablen nicht aktualisiert * händisches ausführen von /usr/share/univention-managed-clien/check_connection, oder beim Setzen von eth0 auf dchp wird der X Server gestartet, aber ich sehe nur ein schwarzes Bild, Wechsel auf die Konsole nicht mehr möglich
Auch auf einem Mobile Client ist der Passwort Cache nicht aktiviert.
Das trat bei einer Neuinstalltion auf. Scheinbar wurde das check_connection aufgerufen bevor das postinst von univention-(mobile|managed)-client aufgerufen wurde. Dadurch wurden die Defaults definiert ohne das der Cache in den Authentisierungstechniken steht. Die Authentisierung über den Cache wird jetzt im preinst aktiviert.
Ich habe einen frisch installierten Managed Client mit statischem Interface, wenn ich jetzt das Netzwerk in der VM Console wegnehme, wird nach einiger Zeit gdm neu gestartet, bleibt aber scharz, bis man das Netz wieder aktiviert, kann man nichts machen Ich denke es liegt an /usr/share/univention-managed-client/check_connection, das ja pre cron aufgerufen wird. Dieses Skript startet /etc/NetworkManager/dispatcher.d/01ifupdown all down (bzw up), soweit ich sehe, werden dann die Skripte in /etc/network/if-down.d ausgeführt. Die Skripte werden auch bei ifdown eth0 ausgeführt. 1) Sollen die Skripte /etc/network/if-down.d ausgeführt werden, wenn das Interface statisch konfiguriert wurde 2) auch ein sleep 10 (oder sleep 20 oder restart des gdm) in /etc/network/if-down.d/50_gdm bringt nix Wenn ich das Skript /usr/share/univention-managed-client/check_connection von Hand mit ausrufe, gibt es folgende Meldung ... + /etc/NetworkManager/dispatcher.d/01ifupdown all down lockfile creation failed
Ich habe den gdm auf dem managed client jetzt mit der Änderung aus https://bugs.launchpad.net/gdm/+bug/228324 neu gebaut, damit funktioniert es ???
Bitte comment#35 ignorieren. Auch damit startet der GDM nicht richtig.
(In reply to comment #34) > Ich habe einen frisch installierten Managed Client mit statischem Interface, > wenn ich jetzt das Netzwerk in der VM Console wegnehme, wird nach einiger Zeit > gdm neu gestartet, bleibt aber scharz, bis man das Netz wieder aktiviert, kann > man nichts machen Da das ganze auch mit statischen Interfaces passiert ist es scheinbar unabhängig vom NetworkManager. > Ich denke es liegt an /usr/share/univention-managed-client/check_connection, > das ja pre cron aufgerufen wird. Dieses Skript startet > > /etc/NetworkManager/dispatcher.d/01ifupdown all down (bzw up), soweit ich sehe, > werden dann die Skripte in /etc/network/if-down.d ausgeführt. > > Die Skripte werden auch bei ifdown eth0 ausgeführt. > > 1) Sollen die Skripte /etc/network/if-down.d ausgeführt werden, wenn das > Interface statisch konfiguriert wurde Ja, da sonst der GDM bei jeder Anmeldung ewig lange Timeouts abwartet bevor die Sitzung gestartet wird. > 2) auch ein sleep 10 (oder sleep 20 oder restart des gdm) in > /etc/network/if-down.d/50_gdm bringt nix Hm, das hat bei einmal Test ja mal funktioniert. Ganz konstant scheint das Verhalten nicht zu sein. > Wenn ich das Skript /usr/share/univention-managed-client/check_connection von > Hand mit ausrufe, gibt es folgende Meldung > > ... > + /etc/NetworkManager/dispatcher.d/01ifupdown all down > lockfile creation failed Der versucht eine Lock-Datei /tmp/.univention_check_connection anzulegen. Existiert diese noch? gibt es noch laufende check_connection Prozesse?
> > Die Skripte werden auch bei ifdown eth0 ausgeführt. > > > > 1) Sollen die Skripte /etc/network/if-down.d ausgeführt werden, wenn das > > Interface statisch konfiguriert wurde > > Ja, da sonst der GDM bei jeder Anmeldung ewig lange Timeouts abwartet bevor die > Sitzung gestartet wird. OK, bei statischem Interface ist es ja gut, dass die Skripte asugeführt werden, was ist aber bei dhcp, führt dann nicht der NetworkManager die Skripte aus und Cron dann nochmal? > > ... > > + /etc/NetworkManager/dispatcher.d/01ifupdown all down > > lockfile creation failed > > Der versucht eine Lock-Datei /tmp/.univention_check_connection anzulegen. > Existiert diese noch? gibt es noch laufende check_connection Prozesse? ach so, cron startet /usr/share/univention-managed-client/check_connection darin werden per /etc/NetworkManager/dispatcher.d/01ifupdown die Scripte in /etc/network/if-down.d/ ausgerufen, dort gibt es einen link /etc/network/if-down.d/05_auth auf /usr/share/univention-managed-client/check_connection , das dann wohl nochmal gestartet wird, daher die Meldnung
(In reply to comment #38) > > > Die Skripte werden auch bei ifdown eth0 ausgeführt. > > > > > > 1) Sollen die Skripte /etc/network/if-down.d ausgeführt werden, wenn das > > > Interface statisch konfiguriert wurde > > > > Ja, da sonst der GDM bei jeder Anmeldung ewig lange Timeouts abwartet bevor die > > Sitzung gestartet wird. > > OK, bei statischem Interface ist es ja gut, dass die Skripte asugeführt werden, > was ist aber bei dhcp, führt dann nicht der NetworkManager die Skripte aus und > Cron dann nochmal? Der Cron-Job sollte die Skripte nur ausführen, wenn sich etwas geändert hat. > > > + /etc/NetworkManager/dispatcher.d/01ifupdown all down > > > lockfile creation failed > > > > Der versucht eine Lock-Datei /tmp/.univention_check_connection anzulegen. > > Existiert diese noch? gibt es noch laufende check_connection Prozesse? > > ach so, cron startet /usr/share/univention-managed-client/check_connection > darin werden per /etc/NetworkManager/dispatcher.d/01ifupdown die Scripte in > /etc/network/if-down.d/ ausgerufen, dort gibt es einen link > /etc/network/if-down.d/05_auth auf > /usr/share/univention-managed-client/check_connection > , das dann wohl nochmal gestartet wird, daher die Meldnung Genau, daher das Locking Auf meiner VM mit einem DHCP-Interface kann ich das auch gerade noch nicht nachstellen.
Ich kann das auf meiner VM mit einem dynmaisch und einem statischen Interface nicht reproudieren. Vielleicht könnte das nochmal auf Hardware getestet werden.
Ich konnte das Problem jetzt mit einem statischen Interface reproduzieren. Obwohl durch den Cron-Job die gleichen Skripte ausgeführt werden wie bei einem dynamischen Interface hängt der GDM beim Reload. Ich habe jetzt den NetworkManager so konfiguriert, dass der sich auch um die statischen Interfaces kümmert. Meine ersten Tests sahen vielversprechend aus. Ich werde das jetzt noch mit dem Paket was gerade baut weiter testen. Daher den Bug noch einmal wieder auf.
Mobile Client mit DHCP installiert. /etc/network/interfaces sieht OK aus, er bekommt auch eine Adresse. Diesen Rechner hab ich gejoint. Dann hab ich das Cron skript aus /etc/cron.d/univention-mobile-client deaktiviert. Wenn ich jetzt über die VM Console das Netzwerk deaktiviere, passiert nichts. Die Variable für die Authentifizierung stehen weiterhin auf ldap, kerberos, ... . Der GDM wird nicht neu gestartet. Sollte jetzt nicht der NetworkManager die Skript aus /etc/network/if-down.d ausführen? dpkg -l network-manager -> 0.7.1-1.18.200911171
Ich kann die Probleme momentan nicht nachvollziehen. Auch die beobachteten Probleme mit statischen IP-Adressen kann ich nicht reproduzieren. Ich installiere jetzt noch einen neuen Mobile Client und schau mir das dort noch einmal an. Sollte jemand einen Mobile- oder Managed-Client mit Netzproblemen haben, dann bitte bescheid geben.
(In reply to comment #43) > Ich kann die Probleme momentan nicht nachvollziehen. Auch die beobachteten > Probleme mit statischen IP-Adressen kann ich nicht reproduzieren. Ich > installiere jetzt noch einen neuen Mobile Client und schau mir das dort noch > einmal an. Sollte jemand einen Mobile- oder Managed-Client mit Netzproblemen > haben, dann bitte bescheid geben. Das Problem hing evtl. damit zusammen, dass interfaces/handler nicht registriert war. Dadurch wurde die /etc/network/interfaces Datei nicht neu erzeugt als der handler auf network-manager gesetzt wurde. Dadurch war die Konfiguration falsch. Nach einem commit auf die Datei habe ich wieder einen GDM bekommen und das Netz war auch konfiguriert.
An einem neu installierten Mobile Client war das Netz jetzt verfügbar und GDm konnte gestartet werden
Der Kommentar an Bug 16318#c10 weist darauf hin, dass dbus restart im univention-network-manager postinst vermieden werden sollte. http://bugs.debian.org/466013 z.B. weist andererseits darauf hin, dass ein reload notwendig ist, damit die Konfiguration und die neuen policy settings von dbus gelesen werden. Ziel des dbus restart war es, die policy settings einzulesen, daher sollte er in ein reload umgewandelt werden.
(In reply to comment #46) > Ziel des dbus restart war es, die policy settings einzulesen, daher sollte er > in ein reload umgewandelt werden. Das wurde jetzt durch einen reload ersetzt
Reopen: Managed- und Mobile-Client mit statischer IP haben nach join und Neustart nur folgendes in der /etc/resolv.conf stehen: # Generated by NetworkManager options timeout:2 ein ucr commit /etc/resolv.conf schreibt Nameserver in die Datei: # Warning: This file is auto-generated and might be overwritten by # univention-config-registry. # Please edit the following file instead: # Warnung: Diese Datei wurde automatisch generiert und kann durch # univention-config-registry überschrieben werden. # Bitte bearbeiten Sie an Stelle dessen die folgende Datei: # # /etc/univention/templates/files/etc/resolv.conf # domain colors.test nameserver 10.200.12.2 options timeout:2 # ucr search --brief interf interfaces/eth0/address: 10.200.12.6 interfaces/eth0/broadcast: 10.200.12.255 interfaces/eth0/netmask: 255.255.255.0 interfaces/eth0/network: 10.200.12.0 interfaces/handler: networkmanager networkmanager/all_interfaces: yes
Wenn kein Nameserver eingetragen ist werden die per UCR Variablen gesetzten ergänzt. Paket baut
In der Update QA eines Mobile Clients fiel auf, dass durch das Entfernen des resolv.py UCR Moduls die resolv.conf allein aus dem statischen Template erzeugt und somit nur die Daten aus den UCR Variablen einträgt. Wenn man keinen nameserver1 gesetzt hat, sondern "nur" einen Nameserver per DHCP mitgeteilt bekommt, dann bricht das Update mit einem Traceback ab, wenn der Repository Server nicht mehr aufgelöst werden kann.
(In reply to comment #50) > In der Update QA eines Mobile Clients fiel auf, dass durch das Entfernen des > resolv.py UCR Moduls die resolv.conf allein aus dem statischen Template erzeugt > und somit nur die Daten aus den UCR Variablen einträgt. Wenn man keinen > nameserver1 gesetzt hat, sondern "nur" einen Nameserver per DHCP mitgeteilt > bekommt, dann bricht das Update mit einem Traceback ab, wenn der Repository > Server nicht mehr aufgelöst werden kann. Das resolv.py Modul wird wieder mitgebracht und führt bei Verwendung des ifplugd dhclient aus. ucr Paket ist gebaut.
(In reply to comment #51) > Das resolv.py Modul wird wieder mitgebracht und führt bei Verwendung des > ifplugd dhclient aus. ucr Paket ist gebaut. Den Aufruf von dhclient im UCR Modul finde ich ungünstig, da dann ggf. mehrere dhclient-Instanzen laufen. 1x pro Commit auf /etc/resolv.conf und zusätzlich 1x von ifplugd.
(In reply to comment #52) > (In reply to comment #51) > > Das resolv.py Modul wird wieder mitgebracht und führt bei Verwendung des > > ifplugd dhclient aus. ucr Paket ist gebaut. > > Den Aufruf von dhclient im UCR Modul finde ich ungünstig, da dann ggf. mehrere > dhclient-Instanzen laufen. 1x pro Commit auf /etc/resolv.conf und zusätzlich 1x > von ifplugd. Ist das denn ein Problem? Wenn nein, dann sollten wir das zur 2.3-1 schieben.
(In reply to comment #53) > (In reply to comment #52) > > Den Aufruf von dhclient im UCR Modul finde ich ungünstig, da dann ggf. mehrere > > dhclient-Instanzen laufen. 1x pro Commit auf /etc/resolv.conf und zusätzlich > > 1x von ifplugd. > > Ist das denn ein Problem? Wenn nein, dann sollten wir das zur 2.3-1 schieben. Im Test konnte ich keine negativen Effekte von mehreren dhclient-Prozessen entdecken. Daher wurde für diesen Punkt Bug 16652 erstellt.
Verified: * alle aus univention-server gebauten Pakete haben als Depends: univention-ifplugd | univention-network-manager sodass das bei Updates und neu * per univention-installer/scripts/50_packages.sh wird für mobile_client explizit network-manager installiert. * mit ifplugd führt 'ucr set nameserver2=127.0.0.1' dazu, dass dhclient aufgerufen wird. Verbesserung gegenüber per-ucs_2.3 Verhalten: Wenn der DHCP Server keinen Nameserver mitliefert, wird tatsächlich der Wert aus der UCR Variable mit in die resolv.conf eingetragen. * mit NetworkManager werden die UCR nameserver Variablen ebenfalls berücksichtigt, wenn von DHCP Server kein Nameserver vorgegeben wurde. Ein 'ucr set nameserver2=127.0.0.1' führt hier dazu, dass die resolv.conf mit den statischen Werten aus der UCR committet wird. Das ist nicht ganz konsistent, aber soweit akzeptabel. * Changelog ist auch angepasst: \item F<FC>r die Konfiguration von Netzwerk-Interfaces wird jetzt bei der Neuinstallation von Mobile-Clients der NetworkManager verwendet. \ucsBug{8994}
UCS 2.3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".