Confirm fixed in latest rolling 201907270337
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 27 2019
Jul 26 2019
Jul 25 2019
Thanks - but still there should not be a Python error and also a user error message
Jul 24 2019
Jul 23 2019
See T1331
backported
Jul 22 2019
Problem exists on 1.2.2
Jul 21 2019
VyOS 1.2.2 only contains DHCP op mode definitions from the following packages:
fix backported to crux
Jul 19 2019
I have ran VyOS 1.2.1 and now 1.2.2 for quiet some time and can no longer see this issue. 1.2.1 and 1.2.2 are both based on PowerDNS recursor 4.1 series.
Unfortunately PowerDNS no longer supports the 4.2 series on Debian oldoldstable (Jessie) - reverting this on current to fix the build.
Jul 18 2019
Jul 14 2019
It will be definately a Kernel issue. I will close this now as it seems to be resolved. Please re-open when the issue re-appears on a new update of the kernel.
Is this what you expect?
The new implementation will behave as follows:
After reading the PowerDNS docs this should be correct: forward-zones-recurse=.=1.1.1.1,intern=172.16.10.1 I will take a look.
Jul 13 2019
Jul 11 2019
Can you share your configuration and the actual /etc/powerdns/recursor.conf file? And an expected /etc/powerdns/recursor.conf?
A check is already present when configuring the firewall name.
How should the config look like?
Jul 10 2019
Issue present in the 1.2.2 ISO, too
Jul 9 2019
Today I experienced the same asynchronity in the OSPFv3 subsystem
Thanks, the trick was adding some link-local adresses.
Jul 7 2019
The issue can be reproduced using the sanitized configuration below:
that commit should be reworded to have the task id in front.
Jul 4 2019
Unfortunately the configuration is incomplete. Can you either add the missing parts or you can PM your real configuration if this works for you, or use the show configuration commands | strip-private command to remove any sensitive stuff.
Jul 3 2019
Thanks for the explanation
Fixed by T1469 both in rolling and crux
Build complete
Please check wirh upcomming rolling release. There was a fix in T1469
Thanks for the contribution
Jul 2 2019
What is the purpose of getting the nic/mac mapping before configuration is applied? Is the result passed to a second script which pins the ethernet interface to its mac address? Why not write a script which dynamically reads the info from the config, parses it and applies further actions without the need of an intermediate file?
Jun 30 2019
Can't reproduce, but I experience a different issue - Nameservers are not propagated into resolv.conf
Jun 29 2019
Unfortunately this is not 100% correct, the intel drivers are pinned to a specific version. Only vyos-wireguard, vyos-accel-ppp are using git HEAD revision from their individual repos.
I only see some minor problems, but in general I like the idea very much!