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/Domain_Controllers/

>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
_______________________________________________
server mailing list -- server@lists.fedoraproject.org
To unsubscribe send an email to server-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue