Note that require_once is bad as well here, because it throws another
uncatched error as opposed to a warning when a file has not been found.
Now it is better in recovery, although 99% of the time this is supposed
to deal with syntax errors during bad core/plugin updates or manual
user edits.
It's also useful to note that the errors/warnings still make their way
to the crash reporter so we can do something about them.
Suggested by: @fabianfrz
simply eval() it and log the error instead of stopping execution.
We don't get to source the code, but since for strict plugins
there is no direct code execution the plugin acts as if it was
deinstalled.
As the plugin scope is growing rapidly, we need this to be able to
guarantee error-free execution in the widest possible sense. This
doesn't currently protect function calls, but the same thing must
be done there as well.
We have a function pair rrd_import() / rrd_export() now, which do
wildly different things even though they've been used for a single
purpose:
(1) rrd_export() writes a string, appends it to the config.xml
(2) rrd_import() takes a parsed config portion, but not as an
argument, rather as a global config element
(3) There was also an older backup clue which exported files, but
simply packed them up for restore after boot
If we can get the system to unify the usage we'll end up with a
neat way of backing, restoring and migrating RRD data, although
I'm not sure if this can be fully compatible with the old files.
The admins group has this now, it makes more sense there as several
people ran into the issue of "my user is admin, but cannot login".
Besides, the privilege sets /bin/csh as the user shell, which we don't
use for root as we have /usr/local/etc/rc.initial there.
rc.newwanip, rc.newwanipv6, interface_configure() and interfaces_configure()
all call ipsec_configure_do(), which is no wonder why the code can be prone
to races.
This looks a bit odd when we have the full struct and pass it down,
but is way easier to maintain than to tell the underlying code
this is a server or a client or whatever, because it shouldn't
matter as the vpnid is unique anyway.
Looking at openvpn_configure_server() and openvpn_configure_client()
it becomes a bit clearer why they take a config.xml subset: it's beause
the write_config() ordering was flipped. We could probably now pass
an ID and let the code figure out if it is a client or server...
