Works as expected, tested on 1.3-rolling-202006201113
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Jun 21 2020
EDIT: EDITED from original for clarity
Jun 20 2020
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
EDIT: See simplified configuration below
VyOS 1.3 uses nftables for performing NAT operations. It might be possible that there is a bug in the new code. It would be interesting to get a copy of your sudo iptables-save -t nat and sudo iptables-save output on 1.2 so we can check it in 1.3.
Version: VyOS 1.3-rolling-202006200117 Release Train: equuleus
I can confirm that your change as of VyOS 1.3-rolling-202006200117 fixed the problem.
Jun 19 2020
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.
set interfaces ethernet eth0 address '2001:XXXX:YYYY:10::1/64' set interfaces ethernet eth0 address '10.0.10.1/24' set interfaces ethernet eth0 description 'Management Network' set interfaces ethernet eth0 duplex 'auto' set interfaces ethernet eth0 hw-id '52:54:00:c4:7f:61' set interfaces ethernet eth0 ipv6 dup-addr-detect-transmits '1' set interfaces ethernet eth0 ipv6 router-advert cur-hop-limit '64' set interfaces ethernet eth0 ipv6 router-advert link-mtu '0' set interfaces ethernet eth0 ipv6 router-advert managed-flag 'true' set interfaces ethernet eth0 ipv6 router-advert max-interval '600' set interfaces ethernet eth0 ipv6 router-advert other-config-flag 'true' set interfaces ethernet eth0 ipv6 router-advert prefix 2001:XXXX:YYYY:10::/64 autonomous-flag 'false' set interfaces ethernet eth0 ipv6 router-advert prefix 2001:XXXX:YYYY:10::/64 on-link-flag 'true' set interfaces ethernet eth0 ipv6 router-advert prefix 2001:XXXX:YYYY:10::/64 valid-lifetime '2592000' set interfaces ethernet eth0 ipv6 router-advert reachable-time '0' set interfaces ethernet eth0 ipv6 router-advert retrans-timer '0' set interfaces ethernet eth0 ipv6 router-advert send-advert 'true' set interfaces ethernet eth0 smp-affinity 'auto' set interfaces ethernet eth0 speed 'auto'
Version: VyOS 1.2.5+
Release Train: crux
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.
- PR for removing old vyatta-op-quagga code https://github.com/vyos/vyatta-op-quagga/pull/7
- 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.
Jun 18 2020
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.
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.