[Dnsmasq-discuss] Feature Request: tftp-script

Simon Kelley simon at thekelleys.org.uk
Wed Mar 21 12:05:59 GMT 2012


On 21/03/12 11:49, Ed W wrote:
> On 21/03/2012 09:50, Simon Kelley wrote:
>> http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.61test7.tar.gz
>>
>>
>> Has the "tftp" action implemented. At the moment it's sent to the
>> --dhcp-script script always. I'm still tending towards that solution,
>> but haven't made the final decision. The bulk of the changes are done
>> anyway.
>
> Just from the point of view of longer term plans. Recently I actually
> read the documentation on Nginx perl (I think I put in the correct link
> below?).
> http://zzzcpan.github.com/nginx-perl/
>
> The point of looking is simply that at first sight, embedding a
> relatively slow scripting language looks troublesome and a performance
> issue. However, I was quite surprised at just HOW embedded is perl in
> what is perhaps one of the highest performing network server software we
> have to study at the moment....
>
> Lua would seem like a better bet for dnsmasq (than perl) due to the very
> low installation size. Also performance is alleged to be extremely high
> (for a scripting language) and the runtime is designed with
> embeddability in mind. Nginx also allows embedded lua, although I
> haven't studied to see if they achieve similar levels of integration
>
> I have an application (captive portal) where it would be quite
> interesting to "manufacture" answers under some conditions, tweak
> answers under others, and also "cheat" on caching timeouts in specific
> situations (if the user if offline/dialup for example).
>
> Just trying to put ideas into your head...
>

Ed,

It's not quite clear if you've looked at dnsmasq-2.60+ or not. Try


make COPTS=-DHAVE_LUASCRIPT

Lua got there first.


There's an architectural problem with all the scripting (Lua and 
fork/exec) in dnsmasq at the moment; there's no sensible way to get 
information from the script back to dnsmasq. Events in dnsmasq get sent 
asynchronously down a pipe to a distinct the process which then runs the 
script. This achieves 1) privilege separation. 2) Script can't block 
dnsmasq - especially important when dnsmasq is a bit of a swiss-army knife.

There is a back-channel for errors, which could be expanded. But there's 
no sensible way at the moment to make dnsmasq wait whilst (eg) a script 
tweaks a DNS answer.

Cheers,

Simon.







More information about the Dnsmasq-discuss mailing list