12:36 a.m.
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(a)fosstodon.org
https://www.happyassassin.net
4:27 a.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
On Sun, Jun 18, 2023 at 8:37 AM Adam Williamson
<adamwill(a)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(a)fosstodon.org
https://www.happyassassin.net
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)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
4:30 a.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
On Sun, Jun 18, 2023 at 12:27 PM Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
On Sun, Jun 18, 2023 at 8:37 AM Adam Williamson
<adamwill(a)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(a)fosstodon.org
> https://www.happyassassin.net
>
>
>
> _______________________________________________
> server mailing list -- server(a)lists.fedoraproject.org
> To unsubscribe send an email to server-leave(a)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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
5:47 a.m.
New subject: Could we drop Active Directory requirements from Fedora
release criteria?
On Sun, 2023-06-18 at 12:30 +0300, Alexander Bokovoy wrote:
On Sun, Jun 18, 2023 at 12:27 PM Alexander Bokovoy
<abokovoy(a)redhat.com> wrote:
>
> On Sun, Jun 18, 2023 at 8:37 AM Adam Williamson
> <adamwill(a)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.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
12:20 p.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
On Sun, Jun 18, 2023 at 6:48 AM Adam Williamson
<adamwill(a)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.
2:26 p.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
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(a)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(a)fosstodon.org
https://www.happyassassin.net
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)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
3:21 p.m.
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/05fc65c6ad8912535a075f778f1c...
(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-sy...
If that is generally interesting to you, feel free to contact me about details.
Pitti
[1] https://github.com/cockpit-project/bots/pull/4885
5:54 p.m.
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/05fc65c6ad8912535a075f778f1c...
(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-sy...
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.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
10:03 p.m.
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!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
5:31 a.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
On Fri, Jul 21, 2023 at 11:03 PM Adam Williamson
<adamwill(a)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!
10:42 a.m.
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).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1:43 p.m.
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
2:38 p.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
Thanks for all the upstream work Alexander!
https://hachyderm.io/@sgnj151/109444697712463380
On Sat, Jul 22, 2023 at 2:44 PM Alexander Bokovoy <abbra(a)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/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
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)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
4:09 p.m.
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/Do...
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.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
4:31 p.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson
<adamwill(a)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/Do...
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!
5:31 a.m.
On Суб, 22 ліп 2023, Neal Gompa wrote:
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson
<adamwill(a)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/Do...
>
> 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
--
/ Alexander Bokovoy
6:43 a.m.
New subject: Could we drop Active Directory requirements from Fedora release criteria?
On Sun, Jul 23, 2023 at 6:31 AM Alexander Bokovoy
<abbra(a)fedoraproject.org> wrote:
On Суб, 22 ліп 2023, Neal Gompa wrote:
>On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson
><adamwill(a)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/Do...
>>
>> 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
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.
--
真実はいつも一つ！/ Always, there's only one truth!
7:03 a.m.
On Няд, 23 ліп 2023, Neal Gompa wrote:
On Sun, Jul 23, 2023 at 6:31 AM Alexander Bokovoy
<abbra(a)fedoraproject.org> wrote:
>
> On Суб, 22 ліп 2023, Neal Gompa wrote:
> >On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson
> ><adamwill(a)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/Do...
> >>
> >> 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
>
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/
--
/ Alexander Bokovoy
5:36 p.m.
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_...
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.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
288
days inactive
323
days old
server@lists.fedoraproject.org
18 comments
8 participants
participants (8)
-
Adam Williamson -
Alexander Bokovoy -
Alexander Bokovoy -
Gregory Carter -
Martin Pitt -
Neal Gompa -
Stephen Gallagher -
Subhendu Ghosh