I think a warning is better than to block it from being set, specially since the workaround to load it through already existing config still remains.

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

sorry for the late reply.You don't need any special commands. The only thing you have to set is the proxy and the commit archive.

@molocho see the tasks T5301 T5154 and https://chrony-project.org/doc/4.3/chrony.conf.html#bindaddress

IMO it would make sense to show the DUID since that has to be passed for static mappings and is also configured on the client side

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

@thannaske it would be very nice if you could re-check now this with VyOS 1.5. It should be fixed by https://github.com/vyos/vyos-cloud-init/commit/70304ff90d931265cb736ace692967242c9b9729

Question as I don’t know the projects’ history: the Python ipaddress library seems to offer the features of ipaddrcheck plus some additional nice to haves. Is a migration from ipaddrcheck to ipaddress being considered?

This expected behavior due to change from ntpd to chrony
@rob needs to update documentation for 1.4 to reflect changes

Believe this task can be closed the PRs for Sagitta and Current were merged:
Merged PR in Current: https://github.com/vyos/vyos-1x/pull/3307
Merged PR in Sagitta: https://github.com/vyos/vyos-1x/pull/3395

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

Note that T5996 has been backported and a full explanation is to be found in the previous comment. Close as resolved, with the needed workaround for earlier images.

Can I claim this? will submit a Draft PR for review, I have it resolved (see test output below)

This was a worthwhile investigation, with the goal of using Cython as a method of easily wrapping the standard netlink headers. Although workable, it appeared more trouble than it's worth, as one still has to cheat to navigate e.g. pass by reference (1), and limitations of Cython at the time (2). A much better approach would be a standard Python extension module ... set to 'on hold' for reference and until we have a plan for development, as has been recently discussed.

As c-po mentioned above, this was an interesting idea that was not workable; it was subsumed by the investigations in T3876.

Is there any movement on implementing this? As per T2760 this is the only way to resolve IPsec on dynamic ip's

In T5835#187963, @dylanneild wrote:

If I had to recommend anything, it'd be that VyOS just remove UPnP completely. What is included doesn't work (or didn't when I last checked) and the attitude from the VyOS community seems to be that it's not wanted/needed anyways.

Awesome. Good luck.

Sorry, but seems like he was right. If the build process or devs with power weren't toxic I'd jump on preparing a PR for fixing the firewall config issue, but both being the case, I'd rather not waste my time contributing to a burning ship.

Could this perhaps be extended into something like this in the help of the command and documentation?