https://github.com/vyos/vyos-1x/pull/200
adding CLI commands
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 9 2020
Jan 8 2020
Update
The problem was resolved by manually removing the interfaces from the file /config/config.boot (section flow-accounting)
Actually, this seems to be a build issue as a fresh build with the up to date vyos-build repo causes a fresh build of 1.2.3 to suffer the same problem.
Jan 7 2020
Jan 6 2020
Jan 5 2020
Jan 2 2020
I got this on two production systems on the next two I migrated I changed my workflow to:
Dec 31 2019
Dec 28 2019
Dec 27 2019
Dec 24 2019
Same behaviour with compiled uacctd version from pmacct git 1.7.5-git (20191224-00):
packets are arriving correctly to nflog group (tcpdump shows them) but they aren't processed by uacct
Dec 23 2019
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).
Dec 22 2019
Dec 21 2019
vyos@vyos# set system flow-accounting syslog-facility brownie
Dec 20 2019
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.
Dec 19 2019
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:
Dec 18 2019
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.
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
Dec 16 2019
Dec 15 2019
Dec 14 2019
Dec 13 2019
tagNode has been renamed to dnssl
Dec 12 2019
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
Dec 11 2019
T1846 fixes this
Dec 10 2019
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.
Dec 9 2019
Related to T1844, which should correct the original problem in this ticket
Dec 8 2019
Dec 6 2019
@zsdc Maybe Incorrect file location. "ddclient.pid"