pfSense

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! :)