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

2016-05-12 Thread Martin Kosek
On 05/12/2016 12:56 AM, Fraser Tweedale wrote:
> 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:
...
 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?

I would love to hear customer expectations, but in that case you should ask the
users/customers, not me :-) But having documented procedure in a KB/wiki
article how to fix a broken profile seems as a good enough for me, we can build
the API command later if we see a pressing need.

Martin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-05-11 Thread 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 ` 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?

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-05-11 Thread 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 ` 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

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-05-11 Thread Fraser Tweedale
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 ` 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.

> 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.

> 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?

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


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

2016-05-11 Thread Jan Cholasta

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,

1) This is a separate operation, so it should be a separate command.

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.


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.


Honza

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code