FYI, I think the culprit (at least one of) is ipa-client-automount
--uninstall. This removes sss entirely from nssswitch, not just from the
On Tue, Sep 1, 2015 at 11:56 AM, Prasun Gera <prasun.g...@gmail.com> wrote:
> So I've again spent a couple of hours debugging a very similar issue.
> Client install would seemingly pass, but with "Unable to find 'admin' user
> with 'getent passwd admin@domain'!" at the end. And nobody would be able
> to authenticate. The reason was that /etc/nsswitch.conf wasn't updated. sss
> wasn't added to it. Wading through his thread
> provided some hints. I have no idea why it did that, but as I have
> experienced before, modifying critical system files this way from python
> scripts which don't have proper transnactional support is very dangerous. I
> suspect that this has something to do with a prior failed install or
> uninstall attempt which left it in an inconsistent state. Is it possible to
> move from this backup-modify-restore approach to critical files to
> something more robust which has transnational guarantees ?
> On Sat, Jun 27, 2015 at 6:26 AM, Dmitri Pal <d...@redhat.com> wrote:
>> On 06/24/2015 04:31 AM, Jakub Hrozek wrote:
>>> On Wed, Jun 24, 2015 at 01:24:37AM -0700, Prasun Gera wrote:
>>>> Thanks. It's good to know that it is fixed upstream. For discussion
>>>> are any enhancements planned for dealing with installation/removal of
>>>> ipa ?
>>> Not sure, but please file bugs as you see them.
>>> Yes, please be more specific . The bugs that were mentioned by Jakub are
>> making its way into downstream. If there are any other issues you are
>> concerned about please let us know.
>> Thank you,
>> Dmitri Pal
>> Director of Engineering for IdM portfolio
>> Red Hat, Inc.
>> Manage your subscription for the Freeipa-users mailing list:
>> Go to http://freeipa.org for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project