django-auth-ldap, python-ldap and pyasn1 move to
conf/requirements-ldap.txt. Installs without LDAP no longer need the
openldap and sasl headers that pip builds python-ldap with; the
installer and the README's system packages drop them, and the README's
LDAP section installs them with that file. The settings already work
without the module.
The Docker image and dev/requirements.txt keep LDAP, so CI still builds
and audits python-ldap.
The installer and the manual installation install four systemd units
(webvirt-cloud, webvirt-novncd, webvirt-socketiod, webvirt-worker) that
run as the web server's user with absolute paths and read
/etc/default/webvirtcloud. gunicorn, socketiod and the worker stop with
KillMode=mixed, so they wind down their own children. supervisor, its
installer code and the contributed systemd files go; the README gets
the update, rollback and a one-time move from supervisor, and the
installer refuses to run over a supervisor install. Docker keeps runit;
novncd's runit script is the one-line form of the others.
The installer's venv sees the system site packages, and pip keeps a
system package that meets a requirement. On openSUSE Leap 15.6 the LDAP
login thus ran on the distro's python-ldap 3.4.4 (CVE-2025-61911, a
filter-escaping bypass, and CVE-2025-61912) and pyasn1 0.5.0
(CVE-2026-30922 and others), which django-auth-ldap loads through
ldap.controls. python-ldap>=3.4.5 and pyasn1>=0.6.4 make pip install
fixed copies in the venv. python-ldap builds there, so openldap2-devel
joins the openSUSE package lists (installer, manual and development
setup) and the update steps. Checked in a fresh Leap 15.6 container
with the installer's package list: 3.4.8 and 0.6.4 from the venv,
ldap.controls imports.
- 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.
- Prevent baking SECRET_KEY into Docker image during collectstatic
- Persist runtime SECRET_KEY in data/secret_key volume or read from environment
- Remove sed-based injection of CSRF_TRUSTED_ORIGINS in favor of native os.getenv
- Avoid overwriting system python3 symlink on SUSE; auto-detect python 3.10+ binaries
- Make /etc/hosts entry in installer idempotent
- Add security notice regarding compute node VNC/SPICE port firewall isolation
- Relax libvirt-python and lxml version pins to allow precompiled distro packages
- Add PEP 508 environment marker to crypt-r (python_version >= 3.13) to avoid unnecessary C compilation on Python 3.12
- Add stdlib crypt fallback when crypt_r is not available in instances/views.py
- Make LDAP imports and configuration optional in settings.py.template
- Add --system-site-packages and missing packages in webvirtcloud.sh for RHEL/CentOS
- Update README with working Rocky Linux / RHEL / Fedora installation and local dev setup
conf/requirements.txt requires django-auth-ldap/python-ldap (added in
#600), which needs libldap2-dev and libsasl2-dev headers to build its
C extension. The Debian branch's PACKAGES list already has both, but
the Ubuntu branch was never updated to match, so a fresh install on
Ubuntu fails to build python-ldap's wheel, which aborts the entire
`pip install -r requirements.txt` — Django itself never gets
installed, and the app fails to start. Verified fix on a real Ubuntu
24.04 host.
webvirtcloud.sh's Ubuntu branch only matched 18.04/20.04/22.04, so
running it on 24.04 (Noble) silently no-ops the entire install block
instead of installing anything. Verified end-to-end on a real 24.04
host: with this check extended, the rest of the Ubuntu install path
(package list, venv setup, nginx/supervisor config) works unmodified.
