The snap migration section had several issues that caused the database
conversion step to fail (as reported at
https://help.nextcloud.com/t/migration-from-snap-installation-to-docker-aio/246329):
- The conversion container overrode the entrypoint with `--entrypoint bash`,
so the Nextcloud source was never rsynced from /usr/src/nextcloud to
/var/www/html. occ was missing and, with the config mounted to the wrong
path, occ reported "Nextcloud is not installed". Now the container runs
with its normal entrypoint (no admin/DB env vars, so it stages files
without installing) and occ is invoked via `docker exec`.
- The temporary config is now mounted to /var/www/html/config/config.php and
made writable (chmod 666) since db:convert-type writes the new DB settings
back into it as www-data.
- The temporary MySQL container now starts with --skip-log-bin to avoid the
"You do not have the SUPER privilege and binary logging is enabled" import
error.
- The SNAP_DATA mount is read-write since the conversion writes to the data
directory.
- Updated the version placeholder example and corrected the typical snap
datadirectory path.
Verified end-to-end with real MySQL/PostgreSQL/Nextcloud containers: the
conversion runs clean and pg_dump produces a valid database-dump.sql.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
- Remove HARP_K8S_BEARER_TOKEN_FILE: HaRP already defaults it to the
in-cluster service account token path, so templating it added nothing.
- Add HARP_SERVICE_ACCOUNT_NAME so the harp pod can run under a service
account the user grants the required RBAC to, and document the setup.
- Correct the HARP_K8S_HOST_ALIASES docs: it is a comma-separated list of
hostname:ip pairs, not JSON.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
When harp syncs over from the manual-install to the helm chart it needs
the Kubernetes backend (HP_K8S_*) instead of the docker backend. The
update-helm script now injects these env vars into the harp deployment,
templated to values.yaml, and the chart readme documents them.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
## Summary
- Integrates Desec into the AIO interface which simplifies the domain
registration and domain setup.
- You can either create a new account directly or use an existing
account.
- You have a button that you can open where the process will be done.
After the process is done, the whole page reloads and you can continue
with the setup.
- Caddy and dnsmasq community containers will be activated during the
process which will take over the cert generation and enable split-brain
dns.
- Community containers will work automatically for example Vaultwarden
as the subdomains of the desec domain point automatically via a wildcard
dns entry towards the main desec domain.
- Playwright tests are added to ensure that the system works as expected
in the future
- the desec api is mocked via a small node js based file.
- the qa and other docs were updated to mention desec
A slug typed into the deSEC form was lost when the form re-rendered after a
201 redirect (e.g. on the awaiting-verification step), forcing the user to
re-enter it. Persist the requested slug in the AIO config when register()
runs and pre-fill the slug input from it on every step, then clear it once a
domain is set. Stored in configuration.json rather than a URL parameter so it
survives the multi-step flow without leaking into the iframe address.
Signed-off-by: Simon L. <szaimen@e.mail.de>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The containers page showed "Reveal deSEC password" for every deSEC domain,
but when the user logs in with their own existing account AIO stores an
empty password, so the reveal exposed nothing useful. Gate the reveal on a
stored password: AIO-created accounts show the generated credentials as
before; existing accounts now just say the domain is managed via that
account and to log in at desec.io with your own password.
Also clear the stored generated password in the awaiting-verification path
when the user logs in with their own password (the email already had an
account), so a non-empty stored password reliably means "AIO generated this
account" — and report the account as not-new so no wildcard CNAME is created
on a domain the user manages themselves.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
Logging in with an existing deSEC account and entering a slug you already
own failed with "Domain limit exceeded": registerDomain() always tried to
POST /domains/, which deSEC rejects (403 when the account is at its quota,
400/409 when the name is taken) even though the domain belongs to you.
Now, for a user-specified slug, a 400/403/409 triggers an ownership check
(GET /domains/{name}/); if the account already owns the domain it is reused
and registration completes. Otherwise a clear message is shown (over-limit
vs. taken by someone else). Random-slug registration is unchanged.
Update the deSEC mock to mirror the real status codes (per-account ownership,
domain limit -> 403, taken name -> 400, GET /domains/{name}/) and add a spec
that exercises the over-limit ownership-recovery path.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
dnsmasq runs in host network mode and auto-detects the host's LAN IP. On
Docker Desktop (Windows/macOS) containers run inside a Linux VM isolated
from the real host LAN, so detection yields the wrong IP and local DNS
resolution does not work. Call this out in the dnsmasq readme and the
in-app deSEC domain notice.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
The deSEC registration entry point now renders regardless of
SKIP_DOMAIN_VALIDATION (it was moved out of the skip-validation guard), and
the deSEC flow already sets the domain with validation skipped internally.
Remove the now-unnecessary SKIP_DOMAIN_VALIDATION=false override from the
deSEC Playwright steps in both workflows and update the stale spec comment.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
The deSEC entry <details> was moved up above the domain submit form, but the
#desec-modal container and desec-modal.js were left behind inside the
skip_domain_validation block. Move them up to sit directly after the entry
block so the open button, modal, and wiring script are always rendered
together (and present even when domain validation is skipped). This restores
the modal flow the Playwright tests drive via #desec-frame.
Signed-off-by: Simon L. <szaimen@e.mail.de>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
Hide the "Your deSEC login credentials" block during the in-flight
register/verify steps — the credentials are still shown in the dedicated
"deSEC account credentials" section once the domain is registered.
Extract the deSEC domain info/dnsmasq-caution notice into a reusable include
and also show it at the top of the initial-install flow, directly above the
"download and start containers" explanation, while keeping it in the
Community Containers section where it already appeared.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
The email input was unstyled because input[type="email"] was missing from
the text/password input rules, and the deSEC form's inline-block inputs
flowed side by side. Add the email type to the input styling rules and lay
the deSEC modal form out as a vertical stack with full-width inputs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Simon L. <szaimen@e.mail.de>
dependabot[bot]