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).


> I'll post the logs if I can't make progress. 
> Regards,
> Prasun
> On Wed, Mar 18, 2015 at 3:12 PM, Dmitri Pal <
> <>> 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
>>     < <>> 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:
>     Go to for more info on the project

Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to