~alpine/devel

4 4

[alpine-devel] Default DHCP server on Alpine Linux v3.3

Christie Taylor
Details
Message ID
<trinity-10d83e02-3adf-4847-89d0-f11c9475eab6-1448110595040@3capp-mailcom-bs10>
Sender timestamp
1448110595
DKIM signature
missing
Download raw message
ISC DHCP is maintained by a team that focuses on DHCP and has been tested over and over on giant networks and is pretty solid.

BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be (in my opinion) coupled with BusyBox. It looks like they try to do everything on what should be just the coreutilities. Bite off more than can chew.

I think the more Alpine distances from BusyBox the better. A single binary doing all these things, from coreutilities to device manager and dhcp server?! Crazy. Programs should be separate. For coreutilities I recommend sbase and for the dhcp server, I think ISC DHCP is the best out there.

What do you think about ISC DHCP? Maybe that v3.3 is coming soon, this could be another great change to come with it.

https://www.isc.org/downloads/dhcp/


Thanks.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Alan Pillay
Details
Message ID
<CAO6-m02wfcpbOPTY8qS19eiUjcpe664fCU8FvKqexffqpFVy1w@mail.gmail.com>
In-Reply-To
<5650743F.60108@skarnet.org> (view parent)
Sender timestamp
1448115815
DKIM signature
missing
Download raw message
I have no knowledge on DHCP servers, so I won't comment on that.
But I find the argument against Busybox that it tried to "bite off
more than they can chew", as you put it a compelling one.
Recently suckless developers explained why existing core-utils and
linux-utils aren't properly done and why they are working on their own
solutions. They specifically mention Busybox and what (from their
point of view) is wrong with it. Check it out, it's an awesome watch:
http://dl.sta.li/slcon/2015/slcon-2015-01-frign-suckless_core.webm
If you are just interested on Busybox/Toybox/Etc problems and the
solution (sbase), it's on 11:08.
And they do talk about their sdhcp project on the video too, but I
didn't look much into it.

Best wishes.

On Sat, Nov 21, 2015 at 11:40 AM, Laurent Bercot <ska-devel@skarnet.org> wrote:
> On 21/11/2015 13:56, Christie Taylor wrote:
>>
>> ISC DHCP is maintained by a team that focuses on DHCP and has been
>> tested over and over on giant networks and is pretty solid.
>
>
>  Yeah, yeah. And ISC BIND is maintained by a team that focuses on DNS
> and has been tested over and over on giant networks, and is still a
> complete piece of crap.
>  And ISC NTP is maintained by a team that focuses on NTP and has been
> tested over and over on giant networks and is a horrible mess.
>  etc. etc.
>
>  ISC has produced exactly one good thing, and it's the ISC license.
> Every piece of software they pump out is a poorly engineered
> monolithic piece of spaghetti code, broken both by design *and* by the
> amount of bugs still present in it after countless releases.
>
>  udhcpc/udhcpd, on the other hand, do exactly what they are supposed
> to do, and nothing more: DHCP client and DHCP server. It's easier to
> understand, easier to maintain, and the people who maintain it actually
> know their heads from their asses code-wise and engineering-wise.
> Don't fall for the sirens of marketing - udhcp is by far the better
> product.
>
>
>> BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be
>> (in my opinion) coupled with BusyBox.
>
>
>  udhcp actually started as a separate project, and was merged into
> busybox for convenience. Whether it's a good thing or a bad thing is
> a political question; a lot of embedded engineers will swear that it's
> a good thing.
>
>
>> It looks like they try to do everything on what should be just the
>> coreutilities. Bite off more than can chew.
>
>
>  It's a political question, and a good one; I suggest you take it to the
> busybox mailing-list. I also tend to think that busybox has overstepped
> its initial goal and is now trying to integrate too many utilities.
> However, it does not mean that it's a bad project. Technically, the
> busybox code is very good, often miles above the projects it reimplements;
> and that's the most important thing.
>
>
>> I think the more Alpine distances from BusyBox the better. A single
>> binary doing all these things, from coreutilities to device manager
>> and dhcp server?! Crazy. Programs should be separate.
>
>
>  You don't have to use a single binary for all this. You can, if you
> so desire, compile a binary named "mdev", a binary named "udhcpc", a
> binary named "cp", and so on; the fact all those binaries are part of
> the Busybox project should be pretty much invisible to you. Having
> everything as a single binary is a choice; historically, that choice
> made perfect sense, and when you're trying to use as few resources as
> possible, it still makes sense today.
>
>  You can agree or disagree with the way Busybox is organized. I'm not
> a fan of the "everything in a single binary" approach, nor of the Kbuild
> approach. But the fact remains that Busybox works, is pretty small, and
> is very maintainable. If you discover a bug in udhcpc and you report it,
> several people (some of them among the Alpine maintainers) can usually
> understand what it's about very quickly, and get a fix out in 24 hours,
> probably much less. I'm not sure you'd get so quick a reaction time with
> ISC dhcp.
>
>  You recommend utilities from the suckless project. That's another
> valid approach, and suckless utilities are usually good. However,
> "I don't like that Busybox is one project encompassing tons of
> different utilities" is not enough of a reason to switch - at least,
> not without research: what would be the benefits of switching from busybox
> to suckless?
>  * quality of code-wise (probably a wash)
>  * maintainability-wise (probably a wash - separate projects doesn't
> automatically
> mean that the code is more maintainable or that the bug-fixing cycle is
> shorter)
>  * resource-wise (probably a loss - having one binary is good for something)
>
>  But please, no ISC software as the default. I'm all for having ISC DHCP
> packaged for people who want it (and as long as I'm not the package
> maintainer),
> but making it the default would be a major regression.
>
> --
>  Laurent
>
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Laurent Bercot
Details
Message ID
<5650743F.60108@skarnet.org>
In-Reply-To
<trinity-10d83e02-3adf-4847-89d0-f11c9475eab6-1448110595040@3capp-mailcom-bs10> (view parent)
Sender timestamp
1448113215
DKIM signature
missing
Download raw message
On 21/11/2015 13:56, Christie Taylor wrote:
> ISC DHCP is maintained by a team that focuses on DHCP and has been
> tested over and over on giant networks and is pretty solid.

  Yeah, yeah. And ISC BIND is maintained by a team that focuses on DNS
