[Andrew Pollock] > I'm sorry, but I have to disagree with your assessment of this.
Well, it is important to Debian Edu, as I said in my original email. Sad to see you give it less priority. > I think it's a bit rich to be foisting the requirements of Debian > Edu onto all of Debian's users of the DHCP client. Can you explain how getting the default dhclient setup to query for more information is "foisting the requirements of Debian Edu onto all of Debian's users of the DHCP client". To me it only is giving Debian Edu and others the possibility to use this information, not forcing anyone to use it. > Surely there's a better way to specify a DHCP client configuration > specifically for Debian Edu? I can think of using a configuration > management system like Puppet, or a configuration package that > either replaces the DHCP client's conffile or diverts it or > something. I am all for a better way to change the dhclient configuration file, but none of the ideas you propose seem to provide it. At the moment we replace the file /etc/dhcp3/dhclient.conf using cfengine at install time, which causes upgrade problems and is the background for this report. As conffiles can't be diverted, we have not managed to come up with a better way. Do you have any concrete proposals that will work? Can you rewrite dhclient to accept a different configuration file? Having some .d directory with configuraiton would be nice, allowing Debian Edu to provide only the dhclient.conf extra fragment we need to get dhclient to ask for the extra information (log-servers, smtp-server and wpad-url at the moment). To me, having to have special configuration for packages in Debian Edu in this case is worse for both Debian and Debian Edu. For Debian, which end up without a way to automatically configure the web proxy for clients in an enterprise setup without editing conffiles, and for Debian Edu which have to maintain more configuration. > I'm particularly uncomfortable about the DHCP client automatically > trusting proxy server configuration provided by the DHCP > server. There's no need to give rogue or hostile DHCP servers more > ways to MITM people. Adding the proposed options do not cause the DHCP client to trust the proxy server. It only causes the DHCP client to collect a bit more information from the DHCP server. Using the wpad URL will be entirely up to others, in this case the debian-edu-config package. I agree that it is a security consideration to make, but given that Debian Edu clients already trust the DNS server information provided by DHCP, and uses DNS to locate the web proxy today, it do not make it easier to setup a man in the middle to fetch the wpad URL directly from DHCP. It do on the other hand make sure we can set up everything needing a proxy using the same information source (the wpad file), and this make it easier for large installations to change their proxy settings by updating one file. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
