Re: DHCP server in base

2010-09-26 Thread David DEMELIER
2010/9/25 Marcin Cieslak sa...@saper.info:
 M. Warner Losh i...@bsdimp.com wrote:

: I agree but like Aleksandr said, almost 70% of dhcp code is already in
: base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea
: to keep some parts in the ports tree and move out from the base.

 Yea.  I agree too.  Just because BIND was EOLd in 6 isn't a great
 argument against dhcp server.  Most of the code is there anyway, and
 it isn't evolving as fast as BIND.

 It would be very convenient to have this particular thing in the base,
 and we shouldn't be too dogmatic about never having any new 3rd party
 things in the base.  After all, we just added more compression
 utilities to the base, and nobody said a peep.  This is analogous: we
 have good opportunity to integrate into the system, and users benefit
 from that integration.

 As a road-warrior consultant I really value having things like
 bootpd, tftpd, bootparamd and similar software always there.
 Many times I wished dhcpd was there, too.

 Another typical use - FreeBSD makes a good small network router out
 of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing).

 I am not sure about the whole modularization goal - I think
 the relatively monolythic nature is one of the FreeBSD's merits.

 For example, it's good to have NFSv4, Kerberos and required
 userland daemons packaged in the base. I don't want to have
 those done separately in a modular way (although Heimdal
 we have is older then what their current trunk is).
 We got stuck on connecting Linux boxes via NFSv4 to Solaris
 and BSD because one of the userland modules in Linux was terribly
 out of date and authenticating the user w/Kerberos was not possible.

 As we build a more complex networking landscape with VIMAGE and
 friends I think that the benefits of better integration of dhcpd
 in the base system (rc.d, rc.conf...) may outweigh its costs
 (maintenance, bloat, etc.).

 //Marcin

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


I agree that for some people it will be completely useless, but if we
can disable it in src.conf everyone will be happy. Since FreeBSD is
great for a router it's really fast to make a full working server
without installing anything else.

I agree for the 70% part of dhcp which is already present.

In any case, src.conf(5) is still working and usable, isn't it?

Kind regards,

-- 
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-26 Thread Michel Talon
David DEMELIER said:

 I agree that for some people it will be completely useless, but if we
 can disable it in src.conf everyone will be happy. Since FreeBSD is
 great for a router it's really fast to make a full working server
 without installing anything else.

What is the problem of installing something else? You are probably
ignoring that many people are complaining about the presence of
sendmail, bind, perl  etc. in the base system from ages, indeed X and
perl have been removed, and it is clear that the consensus is to make the
base smaller not bigger. And frankly i have *very* hard time to think
that a DHCP server in the base has any utility. why not maxima for
example? I am interested in formal computation, you are interested in 
routers, another one likes images and would want gimp, and so on.

-- 

Michel TALON

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-25 Thread Darren Pilgrim

M. Warner Losh wrote:
It would be very convenient to have this particular thing in the 
base, and we shouldn't be too dogmatic about never having any new 3rd

 party things in the base.


Please no, don't add optional servers to the base.  I already don't like
sendmail, bind, ntpd and inetd in the base.  These are *optional*
software--not required for the normal operation of the OS.  They aren't
even enabled by default except sendmail.  Adding sendmail_enable=NONE
to /etc/rc.conf is one of the first things I do on all new systems.  I
only barely tolerate openssl in the base because it's needed for
openssh; however, I'd rather both of those be in ports as well.

There's also the issue of updating:

It's very annoying to have to update the OS just to fix a BIND or
OpenSSL vulnerability and, let's be honest, we'll likely never see the
last of those.  Rebooting a production server is non-trivial.  By-hand
partial installworlds on live systems are a disturbing prospect.  If it
was a port, just update the port.  Its far easier justifying updating a
port than modifying the OS on a production server.  The Ports System
makes updating a port so fast and painless I can do many of the
non-user-facing ones without an announced downtime.

