Looks like it's already been implemented here:
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Wed, Dec 10
Tue, Dec 9
Mon, Dec 8
@hesham, would you like to add a PR?
Sun, Dec 7
Fri, Dec 5
In T4001#173519, @Viacheslav wrote:Needs to re-check for 1.4/1.5
Thu, Dec 4
Tue, Dec 2
Mon, Dec 1
Sat, Nov 29
FRR case where there is a long explanation: https://github.com/FRRouting/frr/issues/15400
Fri, Nov 28
Wed, Nov 26
Example implementation of such a daemon:
https://github.com/vyos/vyos-1x/pull/4872
Tue, Nov 25
Mon, Nov 24
Nov 24 20:55:39 systemd[1]: Starting Cleanup of Temporary Directories... Nov 24 20:56:39 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. Nov 24 20:56:39 systemd[1]: Finished Cleanup of Temporary Directories. Nov 24 20:56:39 systemd[1]: run-credentials-systemd\x2dtmpfiles\x2dclean.service.mount: Deactivated successfully. Nov 24 20:58:53 sudo[3835]: pam_unix(sudo:session): session closed for user root Nov 24 20:58:53 systemd[1]: opt-vyatta-config-tmp-new_config_3466.mount: Deactivated successfully. Nov 24 20:58:53 sudo[3958]: vyos : TTY=pts/1 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/bin/mv /tmp/config.boot.3949 /opt/vyatta/etc/config/archive/config.boot Nov 24 20:58:53 sudo[3958]: pam_unix(sudo:session): session opened for user root(uid=0) by vyos(uid=1003) Nov 24 20:58:53 sudo[3958]: pam_unix(sudo:session): session closed for user root Nov 24 20:58:53 sudo[3961]: vyos : TTY=pts/1 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/sbin/logrotate -f -s /opt/vyatta/etc/config/archive/lr.state /opt/vyatta/etc/config/archive/lr.conf Nov 24 20:58:53 sudo[3961]: pam_unix(sudo:session): session opened for user root(uid=0) by vyos(uid=1003) Nov 24 20:58:53 sudo[3961]: pam_unix(sudo:session): session closed for user root Nov 24 20:58:53 commit[3965]: Successful change to active configuration by user vyos on /dev/pts/1
Fri, Nov 21
Wed, Nov 19
The "issue" why it's blocking for a very long time it the TACACS servers are unreachable is:
Tue, Nov 18
Mon, Nov 17
This could be done with systemd-cryptenroll and LUKS while bound to a TPM. Also you could bind it to a PKCS11 token (Yubikey) with a no touch and no pin policy to allow auto booting. (Not recommending FIDO2 because it always requires user presence)
Seems this should be closed.
Nov 12 2025
I think we can close this issue.
It seems as FRR has a special implementation of regex, even when they say POSIX 1003.2 regex compatibility because some things are different, like the _ character.
Nov 11 2025
Based on the comments above, I am moving this to 'wishlist' for consideration after the legacy backend is retired. My expectation is that we will not want to drop the invariant as such, however, we will be in a position to consider refinements of the model, radical or conservative, once freed from the legacy constraints.
It seems more like a problem of FRR.
I went through the Jinja template for that part and in my case it would generate
Nov 6 2025
Nov 4 2025
Nov 2 2025
Oct 28 2025
Oct 26 2025
The assumption stated in the description is true, as discussed with @c-po at the time. The following invariant is fundamental to the operation of the commit algorithm (legacy and modern) and the config daemons: during a commit, the active and proposed configs are fixed --- no updates during the commit are reflected in any script's config dict, including those called by config dependencies. Evolution of this model will require a refinement of config dependencies, which is not possible until the legacy backend is retired.
Oct 22 2025
SHIM accepted by review-board
Oct 19 2025
Oct 15 2025
There are several errors.
- listen_address instead of address
- `listen-address could has multiple values
vyos@r14# run show conf com | match haproxy
set load-balancing haproxy backend bk01 server 192.0.2.5 address '192.0.2.5'
set load-balancing haproxy backend bk01 server 192.0.2.5 port '993'
set load-balancing haproxy service wan-993 listen-address 192.0.2.2
set load-balancing haproxy service wan-993 port '993'
[edit]
vyos@r14#
[edit]
vyos@r14# set load-balancing haproxy service wan-993 listen-address 192.168.122.14
[edit]
vyos@r14# commit
[ load-balancing haproxy ]
{'backend': {'bk01': {'balance': 'round-robin',
'mode': 'http',
'server': {'192.0.2.5': {'address': '192.0.2.5',
'port': '993'}}}},
'global_parameters': {'ssl_bind_ciphers': ['ecdhe-ecdsa-aes128-gcm-sha256',
'ecdhe-rsa-aes128-gcm-sha256',
'ecdhe-ecdsa-aes256-gcm-sha384',
'ecdhe-rsa-aes256-gcm-sha384',
'ecdhe-ecdsa-chacha20-poly1305',
'ecdhe-rsa-chacha20-poly1305',
'dhe-rsa-aes128-gcm-sha256',
'dhe-rsa-aes256-gcm-sha384'],
'tls_version_min': '1.3'},
'pki': {},
'service': {'wan-993': {'listen_address': {'192.0.2.2': {},
'192.168.122.14': {}},
'mode': 'http',
'port': '993'}},
'timeout': {'check': '5', 'client': '50', 'connect': '10', 'server': '50'}}tmp_address = front_config.get('address', None)shouldn't this be listen_address instead of address on line 75?
Something is wrong with this check
After my workaround described above:
vyos@vyos# sudo netstat -tulpn | grep 993 tcp 0 0 192.0.2.1:993 0.0.0.0:* LISTEN 513 01/haproxy tcp6 0 0 2001:0db8::25:993 :::* LISTEN 784 61/conmon
and then when configuring the other way around:
edit] vyos@vyos# set load-balancing haproxy service wan-993 port 994 [edit] vyos@vyos# commit [edit] vyos@vyos# set load-balancing haproxy service wan-993 port 993 [edit] vyos@vyos# commit [ load-balancing haproxy ] TCP port "993" is used by another service [[load-balancing haproxy]] failed Commit failed [edit] vyos@vyos# sudo netstat -tulpn | grep 993 tcp6 0 0 2001:0db8::25:993 :::* LISTEN 784 61/conmon
sudo netstat -tulpn | grep 993
Oct 13 2025
Oct 7 2025
Oct 6 2025
For the circinus works as expected
vyos@r14:~$ show version Version: VyOS 1.5-stream-202510060458 Release train: circinus Release flavor: generic
Working on the latest rolling (checked VyOS 2025.10.05-0020-rolling)
VyOS config:
set container name radius allow-host-networks set container name radius image 'dchidell/radius-web' set container name radius volume accel destination '/usr/share/freeradius/dictionary.accel' set container name radius volume accel source '/usr/share/accel-ppp/radius/dictionary.accel' set container name radius volume clients destination '/etc/raddb/clients.conf' set container name radius volume clients source '/config/containers/radius/clients' set container name radius volume dictionary destination '/usr/share/freeradius/dictionary' set container name radius volume dictionary source '/config/containers/radius/dictionary' set container name radius volume users destination '/etc/raddb/users' set container name radius volume users source '/config/containers/radius/users' set service pppoe-server access-concentrator 'ACN' set service pppoe-server authentication mode 'radius' set service pppoe-server authentication radius server 192.168.122.14 key 'vyos-secret' set service pppoe-server client-ip-pool FIRST range '100.64.0.0/18' set service pppoe-server client-ipv6-pool IPv6-POOL delegate 2001:db8:8003::/48 delegation-prefix '56' set service pppoe-server client-ipv6-pool IPv6-POOL prefix 2001:db8:8002::/48 mask '64' set service pppoe-server default-ipv6-pool 'IPv6-POOL' set service pppoe-server default-pool 'FIRST' set service pppoe-server gateway-address '100.64.0.1' set service pppoe-server interface eth1 combined set service pppoe-server interface eth1.23 set service pppoe-server log level '5' set service pppoe-server name-server '1.1.1.1' set service pppoe-server name-server '1.0.0.1' set service pppoe-server ppp-options disable-ccp set service pppoe-server ppp-options ipv6 'allow' set service pppoe-server session-control 'disable'
RADIUS users
client-1 Cleartext-Password := "client-1"
Service-Type = Framed-User,
Accel-VRF-Name = "red",
Framed-IP-Address = 10.0.0.11,
Stateful-IPv6-Address-Pool = "IPv6-POOL",
Delegated-IPv6-Prefix-Pool = "IPv6-POOL",
Framed-Route = "100.64.0.11/32 10.0.0.11 1",
Framed-Protocol = PPPOct 3 2025
Oct 1 2025
To work around this at present I am setting the following additional configuration to prevent losing IPv6 connectivity frequently:
I just built a new image with the driver enabled, and it no longer causes kernel panic on my setup.
Sep 29 2025
Sorry, another followup, rather than duplicating the control logic in both interface.py and in vyos-netplug-dhcp-client (and leaving yourself open to another logic divergence in future), you could consider just checking for presence of the config file /var/run/dhcp6c.eth0.conf in vyos-netplug-dhcp-client when determining if the service should restart. That file only exists if dhcp6c is required on that specific interface, and that means the logic for dhcp6c presence is determined only by interface.py and vyos-netplug-dhcp-client just follows its lead.
Relevant section of interface.py: https://github.com/vyos/vyos-1x/blob/5845c4b1c50bc0335284cfb3306e0a91de3efd40/python/vyos/ifconfig/interface.py#L1822-L1824