For completeness let me link this back to discussion here: https://github.com/vyos/vyos-1x/pull/1024#issuecomment-1399908479
TL;DR I do not believe this bug needs to be re-opened, what was likely identified is a different, unrelated, limitation of pdns-recursor that affects the newer authoritative DNS functionality.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Yesterday
Tue, Mar 12
Mon, Mar 11
Dec 29 2023
Jan 23 2023
Apr 5 2022
Oct 12 2021
Oct 11 2021
Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.
Oct 10 2021
I surveyed all the hardware I have to see what kind of UUIDs they report:
Oct 5 2021
Yeah, that seems reasonable to me. I would prefer not add clutter to the system node if it can be avoided.
That seems fair, basically make the DUID generation deterministic. There is some defined structure to the DUID format, I think this would be a "type 3 DUID" per this document: https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/dhcp-unique-id-servers-clients-overview.html.
Oct 3 2021
Sep 27 2021
Adding a few notes here:
- The ideal behavior probably depends on which PKI elements are changed and what services depend on them.
- E.g. OpenVPN does not require a server restart for a CRL change (see https://openvpn.net/community-resources/controlling-a-running-openvpn-process/), but changing the CA or server cert/key would require a restart.
- It seems like there are some swanctrl commands that can conditionally reload parts of the config too without taking all tunnels down
- The former might be useful if you need to renew server certs or something like that and want to do so with the minimal impact
Sep 19 2021
Pull request: https://github.com/vyos/vyos-1x/pull/1010
Sep 17 2021
Tested on latest build VyOS 1.4-rolling-202109160217 and confirmed it is adding the remote id attribute by default as expected. Connections establish without issue.
Sep 15 2021
Sep 14 2021
Booted my host with 1.4-rolling-202109140217 and confirmed pfs enabled is now generating the expected swanctl.conf file to match the old behavior. If I don't report back in exactly an hour from now that my tunnels died, we can assume the fix works.
Sep 13 2021
Note: config versions were added to the default configs here https://github.com/vyos/vyos-build/commit/23639568a945f19471af88547dab45b87bbd642d, but the current vyos-build-ami replaces the default file with its own that hasn't been modified to add the versioning comment yet. That can probably be fixed whenever that repo is updated for equuleus (I have my own patched local branch that I could publish if desired).
cc: @c-po maybe this was a side effect of unifying the two parsers
Sep 11 2021
FYI, if your OpenVPN config relies on cert files or anything you uploaded into the config directory, you may need to change the owner to the openvpn user or widen file permissions. Oddly this only seems to affect equuleus, not sagitta (OpenVPN seems fine reading files owned by "root" out of "/config/auth").
Nov 14 2020
Your revert appears to do the trick. Image booted fine with QAT enabled, and "show system acceleration qat status" shows the QAT device came up fine and is running happily.
Nov 12 2020
Sure—if you want to drop me an image I can try it out. I do have a working vyos-build as well, I can also try and produce my own with that change backed out when I get some time towards the end of the week.
Nov 10 2020
I will perform a few additional tests tomorrow with the oldest available rolling releases (looks like October 13th as of writing). Will see if I can binary search my way to when things broke.
A few updates... the failure still occurs on latest rolling. Similar outcome—the kernel panics and dumps a stacktrace during the initial boot-up configure process. However, this issue goes back further than I expected (and initially expressed in the ticket). I goofed up in my testing of 1.3-rolling-202010260327 by booting with a default config file without the QAT option.
Nov 3 2020
Oct 27 2020
Oct 6 2020
Pull request https://github.com/vyos/vyos-1x/pull/563
Oct 4 2020
Pull request: https://github.com/vyos/vyos-1x/pull/562