And hopefully the last!
dhcpcd.sh is now looking slick and minimal.
ntp, nis and hostname lookup have been moved into example hook scripts.
dhcpcd.conf is now installed by default to request everything dhcpcd.sh needs, and ntp-servers also.
classless_static_routes="188.8.131.52/8 184.108.40.206/16" is now exported to the script.
dhcpcd.sh and dhcpcd.conf now have man pages.
The last thing todo is decide on the following Do we want per interface conigs in dhcpcd.conf? If so provide an example. We currently trim leading and trailing whitespace in dhcpcd.conf. Should we provide a complex mechanism to allow spaces at the start/end of values? If the hostname is an FQDN should we transmit it as such by default?
Answers on a postcard to the usual address :)
Now /etc/dhcpcd.sh is very compatible with dhclient-script! That's the good news :)The bad is that I've totally broken compatibility with older versions of dhcpcd for people that used the scripting part. Most dhcpcd users didn't, as dhcpcd was never that flexable when it came to the script bit. Oh well. We maybe able to provide a compat shim before the final released version though :)EDIT: OK, so we now have a compat shim, but we don't install it by default.
OK, it's not really much more scriptable ;)Basically the dhcpcd binary now only configures the interface and routes - everything else is configured by /etc/dhcpcd.shYes, this means dhcpcd will finally install a script! This makes it easier for the end user to change, as scripting in UNIX is common place, whereas hacking C code not so. The script does everything dhcpcd did, bar looking up the hostname in DNS (hopefully add this back soon), so in essence we've lost nothing but gained more flexability.dhcpcd is still commandline compatible, and users shouldn't notice much difference. However, the defaults may change! Probably to something more minimal - the default probably won't be to update nis/ntp configuration.
OK, no-one likes big code drops. But I've just dropped a large one into dhcpcd git. Here's the commit message
Normally I hate massive code drops, but heh. The code has been drastically re-arranged. Instead of populating a custom structure while parsing dhcp messages, we now pluck what we need right out of the message itself. We have custom functions and a lookup table to make this really easy. This makes us more like dhclient and udhcpc, and will enable us to easily add (and remove!) more dhcp options without having to actually change the code (much). We now store the real dhcp message we got in /var/db/dhcpcd-$iface.lease, the mtime of the file being used as when we got the lease. This file is read in when re-using an old lease instead of parsing the .info file. The benefit of all of this means that we're actually ~15k smaller when compiled with the same features. This has been tested for quite some time, and I'm pretty sure most bugs with the 3.2 branch have been fixed whilst making this. Right now, we are 99% command line compatible with the 3.2 branch.
That's pretty much it :) I've made this now, knowing that it will change very soon. Basically we're going to add knobs such that the default config will just do the basics - configure interface, routes and DNS. This satisfies NetBSD minimalistic requirements (more on this). Then the extra knobs will configure things like NTP, NIS, MTU and the hostname automagically like dhcpcd does at present. Don't panic though - the command line options to turn those off aren't going away either!
After this is done, we'll then add an interface to pull any DHCP option via our new generic interface, maybe something like so `dhcpcd -o LOGSERVERS,99`` Which will pull 2 options, one named which dhcpcd knows about, and the other numeric which dhcpcd doesn't. When dhcpcd doesn't know about it, you'll get the raw data as a hex string I would imagine.
This should make dhcpcd a lot more flexable :) As it's very small, and already feature rich I've put it forward to the NetBSD tech-net mailing list to fullfill a tiny dhcp client to replace the bloated dhclient from ISC. It's not being done as a SoC project (I don't feel that I qualify as dhcpcd was already written really) and it's not a done deal that it will be used in NetBSD, but I am hopeful :)