[Dnsmasq-discuss] Feature request = block-conf

[Rance Hall]

Ercolino:I can't speak for Simon and the rest of the Dnsmasq team (mostly because I'm not on it) but I appreciate your discussion and explanation of your need.  I would have responded sooner, but I've had a medical emergency with my wife and was off the net for a few days being with family in the hospital.Now your comparison to the state of TFTP in my judgement isn't of the same caliber.  If the TFTP root is not present then the only issue is that a handful of netbooting clients wont work at all, and you'll get immediate feedback (on an impacted system) that you broke something, AND anything that booted on its own will be fine.If the supplemental config script were to not be present and skipped, you wouldnt get the immediate feedback that something wasn't working, AND you couldn't guarantee a safe state for the server instance.It seems to me that you have a legitimate issue, but there are other ways to implement what you need to happen that don't require changing Dnsmasq at all.1) manipulating the boot order such that Dnsmasq starts AFTER the USB subsystem is loaded and the supplemental file system is mounted.2) The file system on the embedded device shouldn't be read-only and you should be able to copy the supplemental config script from the USB key to the root filesystem of the device and then it would be available when the system booted and your mount sequencing issue would go away.RanceOn Mar 4, 2022, at 2:52 PM, Ercolino de Spiacico <bellocarico at hotmail.com> wrote:>How does dnsmasq behave if there is a configuration error in the config >file elsewhere?  If the syntax is broken then it fails hard. Don't see >why this wouldn't be true of a suplemental config script being referred >to in the main one.And as to --fail-safe:  I don't see how this is >reasonable, as it will lead to undesirable operation and possibly even >broken clients if the mistake includes part of the dhcp >configuration.Its annoying, but probably better for services not to >start if they can't interpret/understand their starting statI appreciate the reason why this was originally designed to be the default behavior however please allow me: this conf-script might be is another beast.I'm on a router developing this, the dnsmasq config is read at boot from the content of a nvram variable. By the time dnsmasq starts I must already have this conf-script target created, the USB mounting comes way after everything else and the script booting process is screwed; NTP doesn't sync, clients don't get an IP... you name it. Also if the device has no USB this needs to be referenced and created in /tmp (RAM) at boot, this is via the init script that again is coming in a bit too late in the SoE. Until this file is created dnsmasq fails. Moreover there's an additional risk here, part of the config content is coming from Internet so outside the administrative domain. A typo by the list maintainer might cause havoc, most importantly, this is not necessary when the device is initially set up, it can come after months and affect a large number of devices at one.I really don't want to sound insistent but let me put it this way, long time ago I brought up this very topic in the context of TFTP. If the destination folder of TFTP didn't exist it used to fail dnsmasq (big time on a router). Then fortunately the tftp-no-fail directive was introduced.This conf-script is pretty much the same case but in a different context. If this extra info here above is still not enough I'll drop the ball, but I'm just making a final effort because I see value in it, that's all.Regards_______________________________________________Dnsmasq-discuss mailing listDnsmasq-discuss at lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220308/24edfae7/attachment.htm>