DragonFlyBSD

Matthias Schmidt wrote:

I like the priv. separation, etc. but I seem to recall having some
problems with openbsd's DHCP w/r/t config file syntax or parsing at some
point - am using their ports (ISC) version of the server on my openbsd
boxes - cant recall if this isolated to the server or global and I never
reported it there - will try and dig a little deeper & post here ..

personally, that's my only objection, if it bears fruit.. not sure what
everyone else thinks w/r/t maintinance, etc.

aha.. though I nuked that particular workspace (doh!) -
enough remains in the notes to see that the problem was that dhcpd's
dhcpd.conf parser had diverged and that the older version in openbsd did
not like things like

host mybox.199technologies.org {

...

}

as anything passing e.g. isdigit() following a '.' was assumed to be an
IP address .. aka "199technologies.org" confused it..

ISC's parser has been enlightened and can handle this now.

This doesn't seem to affect dhclient type statements since the only
'block's are based on interface names and not host-or-IP strings..

so my particular objection is moot ..

though as I recall, some options are different w/r/t support for
'dynamic dns' - which has improved / changed in v3 (over openbsd's code).

I guess it's the usual tradeoff between security & features..

my ideal preference would be to have the nifty Open features (security)
merged into the ISC client/server release (advanced dhcpitude) and
reimported cleanly as a single unit.. but hey.. I guess I'm an idealist

I defer ..

- Chris

:Hi,
:
:now the release is over, so here is one of the items I had in my submit
:queue: the import of the OpenBSD dhclient.
:
:It is a clean rewrite (in some parts) of the ISC dhclient and contains
:nice features like privilege separation. IIRC Hasso also discovered an
:issue with our dhclient, but I can't remember what is was :) I have the
:client running on a number of machines for some months and experienced
:no problems.
:
:To build the OpenBSD dhclient you need a recent kernel (sys/net/bpf.c,
:rev 1.43) and you need to rebuild world and kernel. To install the
:client perform the following steps:
:
:# cd /usr/src/sbin
:# fetch http://leaf.dragonflybsd.org/~matthias/sbin_dhclient.tgz
:# mv dhclient dhclient.isc
:# tar xfz sbin_dhclient.tgz
:# cd dhclient
:# make && make install
:
:dhclient will complain about a missing _dhcp user but will fallback to
:nobody. If we're going to import the dhclient I'll add the appropriate
:user.
:
:Regards
:
: matthias

I think you should bring it into our tree but under a different name so
    people can mess with it without wiping the current dhclient.  That
    way much wider testing can occur.   Maybe call it 'ndhclient' for
    the moment?

Ultimately if we decide to scrap the current dhclient we can rename
    ndhclient to dhclient.  For now we want flexibility to ease testing.

-Matt

I don't think that it's necessary. At least basic functionality is already
tested by several people including me and it's not something new - the
code is in use for several years in both OpenBSD and FreeBSD. The work to
modify /etc to work with several DHCP clients isn't just worth of it.

I agree with Hasso here. The client runs flawlessly. If we encounter
some bugs during testing we can fix them on-the-fly. If we keep both
clients in parallel most people will use the old one (maybe without even
knowing) and we do not get wider testing.

Regards

Matthias

:I agree with Hasso here. The client runs flawlessly. If we encounter
:some bugs during testing we can fix them on-the-fly. If we keep both
:clients in parallel most people will use the old one (maybe without even
:knowing) and we do not get wider testing.
:
:Regards
:
: Matthias

Ok then, go ahead and replace it in HEAD.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

http://leaf.dragonflybsd.org/mailarchive/commits/2008-08/msg00221.html