DHCP server in base

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 
> asks.
> 
> 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.
> 
> 
> Doug
> 
> -- 
> 
> 	... 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/
> 

Hi,

I fully agree with a small exception:
Base dhclient
-rwxr-xr-x  1 ray  wheel  109296 Sep 11 15:53 dhclient

Modified isc-dhcp
-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?

Thanks 

-- 
Aleksandr Rybalko <ray at ddteam.net>