It's trivial installing ports and utterly so installing packages.  I'd
love to see us use the awesomeness that is the Ports System to manage
these things.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-25 Thread Marcin Cieslak
 M. Warner Losh i...@bsdimp.com wrote:

: I agree but like Aleksandr said, almost 70% of dhcp code is already in
: base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea
: to keep some parts in the ports tree and move out from the base.

 Yea.  I agree too.  Just because BIND was EOLd in 6 isn't a great
 argument against dhcp server.  Most of the code is there anyway, and
 it isn't evolving as fast as BIND.

 It would be very convenient to have this particular thing in the base,
 and we shouldn't be too dogmatic about never having any new 3rd party
 things in the base.  After all, we just added more compression
 utilities to the base, and nobody said a peep.  This is analogous: we
 have good opportunity to integrate into the system, and users benefit
 from that integration.

As a road-warrior consultant I really value having things like
bootpd, tftpd, bootparamd and similar software always there.
Many times I wished dhcpd was there, too.

Another typical use - FreeBSD makes a good small network router out
of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing).

I am not sure about the whole modularization goal - I think
the relatively monolythic nature is one of the FreeBSD's merits.

For example, it's good to have NFSv4, Kerberos and required
userland daemons packaged in the base. I don't want to have 
those done separately in a modular way (although Heimdal
we have is older then what their current trunk is). 
We got stuck on connecting Linux boxes via NFSv4 to Solaris
and BSD because one of the userland modules in Linux was terribly
out of date and authenticating the user w/Kerberos was not possible. 

As we build a more complex networking landscape with VIMAGE and
friends I think that the benefits of better integration of dhcpd
in the base system (rc.d, rc.conf...) may outweigh its costs 
(maintenance, bloat, etc.).

//Marcin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-25 Thread krad
On 25 September 2010 21:10, Darren Pilgrim free...@bitfreak.org wrote:

 M. Warner Losh wrote:

 It would be very convenient to have this particular thing in the base, and
 we shouldn't be too dogmatic about never having any new 3rd
  party things in the base.


 Please no, don't add optional servers to the base.  I already don't like
 sendmail, bind, ntpd and inetd in the base.  These are *optional*
 software--not required for the normal operation of the OS.  They aren't
 even enabled by default except sendmail.  Adding sendmail_enable=NONE
 to /etc/rc.conf is one of the first things I do on all new systems.  I
 only barely tolerate openssl in the base because it's needed for
 openssh; however, I'd rather both of those be in ports as well.

 There's also the issue of updating:

 It's very annoying to have to update the OS just to fix a BIND or
 OpenSSL vulnerability and, let's be honest, we'll likely never see the
 last of those.  Rebooting a production server is non-trivial.  By-hand
 partial installworlds on live systems are a disturbing prospect.  If it
 was a port, just update the port.  Its far easier justifying updating a
 port than modifying the OS on a production server.  The Ports System
 makes updating a port so fast and painless I can do many of the
 non-user-facing ones without an announced downtime.

 It's trivial installing ports and utterly so installing packages.  I'd
 love to see us use the awesomeness that is the Ports System to manage
 these things.

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



have a look at man src.conf and named_program
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-17 Thread M. Warner Losh
In message: 4c91100c.5060...@freebsd.org
Doug Barton do...@freebsd.org writes:
:  Most of the code is there anyway, and it isn't evolving as fast as
:  BIND.
: 
: That is actually a more rational argument, even if I don't agree with
: it. FWIW, part of the reason that I don't agree with it is that at
: some point, hopefully in the near future, we will want to include the
: DHCPv6 client in the mix somewhere; and when we do the code base is
: not going to be as stable as we have enjoyed so far with the v4
: dhclient.

True, but that still won't change the dynamic that adding a dhcp
server is easy give we have most of one already in the tree.  Adding
v6 support likely will mean a certain amount of code churn, I'll grant
you that.  But the code/api churn that's happening is within a single
program, making it much easier to MFC as necessary to keep up.

