[Dnsmasq-discuss] command on DHCP release

[Simon Kelley]

Luca Landi wrote:
> Simon Kelley ha scritto:
> 
>>Every potential addition is a judgement call between useful extra stuff 
>>and bloat. In my experience, running shells to "do stuff" is never that 
>>satisfactory, it's also terifyingly easy to get parameter escaping or 
>>environment stuff wrong and allow arbitrary command execution.
> 
> 
> I quite disagree on the "never satisfactory" thing: in general I can't see 
> anything really simpler and more straightforward to get the job done than 
> running a good old shell script to configure things. Regarding security, in 
> general I much agree with you but I disagree with your strong adjectives: 
> secure programming is always possible, certainly difficult but still 
> possible. Later in your message you mention dbus: IMHO that is fairly 
> contraddicting with respect to security because difficulty of secure 
> programming usually is very related to complexities and introducing dbus 
> introduces complexities also into dnsmasq (don't know, just supposing). 
> Anyway I understand that you are not undecided as the "equivocating" verb 
> you used in your previous message made me think (or maybe I just 
> misinterpreted it due to the Italian meaning of that verb...) so I won't 
> bother you further.

It now the case that the most difficult work on dnsmasq is deciding what 
to leave out: reading the fine line between something which is supposed 
to be "small, lightweight and easy to configure" and a set of over 50 
configuration options. I'm also aware that I have to either stop adding 
features or create stable and development branches soon - there's no 
longer any real justification for significant version churn in the code 
which everyone is using in production.
> 
> 
>>An alternative that I'm thinking about is DBus: 
>>www.freedesktop.org/Software/dbus which is a lightweight IPC system 
>>expressly designed for integrating daemon-like software components on 
>>Unix systems. I already have libdbus patched into the initialisation and 
>>event-loop code in dnsmasq, and DBus methods to set the upstream 
>>nameservers.
> 
> 
> Ideally sounds cool, but I wonder whether it would actually suit an embedded 
> system. I mean: another thing to compile, deploy, make room for in memory 
> and storage... Don't know, seems a bit oversized for what dnsmasq is meant 
> to be. 

It will always be a compile-time option: embedded systems which don't 
use it will not have to pay the code size or dependency penalty for 
libdbus. In fact I plan to continue distributing dnsmasq with DBus 
support defaulted off. I figure that it really needs integration with 
the whole distribution to use it successfully, so it's no loss for there 
to be no dbus functionality in binary packages for distros which don't 
have integrated DBus support.



> But you seem to really "striding" toward it so what do you think 
> about adding methods to also manipulate the internal cache? recently I'd 
> have loved to have the possibility to "hotplug" (add/remove) entries in the 
> cache at my will.
> 
There's already a method to clear the cache (like SIGHUP). More fine 
grained control would certainly be possible.
> 
>>Maybe that could be extended for DHCP lease status changes? 
> 
> 
> Can well be, but in order for it to make sense I think we'd need yet another 
> daemon (to compile, deploy, etc.) waiting for those messages on the dbus. 
> And what would that daemon possibly do on each received message? as long as 
> all (or at least most of) other daemons, utilities, tools, etc. normally 
> present even in the leanest system won't be dbus-aware that daemon would 
> probably end up running a shell script, so you may have pushed many 
> security concerns away from dnsmasq (which is certainly good since, as you 
> said, dnsmasq is directly exposed by definition while dbus is not) but 
> added general complexity to the overall operating system. And all this only 
> to "do stuff" which most of times is very simple and quick? at a first 
> glance to me it does not worth the while.
> 

I'm moving towards an all encompassing system for network configuration 
which should make the added complexity pay off. Imagine a system which 
"just works" when you plug a machine into a new network: the machine 
gets an IP address via DHCP and the DHCP server gives it the rest of the 
network configuration too. Then the DNS server, NTP server, mail 
servers, FTP and HTTP proxies all get automatically configured and all 
the relevant programs pick up the new settings automatically. Mac OS X 
already does this, and efforts like NetworkManager are working on doing 
it for Linux. I've built a DBus-enabled DHCP client called Diamond 
(http://www.thekelleys.org.uk/diamond) which is designed to do the DHCP 
side, and I'm working on automatic configuration of the "users" of 
network settings too. The dnsmasq stuff is part of that.


> All this is just my 2 cents :-)

Thanks for your input.


Cheers,

Simon.