389-devel July 2008

389-devel@lists.fedoraproject.org

4 participants
16 discussions

[Fedora-directory-devel] Please Review: (457329) Make better use of cached DNA config information
by Nathan Kinder 31 Jul '08

31 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=457329 Resolves: bug 457329 Bug Description: Portions of the DNA plug-in leverage the cached configuration information, while other portions do not. In particular, the actual configuration related todetermining the next value to assign always does an internal search on the configuration entry instead of using the in-memory information that it already has available. The DNA plug-in should never need to read from it's configuration entries aside from startup. If a modification is made to the configuration entries directly, we will detect that at the post-operation stage since we register a callback to check for configuration changes. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: See https://bugzilla.redhat.com/show_bug.cgi?id=457329#c1 Platforms tested: Fedora 8 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=313050&action=diff

1 0

[Fedora-directory-devel] Please Review: (457260) dnaFilter configuration attribute is not used properly
by Nathan Kinder 30 Jul '08

30 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=457260 Resolves: bug 457260 Bug Description: The dnaFilter configuration setting is supposed to be applied against an entry to determine if a particular managed range applies to the entry. I have found that it is not used properly. Here's what I have observed: - Configure two managed ranges. One is for the uidNumber for "objectclass=posixAccount" entries. The second is for the gidNumber for "objectclass=posixGroup" entries. - Add a new "posixAccount" entry without specifying a "uidNumber" or "gidNumber" attribute value. The user will be successfully added, and both "uidNumber" and "gidNumber" values will be generated for the new entry, even though the configuration states that only the "uidNumber" should be generated. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The problem is related to the way we load the dnaFilter value from the configuration entries. Our cached configuration entries in the DNA plug-in contain a string representation of the filter in addition to a Slapi_Filter based off of that string. The problem is that we call slapi_str2filter() to create the Slapi_Filter, but we store the pointer to it in our char * pointer that is supposed to be the filter string. This fix simply stores the Slapi_Filter in the proper member of the configEntry struct. With this fix, the test in comment#1 properly rejects adding a new "posixAccount" with no "gidNumber" attribute specified. If one explicitly specifies a "gidNumber" when adding the entry, the entry is added successfully, and the "uidNumber" value is generated by the DNA plug-in. Platforms tested: Fedora 8 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=313010&action=diff

1 0

[Fedora-directory-devel] Please review: [Bug 457156] GER: allow GER for non-existing entries (phase 2)
by Noriko Hosoi 30 Jul '08

