move functions that are only used in a single spot in core to that spot for clarity, certs.inc remaining functions are now:
function &lookup_ca($refid)
function &lookup_ca_by_subject($subject)
function &lookup_cert($refid)
function &lookup_crl($refid)
function ca_chain_array(&$cert)
function ca_chain(&$cert)
function cert_import(&$cert, $crt_str, $key_str)
function certs_build_name($dn)
function cert_get_subject($str_crt, $decode = true)
function cert_get_subject_array($crt)
function cert_get_issuer($str_crt, $decode = true)
function cert_get_modulus($str_crt, $decode = true, $type = 'crt')
function cert_get_purpose($str_crt, $decode = true)
function cert_get_serial($str_crt, $decode = true)
function cert_in_use($certref)
function cert_compare($cert1, $cert2)
function is_cert_revoked($cert, $crlref = "")
function ocsp_validate($ca_filename, $serial)
some of it used in plugins, mostly AcmeClient which may inherit the functions at some point when core doesn't need them anymore.
One complication here is that dhcrelay6 requires an interface
given to the server IP address which we do by simply looking
up the route to it. I'm a bit pessimistic here aboutr link-local
usage which would require a user to input the interface which
very likely ends up in flames for more than one reason:
1. device names need to be used (at least from a technical POV)
2. the device names may contain "." which breaks our IP family detect
3. no no no
As a side note the agent option was not handled in IPv6 previously.
While the main operation are the interfaces we can't add them before we have
a destination set up. So by reordering we are hinting at this work flow and
the destination table should always be a bit shorter anyway.
Menu, ACL and XMLRPC wer consolidated into the IPv4 flag. IPv6 is
no longer functional and operates from the shared reimplementation
now. Syslog doesn't work on OpenBSD dhcrelay especially since we
start it with -d so it tries to spam to stderr which is ignored by
daemon -f to background it properly with a pid file (it's a long
story, don't ask).
Let it just encode the colors given. For now these are service colors
but they could be any colors, especially the bootstrap encoded ones
through the -sucess, etc. macros although for other themes this could
get a bit wild...
Since we are not ISC we can make a new menu spot. Keep the legacy
reconfiguration spot as we end up building a complex command line
to run and this doesn't have to go into a template that just stuffs
args into a variable to start it, which then requires and rc.d file.
Though we want to move it out of dhcpd.inc at some point.
Apparently the new MVC page is missing an apply button. ;)
It would be nice to have both IPv4 and IPv6 in here but it may be
less desirable in practice. For now use a shared namespace and
only migrate IPv4 switching the binary and breaking everything
in the process.
