New PR for fixing it https://github.com/vyos/vyos-1x/pull/541

As discussed in the maintainer's slack channel will be good to replace CLI commands from set vpn anyconnect to set vpn openconnect. But in our docs we should use anyconnect-compatible server.

I don't see problems with clean installed latest rolling

NoCloud (and actually any datasource which provide network-config) must be supported now in VyOS 1.3. Feel free to test it.

The configuration module for 1.3 is compatible with both network-config versions now. Initial testing was successful, but let's keep this for some time to collect more cases.

@querubin please try booting with the vyos-configd service masked: add the kernel boot parameter:

Handling of all supported by VyOS configuration SSH key types was added to the VyOS 1.3 by this commit https://github.com/vyos/vyos-cloud-init/commit/d4004ac6ea1c7c03a35d9410f7c70ab423c926bb

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.

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.

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:

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 yes latest rolling release is working with your patch, thank you so much Sir.

PR https://github.com/vyos/vyos-1x/pull/539

@Cheeze_It
It would be great.

PR https://github.com/vyos/vyos-1x/pull/538

If you guys want, I can also try to test it out too...

@Hazza06 Can you check the latest rolling release?

@Dmitry in various reboots and real-config-tests we've seen it settle in a few seconds, and we've seen it do 121 failed again today: