[Freeipa-devel] [freeipa PR#625][closed] [RFC] remote plugins: add option to force compat plugins

2017-07-10 Thread HonzaCholasta via FreeIPA-devel 
   URL: https://github.com/freeipa/freeipa/pull/625
Author: HonzaCholasta
 Title: #625: [RFC] remote plugins: add option to force compat plugins
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/625/head:pr625
git checkout pr625
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] [freeipa PR#910][opened] ipatests: do not finalize api when IPA is not configured

2017-07-10 Thread tomaskrizek via FreeIPA-devel 
   URL: https://github.com/freeipa/freeipa/pull/910
Author: tomaskrizek
 Title: #910: ipatests: do not finalize api when IPA is not configured
Action: opened

PR body:
"""
Pytest can be executed from a machine that doesn't have IPA configured.
In this case, api can't be finalized because values such as basedn are
unknown and missing.

Fixes https://pagure.io/freeipa/issue/7046

Signed-off-by: Tomas Krizek 

Tests passed: 
https://fedorapeople.org/groups/freeipa/prci/jobs/756acbea-657f-11e7-bdab-c85b762c9683
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/910/head:pr910
git checkout pr910
From da1c51b2ae47dfcab174ba66cb3d20a1920797e8 Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Mon, 10 Jul 2017 14:43:18 +0200
Subject: [PATCH] ipatests: do not finalize api when IPA is not configured

Pytest can be executed from a machine that doesn't have IPA configured.
In this case, api can't be finalized because values such as basedn are
unknown and missing.

Fixes https://pagure.io/freeipa/issue/7046

Signed-off-by: Tomas Krizek 
---
 ipatests/conftest.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ipatests/conftest.py b/ipatests/conftest.py
index a57bf7de45..c6c846e79f 100644
--- a/ipatests/conftest.py
+++ b/ipatests/conftest.py
@@ -18,6 +18,7 @@
 ipaplatform = None
 try:
 import ipaserver
+from ipaserver.install import installutils
 except ImportError:
 ipaserver = None
 
@@ -105,7 +106,7 @@ def pytest_cmdline_main(config):
 
 # XXX workaround until https://fedorahosted.org/freeipa/ticket/6408 has
 # been resolved.
-if ipaserver is not None:
+if ipaserver is not None and installutils.is_ipa_configured():
 api.finalize()
 
 if config.option.verbose:
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] [freeipa PR#909][opened] IPAOptionParser: fix dict comprehension

2017-07-10 Thread MartinBasti via FreeIPA-devel 
   URL: https://github.com/freeipa/freeipa/pull/909
Author: MartinBasti
 Title: #909: IPAOptionParser: fix dict comprehension
Action: opened

PR body:
"""
The statement can be simplified and be more resources friendly
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/909/head:pr909
git checkout pr909
From eea18338ac36c3d4a9d44fe671d47eafd15f936d Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Mon, 10 Jul 2017 14:54:10 +0200
Subject: [PATCH] IPAOptionParser: fix dict comprehension

The statement can be simplified and be more resources friendly
---
 ipapython/config.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ipapython/config.py b/ipapython/config.py
index 19abfc51ee..6e53472e08 100644
--- a/ipapython/config.py
+++ b/ipapython/config.py
@@ -114,7 +114,10 @@ def get_safe_opts(self, opts):
 Returns all options except those with sensitive=True in the same
 fashion as parse_args would
 """
-all_opts_dict = dict([ (o.dest, o) for o in self._get_all_options() if hasattr(o, 'sensitive') ])
+all_opts_dict = {
+o.dest: o for o in self._get_all_options()
+if hasattr(o, 'sensitive')
+}
 safe_opts_dict = {}
 
 for option, value in opts.__dict__.items():
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [DESIGN] Certificate profile update mechanism

2017-07-10 Thread Fraser Tweedale via FreeIPA-devel 
On Mon, Jul 10, 2017 at 12:44:40PM +0200, Tomas Krizek wrote:
> On 07/10/2017 12:16 PM, Simo Sorce via FreeIPA-devel wrote:
> > Hi Fraser,
> > I think you put on a reasonable proposal, however If I had to design
> > this right now and had the freedom to change dogtag and the rest of
> > freeipa to cope I would do the following:
> >
> > - Change the LDAP profile storage to have versioned subtrees for
> > "system" profiles, and have a "custom" subtree for user profiles.
> >
> > - In the base tree have a version attribute that set what version
> > dogtag should use, if absent dogtag will assume its current hardcoded
> > default version. Profiles are never updated per se, a new version is
> > installed and the version is upped.
> >
> > - On upgrade a modified profile is moved to the "custom" tree and the
> > original version of the profile is stored in the system tree. This is
> > assuming this does not cause older versions of dogtag to misbehave,
> > otherwise we keep the modified version and make sure not to raise the
> > version to use. We also find a way to notify the admin he should move
> > customized profiles in the correct new section and leave system
> > profiles alone.
> >
> > - Potentially if a dogtag server does not understand a new version, it
> > keeps using an older version (perhaps we can have a "mandatory version
> > attribute" to cause older versions to return an error instead. (see
> > also previous case)
> >
> > The reason for this is that having a complex check on ipa versions is
> > potentially fragile as well it adds yet another dimension to the things
> > an admin need to know about to figure out why its domain is not using
> > the "right" profiles.
> > And I think in some cases there is no "conflict" between version
> > profiles only new "optional" attributes you may want to add/support.
> >
> > The other option is to tie the dogtag profiles version to the domain
> > level as well, and only ever use new ones when the whole domain level
> > is upped. This is conditional on newer versions of dogtag being able to
> > use older profile versions without modification in LDAP.
> I'd rather avoid any domain level bumps unless there is serious
> justification for it. Additional domain levels introduce big testing
> overhead.
> > HTH,
> > Simo.
> >
> >
> > On Sat, 2017-07-08 at 15:24 +1000, Fraser Tweedale via FreeIPA-devel
> > wrote:
> >> Hi all,
> >>
> >> I've published a draft design for the profile update mechanism.
> >> This feature is to ensure that we can safely update included
> >> profiles even when we use Dogtag profile components only available
> >> in new versions.
> >>
> >> https://www.freeipa.org/page/V4/Certificate_profile_update_mechanism
> >>
> >> Interested persons, please review the design.  In particular there
> >> are two main questions I would like to discuss:
> >>
> >> 1. We need to store the IPA version in IPA master entries.  What
> >>should be the schema?
> >>
> >>https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
> >> sm#IPA_master_entries
> >>
> >> 2. How should we deal with customised versions of included profiles?
> >>There is a big tradeoff here, of complexity + flexibility vs.
> >>simplicitity + reverting customisations to included profiles (and
> >>preventing them in future).
> >>
> >>https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
> >> sm#Dealing_with_modified_profiles
> >>
> I'm in favor of not supporting customized versions. I'm not sure how
> common it is to customize these profiles among users. Unless it is very
> common, I wouldn't support them to avoid the additional complexity. The
> users always have the option to automate these customizations after
> every server upgrade, if they really require them.
>
I agree - unfortunately we currently allow them so the questions
about how to deal with this remain (even if we transition to
preventing modification of included profiles in future).
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [DESIGN] Certificate profile update mechanism

2017-07-10 Thread Simo Sorce via FreeIPA-devel 
On Mon, 2017-07-10 at 12:44 +0200, Tomas Krizek wrote:
> On 07/10/2017 12:16 PM, Simo Sorce via FreeIPA-devel wrote:
> > Hi Fraser,
> > I think you put on a reasonable proposal, however If I had to
> > design
> > this right now and had the freedom to change dogtag and the rest of
> > freeipa to cope I would do the following:
> > 
> > - Change the LDAP profile storage to have versioned subtrees for
> > "system" profiles, and have a "custom" subtree for user profiles.
> > 
> > - In the base tree have a version attribute that set what version
> > dogtag should use, if absent dogtag will assume its current
> > hardcoded
> > default version. Profiles are never updated per se, a new version
> > is
> > installed and the version is upped.
> > 
> > - On upgrade a modified profile is moved to the "custom" tree and
> > the
> > original version of the profile is stored in the system tree. This
> > is
> > assuming this does not cause older versions of dogtag to misbehave,
> > otherwise we keep the modified version and make sure not to raise
> > the
> > version to use. We also find a way to notify the admin he should
> > move
> > customized profiles in the correct new section and leave system
> > profiles alone.
> > 
> > - Potentially if a dogtag server does not understand a new version,
> > it
> > keeps using an older version (perhaps we can have a "mandatory
> > version
> > attribute" to cause older versions to return an error instead. (see
> > also previous case)
> > 
> > The reason for this is that having a complex check on ipa versions
> > is
> > potentially fragile as well it adds yet another dimension to the
> > things
> > an admin need to know about to figure out why its domain is not
> > using
> > the "right" profiles.
> > And I think in some cases there is no "conflict" between version
> > profiles only new "optional" attributes you may want to
> > add/support.
> > 
> > The other option is to tie the dogtag profiles version to the
> > domain
> > level as well, and only ever use new ones when the whole domain
> > level
> > is upped. This is conditional on newer versions of dogtag being
> > able to
> > use older profile versions without modification in LDAP.
> 
> I'd rather avoid any domain level bumps unless there is serious
> justification for it. Additional domain levels introduce big testing
> overhead.

That is the problem with domain levels, you do not introduce a whole
new domain level for one feature. It means piling up (and keeping
disabled) features until you have enough to justify a domain level
bump. So that means, if that is the only option, the feature needs to
be delayed until there are enough.

Simo.

> > HTH,
> > Simo.
> > 
> > 
> > On Sat, 2017-07-08 at 15:24 +1000, Fraser Tweedale via FreeIPA-
> > devel
> > wrote:
> > > Hi all,
> > > 
> > > I've published a draft design for the profile update mechanism.
> > > This feature is to ensure that we can safely update included
> > > profiles even when we use Dogtag profile components only
> > > available
> > > in new versions.
> > > 
> > > https://www.freeipa.org/page/V4/Certificate_profile_update_mechan
> > > ism
> > > 
> > > Interested persons, please review the design.  In particular
> > > there
> > > are two main questions I would like to discuss:
> > > 
> > > 1. We need to store the IPA version in IPA master entries.  What
> > >    should be the schema?
> > > 
> > >    https://www.freeipa.org/page/V4/Certificate_profile_update_mec
> > > hani
> > > sm#IPA_master_entries
> > > 
> > > 2. How should we deal with customised versions of included
> > > profiles?
> > >    There is a big tradeoff here, of complexity + flexibility vs.
> > >    simplicitity + reverting customisations to included profiles
> > > (and
> > >    preventing them in future).
> > > 
> > >    https://www.freeipa.org/page/V4/Certificate_profile_update_mec
> > > hani
> > > sm#Dealing_with_modified_profiles
> 
> I'm in favor of not supporting customized versions. I'm not sure how
> common it is to customize these profiles among users. Unless it is
> very
> common, I wouldn't support them to avoid the additional complexity.
> The
> users always have the option to automate these customizations after
> every server upgrade, if they really require them.
> > > 
> > > Thanks,
> > > Fraser
> > > ___
> > > FreeIPA-devel mailing list -- freeipa-de...@lists.fedorahosted.or
> > > g
> > > To unsubscribe send an email to freeipa-devel-leave@lists.fedorah
> > > oste
> > > d.org
> > 
> > ___
> > FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-devel-leave@lists.fedorahos
> > ted.org
> 
> 
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [DESIGN] Certificate profile update mechanism

2017-07-10 Thread Simo Sorce via FreeIPA-devel 
Hi Fraser,
I think you put on a reasonable proposal, however If I had to design
this right now and had the freedom to change dogtag and the rest of
freeipa to cope I would do the following:

- Change the LDAP profile storage to have versioned subtrees for
"system" profiles, and have a "custom" subtree for user profiles.

- In the base tree have a version attribute that set what version
dogtag should use, if absent dogtag will assume its current hardcoded
default version. Profiles are never updated per se, a new version is
installed and the version is upped.

- On upgrade a modified profile is moved to the "custom" tree and the
original version of the profile is stored in the system tree. This is
assuming this does not cause older versions of dogtag to misbehave,
otherwise we keep the modified version and make sure not to raise the
version to use. We also find a way to notify the admin he should move
customized profiles in the correct new section and leave system
profiles alone.

- Potentially if a dogtag server does not understand a new version, it
keeps using an older version (perhaps we can have a "mandatory version
attribute" to cause older versions to return an error instead. (see
also previous case)

The reason for this is that having a complex check on ipa versions is
potentially fragile as well it adds yet another dimension to the things
an admin need to know about to figure out why its domain is not using
the "right" profiles.
And I think in some cases there is no "conflict" between version
profiles only new "optional" attributes you may want to add/support.

The other option is to tie the dogtag profiles version to the domain
level as well, and only ever use new ones when the whole domain level
is upped. This is conditional on newer versions of dogtag being able to
use older profile versions without modification in LDAP.

HTH,
Simo.


On Sat, 2017-07-08 at 15:24 +1000, Fraser Tweedale via FreeIPA-devel
wrote:
> Hi all,
> 
> I've published a draft design for the profile update mechanism.
> This feature is to ensure that we can safely update included
> profiles even when we use Dogtag profile components only available
> in new versions.
> 
> https://www.freeipa.org/page/V4/Certificate_profile_update_mechanism
> 
> Interested persons, please review the design.  In particular there
> are two main questions I would like to discuss:
> 
> 1. We need to store the IPA version in IPA master entries.  What
>    should be the schema?
> 
>    https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
> sm#IPA_master_entries
> 
> 2. How should we deal with customised versions of included profiles?
>    There is a big tradeoff here, of complexity + flexibility vs.
>    simplicitity + reverting customisations to included profiles (and
>    preventing them in future).
> 
>    https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
> sm#Dealing_with_modified_profiles
> 
> Thanks,
> Fraser
> ___
> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-leave@lists.fedorahoste
> d.org
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org