Backported to crux
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Aug 31 2019
Aug 31 2019
syncer edited projects for T1461: Deleting 'firewall options' causes Python TypeError, added: VyOS 1.3 Equuleus, VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux.
Aug 22 2019
Aug 22 2019
Aug 19 2019
Aug 19 2019
@hagbard can you take a look if that was backported?
Still seeing this bug in 1.2.2. VyOS config has weights configured, but in the FRR config, weight is missing.
Aug 5 2019
Aug 5 2019
c-po moved T1400: iBGP: remote-as and router AS can't be the same value from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T1428: Wireguard: fwmark setting is not honored from Need Triage to Finished on the VyOS 1.3 Equuleus board.
Aug 2 2019
Aug 2 2019
Jul 30 2019
Jul 30 2019
hagbard moved T1351: accel-pppoe adding CIDR based IP pool option from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.2) board.
https://github.com/vyos/vyatta-op-quagga/pull/3 I hope now it looks better
Did I something wrong with https://phabricator.vyos.net/T1550 and https://github.com/vyos/vyatta-op-quagga/pull/2 that the pull request is not showing in phabricator?
Jul 29 2019
Jul 29 2019
hagbard changed the status of T1351: accel-pppoe adding CIDR based IP pool option from Resolved to Unknown Status.
hagbard added a project to T1351: accel-pppoe adding CIDR based IP pool option: VyOS 1.2 Crux (VyOS 1.2.2).
Jul 24 2019
Jul 24 2019
With the new versions of the open-vm-tools you can explicitly disable the pulling of the routing-table. Maybe that's a better way then disabling the whole pulling of information.
Jul 20 2019
Jul 20 2019
syncer moved T1131: open-vm-tools causing 100% CPU load from In Progress to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
syncer edited projects for T1131: open-vm-tools causing 100% CPU load, added: VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux (VyOS 1.2.3).
Jul 14 2019
Jul 14 2019
c-po moved T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders from Finished to In Progress on the VyOS 1.3 Equuleus board.
c-po added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
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 12 2019
Jul 12 2019
Line2 added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
test config looks like this:
Jul 11 2019
Jul 11 2019
squeeby added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
From the slack discussion, we found there should be a single forward-zones-recurse line as the last one takes precedence
c-po added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
Can you share your configuration and the actual /etc/powerdns/recursor.conf file? And an expected /etc/powerdns/recursor.conf?
Line2 added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
It worked as it looked like this:
c-po added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
How should the config look like?
Line2 added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
recursor.conf looks like this:
Line2 added a comment to T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders.
The problem is back in 1.2.0-rolling+201907110337 :-(
The line with the forwarders in recursor.conf is missing again.
@c-po
How can I reopen this task here?
Jul 10 2019
Jul 10 2019
dmbaturin triaged T1505: vyos.config return_effective_values does not convert the output to a list as Urgent! priority.
Jul 3 2019
Jul 3 2019
c-po moved T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po edited projects for T1333: pdns_recursor does not perform recursive lookups on domain specific forwarders, added: VyOS 1.3 Equuleus, VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux (VyOS 1.2.3).
c-po changed the status of T1469: Create forward-zones-recurse entry instead of forward-zones when setting service dns forwarding from Unknown Status to Resolved.
Possibly a related problem here in T1497, we're still chasing an issue where disable-dhcp-nameservers isn't working on startup.
Jul 1 2019
Jul 1 2019
Jun 30 2019
Jun 30 2019
@c-po We have plurals everywhere we have more than one option under a subtree. dhcpv6-options, offload-options, "system options"
Since there's also the hostname option, and possibly other options we may want to send, that makes sense I guess.
Jun 27 2019
Jun 27 2019
csalcedo added a comment to T1392: Large firewall rulesets cause the system to lose configuration and crash at startup.
I have upgraded a couple of clusters to 1.2.0-rolling+201906240337 and systems started successfully, and I also applied the hotfix indicated in thel pull request (https://github.com/vyos/vyatta-cfg-system/pull/102/files) to several productive clusters by just adding "/interfaces" to $VYATTACFG variable with the same successful results, so I can confirm that the fix provided by @mtudosoiu works great.
Jun 24 2019
Jun 24 2019
c-po moved T1484: OSPF md5 key not removed in strip-private from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
c-po edited projects for T1484: OSPF md5 key not removed in strip-private, added: VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux.
c-po moved T1377: BGP Weight Not properly applying from In Progress to Finished on the VyOS 1.3 Equuleus board.
zsdc changed the status of T1392: Large firewall rulesets cause the system to lose configuration and crash at startup from Open to Needs testing.
Provided configuration from the first message was successfully loaded in 1.2.0-rolling+201906240337.
@csalcedo, could you test new rolling to check if the problem is solved for you too?
hagbard added a project to T1452: accel-pppoe - add vendor option to shaper : VyOS 1.2 Crux (VyOS 1.2.2).
Jun 23 2019
Jun 23 2019
[ 131.476053] i40evf: Intel(R) 40-10 Gigabit Virtual Function Network Driver - version 3.6.15 [ 131.476055] Copyright(c) 2013 - 2018 Intel Corporation.
c-po changed the status of T1471: Wireguard interfaces have no firewall subtree from Unknown Status to Resolved.
c-po moved T1471: Wireguard interfaces have no firewall subtree from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po changed the status of T1464: FRR: Set explicit OSPFv3 network type for specified interface from Unknown Status to Resolved.
c-po moved T1464: FRR: Set explicit OSPFv3 network type for specified interface from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
c-po edited projects for T1464: FRR: Set explicit OSPFv3 network type for specified interface, added: VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux.
c-po closed T1477: Intel i40evf fails to load - unknown symbol, a subtask of T1473: Update Kernel from 4.19.52 to 4.19.54, as Resolved.
c-po moved T1477: Intel i40evf fails to load - unknown symbol from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T1455: Update Intel i40e driver to 2.9.21 from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T1475: Enable Kernel Data Center Bridging (CONFIG_DCB) support from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po added a project to T1475: Enable Kernel Data Center Bridging (CONFIG_DCB) support: VyOS 1.2 Crux (VyOS 1.2.2).
c-po added a project to T1477: Intel i40evf fails to load - unknown symbol: VyOS 1.2 Crux (VyOS 1.2.2).
c-po moved T1471: Wireguard interfaces have no firewall subtree from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
Jun 22 2019
Jun 22 2019
c-po changed the status of T1433: "show dhcpv6 server leases" shows leases from wrong file from Unknown Status to Resolved.
c-po moved T1433: "show dhcpv6 server leases" shows leases from wrong file from In Progress to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
backported into 1.2.2
With https://github.com/vyos/vyos-1x/pull/74 tested working on crux.
Jun 19 2019
Jun 19 2019
c-po changed the status of T1454: Reading deprecated /etc/frr/daemons.conf from Unknown Status to Resolved.
c-po changed the status of T1453: Warning: nss-myhostname is not installed from Unknown Status to Resolved.
c-po moved T1453: Warning: nss-myhostname is not installed from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
c-po edited projects for T1453: Warning: nss-myhostname is not installed, added: VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux.
c-po moved T1454: Reading deprecated /etc/frr/daemons.conf from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
c-po edited projects for T1454: Reading deprecated /etc/frr/daemons.conf, added: VyOS 1.2 Crux (VyOS 1.2.2); removed VyOS 1.2 Crux.
Jun 18 2019
Jun 18 2019
c-po moved T1444: Update Linux Kernel to v4.19.52 from Backlog to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
this is also the case for ping 127.0.0.1 count 100 flood
c-po moved T1444: Update Linux Kernel to v4.19.52 from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.2) board.
Jun 17 2019
Jun 17 2019
c-po moved T1390: Extend bgp config for bestpath as-path multipath-relax from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T1390: Extend bgp config for bestpath as-path multipath-relax from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.2) board.
Jun 16 2019
Jun 16 2019
@c-po Line 115 and 116 of src/conf_mode/dhcpv6_server.py (that generate /etc/default/isc-dhcpdv6-server) still reference the dhcpd6 name and would need to be changed also.
Are you sure we should change all these filenames and the leases filename without migrating it? I guess if you wanted the naming with "dhcpv6" consistent, but IMO it's unnecessary.
The alternative would be to just fix src/op_mode/show_dhcpv6.py and keep the old lease file naming, thus not breaking the cache on upgrade for all users.
I'll create a PR with the version you decide...
I‘d keep it as it is as it was previously a bug accessibg the wrong file. As DHCP clients usually request their last assigned address not to many systems will break.