Created attachment 1042155 [details] uninstall log realmd-0.16.0-1.fc23.x86_64 freeipa-client-4.1.4-4.fc23.x86_64 authconfig-6.2.10-8.fc23.x86_64 Running "realm join" fails, and a subsequent ipa-client-install --uninstall also fails. The relevant error message in both cases seems to be: File "/usr/share/authconfig/authinfo.py", line 1901, in readSSSD domain = self.sssdDomain = self.sssdConfig.get_domain(SSSD_AUTHCONFIG_DOMAIN) File "/usr/lib/python3.4/site-packages/SSSDConfig/__init__.py", line 1847, in get_domain raise NoDomainError(name) SSSDConfig.NoDomainError: default I don't have the original install log anymore, but I attach the uninstall log. # cat /etc/ipa/default.conf #File modified by ipa-client-install [global] basedn = dc=mvo,dc=lan realm = MVO.LAN domain = mvo.lan server = ipa.mvo.lan host = fraw.mvo.lan xmlrpc_uri = https://ipa.mvo.lan/ipa/xml enable_ra = True # cat /etc/sssd/sssd.conf [domain/mvo.lan] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = mvo.lan id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = fraw.mvo.lan chpass_provider = ipa dyndns_update = True ipa_server = _srv_, ipa.mvo.lan ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = mvo.lan [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp]
This happens both on my dirty development VM and in a clean test VM. I can easily reproduce this in the test VM and I'll be happy to provide any kind of additional information, of course.
Created attachment 1042180 [details] install log I guess the install log will be necessary, so here it is. Note that it is from a different machine/network than the config files shown above.
It seems to me that the bug is either in authconfig or SSSD 2015-06-23T09:23:07Z DEBUG args='/usr/sbin/authconfig' '--enablesssdauth' '--enablemkhomedir' '--update' '--enablesssd' 2015-06-23T09:23:08Z DEBUG Process finished, return code=1 2015-06-23T09:23:08Z DEBUG stdout= 2015-06-23T09:23:08Z DEBUG stderr=Traceback (most recent call last): File "/usr/share/authconfig/authinfo.py", line 1901, in readSSSD domain = self.sssdDomain = self.sssdConfig.get_domain(SSSD_AUTHCONFIG_DOMAIN) File "/usr/lib/python3.4/site-packages/SSSDConfig/__init__.py", line 1845, in get_domain raise NoDomainError(name) SSSDConfig.NoDomainError: default Uninstall log suggests authconfig: File "/usr/share/authconfig/authinfo.py", line 1904, in readSSSD domname = self.sssdConfig.list_active_domains()[0] TypeError: 'dict_keys' object does not support indexing
As this is a new behaviour in rawhide and authconfig was not changed there I would say that this is something new in SSSDConfig. Of course the fix might be needed to be done in authconfig but I'd like the sssd guys to tell me what changed recently. Reassigning to sssd for investigation.
The only changes in latest year was porting to python3. It was a contribution from python team. sssdConfig.list_active_domains() return "class list" on python2 and "class dict_keys" on python3. Our internal test passed because we didn't try to index returned value. We just iterate over the result from list_active_domains() def testListActiveDomains(self): sssdconfig = SSSDConfig.SSSDConfig(srcdir + "/etc/sssd.api.conf", srcdir + "/etc/sssd.api.d") # Negative Test - Not Initialized self.assertRaises(SSSDConfig.NotInitializedError, sssdconfig.list_active_domains) # Positive Test sssdconfig.import_config(srcdir + '/testconfigs/sssd-valid.conf') control_list = [ 'IPA', 'LOCAL'] active_domains = sssdconfig.list_active_domains() for domain in control_list: self.assertTrue(domain in active_domains, "Domain [%s] missing" % domain) for domain in active_domains: self.assertTrue(domain in control_list, "Domain [%s] unexpectedly found" % domain) Maybe Petr might know why is the class different in python{2,3}. He helped us with porting to python3
The strange thing to me is that authconfig is trying to look up the "default" domain: domain = self.sssdDomain = self.sssdConfig.get_domain(SSSD_AUTHCONFIG_DOMAIN) defined as: SSSD_AUTHCONFIG_DOMAIN = "default" But looking at the first comment, the config file only has "[domain/mvo.lan]", so no wonder it blows up. In the install log I see authconfig was called like this: /usr/sbin/authconfig' '--enablesssdauth' '--enablemkhomedir' '--update' '--enablesssd This looks to me like if the caller only wanted to set up the PAM stack and NSS. Should authconfig care about SSSD config in this case at all?
Note that this code reads the current settings to it is irrelevant to what user asks for. The strange thing is that there is: 'except SSSDConfig.NoDomainError:' which guards the self.sssdConfig.get_domain(SSSD_AUTHCONFIG_DOMAIN) call. So this should not create a traceback. That is for the first traceback. The other traceback seems to be really bug in conversion of SSSDConfig to python3.
Or I misunderstood the problem and the raise of SSSDConfig.NoDomainError is ok and handled correctly. So the only real problem is the bug in conversion of the active domain list. Which is in SSSD conversion to python3.
I checked the documentation of used function and it should return list and not "class dict_keys". def list_active_domains(self): """ Return a list of all active domains. === Returns === The list of configured, active domains. === Errors === NotInitializedError: This SSSDConfig object has not had import_config() or new_config() run on it yet. """
Upstream ticket: https://fedorahosted.org/sssd/ticket/2699
In Python 3, dict.keys() returns a view rather than a list. Since dict keys aren't in any particular order, indexing them doesn't make sense. If list_active_domains needs to return a list, convert to it explicitly -- `return list(somedict.keys())`.
Marius, please test following scratch build[1]. It contains patch just for list_active_domains. It's possible that there are other python3 glitches. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10242268
> please test following scratch build[1]. I will, with lowish priority. Were you able to reproduce the issue and verify your fix yourself? If you are expecting more regressions, I wouldn't want to be the slowest part in your edit-compile-run cycle. :-)
Currently, I do not have a free cycles to review all python SSSDConfig API and check where list should be returned instead of "view". I just prepared simple one-liner with advice from Petr Viktorin. My intention was to unblock you.
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10242268 Is there an easy way to install these packages, other than downloading them all individually by hand?
(In reply to Lukas Slebodnik from comment #14) > My intention was to unblock you. I see, and thanks a lot for that. We run into this bug in our automated tests only and we are simply skipping the relevant test until this bug is fixed. (However, we can't currently refresh our rawhide images because of bug 1232411...)
(In reply to Marius Vollmer from comment #15) > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10242268 > > Is there an easy way to install these packages, other than downloading them > all individually by hand? Oh, they are in the rawhide repositories. Nice!
(In reply to Marius Vollmer from comment #17) > (In reply to Marius Vollmer from comment #15) > > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10242268 > > > > Is there an easy way to install these packages, other than downloading them > > all individually by hand? > > Oh, they are in the rawhide repositories. Nice! No, they are not... alpha vs alpha.1
(In reply to Lukas Slebodnik from comment #12) > please test following scratch build[1]. Both "realm join" and "realm leave" work with those packages.
(In reply to Marius Vollmer from comment #15) > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10242268 > > Is there an easy way to install these packages, other than downloading them > all individually by hand? Just FYI. You canot download scratch build koji command but you can use utility koji-download-scratch which is part of package fedora-review (In reply to Marius Vollmer from comment #19) > (In reply to Lukas Slebodnik from comment #12) > > please test following scratch build[1]. > > Both "realm join" and "realm leave" work with those packages. OK, I will push this patch to rawhide even though it wasn't reviewed in upstream. It is a one-liner and was recommended by Petr Viktorin in comment 11
sssd-1.13.0-2.fc23.alpha is in rawhide. I will close this BZ after fixing it in upstream.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
master: 2ab9822a792e26e9ddb47cbb6bc788a0727c8556
The non-upstream patch which is already present in Fedora packages for some time is correct, sans test, so I'll move this bz to MODIFIED.
sssd-1.13.1-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-202c127199
sssd-1.13.1-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update sssd' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-202c127199
sssd-1.13.1-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.