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 <[email protected]> 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 <[email protected]> > 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 <[email protected] >> > <mailto:[email protected]>> 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 >> >> <[email protected] <mailto:[email protected]>> 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
