Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
Thanks!
On Sun, Jun 18, 2023 at 8:37 AM Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We want to add automation. I can help with this.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
Samba AD in Fedora is to save you here. This is what we should be testing.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
I think we need to keep the release blocking state and instead of Windows test against Samba AD in Fedora. That was always the intent.
Thanks!
Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
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
On Sun, Jun 18, 2023 at 12:27 PM Alexander Bokovoy abokovoy@redhat.com wrote:
On Sun, Jun 18, 2023 at 8:37 AM Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We want to add automation. I can help with this.
Forgot to add that we have the tests against Windows-based Active Directory working already in SSSD and FreeIPA upstream, using images Microsoft has been publishing for exactly this purpose for years.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
Samba AD in Fedora is to save you here. This is what we should be testing.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
I think we need to keep the release blocking state and instead of Windows test against Samba AD in Fedora. That was always the intent.
Thanks!
Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
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
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On Sun, 2023-06-18 at 12:30 +0300, Alexander Bokovoy wrote:
On Sun, Jun 18, 2023 at 12:27 PM Alexander Bokovoy abokovoy@redhat.com wrote:
On Sun, Jun 18, 2023 at 8:37 AM Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We want to add automation. I can help with this.
Forgot to add that we have the tests against Windows-based Active Directory working already in SSSD and FreeIPA upstream, using images Microsoft has been publishing for exactly this purpose for years.
It's been a while since I last checked, but IIRC, these are intended as "evaluation" images. It wasn't entirely clear to me whether they actually *are* intended for the purpose of automated testing, and if their licensing is appropriate for this. Also, for openQA purposes we would probably want to have a pre-configured disk image for the AD server - we don't want to waste time setting it up in the test process every time (for FreeIPA we do because that's part of the criteria, but it's not for AD) - and I think it wasn't clear if *that's* OK legally speaking either.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
Samba AD in Fedora is to save you here. This is what we should be testing.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
I think we need to keep the release blocking state and instead of Windows test against Samba AD in Fedora. That was always the intent.
Was it? That's not my recollection; my memory is that we were always intending to support enrolling to Microsoft AD-controlled domains. I can't find the discussion in the archives, though - the 2014 version of the tech spec says "Fedora Server will provide and support the realmd project for joining FreeIPA and Active Directory domains automatically", I can't find any references for how that got there, though.
Testing against Samba AD would probably be significantly easier, but I was kinda working on the basis that wasn't really what we wanted to do.
On Sun, Jun 18, 2023 at 6:48 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2023-06-18 at 12:30 +0300, Alexander Bokovoy wrote:
...
I think we need to keep the release blocking state and instead of Windows test against Samba AD in Fedora. That was always the intent.
Was it? That's not my recollection; my memory is that we were always intending to support enrolling to Microsoft AD-controlled domains. I can't find the discussion in the archives, though - the 2014 version of the tech spec says "Fedora Server will provide and support the realmd project for joining FreeIPA and Active Directory domains automatically", I can't find any references for how that got there, though.
Testing against Samba AD would probably be significantly easier, but I was kinda working on the basis that wasn't really what we wanted to do.
For the record, the statement was never "don't test against Samba AD", it's that what we wanted to *block on* was the inability to connect to a real Microsoft AD server, since that is (and remains) the most prominent domain controller in the world.
At this point in history, I think we could happily add Samba AD as an *additional* blocking target, but I really don't think it makes sense to replace Microsoft AD.
You should carry a vote for the release with samba-AD capabilities.
However I will put my two cents in.
I myself, have personally never used SAMBA in a Domain Controller sense for a couple of reasons beyond very simple file sharing, which I do use it for:
1) Mixing Microsoft Infrastructure with authentication requirements across platforms doesn't make any operational sense to me.
For example, I have to patch my Windows servers, so why are my Linux boxes down in my HADOOP cluster or more importantly, why did all of my jobs just fail on the cluster because there is no AD service available for whatever reason?
2) I need to add a linux box, but I don't have the proprietary non linux licenses to do so.
Seems sort of odd a licensing issue with application server infrastructure, say a Microsoft platform is preventing me from installing a Linux server.
3) Same for same, Why can't I pick and choose what windows commercial products I need, and discount them because they are or not open source/open standards? Not all software is open and I find keeping Linux out of such environments is a huge plus in operational sanity and the support calls to the companies who build such products are more understanding.
4) That being said AD is getting long in the tooth now days as the browser takes over and everything just works in the cloud now. If you don't adhere to typical open standards none of your stuff will work. So AD I consider legacy infrastructure anyway. Plenty of WAY better ways to share files and approve access to applications and files/printing...etc with just LDAP and none of the baggage of AD.
So these are some of the reasons why I would limit testing and devote time to something more achievable.
THAT BEING SAID, you can test DOMAIN joins and operations between Linux Infrastructure, and just leave the windows testing out. THAT is certainly not a waste of time as whatever problem is traceable and trackable. That certainly makes the SAMBA packages better as all testing is within the confines of the source tree of SAMBA client and server and saves you a lot of reporting headaches.
So I would vote for LIMITED testing within the Linux Eco System, but not include Microsoft testing proper. (Setting up Domain Joins for example on Windows 11/10 Windows Server products etc.)
People can file bug reports with the SAMBA foundation if they have issues with Microsoft AD. SAMBA is getting fairly good now days and I don't think people would mind the odd bug or two in the implementation case.
So what I mean to say here is SAMBA is already pretty well tested outside of Fedora, so I think the risk is pretty small for major issues.
Case in point 3 months ago I installed a complete AD domain on a Fedora box in about 5 minutes. Super simple to do and it worked flawlessly with Windows 10/11 and Server 2019 Fedora 37. No Workstation join issues, or wierd policy affects at least in authentication anyway.
It has been running ever since, diligently protecting all my Mainecoon pictures and does a very fine job of preventing anyone from stealing them if you don't have the right AD password.
On Sat, Jun 17, 2023 at 10:37 PM Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
Thanks!
Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
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
Hello Adam and all,
Adam Williamson [2023-06-18 7:36 +0200]:
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't.
In case it helps: In Cockpit we automatically test AD integration with Samba. The server side is https://github.com/cockpit-project/bots/blob/05fc65c6ad8912535a075f778f1c95c... (don't do the FROM seddery if you can pull from dockerhub, it broke recently [1]).
On the client side there isn't that much setup to do: https://github.com/cockpit-project/cockpit/blob/main/test/verify/check-syste...
If that is generally interesting to you, feel free to contact me about details.
Pitti
On Sun, 2023-06-18 at 22:21 +0200, Martin Pitt wrote:
Hello Adam and all,
Adam Williamson [2023-06-18 7:36 +0200]:
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't.
In case it helps: In Cockpit we automatically test AD integration with Samba. The server side is https://github.com/cockpit-project/bots/blob/05fc65c6ad8912535a075f778f1c95c... (don't do the FROM seddery if you can pull from dockerhub, it broke recently [1]).
On the client side there isn't that much setup to do: https://github.com/cockpit-project/cockpit/blob/main/test/verify/check-syste...
If that is generally interesting to you, feel free to contact me about details.
Thanks a lot! Also thanks to all the others who mentioned Samba AD.
So there's kinda several angles here, now we pull in Samba AD. There's two systems to consider - Samba AD and Windows AD - and three things to consider about both:
1. How *easy* is it to test this? 2. How *useful* is it to test this? 3. How *important* is this thing to Fedora Server users?
Samba AD would definitely be easier to test than Windows AD (and piggybacking off your process would make it easier, so thanks for that). It sounds like at least you and Alexander think testing it would be useful. So we can certainly look at adding Samba AD testing *regardless* of the answer to question 3. But question 3 is actually the one that should determine what goes into the release criteria, I think. That's the one I'm trying to get a feel for in this thread. I don't really know what the answer to question 3 is for Samba AD *or* Windows AD. I'm looking for input to figure that out.
On Sun, 2023-06-18 at 07:36 +0200, Adam Williamson wrote:
Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
Hey folks! Just to give an update on this, as I'm not sure I ever did on the list: the current plan is to not drop the criterion, but instead implement automated testing based on Samba AD (not Microsoft AD).
I am working on this at present and have got quite far, should have it completed next week.
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!
On Fri, Jul 21, 2023 at 11:03 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2023-06-18 at 07:36 +0200, Adam Williamson wrote:
Hi folks! I want to talk about the Active Directory requirements in the release criteria.
Since Fedora Server was created, we've had this in the criteria:
"It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain."
...plus various further requirements at Beta and Final.
For FreeIPA we have this testing entirely automated, it's no problem at all. For Active Directory we...don't. At every release point this does not get tested until very late. Often Stephen Gallagher has to test it manually at the very last minute, which is an unfair burden on him. When we *do* find problems, there is a mad scramble to fix them or at least find workarounds, because we find them way too late.
We've looked into automating it and still kinda intend to do so, but it's not really simple. There's a legal side to it - it's not clear what the licensing requirements involved would be - and a technical side to it - we'd need a way to reliably and quite quickly deploy an AD domain controller using openQA automation, which is not a trivial job.
When I estimate the time that's going to take and consider what *else* I (or anyone else) could do with that time, I'm not certain that "automating AD testing" is the best use of it. To me it doesn't feel like a really key feature of Fedora to the point that would justify the work involved, or justify continuing to throw Stephen and others under the last-minute-manual-testing bus. But I'm not sure!
What do others think? Do you use the AD client support of Fedora Server? Do you think it's a key feature that we should keep as a release-blocking requirement, or no?
Hey folks! Just to give an update on this, as I'm not sure I ever did on the list: the current plan is to not drop the criterion, but instead implement automated testing based on Samba AD (not Microsoft AD).
I am working on this at present and have got quite far, should have it completed next week.
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.
-- 真実はいつも一つ！/ Always, there's only one truth!
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?
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).
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/Domai...
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.
Thanks for all the upstream work Alexander!
https://hachyderm.io/@sgnj151/109444697712463380
On Sat, Jul 22, 2023 at 2:44 PM Alexander Bokovoy abbra@fedoraproject.org wrote:
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/Domai...
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
On Sat, 2023-07-22 at 21:43 +0300, Alexander Bokovoy wrote:
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/Domai...
Thanks. I didn't realize it had that status.
If you team is happy to stand behind Samba AD in the same way it stands behind FreeIPA, I'd have no problem at all with it being release- blocking, if the WG wants to do that.
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2023-07-22 at 21:43 +0300, Alexander Bokovoy wrote:
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/Domai...
Thanks. I didn't realize it had that status.
If you team is happy to stand behind Samba AD in the same way it stands behind FreeIPA, I'd have no problem at all with it being release- blocking, if the WG wants to do that.
I think we'd be comfortable with that. The main issue right now is a lack of official Fedora documentation for setting this up that we could support it with.
To be honest, I'd hoped for a long time that Samba AD would become part of the FreeIPA setup. Sadly, it hasn't so far. :(
-- 真実はいつも一つ！/ Always, there's only one truth!
On Суб, 22 ліп 2023, Neal Gompa wrote:
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2023-07-22 at 21:43 +0300, Alexander Bokovoy wrote:
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/Domai...
Thanks. I didn't realize it had that status.
If you team is happy to stand behind Samba AD in the same way it stands behind FreeIPA, I'd have no problem at all with it being release- blocking, if the WG wants to do that.
I think we'd be comfortable with that. The main issue right now is a lack of official Fedora documentation for setting this up that we could support it with.
To be honest, I'd hoped for a long time that Samba AD would become part of the FreeIPA setup. Sadly, it hasn't so far. :(
That is not a plan and it never was. FreeIPA works just fine with Samba AD over forest trust.
If you want to get a grasp over how complex things are, watch wonderful talk by Nadia who spent a good part of the past decade trying to make OpenLDAP backend for Samba AD.
https://www.youtube.com/watch?v=6TMd9r2VngI
On Sun, Jul 23, 2023 at 6:31 AM Alexander Bokovoy abbra@fedoraproject.org wrote:
On Суб, 22 ліп 2023, Neal Gompa wrote:
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2023-07-22 at 21:43 +0300, Alexander Bokovoy wrote:
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/Domai...
Thanks. I didn't realize it had that status.
If you team is happy to stand behind Samba AD in the same way it stands behind FreeIPA, I'd have no problem at all with it being release- blocking, if the WG wants to do that.
I think we'd be comfortable with that. The main issue right now is a lack of official Fedora documentation for setting this up that we could support it with.
To be honest, I'd hoped for a long time that Samba AD would become part of the FreeIPA setup. Sadly, it hasn't so far. :(
That is not a plan and it never was. FreeIPA works just fine with Samba AD over forest trust.
If you want to get a grasp over how complex things are, watch wonderful talk by Nadia who spent a good part of the past decade trying to make OpenLDAP backend for Samba AD.
Even if it was a forest trust, that doesn't mean that the IPA installer couldn't just set all that up with Samba AD all in one go, and the FreeIPA admin UI could expose Samba AD stuff.
On Няд, 23 ліп 2023, Neal Gompa wrote:
On Sun, Jul 23, 2023 at 6:31 AM Alexander Bokovoy abbra@fedoraproject.org wrote:
On Суб, 22 ліп 2023, Neal Gompa wrote:
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2023-07-22 at 21:43 +0300, Alexander Bokovoy wrote:
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/Domai...
Thanks. I didn't realize it had that status.
If you team is happy to stand behind Samba AD in the same way it stands behind FreeIPA, I'd have no problem at all with it being release- blocking, if the WG wants to do that.
I think we'd be comfortable with that. The main issue right now is a lack of official Fedora documentation for setting this up that we could support it with.
To be honest, I'd hoped for a long time that Samba AD would become part of the FreeIPA setup. Sadly, it hasn't so far. :(
That is not a plan and it never was. FreeIPA works just fine with Samba AD over forest trust.
If you want to get a grasp over how complex things are, watch wonderful talk by Nadia who spent a good part of the past decade trying to make OpenLDAP backend for Samba AD.
Even if it was a forest trust, that doesn't mean that the IPA installer couldn't just set all that up with Samba AD all in one go, and the FreeIPA admin UI could expose Samba AD stuff.
That's not how it works. Samba AD and FreeIPA domain controllers cannot be set up on the same host. They conflict on multiple layers: there are incompatible LDAP schemas, different storage databases, same ports used by different components and so on.
Fundamentally, there is no need to make it working this way either. Samba AD serves Windows clients in the first place and Windows clients have certain expectations to how domain controllers operate. FreeIPA is isolated from those semantics by moving across to a separate forest, which means we only need to follow a very limited set of rules there as Windows clients will talk to their own domain controller and ask it to rely requests to a foreign domain controller if needed.
We plan to reuse some of the common technology, though. For example, ISC BIND project considers to make their database layer API private and doesn't expose it anymore[1]. This will affect both bind-dyndb-ldap and Samba AD DNS backends in future. We are looking at a common solution to those problems.
[1] https://www.isc.org/blogs/bind-architecture-25-years/
On Sat, 2023-07-22 at 17:31 -0400, Neal Gompa wrote:
I think we'd be comfortable with that. The main issue right now is a lack of official Fedora documentation for setting this up that we could support it with.
I didn't actually find it that hard to find decent docs, I used https://fedoramagazine.org/samba-as-ad-and-domain-controller/ and https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Dom... and they gave me everything I needed. Really, I think just the magazine article actually has everything you need, but I found the Samba wiki page first and the magazine article later. It would be fairly easy to turn the article into a doc page I guess.
server@lists.fedoraproject.org
-
Adam Williamson -
Alexander Bokovoy -
Alexander Bokovoy -
Gregory Carter -
Martin Pitt -
Neal Gompa -
Stephen Gallagher -
Subhendu Ghosh