tested with minimum aggregate options (no MAC, VLAN, interface, ...):

That seems to be a uacct problem (test inVyOS 1.3-rolling-201912201452 with new flow-accounting python/xml conf).

Added PR
https://github.com/vyos/vyos-1x/pull/190

This is a known fault, and is not easily fixable in the current implementation. This fault is because the vuos cli manually configures the frr process after it's started, and when the process dies/restarts it will read its config from the saved config file. This makes the process restart into an empty config as we have no way to save the config from the prior process.

I tested this morning and I was able to build the vyos-builder:crux and crux iso.

Please try again

Awesome! Enjoy Testing!

@c-po, there is also third PR in vyos-buid: https://github.com/vyos/vyos-build/pull/69

Found it. Thx

@zsdc is thwre a second PR removing the old implementation?

I was able to build the container, but sudo make iso failed with:

Wow, you did it!!!
I’ll do some tests
But I don’t know to test on a current vyos build so I’ll have to wait until the PR are accepted.
I hope it will accepted asap.

Thanks, @elbuit !
We have prepared PR with full functionality: https://github.com/vyos/vyos-1x/pull/187
It would be great if you will join us and help to test it, find all bugs and fix them. :)

I did some work porting vyatta-netflow to new vyos model

Solved it by importing libyang binary packages onto http://dev.packages.vyos.net/repositories/crux/debian/pool/main/liby/libyang/ which is even better.

Fixed in https://github.com/vyos/vyos-build/commit/f2d457a9ed089995783207574699ec98c6956291

I got the following error:

Testing now. Will update

Please pull and try again

Hi @max1e6 we are currently migrating the repositories to Debian Buster so there could be some turbulences

tagNode has been renamed to dnssl

I'm experiencing the same issue of the service failing to start on 1.3.
The installation was first started with the default config in a VM that had a serial port. Then the installation was transferred to a physical machine without a serial port, and the whole /config directory was manually copied from the old installation on that machine. The machine was then rebooted. The result were the same errors in syslog/journal.
I believe the issue is that if the config.boot is manually replaced or edited on disk, the script that would normally be triggered on commit when deleting system console is never triggered, thus the service remains enabled, but there is no system console in the config to delete any more.

Problem was in the wrong IKEv2 definition, set vpn ipsec ike-group IKE-AZURE ikev2-reauth must be yes

T1846 fixes this

Looks like the vyos-1x images was not rebuilt from the crux branch before the new image was built. I manually checked out the crux branch and the commit ins backported in there, rebuilt the packages manually and everything needed is in there and working.

Link to the changelog https://phabricator.vyos.net/maniphest/query/Vx2T4niywHe4/#R

tested with today rolling release. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912100217-amd64.iso)

@kroy please test with the latest rolling if https://phabricator.vyos.net/T1846 solves your issue.

Related to T1844, which should correct the original problem in this ticket

@zsdc Maybe Incorrect file location. "ddclient.pid"

Okay, so this problem just got a LOT more bizarre.

The runtime errors are fixed by the above commit.

@kroy I can't really reproduce it if I disable the peer first when multiple peers are defined on the same wg interface.
Can you please do a touch /tmp/vyos.ifconfig.debug and then run your commands and post it here?
It will show you the commands execute for each step like:

vyos@wg01# set  interfaces wireguard wg0 peer wg02 disable 
[edit]
vyos@wg01# commit
[ interfaces wireguard wg0 ]
DEBUG/wg0    write '1420' > '/sys/class/net/wg0/mtu'
DEBUG/wg0    write 'wg0' > '/sys/class/net/wg0/ifalias'
DEBUG/wg0    cmd 'wg set wg0 peer G1aA2KkyFyC8xsCUeENvuIW8HC5yDxwi902nR20592Y= remove'
DEBUG/wg0    cmd 'wg set wg0 listen-port 12345 fwmark 0 private-key /config/auth/wireguard/default/private.key peer hbwJSCu6SGUKIReNhWxlDIFRNCl5L7PaUSYOo2BF+Rg=  preshared-key /dev/null  allowed-ips 10.100.100.3/32 endpoint 10.1.1.203:12345 persistent-keepalive 0'
DEBUG/wg0    cmd 'ip link set dev wg0 up'

https://github.com/vyos/vyos-1x/commit/fde531d3791a3d71aa27f99244d7cbb3b3625bf0

What were the steps you used when you upated the pubkey?

When the config was gone, the processes still seemed to be running

You can via https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27, which just sets the completion help.
For T1845, yes it solves the issue with setting address:port _and_ moves protocol up from facility to host. Do you want me to revert and do 2 commits, which requires then 2 migrations, once for address:port and one to solve the logical issue with protocol. Right now you can set a different protocol for different facilities for the same host.

Wrong logic.
Need to return line 108 code

print (cmd.decode (). split (",", 1) [0])

Bug in latest rolling

Wha cant the change which adds the completion helper be backported? Git best practice is you should group changes per commit. But in this commit you add the completion helper and also other regexes (BAD!)

Will interfere with T1845, while I think T1845 should be the backport candidate. Facility is a tag node, protocol has been moved on level up and is host specific. Having the availability to set different port per facility doesn't really make sense.