Works as expected, tested on 1.3-rolling-202006201113

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

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

@fmertz for easier developing I have a bunch of BASH aliases which are also mapped into my docker container.

Added a basic test so this issue does not re-appear on ISO build https://github.com/vyos/vyos-smoketest/commit/b38a42d9d4ab302b44d48844fae49bb0a0817d04

Fair point. In that case I agree with not including a raw config option.
As for the errors when installing vyos-1x, c-po already pointed out why this occurs.For this reason I don't rebase on upstream while working on a set of changes locally, I always try to keep the installed iso and local git state as much together as possible. I also run docker from the vyos-build repo and have the vyos-1x repo dir in vyos-build/packages/vyos-1x (where the included scripts/build-packages would put it) so I can just docker run and build without having to copy any files anywhere, just scp the built deb into the VM.

Hi @fmertz, this is a more or less common "issue" during peak development times.

At this point, i could use a couple of wise words for the development process.

Documentation is here: https://docs.vyos.io/en/latest/services/console-server.html

I'm no fan of the raw options from dhcp and openvpn and think we should not add more of those. Unfortunately they have been inherited from Vyatta. ISC DHCP could never be replaced by any other DHCP server due to this fact which is IMHO a super bad CLI design.

1. PR for removing old vyatta-op-quagga code https://github.com/vyos/vyatta-op-quagga/pull/7
2. PR for add commands to new XML format https://github.com/vyos/vyos-1x/pull/466

@c-po I tend to agree to have as much predefined templates, but I'd leave the option to have a custom config if the user wants to, I don't like imposing artificial limitations. We already allow custom options with dhcp-server, openvpn..., why not allow specifying your own conf file for the driver section to include? Some things are impossible without either this or going with approach 2 by exposing absolutely all configurable driver options through the config. I'd prefer that, but if it results in too much options/config size, the alternative is as I described. But in the long term I think approach 2 would be the best.

I'd go with option 1 to have a well known list of working and supported LCD displays. Each will have it's own configuration template which is used when implementing. I'm not a fan of "power user options" as this usually causes more harm then good - also users tend to be overwhelmed by the number of CLI options. We rather should make adding new display types super easy with proper documentation.

https://github.com/vyos/vyatta-cfg/commit/7f6eb1ed2c2a9dc76227ac355446b6d4b6c27733
https://github.com/vyos/vyatta-cfg/commit/72d0243f10e4df7c2fb7ce35c3d7f333e83bab97
https://github.com/vyos/vyatta-cfg/commit/4592ae65d42e5d8eba77350f8339e07350ad0908

This is a much broader issue in fact, and has nothing to do with VRRP! It's also a possible shell injection, though for values coming from local sources it's irrelevant.

Sadly, still reproducible. I fear we may want to keep it as a known wart until the firewall rewrite is complete.

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.

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.