So does 9P. It's just a protocol, at the end of the day.
FUSE is actually specific to the Linux VFS subsystem. However, there have been many reimplementations on the API compatibility level, even though there is no formal standard beyond the header file, which has seen several divergences.
9p works on Linux (and therefore - hypothetically - Android) via v9fs. u9fs is also an option for non-Linux Unixen. Plan 9 From User Space isn't a figment of my imagination, last I checked.
Author here, the utility isn't that exciting to be honest. Basically it just reads the leases file that isc-dhcpd spits out, and displays the machines in a directory hierarchy via a virtual file system (this is where FUSE comes into play).
It's an alternative approach to the HTML output that home routers display on their DHCP management pages. Arguably less useful approach, but I wanted an excuse to play with FUSE.
interesting idea. if it's an excuse to play with something all for it. that being said:
parsing isc dhcp lease files is a can of worms you probably don't want to open.
to give you an example:
what happens if the same machine appears twice in the lease file?
what happens if some of the fields you are reading are missing? (let's say do you don't have a hostname)
I do a lazy dedup using a map, so only the latest entry will be stored. As all the data is output as ASCII, missing fields are just outputted as zero length strings.
Those particular obstacles proved quiet easy to work around, but I fully expect there's other hidden traps I've overlooked. So I'm welcome to other suggestions for retrieving lease information :)
sure. as a side project there're nothing wrong with it :)
I was just pointing out the pitfalls of lease parsing (i've been bitten by this over the course of time - it looks trivial to do until you look at what isc does under the covers)
side questions:
what happens with 50000 leases?
what about 50000 subnets - do you have support for hierarchically displaying subnets :)
how fast is the whole thing? can you handle malformed input?
It's really basic at the moment so there's no support for hierarchical subnets, but it's something this that might suit this kind display.
Performance wise, it's definitely not ready for any serious use. However there are some easy wins I didn't bother with that would dramatically speed things up (eg the leases file is read with each FUSE API request - which happens a lot. So I really should be running that as a separate thread that runs every x minutes and caches the object.
if Im honest, scalability was a secondary concern. I was more interested in building a working proof of concept and sadly only had one afternoon to do it in. But I tried to keep the code clean enough (though you can be the judge of that) so it could be scaled up at a later date if needed.
13 comments
[ 2.7 ms ] story [ 41.3 ms ] threadFUSE is actually specific to the Linux VFS subsystem. However, there have been many reimplementations on the API compatibility level, even though there is no formal standard beyond the header file, which has seen several divergences.
It's an alternative approach to the HTML output that home routers display on their DHCP management pages. Arguably less useful approach, but I wanted an excuse to play with FUSE.
to give you an example: what happens if the same machine appears twice in the lease file? what happens if some of the fields you are reading are missing? (let's say do you don't have a hostname)
Those particular obstacles proved quiet easy to work around, but I fully expect there's other hidden traps I've overlooked. So I'm welcome to other suggestions for retrieving lease information :)
I was just pointing out the pitfalls of lease parsing (i've been bitten by this over the course of time - it looks trivial to do until you look at what isc does under the covers)
side questions: what happens with 50000 leases? what about 50000 subnets - do you have support for hierarchically displaying subnets :) how fast is the whole thing? can you handle malformed input?
Performance wise, it's definitely not ready for any serious use. However there are some easy wins I didn't bother with that would dramatically speed things up (eg the leases file is read with each FUSE API request - which happens a lot. So I really should be running that as a separate thread that runs every x minutes and caches the object.
if Im honest, scalability was a secondary concern. I was more interested in building a working proof of concept and sadly only had one afternoon to do it in. But I tried to keep the code clean enough (though you can be the judge of that) so it could be scaled up at a later date if needed.