Felis

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
Lemon-miaow	8e7c7bbf24	fix(reaper): deliver pre-reap warnings for real — and never fake a delivery The §18 warning path had no delivery channel at all: no Warner implementation existed, `felis reaper` passed nil, and maybeWarn still stamped warned_3d_at/ warned_1d_at and counted `warned=N`. So every owned server was silently reaped 15 days after its last join with no notice, and the operator's only feedback said warnings were sent. Two changes close that: - Honest stamps: warned_* now records a DELIVERED notice. A nil Warner logs `warning suppressed — no warner wired` and does NOT stamp; a delivery error logs and retries on the next daily run (bounded by the warning window). The stamps are no longer burned by notices nobody received. - A real channel: mail.SendNotice (the second and last message shape the mail package sends) plus a mailWarner that resolves the owner's VERIFIED email and mails the notice through the configured [smtp] relay. `felis reaper` wires it when [smtp] is set (same password_ref convention as felis-api) and prints exactly what happens when it is not. Plumbing so the in-cluster CronJob can actually reach the relay: the reaper pod gets the optional FELIS_SMTP_PASSWORD env (same Secret as felis-api), and the "configure email" screen now refreshes the minecraft-namespace mirrors of felis-smtp AND felis-config (a secretKeyRef is namespace-local, and the config mirror is what carries [smtp] into the reaper's own config). `felis setup`'s replica list gains felis-smtp for fresh installs. Tests: the delivered/retried/suppressed matrix in internal/reaper (the old "stamp advances on failure" contract is deliberately replaced), the notice message shape, the warner's resolve/send/failure paths, and the CronJob's optional-secret env. docs/troubleshooting.md §10 now states the real semantics.	2026-09-23 03:47:19 +08:00
flyemoji	b3989fa4af	fix(mail): prove SMTP deliverability before saving, and stop losing the relay A live install passed the SMTP setup screen and then failed every one-time code with a bare `internal error`. Four separate defects had to line up for that, and each is fixed here. The relay was configured with `from = noreply@<domain-A>` on an account authenticated as `<user>@<domain-B>`. Providers that validate sender identity — Fastmail among them — answer MAIL FROM with an unconditional 250 and only refuse at end-of-DATA. Ping stopped at NOOP, so it never saw the refusal: the wizard reported success, wrote the config, rolled felis-api, and every OTP afterwards died at w.Close(). Ping now runs the same transaction a real code takes — connect, (STARTTLS,) AUTH, MAIL FROM, RCPT TO, DATA — delivering one self-test message to the From address, and SendOTP and Ping share deliver() so the check cannot drift from the thing it checks. The self-test recipient cannot cause a false negative: an authenticated submission relay accepts RCPT for any destination by definition, while the sender identity it does validate is exactly what we want tested. The setup screen now says a message will be sent, names the address it went to, and warns that From must be an address the account is allowed to send as. A relay refusal also answered 500 `internal`, which reads as a broken panel and sends the operator hunting through handler code instead of their [smtp] block. It is now 502 `mail_undeliverable`, mapped inside deliverOTP so all four doors that mail a code (onboarding, email login, op-login, migrate step-up) answer alike. The relay's own text stays out of the response — it can name the SMTP account, and these routes are reachable by any signed-in player — and goes to the log instead. writeError logged nothing when it collapsed an unmapped error to 500, so an operator holding an `internal error` had nothing to grep for and diagnosis degraded into guessing against a live install. It now logs the method, path, wrapped chain and the same request_id the caller is shown. Finally, write_felis_toml regenerated the config wholesale and never emitted [smtp], so re-running the installer — the documented way to update felis-api — silently erased a working relay and reverted OTP delivery to the no-Mailer path, logging codes instead of sending them. It now carries the block forward, cached on first read because the host toml is clobbered before the pod toml is written. Same defect family as the root_domain loss fixed in `ecbeb20`: a generated file holding a hand-set value with no carry-forward. Tests cover the case a MAIL FROM probe cannot see: a fake relay that answers 250 to MAIL FROM and 550 at end-of-DATA must fail both Ping and SendOTP, and the 502 must carry a distinct machine code without leaking the relay's text.	2026-07-21 00:11:40 +09:00
flyemoji	f0b79e9edd	feat(mail): deliver email one-time codes over SMTP and add the setup email screen Felis never actually sent mail: OTP codes for onboarding, email login and op-login were only written to the felis-api log behind a "demo has no SMTP" limitation, and the Settings/SMTP flow those comments promised was never built. Combined with the bootstrap Owner's address being recorded unverified (`87279a1`), op-login start always took the anti-enumeration neutral branch and minted a fake request_id, so the in-game approve inevitably answered "No pending operator sign-in with that code". Give the codes a real delivery path, configured in felis.toml rather than a web settings page so config keeps a single source of truth: - config: new [smtp] table (host, port defaulting to 587, from, username, password_ref). Validation requires a plausible from address and a sane port; the password itself never enters the config file. - internal/mail (new): stdlib net/smtp mailer implementing the api.OTPMailer seam. Port 465 dials implicit TLS, other ports upgrade via STARTTLS when advertised; AUTH only when a username is configured (PlainAuth itself refuses plaintext, so the password cannot leak to a TLS-less relay). Ping() proves reachability and credentials without sending mail. The message shape (CRLF, Q-encoded bilingual subject) is pinned by test. - platform: felis-smtp Secret constants and an optional FELIS_SMTP_PASSWORD env var on the felis-api Deployment, mirroring felis-uploads-s3. - cmd/felis api: construct the real mailer when [smtp] is configured; keep the log fallback otherwise and say so at startup. Warn when a username is set but the credentials env is empty. - setup TUI: "e" on the summary/status screen opens the email form (host, port, from, optional auth). Apply order: Ping preflight, [smtp] into both host and pod config files, felis-smtp Secret piped to kubectl via stdin, config Secret, felis-api rollout. A failed preflight leaves the install untouched. SMTP is deliberately not a wizard rail step: first-run stays mail-less by design, and the passkey minted at onboarding is the pre-SMTP owner credential. Also make PGRepo.UserByEmail match case-insensitively (lower(email) = lower($1)), honoring the interface contract and the users_verified_email_ unique partial index; the fake repo already matched with EqualFold. Existing installs need the felis-api Deployment manifest re-applied (e.g. a bootstrap re-run) before the new env var exists; a rollout restart alone cannot add it.	2026-07-20 10:24:52 +09:00

8e7c7bbf24

fix(reaper): deliver pre-reap warnings for real — and never fake a delivery

The §18 warning path had no delivery channel at all: no Warner implementation
existed, `felis reaper` passed nil, and maybeWarn still stamped warned_3d_at/
warned_1d_at and counted `warned=N`. So every owned server was silently reaped
15 days after its last join with no notice, and the operator's only feedback
said warnings were sent. Two changes close that:

- Honest stamps: warned_* now records a DELIVERED notice. A nil Warner logs
  `warning suppressed — no warner wired` and does NOT stamp; a delivery error
  logs and retries on the next daily run (bounded by the warning window). The
  stamps are no longer burned by notices nobody received.

- A real channel: mail.SendNotice (the second and last message shape the mail
  package sends) plus a mailWarner that resolves the owner's VERIFIED email
  and mails the notice through the configured [smtp] relay. `felis reaper`
  wires it when [smtp] is set (same password_ref convention as felis-api) and
  prints exactly what happens when it is not.

Plumbing so the in-cluster CronJob can actually reach the relay: the reaper
pod gets the optional FELIS_SMTP_PASSWORD env (same Secret as felis-api), and
the "configure email" screen now refreshes the minecraft-namespace mirrors of
felis-smtp AND felis-config (a secretKeyRef is namespace-local, and the config
mirror is what carries [smtp] into the reaper's own config). `felis setup`'s
replica list gains felis-smtp for fresh installs.

Tests: the delivered/retried/suppressed matrix in internal/reaper (the old
"stamp advances on failure" contract is deliberately replaced), the notice
message shape, the warner's resolve/send/failure paths, and the CronJob's
optional-secret env. docs/troubleshooting.md §10 now states the real semantics.

2026-09-23 03:47:19 +08:00

flyemoji

b3989fa4af

fix(mail): prove SMTP deliverability before saving, and stop losing the relay

A live install passed the SMTP setup screen and then failed every one-time
code with a bare `internal error`. Four separate defects had to line up for
that, and each is fixed here.

The relay was configured with `from = noreply@<domain-A>` on an account
authenticated as `<user>@<domain-B>`. Providers that validate sender identity
— Fastmail among them — answer MAIL FROM with an unconditional 250 and only
refuse at end-of-DATA. Ping stopped at NOOP, so it never saw the refusal: the
wizard reported success, wrote the config, rolled felis-api, and every OTP
afterwards died at w.Close().

Ping now runs the same transaction a real code takes — connect, (STARTTLS,)
AUTH, MAIL FROM, RCPT TO, DATA — delivering one self-test message to the From
address, and SendOTP and Ping share deliver() so the check cannot drift from
the thing it checks. The self-test recipient cannot cause a false negative:
an authenticated submission relay accepts RCPT for any destination by
definition, while the sender identity it does validate is exactly what we
want tested. The setup screen now says a message will be sent, names the
address it went to, and warns that From must be an address the account is
allowed to send as.

A relay refusal also answered 500 `internal`, which reads as a broken panel
and sends the operator hunting through handler code instead of their [smtp]
block. It is now 502 `mail_undeliverable`, mapped inside deliverOTP so all
four doors that mail a code (onboarding, email login, op-login, migrate
step-up) answer alike. The relay's own text stays out of the response — it
can name the SMTP account, and these routes are reachable by any signed-in
player — and goes to the log instead.

writeError logged nothing when it collapsed an unmapped error to 500, so an
operator holding an `internal error` had nothing to grep for and diagnosis
degraded into guessing against a live install. It now logs the method, path,
wrapped chain and the same request_id the caller is shown.

Finally, write_felis_toml regenerated the config wholesale and never emitted
[smtp], so re-running the installer — the documented way to update felis-api —
silently erased a working relay and reverted OTP delivery to the no-Mailer
path, logging codes instead of sending them. It now carries the block forward,
cached on first read because the host toml is clobbered before the pod toml is
written. Same defect family as the root_domain loss fixed in ecbeb20: a
generated file holding a hand-set value with no carry-forward.

Tests cover the case a MAIL FROM probe cannot see: a fake relay that answers
250 to MAIL FROM and 550 at end-of-DATA must fail both Ping and SendOTP, and
the 502 must carry a distinct machine code without leaking the relay's text.

2026-07-21 00:11:40 +09:00

flyemoji

f0b79e9edd

feat(mail): deliver email one-time codes over SMTP and add the setup email screen

Felis never actually sent mail: OTP codes for onboarding, email login and
op-login were only written to the felis-api log behind a "demo has no SMTP"
limitation, and the Settings/SMTP flow those comments promised was never
built. Combined with the bootstrap Owner's address being recorded unverified
(87279a1), op-login start always took the anti-enumeration neutral branch and
minted a fake request_id, so the in-game approve inevitably answered "No
pending operator sign-in with that code".

Give the codes a real delivery path, configured in felis.toml rather than a
web settings page so config keeps a single source of truth:

- config: new [smtp] table (host, port defaulting to 587, from, username,
  password_ref). Validation requires a plausible from address and a sane
  port; the password itself never enters the config file.
- internal/mail (new): stdlib net/smtp mailer implementing the api.OTPMailer
  seam. Port 465 dials implicit TLS, other ports upgrade via STARTTLS when
  advertised; AUTH only when a username is configured (PlainAuth itself
  refuses plaintext, so the password cannot leak to a TLS-less relay).
  Ping() proves reachability and credentials without sending mail. The
  message shape (CRLF, Q-encoded bilingual subject) is pinned by test.
- platform: felis-smtp Secret constants and an optional FELIS_SMTP_PASSWORD
  env var on the felis-api Deployment, mirroring felis-uploads-s3.
- cmd/felis api: construct the real mailer when [smtp] is configured; keep
  the log fallback otherwise and say so at startup. Warn when a username is
  set but the credentials env is empty.
- setup TUI: "e" on the summary/status screen opens the email form (host,
  port, from, optional auth). Apply order: Ping preflight, [smtp] into both
  host and pod config files, felis-smtp Secret piped to kubectl via stdin,
  config Secret, felis-api rollout. A failed preflight leaves the install
  untouched. SMTP is deliberately not a wizard rail step: first-run stays
  mail-less by design, and the passkey minted at onboarding is the pre-SMTP
  owner credential.

Also make PGRepo.UserByEmail match case-insensitively (lower(email) =
lower($1)), honoring the interface contract and the users_verified_email_
unique partial index; the fake repo already matched with EqualFold.

Existing installs need the felis-api Deployment manifest re-applied (e.g. a
bootstrap re-run) before the new env var exists; a rollout restart alone
cannot add it.

2026-07-20 10:24:52 +09:00