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
