Bug 1577615

What options to ipa-client-install did you use?

--enable-dns-update --mkhomedir

Is this IPA version already the one that uses authselect? If yes, IPA still modifies nsswitch.conf on its own [1].

I recently fixed [2] in authselect, but removing "sudoers: files sss" by default and leaving only "sudoers: files". 'authselect select sssd with-sudo' needs to be called to enable sssd for sudo.

If you modify nsswitch.conf before calling authselect, it gets overwritten. Otherwise it should not be related. You should switch to authselect here as well.

[1] https://github.com/freeipa/freeipa/blob/master/ipaclient/install/client.py#L914
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1573403

FreeIPA does not explicitly use authselect on IPA clients. However, if authselect-compat is installed, and it will be installed in 4.6.90.pre1 because that's the version without authselect support, it will override all data on upgrade. Looks like this is an outcome from using 'authconfig' because authselect-compat-provided authconfig version will effectively call authselect. As result, it will configure itself as 'authselect is there and in use'.

$ rpm -q --scripts authselect-libs
preinstall scriptlet (using /bin/sh):
rm -f "/var/lib/rpm-state/authselect.update-profile"
if [ $1 -gt 1 ] ; then
    # Check that authselect cli is installed, otherwise there is nothing to do.
    rpm -q authselect &> /dev/null
    if [ $? -ne 0 ] ; then
      exit 0
    fi

    # This is an upgrade. Check that the current configuration is valid
    # and store the information for later use in posttrans. The check must
    # be done here (before profiles are updated), otherwise it would return
    # an error if the new profile is different from the old one but selected.
    /usr/bin/authselect check &> /dev/null
    if [ $? -eq 0 ]; then
      touch "/var/lib/rpm-state/authselect.update-profile"
    fi
fi

exit 0
posttrans scriptlet (using /bin/sh):
if [ -f "/var/lib/rpm-state/authselect.update-profile" ]; then
    # This is an upgrade. Update current profile if possible.
    PROFILE=`/usr/bin/authselect current --raw`
    if [ $? -eq 0 ]; then
        /usr/bin/authselect select $PROFILE --force &> /dev/null
    fi
    rm -f "/var/lib/rpm-state/authselect.update-profile"
fi

exit 0

With freeipa-4.6.90.pre2 we are not using authconfig anymore so authselect-compat should not be involved.

Pavel fixed it in authselect upgrade scripts: https://github.com/pbrezina/authselect/commit/a49011d68931e196b86750f3ce854454aaa16528

I prepared a scratch build with spec file changes applied. Please test.

https://koji.fedoraproject.org/koji/taskinfo?taskID=27320373

Upstream ticket:
https://pagure.io/freeipa/issue/7562

Hi Pavel,
with the scratch build, the profile is updated to sssd with-sudo and sudo is working.

I installed the authselect{,-libs}-0.4-3.1.fc28.x86_64 scratch build, joined a domain, and nsswitch.conf still only says "sudoers:    files", and sudo is not working. The fix above only seems to apply to upgrades, not to fresh installs and realm joins?

Hi Martin,
you are right, the fix only applies to upgrades. We also need to make a fix on ipa side for fresh installs (in the installer, configure authselect select sssd *with-sudo*).

Fixed in FreeIPA upstream
master:
https://pagure.io/freeipa/c/eda831dba1e09e7f4660c64756343538042b48e0

Correcting status to POST which means fixed upstream.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

FTR, we long stopped doing/testing Cockpit updates on Fedora 28, so I don't know if F28 is still affected (F29 is definitively not).

It was fixed in the 4.7.0 release.