It looks like this change was made in https://phabricator.vyos.net/T726 before the python rewrite.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 13 2018
Nov 7 2018
Nov 2 2018
Oct 30 2018
This is exactly the same issue i reported in T786, for every interface thats created the script runs its full processing.. when 10 interfaces are created it tries to execute it 10 times and so on. I have purposed a fix for this behaveor in T786 and there is a PR (https://github.com/vyos/vyos-1x/pull/33) on this. Another thing that could be done to fix this is to fix the underlaying vbash code that makes this happen, but i think that is a larger task.
All right, node.tag gets called twice. In the first round both interfaces are being configured correctly, then the parser calls it again (node.tag) and of course the IP already exists, so the error is valid from a script perspective.
Related to the issue @runar reported: https://phabricator.vyos.net/T786.
Oct 29 2018
Currently only the check for additionally installed packages is implemented, but the script can be extended. Didn't push it to crux to have it properly tested first.
Listing the specific ip addresses was my legacy configuration. I removed it in the current configuration. I played a little with the interface routes and the seem to work properly on the technical side of things as i am able to ping the opposit device. But somehow the routing daemon lists routes to the peers as 'inactive' which makes the configuration unusable for me.
Since I don't know your listen ports I can't verify, if the ports you've set are correct or not. What I see in the logs, looks all ok, please keep in mind that your tunnel shows onl;y active if at least one packet passed the wg interface, otherwise you won't see anything.
So as far as i see from the above your wg interfaces are being created (you can bind multiple different peers to one interface by the way) and active.
I rebased the router with the rc-4 image. After importing the configuration and rebooting the router a similar error occurs. The boot screen shows the error message "vyos-config[1708]: Configuration error". Looking into the configuration using 'show configuration' only shows the configuration of the wg2 interface but 'cat /config/config.boot' shows all three interfaces with correct configurations. The wireguard tool shows threee interfaces similar to the output before without any configuration.
That's intresting. I rebooted the system a few seconds ago and the tunnels dom't become active.
@c-po can we mark this as resolved?
Oct 28 2018
I've tested your setup and can't find any issue with the interfaces in -rc4. However your routes won't survive a reboot, please use 'set protocols static interface-route <destination-net> next-hop-interface wg0'.
If that doesn't solve your issue, please check 'show interfaces' and check if the wg interfaces is setup after reboot there.
Also please provide the output of the following:
'grep wireguard /var/log/messages'
this is the configuration which i need to set again after each reboot (and i remove the ip address from the interface and set it again as ip + peer address as there is no configuration option at the moment). I removed some unimportant information.
Hi @MrXermon ,
can you please share your configuration? At least the set interface wireguard ... ones would be interesting, so I can test it.
@dmbaturin Awesome, I didn't have the time to look into that further. I'm going to test it for sure.
Groups need a big overhaul, but its probably out of the 1.2.0 scope.
I've finally located the place where tag node output is handled and added quoting analogous to what was always done to leaf node values. Now saved configs should be correct.
In rc3 and rc4, it's empty for me.
By default cli-shell-api showCfg is level-aware, and the script indeed did not use the option for supressing it.
Indeed, the original script only took the first word, rather than all words after "filter".
Oct 27 2018
Tested on the latest 1.2.0-rc4 and it appears that the memory plugin is still enabled.
Verified on VyOS 1.2.0-rc4 as working correctly.
So that's what I have right now for checking the packages, if they are newer than the image build time, it would spit out the below:
@hagbardI like the idea to have it modular,
we also need to add profiling option (collecting system metrics over some period of time)
and maybe some more stuff (specific to functionality like ipsec, bgp, firewall, etc)
Sure I can get you tcpdumps. Do you want to see the ospf packets specifically?
Oct 26 2018
https://github.com/vyos/vyatta-cfg-firewall/commit/d4799d1715fc3177b84d66af406fa3028a95d254
pkg checked out ok in ci, tested and verified locally in 1.2.0-rolling+201810211757.
Oct 25 2018
show tech-support network - all network related stuff
show tech-support system - os related (cpu, memory, file system space, pkgs etc.)
Yes,
that will be kind of the first step in troubleshooting workflow
i propose to make another ticket for show tech-support
and current one assign as a subtask
ok, so what do you have in mind for integrity support? If someone installs from external sources or a different kernel for instance, you can only find out when you have the information somewhere, that's why I though to integrate it into the tech-support. So, if someone reports an issue, we can just receive that report and have all information in one tarball to check what's going going on. I'm getting a bit confused.
Current show tech-support can be nuked once we have a replacement
The on-screen output is useful if you debug onsite or have access to the machine
We mixing here stuff, integrity check bit different from show tech-support but can be part of it
Yeah, I agree but what about the show tech-support which currently exists?
There is generate tech-support archive, which stores a tarball and/or you can upload it via scp/ftp to a destination.
Plus there is 'show tech-support' which shows the information to the screen, which I think won't make a lot if sense.
For the packages, I have the full dpkg -l in a file, that can be read and compared easily with the packages installed in the iso.
Do you have a system for automated checks in mind already? (I built something similar in the past on a normal webserver).
we need tech-support but need it reworked
on one hand, it must be human-friendly
on another hand, we need to have ability feed it into analytics platform later
we should skip all sensitive info
Do we need show tech-support at all?
I changed a few things I would gather, I leave /home/user and /config/auth alone, since they can contain sensitive information like private keys.
In the archive I create files for each 'section. Like OS based information, network related information go to an extra file etc.
The idea is to make it easier for the one reading to all that stuff and giving the user the confidence we don't steal their ssh key or wireguard private keys by accident.
Also adding content to the report would be easier there too. I can upload to my github what I have so far since you would only need the script right now, I haven't it integrated in vyos-1x yet.
vmtoolsd --cmd 'info-get guestinfo.ovfEnv' returns "No value found"...
I retested on 1.2.0-rolling-201810240337, the same log:
I tested with only NoCloud.
I understand ovf/ova must include ProductSection with some properties like this https://github.com/cloud-init/cloud-init/blob/master/doc/sources/ovf/example/ubuntu-server.ovf
yes, exactly
Where is the ovf @UnicronNL made?
it does not exist yet :)
I tested with only NoCloud.
I understand ovf/ova must include ProductSection with some properties like this https://github.com/cloud-init/cloud-init/blob/master/doc/sources/ovf/example/ubuntu-server.ovf
Where is the ovf @UnicronNL made?
ovf/ova must be with properly configured ovf environment and cloud-init package @UnicronNL made into vyos repository
the test image with cloud-init is here. https://dev.vyos.jp/vyos/images/rolling/current/amd64/vyos-1.2.0-rolling-201810250337-vmware.ova
@syncer @UnicronNL sorry. I did it right now on https://github.com/vyos/vyos-vm-images/commit/00a5684ba31ed5c68d168290fb45a35bf5d58177
And it seems there are two styles of VM image build. ansible playbooks in vyos-vm-images and shell scripts in vyos-build.
@higebu yes, @UnicronNL already have it in backlog
Oct 24 2018
Resolved by waiting for IPv6 DAD to complete in scripts/vyatta-dhcpv6-client.pl. The 'configure failed!' message no longer appears, dhclient starts and the configuration nodes are not deleted.
Typically it only has to wait 1 second for DAD to complete, so on some systems/reboots you would never have seen this issue.
@syncer I read this: https://twitter.com/vyos_dev/status/1055037448093425664?s=19
so we should use cloud-init for VMware image too?
https://cloud-init.io/
Interestingly, disabling particular modules works fine in 1.1.8 regardless of whether NAT or firewall policies were in place.