Re: [Freeipa-users] Auto membership plugin
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
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
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
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
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
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
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
