When a migration tries to address an non existing attribute, a InvalidArgumentException is thrown, but only partially noted in the log.
It's likely safer to abort the migration if steps fail and send the error to the log for further inspection.
Turns out there is still implicit buffering happening, the exception
thrown is due to a lack of error handling on the Phalcon side. Even
the PHP docs suggest silencing this with '@'.
This reverts commit 7c05e524b047e6d915b80994855a4e69d365645c.
Our default PHP configuration already has output buffering set to 0,
and since there is no explicit buffering start, the ob_end_flush()
will throw two exceptions on development mode when streaming a log
file. We likely don't need this anymore so removing it here.
Endpoints are stored in the instance option as these are only relevant for the client (e.g. servers fqdn:port). Default allowed ip's for clients are all, we might consider storing these in the instance at some point as well, but lets avoid toggles nobody asked for yet.
This allows for hooking into the EventSource mechanism on the client side,
enabling server-sent events without busylooping on the backend.
This will reduce stateless network chatter and eliminates the need for
polling and many other benefits.
Continuation of f25e1214dc,
which disables buffering on the webserver side. This change in particular also
removes implicit buffering on the configd side.
As an example, the polling of CPU usage is included with a backend script here.
Granted, this could easily be replaced by `iostat -w 1 cpu | egrep -v "tty|tin" --line-buffered`,
but the client will eventually need some form of per-event formatting which is already
being handled in this example. When implementing these types of scripts, make sure
that all output that encapsulates a single event is flushed at all times to prevent
OS buffering. A new controller (without any consumers) is also implemented to showcase
the passthrough mechanism on the controller side.
For dhcp type interfaces, gateways are being pushed by the server and we automatically assume these are "external". For static ones you can configure similar behavior, but only explicit. When selecting a gateway, both reply-to and source nat rules are affected.
When nothing is chosen (now default, earlier "auto-detect"), normal routing rules apply and nothing special happens.
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.
