The daily workflow already had a gate, but it could never say no: both of its
version comparisons were guaranteed to differ.
The image installs samba from trixie-security (2:4.22.10+dfsg-0+deb13u2) while
decide-build.sh read only trixie/main (...u1), so the versions never matched.
And image-info recorded the kernel as the ABI string from /boot/vmlinuz-*
(6.12.107+deb13-amd64), which is a package-name suffix, while the script
compared it against the archive's package version (6.12.107-1) — two formats
that cannot match by construction. Either one alone forced a build; together
they produced a fresh multi-hundred-megabyte release every morning for nothing.
Merge trixie, trixie-updates and trixie-security before picking the newest
version, and record kernel_version in image-info so there is something
comparable on both sides. Compare with dpkg instead of sort -V, which
mishandles epochs and tildes, and with "gt" instead of "!=" so an image that is
somehow ahead of the archive cannot spin in a rebuild loop.
Verified against the live archive and a stubbed release API: archive == image
now yields build=no, and the samba, kernel, age, first-build and
image-ahead-of-archive branches all decide correctly.
Releases published before this change carry no kernel_version, so the kernel
check is skipped for them and says so on stderr rather than passing silently.
The next build closes that gap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Builds a Debian image that MAAS deploys to bare metal as an Active Directory
domain controller, with first-boot automation that either creates a domain or
joins an existing one without anyone logging in. To a Windows client the result
is an AD domain: same Kerberos, same LDAP, same Group Policy, same domain join.
The request was for "primary and backup domain controllers", which is NT 4
terminology. Active Directory has no such split — every DC holds a writable copy
and any of them can service a logon. What lives on one DC at a time are the five
FSMO roles, one confusingly named "PDC Emulator". The image therefore offers
provision (create the domain) and join (add another equal DC), which is the
distinction that actually exists.
Contents:
* customize-samba-ad.sh, run inside the packer-maas build VM: installs samba,
winbind, Kerberos, chrony and rsync, swaps the cloud kernel for the generic
one, and deletes every trace of a domain so one image can produce many DCs
* adc-maas-init, a first-boot state machine covering /etc/hosts, node-unique
identifiers, time, the resolver, provisioning or joining, the service
switchover and a self-test that proves Kerberos issues a ticket
* adc-sysvol-sync, a systemd timer implementing the SYSVOL workaround
* a MAAS curtin preseed, cloud-init examples, and the release pipeline
Two findings shaped the design.
Debian builds Samba against its bundled Heimdal rather than system MIT Kerberos
— samba-ad-dc does not depend on krb5-kdc — so the AD DC role is in Samba's
supported configuration, not the experimental MIT one. The build asserts this
and fails if it ever changes.
Samba implements neither DFS-R nor FRS, so SYSVOL — where Group Policy lives —
does not replicate between DCs. Left alone, a policy created on one DC never
reaches the others and clients behave differently depending on which DC answered
them, with nothing reporting an error. adc-sysvol-sync applies the Samba wiki's
rsync workaround: sync idmap.ldb once so SID-to-uid mappings agree, rsync the
tree, then samba-tool ntacl sysvolreset because rsync carries POSIX bits while
the Windows ACLs live in AD. Without an SSH key to the source DC it exits with
an explanation rather than letting Group Policy diverge quietly.
Also carried over from maas-proxmox, where they were verified on real hardware:
the curtin-hooks that skip the kernel install and pin interface names by MAC,
Type=simple on the first-boot unit to avoid the systemd ordering cycle, and
shipping networking.service disabled so MAAS owns the network on first boot.
Specific to this image, the Debian cloud kernel is replaced with the generic one
— a bare-metal node booted with the cloud kernel can come up with no disk.
Nothing here has been built or deployed. The README says so at the top and in a
Verified status section that separates what was checked from what was not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
