DHCP server in base
ray at ddteam.net
Sat Sep 11 13:06:34 UTC 2010
On Fri, 10 Sep 2010 17:33:22 -0700
Doug Barton <dougb at FreeBSD.org> wrote:
> On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote:
> > Hi,
> > another argument about hostapd :) if have access point we must have
> > way to assign IP for AP clients.
> To start with, your assumption is wrong. DHCPd is not *actually* a
> requirement, although I admit that practically it is.
> > Last spring I made firmware based on FreeBSD for router with only 4MB
> > NOR flash (D-Link DIR-320).
> In this category (micro-miniaturization) you're already in the
> "significant customization needed" area, which means that general
> arguments about "the base" don't apply.
> > Since this device is router I must be
> > able to serve DHCP. And current implementation of dhcpclient, that we
> > have, is same isc-dhcp, and I replace system dhcpclient with ports
> > one+dhcpd but with small patch that put basic dhcp utils onto
> > libdhcp.so.
> Your argument is creative and well thought out, but I personally don't
> find it persuasive. Counter arguments that come immediately to mind are:
> 1. The DHCP server is not going to benefit any but a small minority of
> FreeBSD users.
> 2. The software is already available in the ports tree, and adding a
> port/package of it really is not an overwhelming burden.
> More generally, the main reason I want to keep more stuff out of the
> base, and remove some of the stuff that's in there now, is that it makes
> maintenance difficult across FreeBSD branches. We have a general policy
> that if we have a major version N of something in a release branch that
> we don't upgrade that major version without a really good reason to
> avoid POLA surprises for our users. Once again using BIND as an example,
> this has led to a really old and past-EOL version of BIND in FreeBSD 6
> which I've only gotten away with because anyone doing serious DNS work
> nowadays has to upgrade to at least 9.6 anyway. But it's an ugly
> situation, and I don't want to repeat it.
> The problems get worse and/or more complex with the more 3rd party stuff
> you start including in the base. In part because of the product
> lifecycle issues that are similar to BIND's, but also due to the
> possibility of licensing issues (such as with gcc and/or other GPL
> software) and other more esoteric factors.
> Even with home-grown stuff like our pkg_* tools we have problems because
> when we want to introduce new features (or deprecate old ones) there is
> currently a _minimum_ 3-year cycle we have to follow in order to make
> sure that the new feature is/is not available on all supported versions
> of FreeBSD. That's the main motivation behind my continuing to repeat
> the suggestion to move those tools specifically into the ports tree so
> that we can better support innovation in our ports/packages system.
> In my view what we've needed to do for a long time now is to seriously
> strip down the notion of what "the base" should be to those items that
> are needed to work together for a specific API/ABI/AKI release, and move
> everything else into the ports tree. (Obviously there would be some
> exemptions made for really basic/vital stuff like ls, etc.) We can do
> this in a way that finds a middle ground between the linux model where
> literally everything is a package and the traditional BSD model of
> providing a "complete system," which is hardly ever true since I've
> never been involved with any FreeBSD system administration where there
> were absolutely no ports/packages installed at all.
> Such a system could also be streamlined by creating a ports virtual
> category (something like "system") the packages for which could be
> included in the install media as long as we are judicious about what
> goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc.
> could all be in that category, and all we'd have to do to make that work
> is to very slightly expand the list of questions that sysinstall already
> So this is a much longer version of my previous response which hopefully
> gives you more background about why it's a bad idea to add *any* more
> 3rd party stuff to the base.
> ... and that's just a little bit of history repeating.
> -- Propellerheads
> Improve the effectiveness of your Internet presence with
> a domain name makeover! http://SupersetSolutions.com/
I fully agree with a small exception:
-rwxr-xr-x 1 ray wheel 109296 Sep 11 15:53 dhclient
-rwxr-xr-x 1 ray wheel 65316 Jun 4 12:33 dhclient
-rwxr-xr-x 1 ray wheel 74768 Jun 4 12:33 dhcpd
-rwxr-xr-x 1 ray wheel 12624 Jun 4 12:33 dhcrelay
-rwxr-xr-x 1 ray wheel 128752 Jun 4 12:33 libdhcp.so
3 tools basically use same code (I move this code in libdhcp)
Now in base already most of this code (Thought this is 70-80%%), why not pick up the remaining 20-30%% that add two useful tools.
Maybe better way is writing BSD licensed client/server/relay?
Aleksandr Rybalko <ray at ddteam.net>
More information about the freebsd-current