Could we drop Active Directory requirements from Fedora release criteria?

Project Discussion
1

Hi folks! I want to talk about the Active Directory requirements in the release criteria. [cross-posted from the server mailing list].

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!

2

I am using neither AD nor Free IPA. Yet I think with the burden of
testing AD either manually or automated being as high as you described,
I think it’s worth dropping that requirement. Moreover, testing this
properly may incur license fees.

I think having good documentation on how to connect Fedora Server to an
AD domain is sufficient. Maybe there’s an option of having a test day
sometime between beta and final freeze, where the community is asked to
test AD connectivity and report bugs if it’s broken. That way fixes
could be ready for release day (or shortly after) without delaying the
release.

Just my $0.02.

3

Just to avoid possible misunderstandings: The proposal is about dropping the status “release criterion” from AD, not about dropping AD!

Nevertheless, I’m very uncomfortable with quietly withdrawing AD as a release criterion, and thus the status as “strongly supported”.

At least it should be announced 2-3 release in advance, so that users can adjust to it. It would be even better to determine beforehand in a suitable way by whom and to what extent the feature is used. And make a decision ultimately dependent on it.

Fedora Server aims at a (serious) use in production, not only as a development environment or experimental field. And thus long-term usability, backwards compatibility and reliability are of the highest priority. Therefore, AD is „release criterion“ for about 8 years now. We can’t just drop it.

Second, the status “release criterion” was introduced for AD 8 years ago for good reason. Has this reason been lost now? So it’s about the conception of Fedora Server.

Anyway, something like "I am using neither AD nor Free IPA. Yet I think … it’s worth dropping that requirement.“ Is no valid decision making, for sure.

…
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.

Rather than abandon the AD requirements, I would prefer to remedy this by improving the test procedures.

We had already discussed several times about extending and improving the test procedures, for example by using tools such as those that exist for test days and test corners. Adam, you had rather estimated that the automatic test procedures cover all server issues completely and perfectly and that no systematic manual tests were necessary. Therefore, for the last releases, we have introduced additional manual testing only for specific change proposals that might cause problems. And we carried out these tests in different phases, starting at the latest with the branched releases.

…

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.

I wasn’t part of the early Server initiative. I guess that the reason at the time was the smoothest possible integration ability into a Windows-dominated work environment. In any case, that would be very plausible to me, even today. Would that also be ensured with a test against Fedora Samba AD? (Sorry, I haven’t had to deal with Windows environments in years now (fortunately).

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.

As said, I ws not participating in those days. But yes, that’s plausibel for me and still important today in terms of Fedora Server product strategy.

4

Well, I mean, “quietly” is the exact opposite of what I’m doing here. I posted a topic here, a mail to the server list, and a toot. I couldn’t easily be much more loud about it. Doing it quietly would be if we just edited it out of the criteria and hoped nobody noticed.

“It would be even better to determine beforehand in a suitable way by whom and to what extent the feature is used. And make a decision ultimately dependent on it.”

That’s exactly what I’m asking in this thread! That’s the reason for this thread (and the others). That’s why it says “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?”

“Second, the status “release criterion” was introduced for AD 8 years ago for good reason. Has this reason been lost now? So it’s about the conception of Fedora Server.”

Sure, it is. Decisions and conceptions should be up for re-evaluation. Just because we decided to block on AD eight years ago doesn’t mean we’re required to do it forever. The question I’m asking is “does this need to be part of the conception of Fedora Server today?” Is it actually a thing that people who really use Fedora Server are doing? I am not sure, hence the topic.

"Rather than abandon the AD requirements, I would prefer to remedy this by improving the test procedures.

We had already discussed several times about extending and improving the test procedures, for example by using tools such as those that exist for test days and test corners. Adam, you had rather estimated that the automatic test procedures cover all server issues completely and perfectly and that no systematic manual tests were necessary."

I don’t recall saying that. It’s certainly not true. Maybe there was a misunderstanding somewhere? AD support has always been a requirement, and the testing of it has never been automated. So systematic manual testing of AD has always been required.

I don’t believe this is a test process issue. We have a test process that works - the validation events are created and announced, the test cases are listed there, the test cases themselves are good quality. The problem is just with getting the testing done, because it’s a test that’s difficult and annoying to run. You don’t do it. I don’t do it. In most cycles, nobody does it until we notice a few days before release that nobody has done it, and I beg someone - usually Stephen or Tim - to do it. I don’t think that’s really a sustainable process.

5

I have recently started using AWS’ Directory Service for a similar purpose. If Fedora has access to AWS resources it would be a “fairly” quick way to get a hold of a properly licensed (licensing is included in the AWS hourly fee through an agreement Amazon has with Microsoft) real Windows Server based Active Directory on demand.

Spinning it up can be a somewhat lengthy process (I’ve had anything from 15-40 minutes of wait time before the instance became available). But other than calling the instantiatation via API there’s not much you need to do besides waiting. A machine that’s to be tested against that AD would need to either be spawned in the same VPC (to reach the AD cluster), for example through EC2, or be VPN’d into that VPC.
All in all that should be about it.

The AD on AWS side can be entirely scripted through the AWS Directory Service API and for the openQA Part I’m guessing we have all the knowledge in-house for that.

If you manage to pull the test suite off in less than 2 hours (including instantiation of the AWS AD instance) you should come in well under a US dollar a pop on the AWS side.

1 Like
6

Thanks for the idea, Felix! I’ll definitely keep it in mind if we wind up keeping Windows AD as blocking.

3 Likes
7

Sorry, my DeepL translator got my German slang (“Begleitmusik”) completely wrong, and I didn’t notice. You are right, you started it perfectly the right way, of course.

Apart from that, are we approaching any decision here?

I put it on the Server WG IRC meeting agenda tomorrow

==> July 5, 17:00 UTC, #fedora-meeting

8

Hey Peter! Sorry, it’s been a bit busy around here. But given the amount of pushback, my current thinking is to try and implement automated testing using Samba AD as the server end, whenever I can get around to it, hopefully before F39 Beta.

9

Hi Adam, we discussed it shortly on our IRC meeting today, and we agreed on the plan to try Samba AD. I hope it will be successful.

By the way, will you attend FLOCK this year?

10

Yup, I’ll be there!

12

Hi Peter, let me know if you need any help with Samba AD.

13

AD is a part of commercial ecosystem. If testing it incurs licensing fees, then the burden of paying these fees should not be placed on open source community, but on AD users. If there are no users who pay for AD to keep it tested and updated, then that means that AD ecosystem is dead and its support should be abandoned.