uguu.ca

PING in pure Python

For work, I had need of running ping from a Python context in a memory-limited environment. Python was a given, parsing subprocess output is ugly, variable payload-sizes were required, and potentially many hosts would need to be pinged in parallel.

Seems like a great job for fping, but distributing external binaries is kinda tricky with this setup, so I did it in Python. (The other Python PING implementations, all of which seem to be derivatives of python-ping, either didn’t meet my basic needs, had more procedural namespace-bleed than I’d prefer to see, tried to do too much (requiring workaround logic to just do what’s actually needed), didn’t handle errors, or were GPL-licensed, which is unfortunately not something of which this process can make use)

The code, which is public domain, is available after the break.
Continue reading ‘PING in pure Python’

staticDHCPd-2.0.0-beta-9

beta-8 is now live, with the following compelling reasons to upgrade:

• qtag support for the broadcast-bit situation
• Support for “extra” columns from your database to loadDHCPPacket()
• Intuitive data-type conversion for setOption() and getOption() for those of you who’d rather pass strings and ints than lists of bytes
• While not in the release itself, documentation is now about 5% complete, and with the templates defined, it should ramp up quickly, so closing in on rc1

This release needs more testing than any that have come before, but it’s also likely to be less stable than beta-8, because it includes a complete refactoring of DHCPPacket and some other cross-code-reaching changes. It’s almost safe to use beta-8 in controlled production contexts, but beta-9 is only for those brave and willing to tell me what’s broken.

The release is available at downloads page. As before, its changelog is in a transitive state and can be viewed in-source: staticDHCPd, libpydhcpserver.

Of extreme importance to those of you who’ve been testing the 2.0.0-beta series is that this WILL break your loadDHCPPacket() function, if you’ve defined one: definition is now supplied, rather than subnet, serial, and client_ip. To deal with this, replace those three fields (they’re sequential) with definition and access the values as definition.subnet, definition.serial, definition.ip.

staticDHCPd-2.0.0-beta-8

So it’s been a while, and I don’t remember why there was no post announcing beta-7, but beta-8 is now live, sporting the following new features:

• Support for clients that cannot handle broadcast OFFERs, which are few, but can be found in embedded systems; in issue 15′s history, this was identified as a problem with the broadcast-bit
• Persistent and local-file-instead-of-memory caching options
• Support for arbitrary config-file locations, via --config or the STATICDHCPD_CONF_PATH environment variable

The broadcast-bit feature owes a lot to Ken Mitchell, for providing feedback and extensive testing throughout the process. Thanks to corecode#dragonflybsd@efnet, too, for helping to clarify BSD networking philosophy and enable selection of a fallback cross-platform solution for L2 packet-injection.

There’s also Debian-packaging infrastructure in the repository, because that’s coming once past the RC phase. Right now, the focus is on the documentation rewrite, which should be all that remains. Feature-requests are still welcome, but try to hold off on them if you want a stable release sooner than later.

You can, as always, grab this release from its downloads page. Its changelog is in a transitive state and can be viewed in-source: staticDHCPd, libpydhcpserver.

staticDHCPd-2.0.0-beta-6

Cooper Lee identified an issue in which non-existent MACs would lead to an error when their definition, which was None, was asked for an ip attribute. This should no longer happen and went unnoticed by me ever since 2.0.0-beta-1 because I’d been using the dynamism module in my test environment, which masked the problem by always returning a full definition. I now have multiple testing servers to avoid another issue like this.

staticDHCPd 2.0.0-beta-4^H5^H7

This is a minor update, addressing a circular reference discovered by Vladimir Shencov, in which importing from staticdhcpdlib.databases during the config phase (the recommended method of defining custom databases) would prevent the server from starting. Imports should now come from staticdhcpdlib.databases.generic.

If you are using the dynamism module, you’ll need to make that change near the top of the file. Nothing else needs to be modified, though.

beta-4 only half-addressed the issue; beta-5 should deal with it properly. Sorry about that.

And beta-5 missed another reference-point. beta-7, using a fix devised by Vladimir, should have it dealt with for real. For really real.

staticDHCPd 2.0.0-beta-3

This should be the last time I modify the codebase in any significant way. I wanted to clean up libpydhcpserver and that’s now done, so please grab a copy of the most recent release, test it, and let me know about any issues.

I’ll try to work through a little bit of the documentation updates each day and if I get through everything with no new problems being reported, I’ll consider it stable.

staticDHCPd 2.0.0-beta-1

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!

Only two things left beofre staticDHCPd 2.0.0-rc1

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.

Another staticDHCPd screenshot

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)

Another staticDHCPd update

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.