Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Petr Viktorin]

On 02/22/2013 09:19 PM, Rob Crittenden wrote:

Design to allow one to recover DNA ranges when deleting a replica or
just for normal range management.

http://freeipa.org/page/V3/Recover_DNA_Ranges

Supporting ticket https://fedorahosted.org/freeipa/ticket/3321

rob


I wonder if it would be possible to have more on-deck ranges. Could 
dnaNextRange be multi-valued, and when the low-water mark is hit the 
plugin would pick one of them?


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Martin Kosek]

On 02/25/2013 01:44 PM, Petr Viktorin wrote:
 On 02/22/2013 09:19 PM, Rob Crittenden wrote:
 Design to allow one to recover DNA ranges when deleting a replica or
 just for normal range management.

 http://freeipa.org/page/V3/Recover_DNA_Ranges

 Supporting ticket https://fedorahosted.org/freeipa/ticket/3321

 rob
 
 I wonder if it would be possible to have more on-deck ranges. Could
 dnaNextRange be multi-valued, and when the low-water mark is hit the plugin
 would pick one of them?
 

Not at the moment, this is a single valued attribute type:

attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran
 ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE
 -VALUE X-ORIGIN '389 Directory Server' )

But it is a good question for 389-ds guys, it would be a good extension to the
DNA plugin and would prevent us from not-loosing the range when there is no
master with empty dnaNextRange. But maybe there is a strong reason why this was
made single value...


As for the RFE, I have few comments/questions for Rob:

1) I would expand Setting the on-deck range section and add an information
what should we do when the remote master is not accessible (this would result
only in a warning probably).


2) We may want to make sure that the removed replica is readonly before we copy
the range (just to be sure that we do not miss some value due to race condition.


3) In Enhancing ipa-replica-manage:

What does ipa-replica-manage dnarange-set masterA.example.com 250-499 exactly
do? I though that it would just overwrite active range, but based on the next
ipa-replica-manage dnanextrange-show example, it moved the currently active
range of masterA.example.com to the on-deck range. Do we want to do that?


4) What does NOTE: We will need to be clear that this range has nothing to do
with Trust ranges. actually mean? AFAIU, IPA should have all local ranges
covered with a local idrange range(s).

If it does not have it covered, it could happen that for example a new trust
would overlap with this user-defined local range and we would have colliding
POSIX IDs...

IMO, dnarange-set and dnanextrange-set should at first check if the range is
covered with some local idrange and only then allowed setting the new range.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES 0024-0025] Improvements to idrange.py

[Tomas Babej]

On Fri 22 Feb 2013 04:34:55 PM CET, Martin Kosek wrote:

On 02/22/2013 03:01 PM, Tomas Babej wrote:

On 02/21/2013 02:22 PM, Martin Kosek wrote:

On 02/20/2013 03:19 PM, Tomas Babej wrote:

On Wed 20 Feb 2013 02:24:03 PM CET, Alexander Bokovoy wrote:

On Wed, 20 Feb 2013, Tomas Babej wrote:

On 12/21/2012 12:15 PM, Tomas Babej wrote:

Hi,

Sending updated and rebased versions of patches 0024 and 0025.

Tomas



Sending rebased version, these got quite rotten.

Thanks for updating them.


@@ -504,25 +515,37 @@ class idrange_mod(LDAPUpdate):
  'not be found. Please specify the SID
directly '
  'using dom-sid option.'))

-try:
-(old_dn, old_attrs) = ldap.get_entry(dn,
-['ipabaseid',
-'ipaidrangesize',
-'ipabaserid',
-'ipasecondarybaserid'])
-except errors.NotFound:
-self.obj.handle_not_found(*keys)
+if in_updated_attrs('ipanttrusteddomainsid'):
+if in_updated_attrs('ipasecondarybaserid'):
+raise errors.ValidationError(name='ID Range setup',
+error=_('Options dom_sid and secondary_rid_base
cannot '
+'be used together'))

