| Age | Commit message (Collapse) | Author |
|---|
|
Changes:
- Load generate 'avahi-daemon.conf' and validate basic configs
- Add tests for browsing domains and reflect-filter services
|
|
|
|
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.
|
|
|
|
|
|
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`).
|
|
|
|
|
|
|
|
T5230: Added missing enforce-first-as option to bgp protocol common c…
|
|
and frr bgp jinja template.
|
|
To accept a Proxy Protocol header on incoming TCP connections,
add an accept-proxy parameter to the bind line in a frontend section.
This parameter detects both Proxy Protocol version 1 (text format)
and Proxy Protocol version 2 (binary format).
set load-balancing reverse-proxy backend <tag> server <tag> send-proxy
|
|
Load-balancing reverse-proxy listen-address is multi-value node
Use bracketize for correct set bind config for IPv6 addresses
Listen by default IPv4 and IPv6 if listen-address is not defined
|
|
Improve and refactoring "load-balancing reverse-proxy"
- replace 'reverse-proxy server <tag>'
=> 'reverse-proxy service <tag>'
- replace 'reverse-proxy global-parameters tls <xxx>'
=> 'reverse-proxy global-parameters tls-version-min xxx'
=> 'reverse-proxy global-parameters ssl-bind-ciphers xxx'
- replace 'reverse-proxy service https rule <tag> set server 'xxx'
=> 'reverse-proxy service https rule <tag> set backend 'xxx'
'service https rule <tag> domain-name xxx' set as multinode
|
|
T5222: Add load-balancing for web traffic
|
|
|
|
Allow listing additional browse domains (in addition to the default
'local') so that custom domains can be reflected.
Additionally, allow filtering the services that are allowed to be
reflected across multiple (V)LANs.
|
|
When enabling identity-based-config, users can add arbitrary config keys
that are processed by ocserv. The user "must know" what he is been doing, as
invalid config option will make the ocserv daemon go ... whoop!
Thus add a warning and inform the user about this setting.
|
|
|
|
ocserv: T3896: add CLI options to configure ocserv config-per-user/group
|
|
|
|
T5215: add a built-in ping check for VRRP groups
|
|
|
|
Add RADIUS accounting-interim-interval option for PPTP-server
Specifies interval in seconds to send accounting information
(may be overridden by radius Acct-Interim-Interval attribute)
set vpn pptp remote-access authentication radius accounting-interim-interval '52'
|
|
Add RADIUS accounting-interim-interval option for L2TP-server
Specifies interval in seconds to send accounting information
(may be overridden by radius Acct-Interim-Interval attribute)
set vpn l2tp remote-access authentication radius accounting-interim-interval '120'
|
|
cloud-init: T5190: Added Cloud-init pre-configurator
|
|
syslog: T2778: T2769: refactoring and VRF support
|
|
Add RADIUS accounting-interim-interval option for PPPoE/IPoE/SSTP
servers.
Specifies interval in seconds to send accounting information
(may be overridden by radius Acct-Interim-Interval attribute)
set service pppoe-server authentication radius accounting-interim-interval '60'
|
|
Allow syslog messages to be sent through a VRF (e.g. management).
|
|
|
|
Added a new service that starts before Cloud-init, waits for all network
interfaces initialization, and if requested by config, checks which interfaces
can get configuration via DHCP server and creates a corresponding Cloud-init
network configuration.
This protects from two situations:
* when Cloud-init tries to get meta-data via eth0 (default and fallback variant
for any data source which depends on network), but the real network is connected
to another interface
* when Cloud-init starts simultaneously with udev and initializes the first
interface to get meta-data before it is renamed to eth0 by udev
|
|
T5171: Use XML for loadbalancing wan instead of old templates
|
|
Use XML and python3 for 'load-balancing wan'
Use Jinja2 templates instead of old vyatta-wanloadbalance.pl to
generate configuration '/run/load-balance/wlb.conf' wich used by
/opt/vyatta/sbin/wan_lb
|
|
Ability to match 'source-protocol' for the route-map filters
set policy route-map foo rule 10 action 'permit'
set policy route-map foo rule 10 match protocol 'bgp'
|
|
|
|
Commit 923d7f1d7 (bgp: T5010: add missing for-loop when iterating over "both"
route-target) referenced export rt instead of both. This happened while
improperly copy-pasting the line.
|
|
|
|
|
|
openvpn: T4402: Update openvpn server.conf.j2
|
|
The ifconfig-pool command requires the arguments separated by a space.
Hence the space was added before the subnet mask.
|
|
|
|
|
|
Changes the node name from config-per-x to identity-based-config, as a result the j2 templates and vpn_openeconnect.py has been refactored to update the node name when accessing it's child nodes.
|
|
removed extra comma invalidating json.
|
|
|
|
|
|
It is possible to install a route-map which filters the routes between routing
daemons and the OS kernel (zebra)
As of now this can be done by e.g.
* set protocols ospf route-map foo
* set protocols ospfv3 route-map foo
* set protocols bgp route-map foo
Which in turn will install the following lines into FRR
* ip protocol ospf route-map foo
* ipv6 protocol ospf6 route-map foo
* ip protocol bgp route-map foo
The current state of the VyOS CLI is incomplete as there is no way to:
* Install a filter for BGP IPv6 routes
* Install a filter for static routes
* Install a filter for connected routes
Thus the CLI should be redesigned to close match what FRR does for both the
default and any other VRF
* set system ip protocol ospf route-map foo
* set system ipv6 protocol ospfv3 route-map foo
* set system ip protocol bgp route-map foo
* set system ipv6 protocol bgp route-map foo
The configuration can be migrated accordingly. This commit does not come with
the migrator, it will be comitted later.
|
|
T5081: ISIS and OSPF syncronization with IGP-LDP sync
|
|
Initially the option 'rate-limit' was implemented with the
wrong place in the CLI:
set vpn pptp remote-access authentication rate-limit <xxx>
Expected under 'radius' section:
set vpn pptp remote-access authentication radius rate-limit <xxx>
Configuration for 'rate-limit' (Jinja2 template) never worked for
pptp, fix it.
|
|
Fix for Telegraf agent hostname isn't qualified
Try to get hostname from FQDN and then from hostname
Used for metrics
You may have more than one machine with different domain names
r1 domain-name foo.local, hostname myhost
r2 domain-name bar.local, hostname myhost
It helps to detect from which exectly host we get metric for
InfluxDB2
|
