In current Rawhide and Fedora 28, the openQA test which tests enrolment into a FreeIPA domain via kickstart during install fails, e.g.: https://openqa.fedoraproject.org/tests/209813 anaconda's program.log shows this: 12:31:09,463 INF program: Running... realm join --install /mnt/sysimage --verbose --one-time-password=monkeys ipa001.domain.local 12:31:09,763 INF program: * Resolving: _ldap._tcp.ipa001.domain.local 12:31:09,764 INF program: * Resolving: ipa001.domain.local 12:31:09,764 INF program: * Performing LDAP DSE lookup on: 10.0.2.100 12:31:09,765 INF program: * Successfully discovered: domain.local 12:31:09,765 INF program: realm: Couldn't join realm: This computer's host name is not set correctly. however, the hostname *was* (at least, anaconda claims so) set to 'client001.domain.local' a minute earlier, according to anaconda.log: 12:30:15,387 INF network: setting installation environment host name to client001.domain.local So, either anaconda isn't actually setting the host name correctly, or realm isn't noticing that anaconda has changed it, or something. The test which tests enrolment via realmd *after* install - which does 'hostnamectl set-hostname client003.domain.local' then calls 'realm join' - *does* work: https://openqa.fedoraproject.org/tests/209817 Given that, I'm tentatively assigning this to anaconda, but CCing realmd maintainers. Proposing as a Beta blocker, per Basic criterion "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" - https://fedoraproject.org/wiki/Basic_Release_Criteria#Remote_authentication . The 'at install time' part of that criterion explicitly covers this scenario.
realmd prints this error under the following conditions: /* Check the host name */ ret = gethostname (hostname, sizeof (hostname)); if (ret < 0 || g_ascii_strcasecmp (hostname, "localhost") == 0 || g_ascii_strncasecmp (hostname, "localhost.", 10) == 0 || hostname[0] == '.') { g_dbus_method_invocation_return_error (invocation, REALM_ERROR, REALM_ERROR_BAD_HOSTNAME, "This computer's host name is not set correctly."); return TRUE; } So either gethostname() failed or the returned name starts with 'localhost' or a '.'. HTH bye, Sumit
This should be fixed by porting this patch to F28: https://github.com/rhinstaller/anaconda/pull/1385/files From what I've looked at it seems that on rawhide (where the patch is already applied in anaconda-29.5-1.fc) the server_realmd_join_kickstart test fails for other reasons (eg https://openqa.fedoraproject.org/tests/210632).
(In reply to Adam Williamson from comment #0) > The test which tests enrolment via realmd *after* install - which does > 'hostnamectl set-hostname client003.domain.local' then calls 'realm join' - > *does* work: > > https://openqa.fedoraproject.org/tests/209817 > From /var/log/anaconda/journal.log: Mar 22 16:30:15 localhost.localdomain anaconda[1867]: anaconda: installation: Queue started: Network configuration (2/8) Mar 22 16:30:15 localhost.localdomain anaconda[1867]: anaconda: progress: Writing network configuration Mar 22 16:30:15 localhost.localdomain anaconda[1867]: anaconda: installation: Task started: Network configuration (11/21) Mar 22 16:30:15 localhost.localdomain anaconda[1867]: anaconda: network: setting installation environment host name to client001.domain.local Mar 22 16:30:15 localhost.localdomain org.fedoraproject.Anaconda.Modules.Network[1963]: DEBUG:anaconda.modules.network.network:Current hostname cannot be set. Mar 22 16:30:15 localhost.localdomain anaconda[1867]: anaconda: installation: Task completed: Network configuration (11/21) (0.0 s)
I'm +1 blocker on this, for the record.
+1 blocker
Radek: thanks. Note, the test you linked to isn't really a failure, openQA uses 'soft fail' as the term for the mushy state between 'complete pass' and 'complete fail', that particular test is 'soft failed' because everything worked, but AVCs showed up along the way (which we have the tests set to specifically look for and treat as a 'soft fail' if it happens, so we can catch the AVCs and file bugs). Aside from the AVCs, everything worked OK in that run. Can you prepare a build and update of anaconda with this fix, since it seems highly likely to be accepted as a blocker? Thanks!
anaconda-28.22.2-7.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-34ea87ba41
Discussed during the 2018-03-26 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as it violates the following blocker 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" (in all cases where a correct hostname is not set via DHCP) [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-03-26/f28-blocker-review.2018-03-26-16.01.txt
anaconda-28.22.2-7.fc28 has been pushed to the Fedora 28 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-2018-34ea87ba41
This passed for the manual AD client kickstart test[*] I just ran against the Beta candidate. It appears that openqa's test also passed for FreeIPA. So this is probably VERIFIED, but I'll leave that up to Adam to make the final call. [*](https://fedoraproject.org/wiki/QA:Testcase_realmd_join_kickstart)
robot says "yes"
anaconda-28.22.2-7.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.