After quite a few months, I've finally gotten dhcpcd to work fully on Linux (amd64, x86) and FreeBSD (sparc64, x86). The code base is a lot smaller too, and the final compiled binary comes in at 35k on 32-bit arches, although that figure drops to 31k when optimised for size. Still, that makes us smaller that pump, dhclient and the old dhcpcd by quite some way and only 4k bigger than udhcpc. However the size of the udhcpc scripts soon bring it up to 30k, so it's not that much of a difference. Actually if you trim the features that udhcpc doesn't have then dhcpcd now comes a lot lot smaller, making it ideal for embedded devices :)But size isn't everything, it's also what you do that counts.Well, dhcpcd is the only open source DHPC client that handles Classless Static Routes, User Classes and DNS Search Paths by default. dhclient /can/ support them but it requires lots of nasty script hacks!The only plan for dhcpcd now is to fix any bugs (probably some I missed) and add optional dbus support so that it can work with !NetworkManager instead of dhclient.
OK, if you're a zealot and want ALL your state data saved to /var, you can pretty much forget it :evil:Here's the reasons why it's a bad idea for a package like baselayout - /var is not guaranteed to be always available. In fact, we jump through a lot of hoops to work without /usr available too, but we're talking about saving state.Another reason why saving to /var is bad is because I've been toying with the idea of making "rc single" really single user. This means that when the localmount service stops it unmounts all local disks aside from /, and possibly remounting / ro as well. Now, in this state, the user can reasonably do "rc default" and expect everything to spring back to life. Hard to do when your state data on /var isn't there anymore. Also, this is event driven like upstart. In this state the user could insert a pcmcia network card which raises a kernel uevent which triggers hotplug to start net.eth0. net.eth0 depends on localmount for /var, so localmount starts. localmount needs checkfs, so that starts, etc etc.I hear people clamoring for upstart in Gentoo - you have already got its functionality :)There are many other reasons why /var could suddenly drop. So we to store our data somewhere on /. The only guaranteed directories to exist are /dev /bin /etc /lib /sbin. We already have /lib/rcscripts to store things all things baselayout, so /lib/rcscripts/init.d seems like a good choice.So taking that as a given, why not just keep /lib/rcscripts/init.d mounted as tmpfs? It doesn't take that much space (around 200k tops) and for BSD users - well, we loose the allocated space, but no reason why the kernel can't be sensible and move it to swap. This should make everyone happy and remove around 60 lines of code from /sbin/rc which is no bad thing. So if you have an opinion, then please chime in :)
So Abbey and I went to see Saw 3 over the weekend and it was a good movie. Not as good as Saw 1, possibly better than Saw 2. It's the endings that I love - always a good twist. Still that's the point of the movie, the twist at the end. The beauty of Saw 1 was that you didn't expect it which is why no sequel could be better ....Anyway, we have also been busy doing more wedding type stuff and we think we've settled on the "favors". For sure, we'll make then ourselves to save more £££ due to the expensive honeymoon we've booked. We think we've also got the invites themselves sorted - well, just the idea. We're going to try and make them :)So we less than 6 months until I'm a happily married man, things are just going smooth. Where's all this supposed fuss that everyone moans about?
OK, so I run OpenVPN to secure everything. Which is good :)I also run IPv6 just for kicks, which is also good :)I'm starting to love FreeBSD more and more, which is always good :)So what's the bad part? Well, add any any firewall into the above mix (ipfw, pf - ipf didn't compile) and IPv6 connections just hang. After weeks of banging my head, scouring FreeBSD bug reports and firewall setups I was getting nowhere :( Infact I was just about to file a FreeBSD bug report when The_Paya mentioned that mss maybe too high. So lo and behold I experimented and he was right!After trying out many settings, using the OpenVPN setting of tun-mtu 1420 seemed to work the best.There's also this patch for an old beta, but I've not played with that yet.
OK, so yet another bash release borks baselayout and friends :(
But this still probably the nicest release as bash-3.2_p3 mostly works. The big caveat is the =~ semantic has changed. Take this snippet
[[ $(/proc/filesytems)$'\n' =~ " tmpfs"$'\n' ]]
That works fine for bash-3.0 and 3.1 Not so for 3.2! Here's how it's now done
[[ $(/proc/filesytems)$'\n' =~ \ tmpfs$'\n' ]]
Basically, we need to stop using quotes on the RHS when using =~ unless we want to match against the quote exactly. We also need to escape spaces.
As it's totally incompatible for most parts of baselayout, the 1.12 branch has had all the =~ instances removed where it didn't work with either. For the 1.13 branch we've changed to the new semantic and as such, alpha5 will require bash-3.2_p3. If you're using FreeBSD then you'll probably need this little patch for bash too.