I think I have figured it out. The contents of /var/lib/sss/db are not
cleared on uninstall. Stopping sssd, clearing that directory and restarting
sssd solves the problem. Is there a reason why this is not cleared on
uninstall?

On Wed, Mar 18, 2015 at 6:35 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> No I haven't been using docker images. I was merely suggesting it as a way
> of reproducing the failure consistently and passing it on. I have been
> running everything natively. Barring external factors such as DNS, which
> probably don't matter in this case, I think this should be reproducible on
> an up to date RHEL 7 system. From your comments, I guess the domain name is
> not that important; at least not on the server itself since the client on
> the server should have no trouble finding the server. The specific cases
> for which reboot works could be a red herring, and not related to the
> domain name at all. However, any success I've had so far has only been with
> reboots, the choice of domain name notwithstanding. Is there a checklist of
> files that need to be cleaned up after an uninstall? I can try doing a
> manual wipe if that helps.
>
> On Wed, Mar 18, 2015 at 5:55 PM, Rob Crittenden <rcrit...@redhat.com>
> wrote:
>
>> Prasun Gera wrote:
>> > How do I confirm that there are no certs left behind and that
>> > cert-monger isn't tracking them? I'm a bit new to all the components
>> > used by IPA. I do see that the /root/cacert.p12 file is never deleted.
>>
>> Not clean but this shouldn't prevent re-install.
>>
>> > After an uninstall, I see this:
>> > getcert list
>> > Number of certificates and requests being tracked: 0.
>> >
>> > getcert status
>> > process 31282: arguments to dbus_message_new_method_call() were
>> > incorrect, assertion "path != NULL" failed in file dbus-message.c line
>> 1262.
>> > This is normally a bug in some application using the D-Bus library.
>> >   D-Bus not built with -rdynamic so unable to print a backtrace
>> > Aborted (core dumped)
>>
>> Please open a bug against certmonger.
>>
>> >
>> >
>> > I ran a few more tests, and I have had partial success with some
>> > configurations. Here's what I found:
>> >
>> > 1) The install-uninstall-install sequence definitely seems to be broken
>> > (at least for my configuration), and should be reproducible fairly
>> > easily. I would like to reproduce this consistently in a docker
>> > image/vm, but docker is apparently not supported on satellite subscribed
>> > RHEL systems. The only variable in the system is dns(external) and the
>> > choice of ipa domain name. The ipa server setup was pretty stock with no
>> > integrated dns. I don't know if some ipa domain names are preferred over
>> > others, but I feel that it shouldn't affect the client on the server at
>> > least.
>>
>> I think IPA in docker is still rather experimental. Are you
>> re-installing within a docker image?
>>
>> > 2) I had some success with reboots. i.e. After the last install,
>> > rebooting the computer solves the problem for some cases at least. I am
>> > not sure if it is a general solution. I think it's also related to the
>> > choice of the domain name. The reboot trick doesn't help if the ipa
>> > domain name is the one derived from hostname.  It did work for a random
>> > domain name though.
>>
>> I don't know why the domain name would make a difference one way or
>> another.
>>
>> > 3) I need to understand how important the IPA domain name is. Should the
>> > ipa domain name be related to the hostname of the server (as suggested
>> > by the script)? What happens if someone else has another ipa server with
>> > the same domain name on the network? Also, what happens if there is
>> > another NIS server with the same domain name on the network? And lastly,
>> > what if the ipa server is setup on an existing  NIS server or an NIS
>> > client ? I have tried a lot of permutations, and I have a feeling that
>> > this problem is somehow tied to the name resolution, and domain names,
>> > with external dns servers possibly playing a part.
>>
>> IPA just needs valid DNS names. It doesn't matter where they come from
>> or what they are.
>>
>> There can be a conflict with realm names if you want to rely on DNS
>> discovery and there are conflicts (with AD for example).
>>
>> rob
>>
>> >
>> > I'll post the logs if I can't make progress.
>> >
>> > Regards,
>> > Prasun
>> >
>> > On Wed, Mar 18, 2015 at 3:12 PM, Dmitri Pal <d...@redhat.com
>> > <mailto:d...@redhat.com>> wrote:
>> >
>> >     On 03/17/2015 02:54 PM, Prasun Gera wrote:
>> >>     Sorry, the message got sent accidentally earlier before I could
>> >>     provide all the details.
>> >>
>> >>     Version: 4.1.0 on RHEL 7.1 x86_64
>> >>
>> >>     Steps:
>> >>     1. ipa-server-install
>> >>     2. service sshd restart
>> >>     3. kinit admin                              <- This always works
>> >>     4. ssh admin@localhost             <- This works for the first
>> >>     time, fails second time onwards
>> >>         ssh admin@host_addr from external system      <- This also
>> >>     works the first time, fails second time onwards
>> >>
>> >>     5. ipa-server-install --uninstall
>> >>     6. go to 1
>> >>
>> >>     The log messages in /var/log/messages point
>> >>     to [sssd[krb5_child[21029]]]: Decrypt integrity check failed at
>> >>     the point of the authentication failure
>> >>     sssd's log's have a lot of "No matching domain found for user"
>> >>     messages.
>> >>     /var/log/krb5kdc.log has a lot of error decoding FAST: <unknown
>> >>     client> for <unknown server>, Decrypt integrity check failed while
>> >>     handling ap-request armor
>> >>
>> >>     The only ERROR I can see in /var/log/ipaserver-uninstall.log is
>> >>     pkidestroy  : ERROR    ....... subprocess.CalledProcessError:
>> >>      Command '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca',
>> >>     ......returned non-zero exit status 6!
>> >>
>> >>
>> >>     It appears that the uninstall process is leaving some residual
>> >>     configuration behind which is conflicting with the subsequent
>> >>     installation with the same domain name
>> >
>> >
>> >     SSSD and certificate issues with re-install would be unrelated.
>> >
>> >
>> >     Let us start over. Remove IPA, try it several times, it helps
>> >     sometimes as it moves forward and cleans more on each attempt. Make
>> >     sure there are no certs left and certmonger is not tracking
>> anything.
>> >     If you still experience issues with SSSD, add debug_level=10 to sssd
>> >     configuration in the domain section, restart sssd and send the
>> >     sanitized logs for the failed attempts.
>> >
>> >
>> >>
>> >>
>> >>     Regards,
>> >>     Prasun
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera
>> >>     <prasun.g...@gmail.com <mailto:prasun.g...@gmail.com>> wrote:
>> >>
>> >>         Hello,
>> >>         I installed the ipa-server on an RHEL 7.1 system, uninstalled
>> >>         it and reinstalled it with the same domain name as the first
>> >>         time. This somehow creates problems with ssh authentication on
>> >>         the server from external systems as well as from the server
>> >>         itself.
>> >>
>> >>         Steps:
>> >>         1. ipa-server-install
>> >>         2. service sshd restart
>> >>         3. kinit admin
>> >>         4. ssh admin@localhost
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >     --
>> >     Thank you,
>> >     Dmitri Pal
>> >
>> >     Sr. Engineering Manager 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