It’s out.
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:
Yay, stats!
First, of course, is the stats module. That should be pretty simple now, except for the cool part I want to add, but even that should only take about an hour.
Second is updating the documentation.
It’s very close now. Unfortunately, I’ll probably have to leave it alone for tonight, but have something I finished while in transit.
I didn’t get to the stats module today, unfortunately, but I did finish off just about everything else, except for another demo utility to drop into contrib. Of interest to some is that you can now customise the content of <head/>, letting you inject custom CSS, JavaScript, and whatever else you want. All of the default headers, except for JavaScript and content-type, are optional, as are their associated resources.
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.
Database-free reacquisition of dynamic leases (just make sure you have proxy-ARP if you want to use this with relays)
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.
Another snapshot! Yay, terminals!
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.
staticDHCPd’s 1.7.0 web-interface, alpha-state
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.
Also, check out the pared-down config file and the new parameters and scripting guides that ship with. The README and quickstart has also been reworked to be simpler.
If you want to play with the system right now, revision 441′s logging-web branch has passed all of my basic tests and is currently driving my network.
Yay, almost done.
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.
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
[192.168.1.0/24|0]
lease-time: 87840
[08:00:27:2c:49:4c]
ip: 192.168.1.200
subnet: 192.168.1.0/24
serial: 0
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.
So I wanted a lot of screens for the new system I was building: lots of stuff to monitor, a reasonable amount of deskspace, and a desire to have at least one separate X session to handle fullscreen games without needing multiple profiles.
It wasn’t particularly difficult to set up, but documentation was sparse. To help anyone else who might be looking to do something similar, I’m providing my X config here; chances are, if you’re looking to do something similar, you’ll be able to figure out what needs to be tweaked.
Continue reading ‘Two video cards, three X sessions, five monitors: yes, it works’
