Re: [Freeipa-devel] freeIPA wiki account
On Mon, 2011-04-25 at 19:16 -0400, Deon Lackey wrote: > Hi! > > > > Could someone set up a FreeIPA wiki account for me? I thought my > Fedora creds would work, but I was wrong. Done. 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] freeIPA wiki account
Hi! Could someone set up a FreeIPA wiki account for me? I thought my Fedora creds would work, but I was wrong. Thanks! Deon ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 26 Delete the sudoers entry when disabling the Schema Compat plugin
JR Aquino wrote: This patch addresses ticket: https://fedorahosted.org/freeipa/ticket/1160 The disabling of the Schema Compat plugin is failing because the code was not removing all of the entries from the Schema Compatibility Container. This is a 1 line patch. ack, pushed to master and ipa-2-0 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On 04/25/2011 01:32 PM, Simo Sorce wrote: > On Mon, 2011-04-25 at 12:12 -0400, Dmitri Pal wrote: >> This is a problem with the place where we store the configuration >> since >> it is not replicated. But I am concerned about moving it to some other >> place. >> Any ideas of what would be a "proper" solution to make the change >> affect >> all replicas? > In order to avoid changing all plugins I am thinking we might create a > cn=plugin subtree under the shared cn=etc tree. > > And have a new IPA plugin monitor it. > > This plugin will act on any change done to this tree and copy any change > to the non-shared cn=config tree in order to reconfigure plugins. > > This still leaves open the fact that someone may change directly what's > in cn=config instead of modifying the shared subtree. We can create an ACI that will prevent the modification operation to the managed entry plugin configuration for any user except the internal op. This will prevent direct modification. Of cause if user removes ACI all bets are off, but this operation is similar to removing any other ACI that grants some access or protects some crucial part of the tree. It prevents customer from erroneously shooting himself in the foot but would not prevent a suicide if one is so determined... > Not sure how to cope with that best. One way could be to immediately > reset back the values to what's in the shared tree, but this means > intercepting also changes to cn=config. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Mon, 2011-04-25 at 12:12 -0400, Dmitri Pal wrote: > This is a problem with the place where we store the configuration > since > it is not replicated. But I am concerned about moving it to some other > place. > Any ideas of what would be a "proper" solution to make the change > affect > all replicas? In order to avoid changing all plugins I am thinking we might create a cn=plugin subtree under the shared cn=etc tree. And have a new IPA plugin monitor it. This plugin will act on any change done to this tree and copy any change to the non-shared cn=config tree in order to reconfigure plugins. This still leaves open the fact that someone may change directly what's in cn=config instead of modifying the shared subtree. Not sure how to cope with that best. One way could be to immediately reset back the values to what's in the shared tree, but this means intercepting also changes to cn=config. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On 04/25/2011 12:00 PM, Simo Sorce wrote: > On Mon, 2011-04-25 at 14:59 +, JR Aquino wrote: >> On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: >> >>> On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: Hmmm Both Private Groups and the Hostgroup -> Netgroup Managed Entries create objects in the container: cn=Managed Entries,cn=plugins,cn=config Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, and one in the cn=config How will these be treated by replication and the multi masters? >>> Only the common objects in the public suffix are replicated. >>> I think at some point we discussed that we should use a filter in the >>> private config entry made so that we could enable/disable the plugin by >>> simply making the filter result true/false. >>> Thus not ever touch the entries in cn=config but simply >>> "enable"/"disable" the functionality by (not)adding the appropriate >>> attributes to objects so that filters would (not) match. >>> >>> Simo. >> This tool works by toggling the originfilter: objectclass=disabled in order >> to turn off the plugin. > But this is backwards, because originfilter is defined in the > configuration entry stored in cn=config > > Meaning as soon as you change it one server will behave differently from > the others until you go and change it on each and every server. > > Simo. > This is a problem with the place where we store the configuration since it is not replicated. But I am concerned about moving it to some other place. Any ideas of what would be a "proper" solution to make the change affect all replicas? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Mon, 2011-04-25 at 14:59 +, JR Aquino wrote: > On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: > > > On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: > >> Hmmm > >> Both Private Groups and the Hostgroup -> Netgroup Managed Entries > >> create objects in the container: > >> cn=Managed Entries,cn=plugins,cn=config > >> > >> Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, > >> and one in the cn=config > >> > >> How will these be treated by replication and the multi masters? > > > > Only the common objects in the public suffix are replicated. > > I think at some point we discussed that we should use a filter in the > > private config entry made so that we could enable/disable the plugin by > > simply making the filter result true/false. > > Thus not ever touch the entries in cn=config but simply > > "enable"/"disable" the functionality by (not)adding the appropriate > > attributes to objects so that filters would (not) match. > > > > Simo. > > This tool works by toggling the originfilter: objectclass=disabled in order > to turn off the plugin. But this is backwards, because originfilter is defined in the configuration entry stored in cn=config Meaning as soon as you change it one server will behave differently from the others until you go and change it on each and every server. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: > On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: >> Hmmm >> Both Private Groups and the Hostgroup -> Netgroup Managed Entries >> create objects in the container: >> cn=Managed Entries,cn=plugins,cn=config >> >> Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, >> and one in the cn=config >> >> How will these be treated by replication and the multi masters? > > Only the common objects in the public suffix are replicated. > I think at some point we discussed that we should use a filter in the > private config entry made so that we could enable/disable the plugin by > simply making the filter result true/false. > Thus not ever touch the entries in cn=config but simply > "enable"/"disable" the functionality by (not)adding the appropriate > attributes to objects so that filters would (not) match. > > Simo. This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 777 adjust output of user-find
On 04/25/2011 09:49 AM, Dmitri Pal wrote: On 04/22/2011 01:47 PM, Rob Crittenden wrote: Modify the default attributes shown in user-find to match the UI design. This change means the UI can stop using the --all option and have to retrieve significantly less information from the server. It also speeds up user-find as it doesn't have to calculate membership. This adds a new baseclass parameter, search_display_attributes, which can provide a separate list from default_attributes just for find commands. The UI will need to be changed to switch from using cn to using givenname and sn. Please log a ticket to track this. Already is one, 1136. Keeping the front and backend work together on one ticket for this makes sense. ticket 1136 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 777 adjust output of user-find
On 04/22/2011 01:47 PM, Rob Crittenden wrote: > Modify the default attributes shown in user-find to match the UI design. > > This change means the UI can stop using the --all option and have to > retrieve significantly less information from the server. It also > speeds up user-find as it doesn't have to calculate membership. > > This adds a new baseclass parameter, search_display_attributes, which > can provide a separate list from default_attributes just for find > commands. > > The UI will need to be changed to switch from using cn to using > givenname and sn. Please log a ticket to track this. > > ticket 1136 > > rob > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: > Hmmm > Both Private Groups and the Hostgroup -> Netgroup Managed Entries > create objects in the container: > cn=Managed Entries,cn=plugins,cn=config > > Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, > and one in the cn=config > > How will these be treated by replication and the multi masters? Only the common objects in the public suffix are replicated. I think at some point we discussed that we should use a filter in the private config entry made so that we could enable/disable the plugin by simply making the filter result true/false. Thus not ever touch the entries in cn=config but simply "enable"/"disable" the functionality by (not)adding the appropriate attributes to objects so that filters would (not) match. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