:  This is analogous: we
:  have good opportunity to integrate into the system, and users benefit
:  from that integration.
: 
: Given your perspective of wanting more of a complete system in the
: base I can certainly see how you would be supportive of this
: change. My intent was to make the argument in a general way that this
: is the wrong direction to go, and that users would benefit *more* from
: a robust modularized system. The fact that the v4 DHCPd might
: accidentally be a good candidate for including in the base today
: doesn't mean that doing so is the right strategy for the long term.

I take a more nuanced view: we have to evaluate each proposed addition
to the system on its merits.  One of these criteria is long term
viability, but others include how useful is it to the users; how much
demand will there be; will including it make the project look good?;
will not including it make the project look bad?; etc

We'd all like to see a more modular base, but until that nut is
cracked, we have a balancing act to perform.

Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-15 Thread M. Warner Losh
In message: aanlktinkj182=gftdww_0oat6rforjpbxnzmyukce...@mail.gmail.com
David DEMELIER demelier.da...@gmail.com writes:
: 2010/9/11 Doug Barton do...@freebsd.org:
:  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.
: 
: 
: I agree but like Aleksandr said, almost 70% of dhcp code is already in
: base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea
: to keep some parts in the ports tree and move out from the base.

Yea.  I agree too.  Just because BIND was EOLd in 6 isn't a great
argument against dhcp server.  Most of the code is there anyway, and
it isn't evolving as fast as BIND.

It would be very convenient to have this particular thing in the base,
and we shouldn't be too dogmatic about never having any new 3rd party
things in the base.  After all, we just added more compression
utilities to the base, and nobody said a peep.  This is analogous: we
have good opportunity to integrate into the system, and users benefit
from that integration.

Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-15 Thread Doug Barton

On 9/15/2010 7:25 AM, M. Warner Losh wrote:


Yea.  I agree too.  Just because BIND was EOLd in 6 isn't a great
argument against dhcp server.


That rather clearly was not the only element of my argument, and not 
only is it disingenuous for you to indicate that it was, I don't 
appreciate you doing so.



Most of the code is there anyway, and it isn't evolving as fast as BIND.


That is actually a more rational argument, even if I don't agree with 
it. FWIW, part of the reason that I don't agree with it is that at some 
point, hopefully in the near future, we will want to include the DHCPv6 
client in the mix somewhere; and when we do the code base is not going 
to be as stable as we have enjoyed so far with the v4 dhclient.



It would be very convenient to have this particular thing in the base,
and we shouldn't be too dogmatic about never having any new 3rd party
things in the base.  After all, we just added more compression
utilities to the base, and nobody said a peep.


I actually thought that change was rather silly, but it was clear that 
there was so much critical mass in favor of it that there was no point 
in stating a dissenting opinion. As part of the project's leadership you 
should be careful not to mistake silence for agreement, or worse, support.



This is analogous: we
have good opportunity to integrate into the system, and users benefit
from that integration.


Given your perspective of wanting more of a complete system in the base 
I can certainly see how you would be supportive of this change. My 
intent was to make the argument in a general way that this is the wrong 
direction to go, and that users would benefit *more* from a robust 
modularized system. The fact that the v4 DHCPd might accidentally be a 
good candidate for including in the base today doesn't mean that doing 
so is the right strategy for the long term.



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/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-14 Thread Marian Hettwer
On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER
demelier.da...@gmail.com wrote:
 2010/9/13 Gordon Tetlow gor...@tetlows.org:
 On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER demelier.da...@gmail.com
 wrote:

 Perl is a great example, I don't really understand why it's in the
 base, then the port need to rewrite the links into the base hierarchy
 and I think this is bad.

 Perl is not in the base system anymore. It's in the ports system.
 Gordon
 
 Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect !

Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC.
Nothing to do with following -current ;-)

./Marian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-14 Thread David DEMELIER
2010/9/14 Marian Hettwer m...@kernel32.de:
 On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER
 demelier.da...@gmail.com wrote:
 2010/9/13 Gordon Tetlow gor...@tetlows.org:
 On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER demelier.da...@gmail.com
 wrote:

 Perl is a great example, I don't really understand why it's in the
 base, then the port need to rewrite the links into the base hierarchy
 and I think this is bad.

 Perl is not in the base system anymore. It's in the ports system.
 Gordon

 Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect !

 Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC.
 Nothing to do with following -current ;-)

 ./Marian


