Age | Commit message (Collapse) | Author |
|
(cherry picked from commit 4c4c2b1f8a58398798f20c252bde80461320d330)
|
|
This fixes sending packets to uacctd using a socket.
(cherry picked from commit 7a0af0d00bae9179c89155e4b2e6ce94abb29c05)
|
|
'generate tech-support archive' moved to vyos-1x.
Output of 'show tech-support report' command is added to archive.
The default location of the archive is moved to '/tmp'.
The script is rewritten to Python.
(cherry picked from commit 65911b17340a7894aba973113d83ab43964bbf99)
|
|
T5165: Implement policy local-route source and destination port (backport #2342)
|
|
pmacct daemons have one very important specific - they handle control signals in
the same loop as packets. And packets waiting is blocking operation.
Because of this, when systemctl sends SIGTERM to uacctd, this signal has no
effect until uacct receives at least one packet via nflog. In some cases, this
leads to a 90-second timeout, sending SIGKILL, and improperly finished tasks.
As a result, a working folder is not cleaned properly.
This commit contains several changes to fix service issues:
- add a new nftables table for pmacct with a single rule to get the ability to
send a packet to nflog and unlock uacctd
- remove PID file options from the uacctd and a systemd service file. Systemd
can detect proper PID, and PIDfile is created by uacctd too late, which leads
to extra errors in systemd logs
- KillMode changed to mixed. Without this, SIGTERM is sent to all plugins and
the core process exits with status 1 because it loses connection to plugins too
early. As a result, we have errors in logs, and the systemd service is in a
failed state.
- added logging to uacctd
- systemctl service modified to send packets to specific address during a service
stop which unlocks uacctd and allows systemctl to finish its work properly
(cherry picked from commit e364e9813b6833f6b108e7177ef7ea2d9e7bac33)
|
|
T5489: Change default qdisc from 'fq' to 'fq_codel' (backport #2349)
|
|
Add `policy local-route` source and destination port
set policy local-route rule 23 destination port '222'
set policy local-route rule 23 protocol 'tcp'
set policy local-route rule 23 set table '123'
set policy local-route rule 23 source port '8888'
% ip rule show prio 23
23: from all ipproto tcp sport 8888 dport 222 lookup 123
(cherry picked from commit ff43733074675b94ce4ead83fe63870b6cf953c5)
|
|
(cherry picked from commit 93d2ea7d635c7aa5acf3000654393ea48b7c6405)
|
|
(cherry picked from commit 7d597a6dca15cb592230b349ef7ef565f258cf43)
|
|
(cherry picked from commit ac1bd7c2f69e058f54084decbfe6b6d329df6462)
|
|
(cherry picked from commit e357258e645cf85de0035d4ecfbf99db4dd90f7e)
|
|
(cherry picked from commit 27605426a4ad613f45d36e7db5b1664dc3192981)
|
|
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.
(cherry picked from commit 12069d5653034b46a47430353c3867b3678c196f)
|
|
This reverts commit 074870dad33d80e78128736f9e89bdfa1a0e08fd.
|
|
During system startup the system-login.py script is invoked by vyos-router
systemd service. As there is no complete configuration available at this
point in time - and the sole purpose of this call is to reset/re-render
the system NSS/PAM configs back to default - it accidently also deleted the
local useraccounts.
Once the VyOS configuration got mounted, users got recreated in alphabetical
order and thus UIDs flipped and the /home suddenely belonged to a different
account.
This commit prevents any mangling with the local userdatabase during VyOS
bootup phase.
(cherry picked from commit 64d323299586da646ca847e78255ff2cd8464578)
|
|
(cherry picked from commit 646f08fc5a302e08aad90af3fa0ee32e138ee585)
|
|
vyos@vyos:~$ show system login users
Username Type Locked Tty From Last login
---------- ------ -------- ----- ------------- ------------------------
vyos vyos False pts/0 172.16.33.139 Mon Oct 2 20:42:24 2023
(cherry picked from commit 80f08af76db0ccee4d6dc1a99b6d8d90884fa33f)
|
|
Migrate policy local-route <destination|source> to node address
replace 'policy local-route{v6} rule <tag> destination|source <x.x.x.x>'
=> 'policy local-route{v6} rule <tag> destination|source address <x.x.x.x>'
(cherry picked from commit 9f7a5f79200782f7849cab72f55a39dedf45f214)
|
|
Rename avahi-daemon config file to avahi-daemon.conf.j2 to match the
convention used by other config files.
(cherry picked from commit 3a3123485f2ea7b253caa1c49f19c82a0eaa0b37)
|
|
This commit adds a new configuration option to the mDNS repeater service
to allow controlling which IP version to use for mDNS repeater.
Additionally, publishing AAAA record over IPv4 and A record over IPv6 is
disabled as suggested.
See:
- https://github.com/lathiat/avahi/issues/117#issuecomment-1651475104
- https://bugzilla.redhat.com/show_bug.cgi?id=669627#c2
(cherry picked from commit e66f7075ee12ae3107d29efaf683442c3535e8b9)
|
|
Add option `protocol` for policy local-route
set policy local-route rule 100 destination '192.0.2.12'
set policy local-route rule 100 protocol 'tcp'
set policy local-route rule 100 set table '100'
(cherry picked from commit 96b8b38a3c17aa08fa964eef9141cf89f1c1d442)
|
|
Also includes an update to smoketest to verify
(cherry picked from commit 1ac230548c86d3308ff5b479b79b0e64b75a0e8a)
|
|
(cherry picked from commit 12440ea1af8e60482a6a91c1cb04dcb86d7f4a68)
|
|
(cherry picked from commit 0869b91c0b15ddedd72b4d0e1475c52eb45994f0)
|
|
firewall: T5160: Remove zone policy op-mode (backport #2308)
|
|
(cherry picked from commit 9b9b37e9cbb225eaacac2ad8cb03bef735fed117)
|
|
Add op-mode command `generate firewall rule-resequence`
Generates output with new sequences for firewall rules
set firewall ipv4 input filter rule 1 action 'accept'
set firewall ipv4 input filter rule 1 description 'Allow loopback'
$ generate firewall rule-resequence start 10 step 10
set firewall ipv4 input filter rule 10 action 'accept'
set firewall ipv4 input filter rule 10 description 'Allow loopback'
(cherry picked from commit 7ad1e8c7d3440046dce2ffa7bcb70a38bfddc298)
|
|
(cherry picked from commit 2d3f3297b575f88662495e14a7c7324ff73b6bfc)
|
|
(cherry picked from commit 42736111facf08ac37b86e6fc3cbd395aab166bc)
|
|
init: T5239: configure system hostname prior to FRR startup (backport #2289)
|
|
(cherry picked from commit 4bbbaab60d56bfd6f3a145378027642b4c47adee)
|
|
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.
(cherry picked from commit ac21a4e69fac27504b62927a20d0a6a273abb034)
|
|
(cherry picked from commit 56d3f75de487c1dcfd075cf7b65cb16b6501d0ca)
|
|
T5561: nat: inbound|outbound interface should not be mandatory (backport #2253)
|
|
ddclient: T5585: Fix file access mode for dynamic dns configuration (backport #2270)
|
|
T5575: ARP/NDP table-size isnt set properly (backport #2255)
|
|
AgentX does not work stable. From time to time we see the system
service crashing/degrading if something is wrong with SNMP from
util net-snmp.
We should disable it by default and enable it only if configured.
set high-availability vrrp snmp
(cherry picked from commit 47875457cd8b176f7f23a3141175d745aeb14d8a)
|
|
After commit 976f82785 ("T5575: ARP/NDP table-size isnt set properly") the
system bootup process got interrupted as both system-ip.py and system-ipv6.py
tried to talk to FRR which was yet not started.
This has been fixed by using a conditional path to only execute when FRR service
has been enabled. This is safe to do as the initial commit call will has FRR
service running and the path will be executed.
(cherry picked from commit 22d5cd42f082fb11060edc51128f0b246198d2c1)
|
|
ddclient.conf file is expected to have permission 600. We need to set
the permission explicitly while creating the file.
(cherry picked from commit 7a66413d6010485dd913832f54167bce38c12250)
|
|
while configuring dNAT|sNAT rule
(cherry picked from commit ec5437913e489f40fea6bab89a6bb5f565cd1ab7)
|
|
frr: T5239: fix process startup order (backport #2245)
|
|
(cherry picked from commit 976f827859102a4e453b38bc6d2a628c66c9b582)
|
|
(cherry picked from commit 9391fc273ce95ff92a6b40b2dee4a688d3048f9f)
|
|
T5480: Ability to disable SNMP for keepalived service VRRP
|
|
- 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.
(cherry picked from commit df74a09b80df0c2ec769a10ef4f7bac01f50eb2d)
|
|
The `rule` key could be not exists in the entry of the dictionary
for examppe `{'default_action': 'drop'}`
Fix it
(cherry picked from commit 9daac1632df96b6d2089244e3c7a7b42ae682eb9)
|
|
(cherry picked from commit af398c51f7d06cdf582b347a35b1e5c867aaea58)
|
|
T5533: Fix for vrrp dict key if virtual-server is used
|
|
(cherry picked from commit 79a46675b031a4edc0ea925a45066077c0804b9b)
|
|
FRR supports a new way of configuring VLAN-to-VNI mappings for EVPN-VXLAN, when
working with the Linux kernel. In this new way, the mapping of a VLAN to a VNI
is configured against a container VXLAN interface which is referred to as a
'Single VXLAN device (SVD)'.
Multiple VLAN to VNI mappings can be configured against the same SVD. This
allows for a significant scaling of the number of VNIs since a separate VXLAN
interface is no longer required for each VNI.
Sample configuration of SVD with VLAN to VNI mappings is shown below.
set interfaces bridge br0 member interface vxlan0
set interfaces vxlan vxlan0 external
set interfaces vxlan vxlan0 source-interface 'dum0'
set interfaces vxlan vxlan0 vlan-to-vni 10 vni '10010'
set interfaces vxlan vxlan0 vlan-to-vni 11 vni '10011'
set interfaces vxlan vxlan0 vlan-to-vni 30 vni '10030'
set interfaces vxlan vxlan0 vlan-to-vni 31 vni '10031'
(cherry picked from commit 7f6624f5a6f8bd1749b54103ea5ec9f010adf778)
|