These patches apply on top of the previous ipa_uuid related patches.
#1 handles automatic generation of the uuid when the uuid
attribute is the RDN (fixes #413).
#2 prevents cases of false positives when enforcing is set and we are
handling a simple modification of an object that falls into the
On 10/26/2010 04:47 PM, Simo Sorce wrote:
On Tue, 26 Oct 2010 16:26:13 -0400
Adam Youngayo...@redhat.com wrote:
I'll admit this would be useful, but it would be another process that
we don't have now, that I was trying to avoid. We all have git repos
on fedorapeople. The trick is to
On 10/26/2010 11:21 PM, Simo Sorce wrote:
So, I have been working on this ipa_uuid plugin as of late and one of
the last tasks was to let it modify the RDN if ipaUniqueID is part of
the DN of an entry we want to create.
Example:
dn: ipauniqueid=autogenerate,cn=hbac,dc=...
cn: foo rule
hbactype:
Adam Young wrote:
On 10/26/2010 11:21 PM, Simo Sorce wrote:
So, I have been working on this ipa_uuid plugin as of late and one of
the last tasks was to let it modify the RDN if ipaUniqueID is part of
the DN of an entry we want to create.
Example:
dn: ipauniqueid=autogenerate,cn=hbac,dc=...
cn:
Made a change based on a recommendation by Simo: proejct name now
leads, followed by user name.
Posted on the wiki here:
http://fedorahosted.org/freeipa/wiki/PatchFormat
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Simo Sorce wrote:
On Wed, 27 Oct 2010 09:35:17 -0400
Adam Youngayo...@redhat.com wrote:
I'm not up to speed on this code. Why do a find right after create?
I guess to pick up all attributes added automatically by DS, not sure
why it just is.
Simo.
Yes, that's exactly it. We have other
Field Errors
Uses the pattern field of the metat data to see if the input for a
given
field is valid. If not, displays a red box with the contents of
pattern_msg
To test this, I artificially modified the meta data for the Group
description
From
Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 27 Oct 2010 09:35:17 -0400
Adam Youngayo...@redhat.com wrote:
I'm not up to speed on this code. Why do a find right after create?
I guess to pick up all attributes added automatically by DS, not sure
why it just is.
Simo.
Yes, that's
By using the special salt type and generating a random salt we can
rename user's principal name without invalidating their password.
This works only if pre-authentication is required, but that's how we
configure our server anyway.
This patch does not disallow normal salts, but if used they will
On Wed, 27 Oct 2010 14:52:17 -0600
Rich Megginson rmegg...@redhat.com wrote:
Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 27 Oct 2010 09:35:17 -0400
Adam Youngayo...@redhat.com wrote:
I'm not up to speed on this code. Why do a find right after
create?
I guess to pick up all
Simo Sorce wrote:
This plugin intercepts a modrdn change so that when a user is renamed
the krbprincipalname is changhed accordingly.
The second patch activates the plugin.
Simo.
ack x2
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Simo Sorce wrote:
These are a few minor fixes and cleanups I split in multiple patches
for easier review.
1. makes sure we reset the generate flag at every loop, so that we do
not risk a false positive if multiple UUIDs are generated on an entry.
2. makes unlocks safer by tracking when we
Simo Sorce wrote:
When the ipaUuidEnforce option is set to TRUE only the Directory
Manager is allowed to set arbitrary values. Any attempt to set
values != the ipaUuidGenerate value by non DirMgr users will throw an
error.
This is useful to enforce UUIDs are always set by the server.
At this
Simo Sorce wrote:
These patches apply on top of the previous ipa_uuid related patches.
#1 handles automatic generation of the uuid when the uuid
attribute is the RDN (fixes #413).
#2 prevents cases of false positives when enforcing is set and we are
handling a simple modification of an object
14 matches
Mail list logo