Oh then I'm confused, why the ports still rewrite links in /usr/bin then ?

-- 
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-14 Thread Kevin Oberman
 Date: Tue, 14 Sep 2010 19:13:58 +0200
 From: David DEMELIER demelier.da...@gmail.com
 Sender: owner-freebsd-curr...@freebsd.org
 
 2010/9/14 Marian Hettwer m...@kernel32.de:
  On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER
  demelier.da...@gmail.com wrote:
  2010/9/13 Gordon Tetlow gor...@tetlows.org:
  On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER 
  demelier.da...@gmail.com
  wrote:
 
  Perl is a great example, I don't really understand why it's in the
  base, then the port need to rewrite the links into the base hierarchy
  and I think this is bad.
 
  Perl is not in the base system anymore. It's in the ports system.
  Gordon
 
  Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect !
 
  Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC.
  Nothing to do with following -current ;-)
 
  ./Marian
 
 
 Oh then I'm confused, why the ports still rewrite links in /usr/bin then ?

This was a way to avoid breaking the huge number of perl scripts that
had: #!/usr/bin/perl as the first line. If perl simply moved to
/usr/local/bin, this would have broken a LOT of stuff people were doing,
so it was decided to put a link in /usr/bin. The port now has an option
to control this, but it is still there by default:
USE_PERL Rewritelinks in /usr/bin on
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-14 Thread David DEMELIER
2010/9/14 Kevin Oberman ober...@es.net:
 Date: Tue, 14 Sep 2010 19:13:58 +0200
 From: David DEMELIER demelier.da...@gmail.com
 Sender: owner-freebsd-curr...@freebsd.org

 2010/9/14 Marian Hettwer m...@kernel32.de:
  On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER
  demelier.da...@gmail.com wrote:
  2010/9/13 Gordon Tetlow gor...@tetlows.org:
  On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER 
  demelier.da...@gmail.com
  wrote:
 
  Perl is a great example, I don't really understand why it's in the
  base, then the port need to rewrite the links into the base hierarchy
  and I think this is bad.
 
  Perl is not in the base system anymore. It's in the ports system.
  Gordon
 
  Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect !
 
  Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC.
  Nothing to do with following -current ;-)
 
  ./Marian
 

 Oh then I'm confused, why the ports still rewrite links in /usr/bin then ?

 This was a way to avoid breaking the huge number of perl scripts that
 had: #!/usr/bin/perl as the first line. If perl simply moved to
 /usr/local/bin, this would have broken a LOT of stuff people were doing,
 so it was decided to put a link in /usr/bin. The port now has an option
 to control this, but it is still there by default:
 USE_PERL Rewritelinks in /usr/bin on
 --
 R. Kevin Oberman, Network Engineer
 Energy Sciences Network (ESnet)
 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
 E-mail: ober...@es.net                  Phone: +1 510 486-8634
 Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


Well I see, thanks !

-- 
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-13 Thread David DEMELIER
2010/9/11 Doug Barton do...@freebsd.org:
 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.


I agree but like Aleksandr said, almost 70% of dhcp code is already in
base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea
to keep some parts in the ports tree and move out from the base.

Perl is a great example, I don't really understand why it's in the
base, then the port need to rewrite the links into the base hierarchy
and I think this is bad.

 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/





-- 
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-13 Thread Gordon Tetlow
On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER
demelier.da...@gmail.comwrote:

 Perl is a great example, I don't really understand why it's in the
 base, then the port need to rewrite the links into the base hierarchy
 and I think this is bad.


Perl is not in the base system anymore. It's in the ports system.

Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-13 Thread David DEMELIER
2010/9/13 Gordon Tetlow gor...@tetlows.org:
 On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER demelier.da...@gmail.com
 wrote:

 Perl is a great example, I don't really understand why it's in the
 base, then the port need to rewrite the links into the base hierarchy
 and I think this is bad.

 Perl is not in the base system anymore. It's in the ports system.
 Gordon

Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect !

-- 
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-11 Thread Aleksandr Rybalko
On Fri, 10 Sep 2010 17:33:22 -0700
Doug Barton do...@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 

-- 

Re: DHCP server in base

2010-09-11 Thread Bernd Walter
On Fri, Sep 10, 2010 at 10:33:11PM -0700, Kevin Oberman wrote:
  Date: Fri, 10 Sep 2010 17:33:22 -0700
  From: Doug Barton do...@freebsd.org
  Sender: owner-freebsd-curr...@freebsd.org
  
  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.
 
 It is not. I routinely use hostapd for access for my iPod. I use
 static addressing and don't run dhcpd.

With IPv6 you can additionally use stateles autoconfiguration.
The requirement for autoconfiguration with DHCP is a problem of IPv4,
which won't have a long future for mainstream purspose anymore.
Nevertheless there must be a decision about base and not-base and this
point will always be questionable to some.
I'm also not very strict about bind - it is handy to have dig available,
but at the same time it is handy to have whois available, but the
whois in base isn't good enough anymore for most cases.
A DHCP client however can be required for initial network configuration
to retrieve further packages.
dig and co can be handy to debug initial network problems, but there
are other tools in base for those problems.
But to repeat a point which was already made:
Someone who can configure a DHCP server really shouldn't have problems
to install a package - installing packages or ports is so basic for
an operationg system that this is likely one of the first things to
learn.
Additionally there are ready made systems based on FreeBSD for special
purpose, which probably come with the required tools.

   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.

DHCP servers don't have to live on routers and there are many reasons
to have them installed somewhere else.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Alex Dupre
David DEMELIER ha scritto:
 I was surprised to see that there is no DHCP server in base, obviously
 it's not difficult to fetch the net/isc-dhcp31-server package but for
 people that would like to setup a new server on FreeBSD quickly they
 will take some time to learn how packages framework works or ports and
 it can be annoying.

If you (people) don't know how to use ports/packages probably you
shouldn't use FreeBSD. And I hardly think that installing a port
requires more knowledge than correctly configuring a DHCP server. Then,
why 3.1 and not 4.1? Why not bundling also apache? etc., etc.

-- 
Alex Dupre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Matthew Jacob
 I think not. You are given the opportunity to install prebuilt 
packages at install time, and with a modest amount of effort can install 
prebuilt packages afterwards.


IMO, such as it is, there should be *less* in the base system than there 
currently is and more in ports.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Scott Robbins
On Fri, Sep 10, 2010 at 05:29:40PM +0200, Alex Dupre wrote:

 David DEMELIER ha scritto:
  I was surprised to see that there is no DHCP server in base, obviously
  it's not difficult to fetch the net/isc-dhcp31-server package but for
  people that would like to setup a new server on FreeBSD quickly they
  will take some time to learn how packages framework works or ports and
  it can be annoying.
 

As someone who changed from FreeBSD to CentOS, due to a job change, let
me say that one of the things I greatly prefer about FreeBSD is that
they *don't* make very many assumptions about what the user needs,
whereas far too many Linux distributions do the opposite, not only
throwing in too much, but often making it difficult to work around what
they've decided you need.  :)

So, I would respectfully disagree.  It's easy enough to add a dhcp
server if desired, and this way, you don't annoy all the people who
DON'T want it. 
 
Sincerely,

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Willow: Why couldn't he be possessed by a puppy, or some
ducks?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread David DEMELIER
2010/9/10 Matthew Jacob m...@feral.com:
  I think not. You are given the opportunity to install prebuilt packages at
 install time, and with a modest amount of effort can install prebuilt
 packages afterwards.

 IMO, such as it is, there should be *less* in the base system than there
 currently is and more in ports.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


In this case there are some parts in base/ that could live in ports/
instead of the base directory such as hostapd(8), maybe nobody want to
make a usable wireless access point?

