According to Roy's comments here [1], it sounds like we should drop the dhcpcd module from the network scripts and have everyone run dhcpcd as a standalone daemon. He says it listens to uevents and handles adding/removing addresses to/from hotplugged intrfaces correctly. It seems like this would be a better approach than what we are currently doing by tying dhcpcd to the interfaces in the network scripts. What are the objections to doing this? [1] https://bugs.gentoo.org/show_bug.cgi?id=186156#c19
I want to lodge an objection to this. I don't mind dhcpcd running (indeed I seen the benefits to having it persistent), but I don't want it to start doing things to a hotplugged interface just because the interface came into existence.
Does it mean that the IP configuration will now happen in two different config files? Also, similar question to comment 1, is managing an interface with dhcpcd opt-in or opt-out?
FYI using a laptop with wicd .. where wicd manages when dhcpcd runs is also to be considered wicd does not work properly when dhcpcd runs as daemon in my experience .. dhcpcd should be used as necessary .. it's useless with static ip's ;)
(In reply to comment #3) > wicd does not work properly when dhcpcd runs as daemon in my experience .. I don't know how wicd works, but I think it runs as a daemon itself and manages the interfaces. In that situation, you would not want dhcpcd to run as a daemon. > > dhcpcd should be used as necessary .. it's useless with static ip's ;) dhcpcd would not touch an interface that has a static ip configured for it.
(In reply to comment #1) > I want to lodge an objection to this. > > I don't mind dhcpcd running (indeed I seen the benefits to having it > persistent), but I don't want it to start doing things to a hotplugged > interface just because the interface came into existence. Why not? Did you plug in the interface to look pretty or be useful?
(In reply to comment #3) > FYI using a laptop with wicd .. where wicd manages when dhcpcd runs is also > to be considered > > wicd does not work properly when dhcpcd runs as daemon in my experience .. dhcpcd-ui (or dhcpcd-gtk as only that works) works in conjunction with dhcpcd-dbus and wpa_supplicant as a ligher alternative to wicd. The main issue with wicd is that it treats dhcpcd as dhcpcd-1 where no link detection was in place. Even with dhcpcd as a daemon, wicd should stil work, however dhcpcd will return really fast which may confuse wicd. I dont' use wicd so that's purely speculative.
(In reply to comment #0) > According to Roy's comments here [1], it sounds like we should drop the > dhcpcd module from the network scripts and have everyone run dhcpcd as a > standalone daemon. He says it listens to uevents and handles > adding/removing addresses to/from hotplugged intrfaces correctly. It > seems like this would be a better approach than what we are currently > doing by tying dhcpcd to the interfaces in the network scripts. > > What are the objections to doing this? > > [1] https://bugs.gentoo.org/show_bug.cgi?id=186156#c19 Oddly enough I myself will lodge an objection :) Taking the view that net.* will still exist then there is no reason to remove the dhcpcd module. It does work. Taking the view that the future is the network script (server) and/or dhcpcd or equivlanent (hello netmworkmanager) (workstation) then by all means remove the whole net.* scripts and modules. I think this is a knee-jerk ticket to your [1] as dhcpcd handles hotplugged interfaces very well and solves the original problem, although not has originally intended those years ago. Inspite of this, dhcpcd remains (im my skewed rose tinted view) the premire network configuration tool and as such should not be removed as a module from the net.* logic. My whole argument in [1] is that relying on creating init scripts based on hotplugged events is flawed and is better handled by something else. Like say dhcpcd.
I am closing this due to the concerns that were brought up.
