- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 23 2019
Additional issue with requiring something after disable
Unfortunately I can not reproduce this issue
Please, review another batch of trivial rewrites from vyatta-op and the corresponding vyatta-op PR
This can be solved using multiple ways:
- add option to the interfaces-bridge.py script to recreate the bridge when triggered externally
- advantage: the conde is already there
- disadvantage: the script can easily grow to a wastebin of code executed from 100 places
- add a dedicated bridge-group-sync.py script which synchronizes the bridge groups and interfaces, called whenever a interface is added to the system (e.g OpenVPN vtun or ethernet vif). We will walk through all available bridges configured and add possibly missing interfaces
- advantage: code is contained in a dedicated scirpt
- disadvantage: more and more scripts might evolve
- Write a vyos-interfaced which acts as message receiver and will handle tasks as adding/removing IP addresses, adding/removing bridge and bond members
- advantage: most generic and single source
- disadvantage: most complex
Full console dump to reproduce with comments:
## ## Start without anything
the current only way to get the interface added to the group is to remove and readd it to the group.
vyos@vyos# brctl show bridge name bridge id STP enabled interfaces br1 8000.525405123456 yes eth0.1
i've updated the description. the bridge is created and comitted prior to the creation of the interface.
If the bridge priority is higher then the ethernet vif this should work out of the box
I confirm, this behavior was reproduced. As I saw, problem with outgoing marked packets from server. Maybe for this case need add some option for marking only incoming packets, like
mark_in=%unique
While using NAT, just set mark=%unique for in and out marking
Just checked the vyos-1.2-rolling-201908230337-amd64.iso - it is bootable after install.
Unfortunately name resolution seems broken. Here are some details:
- VM with the previous working image 1.2-rolling-201908210337:
vyos@vyos:~$ show system image The system currently has the following image(s) installed: 1: 1.2-rolling-201908230337 2: 1.2-rolling-201908210337 (default boot)
Don't use the same private key in two places at the same time. This means it's not a good idea to copy private keys between computers and use it in two places, and probably also means you shouldn't assign the private key to two interfaces on the same computer at the same time, unless you have a really particular and weird setup and know precisely the implications of it. Doesn't sound like that's the case here. So you're probably best doing a private key per interface.
Aug 22 2019
Does this mean it'll make it into Crux soon?
Aug 21 2019
@UnicronNL , no need to apply the patch, it is already applied to the codebase. this issue needs to be something else
In T1070#41443, @runar wrote:@UnicronNL could you apply my patch to the codebase?
moved get functions into properties, for ifalias, macaddr and mtu to see how it works. If the old get_ function is being used, it prints a message to the console but still works. Will see how well that works.
https://github.com/vyos/vyos-1x/commit/0b9c894fcece6df553a89e42147768ce6efaf372
The problem is in FRRouting itself. It can be reproduced in 7.0.1-20190820-04-g047efd6, 7.1-20190820-02-g1ed807a. But in 7.2-dev-20190820-03-g9316c82 everything work as expected.
We should try to find which changes fixed this problem and reapply it to one of the current stable FRR versions or wait for the next stable.
@UnicronNL could you apply my patch to the codebase?
I an confirm as well this is happening in 1.2.2. Is there anyway to cronjob a restart of the process to re-establish connectivity to the hub as a workaround?
https://phabricator.vyos.net/T834
In T834#41371, @hammersoft wrote:On vyos-1.2-rolling-201908201244-amd64.iso won`t reproduce. All ok, configuration edits are applied.
May close this bug.
Aug 20 2019
On vyos-1.2-rolling-201908201244-amd64.iso won`t reproduce. All ok, configuration edits are applied.
Hello, this function works great, but I think it could be better if we can specify a custom OID for each custom script. For exemple, LibreNMS needs to have specific OID to make automatic OS/hardware detection working : https://docs.librenms.org/Support/SNMP-Configuration-Examples/#linux-snmpd-v2
Thank you.
Aug 19 2019
Backported to crux
@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.
I just tested again.
Running on rolling VyOS-1.2-201908130337, same config as before, recursor.conf is ok.
Updated VyOS to rolling VyOS-1.2-201908190337, reboot, check recursor.conf. The domain forwarding is missing.
Reboot again, it's back in the recursor.conf.
Aug 18 2019
@dmbaturin ok, will address that in the next rewrite
@alkersan Looks good, thanks!
I've also tested this on the newly released dune1.11.1 with the same result
Aug 17 2019
Also the subtask T1524 should be part of this migration script as if the new allow-from node does not exist it should be populated by the current hard-coded addresses of 0.0.0.0/0 and ::/0