Feature #2248
closed
services.inc to detect user override and allow gracefully, perhaps by placing default config in the interface form where it can be edited and reset
0%
Description
A number of packages have hard-coded options in services.inc, which are coded in such a way that if the user tries to set their own values for these options, there's no attempt to detect this gracefully or handle it, the user's chosen options aren't able to gracefully override the default - instead the package fatally terminates.
A simple example - if a user tries to use DNS forwarder in 2.0.1 and uses the "native config" box to optimise its options, services.inc handles it like this:
if ($config['dnsmasq']['custom_options']) {
foreach (preg_split('/\s+/', $config['dnsmasq']['custom_options']) as $c)
$args .= " --$c";
}
/* run dnsmasq */
mwexec_bg("/usr/local/sbin/dnsmasq --local-ttl 1 --all-servers {$dns_rebind} --dns-forward-max=5000 --cache-size=10000 {$args}");Graceful code would check at line 3 if $c starts with one of local-ttl, all-servers, dns-forward-max or cache-size, and if so would not add the relevant command at line 6. The reason being if the user happens to be setting up DNS forwarding and specifies their own values for any of these, the package will auto-fail as soon as it tries to execute the result. The same applies to all packages, meaning in effect that a user can never be guaranteed to copy an existing function's config into pfsense. Without checking the source code at services.inc they can't know what will collide. Without editing the source they may not be able to get options they want.
A user shouldn't have to do that. Calculating the package start command line or config (for any package) is a once-off task. It would be so nice (and pretty easy coding-wise) if services.inc didn't assume the user won't set certain options, and if it gracefully checked whether the user had done so and allowed them to.
It would be conceptually cleaner to put the default config in the "custom config" box of the interface form (and not hard-code it or hide it from the user). Then the user sees the actual standard config for each package, and can modify it, or reset it to the default. Can package default configs be handled that way in 2.1? It's so much nicer! :)
Updated by Chris Buechler over 13 years ago
- Status changed from New to Needs Patch
it could be done if you want to write, test, and put in a merge request in github for it. Otherwise you're asking me to pay an employee to do a significant amount of work, and I'm not interested in doing so. Not a bad idea, but not of enough use to justify the effort for me. If a volunteer would like to pick it up that's fine, but that rarely happens. There would be major caveats in filling in the auto-configured values too.
Updated by Stilez y over 13 years ago
I understand. I reported it because it took me 4 hours to find out and I thought someone else might benefit if it's fixed. Searching the source for a mention of "local-ttl" was tricky to work out how to do, though the issue was obvious (must be well-written code, eh?).
Patching seems conceptually simple and the code's well written, but to coin your words, you'd be asking me to learn C, followed by teach myself BSD (having no experience of any *nix) followed by immersing myself in router source code, before starting it, to have a chance. That's a significant amount of work too, C and FreeBSD are each easily up to a year or more if one has no experience. I'm a volunteer who wouldn't mind picking it up, but won't have a hope. What can I do? My contribution as a volunteer is limited to spotting things that need fixing and bringing them to attention so others can do it. Repeated small but intense frustrations such as a 2 day issue that turns out to be due to a misleading interface or hidden option makes the difference.
I understand the limitations you have, but a better product will foster fewer limitations, and much of this is simple stuff - a clearer interface, better documentation, making a hidden item visible. Reporting the issues is the best I can do to help pfsense in turn. Multiple that a bit... it counts. But I can't fix these and it's sad to hear nobody else probably will either.