and has been tested over and over on giant networks, and is still a
complete piece of crap.
  And ISC NTP is maintained by a team that focuses on NTP and has been
tested over and over on giant networks and is a horrible mess.
  etc. etc.

  ISC has produced exactly one good thing, and it's the ISC license.
Every piece of software they pump out is a poorly engineered
monolithic piece of spaghetti code, broken both by design *and* by the
amount of bugs still present in it after countless releases.

  udhcpc/udhcpd, on the other hand, do exactly what they are supposed
to do, and nothing more: DHCP client and DHCP server. It's easier to
understand, easier to maintain, and the people who maintain it actually
know their heads from their asses code-wise and engineering-wise.
Don't fall for the sirens of marketing - udhcp is by far the better
product.


> BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be
> (in my opinion) coupled with BusyBox.

  udhcp actually started as a separate project, and was merged into
busybox for convenience. Whether it's a good thing or a bad thing is
a political question; a lot of embedded engineers will swear that it's
a good thing.


> It looks like they try to do everything on what should be just the
> coreutilities. Bite off more than can chew.

  It's a political question, and a good one; I suggest you take it to the
busybox mailing-list. I also tend to think that busybox has overstepped
its initial goal and is now trying to integrate too many utilities.
However, it does not mean that it's a bad project. Technically, the
busybox code is very good, often miles above the projects it reimplements;
and that's the most important thing.


> I think the more Alpine distances from BusyBox the better. A single
> binary doing all these things, from coreutilities to device manager
> and dhcp server?! Crazy. Programs should be separate.

  You don't have to use a single binary for all this. You can, if you
so desire, compile a binary named "mdev", a binary named "udhcpc", a
binary named "cp", and so on; the fact all those binaries are part of
the Busybox project should be pretty much invisible to you. Having
everything as a single binary is a choice; historically, that choice
made perfect sense, and when you're trying to use as few resources as
possible, it still makes sense today.

  You can agree or disagree with the way Busybox is organized. I'm not
a fan of the "everything in a single binary" approach, nor of the Kbuild
approach. But the fact remains that Busybox works, is pretty small, and
is very maintainable. If you discover a bug in udhcpc and you report it,
several people (some of them among the Alpine maintainers) can usually
understand what it's about very quickly, and get a fix out in 24 hours,
probably much less. I'm not sure you'd get so quick a reaction time with
ISC dhcp.

  You recommend utilities from the suckless project. That's another
valid approach, and suckless utilities are usually good. However,
"I don't like that Busybox is one project encompassing tons of
different utilities" is not enough of a reason to switch - at least,
not without research: what would be the benefits of switching from busybox to suckless?
  * quality of code-wise (probably a wash)
  * maintainability-wise (probably a wash - separate projects doesn't automatically
mean that the code is more maintainable or that the bug-fixing cycle is shorter)
  * resource-wise (probably a loss - having one binary is good for something)

  But please, no ISC software as the default. I'm all for having ISC DHCP
