| Age | Commit message (Collapse) | Author |
|---|
|
Service config-sync allows synchronizing a section of
the configuration.
As PoC allow only nat, nat66 and firewall sections
Rertreive the configuration for a section from self node and
send this configuration to the section of the 'secondary' node.
This feature adds a symlink from helper 'vyos_config_sync.py'
to '/config/scripts/commit/post-hooks.d' and config that is
located in '/run/config_sync_conf.conf'
It will synchronyze the config only if the setcion
was changed.
set service config-sync secondary address 192.0.2.11
set service config-sync secondary key xxx
set service config-sync section nat
set service config-sync section nat66
set service config-sync section firewall
set service config-sync mode load
|
|
The previous implementation did not iterate over the communit list, so only
one match criteria was supported.
set policy route-map FOO rule 10 action 'permit'
set policy route-map FOO rule 10 set extcommunity rt '1111:2222222'
worked but on the other hand this failed:
set policy route-map FOO rule 20 action 'permit'
set policy route-map FOO rule 20 set extcommunity rt '6500:24 6500:23 192.168.0.1:111 192.168.0.1:222'
|
|
|
|
T5304: Container add volume bind propagation option
|
|
set container name c1 volume myvlm propagation rshared
|
|
|
|
Check upper bound as defined in Debian Policy Manual. Without this
check, user 'nobody' will not be available.
|
|
|
|
|
|
|
|
|
|
|
|
warning: ~ action is deprecated, consider using the 'stop' statement instead [v8.24.0 try http://www.rsyslog.com/e/2307 ]
|
|
http-api: T5248: set/load config sections as JSON via API
|
|
... this is a step towards a new and better implementation that will utilize
VPP.
|
|
frr.service startup and shutdown is now explicitly managed by
vyos-router, so remove the systemd management directive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
T5231: Add op-mode for show reverse-proxy
|
|
T3472: Print warning when commit-confirm is run as regular user
|
|
dns: T5144: Improve dynamic dns monitor and log and miscellaneous updates
|
|
|
|
|
|
|
|
dns: T5144: Refactor smoke tests for dynamic dns operation
|
|
|
|
Prevent failure when the user enters a partial CLI command without any
address specified.
Also, apply some minor formatting changes.
|
|
|
|
on reboot and shutdown attempts
|
|
T5260: Do not use deprecated python crypt module
|
|
Remove the quotes, this will always return the hash for string "password".
|
|
|
|
dns: T5144: Modernize dynamic dns operation (round 2)
|
|
Incorrect logic of node deletion now raises error, after T5251.
|
|
Templatize systemd override for ddclient service and move the generated
override files in /run. This ensures that the override files are always
generated afresh after boot.
Additionally, simplify the systemd override file by removing the
redundant/superfluous overrides.
|
|
|
|
config path
|
|
|
|
Create migration and bump package version from 0 -> 1 for dynamic dns
|
|
ddclient implementation of dualstack for dyndns2 protocol is targeted
for dyn.com (dyndns.org) only. Dualstack won't work for other servers
supporting dyndns2 protocol (for example, dyn.dns.he.net).
|
|
Apply next round of configuration tree updates to 'service dns dynamic'
with the following changes:
- Migrate `service dns dynamic interface <interface> [use-web]`
to `service dns dynamic address <interface>`
or `service dns dynamic address web [web-options]`
This communicates the intent that dynamic dns IP address is detected
in only one way - using the `<interface>` or using an external web
request, not both.
- When using external web request, (`service dns dynamic address web`),
external url is optional (`web-options url`). Ddclient defaults are
used when unspecified,
- Rename all config `login` to `username` for consistency and also to
align better with alternative ddclient backends in consideration.
- Apply global 'ipv6-enable' to per service 'ip-version: ipv6'. Selecting
usage of IPv4 or IPv6 (or both simultaneously) is now at per service
(protocol) level instead of global level. This allows more control on
the ability to select IPv4 in some cases and IPv6 in some other cases
wherever supported by the underlying ddclient protocol.
- While the IP address (and by extension, the detection mechanism) is
global, the way it is applied to a particular ddclient protocol depends
on whether it supports IPv4 or IPv6 or both.
- Related to the above, this also prevents generating incorrect config
file (`ddclient.conf`) with multiple global sections leading to an
unpredictable behavior of ddclient.
- Implement provider (protocol) specific custom tweaks whenever possible
(e.g., `zone`, `username`, `server` are not necessary in all cases).
- Move service name from a combination of 'protocol' (with protocol
config autodetected) and custom (with protocol config specified) to a
single 'service' key. This allows for consisent setup of multiple
config for the same ddclient protocol (with different options and
credentials). This also avoid ambiguity with usual networking term
'protocol' and ddclient specific term 'protocol' (and can change with
a move to a different backend).
- Apply upfront XML constraints and validations consistently wherever
applicable.
- RFC2136 specific change: Rename rfc2136 config `record` to `host-name`
for consistency.
- Cloudflare specific change: While ddclient still supports authenticating
with email and global auth key, skipping `username` in config will
indicate the intent to use API token authentication (with special
'token' literal as `username`).
|
|
|
|
|
|
|
|
configtree: T5251: catch/raise errors in functions delete and delete_value
|
|
The node was already deleted in the 'if path exists' branch; attempt to
delete in 'else' branch will now raise an error.
|
