Let allod site check, update and rotate the hosting credential #163

New issue

Closed

opened 2026-09-06 23:05:07 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-09-06 23:05:07 +01:00

Contributor

Give the hosting credential a full lifecycle in allod site, so it can be checked, changed and rotated without re-entering every field or reaching for rclone directly.

Primary goals:

Check without deploying — a command that answers "does the stored credential still work" and prints nothing secret, so a suspect login is confirmed in a second rather than by attempting a publish.
Change one field — replacing a rotated password should not require retyping the host and user, which is what invites a typo into the field that was previously correct.
Discoverable replacement — --force already overwrites (cmd/allod/site_config.go:63,93), but it reads as an escape hatch rather than as the way to update a credential, and it is only mentioned in the refusal message.
No plaintext on the way through — reading a value back for comparison must not print it, and any new path keeps the existing property that the password never reaches argv.

Current state and specifics

allod site config (cmd/allod/site_config.go:59) creates the remote and refuses when one exists unless --force (cmd/allod/site_config.go:93). So updating is possible but has three rough edges:

Task	Today	Wanted
Verify the stored credential	deploy and see whether it 530s	one command, no publish
Rotate the password	`--force`, retype host and user too	change the password alone
Inspect what is stored	`nix shell nixpkgs#rclone -c rclone config show`	an `allod` command, nothing secret printed

The third one is the sharpest. rclone is installed on the allod wrapper's PATH and not the operator's, so the natural debugging move fails with rclone: command not found and the operator has to know to reach for nix shell. That is a reasonable place to keep rclone, and it means this namespace has to expose whatever inspection is legitimately needed.

Whether the check belongs as allod site config --check, a separate allod site check, or as a flag on deploy is open; the constraint is that it must not publish and must not print the password.

Scope

In: verification, update and rotation of the credential this namespace owns, and whatever inspection replaces reading rclone's config by hand.

Out: the deploy preflight's own authentication, which is allod/tools#162 and which this should reuse rather than duplicate. Storing the credential outside rclone's config file is allod/tools#164.

Give the hosting credential a full lifecycle in `allod site`, so it can be checked, changed and rotated without re-entering every field or reaching for rclone directly. Primary goals: - **Check without deploying** — a command that answers "does the stored credential still work" and prints nothing secret, so a suspect login is confirmed in a second rather than by attempting a publish. - **Change one field** — replacing a rotated password should not require retyping the host and user, which is what invites a typo into the field that was previously correct. - **Discoverable replacement** — `--force` already overwrites (`cmd/allod/site_config.go:63,93`), but it reads as an escape hatch rather than as the way to update a credential, and it is only mentioned in the refusal message. - **No plaintext on the way through** — reading a value back for comparison must not print it, and any new path keeps the existing property that the password never reaches argv. ### Current state and specifics `allod site config` (`cmd/allod/site_config.go:59`) creates the remote and refuses when one exists unless `--force` (`cmd/allod/site_config.go:93`). So updating is possible but has three rough edges: | Task | Today | Wanted | | --- | --- | --- | | Verify the stored credential | deploy and see whether it 530s | one command, no publish | | Rotate the password | `--force`, retype host and user too | change the password alone | | Inspect what is stored | `nix shell nixpkgs#rclone -c rclone config show` | an `allod` command, nothing secret printed | The third one is the sharpest. rclone is installed on the `allod` wrapper's PATH and not the operator's, so the natural debugging move fails with `rclone: command not found` and the operator has to know to reach for `nix shell`. That is a reasonable place to keep rclone, and it means this namespace has to expose whatever inspection is legitimately needed. Whether the check belongs as `allod site config --check`, a separate `allod site check`, or as a flag on deploy is open; the constraint is that it must not publish and must not print the password. ### Scope In: verification, update and rotation of the credential this namespace owns, and whatever inspection replaces reading rclone's config by hand. Out: the deploy preflight's own authentication, which is `allod/tools`#162 and which this should reuse rather than duplicate. Storing the credential outside rclone's config file is `allod/tools`#164.

vnprc-agent referenced this issue

2026-09-06 23:05:26 +01:00

Allow the hosting credential to come from a named config path #164

vnprc-agent referenced this issue

2026-09-06 23:05:55 +01:00

Authenticate the hosting remote in the deploy preflight #162

vnprc-agent commented

2026-09-06 23:16:23 +01:00

Author

Contributor

Two measurements from the live failure that prompted this issue.

Storage is correct, so the lifecycle commands are about wrong values rather than corrupted ones. allod site config at cf384e8 was driven end to end against a real rclone with Tr1cky!Pass#with$pecials; rclone reveal returned it exactly. Obscuring, the terminal read, and the stanza writer all round-trip. That whole path had only ever been tested against stubs, so it was worth checking before building a "check" command on the assumption that what is stored is what was typed.

What actually failed live was a wrong username: this hosting exposes the FTP account under more than one plausible form, and the wrong one is indistinguishable from the right one until the server refuses it. So the verify command's job is to ask the server, and its output has to name which field it is complaining about as far as the protocol allows — 530 alone sends the operator to re-enter all three.

--force retyping everything is the sharp edge here. The live fix required re-entering host, user and password to correct one of them. Re-typing two already-correct fields to change a third is how a second error gets introduced during recovery, and it happened against a domain that was down at the time.

One defect to fix wherever inspection lands. cmd/allod/site_config.go:130 prints Check it with: rclone lsd shared: on success. That command does not exist for the operator — rclone is on the allod wrapper's PATH, not the user's, so it returns rclone: command not found. This issue's inspection command should replace that line rather than sit beside it.

Two measurements from the live failure that prompted this issue. **Storage is correct, so the lifecycle commands are about wrong values rather than corrupted ones.** `allod site config` at `cf384e8` was driven end to end against a real rclone with `Tr1cky!Pass#with$pecials`; `rclone reveal` returned it exactly. Obscuring, the terminal read, and the stanza writer all round-trip. That whole path had only ever been tested against stubs, so it was worth checking before building a "check" command on the assumption that what is stored is what was typed. What actually failed live was a wrong username: this hosting exposes the FTP account under more than one plausible form, and the wrong one is indistinguishable from the right one until the server refuses it. So the verify command's job is to ask the server, and its output has to name which field it is complaining about as far as the protocol allows — `530` alone sends the operator to re-enter all three. **`--force` retyping everything is the sharp edge here.** The live fix required re-entering host, user and password to correct one of them. Re-typing two already-correct fields to change a third is how a second error gets introduced during recovery, and it happened against a domain that was down at the time. **One defect to fix wherever inspection lands.** `cmd/allod/site_config.go:130` prints `Check it with: rclone lsd shared:` on success. That command does not exist for the operator — rclone is on the `allod` wrapper's PATH, not the user's, so it returns `rclone: command not found`. This issue's inspection command should replace that line rather than sit beside it.