And what about bind too? A lot of user do not needs it, by the way
there is already src.conf(5) to enable or disable modules, then a
WITHOUT_DHCPD would be useful.

Cheers.

-- 
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Doug Barton

On 9/10/2010 9:54 AM, David DEMELIER wrote:

2010/9/10 Matthew Jacobm...@feral.com:

  I think not. You are given the opportunity to install prebuilt packages at
install time, and with a modest amount of effort can install prebuilt
packages afterwards.

IMO, such as it is, there should be *less* in the base system than there
currently is and more in ports.


I agree with Matt on this one, although that shouldn't be a surprise 
since I'm on record saying it often. :)



In this case there are some parts in base/ that could live in ports/
instead of the base directory such as hostapd(8), maybe nobody want to
make a usable wireless access point?


Unfortunately arguing to include something new in the base because 
something else that you don't agree with is already there is not a valid 
method. The bar is a lot higher for adding things than keeping things 
(for better or worse).



And what about bind too?


As I've said many times, I'm ready to have it out when there is 
consensus to do so. The usual discussion goes like this:


1. Get BIND out of the base!
2. If we remove it, the command line tools (dig, host, nslookup) go with it.
3. Oh, well, we like those, so keep them, but get rid of the rest!
4. BIND is library based, so 90% of the work to make the command line 
tools is building the libs, after which building the server and its 
accessories is trivial work.

5. Oh, well, then make knobs to disable the server!
6. That's already done.
7. Oh, well, never mind then *mumble mumble*

However, all that is likely to change at some point in the future (as 
in, years from now) when BIND 10 becomes the only and/or most viable 
option since it requires a lot of stuff that we are unlikely to ever 
import into the base (like boost, python, etc.). So there is hope for 
you anti-BIND folks yet! :)



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/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Freddie Cash
On Fri, Sep 10, 2010 at 11:36 AM, Doug Barton do...@freebsd.org wrote:
 On 9/10/2010 9:54 AM, David DEMELIER wrote:
 And what about bind too?

 As I've said many times, I'm ready to have it out when there is consensus to
 do so. The usual discussion goes like this:

 1. Get BIND out of the base!
 2. If we remove it, the command line tools (dig, host, nslookup) go with it.
 3. Oh, well, we like those, so keep them, but get rid of the rest!
 4. BIND is library based, so 90% of the work to make the command line tools
 is building the libs, after which building the server and its accessories is
 trivial work.
 5. Oh, well, then make knobs to disable the server!
 6. That's already done.
 7. Oh, well, never mind then *mumble mumble*

Possibly off-topic for this particular thread, but the above reminded
me of what DragonflyBSD just went through, as they removed BIND from
their base install:  importing a smaller codeset that provides the
same functionality as the BIND tools[1].

However, that may or may not be a net gain, as then you need someone
to maintain those non-BIND tools.

But, if one looks at the Perl situation when it was removed from base,
couldn't one remove BIND, but have the package listed as mandatory
install, the way Perl was for awhile (or maybe still is)?

This is also something that DragonflyBSD does, using pkgsrc packages
for things they want installed by default, but that they don't want to
maintain as part of their source tree.

Of course, then you have to train everyone to use /usr/local/etc/named
instead of /etc/named.  :)  (But, it's that what major version updates
and .0 releases are for?)

[1] http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Julien Laffaye
On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton do...@freebsd.org wrote:
 As I've said many times, I'm ready to have it out when there is consensus to
 do so. The usual discussion goes like this:

 1. Get BIND out of the base!
 2. If we remove it, the command line tools (dig, host, nslookup) go with it.

DragonflyBSD chose to remove BIND and to use drill as a replacement [1].
Don't know if it meet our requirements, though.

