| Age | Commit message (Collapse) | Author |
|---|
|
The regex used is not working if the string contains dots.
Originally authored by: Lucas <pinheirolucas@pm.me>
(cherry picked from commit c8670ae7941a8bac31e2174d4c6426b47272bfcc)
|
|
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.
(cherry picked from commit b8db1a9d7baf91b70c1b735e58710f1e2bc9fc7a)
# Conflicts:
# debian/control
|
|
|
|
underscore and dot
(cherry picked from commit 82b4b2db8fda51df172210f470e5825b91e81de4)
|
|
interfaces
Interfaces matching the following regex (ppp|pppoe|sstpc|l2tp|ipoe)[0-9]+ can
not be used as source-interface for e.g. a tunnel.
The main reason is that these are dynamic interfaces which come and go from a
kernel point of view, thus it's not possible to bind an interface to them.
(cherry picked from commit 5062f5d313548d6ebb9c07fee6b6d6be25b8f8f0)
|
|
set protocols bgp sid vpn per-vrf export '99'
set protocols bgp srv6 locator 'foo'
set protocols bgp system-as '100'
Will generate in FRR config
router bgp 100
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
no bgp network import-check
!
segment-routing srv6
locator foo
exit
sid vpn per-vrf export 99
exit
(cherry picked from commit af46fe54e56cf85d13b62ee771bec3d80f225ac5)
|
|
Apply baseline defaults for `.gitattributes` and `.vscode/settings.json`
for improved developer experience.
The `.gitattrbutes` settings are based on:
Git documentation (https://git-scm.com/docs/gitattributes#_effects)
GitHub documentation (https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings)
Community templates (https://github.com/gitattributes/gitattributes)
Since editor-agnostic line-ending specific settings are applied to
`.gitattributes`, they can be removed from `.vscode/settings.json`.
The global VSCode defaults have also been removed to avoid duplication.
(cherry picked from commit c30002208d392177cb1ffc1a5c714f7ad6d573b6)
|
|
The string data type specifies either an NVT ASCII string enclosed in double
quotes, or a series of octets specified in hexadecimal, separated by colons.
For example:
set interfaces ethernet eth0 dhcp-options client-id CLIENT-FOO
or
set interfaces ethernet eth0 dhcp-options client-id 43:4c:49:45:54:2d:46:4f:4f
As of now there was no input validation performed.
(cherry picked from commit bed1cd01904ef89b5d31bd47de0f230214900f16)
|
|
firewall cli
|
|
|
|
|
|
|
|
|
|
regex
|
|
|
|
|
|
|
