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.
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.
Almost there. Just another day or two until something’s ready for publication.
For now, have a screenshot of what the web interface looks like now (hard to imagine that the unstyled, ancient version lasted more than three years). And know that you can customise just about everything on it: don’t like the logger’s size? That’s changeable. Want more or less stuff it in? You can do that, too. Want to get rid of it? Sure. Want to put your own stuff above or below it? That’s also easy. Everything on that page (there’ll be more once I add bindings to the stats module, which should happen tomorrow) is dynamically referenced, so it’s fully configurable.
At this point, I’ve modified pretty close to every line of code in the system. I’ve tried looking for a block of at least five adjacent, non-comment lines and, aside from constants, haven’t found anything. I’m considering doing a rewrite all all internal documentation, too, because reST is easier to maintain, then calling the release 2.0.0, because it is fundamentally quite different and quite a bit more flexible.
This doesn’t mean I’m giving up on DHCPv6 support — a lot of this reworking is intended to make that possible — but after thinking about it more, over a very long period of time, I’ll likely refactor the IPv4 stuff into isolated portions of the system (with the move to named tuples for most core structures and all of the other changes to how data is puchsed around, that’s not terribly far off), then remove it and incorporate IPv6 using different backend libraries, but all of the same interface logic. I can’t imagine a realistic need to run both IPv4 and IPv6 out of the same server anyway — they’re too dissimilar for the information to be correlatable, and they can’t bind to each other’s interfaces. That said, with the changes to the web architecture and stats components, if someone really wanted to have an integrated console for observing both IPv4 and IPv6 at the same time, they could do it pretty easily.
Anyway, there should be working code (maybe a working preview tarball) and possibly some screenshots tomorrow. If not tomorrow, then early this week for sure.