On Thu, 27 Feb 2014 20:39:18 +0100 Jouke Witteveen <j.witteveen@gmail.com> wrote:
On Thu, Feb 27, 2014 at 7:20 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Thu, 27 Feb 2014 13:03:27 -0500 Dave Reisner <d@falconindy.com> wrote:
On Thu, Feb 27, 2014 at 12:56:02PM -0500, Leonid Isaev wrote:
On Thu, 27 Feb 2014 14:25:15 +0100 Jouke Witteveen <j.witteveen@gmail.com> wrote:
Support for additional DHCP clients is now easy to add.
Just a quick question: are there any plans to use networkd as a DHCP backend? Yes, it is config-file-driven, but one can probably generate the .network files in /run on the fly...
This sounds like pointless masturbation. Just use networkd directly.
That's what I originally thought, and (in a nutshell) this is what I am currently using.
However, networkd config is based on an interface name, not a profile. Hence there are special cases when e.g. 2 wireless networks use different settings (dynamic/static IP, different DNS, etc.). In these scenarios one needs wpa_actiond. As long as the correct profile is selected, one can make use of networkd instead of dhcpcd.
Contrary to networkd, netctl is profile based. This makes netctl useful in changing environments.
If networkd exposes its dhcp client, this patch makes it easy to add support for it to netctl.
There are no cli options, only config files. These will need to be generated based on a specific profile. So, the whole situation is similar to the way netctl-auto handles wpa-configsection.
Even better, if networkd exposes a lot of its functionality, netctl could potentially drop the dependency on iproute2 (not that there is a problem with iproute2).
Yes, static things like bridge, bond, and vlan for which netctl profiles are essentially identical to .net{dev,work} files. I think that the only advantage of netctl over networkd in this case is the ability to specify dependencies (via Before= and After=) between the respective units.
There are other dhcp clients (such as udhcp) for which support can already be implemented easily after this patch is applied.
Regards, - Jouke
Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D