From nhosoi at redhat.com Wed Jul 2 15:54:09 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 02 Jul 2008 08:54:09 -0700 Subject: [Fedora-directory-devel] Please review [Bug 450753] Add CLI for dynamic reload schema file task In-Reply-To: <200807020029.m620TZDP015101@bz-web1.app.phx.redhat.com> References: <200807020029.m620TZDP015101@bz-web1.app.phx.redhat.com> Message-ID: <486BA4A1.8050101@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=450753 Summary: Add CLI for dynamic reload schema file task Product: Fedora Directory Server Version: 1.1.1 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: Command Line Utilities AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ohegarty at redhat.com CC: nkinder at redhat.com Estimated Hours: 0.0 Description of problem: A CLI needs to be provided for creating a dynamic reload schema file task, as well. We can take the same approach of this bug: 450746: Add CLI for memberOf fix-up task ------- Additional Comments From nhosoi at redhat.com 2008-07-01 20:29 EST ------- Created an attachment (id=310740) --> (https://bugzilla.redhat.com/attachment.cgi?id=310740&action=view) cvs diff Makefile.am A change to package template-schema-reload.pl. ------- Additional Comments From nhosoi at redhat.com 2008-07-01 20:27 EST ------- Created an attachment (id=310739) --> (https://bugzilla.redhat.com/attachment.cgi?id=310739&action=view) New file: ldapserver/ldap/admin/src/scripts/template-schema-reload.pl.in template file to generate CLI schema-reload.pl. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Jul 2 16:19:28 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 02 Jul 2008 09:19:28 -0700 Subject: [Fedora-directory-devel] Commit [Bug 450753] Add CLI for dynamic reload schema file task In-Reply-To: <486BA4A1.8050101@redhat.com> References: <200807020029.m620TZDP015101@bz-web1.app.phx.redhat.com> <486BA4A1.8050101@redhat.com> Message-ID: <486BAA90.1060008@redhat.com> Summary: Add CLI for dynamic reload schema file task https://bugzilla.redhat.com/show_bug.cgi?id=450753 ------- Additional Comments From nhosoi at redhat.com 2008-07-02 12:15 EST ------- Created an attachment (id=310817) --> (https://bugzilla.redhat.com/attachment.cgi?id=310817&action=view) cvs commit message Reviewed by Rich (Thank you!!) Checked in into CVS HEAD. > https://bugzilla.redhat.com/show_bug.cgi?id=450753 > > Summary: Add CLI for dynamic reload schema file task > Product: Fedora Directory Server > Version: 1.1.1 > Platform: All > OS/Version: Linux > Status: NEW > Severity: low > Priority: low > Component: Command Line Utilities > AssignedTo: nhosoi at redhat.com > ReportedBy: nhosoi at redhat.com > QAContact: ohegarty at redhat.com > CC: nkinder at redhat.com > Estimated Hours: 0.0 > > > Description of problem: > A CLI needs to be provided for creating a dynamic reload schema file > task, as well. > > We can take the same approach of this bug: 450746: Add CLI for > memberOf fix-up task > > ------- Additional Comments From nhosoi at redhat.com 2008-07-01 20:29 > EST ------- > Created an attachment (id=310740) > --> (https://bugzilla.redhat.com/attachment.cgi?id=310740&action=view) > cvs diff Makefile.am > > A change to package template-schema-reload.pl. > > ------- Additional Comments From nhosoi at redhat.com 2008-07-01 20:27 > EST ------- > Created an attachment (id=310739) > --> (https://bugzilla.redhat.com/attachment.cgi?id=310739&action=view) > New file: ldapserver/ldap/admin/src/scripts/template-schema-reload.pl.in > > template file to generate CLI schema-reload.pl. > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Jul 14 16:32:32 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 10:32:32 -0600 Subject: [Fedora-directory-devel] Please review: Bug 435774: Unhandled error during setup: Could not import LDIF file Message-ID: <487B7FA0.9000902@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=435774 Resolves: bug 435774 Bug Description: Unhandled error during setup: Could not import LDIF file Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This doesn't allow you to re-prompt for the file, but this will at least cause setup to output a sensible error message if it detects that the given LDIF file is not readable. Platforms tested: Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=311725&action=diff From rmeggins at redhat.com Mon Jul 14 16:40:36 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 10:40:36 -0600 Subject: [Fedora-directory-devel] Please review: Bug 440899: setup-ds.pl password prompt loops in Confirm prompt Message-ID: <487B8184.1000405@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=440899 Resolves: bug 440899 Bug Description: setup-ds.pl password prompt loops in Confirm prompt Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Just make sure the prompt tells the user that they can hit Control-B Enter at any time to go back if they need to re-enter the password. Platforms tested: RHEL5, Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=311728&action=diff From rmeggins at redhat.com Mon Jul 14 16:43:21 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 10:43:21 -0600 Subject: [Fedora-directory-devel] Please review: Bug 450941: Does not do in-use port detection properly Message-ID: <487B8229.10006@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=450941 Resolves: bug 450941 Bug Description: Does not do in-use port detection properly Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Set SO_REUSEADDR to make sure the port is really available. Platforms tested: RHEL5, Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=311729&action=diff From rmeggins at redhat.com Mon Jul 14 16:50:09 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 10:50:09 -0600 Subject: [Fedora-directory-devel] Please review: Bug 435778: ds_removal: Error:The server '' is not reachable. Error: unknown error Message-ID: <487B83C1.2070401@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=435778 Resolves: bug 435778 Bug Description: ds_removal: Error:The server '' is not reachable. Error: unknown error Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Added -f (force) flag to ds_removal. The -f (force) flag tells ds_removal to ignore errors and attempt to remove as much as possible. This is only suggested to be used if ds_removal without the -f flag fails, and you really, really want to remove the ds. Platforms tested: RHEL5, Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=311731&action=diff From rmeggins at redhat.com Mon Jul 14 17:51:18 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 11:51:18 -0600 Subject: [Fedora-directory-devel] Please review: Bug 431103: Cannot setup ds with remote config DS Message-ID: <487B9216.4090304@redhat.com> 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: This fix has two main parts. The first part is to fix setup. I took parts out of the 01nsroot template and put them into the templates that set up the directory server and admin server. So when those servers are registered, they will create those common entries if not present, or otherwise modify them to add the necessary information. I had to add uname_m and uname_a and some other items to the mapping files. I fixed a typo in one of the template files. I changed setup to create new directory server instances shutdown, so that when they are configured for the passthrough auth plugin, it will be working when started. Otherwise, directory servers you create with setup will not be manageable in the console until after they are restarted. This is the same way that ds_create works. The second part of the fix is to allow people to fix "broken" installs. I added a -u (update) option to setup. This will scan for exsiting installations are re-register all servers found. The dialog flow is pretty simple - it just confirms that you want to run update mode, then asks for the config ds information, then re-registers all servers with the config ds, updating any information that is missing or outdated. Platforms tested: RHEL5, Fedora 8, Fedora 9 Flag Day: no Doc impact: Yes - need to document the new -u option. https://bugzilla.redhat.com/attachment.cgi?id=311740&action=diff https://bugzilla.redhat.com/attachment.cgi?id=311741&action=diff From rmeggins at redhat.com Mon Jul 14 17:58:49 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 11:58:49 -0600 Subject: [Fedora-directory-devel] Please review: Bug 428765: leak in bitwise plugin Message-ID: <487B93D9.7050107@redhat.com> 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 From rmeggins at redhat.com Mon Jul 14 23:49:37 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 14 Jul 2008 17:49:37 -0600 Subject: [Fedora-directory-devel] Please review: Bug 447614: Lack of manpages Message-ID: <487BE611.2030208@redhat.com> 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 From nkinder at redhat.com Mon Jul 21 20:16:30 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 21 Jul 2008 13:16:30 -0700 Subject: [Fedora-directory-devel] Please Review: (456162) Merge in DNA plug-in code from FreeIPA Message-ID: <4884EE9E.4000404@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From sachinm at crestindia.com Tue Jul 22 11:42:42 2008 From: sachinm at crestindia.com (Sachin) Date: Tue, 22 Jul 2008 17:12:42 +0530 Subject: [Fedora-directory-devel] Fedora DS Message-ID: <4885C7B2.20008@crestindia.com> 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 From rmeggins at redhat.com Tue Jul 22 17:31:03 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 22 Jul 2008 11:31:03 -0600 Subject: [Fedora-directory-devel] Fedora DS In-Reply-To: <4885C7B2.20008@crestindia.com> References: <4885C7B2.20008@crestindia.com> Message-ID: <48861957.1040900@redhat.com> Sachin wrote: > 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 ??? fedora-idm-console if you want the web apps/html interface, install fedora-ds-dsgw - the phonebook/orgchart/ds express links will automagically show up on the http://localhost:9830/ page. > > Can anyone Please help me on this ???? > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Jul 24 15:46:14 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 24 Jul 2008 09:46:14 -0600 Subject: [Fedora-directory-devel] Please review: Bug 431103: Cannot setup ds with remote config DS Message-ID: <4888A3C6.9020400@redhat.com> 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 From nkinder at redhat.com Mon Jul 28 22:44:18 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 28 Jul 2008 15:44:18 -0700 Subject: [Fedora-directory-devel] Please Review: (456968) DNA plug-in should use separate locks for each managed range Message-ID: <488E4BC2.3050206@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Jul 29 15:26:04 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 29 Jul 2008 08:26:04 -0700 Subject: [Fedora-directory-devel] please review: [Bug 428232] DN Rename with case change only fails In-Reply-To: <200807291502.m6TF269i003501@bz-web1.app.phx.redhat.com> References: <200807291502.m6TF269i003501@bz-web1.app.phx.redhat.com> Message-ID: <488F368C.8000802@redhat.com> 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 at 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 at 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 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". -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Jul 30 15:36:27 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 30 Jul 2008 08:36:27 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 457156] GER: allow GER for non-existing entries (phase 2) In-Reply-To: <200807292307.m6TN7UMe024789@bz-web1.app.phx.redhat.com> References: <200807292307.m6TN7UMe024789@bz-web1.app.phx.redhat.com> Message-ID: <48908A7B.30109@redhat.com> 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 at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ckannan at 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 at 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 at 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 -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 -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 -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 -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Jul 30 16:27:59 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 30 Jul 2008 09:27:59 -0700 Subject: [Fedora-directory-devel] Please Review: (457260) dnaFilter configuration attribute is not used properly Message-ID: <4890968F.3040402@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Jul 30 23:15:06 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 30 Jul 2008 16:15:06 -0700 Subject: [Fedora-directory-devel] Please Review: (457329) Make better use of cached DNA config information Message-ID: <4890F5FA.40206@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: