Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
- To: firstname.lastname@example.org
- Subject: Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
- From: Bjørn Mork <email@example.com>
- Date: Sat, 01 Sep 2012 11:04:41 +0200
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <CAOVenEqgMO76fz-cCrPNC0rmi5hDCy7TkR6qs+h0SsKNXMR8jg@mail.gmail.com> (Serge's message of "Fri, 31 Aug 2012 21:28:11 +0300")
- References: <email@example.com> <firstname.lastname@example.org> <20120820000453.2ac64f9c@ileemo> <email@example.com> <20120824104411.4ff17b1a@ileemo> <20120830201911.GC14077@grep.be> <CAOVenEqgMO76fz-cCrPNC0rmi5hDCy7TkR6qs+h0SsKNXMR8jg@mail.gmail.com>
Serge <firstname.lastname@example.org> writes:
> 2012/8/30 Wouter Verhelst wrote:
>>> How do you suppose it's possible to undo arbitrary network
>>> configuration done by arbitrary set of tools when there's no central
>>> place to hold such information (and can't possibly be)?
>> Actually, the kernel holds that information. Any tool can just query the
>> kernel for information, and decide what to do with what's returned.
> Not sure. Will it work for user-space configuration too? I.e. `ifdown`
> may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
> to detect such cases automatically?
If you start dhclient or wpa_supplicant on ifup, then you naturally need
to query and deconfigure those tools on ifdown too. There is a perfect
"up" use rtnetlink => "down" queries/deconfigures rtnetlink
"up" use wpa_supplicant => "down" queries/deconfigures wpa_supplicant
"up" use dhclient => "down" queries/deconfigures dhclient
"up" use pppd => "down" queries/deconfigures pppd
etc. Layered combinations of the above is of course common and must be
But I fail to see the point of this discussion. Post patches for NM
and/or ifupdown implementing the features you'd like to see. No need
for all the theoretical mumbo-jumbo, implying that someone else should
do the job.