The root cause was insufficient validation.

Whichever decision we make, let's not change this in 1.3—there are lots of changes already.

This rabbit hole goes deep. It's not just a display issue, but the whole reason we cannot have rollbacks without reboots—there's no way to generate an inverse changeset "thanks" to this.

This task will be resolved by removing Interface.pm altogether.

Glad to hear that!

Sorry it took so long! I've cherry-picked it into crux, will be in 1.2.6.

Ideally we may want to add an extended "if VRRP configured" check, or make keepalived produce an empty (or special) file when it's running but has no data. For now this fix should do though.

VTI is secretly IPIP, so it doesn't support IPv6. The real issue is that we don't support the IPv6 variant of VTI yet.

The user-data dir actually is preserved on upgrade, it's just the check that is faulty. Need to look into it.

Added a warning.

It may be a good idea, but it sure needs a serious and broad discussion. I'm moving it to 1.4 for now, though we may move it back if we have time before the freeze.

Since we are heading towards a freeze, I believe it's better to live big changes for later, even though I don't categorically disagree with the idea.

Still reproducible in 1.3-rolling-202006241940

Now that we have an HTTP API, I believe it's time to deprecate vymgmt altogether.

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.

Fixed: https://github.com/vyos/ipaddrcheck/commit/27dd86068b1ab3204517b8950746aec7c1c294d0

I'm pretty sure it's my failure to correctly handle an edge case. I'll look into it today, should be simple enough.

I think we can safely remove it indeed.

Sometimes I wonder if we should just silently wrap every op mode command in sudo, at least those in the families other than show. It's hard to name a command that doesn't need sudo, and everyone (myself included!) has forgotten to add it at least once.

All sounds good to me.

As far as I remember, originally in our Quagga days, it was the case: nothing was advertised if it wasn't present in the RIB. So if you wanted to advertise e.g. 192.0.2.0/24 but had it split into /25's, you'd need both set protocols bgp ... network 192.0.2.0/24 and set protocols static route 192.0.2.0/24 blackhole.

I think I agree: at commit time, user's CLI edit level is irrelevant and should have no effect on the script behaviour.

Could you describe your "dream syntax" for it?
The op mode node.def's simply don't have a concept of value help in vyatta-cfg, only comp_help (<completionHelp> in XML terms).