[Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18

Petr Viktorin pviktori at redhat.com
Tue Sep 11 14:18:32 UTC 2012


I clarified with Ade that d9-style instances need pkiremove even under 
d10, and went through other items that changed to verify what they do in 
this case. I put the set of constants into namespace classes to simplify 
handling them, since more parts of CAInstance need bits for the 
configured version that Ade's patch suggested.

I've added the pkispawn config file to the logs, and bumped the 
certmonger version in the specfile.


On 09/11/2012 02:59 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> On 09/11/2012 04:04 AM, Ade Lee wrote:
>>> On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote:
>>>> Petr Viktorin wrote:
>>>>> Attaching rebased and squashed patches. I've done some testing with
>>>>> them
>>>>> but please test some more.
>>>>>
>>>>
>>>> Most of these aren't IPA issues, but dogtag issues. I'll try to split
>>>> them out.
>>>>
>>>> IPA:
>>>>
>>>> For the configuration files in install/conf to be updated at rpm update
>>>> time the VERSION needs to be incremented.
>>
>> These files should stay the same since on upgrade we're still using a
>> Dogtag 9 style instance. The Dogtag 10 ports are only used in new
>> installs.
>>
>>>> The ipa package lacks any updated dogtag dependencies, so I abused it.
>>
>> What should the updated dependencies be? Since it should work with both
>> dogtag 9 and 10, I don't see how they should change.
>
> I don't know either, but we need to prevent people from installing
> incompatible package combinations.
>
>>>> I installed IPA with dogtag 9 and created a replica.
>>>>
>>>> I updated the IPA bits, that worked fine.
>>>>
>>>> I updated to dogtag 10 and now the CA doesn't work on the master,
>>>> including starting the dogtag instance. Note that the rpm update
>>>> process
>>>> worked, no notice that the CA service didn't restart.
>>>>
>>> Did you try to restart the CA with selinux in permissive mode?  This is
>>> still required right now until I get the selinux policy all straightened
>>> out.
>>>
>>> There is also a separate dogtag ticket (which is currently being worked
>>> on) to restart existing dogtag instances when dogtag is upgraded from
>>> 9->10.
>>
>> In permissive mode, this upgrade works for me.
>
> I was in enforcing mode but saw no AVCs. What is the ETA on fixing this?
>
>>
>>
>> Sometimes I do get this error intermittently:
>>
>> ipa: ERROR: Certificate operation cannot be completed: Unable to
>> communicate with CMS (Service Temporarily Unavailable)
>>
>> Usually, waiting a couple of minutes clears this up. Perhaps we are not
>> doing startup detection correctly. Ade mentioned that waiting for ports
>> may not be ideal. How do we know if Dogtag is initialized?
>
> Years ago we had discussed with Andrew and Matt creating a URI that can
> be queried to determine dogtag status. I don't think that ever went
> anywhere.
>
>>
>>>> Uninstalling failed because it tried to run pkidestroy and not
>>>> pkiremove.
>>
>> I was under the impression that pkidestroy was the correct command to
>> remove an upgraded instance. I'll check with Ade.
>>
>>> I'll test this too.
>>>
>>>> The contents of the file passed to pkispawn should be logged so we can
>>>> see exactly what was passed in.
>>>>
>>> Its a pretty big file.  You might want to only log the modifications.
>>> Or save the file somewhere.
>>
>> Our logs are pretty verbose, so that shouldn't be a problem. I'll put it
>> in the next version of the patch.
>
> The question to ask is: would you need the contents of this file if all
> you got were logs and needed to evaluate why installation failed? In
> most cases this is yes.
>
>>>> DOGTAG:
>>>>
>>>> When upgrading using the dogtag-devel repo I had to specify
>>>> pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit
>>>> versions (and failed).
>>>>
>>>> I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64
>>>> --enablerepo=dogtag-devel --enablerepo=updates-testing
>>>>
>>> We'll look into this.  I think I know why this happens.
>>>
>>>> What happens if someone manually upgrades pki-ca without first updating
>>>> ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it.
>>>
>>> We can add that.
>>>
>>>> certificate renewal failed. I spent far too long trying to figure out
>>>> why tomcat wasn't listening on port 9180 but failed. I think 9180 is
>>>> actually the old server, right? So another missing dependency on a
>>>> fixed
>>>> certmonger?
>>>>
>>>> The best I could find was the certmonger error:
>>>>
>>>> ca-error: Error 7 connecting to
>>>> http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect
>>>> to server.
>>>>
>>
>> I'll set the certmonger min version to 0.60 as per Nalin's mail.
>
> Ok.
>
>>> Is this cert renewal on a dogtag 10 instance?  Or the upgraded dogtag 9?
>>> If its dogtag 10, perhaps you do not have the certmonger version that
>>> has the relevant fix?  If its dogtag 9, then we need to figure out whats
>>> going on.  That reminds me - I need to file a bug to allow certmonger to
>>> talk to the newly defined dogtag ports.  Do you have selinux permissive?
>>>
>>>> There is no man page for pkispawn/pkidestroy :-( According to the FHS
>>>> these should not be in /bin but in /usr/sbin (not end-user commands).
>>>>
>>> There is a trac ticket open for man pages for pkispawn and pkidestroy.
>>> We plan to complete this ticket by the time f18 is released.
>>>
>>> We'll look into the location of pkispawn/pkicreate.
>>>
>>>> The output of pkicreate/pkisilent was really terrible and not usable at
>>>> all so we didn't display it when failures occurred. It looks like that
>>>> has been addressed, at least for the case where a CA is already
>>>> configured and you try to install IPA. Perhaps we should capture stderr
>>>> and display that instead of the command-line of pkispawn? Again, a man
>>>> page would help with the integration.
>>>>
>>>> 2012-09-10T20:51:45Z DEBUG   [2/18]: configuring certificate server
>>>> instance
>>>> 2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq
>>>> 2012-09-10T20:51:45Z DEBUG stdout=
>>>> 2012-09-10T20:51:45Z DEBUG stderr=pkispawn    : ERROR    ....... PKI
>>>> subsystem 'CA' for instance 'pki-tomcat' already exists!
>>>>
>>>> 2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command
>>>> '/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1
>>>>
>>> That may be a good idea.  Of course. thats an IPA thing, right?
>
> Right, not a show-stopper for this but a new ticket should be opened to
> track it.
>
> rob
>


-- 
Petr³
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0074-05-Use-Dogtag-10-only-when-it-is-available.patch
Type: text/x-patch
Size: 57887 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120911/1e971b18/attachment.bin>


More information about the Freeipa-devel mailing list