[1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Aleksandr Rybalko
On Fri, 10 Sep 2010 21:06:45 +0200
Julien Laffaye kime...@gmail.com wrote:

 On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton do...@freebsd.org wrote:
  As I've said many times, I'm ready to have it out when there is consensus to
  do so. The usual discussion goes like this:
 
  1. Get BIND out of the base!
  2. If we remove it, the command line tools (dig, host, nslookup) go with it.
 
 DragonflyBSD chose to remove BIND and to use drill as a replacement [1].
 Don't know if it meet our requirements, though.
 
 [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Hi,

another argument about hostapd :)
if have access point we must have way to assign IP for AP clients.

Last spring I made firmware based on FreeBSD for router with only 4MB NOR flash 
(D-Link DIR-320).
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.

So:
1. We already have code for libdhcp in base.
2. We already use isc-dhcp as dhcpclient.
3. We already build small-size embedded routers firmware with DHCP server.
4. We have hostap and other router/AP functionality.

So why not include dhcpd in base now?

-- 
Aleksandr Rybalko r...@ddteam.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread jhell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/10/2010 14:36, Doug Barton wrote:
 On 9/10/2010 9:54 AM, David DEMELIER wrote:
 2010/9/10 Matthew Jacobm...@feral.com:
 I think not. You are given the opportunity to install prebuilt 
 packages at install time, and with a modest amount of effort can
 install prebuilt packages afterwards.
 
 IMO, such as it is, there should be *less* in the base system
 than there currently is and more in ports.
 
 I agree with Matt on this one, although that shouldn't be a surprise 
 since I'm on record saying it often. :)
 
 In this case there are some parts in base/ that could live in
 ports/ instead of the base directory such as hostapd(8), maybe
 nobody want to make a usable wireless access point?
 
 Unfortunately arguing to include something new in the base because 
 something else that you don't agree with is already there is not a
 valid method. The bar is a lot higher for adding things than keeping
 things (for better or worse).
 
 And what about bind too?
 
 As I've said many times, I'm ready to have it out when there is 
 consensus to do so. The usual discussion goes like this:
 
 1. Get BIND out of the base! 2. If we remove it, the command line
 tools (dig, host, nslookup) go with it. 3. Oh, well, we like those,
 so keep them, but get rid of the rest! 4. BIND is library based, so
 90% of the work to make the command line tools is building the libs,
 after which building the server and its accessories is trivial work. 
 5. Oh, well, then make knobs to disable the server! 6. That's already
 done. 7. Oh, well, never mind then *mumble mumble*
 
 However, all that is likely to change at some point in the future
 (as in, years from now) when BIND 10 becomes the only and/or most
 viable option since it requires a lot of stuff that we are unlikely
 to ever import into the base (like boost, python, etc.). So there is
 hope for you anti-BIND folks yet! :)
 
 
 Doug
 

This is where I say: I believe it would be the correct route to move
toward a base package system for things like BIND DHCP... the common
stuff that people would like to see in base but not really a
conceptional sound idea.

My theory behind this goes like this: Make a base package for
bind-server, bind-utils, bind-tools or whatever you want to call them
with the --package-root defined as /. Do this for ports/lang etc... type
of stuff and ship them with the install CD/DVD's. If the user wants the
base port then there is no harm done and they can trivially add it. This
would leave room for other base system options to include too without
having to permanently move things in and out of base because supporting
them in-tree does not make sense or other reasons.

Specifically I like this type of idea due to not needing to have a
compiler (GCC) installed at all times. It could simply be added and
removed from the base system by package or installed from ports and
allow the end user to choose what they want when they want it. Stuff
like GCC, BIND, DHCP Servers  other languages for this make sense. Why
Not ?


Regards,

PS: I'll coin this idea (base-board-ports)

.02

- -- 

 jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMirvXAAoJEJBXh4mJ2FR+SocH/3pK3s8L9bOb12a6IhhrKSdI