Since we agreed to refer to options by their CLI name (--dom-sid and
--secondary-rid-base) in the other patch, it makes sense to use it
here too.



-if is_set('ipanttrusteddomainsid'):
-# Validate SID as the one of trusted domains
-
self.obj.validate_trusted_domain_sid(entry_attrs['ipanttrusteddomainsid'])

+if not in_updated_attrs('ipabaserid'):
+raise errors.ValidationError(name='ID Range setup',
+error=_('Options dom_sid and rid_base must '
+'be used together'))

Same here.


+# secondary base rid must be set if and only if base rid
is set
+if in_updated_attrs('ipasecondarybaserid') !=\
+in_updated_attrs('ipabaserid'):
+raise errors.ValidationError(name='ID Range setup',
+error=_('Options secondary_rid_base and rid_base
must '
+'be used together'))

Same here.


+dict(
+desc='Try to modify ID range %r so it has only primary
rid range set' % (testrange8),
+command=('idrange_mod', [testrange8],
+  dict(ipabaserid=testrange8_base_rid)),
+expected=errors.ValidationError(
+name='ID Range setup', error='Options
secondary_rid_base and rid_base must be used together'),
+),

And synchronize error message here too.


Thanks!

Sending the updated patch 0024.

Tomas


In patch 0024 your intention is OK, but the checking functions are not:

   is_set = lambda x: (x in entry_attrs) and (x is not None)
+in_updated_attrs = lambda x: any((x in attrs and x is not None)
+ for attrs in (entry_attrs, old_attrs))

They return True even when the attribute is None because they check if *x* is
None and not if *attrs[x]* is None. Example:

# ipa idrange-add --base-id=120 --range-size=20 --rid-base=1000
--secondary-rid-base=100 local_range

Added ID range local_range

Range name: local_range
First Posix ID of the range: 120
Number of IDs in the range: 20
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100
Range type: local domain range

This command should be NOOP, but is not:

# ipa idrange-mod local_range --dom-sid=
ipa: ERROR: invalid 'ID Range setup': Options dom-sid and secondary-rid-base
cannot be used together

Martin

Thanks for the catch, all checking functions fixed.

Sending the complete patchset, up to date.

Tomas


I think I am being a nitpicker now (sorry), but this condition also fails if
the old_attrs has a setting, but I am removing it in a current -mod command:

# ipa idrange-add --base-id=120 --range-size=20 --rid-base=1000
--secondary-rid-base=100 local_range

Added ID range local_range

   Range name: local_range
   First Posix ID of the range: 120
   Number of IDs in the range: 20
   First RID of the corresponding RID range: 1000
   First RID of the secondary RID range: 100
   Range type: local domain range
# ipa idrange-mod local_range --dom-sid S-1-2 --secondary-rid-base=
ipa: ERROR: invalid 'ID Range setup': Options dom-sid and secondary-rid-base
cannot be used together

Martin


Yep. Ok, the command should now handle this use case as well.

Tomas
From 61fcd3db8a14a17ed5854dfb4a9f11e2bb06784e Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 20 Feb 

Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Rob Crittenden]

Martin Kosek wrote:

On 02/25/2013 01:44 PM, Petr Viktorin wrote:

On 02/22/2013 09:19 PM, Rob Crittenden wrote:

Design to allow one to recover DNA ranges when deleting a replica or
just for normal range management.

http://freeipa.org/page/V3/Recover_DNA_Ranges

Supporting ticket https://fedorahosted.org/freeipa/ticket/3321

rob


I wonder if it would be possible to have more on-deck ranges. Could
dnaNextRange be multi-valued, and when the low-water mark is hit the plugin
would pick one of them?



Not at the moment, this is a single valued attribute type:

attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran
  ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE
  -VALUE X-ORIGIN '389 Directory Server' )

But it is a good question for 389-ds guys, it would be a good extension to the
DNA plugin and would prevent us from not-loosing the range when there is no
master with empty dnaNextRange. But maybe there is a strong reason why this was
made single value...


As for the RFE, I have few comments/questions for Rob:

1) I would expand Setting the on-deck range section and add an information
what should we do when the remote master is not accessible (this would result
only in a warning probably).


Ok. I'll try to clarify this.



2) We may want to make sure that the removed replica is readonly before we copy
the range (just to be sure that we do not miss some value due to race condition.


That is attempted now as part of CLEANALLRUV. I'll mention it in the 
design so we time this properly.




3) In Enhancing ipa-replica-manage:

What does ipa-replica-manage dnarange-set masterA.example.com 250-499 exactly
do? I though that it would just overwrite active range, but based on the next
ipa-replica-manage dnanextrange-show example, it moved the currently active
range of masterA.example.com to the on-deck range. Do we want to do that?


I'm guessing I wasn't very precise with my example, focusing more on 
usage than output. These are all independent of one another. I'll make 
it more of a sequence.





4) What does NOTE: We will need to be clear that this range has nothing to do
with Trust ranges. actually mean? AFAIU, IPA should have all local ranges
covered with a local idrange range(s).


IPA ranges is completely separate from DNA ranges. You can set/modify 
all the local ranges you want and it won't affect the UIDs getting assigned.



If it does not have it covered, it could happen that for example a new trust
would overlap with this user-defined local range and we would have colliding
POSIX IDs...


Hmm, that's a good point.


IMO, dnarange-set and dnanextrange-set should at first check if the range is
covered with some local idrange and only then allowed setting the new range.


I can do that as well, but again, the local ranges don't really affect 
the ids we hand out via DNA.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Martin Kosek]

On 02/25/2013 03:09 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
...
 4) What does NOTE: We will need to be clear that this range has nothing to 
 do
 with Trust ranges. actually mean? AFAIU, IPA should have all local ranges
 covered with a local idrange range(s).
 
 IPA ranges is completely separate from DNA ranges. You can set/modify all the
 local ranges you want and it won't affect the UIDs getting assigned.
 
 If it does not have it covered, it could happen that for example a new trust
 would overlap with this user-defined local range and we would have colliding
 POSIX IDs...
 
 Hmm, that's a good point.
 
 IMO, dnarange-set and dnanextrange-set should at first check if the range is
 covered with some local idrange and only then allowed setting the new range.
 
 I can do that as well, but again, the local ranges don't really affect the ids
 we hand out via DNA.
 
 rob

You are right, that DNA plugin is really not aware of the idranges we set in
IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with
trust ranges and I think we should respect that with ipa-replica-manage.

I wonder if there was not even a plan to increase cooperation between our
idranges and DNA plugin, maybe Sumit or Alexander knows more.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0116] Fix crash caused by invalid wildcard in update policy string

[Petr Spacek]

Hello,

Fix crash caused by invalid wildcard in update policy string.

https://fedorahosted.org/bind-dyndb-ldap/ticket/108

Question:
What we should do if update policy string contains an error?
Should we disable all updates?
Or let the old policy in place?
I vote for disallowing all updates.

--
Petr^2 Spacek
From 9265430d94cb4997188583b8e4c2befe7b28ba4b Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Mon, 25 Feb 2013 15:24:07 +0100
Subject: [PATCH] Fix crash caused by invalid wildcard in update policy
 string.

https://fedorahosted.org/bind-dyndb-ldap/ticket/108

Signed-off-by: Petr Spacek pspa...@redhat.com
---
 src/acl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/acl.c b/src/acl.c
index c62a8cb9e867b658b65ce05a07fc31377b2356c2..f95cf431b6363d82085e9cfec7e6c1d6ddd45d7a 100644
--- a/src/acl.c
+++ b/src/acl.c
@@ -420,6 +420,18 @@ acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone)
 		CHECK(get_fixed_name(stmt, name, fname));
 		CHECK(get_types(mctx, stmt, types, n));
 
+		if (match_type == DNS_SSUMATCHTYPE_WILDCARD 
+		!dns_name_iswildcard(dns_fixedname_name(fname))) {
+			char name[DNS_NAME_FORMATSIZE];
+			dns_name_format(dns_fixedname_name(fname), name,
+	DNS_NAME_FORMATSIZE);
+			dns_zone_log(zone, ISC_LOG_ERROR,
+ invalid update policy: 
+ name '%s' is expected to be a wildcard,
+ name);
+			CLEANUP_WITH(DNS_R_BADNAME);
+		}
+
 		result = dns_ssutable_addrule(table, grant,
 	  dns_fixedname_name(fident),
 	  match_type,
-- 
1.7.11.7

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0005 Add list of domains associated to our realm to cn=etc

[Jan Cholasta]

Hi,

On 12.2.2013 17:27, Ana Krivokapic wrote:

Add new LDAP container to store the list of domains associated with IPA
realm.
Add two new ipa commands (ipa realmdomains-show and ipa
realmdomains-mod) to allow manipulation of the list of realm domains.
Unit test file covering these new commands was added.

https://fedorahosted.org/freeipa/ticket/2945



I have just noticed a failure in the test for this:

Traceback (most recent call last):
  File /usr/lib/python2.7/site-packages/nose/loader.py, line 390, in 
loadTestsFromName

addr.filename, addr.module)
  File /usr/lib/python2.7/site-packages/nose/importer.py, line 39, in 
importFromPath

return self.importFromDir(dir_path, fqname)
  File /usr/lib/python2.7/site-packages/nose/importer.py, line 86, in 
importFromDir

mod = load_module(part_fqname, fh, filename, desc)
  File 
/home/jcholast/freeipa/tests/test_xmlrpc/test_realmdomains_plugin.py, 
line 35, in module
bad_domain = u'this-domain-does-not-exist-%s.com' % 
''.join(random.choice(string.lowercase) for x in range(10))
UnicodeDecodeError: 'utf8' codec can't decode byte 0xed in position 0: 
invalid continuation byte


This is happening because string.lowercase is locale-dependent, so it 
might contain bad values, such as '\xed'. Please use 
string.ascii_lowercase instead to prevent this.


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Rich Megginson]

On 02/25/2013 06:09 AM, Martin Kosek wrote:

On 02/25/2013 01:44 PM, Petr Viktorin wrote:

On 02/22/2013 09:19 PM, Rob Crittenden wrote:

Design to allow one to recover DNA ranges when deleting a replica or
just for normal range management.

http://freeipa.org/page/V3/Recover_DNA_Ranges

Supporting ticket https://fedorahosted.org/freeipa/ticket/3321

rob

I wonder if it would be possible to have more on-deck ranges. Could
dnaNextRange be multi-valued, and when the low-water mark is hit the plugin
would pick one of them?


Not at the moment, this is a single valued attribute type:

attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran
  ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE
  -VALUE X-ORIGIN '389 Directory Server' )

But it is a good question for 389-ds guys, it would be a good extension to the
DNA plugin and would prevent us from not-loosing the range when there is no
master with empty dnaNextRange. But maybe there is a strong reason why this was
made single value...


If you make it multi-valued, then you probably want to have some sort of 
ordering to the values . . .





As for the RFE, I have few comments/questions for Rob:

1) I would expand Setting the on-deck range section and add an information
what should we do when the remote master is not accessible (this would result
only in a warning probably).


2) We may want to make sure that the removed replica is readonly before we copy
the range (just to be sure that we do not miss some value due to race condition.


3) In Enhancing ipa-replica-manage:

What does ipa-replica-manage dnarange-set masterA.example.com 250-499 exactly
do? I though that it would just overwrite active range, but based on the next
ipa-replica-manage dnanextrange-show example, it moved the currently active
range of masterA.example.com to the on-deck range. Do we want to do that?


4) What does NOTE: We will need to be clear that this range has nothing to do
with Trust ranges. actually mean? AFAIU, IPA should have all local ranges
covered with a local idrange range(s).

If it does not have it covered, it could happen that for example a new trust
would overlap with this user-defined local range and we would have colliding
POSIX IDs...

IMO, dnarange-set and dnanextrange-set should at first check if the range is
covered with some local idrange and only then allowed setting the new range.

Martin


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0005 Add list of domains associated to our realm to cn=etc

[Ana Krivokapic]

On 02/25/2013 04:10 PM, Jan Cholasta wrote:
 Hi,

 On 12.2.2013 17:27, Ana Krivokapic wrote:
 Add new LDAP container to store the list of domains associated with IPA
 realm.
 Add two new ipa commands (ipa realmdomains-show and ipa
 realmdomains-mod) to allow manipulation of the list of realm domains.
 Unit test file covering these new commands was added.

 https://fedorahosted.org/freeipa/ticket/2945


 I have just noticed a failure in the test for this:

 Traceback (most recent call last):
   File /usr/lib/python2.7/site-packages/nose/loader.py, line 390, in
 loadTestsFromName
 addr.filename, addr.module)
   File /usr/lib/python2.7/site-packages/nose/importer.py, line 39,
 in importFromPath
 return self.importFromDir(dir_path, fqname)
   File /usr/lib/python2.7/site-packages/nose/importer.py, line 86,
 in importFromDir
 mod = load_module(part_fqname, fh, filename, desc)
   File
 /home/jcholast/freeipa/tests/test_xmlrpc/test_realmdomains_plugin.py, line
 35, in module
 bad_domain = u'this-domain-does-not-exist-%s.com' %
 ''.join(random.choice(string.lowercase) for x in range(10))
 UnicodeDecodeError: 'utf8' codec can't decode byte 0xed in position 0:
 invalid continuation byte

 This is happening because string.lowercase is locale-dependent, so it
 might contain bad values, such as '\xed'. Please use
 string.ascii_lowercase instead to prevent this.

 Honza


Thanks for the catch. I believe it is already fixed:
https://www.redhat.com/archives/freeipa-devel/2013-February/msg00347.html

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0005 Add list of domains associated to our realm to cn=etc

[Jan Cholasta]

On 25.2.2013 16:29, Ana Krivokapic wrote:

On 02/25/2013 04:10 PM, Jan Cholasta wrote:

Hi,

On 12.2.2013 17:27, Ana Krivokapic wrote:

Add new LDAP container to store the list of domains associated with IPA
realm.
Add two new ipa commands (ipa realmdomains-show and ipa
realmdomains-mod) to allow manipulation of the list of realm domains.
Unit test file covering these new commands was added.

https://fedorahosted.org/freeipa/ticket/2945



I have just noticed a failure in the test for this:

Traceback (most recent call last):
   File /usr/lib/python2.7/site-packages/nose/loader.py, line 390, in
loadTestsFromName
 addr.filename, addr.module)
   File /usr/lib/python2.7/site-packages/nose/importer.py, line 39,
in importFromPath
 return self.importFromDir(dir_path, fqname)
   File /usr/lib/python2.7/site-packages/nose/importer.py, line 86,
in importFromDir
 mod = load_module(part_fqname, fh, filename, desc)
   File
/home/jcholast/freeipa/tests/test_xmlrpc/test_realmdomains_plugin.py, line
35, in module
 bad_domain = u'this-domain-does-not-exist-%s.com' %
''.join(random.choice(string.lowercase) for x in range(10))
UnicodeDecodeError: 'utf8' codec can't decode byte 0xed in position 0:
invalid continuation byte

This is happening because string.lowercase is locale-dependent, so it
might contain bad values, such as '\xed'. Please use
string.ascii_lowercase instead to prevent this.

Honza



Thanks for the catch. I believe it is already fixed:
https://www.redhat.com/archives/freeipa-devel/2013-February/msg00347.html



Oh, OK :)

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 94-99 Read and use per-service PAC type

[Martin Kosek]

On 02/21/2013 04:24 PM, Sumit Bose wrote:
 Hi,
 
 this series of patches fix https://fedorahosted.org/freeipa/ticket/2960
 The related design page is
 http://freeipa.org/page/V3/Read_and_use_per_service_pac_type .
 
 It was agreed while discussing the design page that the currently
 hardcoded value for the NFS service will be dropped completely, hence
 the first patch reverts to patch which added the hardcoded value.
 
 The second patch adds the needed attribute to compensate the now missing
 hardcoded value.
 
 In the following three patches the PAC type is read and used
 accordingly. The last patch adds a unit test for a new function.
 
 bye,
 Sumit

I did only sanity testing to the C part of the RFE so far, but by reading it it
looks ok. It may be beneficial if Simo or Alexander checked if the ipa-kdb part
is OK.

I will comment on the Python parts:

1) Your update check testing if there is any NFS service with ipakrbauthzdata
looks like a good heuristics to prevent admin frustration. Though an ideal
solution would require
https://fedorahosted.org/freeipa/ticket/2961
to prevent multiple updates when admin purposefully removes this attribute. We
may want to reference the ticket in a comment in the update plugin...


2) The upgrade plugin may get into infinite loop if ldap.find_entries returns
truncated result. As you do not update entries directly but only return update
instructions when you have no truncated results, you will loop.

To simulate this, I just created 2 NFS principals and set size_limit=1 in your
find_entries call.


3) Ok, we set ipakrbauthzdata to NONE on upgrades. But what about new NFS
service principals added by service-add? Shouldn't we set ipakrbauthzdata for
new services too? As a default when no user ipakrhbauthzdata is set...
Otherwise admins could be surprised why their new NFS services do not work
while the others do.

Also, I think we should have this NFS culprit documented somewhere (i.e. why we
set ipakrbauthzdata to NONE by default). At least as a small section in the
online help for services plugin...

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Rob Crittenden]

Rich Megginson wrote:

On 02/25/2013 06:09 AM, Martin Kosek wrote:

On 02/25/2013 01:44 PM, Petr Viktorin wrote:

On 02/22/2013 09:19 PM, Rob Crittenden wrote:

Design to allow one to recover DNA ranges when deleting a replica or
just for normal range management.

http://freeipa.org/page/V3/Recover_DNA_Ranges

Supporting ticket https://fedorahosted.org/freeipa/ticket/3321

rob

I wonder if it would be possible to have more on-deck ranges. Could
dnaNextRange be multi-valued, and when the low-water mark is hit the
plugin
would pick one of them?


Not at the moment, this is a single valued attribute type:

attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC
'DNA ran
  ge of values to get from replica' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE
  -VALUE X-ORIGIN '389 Directory Server' )

But it is a good question for 389-ds guys, it would be a good
extension to the
DNA plugin and would prevent us from not-loosing the range when there
is no
master with empty dnaNextRange. But maybe there is a strong reason why
this was
made single value...


If you make it multi-valued, then you probably want to have some sort of
ordering to the values . . .


I don't know. We don't have a whole lot of control of ordering when DNA 
gets a range, so I think that holes in the range happen now, so I 
wouldn't have a problem with lack of control.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DESIGN: Recover DNA Ranges

[Rich Megginson]

On 02/25/2013 09:23 AM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/25/2013 06:09 AM, Martin Kosek wrote:

On 02/25/2013 01:44 PM, Petr Viktorin wrote:

On 02/22/2013 09:19 PM, Rob Crittenden wrote:

Design to allow one to recover DNA ranges when deleting a replica or
just for normal range management.

http://freeipa.org/page/V3/Recover_DNA_Ranges

Supporting ticket https://fedorahosted.org/freeipa/ticket/3321

rob

I wonder if it would be possible to have more on-deck ranges. Could
dnaNextRange be multi-valued, and when the low-water mark is hit the
plugin
would pick one of them?


Not at the moment, this is a single valued attribute type:

attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC
'DNA ran
  ge of values to get from replica' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE
  -VALUE X-ORIGIN '389 Directory Server' )

But it is a good question for 389-ds guys, it would be a good
extension to the
DNA plugin and would prevent us from not-loosing the range when there
is no
master with empty dnaNextRange. But maybe there is a strong reason why
this was
made single value...


If you make it multi-valued, then you probably want to have some sort of
ordering to the values . . .


I don't know. We don't have a whole lot of control of ordering when 
DNA gets a range, so I think that holes in the range happen now, so I 
wouldn't have a problem with lack of control.


Ok.  Please file an RFE ticket.  There are some code changes that we 
will need to make to DNA to make next range take multiple values.




rob



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 146-164 LDAP code refactoring (Part 4)

[Jan Cholasta]

On 20.2.2013 13:03, Petr Viktorin wrote:

On 02/19/2013 03:10 PM, Jan Cholasta wrote:

On 1.2.2013 15:38, Petr Viktorin wrote:

Alright, I renamed get_single to single_value().

I also rebased to current master.



Patch 152:

+def single_value(self, name, default=_missing):
+values = self.get(name, [default])
+if len(values) != 1:
+raise ValueError(
+'%s has %s values, one expected' % (name, len(values)))
+if values[0] is _missing:
+raise KeyError(name)
+return values[0]

I would prefer if you used __getitem__() instead of get() and re-raised
KeyError if default is _missing. Also, until we disallow non-lists, we
need to check if values actually is list. I.e., do something like this:

+def single_value(self, name, default=_missing):
+try:
+values = super(LDAPEntry,
self).__getitem__(self._get_attr_name(name))
+except KeyError:
+if default is _missing:
+raise
+return default
+if not isinstance(values, list):
+return values
+if len(values) != 1:
+raise ValueError(
+'%s has %s values, one expected' % (name, len(values)))
+return values[0]


Updated, thanks.

_get_attr_name is only added in your patch 99, so I used _attr_name here
and modified your patch.

I wrote some tests for single_value, and while I was at it I added tests
for a few other LDAPEntry methods as well. I've also split things up
into more testcases. Including as patch 0181.


Thanks. I think you should also add a tearDown method to test_LDAPEntry 
which disconnects self.conn if it is connected (the same thing test_ldap 
does).





Patch 159:

Like I said in my review of your patch 143, I think we should use DNs
instead of entries in delete_entry, so I think it would make sense to do
delete_entry(entry.dn) in this patch.


I think that for symmetry with add_entry and update_entry, delete_entry
should take entries too. If you already have the entry, having to type
the extra .dn is not very intuitive.
The proper thing to do would be a separate delete_by_dn(), but
delete_entry() taking either entries or DNs works fine IMO.


OK, makes sense.




Patch 160:

I think you should do this (replace % with ,):

+root_logger.debug(
+failed to find mapping tree entry for %s, self.suffix)



Fixed, thanks.

I've also rebased 174 and your patch 104 to current master.



Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] What about desktop policies?

[Loris Santamaria]

Hi all, 

some customers of ours are interested in managing desktop policies for
their linux workstations, really nothing fancy, corporate background and
proxy settings are the most common requests.

In the past I created Gnome desktop profiles using Sabayon, distributed
them using puppet and associated them to user accounts with a Sabayon
specific LDAP attribute, a process a bit convoluted, and no longer
possible since sabayon is no longer developed. Also it was really buggy,
and very gnome specific.

I was thinking in how integrate desktop policies in freeIPA in a general
manner and I wanted to share my ideas with you. Hopefully some of this
may be incorporated in IPA at some point in the future.

Properties of a policy:

  * is a collection of settings
  * can be associated with users or groups (desktop policy) or with
hosts or hostgroups (system policy)
  * is associated with a consumer, the client software that
interprets and applies the policy. This way one could define
policies for dconf, policies for kde, policies for WBEM.

Properties of a setting
  * is a key-value pair
  * must conform to a schema
  * may be mandatory

The schema:
  * indicates which attributes a policy may consist of
  * indicates which kind of value may take an attribute. Bool,
string, etc.
  * There may be more than one schema for a given consumer. For
example for dconf you may have an evolution schema, a
gnome-games schema, etc.
 
Sample policy creation process:
 1. The admin creates a new schema in IPA, with a command like ipa
schema-add --consumer=dconf gnomeSettingsSchema
 2. The admin adds some definition to the schema: ipa
schema-add-setting gnomeSettingsSchema
--name=/schemas/desktop/gnome/background/picture_filename
--type=string --description='File to use for the background
image.'
 3. He creates a new policy: ipa policy-add corporateBackground
--type=desktop --consumer=dconf
 4. He adds a setting to the policy: ipa policy-add-setting
corporateBackground
--name=/schemas/desktop/gnome/background/picture_filename
--value=file:///san/wp/wallpaper.jpg --mandatory. Ipa would
check that the key is defined in one of the dconf related
schemas and the value is acceptable for that key.
 5. He associates the policy with users: ipa-policy-add-user
corporateBackground --groups=ipausers

How should the policy be applied? On the workstation, on startup, an ipa
related utility should check if there are any policies related to the
workstation, if there are any it should call a helper capable of
applying a specific type of policy. Then on user logon another ipa
related utility should check if there are any policies associated with
the user and call the appropriate helper, if available.

For the policy created in the above example, on logon the ipa policy
utility would find that there is a policy of type dconf associated with
the user. It would check if there is a dconf policy helper installed and
if positive it would call the helper passing it the parameters defined
in the policy.

Hope this is useful at least as a starting point in defining desktop
policies in IPA.
-- 
Loris Santamaria   linux user #70506   xmpp:lo...@lgs.com.ve
Links Global Services, C.A.http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:1...@lgs.com.ve

If I'd asked my customers what they wanted, they'd have said
a faster horse - Henry Ford


smime.p7s
Description: S/MIME cryptographic signature
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 137-144 LDAP code refactoring (Part 3)

[Jan Cholasta]

On 19.2.2013 16:56, Petr Viktorin wrote:

On 02/19/2013 02:17 PM, Jan Cholasta wrote:

On 29.1.2013 10:21, Jan Cholasta wrote:

A patch from this patchset (part 3) causes some of the dns plugin tests
to fail (idnsallowdynupdate is missing in dnszone_add output).

Honza



Patch 143:

+assert isinstance(entry_or_dn, DN)
+if normalize is None or normalize:
+entry_or_dn = self.normalize_dn(entry_or_dn)
+entry_attrs = dict(entry_attrs)

Can you please return LDAPEntry here as well, i.e. replace
dict(entry_attrs) with self.make_entry(entry_or_dn, entry_attrs)?


Sure. I tried to keep the old behavior with old usage, but you're right,
using LDAPEntry here will be better.


+def delete_entry(self, entry, normalize=None):
+Delete entry.
+
+The `normalize` argument does nothing when called with a
LDAPEntry.
+
+The legacy variant is:
+delete_entry(dn, normalize=True)
+

I don't think this is right. We don't need to know any of the attributes
of an entry to delete it, just its DN. I think we should keep the DN
variant of delete_entry as the primary one.



Makes sense. I made them both primary.
I didn't bother documenting normalize since your patch will remove that.


Updated patch attached; I'll update my repo when I respond to your
comments on part 4.



ACK part 3.

Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel