Adds pluginctl -d mode to list device types supported, their device
names and finally allows calling a device reconfiguration by name.
This is only the beginning of vlxan refactor.
This was surfaced in 22.1.1 when CARP was treated as an alias as well
leaving setups with "none" IPv4 configuration stranded when calling
get_interface_ip() if the service does not support any explicit listening
on a CARP address (which the function actually does support). Caveats
apply as to which VIP will win as with the code before. Best used with
just one CARP address. IP alias doesn't as much sense since that would
be a static IPv4 configuration.
The latter is the reason why we cannot make a similar change to IPv6
where the primary concept is not equal to "first address in ifconfig"
for (sad) reasons.
... would be called a number of times during bootup. Since it's
a WAN interface that is attached there seems little risk of it
having to be reconfigured multiple times during boot unless the
link is flapping but rc.linkup doesn't react to boot as well so
again not sure what the problem might have been.
Code was commented out in pfSense in 2014 shortly after forking
and eventually removed in 2019.
Going back to #2394 flipflop more of the reload stack to get to the
point of understanding the 6rd/6to4/slaac WAN situation and killing
two uses of /var/run/booting in the process.
Before the phalcon5 compatibility layer, the unit tests were broken due to __isset()
being triggered by an isset call on an __items attribute in getConstraintValidators().
Since __items is only used in BaseField itself, we choose to remove it for further use. Instead,
we rely on __isset() to verify if elements exist in internalChildNodes when a subnode is accessed directly.
The second regression lived in validate() in the custom Validation implementation. Instead
of relying on the incoming data as a key, we iterate through all validators active during the objects' lifetime since
these are set prior to validation. This regression affected all constraints.
* phalcon5: update namespaces
* phalcon5 Autoload: rename registerDirs() to setDirectories()
* phalcon5: remove trailing slash
* phalcon5: default to php74-phalcon
* phalcon5: provide 4/5 compatibility layer except for AbstractValidator
* MVC - Phalcon 5 migration and options to lose dependency of phalcon validation classes.
Since Validation() in 5 moves to Filter\Validation (https://docs.phalcon.io/5.0/en/upgrade#general-notes) and the class is used in strict parameter passing,
it will be difficult to import a situation which works both on 4 and 5.
To prevent future issues, but keep the current situation functional with minimal changes, we wrapped Validation() into a class of our own. When validators inherit from BaseValidator, these are assumed to
be less strict and bound to our own handling. Phalcon validations will follow the old path for now.
Migrating existing validations on our end, should be as simple as changing the following lines:
-use Phalcon\Validation\AbstractValidator;
-use Phalcon\Validation\ValidatorInterface;
-use Phalcon\Validation;
+use OPNsense\Base\BaseValidator;
-class CallbackValidator extends AbstractValidator implements ValidatorInterface
+class CallbackValidator extends BaseValidator
- public function validate(Validation $validator, $attribute): bool
+ public function validate($validator, $attribute): bool
Todo: choose the "correct" Validation() based on phalcon version.
* phalcon5: complete migration to compatibility layer.
uses bc881b9c11 to remove the need
for AbstractValidator and Validator(Interface).
This commit changes the relevant includes and provides some changes to make the unit tests
run correctly.
* MVC - Phalcon 5 migration and options to lose dependency of phalcon validation classes. part duex
Although our previous strategy should work according to how bind() and validation() are being implemented (https://github.com/phalcon/cphalcon/blob/4.2.x/phalcon/Validation.zep),
in reality it seems they aren't the same. Our previous attempt failed some validations (such as booleans) for no valid reasons.
Long term we should remove the phalcon dependency as these effects are highly unpredictable.
phalcon5: update Validation class to now pick the right Phalcon Validation based on version
* MVC - Phalcon 5 migration and options to lose dependency of phalcon validation classes.
Minor regression in previous commit, performValidation()'s return type didn't match. Ideally we would rather switch to plain array's, but since performValidation()
is used in multiple areas (including plugins) we better opt for compatiblity now.
ref https://github.com/opnsense/core/pull/5711
* phalcon5: switch back to using count() on Messages object, adjust unit tests as needed
See 6814f32755 as to why
this is the case.
* phalcon5: remove PhalconGenerator and references, use checked-in files instead
* Update Makefile
Co-authored-by: Franco Fichtner <franco@opnsense.org>
Co-authored-by: Ad Schellevis <ad@opnsense.org>
Co-authored-by: Franco Fichtner <franco@opnsense.org>
Minor regression in previous commit, performValidation()'s return type didn't match. Ideally we would rather switch to plain array's, but since performValidation()
is used in multiple areas (including plugins) we better opt for compatiblity now.
ref https://github.com/opnsense/core/pull/5711
Although our previous strategy should work according to how bind() and validation() are being implemented (https://github.com/phalcon/cphalcon/blob/4.2.x/phalcon/Validation.zep),
in reality it seems they aren't the same. Our previous attempt failed some validations (such as booleans) for no valid reasons.
Long term we should remove the phalcon dependency as these effects are highly unpredictable.
Since Validation() in 5 moves to Filter\Validation (https://docs.phalcon.io/5.0/en/upgrade#general-notes) and the class is used in strict parameter passing,
it will be difficult to import a situation which works both on 4 and 5.
To prevent future issues, but keep the current situation functional with minimal changes, we wrapped Validation() into a class of our own. When validators inherit from BaseValidator, these are assumed to
be less strict and bound to our own handling. Phalcon validations will follow the old path for now.
Migrating existing validations on our end, should be as simple as changing the following lines:
-use Phalcon\Validation\AbstractValidator;
-use Phalcon\Validation\ValidatorInterface;
-use Phalcon\Validation;
+use OPNsense\Base\BaseValidator;
-class CallbackValidator extends AbstractValidator implements ValidatorInterface
+class CallbackValidator extends BaseValidator
- public function validate(Validation $validator, $attribute): bool
+ public function validate($validator, $attribute): bool
Todo: choose the "correct" Validation() based on phalcon version.
Unbound host and domain sort order.
Host and domain names are case insensitive. Should be handled case insensitively. myHost comes before YourHost. Always.
Sort order should be:
myHost
YourHost
Not:
YourHost
myHost
