summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-11-30ddclient: T5708: Fix VRF table generation in smoketestIndrajit Raychaudhuri
Ensure that the random VRF table name is 4 digits long, not 5 and stays within the the range of 100 - 65535.
2023-11-30ddclient: T5708: Additional smoketests for web-optionsIndrajit Raychaudhuri
Add additional smoketests for web-options validation. Also, format error messages to optionally include protocol name.
2023-11-30ddclient: T5708: Migration to 3.11.1 and related improvementsIndrajit Raychaudhuri
Fix execution bit for migration script
2023-11-30ddclient: T5708: Migration to 3.11.1 and related improvementsIndrajit Raychaudhuri
- 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
2023-11-30ddclient: T5708: Validate proper use of `web-options`Indrajit Raychaudhuri
`web-options` is only applicable when using HTTP(S) web request to obtain the IP address. Apply guard for that.
2023-11-30ddclient: T5708: Ensure password is always wrapped in quotesIndrajit Raychaudhuri
Migration to 3.11.1 follow-up: This should make `ddclient.conf` parsing more resilient to edge cases (particularly when `password` isn't the last option right before the host parameter). ddclient config parser applies special treatment to the password field and would unwrap the quotes automatically. Also, switch from now deprecated `use=no` to `use=disabled`.
2023-11-30ddclient: T5708: Migrate `timeout` to `interval`Indrajit Raychaudhuri
Time interval in seconds to wait between DNS updates would be a bit more intuitive as `interval` than `timeout`.
2023-11-30ddclient: T5574: Support per-service cache management for servicesIndrajit Raychaudhuri
Add support for per-service cache management for ddclient providers via `wait-time` and `expiry-time` options. This allows for finer-grained control over how often a service is updated and how long the hostname will be cached before being marked expired in ddclient's cache. More specifically, `wait-time` controls how often ddclient will attempt to check for a change in the hostname's IP address, and `expiry-time` controls how often ddclient to a forced update of the hostname's IP address. These options intentionally don't have any default values because they are provider-specific. They get treated similar to the other provider- specific options in that they are only used if defined.
2023-11-30ddclient: T5612: Additional refactoring for scripts and smoketestsIndrajit Raychaudhuri
Additional cleanup and refactoring for ddclient scripts including the smotektests.
2023-11-30ddclient: T5612: Adjust validator and completion for ddclientIndrajit Raychaudhuri
Adjust the validator and completion for ddclient to remove unsupported or superfluous protocols. Specifically, - remove 'nsupdate' protocol from the list because there is a separate config path for that protocol (rfc2136) - remove 'cloudns' protocol from the list because it has non standard configuration and is not supported by our configurator at this time
2023-11-30ddclient: T5612: Refactor zone configurationIndrajit Raychaudhuri
Refactor zone configuration to use shared XML snippet for all cases.
2023-11-30ddclient: T5612: Improve dual stack support for dyndns2 protocolIndrajit Raychaudhuri
dyndns2 protocol in ddclient honors dual stack for selective servers because of the way it is implemented in ddclient. We formalize the well known servers that support dual stack in a list and check against it when validating the configuration.
2023-11-30ddclient: T5612: Generate more reliable ddclient configIndrajit Raychaudhuri
Adjust the jinja template to avoid generating incorrect ddclient.conf in some cases. The template is reformatted to guarantee whitespacing and empty line separation.
2023-11-30ddclient: T5612: Relax hostname validation for apex and wildcard entryIndrajit Raychaudhuri
Some porvides (like 'namecheap') allow to use '@' or '*' as hostname prefix for apex and wildcard records. This commit relaxes the hostname validation to allow these prefixes.
2023-11-30ddclient: T5612: Enable TTL support for web-service based protocolsIndrajit Raychaudhuri
Enable TTL support for web-service based protocols in addition to RFC2136 based (nsupdate) protocol. Since TTL is not supported by all protocols, and thus cannot have a configuration default, the existing XML snippet `include/dns/time-to-live.xml.i` does not have common `<defaultValue>300</defaultValue>` anymore and is instead added explicitly whenever necessary.
2023-11-30ddclient: T5612: Fix VRF support for ddclient serviceIndrajit Raychaudhuri
Fix VRF support interface definition and configuration mode for ddclient to actually capture the VRF name and pass it to the template.
2023-11-30ddclient: T5573: Fix smoketest for updated ddclient configIndrajit Raychaudhuri
2023-11-30ddclient: T5573: Update config generation aligning with caching fixesIndrajit Raychaudhuri
Now that the caching fixes are in place, we can update the config to remove legacy treatment of ipv4 related properties.
2023-11-30Merge pull request #2526 from vyos/mergify/bp/sagitta/pr-2503Daniil Baturin
vxlan: T5759: change default MTU from 1450 -> 1500 bytes (backport #2503)
2023-11-27Merge pull request #2549 from vyos/mergify/bp/sagitta/pr-2546Christian Breunig
vyos.utils: T5749: fix get_vrf_members() call to iproute2 (backport #2546)
2023-11-27vyos.utils: T5749: fix get_vrf_members() call to iproute2Christian Breunig
The iproute2 master argument is used for both a VRF and a bridge device. Using this in the VRF context would retrieve and report back the wrong interfaces: Old implementation: =================== >>> from vyos.utils.network import get_vrf_members >>> get_vrf_members('br1') ['eth1', 'eth2', 'vxlan1'] >>> get_vrf_members('black') ['br1.3002', 'br1.4000', 'pim6reg10200'] The new implementation: ======================= >>> from vyos.utils.network import get_vrf_members >>> get_vrf_members('br1') [] >>> get_vrf_members('black') ['br1.3002', 'br1.4000', 'pim6reg10200'] (cherry picked from commit e02546655adefe1a6fb3660402e697f872d3ffe7)
2023-11-27Merge pull request #2545 from vyos/mergify/bp/sagitta/pr-2544Christian Breunig
smoketest: T5783: check for any abnormal daemon termination (backport #2544)
2023-11-27smoketest: T5783: check for any abnormal daemon terminationChristian Breunig
We need to ensure when stressing FRR with the smoketests that no unexpected crash happens. We simply verify the PID of the individual FRR daemons. (cherry picked from commit 080e117884196136cd63e5d312ff43fba15f7182)
2023-11-23Merge pull request #2534 from c-po/backport-pr-2522Christian Breunig
https api: T5772: check if keys are configured unless PAM auth is enabled for GraphQL (backport #2522)
2023-11-23https api: T5772: check if keys are configuredDaniil Baturin
unless PAM auth is enabled for GraphQL (cherry picked from commit 8c450ea7f538beb0b2cd21d35c05d18db49a1802)
2023-11-22Merge pull request #2529 from vyos/mergify/bp/sagitta/pr-2527Daniil Baturin
pppoe: T5630: make MRU default to MTU if unspecified (backport #2527)
2023-11-22pppoe: T5630: make MRU default to MTU if unspecifiedChristian Breunig
This fixes the implementation in e062a8c11 ("pppoe: T5630: allow to specify MRU in addition to already configurable MTU") and restores the bahavior that MRU defaults to MTU if MRU is not explicitly set. This was the behavior in VyOS 1.3.3 and below before we added ability to define the MRU value. (cherry picked from commit ffd7339e2ea3eafdd97ac0763ca4a3913fe71bf3)
2023-11-22vxlan: T5759: change default MTU from 1450 -> 1500 bytesChristian Breunig
Found an odd behavior on Linux and the VyOS CLI implementation. If adding VXLAN interfaces using iproute2 the MTU differs depending on the creation syntax: ip -4 link add vxlan100 type vxlan dstport 4789 external df unset tos inherit \ ttl 16 nolearning vnifilter local 172.16.33.201 ip -4 link add vxlan200 type vxlan id 200 dstport 4789 local 172.16.33.201 dev eth0 ip -6 link add vxlan300 type vxlan id 300 dstport 4789 local 2001:db8:1::1 dev eth0 132: vxlan300: <BROADCAST,MULTICAST> mtu 1430 qdisc noop state DOWN group default qlen 1000 link/ether 4e:fb:e3:f5:d9:59 brd ff:ff:ff:ff:ff:ff 133: vxlan200: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000 link/ether 0e:4e:f4:76:59:3f brd ff:ff:ff:ff:ff:ff 134: vxlan100: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ba:b6:b7:0c:b1:37 brd ff:ff:ff:ff:ff:ff VyOS always sets a default MTU of 1450 bytes which is correct for IPv4 p2p links or multicast, but invalid for IPv6 p2p. Also this will break EVPN deployments as ethernet bridges with MTU < 1500 bytes are less fun. Increase default MTU to 1500 bytes. Migrate old configurations to use 1450 bytes if not specified otherwise on the CLI. (cherry picked from commit 4a163b016333e58fee9d6ec6b53a09e0160b3213)
2023-11-22Merge pull request #2525 from vyos/mergify/bp/sagitta/pr-2499Christian Breunig
vxlan: T5753: add support for VNI filtering (backport #2499)
2023-11-22vxlan: T5753: add support for VNI filteringChristian Breunig
In a service provider network a service provider typically supports multiple bridge domains with overlapping vlans. One bridge domain per customer. Vlans in each bridge domain are mapped to globally unique VXLAN VNI ranges assigned to each customer. Without the ability of VNI filtering, we can not provide VXLAN tunnels with multiple tenants all requiring e.g. VLAN 10. To Test: set interfaces vxlan vxlan987 parameters external set interfaces vxlan vxlan987 source-interface eth0 set interfaces vxlan vxlan987 parameters vni-filter set interfaces vxlan vxlan987 vlan-to-vni 50 vni 10050 set interfaces vxlan vxlan987 vlan-to-vni 51 vni 10051 set interfaces vxlan vxlan987 vlan-to-vni 52 vni 10052 set interfaces vxlan vxlan987 vlan-to-vni 53 vni 10053 set interfaces vxlan vxlan987 vlan-to-vni 54 vni 10054 set interfaces vxlan vxlan987 vlan-to-vni 60 vni 10060 set interfaces vxlan vxlan987 vlan-to-vni 69 vni 10069 set interfaces bridge br0 member interface vxlan987 Add new op-mode command: show bridge vni Interface VNI ----------- ----------- vxlan987 10050-10054 vxlan987 10060 vxlan987 10069 (cherry picked from commit 35f6033d21053fa420e837f157cd9377a4ccd26a)
2023-11-22Merge pull request #2523 from vyos/mergify/bp/sagitta/pr-2519Viacheslav Hletenko
http: T5762: rename "virtual-host listen-port" -> "virtual-host port" (backport #2519)
2023-11-22http: T5762: rename "virtual-host listen-port" -> "virtual-host port"Christian Breunig
This complements commit f5e43b136 ("http: T5762: api: make API socket backend communication the one and only default") so we have a consistent port CLI node across VyOS components. (cherry picked from commit 0e885f1bf01424130b6876e769cc42612b19351b)
2023-11-22Merge pull request #2521 from vyos/mergify/bp/sagitta/pr-2516Daniil Baturin
T5767: HTTPS API add reboot and poweroff endpoints (backport #2516)
2023-11-22Merge pull request #2520 from vyos/mergify/bp/sagitta/pr-2518Daniil Baturin
T5770 Enable MACsec encryption stanza (backport #2518)
2023-11-22Merge pull request #2517 from nicolas-fort/T5419-FT-SagittaDaniil Baturin
T5419: firewall: backport firewall flowtable to Sagitta.
2023-11-22Merge pull request #2510 from vyos/mergify/bp/sagitta/pr-2506Daniil Baturin
dhcp-client: T5760: add CLI option to pass user-class parameter (backport #2506)
2023-11-21T5767: HTTPS API add reboot and poweroff endpointsViacheslav Hletenko
Add ability to reboot and poweroff the system via API curl -k --location --request POST 'https://vyos/reboot' \ --form data='{"op": "reboot", "path": ["now"]}' \ --form key='apikey' curl -k --location --request POST 'https://vyos/poweroff' \ --form data='{"op": "poweroff", "path": ["now"]}' \ --form key='apikey' (cherry picked from commit 36f3c329c2df0e78f2f5da933d9729a872fb2a11)
2023-11-21smoketest: macsec: T5770: fix NameError: name 'cipher' is not definedChristian Breunig
(cherry picked from commit 02a3e26e88f0ac3c7368e288769bfed38b41df46)
2023-11-21macsec: T5770: enable iproute2 "encrypt on" stanzaGiga Murphy
(cherry picked from commit a7a90e81ad03ec33acb32beeab71dbd5f27a2044)
2023-11-21T5419: firewall: backport firewall flowtable to Sagitta.Nicolas Fort
2023-11-21Merge pull request #2512 from zdc/T5577-sagittaChristian Breunig
PAM: T5577: Backported PAM settings from circinus
2023-11-20Merge pull request #2514 from vyos/mergify/bp/sagitta/pr-2511Christian Breunig
T5763: fix imprecise check for remote file name (backport #2511)
2023-11-20Merge pull request #2515 from vyos/mergify/bp/sagitta/pr-2508Christian Breunig
http: T5762: api: make API socket backend communication the one and only default (backport #2508)
2023-11-20http: T5762: api: make API socket backend communication the one and only defaultChristian Breunig
Why: Smoketests fail as they can not establish IPv6 connection to uvicorn backend server. https://github.com/vyos/vyos-1x/pull/2481 added a bunch of new smoketests. While debugging those failing, it was uncovered, that uvicorn only listens on IPv4 connections vyos@vyos# netstat -tulnp | grep 8080 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN - As the CLI already has an option to move the API communication from an IP to a UNIX domain socket, the best idea is to make this the default way of communication, as we never directly talk to the API server but rather use the NGINX reverse proxy. (cherry picked from commit f5e43b1361fb59a9c260739bdb28729d5119507c)
2023-11-20T5763: fix imprecise check for remote file nameJohn Estabrook
(cherry picked from commit fe9b08665367b8e7d9b906a0760d44efc9b5cafb)
2023-11-20init: T5577: clear mandatory and optional RADIUS/TACACS PAM settingsChristian Breunig
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.
2023-11-20pam: T5577: Improved PAM configs for RADIUS and TACACS+zsdc
After sources analysis, we found the next possible return statuses for PAM modules: 1. pam_tacplus Auth: - PAM_AUTH_ERR - PAM_AUTHINFO_UNAVAIL - PAM_AUTHTOK_ERR - PAM_BUF_ERR - PAM_CRED_INSUFFICIENT - PAM_PERM_DENIED - PAM_SUCCESS - PAM_USER_UNKNOWN Account: - PAM_AUTH_ERR - PAM_AUTHINFO_UNAVAIL - PAM_PERM_DENIED - PAM_SUCCESS - PAM_USER_UNKNOWN Session: - PAM_AUTHINFO_UNAVAIL - PAM_SESSION_ERR - PAM_SUCCESS - PAM_USER_UNKNOWN 2. pam_radius_auth Auth: - PAM_ABORT - PAM_AUTH_ERR - PAM_AUTHINFO_UNAVAIL - PAM_AUTHTOK_ERR - PAM_BAD_ITEM - PAM_BUF_ERR - PAM_CONV_AGAIN - PAM_CONV_ERR - PAM_IGNORE - PAM_NO_MODULE_DATA - PAM_PERM_DENIED - PAM_SUCCESS - PAM_SYSTEM_ERR - PAM_USER_UNKNOWN Account: - PAM_SUCCESS Session: - PAM_ABORT - PAM_AUTHINFO_UNAVAIL - PAM_BAD_ITEM - PAM_BUF_ERR - PAM_CONV_AGAIN - PAM_CONV_ERR - PAM_IGNORE - PAM_NO_MODULE_DATA - PAM_PERM_DENIED - PAM_SUCCESS - PAM_SYSTEM_ERR - PAM_USER_UNKNOWN PAM configurations were replaced with tuned versions to take this into account.
2023-11-20TACACS: T5577: Added `mandatory` and `optional` modes for TACACS+zsdc
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.
2023-11-20RADIUS: T5577: Added `mandatory` and `optional` modes for RADIUSzsdc
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.
2023-11-20groups: T5577: Added `radius` and `tacacs` groupszsdc
We need separated groups for RADIUS and TACACS+ system users because they need to be used in PAM rules independently.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-23 21:30:23 +0000