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

[Fraser Tweedale]

On Wed, May 11, 2016 at 04:36:34PM +0200, Jan Cholasta wrote:
> 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.
> 
That's true.  The longer answer is that every replica has the same
version of the file, and when we need to change the default profile
we should be implementing a mechanism to automatically update to
latest version: https://fedorahosted.org/freeipa/ticket/5323.  So I
don't think it would be a problem in practice.

> >
> >>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.)
> 
Martin, if the profile is incorrect, do we have to fix it
automatically?  What are our obligations / customer expectations
here?