installer: re-sync install.sh with canonical (release#43) - #433
Merged
Conversation
The canonical-drift job added in #432 went red on main immediately after that PR merged, which is the guard doing exactly its job on its first real run. pilot-protocol/release#43 landed overnight — "fix empty -email flag breaking the default install, and make re-runs safe" — so canonical moved from 988ddeb to 906deea while this repo's copy stayed at 988ddeb. That follow-up is a direct consequence of #432/release#42: once the installer actually started the services instead of only writing the unit files, a unit generated with an empty `-email ` flag became a real failure rather than dead config. release#43 adds a privilege gate (CAN_PRIV / PILOT_SUDO, never prompting), recovers an existing email from account.json/config.json on every run so re-runs don't drop the operator's address, and skips synthesised @nodes.pilotprotocol.network placeholders so they can't harden into an override that defeats a later `pilotctl set-email`. install.sh here is now byte-identical to release@51894f1 (sha256 906deea1…), which is also what the live URL serves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TeoSlayer
enabled auto-merge (squash)
July 28, 2026 10:37
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The
canonical-driftjob added in #432 went red onmainimmediately after that PR merged. That's the guard doing exactly its job on its first real run.pilot-protocol/release#43 landed overnight — "fix empty
-emailflag breaking the default install, and make re-runs safe" — so canonical moved988ddeb→906deeawhile this repo's copy stayed at988ddeb.Why that follow-up existed
It's a direct consequence of #432 / release#42. Once the installer actually started the services instead of only writing the unit files, a unit generated with an empty
-emailflag became a real failure rather than dead config.release#43 therefore:
CAN_PRIV/PILOT_SUDO) that never prompts —sudoonly whensudo -nalready succeeds, and no prefix at all when already root, since minimal containers often ship nosudobinaryaccount.json/config.jsonon every run, not just fresh installs, so a re-run can't silently drop the address the operator configured@nodes.pilotprotocol.networkplaceholders, so one can't harden into an override that outranks the account file and defeats a laterpilotctl set-emailThis PR
install.shis now byte-identical torelease@51894f1(sha256906deea1…), which is also what the live URL serves.bash -nandsh -nboth clean. Thecanonical-driftjob should go green, and with itmain.🤖 Generated with Claude Code