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>
## 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>
Simon L.