fix(operator-docs): DNS bootnode in chain-spec + OPERATOR_KIT (#433) - #40
fix(operator-docs): DNS bootnode in chain-spec + OPERATOR_KIT (#433)#40realdecimalist wants to merge 3 commits into
Conversation
The previously-listed ID was from when materios-node ran in docker as a named container; the node now runs as a native systemd binary and re-derived its libp2p key, so the reserved-nodes multiaddr was unreachable. Real ID via system_localPeerId: 12D3KooWPueKoxRAirTTKH4Y2qQAsJDegWMjS4k89Z7izCbZKgkM Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
chain-spec-raw.json bootNodes pointed at the Hetzner bastion (/ip4/5.78.94.109) with a non-canonical peer id; OPERATOR_KIT.md Diagnostic 2 hardcoded a dead Gemtek egress (/ip4/166.70.250.197). Both now use the canonical DNS bootnode. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X3eiXihFLzQHgQywVZVKQi
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8bd8b251ac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ``` | ||
| If your hash matches canonical, the snapshot is fine and the issue is sync-protocol (proceed to D2). If it differs, your snapshot is from a forked chain — request a fresh one. | ||
|
|
||
| **Diagnostic 2 — isolate sync to a single trusted peer.** Stop the node, edit `/etc/systemd/system/materios-node-spo.service` (the `ExecStart` line), and add: |
There was a problem hiding this comment.
For operators who used the recommended bootstrap/operator-kit path documented above, the installer writes an $OPERATOR_DIR/docker-compose.yml and runs the node as a Docker Compose service; it does not create /etc/systemd/system/materios-node-spo.service. In that environment this troubleshooting step sends them to edit a non-existent unit, so the reserved-node workaround will not be applied when they hit the peer-ban loop. Please direct these users to update the generated Compose command and restart materios-node with Docker Compose, or gate the systemd instructions to deployments that actually use that unit.
Useful? React with 👍 / 👎.
1 participant
chain-spec-raw.json bootNodes + OPERATOR_KIT.md --reserved-nodes: bastion/dead-IP → /dns4/bootnode.materios.fluxpointstudios.com. NOTE for reviewer: chain-spec id=materios_local / chainType=Local left unchanged (flag if intended otherwise). 🤖 Generated with Claude Code