Date: Fri, 17 Apr 1998 20:15:32 -0700 From: Mike Smith <mike@smith.net.au> To: Studded <Studded@san.rr.com> Cc: hackers@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. Message-ID: <199804180315.UAA00280@antipodes.cdrom.com> In-Reply-To: Your message of "Fri, 17 Apr 1998 15:05:26 PDT." <3537D226.457C3B91@san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Mike Smith wrote: > > > > I recently posted asking for opinions as to the desirability of making > > the ISC DHCP tools part of the base system. The response to this has > > been positive so far, and unless there are subsequent strong objections > > they will be imported contrib-style. > > I would suggest that you push back the import for a little while. Ted > just announced on dhcp-client that he's planning a new release for > probably this weekend. Sounds good to me. > Also, as much as I think that importing dhcp into > the base is a necessary step, I have a concern that it will promptly > become orphaned like (for example) xntpd and top. Please say it won't be > so. :) There are two parts to the maintaining of system components like this; a developer willing to put in the time, and a group of users willing to keep the pressure up. In the case of the DHCP client, for example, I can't keep up with the mailing list, but if someone (like you) does, and pesters me/us every time an update becomes available, things will work out just fine. > > There are three basic approaches we can take to integrating DHCP > > clienthood with FreeBSD: > > > > 1 Nothing. Leave the tools and the manpages there for users that > > might feel brave and want to set it up themselves. This doesn't win > > us much over the port, but results in the least change. > > This would actually be a minus in relation to the port since this > dramatically increases the likelihood that it will be orphaned. Sure. I don't fancy it as an approach, but it's one that exists. > > 2 Offer a simple choice between "traditional" static configuration, and > > "use DHCP" configuration. Users with complex part-static part-DHCP > > configurations can use the DHCP client configuration file to achieve > > ultimate flexibility. This results in the least surprise for > > existing users, but perhaps a slightly more convoluted > > implementation. > > I posted a proposal for some very simple rc.conf and rc.network changes > that would make this almost painless several months ago and was told > that implementing changes like that before xntpd was in the tree > wouldn't be wise. If you're interested in a slightly modified version of > my plan feel free to visit http://home.san.rr.com/freebsd/dhcp.html. The > system as it is now is closer to ready for this change than you might > think. I would be happy to work with you (and whoever else is > interested) on details of the implementation. Thanks - I'll look at this and get back to you. > > 3 Use the DHCP client for everything. This will require a rethunk of > > the way that some configuration information is stored in /etc, in > > order to feed it to the DHCP client. In effect, the DHCP client > > will become the sole point of configuration for IP address, default > > route, nameserver, etc. information. > > This will make things simpler and cleaner, but will also result in a > > break away from the "all information in one place" trend we have > > been trying to cleave to. > > Not necessarily... there are ways to achieve this goal but they all > lean pretty far towards the database model that Jordan et al want for > all of the configuration items and implementing half a solution now will > only make the transition more difficult. My feeling again. But then my sympathies for that approach are well known. > > Another significant issue is that the DHCP client can be used to > > retrieve nameserver details. In order to put this information into use, > > /etc/resolv.conf must be updated, requiring /etc/ to be writable. > > The symlink idea proposed as a solution for this seems like a good > idea. As an alternative, would it hurt overmuch to have the resolver look in /var/dhcp/resolv.conf preferentially? This would mean that no administrative changes were required (making a symlink manually in /etc would be a little ugly), the DHCP-acquired nameserver information would simply overload the local config if it was present. > > As > > well, lease information is normally stored under /var (which is > > normally expected to be writable, but often not as early as the DHCP > > client might be running). > > I've never had a problem with this. Do people NFS mount /var? What > circumstances are you thinking of? Diskless clients, where DHCP is often *extremely* useful. In this case, you want the DHCP client to do it stuff, but not write its configuration out immediately. Rather, it should wait until it gets a signal (or just periodically try to save it, so that when /var arrives, everything "just works"). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804180315.UAA00280>