Created attachment 1261118 [details]
ipaserver-install.log from a recent openQA test

Created attachment 1261119 [details]
system journal from recent openQA install (uncompress then use 'journalctl -f system.journal' to view)

Maybe a bind-dyndb-ldap issue?

This is actually caused by bug 1404409 in 389-ds. This issue occurs when using GSSAPI to authenticate to LDAP. As a workaround, simple authentication can be configured in /etc/named.conf.

So we're a week out from Alpha go/no-go, and FreeIPA is definitely not in good enough shape for release. I'm gonna propose this bug as an Alpha blocker as I at least *suspect* this one is the cause of the DNS problems. On that basis I propose it as a violation of "The core functional requirements for all Featured Server Roles must be met", as one of the 'core functional requirements' for the Domain Controller role is "Multiple clients must be able to enrol and unenrol in the domain" (and also "The Domain Controller must serve DNS SRV records for ldap and kerberos on port 53").

What can we do to get this fixed? I was interested by wibrown's mention in the other bug of "Maybe I have fixed this inadvertently with the LFDS disable?", but I can't find any commit since the 1.3.6.1 release with either 'lfds' or 'disable' in its commit message, so I don't know what change that is referring to and can't check to see if it fixes the problem.

I also don't know what settings to use in named.conf exactly to use 'simple authentication', to see if that makes enrolment work properly. 'auth_method' should be 'simple', fine, but what 'bind_dn' and 'password' do I use?

This was fixed in:

https://pagure.io/389-ds-base/issue/49139

We brought in the nunc-stans source tree because it was too hard to bundle in the rpm. This has been getting some extensive testing in the rpm and such since.

I've updated my copr repo https://pagure.io/389-ds-base/issue/49139 so this should have the needed fixes in it. If not, we have to go back and investigate.

Thanks for the reference. A COPR is really no use for Fedora, we need Fedora builds with the relevant fixes included. Does this basically mean backporting https://pagure.io/389-ds-base/c/a82a2cc6479c298db2b95ed476b91d85d9ee934a?branch=master and https://pagure.io/389-ds-base/c/617c61e81c9cc3561f3910697fbd3c3be821ded8?branch=master to the Fedora package? If so, I can try that, if the patches will apply cleanly.

What we have in that copr is going to be the next release of 1.3.6 which is what will go into fedora. You don't need to backport those fixes, and really, they are going to be hard to backport. 

We need to talk to mreynolds about when the next fedora build is going to be made.

When's our next build of 1.3.6 for fedora?

Fedora 26 is now frozen for Alpha. There really needs to be a better co-ordination going on here between the FreeIPA-related teams and the Fedora schedule; there should've been a plan long ago about which versions of what would be in Alpha, and they all should've landed weeks ago and be working by now.

We aren't supposed to land major changes during the milestone freezes, we're only supposed to make just enough changes to fix blocker and freeze exception bugs. Of course, since this whole stack has been broken six ways from Sunday for the last three months it matters a bit less if we land a major change to it, but still. (If you're wondering why this only just came up, various other bits of the FreeIPA stack have been broken over the last several months which prevented our tests even getting to this point to encounter this bug).

So, anyway. The situation is that we need a build without this problem to be done for Fedora 26 (and rawhide) and submitted as an update (the update is only needed for F26) ASAP: 26 Alpha go/no-go is next Thursday, which means we really need a compose to test by Tuesday at the latest. The earlier the better, because there could *well* be further bugs in the FreeIPA stack we need to sort out after this one is dealt with - we haven't had FreeIPA actually working on Rawhide for months, so who knows what else is lurking.

Given the circumstances it's fine for now if the new build has to be a substantial update with other changes that aren't relevant to this bug, but in future it'd be good if the development/package maintenance process could be adjusted to avoid us having to accept major changes through the freezes.

Thanks!

DS 1.3.6 was always going to be in this release, and I believe already is. We just need to make the point release to bring it up to date with the fixes. There are no more substantially large changes, it's all fixes and build process improvement. 

As for the other issue with testing, well I'll let other people talk about that.

Yes, the current package is of 1.3.6.1. But I noticed that release was from October 2016, i.e. five months ago, and there've been rather a lot of commits to master between then and now; if we're getting all those commits in the next build, that's a lot of change.

Based on the discussion, this is not caused by BIND. Moving to appropriate component.

(In reply to Adam Williamson from comment #5)

> I also don't know what settings to use in named.conf exactly to use 'simple
> authentication', to see if that makes enrolment work properly. 'auth_method'
> should be 'simple', fine, but what 'bind_dn' and 'password' do I use?

auth_method "simple";
bind_dn "cn=Directory Manager";
password "<DIRMAN_PASSWORD>";

After you modify the named.conf, don't forget to restart BIND.

# systemctl restart named-pkcs11

bind-dyndb-ldap should be able to connect to LDAP and work properly at this point.

Discussed in today's Blocker Review meeting. This bug is accepted as an Alpha blocker due to the severity of the breakage and lack of an workaround - voilating the following Alpha criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed..."

Note: https://bodhi.fedoraproject.org/updates/FEDORA-2017-042d32a655 is intended to fix this and in fact may, but deployment with that 389-ds-base still fails. Don't know yet if the failure is just another manifestation of the same issue, or a different issue that occurs *before* this issue, or a different issue that occurs *after* this issue. More info in parent bug https://bugzilla.redhat.com/show_bug.cgi?id=1404409 .

A patch has now been provided to upstream.

https://pagure.io/389-ds-base/issue/49165

389-ds-base-1.3.6.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b9fbd8b768

389-ds-base-1.3.6.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b9fbd8b768

389-ds-base-1.3.6.2-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d0ad136c8c

389-ds-base-1.3.6.2-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d0ad136c8c

389-ds-base-1.3.6.2-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.