packaged for people who want it (and as long as I'm not the package maintainer),
but making it the default would be a major regression.

-- 
  Laurent


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham
Details
Message ID
<20151122034615.GA8248@newbook>
In-Reply-To
<trinity-10d83e02-3adf-4847-89d0-f11c9475eab6-1448110595040@3capp-mailcom-bs10> (view parent)
Sender timestamp
1448163976
DKIM signature
missing
Download raw message
On Sat, Nov 21, 2015 at 01:56:35PM +0100, Christie Taylor wrote:
> ISC DHCP is maintained by a team that focuses on DHCP and has been tested over and over on giant networks and is pretty solid.
> 
> BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be (in
> my opinion) coupled with BusyBox. It looks like they try to do everything
> on what should be just the coreutilities. Bite off more than can chew.

Booting a system takes more than coreutils.
It takes init, a shell, coreutils, linux-utils, some networking programs...

> What do you think about ISC DHCP? Maybe that v3.3 is coming soon, this could be another great change to come with it.
> 
> https://www.isc.org/downloads/dhcp/

ISC dhcp is probably some of the most reliable code from ISC, but that
isn't saying much.
I always found dhclient to hang shutdown on my Debian Squeeze laptop, due
to it persistently trying to release the lease after the wireless
interface went down (and retrying repeatedly...).


> I think the more Alpine distances from BusyBox the better. A single
> binary doing all these things, from coreutilities to device manager
> and dhcp server?! Crazy. Programs should be separate. For coreutilities
> I recommend sbase and for the dhcp server, I think ISC DHCP is the best
> out there.

Try morpheus, then.
http://morpheus.2f30.org/
Other than using the suckless dhcp client, it sounds more like what you
want.


It seems you fundamentally reject the concept of Busybox.
Alpine was built around exploiting it.

But if you're actually curious about what the justification for a
multi-call binary like Busybox is, here are some.
- shared code:
Almost every program out there has a standard routine for parsing arguments.
A lot of programs need to read files and convert them into numbers.
A lot of programs need to write a buffer in full.
There are pretty standard formats for writing errors...
In summary, the bulk of most small *nix programs have a pattern that
could be factored out into shared code.
- total binary size:
Code can be shared a lot of ways, including static and shared libraries
as well as multicall binaries.
Static libraries and compile-time tricks with #include only share it at
the source level.
If you use shared libraries, they share the same implementation.
But every binary that you have has a standard ELF header, taking up a bit
of space.
You can only avoid this by sharing the header, which requires a single
binary.
(Shared libraries have their own headers, so using them is sharing code
at the expense of increasing the number of headers.)
- simple, atomic upgrades:
Frequently, one program will rely on a specific version of another.
With Busybox, you can just drop one new binary in, and you don't
need to worry about whether (for example) your new ifup requires a newer
version of ip, or if it uses ifconfig...
And if the new binary is properly copied, you don't need to
worry about what happens when an upgrade gets interrupted by a reboot.
- easily portable binary:
Besides not depending on external programs that might not be on every
system, it's easier to just copy a single binary over.


Now, I will say that Busybox does have some tools that perhaps shouldn't
be there.
For example:
-pscan: you don't need a port scanner for most uses
-dnsd: while a DNS server can be useful for small network devices that
often use Busybox, this one is essentially useless without dnsmasq or
similar tools, which make it redundant.
-fbsplash: a timed PPM display on a framebuffer doesn't need to happen
in Busybox; you'll need another file anyhow, and PPM more than makes up
for any savings in space...


Thanks,
Isaac


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Chris Spillane
Details
Message ID
<CAKv362vJzPbq6Au+b29PmtDBj+VuXc_PdkTi2q+dmkgwmR_GXg@mail.gmail.com>
In-Reply-To
<trinity-10d83e02-3adf-4847-89d0-f11c9475eab6-1448110595040@3capp-mailcom-bs10> (view parent)
Sender timestamp
1448274243
DKIM signature
missing
Download raw message
Hello Christie,

you don't have to use Busybox's DHCP server if you don't want to.  There is
already a package for ISC DHCP that you are free to use:
https://pkgs.alpinelinux.org/package/main/x86_64/dhcp

Thanks,

Chris

On 21 November 2015 at 12:56, Christie Taylor <ctaylorm@gmx.com> wrote:

> ISC DHCP is maintained by a team that focuses on DHCP and has been tested
> over and over on giant networks and is pretty solid.
>
> BusyBox DHCP (udhcp) is just another BusyBox tool that shouldn't be (in my
> opinion) coupled with BusyBox. It looks like they try to do everything on
> what should be just the coreutilities. Bite off more than can chew.
>
> I think the more Alpine distances from BusyBox the better. A single binary
> doing all these things, from coreutilities to device manager and dhcp
> server?! Crazy. Programs should be separate. For coreutilities I recommend
> sbase and for the dhcp server, I think ISC DHCP is the best out there.
>
> What do you think about ISC DHCP? Maybe that v3.3 is coming soon, this
> could be another great change to come with it.
>
> https://www.isc.org/downloads/dhcp/
>
>
> Thanks.
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
>


-- 
Chris Spillane