Accidentally committed a crux fix with https://github.com/vyos/vyos-1x/commit/920d87447ca479c311102260e5816ec0f5268a9b
Jul 26 2020
Jul 24 2020
https://github.com/FRRouting/frr/issues/6797 Opened an issue with FRR.
Jul 21 2020
Jul 18 2020
This only happens when there are multiple <path> options.
Jul 15 2020
Jun 28 2020
I suppose "service ids ddos-protection" makes sense indeed.
Jun 25 2020
I think this is a good idea. Maybe separate the protocols, http-client and ssh-client?
Or we can make protocol a multi node.
Since the user can specify both protocols inside, we'll probably have to duplicate the whole things if we detect that.
Ok, let's switch to an empty banner.
Apparently the "still in use" check logic really leaves much to be desired. See T1292. I wonder if there's a general fix within the current approach.
That part is rewritten in current already. https://github.com/vyos/vyos-1x/blob/current/op-mode-definitions/show-log.xml#L212
Turns out it's because the conf mode "allowed: " is escaped and eval'd when it's passed to the shell: https://github.com/vyos/vyatta-cfg/blob/current/src/cstore/cstore.cpp#L756-L762
Could you make a pull request?
I've reviewed the code and it looks good to me.
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.
Jun 18 2020
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.
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.