vyos-1x.git/src/etc, branch 1.4.0-epa1

vrf: T5973: module is now statically compiled into the kernel

2024-02-07T20:54:41+00:00

Always enable VRF strict_mode (cherry picked from commit 117fbcd6237b59f54f2c1c66986a8ce073808c84)

dns: T5959: Streamline dns forwarding service

2024-02-01T19:52:15+00:00

Streamline configuration and operation of dns forwarding service in following ways: - Remove `dns_forwarding_reset.py` as its functionality is now covered by `dns.py` - Adjust function names in `dns.py` to disambiguate between DNS forwarding and dynamic DNS - Remove `dns_forwarding_restart.sh` as its functionality is inlined in `dns-forwarding.xml` - Templatize systemd override for `pdns-recursor.service` and move the generated override files in /run. This ensures that the override files are always generated afresh after boot - Simplify the systemd override file by removing the redundant overrides - Relocate configuration path for pdns-recursor to `/run/pdns-recursor` and utilize the `RuntimeDirectory` default that pdns-recursor expects - We do not need to use custom `--socket-dir` path anymore, the default path (viz., `/run/pdns-recursor` is fine) (cherry picked from commit 1c1fb5fb4bd7c0d205b28caf90357ad56423464f)

Merge pull request #2827 from vyos/mergify/bp/sagitta/pr-2823

2024-01-15T10:27:00+00:00

T4856: Fix IPsec DHCP-client exit hook (backport #2823)

T5901: Add DHCP base_path dir during first boot

2024-01-15T08:54:24+00:00

We should create dhclient base_path dir `/run/dhclient` during the first boot. It fixes cloud-init boot issues ``` /etc/dhcp/dhclient-exit-hooks.d/03-vyos-dhclient-hook: line 33: /run/dhclient/dhclient_eth0.lease: No such file or directory ``` (cherry picked from commit e613983721c48c13c2e6e73e7c4dbdbaa8e9eacf)

T4856: Fix IPsec DHCP-client exit hook

2024-01-15T08:50:24+00:00

The script acually does not have the variable `secrets_lines` and secret lines itself does not have the marker `# dhcp:{interface}` in `to_find` Needs to rewrite this script in the future if it is required This commit fixes DHCP-client exit hook: ``` dhclient[6800]: NameError: name 'secrets_lines' is not defined root[6801]: /etc/dhcp/dhclient-exit-hooks.d/99-ipsec-dhclient-hook returned non-zero exit status 1 ``` (cherry picked from commit a9cf7246d4450c8b3e1b749b36c3393b0963404b)

https: T5902: remove virtual-host configuration

2024-01-10T07:11:39+00:00

We have not seen the adoption of the https virtual-host CLI option. What it did? * Create multiple webservers each listening on a different IP/port (but in the same VRF) * All webservers shared one common document root * All webservers shared the same SSL certificates * All webservers could have had individual allow-client configurations * API could be enabled for a particular virtual-host but was always enabled on the default host This configuration tried to provide a full webserver via the CLI but VyOS is a router and the Webserver is there for an API or to serve files for a local-ui. Changes Remove support for virtual-hosts as it's an incomplete and thus mostly useless "thing". Migrate all allow-client statements to one top-level allow statement. (cherry picked from commit d0d3071e99eb65edb888c26ef2fdc9e038438887)

pki: T5886: add support for ACME protocol (LetsEncrypt)

2024-01-08T20:11:13+00:00

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 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. (cherry picked from commit b8db1a9d7baf91b70c1b735e58710f1e2bc9fc7a) # Conflicts: # debian/control

T5897: frr should be stopped before vyos-router

2024-01-04T17:16:52+00:00

Signed-off-by: Date Huang (cherry picked from commit 6d16ab081b70bc4ea837b66dfe032ec6bdb563d7)

T5474: establish common file name pattern for XML conf mode commands

2024-01-01T08:25:32+00:00

We will use _ as CLI level divider. The XML definition filename and also the Python helper should match the CLI node. Example: set interfaces ethernet -> interfaces_ethernet.xml.in set interfaces bond -> interfaces_bond.xml.in set service dhcp-server -> service_dhcp-server-xml.in (cherry picked from commit 4ef110fd2c501b718344c72d495ad7e16d2bd465)

srv6: T591: enable SR enabled packet processing on defined interfaces

2023-12-21T15:28:52+00:00

The Linux Kernel needs to be told if IPv6 SR enabled packets whether should be processed or not. This is done using /proc/sys/net/conf//seg6_* variables: seg6_enabled - BOOL Accept or drop SR-enabled IPv6 packets on this interface. Relevant packets are those with SRH present and DA = local. 0 - disabled (default) not 0 - enabled Or the VyOS CLI command: * set protocols segment-routing interface eth0 srv6 (cherry picked from commit 774cc97eda61eb0b91df820797fb3c705d0073d5)