The forced change of the generated admin password was a session flag
set at login when the password still matched data/admin_password. A
new session after the file was gone bypassed it.
- UserAttributes.must_change_password (migration 0007) holds it; the
admin created with a generated password gets it, and a password
change clears it. ForcePasswordChangeMiddleware reads it.
- A system check (accounts.E001) stops the server unless the middleware
follows AuthenticationMiddleware; the README has the settings change.
- If the generated password cannot be stored privately, provisioning
stops without printing it and without creating the admin (one
transaction for the user and its attributes).
- The admin is provisioned on any real migrate run while no user
exists, so running migrate again after a failure creates it; flush
(plan=None) and rollbacks of accounts are skipped.
- The post_migrate receivers check the migration state for the models
they use, so a targeted migrate on a fresh database (e.g. migrate
appsettings) no longer fails with 'no such table'.
In Docker, migrate runs as root while data/ belongs to www-data, so a
planted data/admin_password symlink would make root overwrite its target.
Remove any existing path first and create the file with
O_CREAT|O_EXCL|O_NOFOLLOW (mode set via fchmod). install.sh's /tmp
fallback log is now created with mktemp instead of a fixed name.
- The generated admin password is written to data/admin_password (mode
0600) instead of being printed, so it no longer ends up in the install
log or `docker logs`. If the file cannot be written it is printed as
before, so the admin is never locked out.
- webvirtcloud.sh no longer echoes the generated SECRET_KEY.
- install.sh creates the install log with mode 0600.