30 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=457156 Summary: GER: allow GER for non-existing entries (phase 2) Product: Fedora Directory Server Version: 1.1.1 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: Security - Access Control (GER) AssignedTo: nhosoi(a)redhat.com ReportedBy: nhosoi(a)redhat.com QAContact: ckannan(a)redhat.com Estimated Hours: 0.0 The change is too small for "(phase 2)", though... :) Description of problem: "437525: GER: allow GER for non-existing entries" introduced a new type of list (e.g., "*@inetorgperson" "*@posixaccount") to the ldapsearch when the Get Effective Rights Control OID is given. If such list is given, a template entry is internally created and the effective rights are evaluated. Currently, the entry is not associated with any suffix. Therefore, no meaning ACIs are applied to the template entry. Since the search specifies the search base, we could use the dn as the template entry is located. ------- Additional Comments From nhosoi(a)redhat.com 2008-07-29 19:05 EST ------- Created an attachment (id=312947) --> (https://bugzilla.redhat.com/attachment.cgi?id=312947&action=view) cvs diff ldap/servers/plugins/acl/acleffectiverights.c Fix Description: get the target dn from the pblock and add it to the template entry dn if available. Plus a memory leak was found and fixed at the same time. ------- Additional Comments From nhosoi(a)redhat.com 2008-07-30 11:29 EST ------- Created an attachment (id=313006) --> (https://bugzilla.redhat.com/attachment.cgi?id=313006&action=view) test ldif file This test sets ACI: aci: (target=ldap:///ou=Accounting,dc=example,dc=com)(targetattr="*")(version 3. 0; acl "tp25"; allow (read,search,compare) (userdn = "ldap:///anyone") ;) That is, no ACI in dc=example,dc=com, nor entries under ou other than ou=Accounting; entries under ou=Accounting,dc=example,dc=com have the permission rsc. Test cases: 1) search from dc=example,dc=com: $ ldapsearch -D "cn=Directory Manager" -w <pw> -b "dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" dn: cn=template_posixaccount_objectclass,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none 2) search from ou=accounting,dc=example,dc=com: $ ldapsearch -D "cn=Directory Manager" -w <pw> -b "ou=accounting,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" dn: cn=template_posixaccount_objectclass,ou=accounting,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: v attributeLevelRights: cn:rsc, uid:rsc, uidNumber:rsc, gidNumber:rsc, homeDirec tory:rsc, objectClass:rsc, userPassword:rsc, loginShell:rsc, gecos:rsc, desc ription:rsc, aci:rsc 3) search from ou=payroll,dc=example,dc=com: $ ldapsearch -D "cn=Directory Manager" -w <pw> -b "ou=payroll,dc=example,dc=com" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount" dn: cn=template_posixaccount_objectclass,ou=payroll,dc=example,dc=com objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none 4) search from "" (no acis are set): ldapsearch D "cn=Directory Manager" -w <pw> -b "" -s base -J "1.3.6.1.4.1.42.2.27.9.5.2:false:dn: cn=Jacques SMITH, dc=example,dc=com" "(uidnumber=*)" "*@posixaccount"version: 1 dn: cn=template_posixaccount_objectclass, objectClass: posixaccount objectClass: top homeDirectory: dummy gidNumber: dummy uidNumber: dummy uid: dummy cn: dummy entryLevelRights: none attributeLevelRights: cn:none, uid:none, uidNumber:none, gidNumber:none, homeD irectory:none, objectClass:none, userPassword:none, loginShell:none, gecos:n one, description:none, aci:none

1 0

[Fedora-directory-devel] please review: [Bug 428232] DN Rename with case change only fails
by Noriko Hosoi 29 Jul '08

29 Jul '08

Summary: DN Rename with case change only fails https://bugzilla.redhat.com/show_bug.cgi?id=428232 Description of problem: modrdn treated DN case insensitive. If the new dn and the old dn were identical except the case difference, the code stopped there and returned LDAP_ALREADY_EXISTS. Thus, users had no way to change the case in the DN. ------- Additional Comments From nhosoi(a)redhat.com 2008-07-29 10:59 EST ------- Created an attachment (id=312887) --> (https://bugzilla.redhat.com/attachment.cgi?id=312887&action=view) cvs diffs Files: slapi-plugin.h dn.c back-ldbm/ldbm_modrdn.c Description: added additional checks if the original DN and the to-be-updated DN are different in terms of the cases. If the cases do not match, instead of returning LDAP_ALREADY_EXISTS, continue the modrdn process. ------- Additional Comments From nhosoi(a)redhat.com 2008-07-29 11:02 EST ------- Created an attachment (id=312890) --> (https://bugzilla.redhat.com/attachment.cgi?id=312890&action=view) modrdn test program modrdn.c How to verify: 1. Replace the modrdn.c in the mozilla ldap client's examples and compile it. 2. Prepare a suffix "dc=example,dc=com" on the test server. 3. run the program $ ./modrdn <port> <directory_manager_password> Added entry "cn=Jacques Smith, dc=example,dc=com". Calling modrdn: "cn=Jacques Smith, dc=example,dc=com" => "cn=Jacques SMITH" The modrdn operation was successful. Entry "cn=Jacques Smith, dc=example,dc=com" has been changed to "cn=Jacques SMITH, dc=example,dc=com".

1 0

[Fedora-directory-devel] Please Review: (456968) DNA plug-in should use separate locks for each managed range
by Nathan Kinder 29 Jul '08

29 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=456968 Resolves: bug 456968 Bug Description: The DNA plug-in currently shares a single mutex to protect the generation of new values across all configured ranges. While this approach is safe, it can cause excessive thread contention if you have multiple managed ranges configured. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix is to create a mutex as a part of each cached configuration object. We have one cached configuration object per configured range. When we load the configuration, we could create the mutexes and store them with the rest of the configuration. With this approach, a thread would only need to lock the range that it is getting a new value from, which would not block threads working with other configured ranges. Platforms tested: Fedora 8 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=312827&action=diff

1 0

[Fedora-directory-devel] Please review: Bug 431103: Cannot setup ds with remote config DS
by Rich Megginson 24 Jul '08

24 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=431103 Resolves: bug 431103 Bug Description: Cannot setup ds with remote config DS Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: If using a non-standard config dir for the directory server, creating additional instances with setup-ds-admin.pl fails, because it doesn't take into consideration the location. DS_CONFIG_DIR is set in DSCreate.pm to the real location of the new directory server instance config directory. Platforms tested: Fedora 8 Flag Day: no Doc impact: no https://bugzilla.redhat.com/show_bug.cgi?id=431103#c12

1 0

[Fedora-directory-devel] Fedora DS
by Sachin 22 Jul '08

22 Jul '08

Hi all I have installed fedora directory server on fedora9 OS through yum as per the document successfully. I am also able to get the http://localhost:9830/ page . but its all static how go would I go about, how do I add users groups and policies ??? Can anyone Please help me on this ???? -- Regards Sachin M Sr. Clustering Engg Crest Animation Studio Ltd Ph 25197628 cell no - 9819565900

2 1

[Fedora-directory-devel] Please Review: (456162) Merge in DNA plug-in code from FreeIPA
by Nathan Kinder 22 Jul '08

22 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=456162 Resolves: bug 456162 Bug Description: The distributed numeric assignment plug-in was initially written for the FreeIPA project, and checked into both their tree as well as the Fedora Directory Server tree. The plug-in has evolved over time in the FreeIPA tree, and it a part of their current release. Unfortunately, these changes haven't made it back to the Fedora DS source code. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: These changes merge the code from FreeIPA into our source tree. The plan is to have us provide the DNA plug-in for FreeIPA to use in future versions. There are a number of changes that are noide (formatting cleanups and such), but there are a number of other useful fixes and changes in here as well. Platforms tested: Fedora 8 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=312297&action=diff

1 0

[Fedora-directory-devel] Please review: Bug 447614: Lack of manpages
by Rich Megginson 15 Jul '08

15 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=447614 Resolves: bug 447614 Bug Description: Lack of manpages Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This adds man pages for the command line utilities. The configure.ac diffs were a little bit tricky - apparently, mandir is not set to a correct default value, so we have to make sure we set a reasonable default value it if the user has not set it (e.g. rpmbuild will override it with --mandir=something). Platforms tested: Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=311789&action=diff

1 0

[Fedora-directory-devel] Please review: Bug 428765: leak in bitwise plugin
by Rich Megginson 14 Jul '08

14 Jul '08

https://bugzilla.redhat.com/show_bug.cgi?id=428765 Resolves: bug 428765 Bug Description: leak in bitwise plugin Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The bitwise plugin should first check to make sure the requested OID is one that it can handle. Platforms tested: RHEL5, Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=311516&action=diff

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel July 2008