Re: [Freeipa-devel] [PATCH 13/13] Update Polish and Chinese translations
John Dennis wrote: This patch does not apply patch -p1 --dry-run /tmp/0013-Update-Polish-and-Chinese-translations.patch patching file install/po/pl.po Hunk #1 FAILED at 6. Hunk #2 FAILED at 104. Hunk #4 FAILED at 443. Hunk #5 FAILED at 675. Hunk #6 FAILED at 687. Hunk #7 FAILED at 802. Hunk #8 FAILED at 894. Hunk #9 FAILED at 935. Hunk #10 FAILED at 1250. Hunk #11 FAILED at 1306. Hunk #12 succeeded at 692 (offset -631 lines). Hunk #13 FAILED at 708. Hunk #14 FAILED at 967. Hunk #15 succeeded at 1477 (offset -172 lines). 12 out of 15 hunks FAILED -- saving rejects to file install/po/pl.po.rej patching file install/po/zh_CN.po ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] about DNs
Pavel Zůna wrote: Hi, I didn't want to quote the already over-quoted e-mail about DNs from Rich, so I'm starting a new thread. :) Anyway, if I understand correctly, we should stop using quoted strings in DNs and use escapes instead, so: This: cn=dc=example,dc=com,dc=example,dc=com Becomes this: cn=dc\=example\,dc\=com,dc=example,dc=com ldap2 was designed to produces DNs like this, but we still use the old LDAPv2 style in a lot of places, so we made it possible to disable DN normalization and stopped escaping characters in quoted attribute values. This introduced the recent problems with python-ldap functions blowing up in our faces, when a plugin author didn't check his DNs manually. With your approval, I would like to make sure we switch to the new LDAPv3 style DNs everywhere, because: 1) it's going to prevent future problems if strict DN syntax checking is turned on (Rich was talking about this) 2) we'll be able to use ldap2 methods to build DNs everywhere, preventing python-ldap calls from blowing up 3) we'll be able to remove the ability to disable DN normalization as it won't be needed anymore, thus simplifying our LDAP API When this is done, we should encourage plugin authors to use our framework to build DNs instead of doing it manually, because it's fail-safe and will work even if the location where the entries are stored changes. Example: building DNs for CoS entries of password policies: group = 'some_group_name' container_cos = 'cn=cosTemplates,%s' % api.env.container_accounts group_dn = api.Object.group.get_dn(group) cos_dn = ldap2.make_dn_from_attr( 'cn', group_dn, container_costemplates ) Yes go ahead, we need to do this to support the upcoming strict enforcement in 389-ds. Note that you may still need to retain the ability to skip the normalizer. The KDC ldap plugin is extremely picky about DN format. You'll know quickly enough if things are working by creating some group password policy and see if it is enforced. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 404 ensure priority is unique
Pavel Zůna wrote: Rob Crittenden wrote: Pavel Zuna wrote: Jason Gerard DeRose wrote: On Fri, 2010-03-12 at 18:01 -0500, Rob Crittenden wrote: Ensure that the group policy priority is unique. We use CoS to determine the order in which group policy is applied. The behavior in CoS is undefined for multiple entries with the same cospriority. This likely relies on some other outstanding pwpolicy patches. rob ack. pushed to master. The patch works, but I find the way it checks for priority uniqueness highly ineffective. It pulls out all policies and then retrieves their CoS entries one by one to do the checking. Instead it should just make a search for a CoS entry with the given priority. Pavel Well, we may need to store the group policy entries in a subtree then. All CoS policies are currently dumped into the same place making this impossible. Not necessarily. It's just a matter of tweaking the search filter. We can search only for CoS entries, that have the krbContainer object class and their krbPwdReference attribute contains a group DN. Oh right, duh. Yeah, it is even simpler than that as we don't need to look at group dns because only group policy is stored this way. New patch attached. rob freeipa-404-2-pwpolicy.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 13/13] Update Polish and Chinese translations
On 03/22/2010 09:26 AM, Rob Crittenden wrote: John Dennis wrote: This patch does not apply patch -p1 --dry-run /tmp/0013-Update-Polish-and-Chinese-translations.patch patching file install/po/pl.po Hunk #1 FAILED at 6. Hunk #2 FAILED at 104. Hunk #4 FAILED at 443. Hunk #5 FAILED at 675. Hunk #6 FAILED at 687. Hunk #7 FAILED at 802. Hunk #8 FAILED at 894. Hunk #9 FAILED at 935. Hunk #10 FAILED at 1250. Hunk #11 FAILED at 1306. Hunk #12 succeeded at 692 (offset -631 lines). Hunk #13 FAILED at 708. Hunk #14 FAILED at 967. Hunk #15 succeeded at 1477 (offset -172 lines). 12 out of 15 hunks FAILED -- saving rejects to file install/po/pl.po.rej patching file install/po/zh_CN.po I don't think [PATCH 6/6] update Polish translations was pushed, that would cause the merge failure if that were the case. -- John Dennis jden...@redhat.com 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] Add INTERNAL flag to frontend plugins. If set, the plugin won't show up in UI.
Pavel Zuna wrote: We discussed this with Jason on IRC. There are cases when a defining an internal command plugin might come in handy. The plugin can be used by other plugin (for example to create helper objects in LDAP like Class of Service entries). Pavel ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Use ldap2.make_*dn* methods in pwpolicy plugin.
Pavel Zuna wrote: Fixes bug #572423 (Providing multiple group names in pwpolicy-show command throws internal serer error.) Pavel ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 6/6] update Polish translations
John Dennis wrote: pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 13/13] Update Polish and Chinese translations
John Dennis wrote: On 03/22/2010 09:26 AM, Rob Crittenden wrote: John Dennis wrote: This patch does not apply patch -p1 --dry-run /tmp/0013-Update-Polish-and-Chinese-translations.patch patching file install/po/pl.po Hunk #1 FAILED at 6. Hunk #2 FAILED at 104. Hunk #4 FAILED at 443. Hunk #5 FAILED at 675. Hunk #6 FAILED at 687. Hunk #7 FAILED at 802. Hunk #8 FAILED at 894. Hunk #9 FAILED at 935. Hunk #10 FAILED at 1250. Hunk #11 FAILED at 1306. Hunk #12 succeeded at 692 (offset -631 lines). Hunk #13 FAILED at 708. Hunk #14 FAILED at 967. Hunk #15 succeeded at 1477 (offset -172 lines). 12 out of 15 hunks FAILED -- saving rejects to file install/po/pl.po.rej patching file install/po/zh_CN.po I don't think [PATCH 6/6] update Polish translations was pushed, that would cause the merge failure if that were the case. Yes, I missed that one. Pushed now. This one pushed too rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
