Relevant PR:

Hmm, I can't seem to reproduce that name with "pdns-recursor/now 4.8.0~beta1-1pdns.bullseye amd64" or "pdns-recursor/now 4.8.0~beta2-1pdns.bullseye amd64" both in a live bare-metal system or in a VM. Both versions return pdns_recursor for me when printed from p.name(). The worker thread names (as listed from ps or htop) also don't match: "rec/web+stat" and "rec/taskThread", not that either of these are returned by p.name().

We use p.name from process_iter and it returns pdns-r/worker. That‘s why I have reverted the commits as in the latest 1.4 VyOS iso with PDNS 4.8 beta it‘s how they names the worker thread

list/lists in config and op-mode now moved to external-list

task-scheduler logic was moved into vyos.task_scheduler so it can be imported properly and used by other modules

@c-po I noticed you've reverted the commit, may I ask how you're able to reproduce the process name of 'pdns-r/worker'? Just doing the testing again with the latest build as of writing (vyos-1.4-rolling-202211060813-amd64.iso), I get:

In the PR it was requested to change the group category from lists to external-list which I'm fine with, but before I do the work to rename files and fields, does everyone agree with this change?

I've added PR https://github.com/vyos/vyos-1x/pull/1649 for review. Not tested yet, I want to know if I'm on the right path.

PR was added, I'm just trying to learn the documentation system now. Though to be frank documentation has never been my strong suit.

To be a PR, after discussion with @sdev :
https://github.com/vyos/vyos-1x/compare/current...jestabro:trace-migration

TLDR; confirmed fixed for 1.3, please backport.

FRRouting Release 8.4 Available for Download
November 7, 2022

One miracle at a time :)

PR https://github.com/vyos/vyos-1x/pull/1643

https://github.com/vyos/vyos-build/pull/277

i see it like that

I'm not sure if wildcard-address fits. The address and the mask together combine to create the wildcard.

Note: this requires https://phabricator.vyos.net/T4800 to be completed.

https://github.com/vyos/vyos-build/pull/277

See https://github.com/vyos/vyos-build/pull/276

Well, after a better code reading, the var should be named chroot_includes_dir instead of includes_chroot_dir.

Thanks for catching this

Relevant PRs:

After a few hours of digging I do think this request would be very similar to geoip, only ipv4, and ipv6 groups would be required per list.

PR adds groups to NAT: https://github.com/vyos/vyos-1x/pull/1633

Reopened, as this was never backported to 1.3; set for 1.3.3.

The enhanced linux-cp plugin (from IPng) is since 21.06 an official part of VPP, so the integration should be simple:
https://vpp.flirble.org/master/aboutvpp/releasenotes/v21.06.html#linux-control-plane-plugin-linux-cp

A patch to the WIDE DHCPv6 client seems to be sufficient to resolve this issue with respect to the way VyOS currently uses the daemon (one daemon per configured interface), PRs below:

Sure, it is fully compatible with 1.3. If no problems are found after the changes in 1.4 it must be backported.

Requires rewriting function show to python-systemd

on nightly build nftables v1.0.5 and kernel 5.15.76

As a first step, we need a wrapper script to control the start, stop and restart of socat, because socat sometimes exits automatically

As a first step, we need a wrapper script to control the start, stop and restart of socat, because socat sometimes exits automatically