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.
On Tue, May 7, 2013 at 10:50 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
> John Blaut wrote:
>> 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
>> 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
> 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
> 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
Freeipa-users mailing list