After sitting on the fixes for what seems like forever, staticDHCPd 1.5.5 has been released.
I’ve moved Prismscript to Google Code and added a fairly substantial amount of documentation.
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.
Full details, as always, are in the changelog.
This is just a bugfix release over 1.5.0; details are in the changelog.
Note: I intend to make some more behind-the-scenes changes over the coming week or so to allow other projects easier access to the database.
I recently received user-e-mail letting me know that I’ve fallen behind (again) in my goal of matching the Japanese Hymmnoserver’s content.
So, like, thanks for the heads-up, Maverynthia; I’ll get started on translating the new content and performing a vocabulary audit today, with hopes of finishing the process by next weekend.
Update: It looks like aquagon beat me to translating key technical details from new sections, so I’ll be using his work as a basis for my own. This should speed things up considerably.
staticDHCPd 1.5.0 is now available for download.
For anyone curious, the changelog can be found on the Google Code project site.
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_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.
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.
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)