Re: [Freeipa-users] Auto membership plugin

2011-04-11 Thread Nathan Kinder

On 04/08/2011 09:07 AM, Dmitri Pal wrote:

On 04/08/2011 11:49 AM, JR Aquino wrote:

Is there any way to capture a description associated with the regex -  group 
mapping?

I was thinking that after time, it would be important to look back on rules and 
know why they were put there.

Particularly in the case of regex, since it may not be completely obvious by 
looking back at alphabet soup.

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



The more I think about current design the more I want to normalize things.
I would rather instead of:

dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinition
autoMemberScope: dc=example,dc=com
autoMemberFilter: objectclass=ipaHost
autoMemberExclusiveRegex: 
cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com
autoMemberInclusiveRegex: 
cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com
autoMemberInclusiveRegex: 
cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com
autoMemberInclusiveRegex: 
cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com
autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
autoMemberGroupingAttr: member:dn


Have something like:

dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinition
objectclass: cnContainer
autoMemberScope: dc=example,dc=com
autoMemberFilter: objectclass=ipaHost
autoMemberRegexRule: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto 
Membership Plugin,cn=plugins,cn=config
autoMemberRegexRule: cn=Mailserver Inclusion Rule,cn=Hostgroups,cn=Auto 
Membership Plugin,cn=plugins,cn=config
autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto Membership 
Plugin,cn=plugins,cn=config
autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
autoMemberGroupingAttr: member:dn


dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership 
Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinitionRegexRule
cn: Webserver Inclusion Rule
description: Rule contains regular expression to include webserver hosts into 
the webserver group.
include: yes- include or exclude
memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
arrtibuteToMath: fgdn
expressionToMatch: ^www[1-9]+\.example\.com


Or something along those lines...
It's a nice logical layout, but it would be hard for an administrator to 
figure out what exactly would happen if they were to add a host with a 
specific hostname.  Since the config is spread over so many entries, one 
would have to look at the top level config entry to find each rule DN, 
fetch each rule DN to look at the regexes.  All of the information is so 
spread out that you can't just look in one place to see the rules that 
will be used.  This could make things difficult from a troubleshooting 
perspective.


The description issue is a tough one to deal with if we have the config 
in the form that is currently described in the design doc.  Since we 
want a description per regex rule, we should need to make the 
description be a part of the regex rule value instead of a separate 
description attribute.  I don't necessarily like this approach, as the 
readability of the config will not be nice.


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


Re: [Freeipa-users] Auto membership plugin

2011-04-11 Thread Dmitri Pal
On 04/11/2011 11:27 AM, Nathan Kinder wrote:
 On 04/08/2011 09:07 AM, Dmitri Pal wrote:
 On 04/08/2011 11:49 AM, JR Aquino wrote:
 Is there any way to capture a description associated with the regex
 -  group mapping?

 I was thinking that after time, it would be important to look back
 on rules and know why they were put there.

 Particularly in the case of regex, since it may not be completely
 obvious by looking back at alphabet soup.

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


 The more I think about current design the more I want to normalize
 things.
 I would rather instead of:

 dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
 objectclass: autoMemberDefinition
 autoMemberScope: dc=example,dc=com
 autoMemberFilter: objectclass=ipaHost
 autoMemberExclusiveRegex:
 cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com
 autoMemberInclusiveRegex:
 cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com
 autoMemberInclusiveRegex:
 cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com
 autoMemberInclusiveRegex:
 cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com
 autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
 autoMemberGroupingAttr: member:dn


 Have something like:

 dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
 objectclass: autoMemberDefinition
 objectclass: cnContainer
 autoMemberScope: dc=example,dc=com
 autoMemberFilter: objectclass=ipaHost
 autoMemberRegexRule: cn=Webserver Inclusion
 Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
 autoMemberRegexRule: cn=Mailserver Inclusion
 Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
 autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto
 Membership Plugin,cn=plugins,cn=config
 autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
 autoMemberGroupingAttr: member:dn


 dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership
 Plugin,cn=plugins,cn=config
 objectclass: autoMemberDefinitionRegexRule
 cn: Webserver Inclusion Rule
 description: Rule contains regular expression to include webserver
 hosts into the webserver group.
 include: yes- include or exclude
 memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
 arrtibuteToMath: fgdn
 expressionToMatch: ^www[1-9]+\.example\.com


 Or something along those lines...
 It's a nice logical layout, but it would be hard for an administrator
 to figure out what exactly would happen if they were to add a host
 with a specific hostname.  Since the config is spread over so many
 entries, one would have to look at the top level config entry to find
 each rule DN, fetch each rule DN to look at the regexes.  All of the
 information is so spread out that you can't just look in one place to
 see the rules that will be used.  This could make things difficult
 from a troubleshooting perspective.

