<div dir="ltr">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? </div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Mar 18, 2015 at 6:35 PM, Prasun Gera <<a href="mailto:prasun.gera@gmail.com" target="_blank">prasun.gera@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. </div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"> <div class="gmail_quote">On Wed, Mar 18, 2015 at 5:55 PM, Rob Crittenden <<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a> <div><div>> <mailto:<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>>> 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 </div></div><div><div>>> <<a href="mailto:prasun.gera@gmail.com" target="_blank">prasun.gera@gmail.com</a> <mailto:<a href="mailto:prasun.gera@gmail.com" target="_blank">prasun.gera@gmail.com</a>>> 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: > <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> > Go to <a href="http://freeipa.org" target="_blank">http://freeipa.org</a> for more info on the project > > > > </div></div></blockquote></div> </div> </div></div></blockquote></div> </div>