The immediate issue was resolved above. As far as changing the backend code, this will only be done if there emerges another annoyance; for now, we will consider the preamble 'path' when calling print in a config session a 'feature'.

On boot, the existing config file is committed.

Definition of effective is here:

This has a dependency on python3-flask-restx, which will need to be added using, for example, T2396.

The form will be made consistent with other commands, using an explicit 'op' (show|generate) and 'path' as list of strings. For example:

Yes, that changed it: neither single or double quotes worked previously --- with the change to use crypt(), single quotes around plaintext password with (those) special characters now works; double quoted special characters are still interpreted.

No it's the shell interpreting from Popen (cmd), but you may have already resolved this by using the library function; I'll check.

@fetzerms Thank you for the logs; that was the output I was hoping to confirm. The WSGI server in python3-bottle is showing occasional instabilities; I am not able to confirm with collections of set commands similar to yours, though I am able to induce it artificially. There are a few recent changes that will help avoid triggering this, while I track down a root cause. If you have a chance, it would be helpful if you could try a recent rolling (>= vyos-1.3-rolling-202004100117). If your are able to monitor the output of 'journalctl -fx' on the system, while executing remote configuration, that would be very useful, though that may not be feasible in your setting.

@adestis The status 'Backport Candidate' indicates the intention to include it in 1.2.x; I may have mistakenly removed the specific project (1.2.6) when I changed the status.

@chrismarget I'll commit the changes shortly, and close the task; thanks!

True, it doesn't currently work; that patch has various problems.

The time-out issue is resolved in T2252; other issues as summarized above.

@fetzerms I was mistaken: cfg-stdout.log is logrotated, but not removed on boot, and this is useful info. When you are able to reproduce, please share. I believe the corner case I am seeing is distinct but related to what you are seeing. Thanks.

@fetzerms I am able to reproduce this, in a manner that's not completely clean, but which will allow me to investigate further. Feel free to add any other details you run across; thanks.

Note, there is /opt/vyatta/etc/config/vyos-migrate.log (/config/vyos-migrate.log after image installation) that will list failed migration scripts, if any). This is created before /var/log is available, hence the non-canonical location.

Regarding the first question, yes, cfg-stdout.log is cleared on reboot, unfortunately. The commit error logging is currently a mixture of (un-verbose) reporting from the backend, and limited reporting from python; improvements pending. Firstly, if there are migration errors, those need to be investigated; secondly, the error that you initially reported is (generally) related to stale information in the config hierarchy itself, but may be obscuring earlier errors.

In this failure case, there are some expected "failed" lines in /var/log/vyatta/cfg-stdout.log. Although they are not detailed log messages, they may help narrow down the source of the failure, if you could share those.

https://github.com/vyos/vyos-1x/pull/284