Bug 1234792

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.