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.
Instead, the next release will be 1.7.0. In revising logging and the web structure, the DHCP-processing core was entirely refactored (the handlers are now much, much easier to understand), more data was made accesible, and extensions now run on a publish/subscribe model, to make it easier for sites to plug in custom code and otherwise do nifty things.
There’s still a bit of work to be done, but it should be ready in a few days. Old config files and custom code will still function properly, albeit with the need to change two lines, which are documented in the README.
I decided against calling it 1.6.3 because, with so much change to the code, it’ll probably need a 1.7.1 release before I’d recommend that production environments trust it, but I’ll be putting it through its paces as much as possible myself, while it’s in development, so it should be stable and mature enough for use in non-mission-critical sites when the tarball gets published.
staticDHCPd1.6.2 is now out. As mentioned yesterday, the new feature for this release is support for using simple INI files to configure small networks.
This comes alongside much better abstraction of the underlying database engine, so it should now be easy to tie in webservices and other fun stuff without needing to kludge around SQL concepts everywhere.
Statically managed DHCP, now as easy as [192.168.1.0/24|0]
staticDHCPd1.6.1 has been published, which formally introduces dynamic provisioning, but which is mostly a major restructuring of the codebase.
For full details, please consult the changelog, but know that it’s mostly compatible with existing installations: copy your conf file to one of the new locations, either conf/ or /etc/staticDHCPd and everything should keep working, just as it did before. Of course, since it will work as it did before, if what it did before works for you, you don’t need to bother updating.
The biggest change for new users is that there are now setup scripts and installers, quickly outlined in the README and on the main page of the GoogleCode site. Using the installer/setup method, keeping a site up-to-date should be easier than before, because there’s no chance of a config file being overwritten with the new structure, which makes it one step easier than copying your old config file into place.
Two more updates are expected over the next couple of days, however, so you may want to hold off on changing anything until they’re out. The next one will be the introduction of a simple INI-based config method, which will probably be of benefit to really small sites, where even SQLite is overkill (but, more importantly, it means an abstraction layer will be introduced above SQL brokers, which should allow for more flexibility in general, configuration-wise). And the one after that will try to reconcile the differences between the old logging method and Python’s native logging module, hopefully resulting in better runtime logs, while still keeping the web interface around, but decoupling it so that it can be redesigned in the not-too-distant future.
staticDHCPd 1.6.0 is now in testing, adding support for, surprisingly, dynamic provisioning.
This isn’t a new focus for the project, but a request came in and it seemed pretty easy to do it in a way that leaves all of the dynamic messiness in the domain of site-specific configuration code, without changing the internals one bit. This was accomplished by adding a new hook-function to conf.py that gets triggered whenever a MAC isn’t found in the database, offering a chance for custom code to synthesise a record. Injecting a record at this point is, to the rest of the architecture, the same as having found it in the database, so yay for well-factored designs.
The gist of this is that, if you want to provision things on the fly, whether permanently or not, or if you just want to send yourself an SMS, or both, or something else that’s totally wild, you’ve now got the facilities to do so. Have fun and let me know what, if anything, breaks.
An in-memory example of dynamic provisioning is in the 1.6.0 codebase and its usage is described on the project wiki, under the FAQ and new dynamism page.
Also new is a DAEMON option, allowing you to decide whether you want to run the process as a true daemon or keep its controlling terminal for testing purposes. Daemon mode ships enabled in new config files, but defaults to disabled in older ones, since it was up to the initscript/policy to handle that before, but that’s kinda silly.
staticDHCPd1.5.7 is now available, which is identical to 1.5.6, except that PXE requests will work, even if you have your network configured to use relays only. PXE requests are strictly unicast and omit gateway information in many cases. Chances are this will affect very few people, but it’s understandably confusing for those who are.
Okay, so I’m a terrible liar because I’ve had no time to really do anything related to project-work, but have staticDHCPd1.5.6, which should now really do PXE, not break when setting complex RFC options, timeout when sending e-mail to unreachable servers, and generally do other things more goodishly.
No, you won’t need to update your config files, since missing values will be set to sane defaults, but you should read the new one to see what the ‘pxe’ parameter has become. Using ‘if pxe’ like before, even though it didn’t work, will not result in any breakages, though.
Yeah, I skipped 1.5.2 and 1.5.3 and went straight to 1.5.4. I didn’t want to push out three versions within the span of two days (the others are tagged in Subversion if you really want them on their own).
1.5.2 fixes an issue with Cisco relays not liking packets sent from ports other than 67 and adds support for Oracle (thanks to Matthew Boedicker for making both of these possible). 1.5.3 makes PXE booting work when the client insists on using 4011 and you don’t want to set up another server (and it makes it easier to process client-vendor options). 1.5.4 makes upgrading from older versions a very simple process.