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
https://www.redhat.com/archives/freeipa-users/2015-March/msg00538.html
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
>>> though,
>>> 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:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to