Can you please share which 1.2 version was used and also a show configuration commands output so the issue can be reproduced easily.

@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.

No, seems to be fixed! I was pretty sure it was upstream, must be resolved now.

Do not use vyatta-cfg-cmd-wrapper. The script-template takes care of the environment setup and exposes the set/delete/commit command for you to run as if it was an interactive session.

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.

It's updated in current, still needs an update in crux.

Definitely works fine after the work from T1855

If more evidence that is valid appears, please reopen.

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

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