Age | Commit message (Collapse) | Author |
|
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.
|
|
Calling system-login.py with no mounted VyOS config has the negative effect
that the script will not detect any local useraccounts and thus assumes they
all need to be removed from the password backend.
As soon as the VyOS configuration is mounted and the CLI content is processed,
system-login.py get's invoked and re-creates the before deleted user accounts.
As the account names are sorted in alphabetical order, the name <-> UID mapping
can get mixed up during system reboot.
The intention behind calling system-login.py from vyos-router init was to
reset system services (PAM, NSS) back to sane defaults with the defaults
provided via system-login.py. As PAM is already reset in vyos-router startup
script, /etc/nsswitch.conf was the only candidate left.
This is now accomplished by simply creating a standard NSS configuration file
tailored for local system accounts.
This is the second revision after the first change via commit 64d32329958
("login: T5521: home directory owner changed during reboot") got reverted.
|
|
init: T5577: clear mandatory and optional RADIUS/TACACS PAM settings
|
|
This complements commit 5181ab60bb ("RADIUS: T5577: Added 'mandatory' and
'optional' modes for RADIUS") and commit 1c804685d0 ("TACACS: T5577: Added
'mandatory' and 'optional' modes for TACACS+"). As those new services
should also be cleaned during system boot.
|
|
|
|
On first boot after an upgrade /etc/hostname and FRR configuration is not
populated. FRR determines the system hostname once during startup and does not
repect changes of the hostname CLI value.
Thus after an upgrade of VyOS FRR started with a hostname of debian that was
propagated to peers.
The commit retrieves the hostname from the CLI and presets this before FRR is
initially started.
|
|
|
|
- Reuse existing utility functions to check if a boot is ongoing
(boot_configuration_complete())
- Run system_frr.py script to configure FRR daemon before initial launch
- Add safety net to always have FRR running on the system
This does yet not solve the error in T5239 but it's a small step towards
the solution.
|
|
add IPv6 support and firewall groups
|
|
Using variable ${vyos_rootfs_dir} instead of wildcard for both restore_if_missing_preconfig
and restore_if_missing_postconfig.
|
|
|