Breaking user existing configs should be a no-no. If the options can be used that way under Linux, then we should not restrict it if it is not invalid. If we intend to prevent it then we would need a way to warn users clearly and we have no framework for this ATM.

Need to add max MTU to operational mode and create a new validator using it and applying it to the xml. The only question being if the information is always available.

I see no issue with the proposed solution.

Is this related to T2619? It sure looks like it to me.

A first implementation is already live with the console-server https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/service_console-server.py

Thinking on this, should ("source-address" / "remote") and ("group" / "source-interface") be mutually exclusive? I cant think of any reason you would want both set to be setup on the same interface, I'm not even sure you can have both. Usually ("source-address" / "remote") would be used for unicast setups, and ("group" / "source-interface") for multicast. Seems like an either or, but not both, setup would be ideal.

This would have been fixed for isc-dhcp-client if T2590 hadn't happened in the process of me working on it, now it requires writing a new dhclient script for the WIDE client.

Fixed as part of T2486

Fixed as part of T2486

The above PR419 did not fix the issue as a wrong pdns-recursor process name was used (its real name is 'pdns-rec/worker'). It was fixed as part of T2486.

That's great, I like the config syntax. What does the interface alias do regarding the display? Maybe it could be read from the interface description? Then again the display name needs to be short as the displays are small and the interface description can be longer. Maybe default to reading the alias from the interface description and override it with the display alias.
For starting services in 1.3 we use systemd, it's simple to create new service files in src/systemd that will be put in /lib/systemd/system. Just make sure they're started manually by the config script and not as part of a target (just creating a service file without the Install section should ensure that).

FWIW, this integration package is coming along nicely. I was able to create the XML CLI. The python code is kept to a minimum by passing a dictionary of the Config to the template engine "render". At this point, I can generate the proper LCDd.conf and lcdproc.conf based on the CLI. I now need to work on start/stop/restart as well as (basic) config validation. I have nothing for lcdexec/menu this far.

OK, another approach question.

I feel @Dmitry has more experience here from past topics. I hope you do not mind the reassignment.

Or use a VRF T31, closing - feel free to reopen if you think this was done wrongly.

Should be resolved via T2569

Resolved via T2569

Works as expected, tested on 1.3-rolling-202006201113

EDIT: EDITED from original for clarity

LOL - I could have commited :-) Thanks !

Added code received via Slack ;) extreme programming.

@thomas-mangin I hope you can have a look here. Thanks!

Picking up on the build issue

VyOS 1.3 uses nftables for performing NAT operations. It might be possible that there is a bug in the new code. It would be interesting to get a copy of your sudo iptables-save -t nat and sudo iptables-save output on 1.2 so we can check it in 1.3.

I can confirm that your change as of VyOS 1.3-rolling-202006200117 fixed the problem.

I will do that tonight.

The next rolling ISO will have a fix for the migrations script. It would be nice if you could re-upgrade from 1.2 to additionally verify the fix besides me.

Version: VyOS 1.2.5+
Release Train: crux