rpcserver: Support dynamic cert reload. #3153
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davecgh
commented
Jul 10, 2023
davecgh
force-pushed
the
rpcserver_reloadable_certs
branch
from
07dbf1a
to
ab47b11
Compare
JoeGruffins
approved these changes
Jul 24, 2023
Comment on lines
+3302
to
+3306
| changed := fi.Size() != f.curSize || fi.ModTime() != f.curTime | ||
| if changed { | ||
| f.curSize = fi.Size() | ||
| f.curTime = fi.ModTime() | ||
| } |
There was a problem hiding this comment.
No big deal, but shouldn't the modified time be enough?
There was a problem hiding this comment.
Most of the time, yes, but it isn't always.
For example, it is quite common on some shared file systems to preserve the modification time when copying files. Another example is cp -p which various sync methods use.
davecgh
force-pushed
the
rpcserver_reloadable_certs
branch
from
ab47b11
to
a00201a
Compare
dajohi
approved these changes
Jul 24, 2023
This modifies the RPC server to support dynamically reloading (aka hot reload) the RPC certificate/key pair as well as the client CAs (when configured with --authtype=clientcert). In other words, dcrd will now notice when the certificates have been changed on the file system on new connections and reload and cache the new ones. In terms of deciding when to reload the files, this implementation opts for a highly portable stat-based approach that does not require any additional dependencies over using platform specific file change notifications such as inotify on Linux. This implementation also aims to provide nice error handling semantics and includes additional logic to minimize the amount of disk accesses needed to determine with the files have changed. The following is an overview of the semantics: - All connections used a cached TLS config - Certs are only tested for changes and reloaded when: - A new connection is established - At least 5 seconds have passed since the last check - The file modification times and/or sizes have changed - The existing working certs are retained if any errors are encountered when loading the new ones in order to avoid breaking a working config - Only a single error will be shown for attempt at loading an invalid config as opposed to spamming the same error on every new connection
davecgh
force-pushed
the
rpcserver_reloadable_certs
branch
from
a00201a
to
488b816
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This modifies the RPC server to support dynamically reloading (aka hot reload) the RPC certificate/key pair as well as the client CAs (when configured with
--authtype=clientcert).In other words, dcrd will now notice when the certificates have been changed on the file system on new connections and reload and cache the new ones.
In terms of deciding when to reload the files, this implementation opts for a highly portable stat-based approach that does not require any additional dependencies over using platform specific file change notifications such as
inotifyon Linux.This implementation also aims to provide nice error handling semantics and includes additional logic to minimize the amount of disk accesses needed to determine when the files have changed.
The following is an overview of the semantics: