As I already stated on IRC. It is desired that ipa-client-install --uninstall doesn't remove sss from nsswitch.conf. See bug 953453

Therefore I think that "Expected results" are wrong and this is not a bug in IPA.

Ignoring --noac in ipa-client-install --uninstall is also correct since it's an installation option, not an uninstallation one. I would say that if authconfig calls ipa-client-install --uninstall --noac, then there is a bug in authconfig, but it doesn't matter given that the option is ignored.

Even if --noac would have some effect, the desired behaviour of ipa-client-install would be to not touch nsswitch.conf.

And as you stated, sss was added to nsswitch.conf by authconfig, not IPA.

That's a simple nonsense - we really need the ipa-client-install to not call authconfig if --noac is passed to it. It is basically impossible to properly handle mechanism enablement/disablement in authconfig if it is recursively called from ipa-client-install. I understand that because ipa-client-install --uninstall call was added to authconfig only recently ipa-client-install does not know that it needs to handle --noac with this action as well, but it is really needed to be added.

Please understand, that the situation here is very different from the bug 953453 because in this case the user explicitly asked for sss to be removed from nsswitch.conf prior to enablement of IPA and that means he most probably also does not want it to stay in nsswitch.conf after IPA is uninstalled.

I've straced ipa-client-install --noac and then ipa-client-install --uninstall. After each call I also diffed nsswitch.conf.

tl;dr; ipa-client-install calls authconfig, but doesn't add nor remove sss from nsswitch.conf for services stated in d). It touches 'sudoers' but not through authconfig.

Therefore the stated actual result of this BZ: "sss is in nsswitch.conf after uninstall" has nothing to do with ipa-client-install.

But after investigation of --noac origin, I agree that we have a bug, or more precisely that we incorrectly changed meaning of --noac option.

Help text for the option now says:
  "do not modify the nsswitch.conf and PAM configuration" 
instead of original:
  "do not use Authconfig to modify the nsswitch.conf and PAM configuration".

It was because of 
* https://fedorahosted.org/freeipa/ticket/4052
* https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=5f31f2d35f714880230c1a92a322c620e8708eb3

For others: --noac option was requested by: bug 789413

Question: --noac should mean:
a) ipa-client-install should not call authconfig
b) a) + ipa-client-install should not touch nsswitch.conf

Because

ipa-client-install also touches nsswitch.conf directly to add 'sss' into 'sudoers'. It then removes it on uninstall.

Strace results (grep 'execve("/usr/sbin/authconfig"'):

install with --noac:

16275 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--update", "--nisdomain", "example.com"], [/* 29 vars */] <unfinished ...>


--uninstall after install with --noac:

16007 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--disablekrb5", "--disablesssdauth", "--disablemkhomedir", "--update", "--disableldap"], [/* 28 vars */] <unfinished ...>
16071 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--update", "--nisdomain", ""], [/* 28 vars */] <unfinished ...>


install without --noac:

16627 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--enablesssdauth", "--update", "--enablesssd"], [/* 29 vars */] <unfinished ...>
16737 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--update", "--nisdomain", "example.com"], [/* 29 vars */] <unfinished ...>

--uninstall after install without --noac:

16894 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--disablesssdauth", "--update"], [/* 28 vars */] <unfinished ...>
16972 execve("/usr/sbin/authconfig", ["/usr/sbin/authconfig", "--update", "--nisdomain", ""], [/* 28 vars */] <unfinished ...>

The problem is once the authconfig is recursively called from ipa-client-install when it is called itself from authconfig, the outcome is basically undefined and I cannot fix that in authconfig.

It might be true that previously this worked fine only by coincidence though. I could try to fix the potential error in authconfig only after ipa-client-install will not call-back authconfig when started with --noac option.

Ok, ipa-client-install should not call authconfig in any way with --noac.

From the strace you can see that it also called authcounfig to set nisdomain. Does caller of `authconfig --enableipav2 ...`  call `authconfig --nisdomain ...` as well? Or is it handled by authconfig? I want to make sure that we won't break anything else.

Will authconfig deal with direct change in nsswitch.conf done by ipa-client-install(to set `sudoers: files sss`) when ipa-client-install is called  by authconfig?

Direct change of nsswitch.conf to manipulate sudoers does not matter to authconfig as it will not overwrite this change.

Why does the nisdomain need to be set?

Authconfig currently does not set it when enabling ipav2, so that would have to be added.

ipa-client-install configures $domain as NIS domain by default unless --no-nisdomain option is supplied. People might expect that IPA configured by authconfig will have the same behaviour. I don't know if that's really the case.

It reveals a design flaw in the --noac usage. There is no single source of truth. Every time ipa-client-install does a change in its usage of authconfig, authconfig will have to do the same change. It's very prone to bugs.

It would be better if authconfig could handle the recursive call and ipa could drop the option.

Is it really so impossible, as you write in comment 2, for authconfig to prepare itself for an outcome of the recursive call?

I think we aren't getting anywhere this way. Basically the recursive call can do anything to files that authconfig configures and thus it cannot expect anything. You also cannot expect that the settings done by the recursive call will stay saved. But feel free to close this as wontfix but I will not fix this in authconfig either.

I feel more and more that the IPA support in authconfig was a mistake and should be dropped.

And the only supported way to join IPA domain would be directly through the ipa-client-install command.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4677

Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as WONTFIX. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.