set service https certificates certbot
domain-name(s) should contain the desired server-name. A rewrite is in progress in:
https://phabricator.vyos.net/T2289
set service https certificates certbot
domain-name(s) should contain the desired server-name. A rewrite is in progress in:
https://phabricator.vyos.net/T2289
It exists:
https://phabricator.vyos.net/T1585
This still needs to be integrated into check-qemu-install before PR:
https://github.com/vyos/vyos-1x/compare/current...jestabro:vyos-configtest
Thanks @Viacheslav; I'm running other tests with vyos-load-config at the moment, and will check and add.
Ongoing discussion in the forum on this matter:
https://forum.vyos.io/t/commit-causing-vyos-configd-service-to-exit-and-restart/5945
Summary to follow when there is a reproducer.
@Viacheslav et. al. note that the succinct Mem-Info message shown above was added after v4.19 (commit ef8444ea), so was only seen during the brief window when we moved to 5.8 before reverting the kernel version, due to QAT issues and a bug affecting parted.
@querubin thanks for the info; that requirement should not persist, as current work should lessen the overhead. I'll link the task back here when defined.
@querubin Thank you for the detailed results --- firstly, these issues may be overdetermined due to several updates earlier this month; one notable issue is that we had moved to a 5.x series kernel, which showed several problems re QAT support, and an identified kernel bug. We have reverted to 4.19 as of yesterday until the next LTS kernel is available. I would suggest trying the most recent rolling, and then we will diagnose any persistent issues.
This is resolved by T2332; the normalized form is:
Taking a look ...
@querubin please try booting with the vyos-configd service masked: add the kernel boot parameter:
Resolved in PR536.
@thomas-mangin in further tests, I've seen wide variability in timing tests, independent of caching, with the original quote being the high-end. That will need to be investigated, but I think performance should not be considered a road-block for now.
@tux, this has been fixed in the current rolling.
FRR 7.4 has been released, and the default behaviour has been changed, commit 62282e8379. @Viacheslav, when we update to this version, I can work with you to update the migration script.
As discussed in above comment, this is understandable behaviour, but will be re-investigated after the move to fastapi, re T2397.