A workaround

PR from @ronie https://github.com/vyos/vyos-documentation/pull/317

Ok, so this now waits for T2854. I've already drafted some partial implementation and would like to base it on the architecture introduced in that task.

Latest rolling has this fixed. Thanks Viacheslav.

@Maltahl try the latest rolling release.

I think stricter validation should only be added to 1.3 so that 1.2 LTS behaviour remains stable.

I hacked this into VyOS/Vyatta some 5 years ago - all it took was commenting out a snippet in Zone.pm and /opt/vyatta/share/vyatta-cfg/templates/zone-policy/zone/node.tag/from/node.def to prevent VyOS from complaining when creating a zonex_to_zonex chain

Intel QAT works for CRUX brunch. As for rolling with the newest kernel 5.8.5, it seems some issues on the modules building stage.

Issue seems to be related to quote handling. OS seems to have version as 1.2.5 and GRUB file shows "1.2.5". show system image reflects the GRUB name. If I manually remove the quotes from the GRUB file, I can successfully rename and delete the image.

From official docs

@c-po I build qat manually but add --enable-qat-lkcf to https://github.com/vyos/vyos-build/blob/crux/packages/linux-kernel/build-intel-qat.sh#L55 and it seems it works

vyos@R2-QAT:~$ show system acceleration qat device qat_dev0 flows 
+------------------------------------------------+
| FW Statistics for Qat Device                   |
+------------------------------------------------+
| Firmware Requests [AE  0]:              147225 |
| Firmware Responses[AE  0]:              147225 |
+------------------------------------------------+
| Firmware Requests [AE  1]:              113758 |
| Firmware Responses[AE  1]:              113758 |
+------------------------------------------------+
| Firmware Requests [AE  2]:              144886 |
| Firmware Responses[AE  2]:              144886 |
+------------------------------------------------+
| Firmware Requests [AE  3]:              147221 |
| Firmware Responses[AE  3]:              147221 |
+------------------------------------------------+
| Firmware Requests [AE  4]:              113774 |
| Firmware Responses[AE  4]:              113774 |
+------------------------------------------------+
| Firmware Requests [AE  5]:              144891 |
| Firmware Responses[AE  5]:              144891 |
+------------------------------------------------+

The perl scripts didn't create any config line, that's why I'm asking. I have it already implemented and successfully tested with the new python code, but wonder how people were able to use it all by just using the cli. I may need somebody for testing with AD, since I don't have access to any AD environment anymore.

Tested on 1.3-rolling-202009060846

PR https://github.com/vyos/vyos-build/pull/124

Large enterprises usually use LDAP/AD to authenticate and log its users web browsing, so this should be added. Anonymous binding is kinda old fashioned so maybe it was a bug.

Does anyone know if ldap auth worked at all with the old perl backend? I try to find out how likely I need to migrate cli entries. from what I have seen, ldap auth with anonymous ldap browsing didn't generate any required config for squid.

I agree, a separate DNS would be way easier to maintain if you have a lot of TLDs you need/want to block, since squid has to load it from a list, let's see if anyone is still using that, other wise it would be nicer and easier to scrape that off and implement a nameserver tag node win the cli.

And PR for vyos-1x: https://github.com/vyos/vyos-1x/pull/540

PR for vyos-build: https://github.com/vyos/vyos-build/pull/123

I've previously mentioned light blocking (domain level, gTLD level), but with the increasing amount of DoH, having a means to kill off DoH and force special DNS processing, including offload to a separate DNS server (managed by a security appliance for example, say PiHole or similar) would be valuable.

Is there any interest in the following scenarios:

Tested with:

set service dns dynamic interface eth0.203 service custom host-name 'test.vyos.net'
set service dns dynamic interface eth0.203 service custom login 'vyos'
set service dns dynamic interface eth0.203 service custom password 'vyos'
set service dns dynamic interface eth0.203 service custom protocol 'dyndns2'
set service dns dynamic interface eth0.203 service custom server 'vyos.io'

This also happens on service deletion

Looks like it's a floating bug - I've just sucscessfuly disabled a vti interface on another router (running vyos 1.2.6-epa1).

In T2508#74559, @dongjunbo wrote:

why don't we chang unbound to coredns ? Coredns will be more stronger thant unbound.

why don't we chang unbound to coredns ? Coredns will be more stronger thant unbound.

@Viacheslav it happened yesterday again but the stack trace was different. This time it was complaining that BGPD did not respond and the frr watch process tried to restart it, which of course did not help the situation.
I will continue to monitor but i think we can close this issue and wait for more details when it happens again.