| Age | Commit message (Collapse) | Author |
|---|
|
image latest vrf <name>"
|
|
Commit-confirm will restore a previous configuration if a confirmation
is not received in N minutes. Traditionally, this was restored by a
reboot into the last configuration on disk; add a configurable option to
reload the last completed commit without a reboot. The default setting
is to reboot.
|
|
|
|
|
|
Improvements in the `vyos_net_name`:
- Used a new locking system, to be sure that multiple running scripts will not
try to perform operations at the same time.
- Replace logging from a file to syslog. This is common with all the rest logs,
and additionally gives a better view of actions done during a boot.
- Small bug fix in `get_configfile_interfaces()`: exit with an error in case a
config file cannot be parsed. This resolves potentially an unbound `config` object.
- Minor formatting fixes to follow our requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add the ability to configure the API port if the API on the secondary
server works on a non-default port.
The primary node will connect to configured port for config-sync
```
set service config-sync secondary address '192.0.2.11'
set service config-sync secondary port '8443'
```
|
|
The actual name of the script is `vyos-vrrp-conntracksync.sh`
|
|
onlink pretend that the nexthop is directly attached to this link,
even if it does not match any interface prefix.
Useful when gateway not in the same interface network
set interfaces ethernet eth0 vif 10 address '10.20.30.1/32'
set protocols static route 10.20.30.0/32 interface eth0.10
set protocols failover route 192.0.2.11/32 next-hop 10.20.30.0 onlink
```
vyos@r4# sudo ip route add 192.0.2.111/32 via 10.20.30.0 dev eth0.10 metric 1 proto failover
Error: Nexthop has invalid gateway.
[edit]
vyos@r4#
[edit]
vyos@r4# sudo ip route add 192.0.2.111/32 via 10.20.30.0 dev eth0.10 onlink metric 1 proto failover
[edit]
vyos@r4#
```
|
|
found using "git ls-files *.py | xargs pylint | grep W0611"
|
|
|
|
Package path/section data in single command containing a tree (dict) of
section paths and the accompanying config data. This drops the call to
get_config_dict and the need for a list of commands in request.
|
|
|
|
|
|
Extend `service config-sync` with new sections:
- LeafNodes: pki, policy, vpn, vrf (syncs the whole sections)
- Nodes: interfaces, protocols, service (syncs subsections)
In this cae the Node allows to uses the next level section
i.e subsection
For example any of the subsection of the node `interfaces`:
- set service config-sync section interfaces pseudo-ethernet
- set service config-sync section interfaces virtual-ethernet
Example of the config:
```
set service config-sync mode 'load'
set service config-sync secondary address '192.0.2.1'
set service config-sync secondary key 'xxx'
set service config-sync section firewall
set service config-sync section interfaces pseudo-ethernet
set service config-sync section interfaces virtual-ethernet
set service config-sync section nat
set service config-sync section nat66
set service config-sync section protocols static
set service config-sync section pki
set service config-sync section vrf
```
|
|
|
|
This extends commit 86d1291ec5 ("[boot-config-loader] T1622: Add failsafe
and back trace") and adds missing groups to the vyos user. Without this
change the vyos user will only have operator (vyos@vyos>) privileges,
even if this level is discontinued.
One could hack himself up as the user has sudo rights, but rather place
the user in the right groups from the beginning.
NOTE: This user is only added if booted with "vyos-config-debug" and
an error when the configuration can not be loaded at all.
|
|
The "idea" of this PR is to add new CLI nodes under the pki subsystem to
activate ACME for any given certificate.
vyos@vyos# set pki certificate NAME acme
Possible completions:
+ domain-name Domain Name
email Email address to associate with certificate
listen-address Local IPv4 addresses to listen on
rsa-key-size Size of the RSA key (default: 2048)
url Remote URL (default:
https://acme-v02.api.letsencrypt.org/directory)
Users choose if the CLI based custom certificates are used
set pki certificate EXAMPLE acme certificate <base64>
or if it should be generated via ACME.
The ACME server URL defaults to LetsEncrypt but can be changed to their staging
API for testing to not get blacklisted.
set pki certificate EXAMPLE acme url https://acme-staging-v02.api.letsencrypt.org/directory
Certificate retrieval has a certbot --dry-run stage in verify() to see if it
can be generated.
After successful generation, the certificate is stored in under
/config/auth/letsencrypt. Once a certificate is referenced in the CLI (e.g. set
interfaces ethernet eth0 eapol certificate EXAMPLE) we call
vyos.config.get_config_dict() which will (if with_pki=True is set) blend in the
base64 encoded certificate into the JSON data structure normally used when
using a certificate set by the CLI.
Using this "design" does not need any change to any other code referencing the
PKI system, as the base64 encoded certificate is already there.
certbot renewal will call the PKI python script to trigger dependency updates.
|
|
|
|
|
|
Commit 30eb308149 ("T5713: Strip string after "secret" in IPSEC config") had
good intention but this will happen:
use-secret foo CLI node will become " secret xxxxxx" so the output of
strip-private invalidates the configuration.
This has been changed to an exact match of "secret" only
|
|
Make "strip-private" strip the string after "secret"
|
|
|
|
|
|
|
|
|
|
conntrack: T4309: T4903: Refactor `system conntrack ignore`, add IPv6 support and firewall groups
|
|
|
|
add IPv6 support and firewall groups
|
|
|
|
|
|
|
|
* T5195: move run, cmd, call, rc_cmd helper to vyos.utils.process
* T5195: use read_file and write_file implementation from vyos.utils.file
Changed code automatically using:
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import read_file$/from vyos.utils.file import read_file/g' {} +
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import write_file$/from vyos.utils.file import write_file/g' {} +
* T5195: move chmod* helpers to vyos.utils.permission
* T5195: use colon_separated_to_dict from vyos.utils.dict
* T5195: move is_systemd_service_* to vyos.utils.process
* T5195: fix boot issues with missing imports
* T5195: move dict_search_* helpers to vyos.utils.dict
* T5195: move network helpers to vyos.utils.network
* T5195: move commit_* helpers to vyos.utils.commit
* T5195: move user I/O helpers to vyos.utils.io
|
|
|
|
bracketize IPv6 remote address to avoid
Failed to parse: https://2001:db8::2/configure-section
|
|
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
|
|
|
|
Add policy (any-available|all-available) for target checking for failover route
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 'any-available'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.1'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.11'
It depends if we need that all targets must be alive on just one target.
|
|
There is only one target for checking ICMP/ARP
Extend it for checking multiple targets
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '203.0.113.1'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '203.0.113.11'
The route will be installed only if all targets are 'alive'
|
|
If there is no route in the routing table (requires install route)
it checks routing table and returns best route None
But if we have 2 routes to the same dest ip but with different
metrics it doesn't get None (not first route install)
It cause that bast metric route cannot be installed (wrong logic)
Add func "is_route_exists" and check route/gateway/metric for
the required route
|
|
routing: T1237: Add new feature failover route
|
|
Failover route allows to install static routes to the kernel routing
table only if required target or gateway is alive
When target or gateway doesn't respond for ICMP/ARP checks this route
deleted from the routing table
Routes are marked as protocol 'failover' (rt_protos)
cat /etc/iproute2/rt_protos.d/failover.conf
111 failover
ip route add 203.0.113.1 metric 2 via 192.0.2.1 dev eth0 proto failover
$ sudo ip route show proto failover
203.0.113.1 via 192.0.2.1 dev eth0 metric 1
So we can safely flush such routes
|
|
<name> interface <ifname>`
* Include refactor to policy route to allow for deletion of mangle table instead of complex cleanup
* T4605: Rename mangle table to vyos_mangle
|
|
|
