[Freeipa-users] ipa-client-install: done remotely, DNS discovery and multiple servers

John Blaut john.blaut at gmail.com
Tue May 7 22:42:38 UTC 2013


Hi

Many thanks for the feedback and bringing those tickets to my attention.

I tried the 'ipa-getcert resubmit' before posting this, but it did not
help. The status remained NEED_CSR.
I'll try a few other things which come to mind.

Regards

John


On Tue, May 7, 2013 at 10:50 PM, Rob Crittenden <rcritten at redhat.com> wrote:

> John Blaut wrote:
>
>> Hi
>>
>> Since EL 6.4, executing ipa-client-install over SSH i.e. 'ssh <client>
>> "ipa-client-install <params>"', results in an issue with the host
>> certificate.
>>
>> The output returns the following error during the: 'ipa-getcert request
>> -d /etc/pki/nssdb' stage:
>>
>> TLS: could not close certdb slot - error -8018:Unknown PKCS #11 error.
>> TLS: could not shutdown NSS - error -8053:NSS could not shutdown
>>
>> The host certificate remains in state: 'status: NEED_CSR' when checking
>> with ipa-getcert list
>>
>
> I'm not able to reproduce this.
>
> You might try:
>
> ipa-getcert resubmit -i <requestid> post-install to see if it goes out of
> NEED_CSR.
>
>
>  In EL6.2 and EL6.3 this was not an issue.
>> Perhaps you may reproduce this and advise.
>> In order to work around this, I end up having to run ipa-client-install
>> locally on the client.
>>
>> Also, with 6.4, thanks to the --fixed-primary switch we can now
>> statically set specific IPA servers to use for a given client, instead
>> of rely on DNS (SRV records) discovery. Before this feature we would
>> need to patch the sssd.conf manually and restart SSSD, as
>> ipa-client-install would remain stuck since the given client via SRV
>> discovery would attempt using an IPA server it does not have access to.
>> Now we longer have this issue, however ipa-client-install still picks
>> the NTP server with which it should synchronize time during the
>> enrolment process via DNS discovery. In the past ipa-client-install
>> would 'give up' after 3 attempts or so, but now it keeps attempting
>> until it encounters a reachable IPA NTP server. In an environment where
>> there is a significant amount of IPA servers installed and distributed
>> in different places where access is restricted by location, it can take
>> some time until the reachable IPA/NTP server for a given client/location
>> is found.
>>
>> A suggestion would be that if one goes for the --fixed-primary +
>> --server options, then the omission of DNS discovery should not only
>> apply to the IPA service but also for time synchronization. In most
>> cases chances are that if one opts to use specific servers for IPA, one
>> probably also wants to use specific servers for NTP. Or for added
>> flexibility, provide another switch to select a specifc server to
>> synchronize time with during the enrolment process. FYI, use of the
>> --ntp-server switch does not prevent the enrolment process from using
>> DNS discovery to synchronize the time. I suppose that switch is only
>> used for setting the NTP server to use if one wishes to configure NTPD.
>> (Besides not everyone opts to use NTPD on clients - some use an ntpdate
>> job - so fixed-server time synchronization during enrolment should also
>> be possible when using -N/--no-ntp)
>>
>
> We have a number of tickets against NTP. There is some amount of overlap,
> but it doesn't seem to cove everything.
>
> Specifically tickets https://fedorahosted.org/**freeipa/ticket/3092<https://fedorahosted.org/freeipa/ticket/3092>,
> https://fedorahosted.org/**freeipa/ticket/2992<https://fedorahosted.org/freeipa/ticket/2992>and
> https://fedorahosted.org/**freeipa/ticket/1954<https://fedorahosted.org/freeipa/ticket/1954>
>
> If we've missed anything any chance you can open a ticket (or tickets) for
> the new features?
>
>
>  One last thing is that when using the --server option multiple times, it
>> seems the order in sssd.conf is reversed. Example if I specify --server
>> node1 --server node2, in sssd.conf I will end up with: ipa_server =
>> node2, node1 Therefore I specify the servers to begin with in reverse
>> order, in order to have them configured in the desired order.
>>
>
> Fixed upstream https://fedorahosted.org/**freeipa/ticket/3418<https://fedorahosted.org/freeipa/ticket/3418>
>
> regards
>
> rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130508/bbfceeaf/attachment.htm>


More information about the Freeipa-users mailing list