From owner-freebsd-hackers Wed Apr 15 20:39:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA16216 for freebsd-hackers-outgoing; Wed, 15 Apr 1998 20:39:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles2.castles.com [208.214.165.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA16045 for ; Wed, 15 Apr 1998 20:37:56 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id SAA00388 for ; Wed, 15 Apr 1998 18:51:57 -0700 (PDT) Message-Id: <199804160151.SAA00388@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG Subject: Discussion : Using DHCP to obtain configuration. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Apr 1998 18:51:57 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. There are, however, a number of issues related to being a good DHCP client which impact on the FreeBSD startup scripts. These issues can be resolved in a number of ways, with varying degrees of perturbation and complexity. Some discussion of the possible approaches would seem to me to be a good idea. Avid readers of this list may recall a discussion some time back which proposed an event-based approach to handling interface configuration. I never came up with a suitable model for this, however the ISC DHCP client achieves almost exactly that with its dhclient-script. 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. 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. 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. 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. 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). So, comments? Suggestions? Examples from real-world applications? -- \\ 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