Just make a MD5 sum of the file and change polling to 20 seconds.
Call backend on first run as well without waiting. Interval could
be lower still, but as said earlier it doesn't matter much all
things considered.
Gets rid of package dependency which for dhcpleases6 simply
listens on the DHCPD lease file and runs the prefix.php command
unconditionally.
For now emulate this by issuing the command every 60 seconds
which can be adjusted later if someone complains, but seeing
how many bugs this script has had vs. how many people noticed
it (basically none) I doult this will have much impact overall.
'prefix' was never a key so this got never executed for whatever reason.
It remains broken in other projects and the question is if this script
really has any useful value.
Make sure to use a proper example from ISC dhcpd itself.
Here now we truncate the prefix and add the suffix, making
sure the suffix is correct. If the upper 64 bits are empty
we likely have the wrong format and we shift it up as
e.g. "::2" is not a prefix range value, but "::2:0:0:0:0" is.
Note that this is in contrast to static IPv6 where this has
to be configured correctly in the first place.
According to the manual "forever" is actually the correct keyword.
Also the double-pipe was senseless matching an empty expression
and there was a dash missing between month and day.
Revert previous here. Debug mode is "raw" error display
mode and non-debug forwards to crash reporter.
Crash reporter itself could be broken, but mostly because
the system / include chain is broken. Until PHP offers
a reliable way to intercept parse error 500 we will have
to live with this unless it causes other side effects.
Although we could agree that we should not emit link locals
without scope attached and/or that system_host_route() should
fix this by itself, there is only caller of system_host_route()
with the same problem and that one handles it correctly already.
Since we do not know the side effects and it is late into the
22.7 development with RC1 already out that we fix this issue here
fully with the least impact possible.
When setting up an IPv4-over-IPv6 or IPv4-over-IPv4 gif tunnel, IPv6 should be disabled inside the tunnel to prevent the automatic configuration of an IPv6 link-local address.
Although the risk of misuse is likely rather small, we better drop traffic if we don't know what should be allowed yet. Our default policy should take care of standard loopback behaviour, so the impact of this change should be relatively small.
