vyos-1x.git/debian, branch 1.4.0-epa2

Debian: T2267: extend version tag from GIT repo

2024-01-19T19:06:26+00:00

This extends commit 2c3e4696b3e22 ("T2267: Versioning: Update version tag from GIT repo") to also include release tags. (cherry picked from commit 04aa70e3f75169fc592b20acfa6e0b2f37d90a6c)

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

tacacs: T141: Wrap string in double quotes to allow expansion

2023-12-29T20:04:15+00:00

(cherry picked from commit a95ee3fd38f3c1d54ea359088d0eb1a4d4582b6b)

image: T4516: use copy of pw_reset script for install, link for compat

2023-12-17T02:37:10+00:00

Note that this was updated for the fix in T5739. (cherry picked from commit 424c9b19fd54598081e965c3364b082c5ef984de)

T5826: ensure dmidecode is installed as a dependency of vyos-1x

2023-12-14T05:47:37+00:00

dmicode is used in the "show hardware dmi" and to derive synthetic MAC addresses (see python/vyos/ifconfig/interface.py). On non-x86 platforms like arm64 it may not be pulled in explictly by other packages (like libparted2) so add it as an explicit dependency. (cherry picked from commit 46c929a99b7d507451d8385b315ae7ef9e7cbed5)

login: T4943: use pam-auth-update to enable/disable Google authenticator

2023-12-08T17:06:26+00:00

The initial version always enabled Google authenticator (2FA/MFA) support by hardcoding the PAM module for sshd and login. This change only enables the PAM module on demand if any use has 2FA/MFA configured. Enabling the module is done system wide via pam-auth-update by using a predefined template. Can be tested using: set system login user vyos authentication plaintext-password vyos set system login user vyos authentication otp key 'QY735IG5HDHBFHS5W7Y2A4EM274SMT3O' See https://docs.vyos.io/en/latest/configuration/system/login.html for additional details. (cherry picked from commit e134dc4171b051d0f98c7151ef32a347bc4f87e2)

T160: Fix Debian control conflicts

2023-12-07T14:39:01+00:00

nat64: T160: Implement Jool-based NAT64 translator

2023-12-07T14:11:00+00:00

Signed-off-by: Joe Groocock (cherry picked from commit 7d49f7079f1129c2fadc7f38ceb230804d89e177) # Conflicts: # debian/control

mdns: T5793: Cleanup avahi-daemon configuration in `/etc`

2023-12-02T07:44:07+00:00

`/etc/avahi` technically can be deleted since we operate with avahi-daemon configuration in `/run/avahi-daemon`. But we still need to keep `/etc/avahi/services` because avahi-daemon `chroot` to that location at startup. This is setup at build time via `AVAHI_CONFIG_DIR` and there is no way to change it at runtime. (cherry picked from commit 2b57ca6c3f9ff98cd6d4dd2a101a8b72ed2d94f4)