Category: puukusoft

staticDHCPd 1.6.3 will not be released

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.

staticDHCPd 1.6.2 – finally, an on-schedule release

staticDHCPd 1.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
lease-time: 87840

serial: 0

staticDHCPd 1.6.1

staticDHCPd 1.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.5.6

Okay, so I’m a terrible liar because I’ve had no time to really do anything related to project-work, but have staticDHCPd 1.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.

staticDHCPd 1.5.4

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).

staticDHCPd 1.5.4 is now available for download, obviously.

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.

Full details, as always, are in the changelog.

staticDHCPd 1.6.x planned

Once the 1.5.x expansions are done, 1.6.x will be built, featuring a semi-stateful view into address-assignment, through a simple table design: the IP/subnet/serial key assigned to a MAC will be grouped with an expiration timestamp, allowing for an unreliable view of which hosts currently have “leases” (hosts that simply asked for configuration data, without an IP, will be tracked, too, with a special typecode). For DHCPv4 clients, this will be largely informational, enabling only the addition of LEASEQUERY support, but when v2 is implemented for DHCPv6, it will allow for server-initiated RECONFIGURE events, as described in section 19 of RFC 3315, which are pretty important, given the nature of the networks staticDHCPd is intended to serve.

This new subsystem will be configurable, using options like enable_leasequery and enable_reconfigure; if not enabled, the corresponding tracking mechanisms will not be used, for performance reasons. The data will also be storable in a local SQLite database, instead of the standard storage (this also allows for a second database if using SQLite already, to allow for better thread concurrency), to avoid a second remote access hit, when speed really matters.

While on the subject of performance, non-crucial data, like the list of clients remaining to be reconfigured and temporarily blacklisted MACs, may be stored in an in-memory SQLite database, rather than Python data-structures: this should save memory at a slight cost of speed; tests and stats will be necessary to decide whether the trade-off is worthwhile, though.

More enhancements planned for staticDHCPd 1.x

Although 1.5.0 will be published as previously described, I’ll continue extending it through 1.5.x, which will involve a revised logging engine, favouring deferred unattended writes to disk (to simplify forensics without impacting performance), a prettier web interface (though the information presented will remain about the same), and a few more runtime config options, including, if feasible, the ability to reload config options on the fly.

staticDHCPd, now with more activity

I’ve received a request to add DHCPv6 support to staticDHCPd. Lacking any reason to say no, I said yes, so v2 won’t be about moving to Python 3.0 (though I expect that the code will branch quite soon after this addition is complete), but rather about adding IPv6 support for those of you who actually need it.

My first step will be to finally add native PostgreSQL support, using psycopg, since it seems to have emerged as the dominant library since the last time I looked. This will finish 1.5.0 and mark the end of the 1.x line, save for any necessary bugfixes.

DHCPv6 support will be introduced by forking libpydhcpserver (the library that evolved from Mathieu Ignacio’s pydhcplib) into libpydhcpserver6, which may or may not be a full rewrite (if it can inherit from the old codebase, it will, but chances are it can’t, due to fundamental differences between option encodings and packet structure). Both libraries will be present in the new product, and IPv4 support will work alongside IPv6 support in the same process, to the fullest extent possible.

If anyone can recommend consumer-grade hardware that runs IPv6 (home routers, for example), I’d appreciate it, since all I’ll have to test with will be ISC-based VMs, due to a lack of physical routing fabric. (I’d like my tests to be as representative of reality as possible)