mJZeFSyMdx3n4olIkd1VhYA2O6Qsl6hUBASitpbiJ3/9Vz/BAcCW2JE+Ub0rDwZT
SG7vk0aaCtjFEBk5xdLM52iDKIGs5uNaKxYQMot0KX4pi/Obm7Pf8AGmQpc8RnSd
PBbUX5T0kzbStPE59tQA9gW2UcTxKtx2up+Pzns8mYvUEb+dgEuwPo2rE10aZKuK
lnfoZ2LclmQg1KmvzZATrRUxFjHdJQqD4PgPFGEAAWVDlzAFnwQhBufYtyT71lqZ
0T+XW5WQUo6WjjtweyV6uhfPeJUuk+DqkmDGw8oJIRfqYOm3yetSKiOoAgmJ9Qo=
=brrR
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread jhell
On 09/10/2010 19:14, jhell wrote:
 On 09/10/2010 14:36, Doug Barton wrote:
 On 9/10/2010 9:54 AM, David DEMELIER wrote:
 2010/9/10 Matthew Jacobm...@feral.com:
 I think not. You are given the opportunity to install prebuilt 
 packages at install time, and with a modest amount of effort can
 install prebuilt packages afterwards.

 IMO, such as it is, there should be *less* in the base system
 than there currently is and more in ports.
 
 I agree with Matt on this one, although that shouldn't be a surprise 
 since I'm on record saying it often. :)
 
 In this case there are some parts in base/ that could live in
 ports/ instead of the base directory such as hostapd(8), maybe
 nobody want to make a usable wireless access point?
 
 Unfortunately arguing to include something new in the base because 
 something else that you don't agree with is already there is not a
 valid method. The bar is a lot higher for adding things than keeping
 things (for better or worse).
 
 And what about bind too?
 
 As I've said many times, I'm ready to have it out when there is 
 consensus to do so. The usual discussion goes like this:
 
 1. Get BIND out of the base! 2. If we remove it, the command line
 tools (dig, host, nslookup) go with it. 3. Oh, well, we like those,
 so keep them, but get rid of the rest! 4. BIND is library based, so
 90% of the work to make the command line tools is building the libs,
 after which building the server and its accessories is trivial work. 
 5. Oh, well, then make knobs to disable the server! 6. That's already
 done. 7. Oh, well, never mind then *mumble mumble*
 
 However, all that is likely to change at some point in the future
 (as in, years from now) when BIND 10 becomes the only and/or most
 viable option since it requires a lot of stuff that we are unlikely
 to ever import into the base (like boost, python, etc.). So there is
 hope for you anti-BIND folks yet! :)
 
 
 Doug
 
 
 This is where I say: I believe it would be the correct route to move
 toward a base package system for things like BIND DHCP... the common
 stuff that people would like to see in base but not really a
 conceptional sound idea.
 
 My theory behind this goes like this: Make a base package for
 bind-server, bind-utils, bind-tools or whatever you want to call them
 with the --package-root defined as /. Do this for ports/lang etc... type
 of stuff and ship them with the install CD/DVD's. If the user wants the
 base port then there is no harm done and they can trivially add it. This
 would leave room for other base system options to include too without
 having to permanently move things in and out of base because supporting
 them in-tree does not make sense or other reasons.
 
 Specifically I like this type of idea due to not needing to have a
 compiler (GCC) installed at all times. It could simply be added and
 removed from the base system by package or installed from ports and
 allow the end user to choose what they want when they want it. Stuff
 like GCC, BIND, DHCP Servers  other languages for this make sense. Why
 Not ?
 
 
 Regards,
 
 PS: I'll coin this idea (base-board-ports)
 
 .02
 

This is also a conversation for another thread. So please do not let it
distract you.

-- 

 jhell,v
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Doug Barton

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/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: DHCP server in base

2010-09-10 Thread Kevin Oberman
 Date: Fri, 10 Sep 2010 17:33:22 -0700
 From: Doug Barton do...@freebsd.org
 Sender: owner-freebsd-curr...@freebsd.org
 
 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.

It is not. I routinely use hostapd for access for my iPod. I use
static addressing and don't run dhcpd.

  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.

Again, I tend to not make much use of DHCP except when traveling. If I
am on a known network at work or home, I static address everything
(including the iPod and my laptop). I don't need (or run) dhcpd for my
use.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org