General

Anything else.

Migrated sites lost their crontabs (cPanel to Enhance); audit apps that need cron

Imported from GitHub issue [El-SaMa/oma#231](https://github.com/El-SaMa/oma/issues/231) by @El-SaMa. --- Found 2026-10-15 via Jatta (laskutus.terapiajatta.fi, Invoice Ninja): reminders stopped after 2026-08-20. Crontab file for laskutus1 on laituri was created empty on 2026-08-28 (migration). - laituri and satama: every /var/spool/cron/crontabs file is 0 bytes, so no migrated site has any cron. - OMA cron add (portal, oma.manage_cron, App Market install cron) always failed with orchd 400 `missing field lineNumber`. Fixed in a6b8a70d. - ranta (2.29.17.109): SSH host key changed vs known_hosts, so not audited. Verify the key is legit first. To do: - [ ] List migrated sites that are not plain WordPress (Laravel, Invoice Ninja, custom PHP) and add their scheduler crons with the site PHP (/opt/ecp-phpXX/bin/php). - [ ] Check old cPanel crontabs in JetBackup if available, to restore exact jobs. - [ ] Confirm ranta host key change, then audit ranta. - [ ] Staff note: use /opt/ecp-phpXX/bin/php in cron, never bare php (node PHP 8.1).

BugOpenGeneral·12 days ago·0

Atelier: validate the agency placement pin against live servers (ranta is gone, all-zero id is not 'master')

Imported from GitHub issue [El-SaMa/oma#138](https://github.com/El-SaMa/oma/issues/138) by @El-SaMa. --- `reseller_accounts.app_server_id` pins an agency's new sites to one app node. Two problems found 2026-10-01: 1. **Deleted servers are accepted.** QA agencies were pinned to ranta (`933bd0fb-…`), which no longer exists in the hosting panel, so provisioning failed with `404: server` (agencies see the "capacity" reason). 2. **The all-zero id does not target the master.** The panel treats `00000000-0000-0000-0000-000000000000` as "no preference" and auto-places the site (a QA site landed on ns1). ## What - In `staffUpdateResellerAccount` (`services/core-api/src/reseller/account.ts`) / `oma.admin_reseller_account`, check `appServerId` against the live server list (the same source as `oma.admin_hosting_servers`) and refuse unknown ids with a clear error. Refuse the all-zero id, or document it as auto-placement. - Optionally show a warning in `/admin/resellers` when an agency is pinned to a server that no longer exists. - Update docs that still list ranta as an app node: `CLAUDE.md` access map and the web-A rule, and the handbook. ## Done when A pin to a non-existent server is refused, the all-zero id is handled explicitly, and docs no longer list ranta as a live node.

BugShippedGeneral·26 days ago·0

Crew website chat trusts a caller-supplied origin

Imported from GitHub issue [El-SaMa/oma#158](https://github.com/El-SaMa/oma/issues/158) by @El-SaMa. --- ## What is wrong `resolveWebsiteChatOrigin` in `apps/web/lib/crew/security.ts` returns `parentOrigin` from the JSON body when the request has no `Origin` header, or when `Origin` is a portal host (`oma.lanetti.fi`, `*.oma.lanetti.fi`, `localhost:3000`). The widget chat route (`apps/web/app/api/crew/widget/[siteKey]/chat/route.ts`) uses that value, and `runWebsiteCrewChat` checks it again with the same allow-list. The site key is public in the embed snippet. There is no signature that the request came from the customer site. A caller can omit `Origin` and set `parentOrigin` to a site on that widget's allow-list. The chat then runs: Crew credits are spent, leads can be stored, and the reply is returned. No login is required. ## Fix Trust the browser `Origin` only. Do not accept `parentOrigin` from the body as proof of the visitor site. If the embed iframe must name its parent, sign that value (widget key or a short-lived token minted for the allowed origin) and reject anything else. ## Found Read-only review of `origin/main`, 8 Oct 2026. Not confirmed against the live server.

BugShippedGeneral·19 days ago·0

Glama: dovecot sieve cannot write spam-global.svbin (read-only), warning on every delivery

Imported from GitHub issue [El-SaMa/oma#142](https://github.com/El-SaMa/oma/issues/142) by @El-SaMa. --- Every local delivery on Glama logs: ``` lmtp(...): Error: open(/etc/dovecot/spam-global.svbin.glama.lanetti.fi....) failed: Read-only file system sieve: binary /etc/dovecot/spam-global.svbin: save: failed to create temporary file ``` Mail is still stored (`stored mail into mailbox 'INBOX'`), so this is noise plus a recompile of the global spam sieve on every message. ## Careful CLAUDE.md: mail on Glama goes through the Enhance API, and appcd/Enhance-owned files are not hand-edited. Investigate whether Enhance ships a precompiled `spam-global.svbin` or a writable location. If it needs a config change, get operator approval and prefer the Enhance-supported way. ## Done when The cause is understood and either fixed the supported way or documented as harmless Enhance behaviour.

BugShippedGeneral·26 days ago·0

CRITICAL: cpanel_credentials RLS policy is non-functional (using(true))

Imported from GitHub issue [El-SaMa/oma#95](https://github.com/El-SaMa/oma/issues/95) by @El-SaMa. --- **Severity: Critical — active in production** \`packages/db/migrations/0051_cpanel.sql\` lines 24-26, 52-54: \`cpanel_credentials\` and \`cpanel_provisioned_service\` RLS policies are named \`"staff only"\` but their predicate is literally: \`\`\`sql using (true) with check (true) \`\`\` This grants **any authenticated (or anon, depending on grants) role** full read/write access to cPanel API tokens and provisioned-account records — no access control at all. **Fix:** replace with \`using (is_any_staff_member()) with check (is_any_staff_member())\`, consistent with every other credential table (enhance_credentials, hetzner_settings, etc.). Must ship together with the \`is_any_staff_member()\` scoping fix (#1) so it doesn't just open the door to "any org owner" instead of "anyone."

BugShippedGeneral·4 months ago·0

CRITICAL: is_any_staff_member() grants platform-wide admin to any org owner

Imported from GitHub issue [El-SaMa/oma#94](https://github.com/El-SaMa/oma/issues/94) by @El-SaMa. --- **Severity: Critical — active in production** \`is_any_staff_member()\` (used by ~18 RLS policies: enhance_credentials, hetzner_settings root passwords, billing_settings, support_mail_*, enhance_db_node_credentials, etc.) checks \`memberships.role IN ('owner','admin','staff')\` with **no organization filter**. Any customer who owns their own hosting org (the normal state via \`organizations.owner_user_id\`) passes this check and gets platform-wide staff access to every other customer's data. App-layer equivalent (\`resolveRoleForUser\` in \`apps/web/lib/roles.ts\`) had the identical bug. **Fix drafted, not yet deployed:** - \`packages/db/migrations/0053_fix_staff_role_scope.sql\` — redefines \`is_any_staff_member()\` to check membership in one specific staff org UUID (Lanetti, \`edb40deb-e0ac-49f6-ab39-1efee07831a7\`) - \`apps/web/lib/roles.ts\` — \`resolveRoleForUser\` now scoped to \`STAFF_ORGANIZATION_ID\` **Prerequisite:** the platform operator (\`[email protected]\`) must be added as \`owner\` of the Lanetti org first, or this fix locks out the operator's own admin access (neither \`OMA_STAFF_EMAILS\` nor \`OMA_STAFF_ORGANIZATION_ID\` is set in production, so admin access currently depends entirely on the same unscoped membership lookup). **Exposure:** currently 13 real customer accounts have unintended \`owner\`-role-driven staff access.

BugShippedGeneral·4 months ago·0

siteManage i18n namespace missing from 19 of 22 locales

Imported from GitHub issue [El-SaMa/oma#104](https://github.com/El-SaMa/oma/issues/104) by @El-SaMa. --- **Customer-facing bug.** The \`siteManage\` translation namespace (used by \`database-users-panel.tsx\`, \`databases-list-panel.tsx\`, and the rest of the service-management panels — including the new Kanta IP-access-control panel) exists in only \`en.json\`, \`fi.json\`, and \`sv.json\`. The other 19 locale files (ar-EG, da, de, es, fr, hi, id, it, ja, nb, nl, pl, pt, ru, tr, uk, zh) are missing it entirely. Customers on any of those 19 locales see broken strings or English fallback on every service-management page right now. **Fix:** backfill the \`siteManage\` namespace into all 22 locale files (English copy as placeholder is acceptable short-term, but it needs to exist so the key doesn't throw/fallback silently). Expand \`i18n-validate.mjs\` to enforce strict parity for portal namespaces (currently only enforced for en/fi/sv), not just landing/marketing keys, and wire it into CI.

BugShippedGeneral·4 months ago·0

CRITICAL: deploy runs migrations with no dry-run, no pre-flight check, no halt-on-failure

Imported from GitHub issue [El-SaMa/oma#108](https://github.com/El-SaMa/oma/issues/108) by @El-SaMa. --- **Severity: Critical for a live solo-operator system.** \`migrate.mjs\` supports \`--dry-run\`, \`--baseline\`, and \`--to=\` flags — none are ever invoked. \`scripts/docker-stack-up.sh\` line 37-38 runs migrations blind, and line 41 starts containers regardless of whether the migration step succeeded. A broken migration leaves the stack running against a half-migrated schema with no automatic halt. CI also never dry-runs migrations against a throwaway DB, so a broken migration is only ever discovered live, during deploy, in production. **Fix:** 1. Add a CI step: \`docker compose run --rm migrate node migrate.mjs --dry-run\` against a throwaway Postgres, on every PR. 2. Make \`docker-stack-up.sh\` halt (non-zero exit, don't proceed to \`docker compose up -d\`) if the migrate step fails.

BugShippedGeneral·4 months ago·0

lamoi.fi: Enhance panel zone is stale (apex on dead WAN) while ns1/ns2 serve a hand-kept zone

Imported from GitHub issue [El-SaMa/oma#203](https://github.com/El-SaMa/oma/issues/203) by @El-SaMa. --- Found 2026-10-14 by the drift guard while issuing the lamoi.fi wildcard: a website in the Lanetti staff org has the domain lamoi.fi, and its panel DNS differs from what ns1/ns2 serve, e.g. apex A panel 91.152.236.68 (dead WAN) vs served 91.154.33.71, mysql.lamoi.fi panel 91.152.236.68 vs served 2.29.17.109, and dozens of live records (n8n, wiki, grafana, cloud, chat, ops, hs3, intowp, …) missing in the panel. Risk: any Enhance change on that website (DNS record, domain mapping) rewrites the whole lamoi.fi zone from the panel and breaks every lamoi.fi service plus the Lamoi network (lamoi.fi, *.lamoi.fi). Interim: ACME_DNS_DIRECT_ZONES=lamoi.fi makes the ACME helper write lamoi.fi on ns1/ns2 directly; oma.manage_site_dns refuses while drift exists. Fix options (operator decision): (a) remove lamoi.fi from that Enhance website if it is not needed there, so the zone is file-only for good; (b) align the panel with the live zone record by record (force), then keep using the panel. Until then: never touch lamoi.fi in the Enhance panel.

BugOpenGeneral·13 days ago·0

maxfort.fi: DKIM record missing

Imported from GitHub issue [El-SaMa/oma#167](https://github.com/El-SaMa/oma/issues/167) by @El-SaMa. --- DNS health engine (`dns_health`, `oma.read_dns_health`) flags maxfort.fi: DKIM missing. Zone is hosted by us, so the staff bell will keep firing. Fix via staff tools only: read the DKIM key from Enhance/Glama, then `oma.admin_dns_zone_read` → `oma.admin_dns_record` → `oma.confirm_tool`, verify with `oma.dns_lookup` and re-run the DNS health check. Do not touch MX/SPF/mail.* beyond adding DKIM. Show the diff to the operator before confirming.

BugShippedGeneral·15 days ago·0

SEO audit fetches a URL before the private-address check

Imported from GitHub issue [El-SaMa/oma#159](https://github.com/El-SaMa/oma/issues/159) by @El-SaMa. --- ## What is wrong `fetchUrl` in `services/core-api/src/seo-audit.ts` requests the submitted URL, following redirects, and only then calls `resolvePublicAddresses` on the final hostname. `normalizeAuditUrl` blocks a literal private IP and `localhost`. It does not resolve the name first. `resolvePublicAddresses` asks 1.1.1.1 and 8.8.8.8, not the address the connection actually used. Any signed-in customer can submit a URL (`apps/web/app/api/ai/seo-audit/route.ts`, 12 per rate-limit window). A redirect onto a LAN address is already sent before the later check throws. When that check fails, the body is dropped and the audit says the site did not respond, so this is the portal making an internal request, not a proven database read. If the server's own DNS and 1.1.1.1 disagree, the internal response is returned in the audit. Webhooks and uptime monitors already use `assertSafePublicHttpUrl` in `services/core-api/src/platform/ssrf-url.ts`, which resolves and rejects private addresses before the request. ## Fix Resolve and reject private, link-local, and metadata addresses before connecting. Pin the connection to the checked address so a later DNS change cannot swing it. Re-check every redirect the same way. Reuse `assertSafePublicHttpUrl` rather than a second checker. ## Found Read-only review of `origin/main`, 8 Oct 2026. Not confirmed against the live server.

BugShippedGeneral·19 days ago·0

Portal: footer links prefetch into www.lanetti.fi and log CORS errors on every page

Imported from GitHub issue [El-SaMa/oma#225](https://github.com/El-SaMa/oma/issues/225) by @El-SaMa. --- Every signed-in portal page logs console errors like: Access to fetch at 'https://www.lanetti.fi/status' (redirected from 'https://oma.lanetti.fi/status?_rsc=…') … blocked by CORS policy Same for /legal, /legal/privacy, /legal/terms, /tutorials, /news and news articles. Next.js Link prefetches these, oma.lanetti.fi redirects them to www.lanetti.fi, and the RSC fetch fails cross-origin (net::ERR_FAILED). Seen on /apps/uptime, /dashboard and the other app pages (2026-10-15 headless run). Fix: link straight to https://www.lanetti.fi/... with a plain <a> (or prefetch={false}) in the portal chrome/footer.

BugShippedGeneral·13 days ago·0

Uptime: heartbeat (push) monitors show an empty Advanced tab and a useless response-time chart

Imported from GitHub issue [El-SaMa/oma#219](https://github.com/El-SaMa/oma/issues/219) by @El-SaMa. --- Found in a click-through of /apps/uptime on 2026-10-15 (monitor "ops: disk space"). - Edit modal: the **Advanced** tab renders nothing for push monitors (only Cancel / Save). Hide the tab for push, or show one line saying heartbeats have no advanced options. - Detail modal: "Response time, last 24 hours" shows "Not enough checks yet" and "Avg — · min — · max —". Push beats have no latency, so hide the chart for push. - Card footer shows "Heartbeat (push) — #ops" because latency is null. Files: apps/web/components/uptime/uptime-monitor-form.tsx, uptime-monitor-detail.tsx, uptime-monitor-board.tsx. Check: https://oma.lanetti.fi/apps/uptime (open a push monitor, Edit, Advanced).

BugShippedGeneral·13 days ago·0

Uptime: 24 h uptime on the card differs from the detail view

Imported from GitHub issue [El-SaMa/oma#220](https://github.com/El-SaMa/oma/issues/220) by @El-SaMa. --- Same monitor, same minute: card shows **80.20%** (24 hours), detail modal shows **76.24%** (24 HOURS). Cause: the card uses the checker's live 24 h figure (KumaLiveStats.uptime24h in listUptimeMonitors), the detail computes up/(up+down) from getMonitorBeats(24) in services/core-api/src/uptime/stats.ts. Pick one source (checker figure when present, beats as fallback) in both places. Check: https://oma.lanetti.fi/apps/uptime (open "ops: disk space").

BugShippedGeneral·13 days ago·0

Uptime status page: "All systems operational" shown when the page has no monitors

Imported from GitHub issue [El-SaMa/oma#221](https://github.com/El-SaMa/oma/issues/221) by @El-SaMa. --- Builder preview with an empty layout shows a green **All systems operational** banner over "Nothing to show yet." A published empty page would claim everything works. overallStatus() in services/core-api/src/uptime/status-view.ts returns operational for an empty monitor list. Return unknown (or hide the banner) when no monitors are on the page, add a unit test. Check: https://oma.lanetti.fi/apps/uptime/status (Open builder, no sections).

BugShippedGeneral·13 days ago·0

Portal: Supabase realtime websocket handshake fails (wss://oma.lanetti.fi/realtime/v1/websocket)

Imported from GitHub issue [El-SaMa/oma#230](https://github.com/El-SaMa/oma/issues/230) by @El-SaMa. --- Seen on /apps/uptime/status in the 2026-10-15 headless run: WebSocket connection to wss://oma.lanetti.fi/realtime/v1/websocket?... failed: Error during WebSocket handshake (unexpected response). The same-origin Supabase proxy apparently does not pass the WebSocket upgrade for /realtime/v1, so any realtime subscription in the portal never connects. Check the edge/NPM and app proxy config for Upgrade/Connection headers on /realtime/v1, then confirm a 101 Switching Protocols.

BugOpenGeneral·13 days ago·0

Deploy train: container name conflict and workers build failure (2026-10-14)

Imported from GitHub issue [El-SaMa/oma#235](https://github.com/El-SaMa/oma/issues/235) by @El-SaMa. --- Two failed runs: 29baa0d8 'container name /oma-api-gateway is already in use' after removing MCP containers, then 62e84037 'target workers: failed to solve' at FROM node:22-alpine. The next run succeeded. Make the train remove stale named containers before recreate and retry a base image pull once. Log: /var/lib/oma-deploy-train/last-deploy.log.

BugOpenGeneral·12 days ago·0