staticDHCPd 1.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 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.
Nothing to announce, really, other than that I finally seem to have something approximating free time, and will be using it to start catching up on projects. If you’re waiting for me on an issue or e-mail response, you should have it within a few days, and every project should be getting updates shortly.
After sitting on the fixes for what seems like forever, staticDHCPd 1.5.5 has been released.
As always, you can grab it from Google Code, and the changelog can be checked to see that this is a bugfix release, addressing some important (if not exactly everyday) issues.
I’ve moved Prismscript to Google Code and added a fairly substantial amount of documentation.
I just solved a weird problem that, once understood, actually makes a lot of sense, but would probably be pretty hard to identify without a lot of guesswork.
My scenario, simplified:
timeout=7.5s) to get events to processNow, this should seem like a fairly straightforward thing: a handful of threads, each capable of running in isolation, except for a common dependency on a threadsafe queue. The problem, however, is that the worker threads all eventually seemed to freeze, doing nothing while the infinite-looping thread ran fine.
Symptoms included being able to enumerate all threads, being able to have printouts saying that the threads were, indeed, alive, and what seemed to be freezing related to the logging module.
After commenting out every logging statement in the threads, the problem persisted, so they weren’t the issue. After that, I tried replacing queue.get() with a simple time.sleep(7.5) to see if the threads were still operating and the queue was at fault. The same behaviour occurred, with threads freezing when they slept. This implied that the problem was related to blocking.
It wasn’t until I started pinging someone uninvolved as a sounding board that the pattern started to make sense: the threads may not be reacquiring the GIL, so they might not ever be able to resume, even after they’re supposed to wake up. I tried waiting for ten minutes and, sure enough, one of the threads showed signs of life.
The problem was that my C polling function never released the GIL, so the entire timeout window would have been one big instruction to Python. Instead of taking advantage of threads for extended I/O delays, every other thread was blocking on their completion and the default 100-instruction context-switch was making the process take forever.
Simple to fix, but really, really hard to diagnose when just looking at the obvious symptoms. Hopefully, anyone who reads this will jump to a conclusion faster than I did, since it’s the sort of issue that can be really frustrating in what seems like a common design.
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.5.1 is now available for download.
This is just a bugfix release over 1.5.0; details are in the changelog.
As I get stuff set up to set about working on DHCPv6 support for staticDHCPd, I find that I now have five distinct subnets in a sub-1000sqft space. Yes, they all have a purpose (and will continue to exist long after 2.0 is out, ’cause I like my resources clearly defined by boundaries), yet I can’t help but feel that I’m doing something just a little unusual.
All new content from the Japanese site (Ar ciela) has been added to the Hymmnoserver. It’d have been done faster, but work does not afford much free time these days, unfortunately.
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.
