Re: Embedded dhcpcd options

[David Brownlee <abs%netbsd.org@localhost>]

On 27 November 2013 22:56, Roy Marples <roy%marples.name@localhost> wrote:
>
> Hi List
>
> I've just added support for decoding user defined, embedded and encapsulation 
> option to dhcpcd(8) here:
> http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=commit;h=0fe99f0519d2dc9dbcc098a1dc671c5d164d2ed6
>
> Now, dhcpcd embeds inside itself static constant structures to define DHCP 
> and DHCPv6 options.
> I found that I cannot easily extent this to support embedded or encapsulated 
> options as defined in RFC's, so it's an easy fix to create a small 
> dhcpcd-embedded.conf file and parse this before /etc/dhcpcd.conf.
> dhcpcd-embedded.conf is installed to LIBEXECDIR as it's not meant to be user 
> editable.
> I've attached it to demonstrate how to define options for decoding :)
>
> So before this gets rolled out, does anyone have any feelings about the 
> following?
>
> 1) Move the entire DHCP option setup from embedded structs in the code to 
> dhcpcd-embedded.conf
>    Benefit would be smaller binary and maybe changing the struct to a TAILQ 
> list rather than being doing reallocs per directive.
>    Downside means that this file NEEDS be to installed, currently it's 
> optional.
>    Also, more types would have to be exposed which may not be desirable.
>
> 2) Install dhcpcd-embedded.conf to /etc instead of LIBEXECDIR
>    Benefit would be that it's more user visible as to the decoding rather 
> than having to read RFC's or dhcpcd code.
>    Downside is that the dhcpcd install process won't update it by default as 
> /etc is supposed to be sacrosanct, but we could make an exception here.
>    Also, disributions often have a seperate process to update /etc, removed 
> from just updating dhcpcd or itself. Sometimes the user may not enact this 
> setp and if an up-to-date dhcpcd-embedded.conf isn't installed / updated 
> there stands more chance of breakage.


I like the elegance of defining everything via the same mechanism (1),
As you mention it allows people to more easily potentially mess with
things they should not, but building dhcpcd from source isn't exactly
a stratospheric bar... If I recall correctly the old saying was "Unix
doesn't stop you from doing something stupid, as this would also stop
you from doing something (unexpectedly) clever".

From a size perspective, if the binary plus extra .conf lines is
smaller its a win for install media, otherwise probably not an issue.

For 2) - it may be worth having a conf version in the file in case of
incompatible future changes. It could be a protocol major version plus
a minor. dhcpcd would refuse to run on a major mismatch and just warn
on a minor (which at least specifically alerts the user to an out of
date file).