So dhcpcd has supported a shared IP address for a long time. It did this by removing the address from the non preferrred interface and then adding it to the preferred interface.
Easy!
But this came with some issues:
- There is a window where the IP address doesn't exist, and the kernel may wipe out the subnet route at that point also.
- DHCP renews didn't come through to the right interface.
- Some kernels didn't like the address moving interfaces.
Still, to the best of my knowledge, no other product has this feature and for the most part, it did work well allowing almost seamless switching of wired -> wireless and back again with both using the same IP address. But that wasn't good enough - I was challenged to do better!
So I took up the bat and cooked up this changeset to change the behaviour to this:
- Each applicable interface will have the shared ip address.
- Whenever the address is added, the most preferred address will be ARP announced.
And lo - IT WORKS!!! The changeover when plugging/removing the wired interface is 100% seamless for me. ssh, ping, etc get zero interuption. Of course, YMMV ;)
But there are some costs:
- Thanks to ARP, only the primary interface will receive DHCP unicast messages for other interfaces.
As such we need to re-direct them to the correct interface by examiningxidandchaddr.
This means we have to relax the BPF filters to allow more through. - Kernels supporting RFC5227 will double ARP announce the address.
- NetBSD-8 kernels needed some love to get it to work and there's still an issue with it not working when an address is deleted from the interface.
Only the last bullet is really important, which is mainly why the changeset hasn't hit the master branch yet. But that should be fixed soon. The other points can be fixed as and when.
I rarely talk about work here. But in this case I will because although it's unrelated entirely to my Open Source projects it's actually very enjoyable for a change because we have the change to use some cutting edge tech. Like any large and old product there are crusty bits - some of ours are so crusty they are implemented in Visual Basic 6. So Management have give us the green light to replace a large chunk of that and now that we're part of a bigger business (the joy's of being bought by a large company) we have a mandate to use relevant tech. So I'm learning all about ASP.NET Core and Entity Framework Core. We'll be creating MicroServices talking to an API Gateway, each in a Docker Container. We'll mandate that each project has to have no compile warnings and uses StyleCopy Analyzers. Also we must have unit tests across the board. Each checkin will trigger a static analysis by Sonar Qube. This will be a full Continuous Integration Pipeline.
This is a massive change from the way we've worked before and it excites me! The bad news is that I am spending some of my hobby time on this because it's fun! But I should be getting back onto dhcpcd / NetBSD related stuff soon once the initial prototypes are in place and the new tech feeling wears off.
I've been trying to run an IPv6 tunnel without much success - it's far to laggy to use for real work.
So I've turned that off, and I just noticed I'm now getting an IPv6 Router Advertisement across my Super Hub3 in modem mode.
I've gotten a default route AND a online prefix option to 2a02:8800:f000:2120::/64 (but sadly, no auto config flag).
This prefix is owned by Virgin Media.
So, I can ping the router but nothing else as I don't have a public IPv6 IP address. No address via RA, no reply from my DHCPv6 solicitations - which is odd as the router says I can get a managed address and other information. Maybe they have yet to turn that part on? Please, turn it on soon Virgin!
It's been a while in the making, but dhcpcd-7.0.0-beta1 is finally here! I have been using this a lot on all supported platforms bar Solaris and it's been very trouble free, so hopefully not many changes (if any? famous last words!) before a RC and final release.
Summary of changes since dhcpcd-6.11.5:
- source file locations reworked: dhcpcd source is in src dhcpcd hooks are in hooks compat is in compat
- README split into README.md and BUILDING.md
- internal routing is now protocol agnostic
- avoid using
__packedand use compile time asserts instead - addresses some alignment issues
- disable some ARP code on kernels which support RFC5227
- BSD IPv6 kernel settings are now updated to reflect dhcpcd config
- custom logger has been removed, syslog handles everything
as such, the
--logfileoption has been removed as well. If you need better/earlier logging, get a better syslogger! - distinfo and signed distinfo files are now available alongside release taraballs from this point onwards
- default DBDIR has changed from
/var/dbto/var/db/dhcpcd /etc/dhcpcd.duidmoves toDBDIR/duid/etc/dhcpcd.secretmoves toDBDIR/secret- lease file names have dhcpcd removed from them as they are now inside a directory of the same name
- fixed issues with reject routes not working on some platforms
- improved nl80211 support on Linux for working out the SSID
- no longer request NTP by default in dhcpcd.conf
- fix detecting IPv6 DAD on OpenBSD
- remove custom Solaris DLPI filtering in favour of BPF (note there seems to be a kernel issue where the DHCP fd receives ARP's as well, the only side effect is a noisy syslog)
- BPF filtering vastly improved so dhcpcd only wake up on ARP or DHCP packets destined for it
- support for MUD URL (draft-ietf-opsawg-mud-05)
- if the kernel isn't doing DAD, don't insist on waiting for it to actually do it
- fix a potential crash where the DHCP or ARP states could be freed before the packet processing loop naturally breaks
- removed gateway and nogateway options (these can be controlled by the nooption directive which works for more than just gateways)
- removed ipv6ra_own and ipv6ra_own_default options (these can be controled by the ipv6rs/noipv6rs directive)
- fix a memory leak on systems where posix_spawnattr_init allocates memory by calling posix_spawnattr_destroy afterwards
- fix a crash receiving SIGUSR1
I've not done everything I've wanted to, but I feel that many issues have now been addressed and on the whole dhcpcd is in a very good state right now.
Let me know of any issues you find!
After waving a fond farewell to Fossil I give a hearty hello to Phabricator!
The Good
Phabricator is written in PHP which means I don't have to install Yet Another Framework. I use quite a few things that depend on PHP on this site already, such as Grav and RoundCube. So of course, it allows me to self host. Or you can rent a Phabricator VPS @ Phacility.
The sign up process (to my Phabricator instance, not somewhere else) is very straight-forward, allowing email/password with ReCaptha or use a OAuth2 provider such as Google. So this is very socially acceptable and should be secure from spambots.
The core work is based around the ease of code auditing and review of patches. There is even a pastebin so users can upload config files and logs for analysis. Doing all this in a mailing list over the years results in things being here, there and everywhere .... and then expiring. Having it all centralised means nothing is lost. But more importantly, it's much easier to look at and work with, so this is a massive quality of life improvement.
Tickets (or tasks in Phabricator) very user friendly, showing a collapsable history with full links to related objects such as commits, reviews, logs, etc. Infact the linking is extremely easy, one can reference some more of the popular objects by using a single letter follows by the id. Such as T1. Tickets can be related to one or more Projects and in turn Projects can display Tasks on a KanBan Board.
Phabricator can host your code in your SCM of choice for you and defaults to not allowing destructive changesets by default which saves me from messing around with custom hooks. This allows the same feature as Fossil's immutable history on the server - you can do what you like to your own clone still.
It's fast! No, it's not as fast as Fossil, but it's still more than fast enough especially when you consider the extra toys you get - syntax highlighting, desktop notifications (on supported browsers, which is most recent ones), user icons, in-depth tooltips. It's certainly faster than other solutions I've looked at recently and bar Fossil, probably the fastest.
You get a chat room (does require a NodeJS server on the host for automatic updates though it seems) and a wiki. I still use IRC on FreeNode, but the advantage here is that this is web based and persistent so you don't loose anything if you get disconnected. Still, unsure how useful either be as I don't recall users editing any publically editable wiki pages I've had over the years - are my man pages really that good? Heh.
The Bad
Phabricator is written in PHP. Now I did say that was a good thing earlier, but it's a double edged sword. PHP does have a bad reputation for both security and language structure. I would argue that this is no different from how C is today. This is also bad, because my site ran on PHP-7.0 and that was soooo much faster than earlier versions it was silly. But Phabricator didn't support PHP-7 until PHP-7.1 in early Feb this year. Something to think about for long term support, but this equally applies to other languages, especially the Python-2 vs Python-3 issue as my box has two Python versions due mainly to certbot needing Python-2.7
Phabricator requires MySQL (I installed MariaDB, the fork from MySql). I was very happy with PostgreSQL but my box does not have the resources to run both. Pretty much all other software I use allows the choice of DB, so this actually took me by surprise. And just like the PHP reaction others have, I was concerned by using MySQL, but as I'm not really into being a DBA I'm quite happy with MySQL so far.
The linking is really bad for DHCP, because we always talk about T1 and T2 as timers. This is important, because my main product is of course dhcpcd.
In Phabricator T1 and T2 are shorthand to link to Task 1 and Task 2.
You can fix this by stopping Phabricator from linking via a matchig regex, but I quite like the ease of use and solved the problem via changing the AUTO_INCREMENT value in some tables from 1 to 101. This reduces the potential collision with other things, such as Z1 and allows the same workflow. Upstream rejected my change and even went as far as to remove me posting my fix if anyone else has the same issue claiming this would make support hard. As it turns out, something with my change isn't quite right - either Phabricator or MySQL resets the AUTO_INCREMENT value. I don't know which one, or what action I did or if it's a general Garbage Collection going on. This could be why they didn't like the change, but heh ho most of the important tables now have values in at 101 and higher so it shouldn't be a problem anymore.
The Continuous Integration support is limiting, but it is there. Apparently you can at least call out to Jenkins or BuildBot.
Because Phabricator is based on and developed in a DevOps fashion, there is practically no support for managed releases or milestones. This isn't a problem for me as such, but I would like a feature to track important things that went into a release better.
The Ugly
Phabricator is NOT ugly. It's quite visually appealing. However, it is quite possibly the most complex installation I've ever done as it uses many databases and as many configuration options as sysctl on a good BSD. This wasn't helped by running on NetBSD -current and a gcc built PHP with Phabricator just didn't work and I spent a long time working out why. My fix was to build everthing with clang which required a lot of personal effort from me at the time due to the recent UEFI booting support breaking the build and a the new clang-4 compiler not working with the NetBSD build knobs I was using. On the plus side, the Phabricator docmentation is good and about 95% of the issues I had were easily searchable on StackOverflow or the (mostly) friendly Phabricator community helped me out in their chat channel - which oddly enough is also a Phabricator application.
Phabricator workflow with more than one dev, or the best way of submitting patches, is to use the Arcanist tool. They admit it's not great and things should be manageable directly through the SCM. We'll see how that progresses. In the meantime, posting patches to the Differential application is quite easy and allows easy patch review.
I had to stop using Fossil because Fossil is more than just a SCM - it strives to be a complete one stop solution. Obviously that won't work for the desire to use Phabricator for all the good reasons, so I needed to pick a SCM to use. Luckily Phabricator quite a few - GIT, Mercurial and SVN.
But what about the source code control?
It's importance cannot be understated - the code is everything, the history of the code is everything. This has been known since the dawn of time. At this point though, the SCM just becomes a tool in the box, just like sed.
Eh what?
Every SCM solution out there has pretty much the same set of basic features you need - atomic checkins (ok, CVS lacks this), changesets, branching, tagging. That's all you pretty much need at a basic level - the rest of the features are predominently driven by workflow.
Tools exist to export data from one to the other, and tools are being created to allow a more transparent bridge again making the choice of SCM even less important than it was before. The only real issue is the importance of meta data that has no place-holder in the other SCM you want to use. A good example of this would git the Author vs Commiter git attribute on the commit.
Then, you need to understand that the SCM is only for developers. End users don't care a hoot about it - what they do care about is an easy to use system which handles the lifetime of their issue where dicussion, patches, logs, reviews and audits can happen. Hopefully they can even get a fixed build at the end. This is basically part of Application Lifecycle Management.