Repository navigation
truenas-appliance-runner: read node B's ids in the call that sees its new boot, not in a later one sshd may refuse - #25
Conversation
… new boot, not in a later one sshd may refuse
| # B's ids are read in the same call that sees the new boot, not in another | ||
| # one after it: sshd answering once does not mean it stays up. Middleware | ||
| # applies its own SSH settings as it starts and restarts sshd, and in run |
There was a problem hiding this comment.
LOW — This comment states as fact that middleware "restarts sshd", but the PR description calls that cause a reading, not confirmed. The code doesn't depend on which cause it is, but these comments are where the repo records why things are the way they are. Something like "most likely restarts sshd" would keep the record accurate if the real cause turns out to be different.
|
One finding: one LOW. No human review needed. The change reads node B's boot id, machine-id and hostid in one SSH call, so the call that sees the new boot also returns the IDs. That removes the later
LOW — the new comment at Separately, |
Why
#24 made
unique()wait until node B answers SSH from a new boot after its reboot. webui run 39296815434 still failed at the same step:ssh: connect to host 10.231.0.12 port 22: Connection refused.So sshd answering once does not mean it stays up. SSH on the nodes is enabled through middleware (
tnctl enable-ssh), and middleware applying its SSH settings as it starts most likely restarts sshd. That cause is a reading, not confirmed.Change
The loop's SSH call now returns B's boot id and its machine-id and hostid together. The call that sees the new boot also yields the IDs, so nothing depends on sshd staying up afterwards. The API wait still follows, and it does not use SSH.
Testing
shellcheck -x appliance.sh ha.sh lib.sh(the CI command) passes.ssh_: refused twice, then the old boot, then a new boot. It kept waiting, took the new boot id and the IDs from that one call, and the "still has A's ids" check passed.