Although this isn't a full implementation yet, it can help callers that need to access the menu system.
In the long run it might be practical if this class would also construct the menu system, so we can add some flexibility there.
* VPN: OpenVPN: Add tls-crypt-v2 support, initial implementation
* Unify key generation into a single bash script that handles stdout parsing and always emits base64, consume that in the key generator
* plist fix
* Add comment that explains stuff a bit better
* VPN: OpenVPN: add tls-crypt-v2 support - refactor https://github.com/opnsense/core/pull/10069
---------
Co-authored-by: Ad Schellevis <ad@opnsense.org>
* Services: Kea: DHCPv4/6: Add type system with validation and encoding for supported DHCP options
This adds a type framework using MAPS extracted from data inside the KEA documentation.
Most flat options have a validator and encoder added. Users are guided via validation messages which types are correct choices for each code selection.
Advanced options (structured, nested, encapsulated) do not have an own validator or encoder yet, they fall back to hex.
Unknown options that are valid in the IANA lists, but maybe not inside KEA yet, also fallback to hex.
The user can always bail out of the type system and always use hex instead for any option.
* CodeSource was missing, preventing match_code and code to be evaluated independently upon instantiation of the field type
* Clean up some failguards since if those conditions would be true I don't want to fail silently
* Turn encoding into a map so the code is easier readable, add missing uint length validation
* Do not hide this error silently
* Add missing encodeHex() function and normalize to uppercase to relax validation a bit
* Forgot two spots that still refer uppercase as mandatory
* Change getEncodedValue() to encodeValue() Feedback from @fichtner
* Some light restructuring, reduce amount of public endpoints, turn them private.
* Cull two helpers that are only used once
* An unknown option should only allow hex, otherwise we accidentally allow all encoding types. The IANA list may contain options that are not inside the DHCPv4 or DHCPv6 maps
* Fix int32 validator
* Some minor cleanups to reduce some single use variables
* Update src/opnsense/mvc/app/models/OPNsense/Kea/FieldTypes/KeaOptionDataField.php
Co-authored-by: Franco Fichtner <franco@opnsense.org>
* Update src/opnsense/mvc/app/models/OPNsense/Kea/FieldTypes/KeaOptionDataField.php
Co-authored-by: Franco Fichtner <franco@opnsense.org>
* Add comments to the more complex encoders and fix some missing uint encoders
* I forgot the encodeString() encoder :D
* Add KeaOptionDataFieldTest.php with test cases for each encoder
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
This uses csv-false to force kea to send option data as hexadecimal value, instead of enforcing types on them.
This means theoretically you can now send any byte coded option out, meaning the user can construct whatever value they need. This also means encapsulated options like 43 can be sent in the format any vendor might require, as binary that is.
There is also another possibility, a very specific format of data can automatically convert strings into hex (bytes), kea handles this conversion internally. "data": "'convert this text to binary'"
* kea: WIP add dhcp-ddns daemon with forward zone support, goal is initial feature parity with what ISC had.
* Add a default for ddns_domain_algorithm inside the config generator
* The control socket is not needed right now. It would only be required to directly query the ddns server
* Some updates to ddns model and dialogs
* Update service controls via data_service_widget
* More terminology changes for ddns server ip and port
* It looks like a trailing dot validation is not necessary as the configuration is valid regardless, kea does not crash or log any error here
* Add constraints for key_name and key_secret to be used together, adjust some property names for clarity, extend ddns_domain_key_algorithm with all supported values per documentation
* Use single validation string
* Small tweak on validation message, push default of key_algorithm to model
* key_algorithm is required due to the default
* Fix labels in dialogs
* Validate dependency between forward zone and DNS server
* Now that we tightened validation in the model we can drop some guards in the config generator
* Lets not offer manual config at the beginning
* Add newline to model
* Copyright date
* fix DDNS config generation to place key-name at domain level and deduplicate DNS servers
* Update src/opnsense/mvc/app/models/OPNsense/Kea/KeaDdns.php
Co-authored-by: Franco Fichtner <franco@opnsense.org>
* Review comments, add trailing commas for diff control reasons
* Add a DependConstraint for ddns_domain_key_secret instead of making it a required field, saves on model migrations
* Apply suggestion from @Monviech
* Minor terminology adjustments
* Forgot the ACL name
* This guard is not needed, it's better if the config keys become empty arrays when nothing is configured to prevent old data sticking around
* Simplify ctrl_agent volt page to look like the new ddns agent volt page for consistency
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
Most notable differences that are decided by the controller providing an "entrypoint" and "categoryKey" variable:
- controller name (entrypoint)
- category key (category vs categories)
Other subtle differences:
- enabled/disabled key (dnat is disabled)
- DNAT local port cannot do port ranges so the list_port_select_options reflect that
The functionality should be the same as before with less code as the same view template can be shared by all NAT controllers.
Add UUID to the fields that can be searched, but only if the searchPhrase contains a valid UUID. That way it won't match on partial strings.
* Create new Type class in core library and add isUUID static, replace individual callers with the new static.
* Add a new static function containsUUID() to the new Type class.
* Move searchPhrase tokenization to ApiMutableControllerBase searchBase()
Determine if search_tokens contain a valid UUID, if yes collect the uuid field so it can be searched. Doing this prevents finding partial strings in UUIDs, but allows to find exact UUIDs.
Inside UIModelGrid fetchBindRequest(), use the search_tokens directly. A compatability case makes this backwards compatible for callers that do not know about search_tokens.
Pass the search_tokens directky into UIModelGrid fetch() instead of the raw searchPhrase.
The tests aren't complete but they do cover parseReplaceSimple()
in its latest form so that's good enough.
Just as a note the tests are designed to be render-agnostic so
that we always start with our rule input and produce pf.conf
compatible rulesets with the tests. There are two purposes here:
1. Catch regressions when parsers are changed and that also includes
switching the parser implementation completely in the future.
2. Make sure that the files are actually compilable by pf.conf and
this should be covered later (the conf files are there on the
disk for that purpose).
This is the right type of testing for the purpose since the pf.conf
syntax is virtually static and will require little maintenance.
Just needs a lot more coverage for the missing features/rule types.
The test already revealed an issue with the refactor:
replacing "any" with "" and then "" with "in" is not in
the interest of the inventor. Fix follows.
Only support %s and %% using preg_replace_callback() and throw
3 distinct TypeError cases making sure the resulting command is
the dummy command then.
We're not overly interested in how well escapeshellarg() works,
but we ensure it's being called always.
Now that the new dhcp6c code is in 26.1 we can start using it.
The file was conceptually created inline via d36f0f4f62 and before was
a single command line script... so add appropriate copyrights from that
time onward.
Many thanks to Martin for pinoeering this back in the day!
* Firewall: Rules: Migration assistant - add export option and guidance for migrations to the new mvc system.
Add new "Firewall: Rules: Migration assistant" to help people moving to our new mvc based firewall system by offering a couple of simple steps for exporting the old rules into a csv file and importing them into the new system. When all rules are migrated the user may drop all old ones using the ConfigMaintenance module used in "defaults".
There's one small issue remaining in fbegin.inc as it doesn't render the icon correctly due to VisibleName being escaped currently (which isn't the case in our mvc template).
closes https://github.com/opnsense/core/issues/9579
* Update src/opnsense/service/conf/actions.d/actions_filter.conf
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
The bulk of this started in 732e4b3388 but Martin was involved
here too over the years. To make this work read the daemon
configuration from the respective daemon config file.
>>> Invoking update script 'isc-dhcp-plugin.sh'
Installing legacy ISC-DHCP plugin for compatibility...
Strict TLS 1.3 and CRL checking is enabled.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
pkg: Cannot get an advisory lock on a database, it is locked by another process
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
process with pid 7698 still holds the lock
pkg: Cannot get an advisory lock on a database, it is locked by another process
We're going to need this for 99% of the cases in existing installs
so instead of checking for something just install it and ask the
user to let it go if unneeded.
Migrate router advertisements to its own space. Although
the data shifts around a bit the end result should be equivalent.
Of note is that we currently do not have visibility for automatic
interface tracking when not disabled, but they can be disabled
manually by adding the interface configuration and unchecking
the service enable.
Co-authored-by: Monviech <gitacc@pischem.com>
