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

[Rob Crittenden]

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