[Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile

[Jan Cholasta]

On 11.5.2016 15:04, Fraser Tweedale wrote:
> On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote:
>> On 11.5.2016 11:22, Fraser Tweedale wrote:
>>> Hi,
>>>
>>> Re: Bug 1327092 - URI details missing and OCSP-URI details are
>>> incorrectly displayed when certificate generated using IPA.
>>>
>>> This issue occurs when replica installation overwrites the existing
>>> IPA version of the caIPAserviceCert profile with the version shipped
>>> with Dogtag.  My patch 0057 prevents the issue from occuring but
>>> does not repair installations where the problem already happened.
>>>
>>> For repair, one possibility is to detect when this has occured, and
>>> re-import the IPA version of the profile.  IMO this would be quite
>>> brittle, e.g. if the profile shipped with Dogtag changes or if user
>>> has made other changes to the profile it may no longer work.
>>>
>>> I propose to add a new option to ``ipa certprofile-mod`` which can
>>> be used to restore profiles shipped with IPA to a "pristine" state.
>>> This would allow admins of affected installations to run a single
>>> command to repair the profile, but I think it is an independently
>>> useful feature, e.g. if admin messes up a profile but didn't keep a
>>> backup of the original config, they can easily get back to the
>>> original state.
>>>
>>> The new option would only be applicable to included profiles (error
>>> otherwise).  I suggest it be called ``--reset``.  Example usage:
>>>
>>>    ipa certprofile-mod caIPAserviceCert --reset
>>>
>>> All comments welcome!
>>
>> NACK,
>>
> Honza, thanks for your feedback.
>
>> 1) This is a separate operation, so it should be a separate command.
>>
> certprofile-mod already supports updating the Dogtag profile
> configuration, via `--file <FILE>` option.  However, we cannot use
> that with /usr/share/ipa/profiles/* because these are templates that
> have installation-specific values substituted into them.
> Consequently, your suggestion at (3) is not feasible.  The need to
> do the template substitutions is what led me to this proposal.

I stand corrected.

>
>> 2) I don't think it is generally a good idea to have a command which relies
>> on some file being existent or having expected content on all replicas.
>>
> The operation would only need to be performed on a single replica
> (Dogtag profiles are stored in LDAP and replicated), so there is no
> such reliance.

Sure, but how are you going to guarantee the command is executed on a 
replica with the right version of the file? The short answer is that you 
can't, but an API command should do the same thing no matter what 
replica you are talking to.

>
>> 3) I would rather avoid adding new commands just to work around bugs. IMO
>> "certprofile-import caIPAserviceCert
>> /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this
>> case.
>>
> As discussed above, I'm afraid it is not, unless users manually do
> the substitutions.  If we provide some code to do the substitutions,
> we have essentially reach what I have proposed.
>
> Other suggestions are welcome.
>
> BTW, there is another option I did not already mention: do nothing
> in code, and help users on a case-by-case basis / point them to a
> guide / KB article?

This option is my favorite :-) (If automatic fix during upgrade is 
indeed out of the picture.)

-- 
Jan Cholasta