vyos-1x.git/interface-definitions/include, branch 1.4.0-rc2

Merge pull request #2789 from vyos/mergify/bp/sagitta/pr-2777

2024-01-11T05:48:06+00:00

T5688: Changed 'range' to multi in 'client-ip-pool' for accell-ppp (backport #2777)

Merge pull request #2793 from sarthurdev/T5550_sagitta

2024-01-11T05:41:17+00:00

interface: T5550: Interface source-validation priority over global value (backport)

T5688: Changed 'range' to multi in 'client-ip-pool' for accell-ppp

2024-01-10T19:00:37+00:00

Changed node 'range' to multi in 'client-ip-pool' for accell-ppp services. Added completionHelp to default-pool and next-pool. Fixed verification in vpn l2tp config script. (cherry picked from commit 4ffec67d04670192d9b722353cbaef04cb0ba129)

bgp: T5913: allow peer-group support for ipv4|6-labeled-unicast SAFI

2024-01-10T18:58:27+00:00

(cherry picked from commit f1411240c6b11ec400ac0f66eb71982259204317)

Merge pull request #2783 from vyos/mergify/bp/sagitta/pr-2263

2024-01-10T10:21:25+00:00

T5530: isis: Adding loop free alternate feature (backport #2263)

T5530: isis: Adding loop free alternate feature

2024-01-10T07:27:04+00:00

(cherry picked from commit 7a2b70bd73c8579a885348b93b8addfb20fb006c)

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)

https: T5886: migrate https certbot to new "pki certificate" CLI tree

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

(cherry picked from commit 9ab6665c80c30bf446d94620fc9d85b052d48072)

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

T5896: firewall: backport interface validator for firewall rules.

2024-01-08T11:05:56+00:00