From umasankar_p at yahoo.com Fri Oct 7 03:31:40 2005 From: umasankar_p at yahoo.com (Umasankar) Date: Thu, 6 Oct 2005 20:31:40 -0700 (PDT) Subject: [Fedora-directory-devel] Plug-in development query Message-ID: <20051007033140.99849.qmail@web30302.mail.mud.yahoo.com> Hi, Please bear with me if this is already handled in a bug report or something like that. I did a search on that docs, web and bugzilla but didn?t find an answer. I am trying to write a simple post add operation plug-in that logs the added entry to a change log file. But I am facing an issue that even when the add operation fails due to any reason, the post operation plug-in logs the changes which is logically incorrect. I am aware that a post operation plug-in will run irrespective of whether the operation was successful or failure. But I think there should be a way to know the status of the operation from within the post-op plug-in i.e. through the parameter block. I searched through the RedHat?s plug-in programmer?s guide, but to no avail. I found that the Parameter block structure has an integer variable ?pb_result_code? (slap.h:1395: int pb_result_code) which I believe should store the result of the operation as set by the back end. I would like to know if this is right and if so, how to access this variable from the plug-in or is there a better way of finding the status of the operation that I am not aware of. Any help or pointers to the right document will be appreciated. Thanks Umasankar P __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From david_list at boreham.org Fri Oct 7 03:51:35 2005 From: david_list at boreham.org (David Boreham) Date: Thu, 06 Oct 2005 21:51:35 -0600 Subject: [Fedora-directory-devel] Plug-in development query In-Reply-To: <20051007033140.99849.qmail@web30302.mail.mud.yahoo.com> References: <20051007033140.99849.qmail@web30302.mail.mud.yahoo.com> Message-ID: <4345F0C7.70703@boreham.org> > >Any help or pointers to the right document will be >appreciated. > > You could check out the retro changelog code : it does exactly what you are trying to do --- maintain a flat file change log like we had in UMich, OpenLDAP, Netscape DS 1-4x and so on. Somewhere right around here would be a good place to look: http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/plugins/retrocl/retrocl_po.c#492 From umasankar_p at yahoo.com Fri Oct 7 11:39:42 2005 From: umasankar_p at yahoo.com (Umasankar) Date: Fri, 7 Oct 2005 04:39:42 -0700 (PDT) Subject: [Fedora-directory-devel] Plug-in development query In-Reply-To: <4345F0C7.70703@boreham.org> Message-ID: <20051007113942.57026.qmail@web30310.mail.mud.yahoo.com> Thanks a lot. It works. Umasankar P --- David Boreham wrote: > > > > >Any help or pointers to the right document will be > >appreciated. > > > > > You could check out the retro changelog code : it > does exactly > what you are trying to do --- maintain a flat file > change log like > we had in UMich, OpenLDAP, Netscape DS 1-4x and so > on. > > Somewhere right around here would be a good place to > look: > http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/plugins/retrocl/retrocl_po.c#492 > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From Umashankar.Pandurangan at ip-soft.net Fri Oct 7 03:27:33 2005 From: Umashankar.Pandurangan at ip-soft.net (Umasankar Pandurangan) Date: Fri, 7 Oct 2005 08:57:33 +0530 Subject: [Fedora-directory-devel] Plug-in development query Message-ID: <6C0E88C3CD29B048B40FF911122EDC6C06A6819E@blr-msx-01.ip-soft.net> Hi, Please bear with me if this is already handled in a bug report or something like that. I did a search on that docs, web and bugzilla but didn't find an answer. I am trying to write a simple post add operation plug-in that logs the added entry to a change log file. But I am facing an issue that even when the add operation fails due to any reason, the post operation plug-in logs the changes which is logically incorrect. I am aware that a post operation plug-in will run irrespective of whether the operation was successful or failure. But I think there should be a way to know the status of the operation from within the post-op plug-in i.e. through the parameter block. I searched through the RedHat's plug-in programmer's guide, but to no avail. I found that the Parameter block structure has an integer variable 'pb_result_code' (slap.h:1395: int pb_result_code) which I believe should store the result of the operation as set by the back end. I would like to know if this is right and if so, how to access this variable from the plug-in or is there a better way of finding the status of the operation that I am not aware of. Any help or pointers to the right document will be appreciated. Thanks Umasankar P -------------- next part -------------- An HTML attachment was scrubbed... URL: From discovery64 at gmail.com Sat Oct 8 20:54:01 2005 From: discovery64 at gmail.com (discover) Date: Sat, 08 Oct 2005 16:54:01 -0400 Subject: [Fedora-directory-devel] ACI evaluation Message-ID: <434831E9.70005@gmail.com> Is there any way to see the order of ACI evaluation for search/mod ...etc ? Also does the order of ACI impact the performance ? Thanks From david_list at boreham.org Sat Oct 8 21:59:49 2005 From: david_list at boreham.org (David Boreham) Date: Sat, 08 Oct 2005 15:59:49 -0600 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <434831E9.70005@gmail.com> References: <434831E9.70005@gmail.com> Message-ID: <43484155.2080201@boreham.org> discover wrote: > Is there any way to see the order of ACI evaluation for search/mod > ...etc ? Not easily. You might me able to glean some information by enabling access control logging and looking at the error log output when you submit an operation. > Also does the order of ACI impact the performance ? Probably not. (not sure if you mean the order the aci attributes are added to the DS -- in that case absolutely not; or if you are asking about the internal ordering of clauses within a single aci -- in that case probably not). To gain a total understanding you'd really need to step through the code in the debugger, which would only suit those with a strong constitution. From discovery64 at gmail.com Sun Oct 9 12:07:28 2005 From: discovery64 at gmail.com (discover) Date: Sun, 09 Oct 2005 08:07:28 -0400 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <43484155.2080201@boreham.org> References: <434831E9.70005@gmail.com> <43484155.2080201@boreham.org> Message-ID: <43490800.7080507@gmail.com> Thanks David . Regarding the order of ACI , I meant for example, say there are 4 ACIs on dc=example,dc=com. One for config admins, one for directory admins, Anonymous Access and one for group admin listed in that order. Whether this particular order has any impact ? Or the order is insignificant ? David Boreham wrote: > discover wrote: > >> Is there any way to see the order of ACI evaluation for search/mod >> ...etc ? > > > Not easily. You might me able to glean some information by enabling > access control logging and looking at the error log output when you > submit > an operation. > >> Also does the order of ACI impact the performance ? > > > Probably not. (not sure if you mean the order the aci attributes > are added to the DS -- in that case absolutely not; or if you > are asking about the internal ordering of clauses within a > single aci -- in that case probably not). > > To gain a total understanding you'd really need to step through > the code in the debugger, which would only suit those > with a strong constitution. > > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > From jclowser at unitedmessaging.com Mon Oct 10 13:56:50 2005 From: jclowser at unitedmessaging.com (Jeff Clowser) Date: Mon, 10 Oct 2005 09:56:50 -0400 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <43490800.7080507@gmail.com> References: <434831E9.70005@gmail.com> <43484155.2080201@boreham.org> <43490800.7080507@gmail.com> Message-ID: <434A7322.4020603@unitedmessaging.com> I don't think the order in which they are processed matters (maybe very slightly from a performance pov, but not from a "what can I do" pov). Denies take precedence over allows no matter where they are, and all aci's are cumulative, so your access is the combined set of permissions defined, no matter the order they are in. Also, deny is the default, so a lack of an aci to allow something will deny it (FWIW, I never use deny aci's if at all possible, because there is no way to override them with a subsequent allow - better to carefully define what you allow and where). This is much different than openldap aci's, where the order is very important. In your example, presumably anonymous will have some base level of access, and config, directory, and group admin aci's will give additional access. Adding a user to each of these groups will extend their access by what each aci allows, and putting users in more than one of these groups will just allow them more access, but the order they appear in doesn't matter (and given that they are in the same entry, there is no way to specify/guarantee the order anyway). - Jeff discover wrote: > Thanks David . Regarding the order of ACI , I meant for example, say > there are 4 ACIs on dc=example,dc=com. > One for config admins, one for directory admins, Anonymous Access and > one for group admin listed in that order. Whether this particular > order has any impact ? Or the order is insignificant ? > > David Boreham wrote: > >> discover wrote: >> >>> Is there any way to see the order of ACI evaluation for search/mod >>> ...etc ? >> >> >> >> Not easily. You might me able to glean some information by enabling >> access control logging and looking at the error log output when you >> submit >> an operation. >> >>> Also does the order of ACI impact the performance ? >> >> >> >> Probably not. (not sure if you mean the order the aci attributes >> are added to the DS -- in that case absolutely not; or if you >> are asking about the internal ordering of clauses within a >> single aci -- in that case probably not). >> >> To gain a total understanding you'd really need to step through >> the code in the debugger, which would only suit those >> with a strong constitution. >> >> >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel From rmeggins at redhat.com Mon Oct 10 14:19:34 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 10 Oct 2005 08:19:34 -0600 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <434A7322.4020603@unitedmessaging.com> References: <434831E9.70005@gmail.com> <43484155.2080201@boreham.org> <43490800.7080507@gmail.com> <434A7322.4020603@unitedmessaging.com> Message-ID: <434A7876.5020201@redhat.com> There are two useful ACI development utilities. The first is the special ACL Summary error log level. This can provide very useful information about ACI evaluation without the extremely verbose output of the "regular" aci log level. The second is the Get Effective Rights query, so you can do queries like "If I were to BIND as user X, would I be able to read/write this attribute? If I were to bind as user X, what attributes would be visible to me?". Jeff Clowser wrote: > I don't think the order in which they are processed matters (maybe > very slightly from a performance pov, but not from a "what can I do" > pov). > > Denies take precedence over allows no matter where they are, and all > aci's are cumulative, so your access is the combined set of > permissions defined, no matter the order they are in. Also, deny is > the default, so a lack of an aci to allow something will deny it > (FWIW, I never use deny aci's if at all possible, because there is no > way to override them with a subsequent allow - better to carefully > define what you allow and where). > > This is much different than openldap aci's, where the order is very > important. > > In your example, presumably anonymous will have some base level of > access, and config, directory, and group admin aci's will give > additional access. Adding a user to each of these groups will extend > their access by what each aci allows, and putting users in more than > one of these groups will just allow them more access, but the order > they appear in doesn't matter (and given that they are in the same > entry, there is no way to specify/guarantee the order anyway). > > - Jeff > > discover wrote: > >> Thanks David . Regarding the order of ACI , I meant for example, say >> there are 4 ACIs on dc=example,dc=com. >> One for config admins, one for directory admins, Anonymous Access and >> one for group admin listed in that order. Whether this particular >> order has any impact ? Or the order is insignificant ? >> >> David Boreham wrote: >> >>> discover wrote: >>> >>>> Is there any way to see the order of ACI evaluation for search/mod >>>> ...etc ? >>> >>> >>> >>> >>> Not easily. You might me able to glean some information by enabling >>> access control logging and looking at the error log output when you >>> submit >>> an operation. >>> >>>> Also does the order of ACI impact the performance ? >>> >>> >>> >>> >>> Probably not. (not sure if you mean the order the aci attributes >>> are added to the DS -- in that case absolutely not; or if you >>> are asking about the internal ordering of clauses within a >>> single aci -- in that case probably not). >>> >>> To gain a total understanding you'd really need to step through >>> the code in the debugger, which would only suit those >>> with a strong constitution. >>> >>> >>> >>> -- >>> Fedora-directory-devel mailing list >>> Fedora-directory-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > > > -- > 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: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From david_list at boreham.org Mon Oct 10 14:37:21 2005 From: david_list at boreham.org (David Boreham) Date: Mon, 10 Oct 2005 08:37:21 -0600 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <43490800.7080507@gmail.com> References: <434831E9.70005@gmail.com> <43484155.2080201@boreham.org> <43490800.7080507@gmail.com> Message-ID: <434A7CA1.5080901@boreham.org> discover wrote: > Thanks David . Regarding the order of ACI , I meant for example, say > there are 4 ACIs on dc=example,dc=com. > One for config admins, one for directory admins, Anonymous Access and > one for group admin listed in that order. Whether this particular > order has any impact ? Or the order is insignificant ? The order isn't supposed to be significant (in fact, there is no defined order, but in reality I bet the server reads the acis in the order they were added). It's possible that the order could affect performance in the case that an expensive to evaluate aci comes after or before a cheap to evaluate aci that denies access. Evaluation may stop when access is found to be denied. You'd need to run tests to determine if this is the case or not. I don't think the acl code is smart enough to decide which acis might be more or less expensive to evaluate (like a database query planner would do, for example). From discovery64 at gmail.com Wed Oct 12 02:19:58 2005 From: discovery64 at gmail.com (discover) Date: Tue, 11 Oct 2005 22:19:58 -0400 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <434A7876.5020201@redhat.com> References: <434831E9.70005@gmail.com> <43484155.2080201@boreham.org> <43490800.7080507@gmail.com> <434A7322.4020603@unitedmessaging.com> <434A7876.5020201@redhat.com> Message-ID: <434C72CE.2090700@gmail.com> I have used the ACL logging and is helpful a little . It does not show the "weight" or "cost" of each acl evaluation . As David mentioned , may be trying it out may be the only way?! Also the logs show AC s evaluating entry/attribute rights for the client DN for attributes neither in the filter nor in the attributes to return .I was expecting to see only for the attributes in the search filter or the returned attributes . Also the ACL Cache, what is the size ? Does this come out of entrycache ? Is ACL eval memory intensive ? Thanks Rich Megginson wrote: > There are two useful ACI development utilities. The first is the > special ACL Summary error log level. This can provide very useful > information about ACI evaluation without the extremely verbose output > of the "regular" aci log level. The second is the Get Effective > Rights query, so you can do queries like "If I were to BIND as user X, > would I be able to read/write this attribute? If I were to bind as > user X, what attributes would be visible to me?". > > Jeff Clowser wrote: > >> I don't think the order in which they are processed matters (maybe >> very slightly from a performance pov, but not from a "what can I do" >> pov). >> >> Denies take precedence over allows no matter where they are, and all >> aci's are cumulative, so your access is the combined set of >> permissions defined, no matter the order they are in. Also, deny is >> the default, so a lack of an aci to allow something will deny it >> (FWIW, I never use deny aci's if at all possible, because there is no >> way to override them with a subsequent allow - better to carefully >> define what you allow and where). >> >> This is much different than openldap aci's, where the order is very >> important. >> >> In your example, presumably anonymous will have some base level of >> access, and config, directory, and group admin aci's will give >> additional access. Adding a user to each of these groups will extend >> their access by what each aci allows, and putting users in more than >> one of these groups will just allow them more access, but the order >> they appear in doesn't matter (and given that they are in the same >> entry, there is no way to specify/guarantee the order anyway). >> >> - Jeff >> >> discover wrote: >> >>> Thanks David . Regarding the order of ACI , I meant for example, say >>> there are 4 ACIs on dc=example,dc=com. >>> One for config admins, one for directory admins, Anonymous Access >>> and one for group admin listed in that order. Whether this >>> particular order has any impact ? Or the order is insignificant ? >>> >>> David Boreham wrote: >>> >>>> discover wrote: >>>> >>>>> Is there any way to see the order of ACI evaluation for search/mod >>>>> ...etc ? >>>> >>>> >>>> >>>> >>>> >>>> Not easily. You might me able to glean some information by enabling >>>> access control logging and looking at the error log output when you >>>> submit >>>> an operation. >>>> >>>>> Also does the order of ACI impact the performance ? >>>> >>>> >>>> >>>> >>>> >>>> Probably not. (not sure if you mean the order the aci attributes >>>> are added to the DS -- in that case absolutely not; or if you >>>> are asking about the internal ordering of clauses within a >>>> single aci -- in that case probably not). >>>> >>>> To gain a total understanding you'd really need to step through >>>> the code in the debugger, which would only suit those >>>> with a strong constitution. >>>> >>>> >>>> >>>> -- >>>> Fedora-directory-devel mailing list >>>> Fedora-directory-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>> >>> >>> >>> -- >>> Fedora-directory-devel mailing list >>> Fedora-directory-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> >> >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > >------------------------------------------------------------------------ > >-- >Fedora-directory-devel mailing list >Fedora-directory-devel at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 12 12:50:10 2005 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 12 Oct 2005 06:50:10 -0600 Subject: [Fedora-directory-devel] ACI evaluation In-Reply-To: <434C72CE.2090700@gmail.com> References: <434831E9.70005@gmail.com> <43484155.2080201@boreham.org> <43490800.7080507@gmail.com> <434A7322.4020603@unitedmessaging.com> <434A7876.5020201@redhat.com> <434C72CE.2090700@gmail.com> Message-ID: <434D0682.90100@redhat.com> discover wrote: > I have used the ACL logging and is helpful a little . It does not show > the "weight" or "cost" of each acl evaluation . As David mentioned , > may be trying it out may be the only way?! Yes. If you want to get the raw performance data, the only way is to run some tests yourself. > Also the logs show AC s evaluating entry/attribute rights for the > client DN for attributes neither in the filter nor in the attributes > to return .I was expecting to see only for the attributes in the > search filter or the returned attributes . I think that's just the way it works. > > Also the ACL Cache, what is the size ? Does this come out of entrycache ? No, it has its own separate cache. You probably won't notice it unless you have thousands of ACIs. > > Is ACL eval memory intensive ? Only if you have thousands of ACIs. > Thanks > > Rich Megginson wrote: >> There are two useful ACI development utilities. The first is the >> special ACL Summary error log level. This can provide very useful >> information about ACI evaluation without the extremely verbose output >> of the "regular" aci log level. The second is the Get Effective >> Rights query, so you can do queries like "If I were to BIND as user >> X, would I be able to read/write this attribute? If I were to bind >> as user X, what attributes would be visible to me?". >> >> Jeff Clowser wrote: >> >>> I don't think the order in which they are processed matters (maybe >>> very slightly from a performance pov, but not from a "what can I do" >>> pov). >>> >>> Denies take precedence over allows no matter where they are, and all >>> aci's are cumulative, so your access is the combined set of >>> permissions defined, no matter the order they are in. Also, deny is >>> the default, so a lack of an aci to allow something will deny it >>> (FWIW, I never use deny aci's if at all possible, because there is >>> no way to override them with a subsequent allow - better to >>> carefully define what you allow and where). >>> >>> This is much different than openldap aci's, where the order is very >>> important. >>> >>> In your example, presumably anonymous will have some base level of >>> access, and config, directory, and group admin aci's will give >>> additional access. Adding a user to each of these groups will >>> extend their access by what each aci allows, and putting users in >>> more than one of these groups will just allow them more access, but >>> the order they appear in doesn't matter (and given that they are in >>> the same entry, there is no way to specify/guarantee the order anyway). >>> >>> - Jeff >>> >>> discover wrote: >>> >>>> Thanks David . Regarding the order of ACI , I meant for example, >>>> say there are 4 ACIs on dc=example,dc=com. >>>> One for config admins, one for directory admins, Anonymous Access >>>> and one for group admin listed in that order. Whether this >>>> particular order has any impact ? Or the order is insignificant ? >>>> >>>> David Boreham wrote: >>>> >>>>> discover wrote: >>>>> >>>>>> Is there any way to see the order of ACI evaluation for >>>>>> search/mod ...etc ? >>>>> >>>>> >>>>> >>>>> >>>>> Not easily. You might me able to glean some information by enabling >>>>> access control logging and looking at the error log output when >>>>> you submit >>>>> an operation. >>>>> >>>>>> Also does the order of ACI impact the performance ? >>>>> >>>>> >>>>> >>>>> >>>>> Probably not. (not sure if you mean the order the aci attributes >>>>> are added to the DS -- in that case absolutely not; or if you >>>>> are asking about the internal ordering of clauses within a >>>>> single aci -- in that case probably not). >>>>> >>>>> To gain a total understanding you'd really need to step through >>>>> the code in the debugger, which would only suit those >>>>> with a strong constitution. >>>>> >>>>> >>>>> >>>>> -- >>>>> Fedora-directory-devel mailing list >>>>> Fedora-directory-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>>> >>>> >>>> >>>> -- >>>> Fedora-directory-devel mailing list >>>> Fedora-directory-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >>> >>> >>> -- >>> Fedora-directory-devel mailing list >>> Fedora-directory-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 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: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From langel at redhat.com Wed Oct 12 20:52:31 2005 From: langel at redhat.com (Lillian Angel) Date: Wed, 12 Oct 2005 16:52:31 -0400 Subject: [Fedora-directory-devel] Fedora Directory Server Application patch Message-ID: <1129150351.2953.114.camel@tow.toronto.redhat.com> Hello, I have created a patch for the Netscape/Fedora Directory Server Application. When applied to the console directory, the application builds successfully against Classpath and the JDK. Also, the file console.src.com.netscape.client.comm.Hanger.java should be removed from the cvs repository. Its a problem for free VMs since we don't implement sun.net.www.protocol.http*. I found by removing it, it compiles fine with the JDK and Classpath. See the attached patch. Thanks, Lillian Angel -------------- next part -------------- A non-text attachment was scrubbed... Name: Netscape_Patch.diff Type: text/x-patch Size: 4362 bytes Desc: not available URL: From langel at redhat.com Wed Oct 12 20:56:58 2005 From: langel at redhat.com (Lillian Angel) Date: Wed, 12 Oct 2005 16:56:58 -0400 Subject: [Fedora-directory-devel] Fedora Directory Server Application patch In-Reply-To: <1129150351.2953.114.camel@tow.toronto.redhat.com> References: <1129150351.2953.114.camel@tow.toronto.redhat.com> Message-ID: <1129150618.2953.121.camel@tow.toronto.redhat.com> On Wed, 2005-10-12 at 16:52 -0400, Lillian Angel wrote: > Hello, > > I have created a patch for the Netscape/Fedora Directory Server > Application. When applied to the console directory, the application > builds successfully against Classpath and the JDK. > > Also, the file console.src.com.netscape.client.comm.Hanger.java should > be removed from the cvs repository. My mistake, I typed the filename wrong. Should be: console/src/com/netscape/client/comm/Handler.java Lillian From langel at redhat.com Fri Oct 14 17:42:27 2005 From: langel at redhat.com (Lillian Angel) Date: Fri, 14 Oct 2005 13:42:27 -0400 Subject: [Fedora-directory-devel] Bug Report Message-ID: <1129311747.2953.195.camel@tow.toronto.redhat.com> Hi, I have filed a new bug report, and attached a proposed patch. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170823 Lillian From langel at redhat.com Mon Oct 17 18:36:29 2005 From: langel at redhat.com (Lillian Angel) Date: Mon, 17 Oct 2005 14:36:29 -0400 Subject: [Fedora-directory-devel] ResourceCellRenderer.paint Bug Report Message-ID: <1129574189.31849.12.camel@tow.toronto.redhat.com> Hi, I have filed a new bug and attached a patch. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171051 Lillian From discovery64 at gmail.com Wed Oct 19 11:35:20 2005 From: discovery64 at gmail.com (discover) Date: Wed, 19 Oct 2005 07:35:20 -0400 Subject: [Fedora-directory-devel] query processing Message-ID: <43562F78.9030006@gmail.com> If you have query like (|(objectclass=*)(objectclass=ldapsubentry)), may a scope=0, as for I know the filters get evaluated independently first i.e objectclass=* then objectclass=ldapsubentry , then an intersection of two sets is computed . The resulting entry ids would be checked against the ancestorid index for the subtree , scope to arrive at the final results . Is this a correct understanding ? Is there any other way the scope is handled ? Thanks From david_list at boreham.org Wed Oct 19 14:42:35 2005 From: david_list at boreham.org (David Boreham) Date: Wed, 19 Oct 2005 08:42:35 -0600 Subject: [Fedora-directory-devel] query processing In-Reply-To: <43562F78.9030006@gmail.com> References: <43562F78.9030006@gmail.com> Message-ID: <43565B5B.4070007@boreham.org> discover wrote: > If you have query like (|(objectclass=*)(objectclass=ldapsubentry)), > may a scope=0, as for I know the filters get evaluated independently > first i.e > objectclass=* then objectclass=ldapsubentry , then an intersection of > two sets is computed . The resulting entry ids would be checked > against the ancestorid index for the subtree , scope to arrive at the > final results . Is this a correct understanding ? Nope. For a base scope search the base entry is found alone (using the cache and if it isn't in there the entrydn index). Then the filter is applied to the entry. > > Is there any other way the scope is handled ? You really need to read the code to understand how queries are processed. Look at ldbm_search.c and filterindex.c. From sparklezou at hotmail.com Thu Oct 20 10:14:29 2005 From: sparklezou at hotmail.com (sparklezou at hotmail.com) Date: Thu, 20 Oct 2005 10:14:29 +0000 Subject: [Fedora-directory-devel] About SNMP develop Message-ID: Dear all, I'm the newbie in the fedora directory server. I would like to know clear the sofeware architecture of SNMP part of fedora. Could you give me your kind help? Which document is useful? Please give me a hand. Thank you very much! Waiting for your kind replay! Best Regards, Sparklezou From sparklezou at hotmail.com Thu Oct 20 10:09:13 2005 From: sparklezou at hotmail.com (sparklezou at hotmail.com) Date: Thu, 20 Oct 2005 10:09:13 +0000 Subject: [Fedora-directory-devel] About SNMP develop Message-ID: Dear all, I'm the newbie in the fedora directory server. I would like to know clear the sofeware architecture of SNMP part of fedora. Could you give me your kind help? Which document is useful? Please give me a hand. Thank you very much! Waiting for your kind replay! Best Regards, Sparklezou From rmeggins at redhat.com Thu Oct 20 14:34:08 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 20 Oct 2005 08:34:08 -0600 Subject: [Fedora-directory-devel] About SNMP develop In-Reply-To: References: Message-ID: <4357AAE0.5010301@redhat.com> I'm not sure what you mean. Does this answer your question - http://www.redhat.com/docs/manuals/dir-server/ag/7.1/snmp.html#1073255 also search for snmp in here - http://www.redhat.com/docs/manuals/dir-server/pdf/ds71cli.pdf sparklezou at hotmail.com wrote: > Dear all, > > I'm the newbie in the fedora directory server. I would like to know > clear the sofeware architecture of SNMP part of fedora. Could you give > me your kind help? Which document is useful? > Please give me a hand. > > Thank you very much! > > Waiting for your kind replay! > > Best Regards, > Sparklezou > > > -- > 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: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 25 16:58:01 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Oct 2005 10:58:01 -0600 Subject: [Fedora-directory-devel] Please review: bug 171722: console: build.xml has hardcoded reference to root directory Message-ID: <435E6419.7090406@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171722 Bug(s) fixed: 171722 Bug Description: console: build.xml has hardcoded reference to root directory Reviewed by: ??? Files: build.xml, build.properties Branch: HEAD Fix Description: Use "." instead of ".." as the console.root. This allows us to use console.root/buildnum.pl instead of console.root/console/buildnum.pl. The imports and built dirs are referenced by console.root/../built e.g. The problem is that when building from a source tar ball in rpm or gar, it expects the source directory when unpacked to be the same name as the .tar.gz file e.g. fedora-console-7.1.1.tar.gz unpacks into fedora-console-7.1.1. If "/console/" is hard coded, this won't work. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120372 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Oct 25 17:14:15 2005 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 25 Oct 2005 10:14:15 -0700 Subject: [Fedora-directory-devel] Please review: bug 171722: console: build.xml has hardcoded reference to root directory In-Reply-To: <435E6419.7090406@redhat.com> References: <435E6419.7090406@redhat.com> Message-ID: <435E67E7.2040806@redhat.com> Looks good. I tested it with and without a renamed root directory, and the build worked fine. -NGK Rich Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171722 > Bug(s) fixed: 171722 > Bug Description: console: build.xml has hardcoded reference to root > directory > Reviewed by: ??? > Files: build.xml, build.properties > Branch: HEAD > Fix Description: Use "." instead of ".." as the console.root. This > allows us to use console.root/buildnum.pl instead of > console.root/console/buildnum.pl. The imports and built dirs are > referenced by console.root/../built e.g. The problem is that when > building from a source tar ball in rpm or gar, it expects the source > directory when unpacked to be the same name as the .tar.gz file e.g. > fedora-console-7.1.1.tar.gz unpacks into fedora-console-7.1.1. If > "/console/" is hard coded, this won't work. > Platforms tested: RHEL4 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120372 > >------------------------------------------------------------------------ > >-- >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: 3174 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 25 17:32:58 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Oct 2005 11:32:58 -0600 Subject: [Fedora-directory-devel] Checkin: bug 171722: console: build.xml has hardcoded reference to root directory Message-ID: <435E6C4A.6020500@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171722 Bug(s) fixed: 171722 Bug Description: console: build.xml has hardcoded reference to root directory Reviewed by: nkinder at redhat.com nhosoi at redhat.com (Thanks!) Files: build.xml, build.properties Branch: HEAD Fix Description: Use "." instead of ".." as the console.root. This allows us to use console.root/buildnum.pl instead of console.root/console/buildnum.pl. The imports and built dirs are referenced by console.root/../built e.g. The problem is that when building from a source tar ball in rpm or gar, it expects the source directory when unpacked to be the same name as the .tar.gz file e.g. fedora-console-7.1.1.tar.gz unpacks into fedora-console-7.1.1. If "/console/" is hard coded, this won't work. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120372 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 27 03:05:26 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Oct 2005 21:05:26 -0600 Subject: [Fedora-directory-devel] Please review: bug 171854: Allow DSMLGW to build with GAR build scripts Message-ID: <436043F6.4060305@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171854 Bug(s) fixed: 171854 Bug Description: Allow DSMLGW to build with GAR build scripts Reviewed by: ??? Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120444 Branch: HEAD Fix Description: Add a new macro DSMLGWJARS_BUILD_DIR which defaults to dist/classes for internal builds. For external builds, the developer can grab these jars from their respective locations, or grab the bundle from the fds download site, which is what the GAR builds will do. The location is then passed in on the make command line as DSMLGWJARS_BUILD_DIR=/path/to/dsmlgwjars. Regular internal builds should continue to work as always. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120445 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 27 14:16:45 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Oct 2005 08:16:45 -0600 Subject: [Fedora-directory-devel] Checkin: bug 171854: Allow DSMLGW to build with GAR build scripts Message-ID: <4360E14D.9030202@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171854 Bug(s) fixed: 171854 Bug Description: Allow DSMLGW to build with GAR build scripts Reviewed by: nhosoi at redhat.com (Thanks!) Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120444 Branch: HEAD Fix Description: Add a new macro DSMLGWJARS_BUILD_DIR which defaults to dist/classes for internal builds. For external builds, the developer can grab these jars from their respective locations, or grab the bundle from the fds download site, which is what the GAR builds will do. The location is then passed in on the make command line as DSMLGWJARS_BUILD_DIR=/path/to/dsmlgwjars. Regular internal builds should continue to work as always. Platforms tested: RHEL4 Flag Day: no Doc impact: no -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 27 15:27:12 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 27 Oct 2005 09:27:12 -0600 Subject: [Fedora-directory-devel] Please review: bug 171892: parameterize ldapjdk and crimson jar locations Message-ID: <4360F1D0.4000409@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171892 Bug(s) fixed: 171892 Bug Description: parameterize ldapjdk and crimson jar locations Reviewed by: ??? Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120466 Branch: HEAD Fix Description: This is also needed for GAR. The xmltools also ldapjdk.jar, and needs crimson.jar. DSMLGW does not need crimson.jar. It makes sense to separate these out of the dsmlgw jars. I changed the dsmlgw build.xml to be able to pickup ldapjdk.jar from a different location - defaults to the usual dist/classes. Platforms tested: RHEL4 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120467 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Sat Oct 29 02:24:02 2005 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 28 Oct 2005 20:24:02 -0600 Subject: [Fedora-directory-devel] Checkin: bug 171892: parameterize ldapjdk and crimson jar locations Message-ID: <4362DD42.3020503@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171892 Bug(s) fixed: 171892 Bug Description: parameterize ldapjdk and crimson jar locations Reviewed by: Noriko, Nathan (Thanks!) Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120466 Branch: HEAD Fix Description: This is also needed for GAR. The xmltools also ldapjdk.jar, and needs crimson.jar. DSMLGW does not need crimson.jar. It makes sense to separate these out of the dsmlgw jars. I changed the dsmlgw build.xml to be able to pickup ldapjdk.jar from a different location - defaults to the usual dist/classes. Platforms tested: RHEL4 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120467 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature URL: