| Age | Commit message (Collapse) | Author |
|---|
|
During podman upgrade and a build from the original source the UNIX socket
definition for systemd got lost in translation.
This commit re-adds the UNIX socket which is started on boot to interact with
Podman.
Example:
curl --unix-socket /run/podman/podman.sock -H 'content-type: application/json' \
-sf http://localhost/containers/json
(cherry picked from commit f67e217f2716937115a3bdf6d316b172bbec75e5)
|
|
(cherry picked from commit b9daaaa38abc08d27158ea44e016752b3cb45400)
|
|
This fixes an error during ISO assembly:
update-alternatives: error: no alternatives for regulatory.db
dpkg: error processing archive /tmp/apt-dpkg-install-PJplR3/00-vyos-1x_1.5dev0-1880-gecaa44498_amd64.deb (--unpack):
new vyos-1x package pre-installation script subprocess returned error exit status 2
(cherry picked from commit a414190447c32be0775a077cde13cef0cf2b8c54)
|
|
wireless: T4287: use upstream regulatory database due to kernel signing (backport #3777)
|
|
Most likely b/c of our non signed Kernel binary we do not trust the Debian
signed wireless regulatory database. Fallback to the upstream database instead.
(cherry picked from commit 9263965071289b6e51e22669b6d588a8d8fbcc1f)
|
|
(cherry picked from commit 72a704d2e2b06bfedc4f1ee841814f983fc34baa)
|
|
|
|
|
|
suricata: T751: Initial support for suricata
|
|
Remove `service upnp` as it never worked as expected, nft rules do
not integrated and custom patches do not seem like a suitable
solution for now.
Security:
UPnP has been historically associated with security risks due to its automatic
and potentially unauthenticated nature.
UPnP devices might be vulnerable to unauthorized access or exploitation.
|
|
|
|
|
|
|
|
|
|
|
|
Currently VyOS only supports binding a service to one individual VRF. It might
become handy to have the services (initially it will be VRF, NTP and SNMP) be
bound to multiple VRFs.
Changed VRF from leafNode to multi leafNode with defaultValue: default - which
is the name of the default VRF.
|
|
Also raise op-mode error when unable to fetch data from Kea socket
|
|
|
|
|
|
This extends commit 2c3e4696b3e22 ("T2267: Versioning: Update version tag from
GIT repo") to also include release tags.
|
|
|
|
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.
|
|
dhcp: T3316: Adjust kea lease files' location and permissions
|
|
|
|
Allowing `_kea` to be a member of `vyattacfg` group allows
kea-dhcp{4,6}-server to have access to DHCP lease directory under
`/config/` and thus have ability to manipupate the leases files.
|
|
VyOS CLI command
set service ndp-proxy interface eth0 prefix 2001:db8::/64 mode 'static'
Will generate the following NDP proxy configuration
$ cat /run/ndppd/ndppd.conf
# autogenerated by service_ndp-proxy.py
# This tells 'ndppd' how often to reload the route file /proc/net/ipv6_route
route-ttl 30000
# This sets up a listener, that will listen for any Neighbor Solicitation
# messages, and respond to them according to a set of rules
proxy eth0 {
# Turn on or off the router flag for Neighbor Advertisements
router no
# Control how long to wait for a Neighbor Advertisment message before invalidating the entry (milliseconds)
timeout 500
# Control how long a valid or invalid entry remains in the cache (milliseconds)
ttl 30000
# This is a rule that the target address is to match against. If no netmask
# is provided, /128 is assumed. You may have several rule sections, and the
# addresses may or may not overlap.
rule 2001:db8::/64 {
static
}
}
|
|
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.
|
|
dhcp: T3316: Migrate dhcp/dhcpv6 server to Kea
|
|
login: T4943: use pam-auth-update to enable/disable Google authenticator
|
|
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.
|
|
|
|
Signed-off-by: Joe Groocock <me@frebib.net>
|
|
`/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.
|
|
`/etc/avahi` can be deleted since we operate with avahi-daemon
configuration in `/run/avahi-daemon`.
|
|
|
|
T2405: add Git support to commit-archive
|
|
Note that this was updated for the fix in T5739.
|
|
|
|
T5706: Add custom systemd udev rules to exclude dynamic interfaces
|
|
- Migrate to ddclient 3.11.1 and enforce debian/control dependency
- Add dual stack support for additional protocols
- Restrict usage of `porkbun` protocol, VyOS configuration structure
isn't compatible with porkbun yet
- Improve and cleanup error messages
|
|
Add custom systemd udev rules to exclude some regular and dynamic
interfaces from "systemd-sysctl" calls.
It fixes high CPU utilization (100%) as we have a lot of calls per
interface for dynamic interfaces like ppp|ipoe|sstp etc.
/lib/systemd/systemd-udevd should not be called for those interfaces
|
|
|
|
|
|
T5577: Optimized PAM configs for RADIUS/TACACS+
|
|
T5261: Add AWS load-balancing tunnel handler
|
|
In CLI we can choose authentication logic:
- `mandatory` - if TACACS+ answered with `REJECT`, authentication must be
stopped and access denied immediately.
- `optional` (default) - if TACACS+ answers with `REJECT`, authentication
continues using the next module.
In `mandatory` mode authentication will be stopped only if TACACS+ clearly
answered that access should be denied (no user in TACACS+ database, wrong
password, etc.). If TACACS+ is not available or other errors happen, it will be
skipped and authentication will continue with the next module, like in
`optional` mode.
|
|
In CLI we can choose authentication logic:
- `mandatory` - if RADIUS answered with `Access-Reject`, authentication must
be stopped and access denied immediately.
- `optional` (default) - if RADIUS answers with `Access-Reject`,
authentication continues using the next module.
In `mandatory` mode authentication will be stopped only if RADIUS clearly
answered that access should be denied (no user in RADIUS database, wrong
password, etc.). If RADIUS is not available or other errors happen, it will be
skipped and authentication will continue with the next module, like in
`optional` mode.
|
|
We need separated groups for RADIUS and TACACS+ system users because they need
to be used in PAM rules independently.
|
|
|
|
|
