[Freeipa-users] ipa-replica-prepare clarification

[Rob Crittenden]

James Roman wrote:
> Yes the valicert.com certificate did get installed in the DS cert 
> database and then subsequently failed to install in the web server 
> database. I can't find any output to indicate why it was missed. The 
> answer to your next question is yes, I did specify  the same PKCS12 
> certificate file and pin for the dirsrv and http options when I ran 
> ipa-replica-prepare.
> 
> Now I am getting past the certificate trust failure, but have 
> encountered a whole new set of problems. My Directory server is failing 
> to start with the following error:
> 
> Starting dirsrv:
>    REALM-COM...[15/Sep/2009:09:39:18 -0400] dse - The entry cn=schema in 
> file /etc/dirsrv/slapd-REALM-COM/schema/99user.ldif is invalid, error 
> code 21 (Invalid syntax) - object class nsAIMpresence: Unknown allowed 
> attribute type "nsaimid"
> [15/Sep/2009:09:39:18 -0400] dse - Please edit the file to correct the 
> reported problems and then restart the server.
> 
> I am pretty sure I know why this is happening, I'm just not sure how I 
> want to address it. My Master is a FC9 install, my replica is a FC10 
> install. My master was installed as FC9 due to issues loading FC10 into 
> a Cent 5 Xen VM. Now that I've overcome those, I was hoping that I could 
> go this route to provide a migration path. Perhaps not. This will be 
> subject of a new thread.

I've seen this happen too, it is a bug in 389-DS I think. It doesn't 
happen all the time though, I've worked around it by trying the replica 
installation again.

rob

> 
> Rob Crittenden wrote:
>> James Roman wrote:
>>> I installed the 1.2.2-1 version from the test repo. I get really 
>>> close to the end, but it is still bombing when trying to set the 
>>> trust permissions on the web server cert. For some reason the final 
>>> cert in the chain did not get installed into the /etc/httpd/alias 
>>> directory. All worked fine for the directory server.
>>
>> Strange, Does the valicert.com certificate exist in the DS database?
>>
>> I guess I assumed that if the certificate was in the PKCS#12 file then 
>> it would be loaded by NSS. That doesn't seem to be the case.
>>
>> This patch should help. It will log the failure of setting trust but 
>> will continue. If the certificate is indeed not needed then it 
>> shouldn't hurt anything.
>>
>> diff --git a/ipa-server/ipaserver/certs.py 
>> b/ipa-server/ipaserver/certs.py
>> index 95e6ac7..3782acf 100644
>> --- a/ipa-server/ipaserver/certs.py
>> +++ b/ipa-server/ipaserver/certs.py
>> @@ -386,8 +386,11 @@ class CertDB(object):
>>           if root_nickname[:7] == "Builtin":
>>               logging.debug("No need to add trust for built-in root 
>> CA's, skippi
>>           else:
>> -             self.run_certutil(["-M", "-n", root_nickname,
>> -                                "-t", "CT,CT,"])
>> +             try:
>> +                 self.run_certutil(["-M", "-n", root_nickname,
>> +                                    "-t", "CT,CT,"])
>> +             except ipautil.CalledProcessError, e:
>> +                 logging.error("Setting trust on %s failed" % 
>> root_nickname)
>>
>>      def find_server_certs(self):
>>          p = subprocess.Popen(["/usr/bin/certutil", "-d", self.secdir,
>>
>> The file to modify on an installed system is 
>> /usr/lib[64]/python*/site-packages/ipaserver/certs.py
>>
>> Let me know if this fixes it for you and I'll see about getting this 
>> committed.
>>
>> rob
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20090915/61cafe0a/attachment.bin>