If it reappears, please reopen.

Could anyone test if it's still reproducible?

Sorry for a very late reply. The script-template already takes care of everything, there is no need to use vyatta-cfg-cmf-wrapper.

With migration to nftables this is a very real possibiliy.

1.3 rolling supports it already, see https://github.com/vyos/vyos-1x/blob/current/src/services/vyos-http-api-server#L195

I wonder if it may be a good idea to make reboot and poweroff commands create a file in our own format.

The rolling release images are not signed. Never were, though I hope at some point they will be. But then again, automatically signing images, with a key stored on a public-facing machine, without a password... kinda defeats the purpose of signing.

Making it a default can make sense, if everyone agrees.

I'd go with approach 3, if 2 is too complex. Have a predefined set of appliances that can be configured by a single option. For all other scenarios, one of:
a) have the user supply the path to a file in /config that the script will include in lcdd.conf as-is (as including a multi-line string in the config directly is very awkward and unreadable).
b ) we could for example make a /config/lcdproc directory, containing a template conf file that would be used if the user selected that option in config, still starting the daemon via the config.
c) or split out the individual driver sections with defaults (as in lcdd.conf) into many files in /config/lcdproc/$drivername.conf that can be edited by the user, and have a config option that selects which driver to use, and have the user edit the file to configure it.

OK, question on the approach. Looking at LCDd.conf (check the link above), there are a few server options, but TONS of individual driver options. Doing some sort of complete support in VYOS would be fairly straightforward, but would lead to a massive XML file. The lcdproc project has been around a while, so there are many different devices that are supported, most possibly somewhat historic or even one-off. We can (artificially) categorize them in 2 groups:

Works as expected!

Can I propose this do as default but keep the possibility redefine replace option?

This does not work in VyOS 1.2.5 either.

What should be displayed in this output?

Revising this since I nailed down the issue.

Perfect. Thank You! I was against this feature the first time bit now I need it, too ;)

@c-po Yes, sorry. This is my fault, I forgot that you told me already this.
Done, PR https://github.com/vyos/vyos-1x/pull/464

Can confirm. This bug is corrected in the the latest rollings (for at least a month or more)

The boot config load mechanism has been changed by @jestabro which possibly led to resolution of this bug

@Dmitry I accidently merged this to quick. Now every RADIUS instance has a peiority node bit irs only evaluates foe system login. Can dou please fix the XML definitions to only have this for system login?

Feature now also in crux version ob libpam-radius.

Add PR for rolling https://github.com/vyos/vyos-1x/pull/462

There is another use of is_tag/is_leaf in python/vyos/validate.py is_member, as it can work on both bridge and bond members, and they have different syntax for member interfaces. It would only be possible to hardcode each case and remove the use of is_*

In the latest rolling, I don't see this bug.

VyOS 1.3-rolling-202006170117

Hmmm is it the fact I have a remote syslog configured that triggers this bug?
I didn't realise that, I'll have to remove it and see if it helps.
It's very frustrating not having the firewall logs available to view.

For what little to no weight my opinion matters, I also agree that this should be backported to Crux.
As I've bashed my head into it testing :-)

Implementation steps:

1. Add $INCLUDE dictionary.rfc4849 to /usr/share/accel-ppp/radius/dictionary file
2. Add required modules for use ip-pre-up/ip-up/ip-down scripts

[modules]
sigchld
pppd_compat

And pppd_compat params

[pppd-compat]
verbose=1
ip-pre-up=/path/to/ip-pre-up 
radattr-prefix=/var/run/radattr

3. Create ip-pre-up/ip-down script which will get configured firewall names and rules from CLI or supported script

Note: When ip-pre-up return 1 then the session will not start like described in https://tools.ietf.org/html/rfc4849

Fixed https://github.com/vyos/vyos-1x/pull/460.

Does not possible to disable ccp in l2tp

vyos@RTR1# set vpn l2tp remote-access ccp-disable 
[edit]
vyos@RTR1# commit
[ vpn l2tp ]
VyOS had an issue completing a command.

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

By the way, shouldn't we better talk through slack? : )

I tested on PPPoE the simple configuration I gave you on slack. It works perfectly, delay goes down for interactive traffic and bulk flows are distributed fairly.