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:
> >>>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!
> >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
> >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
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code