On Суб, 22 ліп 2023, Adam Williamson wrote:
On Sat, 2023-07-22 at 06:31 -0400, Neal Gompa wrote:
> >
> > What I intend after that is that we will be OK with releasing so long
> > as the automated tests against Samba AD pass, but if anyone decides to
> > manually test against Microsoft AD and finds a bug, that can
> > potentially be a blocker. But we will not block the release on making
> > sure Microsoft AD has been tested.
> >
> > Does this sound like a decent solution to everyone? Thanks!
>
> Does that mean that we will also have tests for setting up and using
> Samba AD from Fedora? Because if we're going to block on client
> connectivity on Samba AD, I think we should also block on Samba AD
> from the server side too.
It means we'll have a test, but as things stand, failures of it won't
be blocking, because "work as a Samba AD server" is not in the
criteria.
You could, of course, propose a criterion change and we could debate
it, though I think that might be a bit of a stretch - we already block
on one domain server technology which is more in our ecosystem. Who's
going to be the "throat to choke" for Samba AD server functionality if
it breaks?
The same people who are responsible for 'FreeIPA server functionality if
it breaks', for years.
We chose to have FreeIPA and Samba AD with MIT Kerberos as our domain
controller technologies in Fedora more than a decade ago, we committed
to develop them through Samba and FreeIPA upstreams, we keep doing so.
Please watch our talk at SambaXP'23: 'Samba AD / MIT Kerberos: path out
of experimental'.
https://www.youtube.com/watch?v=0_cdYuIYw0o
As I said, we already committed to this work for more than a decade ago
in Fedora. We first announced productization of Samba AD DC with MIT
Kerberos in Fedora 27 in 2017, this was a milestone which went into
Fedora 27's release notes:
https://docs.fedoraproject.org/en-US/fedora/f27/release-notes/sysadmin/Do...
As things stand, only failures in the client tests would be direct
blockers; problems with the server test wouldn't be. (If we couldn't
work around the server issues they would mean we'd have to fall back to
testing manually against Microsoft AD to pass the client requirements,
I guess, which would be a pain, but they wouldn't be blockers in
themselves).
We do test weekly against Microsoft AD the following stack:
- SSSD in direct integration with Microsoft AD domain (SSSD upstream)
- SSSD on FreeIPA client, with IPA trust to Microsoft AD (FreeIPA
upstream)
This happens on current Fedora N, on the Fedora N-1, and on Rawhide,
every week. Issues typically get addressed upstream or investigated and
filed against broken parties.
You don't see most of this in OpenQA testing in Fedora because we
typically get through all failures prior to releasing to Fedora.
On Samba side, we have comprehensive test suite that allows us to get
behavior pinned down against Microsoft AD implementation and then
applied against both Samba AD/Heimdal and Samba AD/MIT Kerberos. There
are differences but we are able to pin down those and generally know
what happens or should happen. Samba upstream runs Fedora 38/MIT
Kerberos target for each commit, on par with the rest of targets.
So we have pretty good coverage semantics-wise and OpenQA use here would
be more of making sure other parts of Fedora don't unintentially break
behavior of these enterprise environments.
--
/ Alexander Bokovoy