Re: [Freeipa-devel] [PATCH] #333 plugin to change kerberos principal name when user is renamed
On Mon, 25 Oct 2010 20:27:04 -0400 Nalin Dahyabhai na...@redhat.com wrote: On Mon, Oct 25, 2010 at 06:59:18PM -0400, Simo Sorce wrote: I was meaning to ask you if we have any other way around. Is it possible to use a random salt instead of the principal name ? We do enforce pre-authentication by default, so IIRC it should be possible, but it doesn't seem to make any difference atm, I guess we need to change something in the password plugin ? If the salt stored in the user's key is marked as special instead of normal, the KDC should just send the recorded salt to the client. It looks like encrypt_encode_key() needs to generate and store a random salt when it sees that salt type in the configuration, and we need to start configuring IPA to use that. I'll open a bug with this comment in it. 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] whoami goodby
On Mon, 25 Oct 2010 20:38:04 -0400 Adam Young ayo...@redhat.com wrote: removal of the whoami plugin ACK -- 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] 585 entitlement plugin
On Mon, 25 Oct 2010 14:26:47 -0400 Rob Crittenden rcrit...@redhat.com wrote: Add entitlement plugin for counting client entitlements. This just adds the capability to tie to a candlepin server or manually import entitlement certificates. The code to use these to count clients is still under development. rob This plugin seem to depend on python libraries that are not available in Fedora nor any other distribution. ECANTTEST NACK until that is fixed. 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] [Fwd: [freeipa] #402: SUDO command attribute should be case sensitive]
Dmitri Pal wrote: Dmitri Pal wrote: Simo Sorce wrote: On Wed, 20 Oct 2010 15:42:17 -0400 Dmitri Pald...@redhat.com wrote: Any suggestions what it should be? Should we create a new attribute or there is something handy to reuse? Probably makes sense to add a custom attribute, properly named. Ok I will propose one. The attached patch should address the issue. I did the change but I have not done the build so view this patch as a proposal. ACK and pushed to master. I had to hand-apply this because it didn't apply cleanly. Please send all patches with [PATCH] in the subject so they don't get lost in the shuffle. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 588 Removing HBAC service nesting
Remove group nesting from the HBAC service groups. ticket https://fedorahosted.org/freeipa/ticket/389 rob rcrit-freeipa-588-hbac.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed standard for Patches: RFC
On Tue, 26 Oct 2010 13:40:11 -0400 Adam Young ayo...@redhat.com wrote: We've been doing this informally for a while, and I think, if we all agree to the format, it will help keep track of patches, ACKs, and commits. 1. Patch naming Example patch name: edewata-freeipa-0019-Certificate-management-for-services.patch Format: username-project-seq[-update]-description.extension username: Your Fedora account name. project name: always 'freeeipa' Are these really necessary ? We have the name of the author in the patch anyway, and freeipa (with 2 'e's not 3 :-P) seem really redundant. Bottomline I am lazy and would prefer not to have to rename patches after git format-patch creates them. So I'd like to understand the rationale for this format. After all we always send patches as attachments to emails, where we can explain what is going on. seq: sequnece number. please try to not skip numbers, as we will use this number to ensure all patches from a given contributor get reviewed. update. If a patch requires modifications and additional prior to submisiion, append a number starting at 2 and increasing by one for each update. Thus, if the above patch required additional changes, the first would be: edewata-freeipa-0019-2-Certificate-management-for-services.patch and then edewata-freeipa-0019-3-Certificate-management-for-services.patch description: This is the first line of the git commit, and should be less than six words long (idealy two or three). git format patch will translate this line into the subject of the patch, with hyphens replacing the whitespace. extension: always .patch 2. Patch format: All patches should be in format to apply with 'git am'. This is produced from a git repository using the command 'git format-patch' If a patch addresses a ticket in Trac, the second line of the commit should be the URL to track with the Ticket number. For example: https://fedorahosted.org/freeipa/ticket/339 This part is worth, but I think we should require only the bug number and have the full URL as a nice optional. 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] 588 Removing HBAC service nesting
On 10/26/2010 01:59 PM, Rob Crittenden wrote: Remove group nesting from the HBAC service groups. ticket https://fedorahosted.org/freeipa/ticket/389 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 590 error out when missing headers
Error out of configure when it finds some missing headers. rob rcrit-freeipa-590-configure.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed standard for Patches: RFC
On Tue, 26 Oct 2010 14:22:01 -0400 Adam Young ayo...@redhat.com wrote: On 10/26/2010 02:08 PM, Simo Sorce wrote: On Tue, 26 Oct 2010 13:40:11 -0400 Adam Youngayo...@redhat.com wrote: We've been doing this informally for a while, and I think, if we all agree to the format, it will help keep track of patches, ACKs, and commits. 1. Patch naming Example patch name: edewata-freeipa-0019-Certificate-management-for-services.patch Format: username-project-seq[-update]-description.extension username: Your Fedora account name. project name: always 'freeeipa' Are these really necessary ? We have the name of the author in the patch anyway, and freeipa (with 2 'e's not 3 :-P) seem really redundant. Otherwise, we get into a conflict over who''s patch 519 it is, and we have no way to order it. We've had enough issues where patch 11 requires patch 10 that it is just cleaner to try to apply all patches from a given developer in order. If the problem is tracking which patches have been applied an which are needed wouldn't it be easier instead if each developer published an official tree with the patches he proposes for inclusion ? That way all you need to do is a git log origin/master..dev_tree and you have all pending patches and the order they are applied to. Looks to me *much* handier then trying to order them based on file names and arbitrary sequence numbers. If a patch addresses a ticket in Trac, the second line of the commit should be the URL to track with the Ticket number. For example: https://fedorahosted.org/freeipa/ticket/339 This part is worth, but I think we should require only the bug number and have the full URL as a nice optional. I just copy and paste from the browser. It does make it clear whether we are talking about Trac or Bugzilla. bugzilla numbers flies around the 600k mark, looks pretty easy to tell which is which unless we have a sudden, dramatic spike in tickets filed against the trac instance :) 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] 590 error out when missing headers
Simo Sorce wrote: On Tue, 26 Oct 2010 15:16:04 -0400 Rob Crittendenrcrit...@redhat.com wrote: Error out of configure when it finds some missing headers. rob ACK pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] admiyo-freeipa-0068-association-header.patch
On 10/25/2010 8:39 PM, Adam Young wrote: https://fedorahosted.org/freeipa/ticket/338 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACKed and pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed standard for Patches: RFC
On 10/26/2010 03:29 PM, Simo Sorce wrote: On Tue, 26 Oct 2010 14:22:01 -0400 Adam Youngayo...@redhat.com wrote: On 10/26/2010 02:08 PM, Simo Sorce wrote: On Tue, 26 Oct 2010 13:40:11 -0400 Adam Youngayo...@redhat.com wrote: We've been doing this informally for a while, and I think, if we all agree to the format, it will help keep track of patches, ACKs, and commits. 1. Patch naming Example patch name: edewata-freeipa-0019-Certificate-management-for-services.patch Format: username-project-seq[-update]-description.extension username: Your Fedora account name. project name: always 'freeeipa' Are these really necessary ? We have the name of the author in the patch anyway, and freeipa (with 2 'e's not 3 :-P) seem really redundant. Otherwise, we get into a conflict over who''s patch 519 it is, and we have no way to order it. We've had enough issues where patch 11 requires patch 10 that it is just cleaner to try to apply all patches from a given developer in order. If the problem is tracking which patches have been applied an which are needed wouldn't it be easier instead if each developer published an official tree with the patches he proposes for inclusion ? That way all you need to do is a git log origin/master..dev_tree and you have all pending patches and the order they are applied to. Looks to me *much* handier then trying to order them based on file names and arbitrary sequence numbers. 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 deal with patches that have to get changed prior to commit, hence the numbering of -2 -3 after the seq number. Really, the seq number is not needed, but makes a nice ready shorthand for the patch. Pavel, Endi and I often refer to patches by number, like your patch 0019 which makes it handy. The increasing seq approach to detect a missing packet works in TCP, so why not for us? If a patch addresses a ticket in Trac, the second line of the commit should be the URL to track with the Ticket number. For example: https://fedorahosted.org/freeipa/ticket/339 This part is worth, but I think we should require only the bug number and have the full URL as a nice optional. I just copy and paste from the browser. It does make it clear whether we are talking about Trac or Bugzilla. bugzilla numbers flies around the 600k mark, looks pretty easy to tell which is which unless we have a sudden, dramatic spike in tickets filed against the trac instance :) Yeah, but the full URL approach is self documenting. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed standard for Patches: RFC
On Tue, 26 Oct 2010 16:26:13 -0400 Adam Young ayo...@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 deal with patches that have to get changed prior to commit, hence the numbering of -2 -3 after the seq number. Not sure what's the problem here, if I rebase a patch you have the latest one in my tree, no need to look for -1 -2 -3 as you can't be wrong if you re-fetch from my tree. Really, the seq number is not needed, but makes a nice ready shorthand for the patch. Pavel, Endi and I often refer to patches by number, like your patch 0019 which makes it handy. The increasing seq approach to detect a missing packet works in TCP, so why not for us? Because I am not a machine :) I see we constantly fail at correctly numbering sequentially stuff, from new error numbers to OIDs and other stuff, so I do not see this as a big improvement. I am not saying people shouldn't use this method if so they prefer, but mandating it seems a bit too much. Of course if others strongly feel this is the way to go, I will (try to) comply. 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] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add
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: allow ... 'autogenerate' is the magic value that makes the ipa_uuid plugin generate a uuid and set it on the entry. The problem is that LDAPCreate, after adding the entry will try to search it back immediately using the DN we passed in. This search will fail as the DN that is stored in LDAP is different (it has the generated uuid instead of 'autogenerate'). So ideas on how to gracefully handle this are welcome. I discussed of 2 with Rob on IRC but we'd like more inputs (Pavel, that would be directed at you :-). 1. Ignore the error in calls that pass in a DN containing ipauniqueid as the RDN and perform a new search. 2. modify LDAPCreate so that we can pass in a filter. If the caller passes in a filter we use that instead of the DN to search the entry back. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
