Persist and restore TSIG keys for zone sources#626
Conversation
bal-e
force-pushed
the
persist-zone-source-tsig-keys
branch
from
1775511 to
e8cc640
Compare
|
Manual testing with the |
| // to the zones and policies being restored. | ||
| // Load the TSIG store file. | ||
| match state.tsig_store.init_from_file(&config) { | ||
| Ok(()) => debug!("Loaded the TSIG store"), |
There was a problem hiding this comment.
Inconsistent logging:
State::init_from_file()loads the file then logs at info level and notes the path that was loaded from.TsigStore::init_from_file()doesn't log, insteadmaindoes, and that log message doesn't mention the path that was loaded from.
Also, though not caused by this PR, neither for main state nor TSIG store state do we log the path we are trying to load from before loading, nor on error, so in the unhappy case the path used is not mentioned at all - unless I'm missing something.
There was a problem hiding this comment.
You're right; I've added a commit which logs every time.
|
|
||
| let mut state = center::State::default(); | ||
|
|
||
| // Load the TSIG store file. |
There was a problem hiding this comment.
Why would there be a TSIG store file if there was no state file?
There was a problem hiding this comment.
Maybe the user deleted the state file (or lost it) and doesn't want to re-enter their TSIG keys?
There was a problem hiding this comment.
Okay, but we don't generally support restoring from a partial/corrupted state, e.g. once the state file is lost any zone state files become orphans, those zones are no longer reflected in main state IIRC. This seems a bit inconsistent.
bal-e
force-pushed
the
persist-zone-source-tsig-keys
branch
from
4b1fe83 to
e7031df
Compare
2 participants
A re-implementation of #590. GH seems confused about that PR, so it's hard to see it's original diff, but I think this is the core of it.
Cargo.*,crates/,etc/,integration-tests/,src/):actthrough theact-wrapper(as described inTESTING.md)?