This should not be viewed in raw. THe UI and CLi should come to the rescue.
I am not sure that this is a right approach to mix readability and
normalization.
To follow this logic no-one would ever normalize data in any DB due to
the claim that it would be hard to join tables. 


 The description issue is a tough one to deal with if we have the
 config in the form that is currently described in the design doc. 
 Since we want a description per regex rule, we should need to make the
 description be a part of the regex rule value instead of a separate
 description attribute.  I don't necessarily like this approach, as the
 readability of the config will not be nice.


I think this tips the scale towards the approach I proposed.

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




-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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


Re: [Freeipa-users] Auto membership plugin

2011-04-08 Thread JR Aquino
Is there any way to capture a description associated with the regex - group 
mapping?

I was thinking that after time, it would be important to look back on rules and 
know why they were put there.

Particularly in the case of regex, since it may not be completely obvious by 
looking back at alphabet soup.

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


Re: [Freeipa-users] Auto membership plugin

2011-04-08 Thread Dmitri Pal
On 04/08/2011 11:49 AM, JR Aquino wrote:
 Is there any way to capture a description associated with the regex - group 
 mapping?

 I was thinking that after time, it would be important to look back on rules 
 and know why they were put there.

 Particularly in the case of regex, since it may not be completely obvious by 
 looking back at alphabet soup.

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


The more I think about current design the more I want to normalize things.
I would rather instead of:

dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinition
autoMemberScope: dc=example,dc=com
autoMemberFilter: objectclass=ipaHost
autoMemberExclusiveRegex: 
cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com
autoMemberInclusiveRegex: 
cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com
autoMemberInclusiveRegex: 
cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com
autoMemberInclusiveRegex: 
cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com
autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
autoMemberGroupingAttr: member:dn


Have something like:

dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinition
objectclass: cnContainer
autoMemberScope: dc=example,dc=com
autoMemberFilter: objectclass=ipaHost
autoMemberRegexRule: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto 
Membership Plugin,cn=plugins,cn=config
autoMemberRegexRule: cn=Mailserver Inclusion Rule,cn=Hostgroups,cn=Auto 
Membership Plugin,cn=plugins,cn=config
autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto Membership 
Plugin,cn=plugins,cn=config
autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
autoMemberGroupingAttr: member:dn


dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership 
Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinitionRegexRule
cn: Webserver Inclusion Rule
description: Rule contains regular expression to include webserver hosts into 
the webserver group.  
include: yes   - include or exclude
memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
arrtibuteToMath: fgdn
expressionToMatch: ^www[1-9]+\.example\.com


Or something along those lines...

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Rob Crittenden

Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?
2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped
3) Parsing pairs in the value as a bit of overhead. I wonder if there is
any way to avoid it?
4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?



Because the configuration is stored in cn=config we would need to bind 
as DM to be able to manage it (unless we want to make an exception and 
allow writing here. Could a bad config could prevent 389-ds from starting).


I assume a restart would be needed whenever a configuration change is made?

What happens if the target in automembertargetgroup gets removed?

rob

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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Nathan Kinder

On 03/30/2011 06:32 AM, Rob Crittenden wrote:

Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?
2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped
3) Parsing pairs in the value as a bit of overhead. I wonder if there is
any way to avoid it?
4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?



Because the configuration is stored in cn=config we would need to bind 
as DM to be able to manage it (unless we want to make an exception and 
allow writing here. Could a bad config could prevent 389-ds from 
starting).
No.  Similar to a bad DNA or managed entry setup, an error would be 
logged and the bad config entry would be skipped.


I assume a restart would be needed whenever a configuration change is 
made?
Only enabling the plug-in at the top level, which we could enabled by 
default.  The definition entry changes would be dynamic.


What happens if the target in automembertargetgroup gets removed?
I still need to fill in the Behavior section in the design doc, but 
this plug-in is not a referential integrity plug-in.  It simply monitors 
ADD operations and updates the membership accordingly.  Nothing is done 
for MOD, DEL, or MODRDN operations.


-NGK


rob


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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Rob Crittenden

Nathan Kinder wrote:

On 03/30/2011 06:32 AM, Rob Crittenden wrote:

Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?
2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped
3) Parsing pairs in the value as a bit of overhead. I wonder if there is
any way to avoid it?
4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?



Because the configuration is stored in cn=config we would need to bind
as DM to be able to manage it (unless we want to make an exception and
allow writing here. Could a bad config could prevent 389-ds from
starting).

No. Similar to a bad DNA or managed entry setup, an error would be
logged and the bad config entry would be skipped.


Ok, great. But we would still need to carve out an exception for allow 
people to write in cn=config, right?




I assume a restart would be needed whenever a configuration change is
made?

Only enabling the plug-in at the top level, which we could enabled by
default. The definition entry changes would be dynamic.


What happens if the target in automembertargetgroup gets removed?

I still need to fill in the Behavior section in the design doc, but
this plug-in is not a referential integrity plug-in. It simply monitors
ADD operations and updates the membership accordingly. Nothing is done
for MOD, DEL, or MODRDN operations.


I was thinking more what happens if the targetgroup is deleted and a new 
user is added? Will this result in a failed modify or would the user get 
a member pointer to a non-existent entry, or something else?


rob

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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Nathan Kinder

On 03/30/2011 06:00 AM, Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?

I'm not sure.  Is there a use case for it?

2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped
Where exactly are you thinking that they need to be escaped? Why do you 
think they might need to be escaped?

3) Parsing pairs in the value as a bit of overhead. I wonder if there is
any way to avoid it?
Do you mean parsing the pair contained in the autoMemberGroupingAttr 
attribute in the config definition entry?  This will only be parsed when 
the definition entry is loaded at startup or when it is modified.  It 
would be stored in a different form that is more efficient to use when 
we actually need to perform auto membership operations.


-NGK

4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?



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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Dmitri Pal
On 03/30/2011 10:43 AM, Nathan Kinder wrote:
 On 03/30/2011 07:34 AM, Rob Crittenden wrote:
 Nathan Kinder wrote:
 On 03/30/2011 06:32 AM, Rob Crittenden wrote:
 Dmitri Pal wrote:
 Hello,

 Please find the design for the auto membership plugin:
 https://fedorahosted.org/freeipa/ticket/753
 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

 I have some comments and questions:
 1) Is the AND functionality for inclusion criteria required?
 2) How the attributes are escaped? Do they need to? Probably there
 will
 be cases when they should be escaped
 3) Parsing pairs in the value as a bit of overhead. I wonder if
 there is
 any way to avoid it?
 4) I have concerns about the UI and CLI, do you see any good ways to
 mange such entries?


 Because the configuration is stored in cn=config we would need to bind
 as DM to be able to manage it (unless we want to make an exception and
 allow writing here. Could a bad config could prevent 389-ds from
 starting).
 No. Similar to a bad DNA or managed entry setup, an error would be
 logged and the bad config entry would be skipped.

 Ok, great. But we would still need to carve out an exception for
 allow people to write in cn=config, right?
 Yes, someone will need to write the config entry, so that will need to
 be allowed.

But can it be an ordinary user controlled by CLI or it is a DM?
Will  newly added rule be respected right away?

You probably want to have an enable/disable flag on the rule to give
some staging capability to the admin.




 I assume a restart would be needed whenever a configuration change is
 made?
 Only enabling the plug-in at the top level, which we could enabled by
 default. The definition entry changes would be dynamic.

 What happens if the target in automembertargetgroup gets removed?
 I still need to fill in the Behavior section in the design doc, but
 this plug-in is not a referential integrity plug-in. It simply monitors
 ADD operations and updates the membership accordingly. Nothing is done
 for MOD, DEL, or MODRDN operations.

 I was thinking more what happens if the targetgroup is deleted and a
 new user is added? Will this result in a failed modify or would the
 user get a member pointer to a non-existent entry, or something else?
 That's an interesting case.  It would result in a failed modify, as we
 would not be able to update the non-existent group entry.  This
 plug-in does not add a pointer to the user entry (that's done by the
 memberOf plug-in if it is desired).  The usre entry would still be
 consistent, but you would have an error in the errors log about the
 failed modify.

 rob

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



All the rest seems fine so far.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Nathan Kinder

On 03/30/2011 06:00 AM, Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design
I had a lengthy discussion with JR, and I have come up with an alternate 
approach.  I have added this approach to the design document.  I am 
currently leaning towards this new approach.  Please take a look at it.

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?
2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped
3) Parsing pairs in the value as a bit of overhead. I wonder if there is
any way to avoid it?
4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?



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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Dmitri Pal
On 03/30/2011 12:44 PM, Nathan Kinder wrote:
 On 03/30/2011 06:00 AM, Dmitri Pal wrote:
 Hello,

 Please find the design for the auto membership plugin:
 https://fedorahosted.org/freeipa/ticket/753
 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design
 I had a lengthy discussion with JR, and I have come up with an
 alternate approach.  I have added this approach to the design
 document.  I am currently leaning towards this new approach.  Please
 take a look at it.
 I have some comments and questions:
 1) Is the AND functionality for inclusion criteria required?
 2) How the attributes are escaped? Do they need to? Probably there will
 be cases when they should be escaped
 3) Parsing pairs in the value as a bit of overhead. I wonder if there is
 any way to avoid it?
 4) I have concerns about the UI and CLI, do you see any good ways to
 mange such entries?

Makes sense

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Nathan Kinder

On 03/30/2011 08:06 AM, Dmitri Pal wrote:

On 03/30/2011 10:43 AM, Nathan Kinder wrote:

On 03/30/2011 07:34 AM, Rob Crittenden wrote:

Nathan Kinder wrote:

On 03/30/2011 06:32 AM, Rob Crittenden wrote:

Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?
2) How the attributes are escaped? Do they need to? Probably there
will
be cases when they should be escaped
3) Parsing pairs in the value as a bit of overhead. I wonder if
there is
any way to avoid it?
4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?


Because the configuration is stored in cn=config we would need to bind
as DM to be able to manage it (unless we want to make an exception and
allow writing here. Could a bad config could prevent 389-ds from
starting).

No. Similar to a bad DNA or managed entry setup, an error would be
logged and the bad config entry would be skipped.

Ok, great. But we would still need to carve out an exception for
allow people to write in cn=config, right?

Yes, someone will need to write the config entry, so that will need to
be allowed.

But can it be an ordinary user controlled by CLI or it is a DM?

I believe this could be done by a normal (admin) user if the ACI allows it.

Will  newly added rule be respected right away?

Yes, changes to the definition entry would be respected right away.

You probably want to have an enable/disable flag on the rule to give
some staging capability to the admin.

Makes sense.



I assume a restart would be needed whenever a configuration change is
made?

Only enabling the plug-in at the top level, which we could enabled by
default. The definition entry changes would be dynamic.

What happens if the target in automembertargetgroup gets removed?

I still need to fill in the Behavior section in the design doc, but
this plug-in is not a referential integrity plug-in. It simply monitors
ADD operations and updates the membership accordingly. Nothing is done
for MOD, DEL, or MODRDN operations.

I was thinking more what happens if the targetgroup is deleted and a
new user is added? Will this result in a failed modify or would the
user get a member pointer to a non-existent entry, or something else?

That's an interesting case.  It would result in a failed modify, as we
would not be able to update the non-existent group entry.  This
plug-in does not add a pointer to the user entry (that's done by the
memberOf plug-in if it is desired).  The usre entry would still be
consistent, but you would have an error in the errors log about the
failed modify.

rob

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



All the rest seems fine so far.



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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Nathan Kinder

On 03/30/2011 08:03 AM, Dmitri Pal wrote:

On 03/30/2011 10:39 AM, Nathan Kinder wrote:

On 03/30/2011 06:00 AM, Dmitri Pal wrote:

Hello,

Please find the design for the auto membership plugin:
https://fedorahosted.org/freeipa/ticket/753
Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?

I'm not sure.  Is there a use case for it?

2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped

Where exactly are you thinking that they need to be escaped? Why do
you think they might need to be escaped?

Wild cards and regular expression might have special symbols like =
\ slashes etc.
If we decode to support AND it would probably be solved by concatenating
multiple attr=regex pairs in one attribute. I am concerned it will be a
challenge to parse.
We use libpcre elsewhere in 389 to allow regular expressions to be 
used.  We actually have a public regular expression API within SLAPI 
(the slapi_re_* functions).  We would leverage these functions in this 
plug-in.  The SASL mapping code already uses these for something 
similar, so there is not a new problem to solve here.

3) Parsing pairs in the value as a bit of overhead. I wonder if there is
any way to avoid it?

Do you mean parsing the pair contained in the autoMemberGroupingAttr
attribute in the config definition entry?  This will only be parsed
when the definition entry is loaded at startup or when it is
modified.  It would be stored in a different form that is more
efficient to use when we actually need to perform auto membership
operations.

Yes I am concerned about parsing pairs for the purposes of the modify
operation in CLI/UI.
This is only done when loading the config, so it's a one-time penalty at 
startup or when the config is modified (which should be fairly rare).  I 
wouldn't worry about this.

-NGK

4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?


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






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


Re: [Freeipa-users] Auto membership plugin

2011-03-30 Thread Dmitri Pal
On 03/30/2011 02:23 PM, Nathan Kinder wrote:
 On 03/30/2011 08:03 AM, Dmitri Pal wrote:
 On 03/30/2011 10:39 AM, Nathan Kinder wrote:
 On 03/30/2011 06:00 AM, Dmitri Pal wrote:
 Hello,

 Please find the design for the auto membership plugin:
 https://fedorahosted.org/freeipa/ticket/753
 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design

 I have some comments and questions:
 1) Is the AND functionality for inclusion criteria required?
 I'm not sure.  Is there a use case for it?
 2) How the attributes are escaped? Do they need to? Probably there
 will
 be cases when they should be escaped
 Where exactly are you thinking that they need to be escaped? Why do
 you think they might need to be escaped?
 Wild cards and regular expression might have special symbols like =
 \ slashes etc.
 If we decode to support AND it would probably be solved by concatenating
 multiple attr=regex pairs in one attribute. I am concerned it will be a
 challenge to parse.
 We use libpcre elsewhere in 389 to allow regular expressions to be
 used.  We actually have a public regular expression API within SLAPI
 (the slapi_re_* functions).  We would leverage these functions in this
 plug-in.  The SASL mapping code already uses these for something
 similar, so there is not a new problem to solve here.

I am not worried about you, I am worried that we will have to parse it
in the python code and may be Javascript in ­CLI.
Hope we can create an abstraction on the management plugin side that
will do the trick and hide it from actual UI and client part of CLI.
But anyways this means two different parsers - internal in the DS plugin
and external in the management plugin.


 3) Parsing pairs in the value as a bit of overhead. I wonder if
 there is
 any way to avoid it?
 Do you mean parsing the pair contained in the autoMemberGroupingAttr
 attribute in the config definition entry?  This will only be parsed
 when the definition entry is loaded at startup or when it is
 modified.  It would be stored in a different form that is more
 efficient to use when we actually need to perform auto membership
 operations.
 Yes I am concerned about parsing pairs for the purposes of the modify
 operation in CLI/UI.
 This is only done when loading the config, so it's a one-time penalty
 at startup or when the config is modified (which should be fairly
 rare).  I wouldn't worry about this.
 -NGK
 4) I have concerns about the UI and CLI, do you see any good ways to
 mange such entries?

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




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




-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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