[Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server
Rob Crittenden
rcritten at redhat.com
Wed Mar 18 21:55:52 UTC 2015
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 <dpal at redhat.com
> <mailto:dpal at 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 at localhost <- This works for the first
>> time, fails second time onwards
>> ssh admin at 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.gera at gmail.com <mailto:prasun.gera at 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 at 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
>
>
>
>
More information about the Freeipa-users
mailing list