Re: [Freeipa-devel] Releasing testing tools as standalone projects
On 3.11.2014 16:47, Rob Crittenden wrote: Petr Viktorin wrote: Hello! There's been some interest in releasing pieces of FreeIPA's testing infrastructure so it can be reused in other projects. I will soon take the pytest-beakerlib plugin (currently in my patch 0672), and making a stand-alone project out of it. Later I'll extract the common pieces of the integration testign framework, and release that independently. Do we want projects projects like these to be hosted on Fedorahosted? That would be the 100% open-source solution. Or do we want to put it under a freeipa organization on Github, since we're more likely to get external contributors there? Why do you think it would get more contributors from github? Because yet another account isn't required, or the contributor process is perhaps better understood (via pull requests)? IMHO yes. Even for me it is much easier to quickly do - git clone - edit source - git push - create pull request (*this is the same for every project hosted on Github*) instead of - git clone - edit source (re-do following again for every single project) - hunt submission how-to - join mailing list/create account in project's tracker - prepare patch in project's format-of-choice - send patch Or both? (Would we want to officially mirror the project to Github from FH?) I'd be in favor of fedorahosted because you get a tracker and wiki as well, and having the repo there would round things out. rob -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing testing tools as standalone projects
On 11/03/2014 04:47 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello! There's been some interest in releasing pieces of FreeIPA's testing infrastructure so it can be reused in other projects. I will soon take the pytest-beakerlib plugin (currently in my patch 0672), and making a stand-alone project out of it. Later I'll extract the common pieces of the integration testing framework, and release that independently. Do we want projects projects like these to be hosted on Fedorahosted? That would be the 100% open-source solution. Or do we want to put it under a freeipa organization on Github, since we're more likely to get external contributors there? Why do you think it would get more contributors from github? Because yet another account isn't required, or the contributor process is perhaps better understood (via pull requests)? Both. The community is larger (i.e. contributors are likely to already have an account on Github), and the contribution process is nowadays more familiar to most people. And I'm not talking about a proprietary process here: the pull request process is publish a Git repo, and nag people to merge from it. It's built into Git itself – see git-request-pull(1). Github makes this easy, and adds a Web UI and some inevitable (but optional) proprietary perks. But underneath it's still Git and e-mail if you care to use those. Or both? (Would we want to officially mirror the project to Github from FH?) I'd be in favor of fedorahosted because you get a tracker and wiki as well, and having the repo there would round things out. Yeah, the tracker is a reason for FH. Github does host git-backed wikis using an open-source backend, but it doesn't have an acceptable bug tracker. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] User life-cycle management as additional plugin
Hello, I wonder if user life-cycle extensions [1] can be in form of separate FreeIPA plugin for FreeIPA framework. Reasoning behind this is that different organizations will have different requirements (including no life-cycle management). I don't think that one-size-fits-all so from my point of view it makes sense to ease replacing our life-cycle management by some home-grown plugin. Is something like that possible? [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle management as additional plugin
Hi, Dne 4.11.2014 v 10:46 Petr Spacek napsal(a): Hello, I wonder if user life-cycle extensions [1] can be in form of separate FreeIPA plugin for FreeIPA framework. Reasoning behind this is that different organizations will have different requirements (including no life-cycle management). I don't think that one-size-fits-all so from my point of view it makes sense to ease replacing our life-cycle management by some home-grown plugin. Is something like that possible? I'm afraid the framework is not extensible enough for this in its current incarnation. There is no way (or just a very hacky one) to add new options to an existing command in the form of a plugin. [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing testing tools as standalone projects
On 11/04/2014 10:30 AM, Petr Viktorin wrote: On 11/03/2014 04:47 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello! There's been some interest in releasing pieces of FreeIPA's testing infrastructure so it can be reused in other projects. I will soon take the pytest-beakerlib plugin (currently in my patch 0672), and making a stand-alone project out of it. Later I'll extract the common pieces of the integration testing framework, and release that independently. Do we want projects projects like these to be hosted on Fedorahosted? That would be the 100% open-source solution. Or do we want to put it under a freeipa organization on Github, since we're more likely to get external contributors there? Why do you think it would get more contributors from github? Because yet another account isn't required, or the contributor process is perhaps better understood (via pull requests)? Both. The community is larger (i.e. contributors are likely to already have an account on Github), and the contribution process is nowadays more familiar to most people. +1, from my experience with the openstack community, and with redhat - see github.com/redhat-openstack, et. al. And I'm not talking about a proprietary process here: the pull request process is publish a Git repo, and nag people to merge from it. It's built into Git itself – see git-request-pull(1). Github makes this easy, and adds a Web UI and some inevitable (but optional) proprietary perks. But underneath it's still Git and e-mail if you care to use those. +1 Or both? (Would we want to officially mirror the project to Github from FH?) I'd be in favor of fedorahosted because you get a tracker and wiki as well, and having the repo there would round things out. Yeah, the tracker is a reason for FH. Github does host git-backed wikis using an open-source backend, but it doesn't have an acceptable bug tracker. What's wrong with the github issue tracker? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing testing tools as standalone projects
On 11/04/2014 11:50 AM, Rich Megginson wrote: On 11/04/2014 10:30 AM, Petr Viktorin wrote: On 11/03/2014 04:47 PM, Rob Crittenden wrote: [...] Or both? (Would we want to officially mirror the project to Github from FH?) I'd be in favor of fedorahosted because you get a tracker and wiki as well, and having the repo there would round things out. Yeah, the tracker is a reason for FH. Github does host git-backed wikis using an open-source backend, but it doesn't have an acceptable bug tracker. What's wrong with the github issue tracker? It's stored in a closed format and hosted on a proprietary service; if Github goes down or goes evil we lose the issues. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Releasing testing tools as standalone projects
On 11/04/2014 12:00 PM, Petr Viktorin wrote: On 11/04/2014 11:50 AM, Rich Megginson wrote: On 11/04/2014 10:30 AM, Petr Viktorin wrote: On 11/03/2014 04:47 PM, Rob Crittenden wrote: [...] Or both? (Would we want to officially mirror the project to Github from FH?) I'd be in favor of fedorahosted because you get a tracker and wiki as well, and having the repo there would round things out. Yeah, the tracker is a reason for FH. Github does host git-backed wikis using an open-source backend, but it doesn't have an acceptable bug tracker. What's wrong with the github issue tracker? It's stored in a closed format and hosted on a proprietary service; if Github goes down or goes evil we lose the issues. Ah, ok. That does tilt things in favor of using fedorahosted for trac. I believe we can configure fedorahosted trac to use a different git repo (github) than git.fedorahosted. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0155] Fix CI test
patch attached -- Martin Basti From c867877b0b8c23ae132491710f748028a07e6311 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Tue, 4 Nov 2014 12:29:32 +0100 Subject: [PATCH] Fix CI tests: install_adtrust IPA uses both named and named-pkcs11 service. If named is masked use named-pkcs11, instead of raising exception --- ipatests/test_integration/tasks.py | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py index 4ed4662a03e666505c2ca3a74132362a122be7e4..1458d7f93fa609ff844bfbe9307a25954116fc56 100644 --- a/ipatests/test_integration/tasks.py +++ b/ipatests/test_integration/tasks.py @@ -278,7 +278,15 @@ def install_adtrust(host): # Restart named because it lost connection to dirsrv # (Directory server restarts during the ipa-adtrust-install) -host.run_command(['systemctl', 'restart', 'named']) +# we use two services named and named-pkcs11, +# if named is masked restart named-pkcs11 +result = host.run_command(['systemctl', 'is-enabled', 'named'], + raiseonerr=False) +if result.stdout_text.startswith(masked): +host.run_command(['systemctl', 'restart', 'named-pkcs11']) +else: +host.run_command(['systemctl', 'restart', 'named']) + # Check that named is running and has loaded the information from LDAP dig_command = ['dig', 'SRV', '+short', '@localhost', -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0026 Stop dirsrv last in ipactl stop.
https://fedorahosted.org/freeipa/ticket/4632 -- David Kupka From 79a716af3a82e7cb419376c727fd655af070904e Mon Sep 17 00:00:00 2001 From: David Kupka dku...@redhat.com Date: Tue, 4 Nov 2014 03:22:59 -0500 Subject: [PATCH] Stop dirsrv last in ipactl stop. Other services may depend on directory server. https://fedorahosted.org/freeipa/ticket/4632 --- install/tools/ipactl | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/install/tools/ipactl b/install/tools/ipactl index 7a1e41b01a80eeea85c417399dcf4666f70d4b26..b1b0b6e26fa97cdc953c86eee22e160782b57379 100755 --- a/install/tools/ipactl +++ b/install/tools/ipactl @@ -291,12 +291,6 @@ def ipa_stop(options): finally: raise IpactlError() -try: -print Stopping Directory Service -dirsrv.stop(capture_output=False) -except: -raise IpactlError(Failed to stop Directory Service) - for svc in reversed(svc_list): svchandle = services.service(svc) try: @@ -305,6 +299,12 @@ def ipa_stop(options): except: emit_err(Failed to stop %s Service % svc) +try: +print Stopping Directory Service +dirsrv.stop(capture_output=False) +except: +raise IpactlError(Failed to stop Directory Service) + # remove file with list of started services try: os.unlink(paths.SVC_LIST_FILE) -- 2.1.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0033] Remove trivial path constants
On 11/03/2014 01:54 PM, Petr Spacek wrote: On 4.10.2014 01:58, Gabe Alford wrote: Thanks Petr. Updated patch attached. Petr^3, is it okay now? Oh my, this patch fell through the cracks during the release frenzy. Apologies! ACK, pushed to master: 7eca640ffa3e661140843d91dc4a846d3355a242 Petr^2 Spacek On Tue, Sep 30, 2014 at 10:59 AM, Petr Viktorin pvikt...@redhat.com wrote: On 09/30/2014 05:13 AM, Gabe Alford wrote: Updated patch to fix merge conflicts from recent changes. On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: Hello, Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know if I missed any. Thanks, Gabe -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type
On 10/15/2014 02:20 PM, Petr Vobornik wrote:
ticket: https://fedorahosted.org/freeipa/ticket/4221
updated version of patch 773 attached. Fixes issue in
interactive_prompt_callback.
Not related to this ticket:
- should we show interactive prompt for domain name when user specifies
--type=ipa-adtrust or ipa-adtrust-posix? Atm it will prompt for values
related to local range.
--
Petr Vobornik
From d4aab791db8349da45711d8c6dcba724b752a03b Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 13 Oct 2014 14:57:45 +0200
Subject: [PATCH] ranges: prohibit setting --rid-base with ipa-trust-ad-posix
type
We should not allow setting --rid-base for ranges of ipa-trust-ad-posix since we do not perform any RID - UID/GID mappings for these ranges (objects have UID/GID set in AD). Thus, setting RID base makes no sense.
Since ipaBaseRID is a MUST in ipaTrustedADDomainRange object class, value '0' is allowed and used internally for 'ipa-trust-ad-posix' range type.
No schema change is done.
https://fedorahosted.org/freeipa/ticket/4221
---
ipalib/plugins/idrange.py | 61 ---
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index 9e0481e94048c465f9a86112378a47390de0d494..6c3be6e69595127e346969e41703dc98e783282e 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -248,6 +248,12 @@ class idrange(LDAPObject):
if not options.get('all', False) or options.get('pkey_only', False):
entry_attrs.pop('objectclass', None)
+def handle_ipabaserid(self, entry_attrs, options):
+if any((options.get('pkey_only', False), options.get('raw', False))):
+return
+if entry_attrs['iparangetype'][0] == u'ipa-ad-trust-posix':
+entry_attrs.pop('ipabaserid', None)
+
def check_ids_in_modified_range(self, old_base, old_size, new_base,
new_size):
if new_base is None and new_size is None:
@@ -414,6 +420,7 @@ class idrange_add(LDAPCreate):
rid_base = kw.get('ipabaserid', None)
secondary_rid_base = kw.get('ipasecondarybaserid', None)
+range_type = kw.get('iparangetype', None)
def set_from_prompt(param):
value = self.prompt_param(self.params[param])
@@ -424,7 +431,7 @@ class idrange_add(LDAPCreate):
# This is a trusted range
# Prompt for RID base if domain SID / name was given
-if rid_base is None:
+if rid_base is None and range_type != u'ipa-ad-trust-posix':
set_from_prompt('ipabaserid')
else:
@@ -486,23 +493,33 @@ class idrange_add(LDAPCreate):
if not is_set('iparangetype'):
entry_attrs['iparangetype'] = u'ipa-ad-trust'
-if entry_attrs['iparangetype'] not in (u'ipa-ad-trust',
- u'ipa-ad-trust-posix'):
+if entry_attrs['iparangetype'] == u'ipa-ad-trust':
+if not is_set('ipabaserid'):
+raise errors.ValidationError(
+name='ID Range setup',
+error=_('Options dom-sid/dom-name and rid-base must '
+'be used together')
+)
+elif entry_attrs['iparangetype'] == u'ipa-ad-trust-posix':
+if is_set('ipabaserid') and entry_attrs['ipabaserid'] != 0:
+raise errors.ValidationError(
+name='ID Range setup',
+error=_('Option rid-base must not be used when IPA '
+'range type is ipa-ad-trust-posix')
+)
+else:
+entry_attrs['ipabaserid'] = 0
+else:
raise errors.ValidationError(name='ID Range setup',
error=_('IPA Range type must be one of ipa-ad-trust '
'or ipa-ad-trust-posix when SID of the trusted '
-'domain is specified.'))
+'domain is specified'))
if is_set('ipasecondarybaserid'):
raise errors.ValidationError(name='ID Range setup',
error=_('Options dom-sid/dom-name and secondary-rid-base '
'cannot be used together'))
-if not is_set('ipabaserid'):
-raise errors.ValidationError(name='ID Range setup',
-error=_('Options dom-sid/dom-name and rid-base must '
-'be used together'))
-
# Validate SID as the one of trusted domains
self.obj.validate_trusted_domain_sid(
entry_attrs['ipanttrusteddomainsid'])
@@ -557,6 +574,7 @@ class idrange_add(LDAPCreate):
def post_callback(self, ldap, dn,
Re: [Freeipa-devel] Releasing testing tools as standalone projects
On Mon, 03 Nov 2014 16:07:20 +0100 Petr Viktorin pvikt...@redhat.com wrote: Hello! There's been some interest in releasing pieces of FreeIPA's testing infrastructure so it can be reused in other projects. I will soon take the pytest-beakerlib plugin (currently in my patch 0672), and making a stand-alone project out of it. Later I'll extract the common pieces of the integration testign framework, and release that independently. Do we want projects projects like these to be hosted on Fedorahosted? That would be the 100% open-source solution. Or do we want to put it under a freeipa organization on Github, since we're more likely to get external contributors there? Or both? (Would we want to officially mirror the project to Github from FH?) I'm asking about the projects' home, the Git repo can of course be mirrored anywhere. The release and issues stuff on github is ridiculous, I have no opposition to mirror on github and get pull requests from there, but the home (ie where official tarballs are released) should be elsewhere also trac, although perhaps not so fancy looking is much better than github issue tracker imo. The only nice thing about github's issues is that you can answer via email, too bad it mangles addresses so that it is super easy to just send any reply in a black hole (done that on several occasions and was wondering why the reporter did not reply). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 782 webui: use domain name instead of domain SID in idrange adder dialog
It's more user friendly. Almost nobody remembers SIDs.
https://fedorahosted.org/freeipa/ticket/4661
depends on patch 777
--
Petr Vobornik
From a5c3b903dbfa3a11dd122de3f8a9e36d562b34c2 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 4 Nov 2014 13:38:12 +0100
Subject: [PATCH] webui: use domain name instead of domain SID in idrange adder
dialog
It's more user friendly. Almost nobody remembers SIDs.
https://fedorahosted.org/freeipa/ticket/4661
---
install/ui/src/freeipa/idrange.js | 16 +++-
ipatests/test_webui/task_range.py | 20 ++--
ipatests/test_webui/test_range.py | 4 ++--
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/install/ui/src/freeipa/idrange.js b/install/ui/src/freeipa/idrange.js
index 4e5dbfa00dcf80495d8a96f7fc961b9c6676691f..8af1598af335db2429512910d286bc3bada7b325 100644
--- a/install/ui/src/freeipa/idrange.js
+++ b/install/ui/src/freeipa/idrange.js
@@ -138,9 +138,7 @@ return {
title: '@mo-param:idrange:ipasecondarybaserid:label'
},
{
-name: 'ipanttrusteddomainsid',
-label: '@i18n:objects.idrange.ipanttrusteddomainsid',
-title: '@mo-param:idrange:ipanttrusteddomainsid:label',
+name: 'ipanttrusteddomainname',
enabled: false
}
],
@@ -153,14 +151,14 @@ return {
IPA.idrange_adder_policy = function(spec) {
/*
The logic for enabling/requiring ipabaserid, ipasecondarybaserid and
-ipanttrusteddomainsid is as follows:
+ipanttrusteddomainname is as follows:
1) for AD ranges (range type is ipa-ad-trust or ipa-ad-trust-posix):
- * ipanttrusteddomainsid is required
+ * ipanttrusteddomainname is required
* ipabaserid is required for ipa-ad-trust but disabled for
ipa-ad-trust-posix
* ipasecondarybaserid is disabled
2) for local ranges
- * ipanttrusteddomainsid is disabled
+ * ipanttrusteddomainname is disabled
A) if server has AD trust support:
* both ipabaserid and ipasecondarybaserid are required
B) if server does not have AD trust support:
@@ -207,7 +205,7 @@ IPA.idrange_adder_policy = function(spec) {
var type_f = that.container.fields.get_field('iparangetype');
var baserid_f = that.container.fields.get_field('ipabaserid');
var secondarybaserid_f = that.container.fields.get_field('ipasecondarybaserid');
-var trusteddomainsid_f = that.container.fields.get_field('ipanttrusteddomainsid');
+var trusteddomainname_f = that.container.fields.get_field('ipanttrusteddomainname');
var type_v = type_f.get_value()[0];
var baserid_v = baserid_f.get_value()[0] || '';
@@ -221,10 +219,10 @@ IPA.idrange_adder_policy = function(spec) {
} else {
disable(baserid_f);
}
-require(trusteddomainsid_f);
+require(trusteddomainname_f);
disable(secondarybaserid_f);
} else {
-disable(trusteddomainsid_f);
+disable(trusteddomainname_f);
if (IPA.trust_enabled) {
require(baserid_f);
diff --git a/ipatests/test_webui/task_range.py b/ipatests/test_webui/task_range.py
index d46d345f03a2b50730e3107ef6f7cda4465c..b71285d1e6056b11e3e74703a568be27973de3bc 100644
--- a/ipatests/test_webui/task_range.py
+++ b/ipatests/test_webui/task_range.py
@@ -59,13 +59,13 @@ class range_tasks(UI_driver):
self.max_id = max_id
self.max_rid = max_rid
-def get_sid(self):
+def get_domain(self):
result = self.execute_api_from_ui('trust_find', [], {})
trusts = result['result']['result']
-sid = None
+domain = None
if trusts:
-sid = trusts[0]['ipanttrusteddomainsid']
-return sid
+domain = trusts[0]['cn']
+return domain
def get_data(self, pkey, size=50, add_data=None):
@@ -81,7 +81,7 @@ class range_tasks(UI_driver):
}
return data
-def get_add_data(self, pkey, range_type='ipa-local', size=50, shift=100, sid=None):
+def get_add_data(self, pkey, range_type='ipa-local', size=50, shift=100, domain=None):
base_id = self.max_id + shift
self.max_id = base_id + size
@@ -98,19 +98,19 @@ class range_tasks(UI_driver):
('callback', self.check_range_type_mod, range_type)
]
-if not sid:
+if not domain:
base_rid = self.max_rid + shift
self.max_rid = base_rid + size
add.append(('textbox', 'ipasecondarybaserid', str(base_rid)))
-if sid:
-add.append(('textbox', 'ipanttrusteddomainsid', sid))
+if domain:
+add.append(('textbox', 'ipanttrusteddomainname', domain))
return add
def check_range_type_mod(self,
[Freeipa-devel] [PATCH] 783 webui: normalize idview tab labels
ID View tab labels are no longer redundant.
https://fedorahosted.org/freeipa/ticket/4650
--
Petr Vobornik
From 97d3d854c4d7bae84b12c277ffe071892fb99235 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 4 Nov 2014 15:49:34 +0100
Subject: [PATCH] webui: normalize idview tab labels
ID View tab labels are no longer redundant.
https://fedorahosted.org/freeipa/ticket/4650
---
install/ui/src/freeipa/idviews.js | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index cbc78ae7c62916b6334a8ef0cdf12a92485b0876..823936401653096a0a649282e3b18f573de09804 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -112,7 +112,7 @@ return {
nested_entity: 'idoverrideuser',
search_all_entries: true,
label: '@mo:idoverrideuser.label',
-tab_label: '@mo:idoverrideuser.label',
+tab_label: '@mo:user.label',
name: 'idoverrideuser',
columns: [
{
@@ -132,7 +132,7 @@ return {
nested_entity: 'idoverridegroup',
search_all_entries: true,
label: '@mo:idoverridegroup.label',
-tab_label: '@mo:idoverridegroup.label',
+tab_label: '@mo:group.label',
name: 'idoverridegroup',
columns: [
{
@@ -148,7 +148,7 @@ return {
$type: 'idview_appliedtohosts',
name: 'appliedtohosts',
attribute: 'appliedtohosts',
-tab_label: '@i18n:objects.idview.appliedtohosts',
+tab_label: '@mo:host.label',
facet_group: 'appliedto',
actions: [
'idview_apply',
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle management as additional plugin
On 11/04/2014 10:58 AM, Jan Cholasta wrote: Hi, Dne 4.11.2014 v 10:46 Petr Spacek napsal(a): Hello, I wonder if user life-cycle extensions [1] can be in form of separate FreeIPA plugin for FreeIPA framework. Reasoning behind this is that different organizations will have different requirements (including no life-cycle management). I don't think that one-size-fits-all so from my point of view it makes sense to ease replacing our life-cycle management by some home-grown plugin. Is something like that possible? I'm afraid the framework is not extensible enough for this in its current incarnation. There is no way (or just a very hacky one) to add new options to an existing command in the form of a plugin. [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management Honza Hi Petr, I like the idea of home-grown ULC. If it is not feasible with the current framework, customer would have the ability to define home made placeholder. I does not implement the workflow of commands but is a kind of flexibility. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0155] Fix CI test
On 11/04/2014 12:33 PM, Martin Basti wrote: patch attached Thanks! ACK, pushed to: master: e7edac30a10c0da40d7cfd625e19bd4237b9e1f6 ipa-4-1: 49a73e1d6b710d777d4cc3a3ac358491c3e0e85a -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS
On 04/11/14 16:08, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4670 Patch attached I forgot to mention, this is an ancient bug, IMO the fix should go to all branches. -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable
On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote:
On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote:
On 10/29/2014 10:37 AM, Martin Kosek wrote:
On 10/28/2014 09:59 PM, Nathaniel McCallum wrote:
On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote:
This patch gives the administrator variables to control the size of
the authentication and synchronization windows for OTP tokens.
https://fedorahosted.org/freeipa/ticket/4511
NOTE: There is one known issue with this patch which I don't know how to
solve. This patch changes the schema in install/share/60ipaconfig.ldif.
On an upgrade, all of the new attributeTypes appear correctly. However,
the modifications to the pre-existing objectClass do not show up on the
server. What am I doing wrong?
After modifying ipaGuiConfig manually, everything in this patch works
just fine.
This new version takes into account the new (proper) OIDs and attribute
names.
Thanks Nathaniel!
The above known issue still remains.
Petr3, any idea what could have gone wrong? ObjectClass MAY list extension
should work just fine, AFAIK.
You added a blank line to the LDIF file. This is an entry separator, so
the objectClasses after the blank line don't belong to cn=schema, so
they aren't considered in the update.
Without the blank line it works fine.
Thanks for the catch!
Here is a version without the blank line.
I forgot to remove the old steps defines. This patch performs this
cleanup.
From 6007faa6fc86de5087ab8028febe162557ea46be Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Thu, 23 Oct 2014 15:18:26 -0400
Subject: [PATCH] Make token window sizes configurable
This patch gives the administrator variables to control the size of
the authentication and synchronization windows for OTP tokens.
https://fedorahosted.org/freeipa/ticket/4511
---
API.txt | 6 +-
VERSION | 4 +-
daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.c | 195 +-
daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.h | 17 ++
daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 79 +++--
daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c | 7 +-
daemons/ipa-slapi-plugins/libotp/libotp.c | 133 +++
daemons/ipa-slapi-plugins/libotp/libotp.h | 30 ++--
install/share/60ipaconfig.ldif| 6 +-
install/ui/src/freeipa/serverconfig.js| 10 ++
install/ui/test/data/ipa_init.json| 3 +-
install/updates/40-otp.update | 6 +
ipalib/plugins/config.py | 31 +++-
ipalib/plugins/internal.py| 1 +
14 files changed, 333 insertions(+), 195 deletions(-)
diff --git a/API.txt b/API.txt
index 491d7a76fd1d2d50208d314d1600839ce295..4f204d0fa2e33dc4c9202645e111c25d2a545d70 100644
--- a/API.txt
+++ b/API.txt
@@ -514,7 +514,7 @@ args: 0,1,1
option: Str('version?', exclude='webui')
output: Output('result', None, None)
command: config_mod
-args: 0,25,3
+args: 0,29,3
option: Str('addattr*', cli_name='addattr', exclude='webui')
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('delattr*', cli_name='delattr', exclude='webui')
@@ -525,6 +525,8 @@ option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name='
option: Str('ipagroupobjectclasses', attribute=True, autofill=False, cli_name='groupobjectclasses', csv=True, multivalue=True, required=False)
option: IA5Str('ipagroupsearchfields', attribute=True, autofill=False, cli_name='groupsearch', multivalue=False, required=False)
option: IA5Str('ipahomesrootdir', attribute=True, autofill=False, cli_name='homedirectory', multivalue=False, required=False)
+option: Int('ipahotpauthwindow', attribute=True, autofill=False, cli_name='hotp_auth_window', maxvalue=1000, minvalue=1, multivalue=False, required=False)
+option: Int('ipahotpsyncwindow', attribute=True, autofill=False, cli_name='hotp_sync_window', maxvalue=1000, minvalue=1, multivalue=False, required=False)
option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD', u'nfs:NONE'))
option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', minvalue=1, multivalue=False, required=False)
option: Bool('ipamigrationenabled', attribute=True, autofill=False, cli_name='enable_migration', multivalue=False, required=False)
@@ -533,6 +535,8 @@ option: Int('ipasearchrecordslimit', attribute=True, autofill=False, cli_name='s
option: Int('ipasearchtimelimit', attribute=True, autofill=False, cli_name='searchtimelimit', minvalue=-1, multivalue=False, required=False)
option: Str('ipaselinuxusermapdefault', attribute=True, autofill=False,
Re: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update)
On 30/10/14 14:47, thierry bordaz wrote: https://fedorahosted.org/freeipa/ticket/4635 I can't reproduce the deadlock, so ACK -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 353 Added initial vault implementation.
On 11/04/2014 07:27 AM, Endi Sukma Dewata wrote: On 10/28/2014 5:34 PM, Endi Sukma Dewata wrote: The NSSConnection class has to be modified not to shutdown existing database because some of the vault clients (e.g. vault-archive and vault-retrieve) also use a database to encrypt/decrypt the secret. The problem is described in more detail in this ticket: https://fedorahosted.org/freeipa/ticket/4638 The changes to the NSSConnection in the first patch caused the installation to fail. Attached is a new patch that uses the solution proposed by jdennis. New patch attached. It's now using the correct OID's for the schema. It also has been rebased on top of #352-1 and #354. New patch attached to fix the ticket URL. It depends on #352-2 and #354-1. New patch attached to fix vault/container ID problems and for some cleanups. The new schema can go to 60basev3.ldif, no need for a new file. ipalib/plugins/user.py: Make the try: block as small as possible; maybe something like this: try: vaultcontainer_id = ... except errors.NotFound: pass else: (vaultcontainer_name, vaultcontainer_parent_id) = ... self.api.Command.vaultcontainer_del(...) ipapython/dn.py: This change is not needed. If you have a sequence of RNDs you can do `DN(*seq)`. ipalib/plugins/vault.py: Do not use star imports in new code; remove the line from ipalib.plugins.baseldap import * and use e.g. `baseldap.LDAPObject` instead of just `LDAPObject`. Hopefully the only star-imported used are the base classes? To make translators' jobs easier, split the help text in __doc__ into strings that can be translated individually. Replace every blank line by: ) + _( The pattern and pattern_errmsg for the 'cn' param don't match. Which one is right? Shouldn't a similar check be there for parent? vaultcontainer.get_dn: Why put '/' at the end of container_id, if the empty string is ignored later anyway? Nitpick: In vaultcontainer.get_dn, prefer the if statement over the if-else expressions; it's a bit longer but more readable. In vaultcontainer.get_id, what's the purpose of the len() check? Did you want dn.endswith() instead? I sugggest writing doctests for the id manipulation methods (get_id, get_private_id, ...) – it's not always obvious what exactly they do. According to the design doc, container IDs shouldn't end in '/'. If you did that I think the manipulation would be simpler, and it could be shared with the vault equivalents. vaultcontainer_add: You should use ldap backend directly. Calling Commands is costly, most of the call is spent doing validation of what here is already validated. You should add a function to recursively create vault container using just the ldap client, and call that here and in vault_add. You can delete a container with children; is that expected? vault_add should complain if it does not get exactly one of data/text/in. What's the difference between vault_add and vault_archive? I don't see vault_archive in the design. It seems '/' is equivalent to '-' as far as KRA is concerned; should we disallow '-' in container/vault names? You can specify an absolute id by starting it with a slash, but only in --parent and not in the name itself. I think this should be possible in the name too. You can't include slashes in the name, so you always need to specify the prefix with --parent. I don't think there's a technical reason for this limitation. There are no tests. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 353 Added initial vault implementation.
Thanks for the review. I have some questions below. I'll post a new
patch after the issues are addressed.
On 11/4/2014 11:36 AM, Petr Viktorin wrote:
The new schema can go to 60basev3.ldif, no need for a new file.
Fixed. Also removed nsContainer as suggested by Simo.
ipalib/plugins/user.py: Make the try: block as small as possible; maybe
something like this:
try:
vaultcontainer_id = ...
except errors.NotFound:
pass
else:
(vaultcontainer_name, vaultcontainer_parent_id) = ...
self.api.Command.vaultcontainer_del(...)
Actually the command that generates the NotFound exception is the last
command. The first two commands are preparing the parameters. I moved
them before the try-block.
ipapython/dn.py: This change is not needed. If you have a sequence of
RNDs you can do `DN(*seq)`.
This is actually needed to construct a parent DN from an existing DN:
parent_dn = DN(dn[1:])
Note that the parameter is an array of RDNs, not a sequence of RDNs. I
don't see an existing mechanism to get a parent DN from a DN. Without
this change it would generate an error:
ValueError: tuple or list must be 2-valued, not
[ipapython.dn.RDN('cn=admin'), ipapython.dn.RDN('cn=users'),
ipapython.dn.RDN('cn=vaults'), ipapython.dn.RDN('dc=idm'),
ipapython.dn.RDN('dc=lab'), ipapython.dn.RDN('dc=bos'),
ipapython.dn.RDN('dc=redhat'), ipapython.dn.RDN('dc=com')]
ipalib/plugins/vault.py:
Do not use star imports in new code; remove the line
from ipalib.plugins.baseldap import *
and use e.g. `baseldap.LDAPObject` instead of just `LDAPObject`.
Hopefully the only star-imported used are the base classes?
I found 20 star imports in the existing plugins :/
All existing plugins are actually using LDAPObject directly, not
baseldap.LDAPObject. Is there a concern doing that? I fixed the code to
do the same thing.
To make translators' jobs easier, split the help text in __doc__ into
strings that can be translated individually.
Replace every blank line by:
) + _(
Fixed.
The pattern and pattern_errmsg for the 'cn' param don't match. Which one
is right? Shouldn't a similar check be there for parent?
This is actually copied verbatim from user's uid. Could you give some
sample values that show the problem?
I think ideally there should be a similar check for parent, but I
haven't figured out the proper pattern yet. I think we can do this as a
later enhancement. Or maybe we should remove the validation for cn for now.
vaultcontainer.get_dn: Why put '/' at the end of container_id, if the
empty string is ignored later anyway?
I'm still considering some options for container ID:
a) use a slash at the end for all containers (e.g. /users/)
b) don't use a trailing slash, except for root container (/)
I think option (a) is more consistent, container ID always ends with
slash, although in cases like this it can be redundant. This is how the
code is currently written. We can make an exception for
vaultcontainer.get_dn() though.
Option (b) will require more careful coding in many places (e.g.
concatenations) because it needs to handle a special case for root
container.
Maybe a better way is to use an array of names internally and the slash
is only used during input/output. The problem is when calling another
command the array has to be converted into string and parsed back into
array, so it may even introduce more redundancies. I don't see a way to
pass an object parameter to a command. Any suggestion?
Nitpick: In vaultcontainer.get_dn, prefer the if statement over the
if-else expressions; it's a bit longer but more readable.
Fixed.
In vaultcontainer.get_id, what's the purpose of the len() check? Did you
want dn.endswith() instead?
Yes, but my assumption is the DN will always be within the namespace
because it's only used internally, and using len() will be faster than
endswith(). The error case will never happen, but I was just making sure
there won't be an infinite loop. Maybe instead of calling the method
recursively I should just use a loop? That will avoid repetitive
validations.
I sugggest writing doctests for the id manipulation methods (get_id,
get_private_id, ...) – it's not always obvious what exactly they do.
Do you mean sample code in docs? Is it still necessary if we have some
test code?
According to the design doc, container IDs shouldn't end in '/'. If you
did that I think the manipulation would be simpler, and it could be
shared with the vault equivalents.
Yeah, as mentioned above I'm still considering several options. The
design may need to be adjusted.
vaultcontainer_add: You should use ldap backend directly. Calling
Commands is costly, most of the call is spent doing validation of what
here is already validated. You should add a function to recursively
create vault container using just the ldap client, and call that here
and in vault_add.
Hmm.. I'm not sure if we should write a code that will
Re: [Freeipa-devel] [PATCH] 357 Added symmetric and asymmetric vaults.
Hi, Dne 4.11.2014 v 17:54 Endi Sukma Dewata napsal(a): Hi, In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute types to store salt and public key for vault. Are there existing attribute types that I can use instead? I see there's an ipaPublicKey, should I use that and maybe add ipaSalt/ipaEncSalt? Thanks. yes, please re-use existing attributes where possible. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
