Anything in the 2.0.0 branch from r774+ now needs to be tested and the checklist will be tracked on the GoogleCode page. If, after two weeks, no issues are reported, an “rc1” source package will be published, and if that goes for another two weeks without issues, 2.0.0 will be considered stable and Debian packages and RPMs will be prepared.
At this point, no new features will be added until the system is stable (but please submit ideas to the issue-tracker anyway). Any non-bugfix commits will be things to prepare for the Debian/RPM packages or minor formatting tweaks.
beta-8 is now live, with the following compelling reasons to upgrade:
qtag support for the broadcast-bit situation
Support for “extra” columns from your database to loadDHCPPacket()
Intuitive data-type conversion for setOption() and getOption() for those of you who’d rather pass strings and ints than lists of bytes
While not in the release itself, documentation is now about 5% complete, and with the templates defined, it should ramp up quickly, so closing in on rc1
This release needs more testing than any that have come before, but it’s also likely to be less stable than beta-8, because it includes a complete refactoring of DHCPPacket and some other cross-code-reaching changes. It’s almost safe to use beta-8 in controlled production contexts, but beta-9 is only for those brave and willing to tell me what’s broken.
Of extreme importance to those of you who’ve been testing the 2.0.0-beta series is that this WILL break your loadDHCPPacket() function, if you’ve defined one: definition is now supplied, rather than subnet, serial, and client_ip. To deal with this, replace those three fields (they’re sequential) with definition and access the values as definition.subnet, definition.serial, definition.ip.
So it’s been a while, and I don’t remember why there was no post announcing beta-7, but beta-8 is now live, sporting the following new features:
Support for clients that cannot handle broadcast OFFERs, which are few, but can be found in embedded systems; in issue 15’s history, this was identified as a problem with the broadcast-bit
Persistent and local-file-instead-of-memory caching options
Support for arbitrary config-file locations, via --config or the STATICDHCPD_CONF_PATH environment variable
The broadcast-bit feature owes a lot to Ken Mitchell, for providing feedback and extensive testing throughout the process. Thanks to corecode#dragonflybsd@efnet, too, for helping to clarify BSD networking philosophy and enable selection of a fallback cross-platform solution for L2 packet-injection.
There’s also Debian-packaging infrastructure in the repository, because that’s coming once past the RC phase. Right now, the focus is on the documentation rewrite, which should be all that remains. Feature-requests are still welcome, but try to hold off on them if you want a stable release sooner than later.
Cooper Lee identified an issue in which non-existent MACs would lead to an error when their definition, which was None, was asked for an ip attribute. This should no longer happen and went unnoticed by me ever since 2.0.0-beta-1 because I’d been using the dynamism module in my test environment, which masked the problem by always returning a full definition. I now have multiple testing servers to avoid another issue like this.
This is a minor update, addressing a circular reference discovered by Vladimir Shencov, in which importing from staticdhcpdlib.databases during the config phase (the recommended method of defining custom databases) would prevent the server from starting. Imports should now come from staticdhcpdlib.databases.generic.
If you are using the dynamism module, you’ll need to make that change near the top of the file. Nothing else needs to be modified, though.
beta-4 only half-addressed the issue; beta-5 should deal with it properly. Sorry about that.
And beta-5 missed another reference-point. beta-7, using a fix devised by Vladimir, should have it dealt with for real. For really real.
This should be the last time I modify the codebase in any significant way. I wanted to clean up libpydhcpserver and that’s now done, so please grab a copy of the most recent release, test it, and let me know about any issues.
I’ll try to work through a little bit of the documentation updates each day and if I get through everything with no new problems being reported, I’ll consider it stable.
I still need to revise all of the comments/inline documentation before I’ll be ready to call it a release-candidate, but I don’t anticipate adding any features or making any significant code-changes before that.
Head to GoogleCode and grab a copy. Play with it and report any issues.
In the meantime, here’s what the stats module provides:
For now, though, have another screenshot. This one shows something cool and powered by scapy, which will be used if it’s available on your system.
Getting close now, just stats stuff left. Well, that and rewriting the comments as reST and making sure the wiki is up to date, but that should only take a day, which puts the release on track for end-of-this-week.
Have another screenshot, this one showing off user-code-injected web-interface elements. The code used to do this is identical to what you’ll find in the documentation of dynamism.py, which was reworked to allow for any number of dynamic pools to be defined and to let you subclass it to easily do your own stuff.
It also shows what the system looks like in elinks, because real network admins use consoles.