Whatever you guys are most comfortable with. The idea here is to get a view of what the call chain looks like and which methods are executing most of the time. This will give us an idea of what kind of infinite loop we're dealing with which steals one or more threads and hikes up the CPU. Thanks, Alex On Thu, Dec 10, 2009 at 12:59 AM, Ioannis Mavroukakis < imavroukakis@gameaccount.com> wrote: > Sure, I'll arrange this with our sysadm. Do you have anything particular in > mind or will jvisualvm do? > > Y. > > > On 10 Dec 2009, at 04:00, Alex Karasulu wrote: > > It would be nice to run your server with a profiler to be able to catch >> just >> when it does get into this state. This would be very valuable since we'd >> see exactly where the code is getting stuck in this terrible loop that >> eats >> your CPU. >> >> You think you can give that a try Ioannis? If you can I'm sure we can work >> together to nip this bug quickly. >> >> Thanks, >> Alex >> >> On Wed, Dec 9, 2009 at 11:04 AM, Ioannis Mavroukakis < >> imavroukakis@gameaccount.com> wrote: >> >> Hi Emmanuel, >>> >>> Don't think it is too, as the same behaviour persists when we shut down >>> ADS >>> and re-start it. Only clearing the ADS directory allows it to recover! I >>> have kept the directory contents though, is there >>> any way I can run any forensics on them ? >>> >>> Thanks, >>> >>> Y. >>> >>> On 9 Dec 2009, at 15:21, Emmanuel LŽcharny wrote: >>> >>> Ioannis Mavroukakis a écrit : >>> >>>> >>>> Hey fellow listers. >>>>> >>>>> Hi Ioannis, >>>> >>>> if you get 100% loaded CPU the it might be MINA which is the problem. >>>> There is a painful bug in the way the JVM handle epoll, and in certain >>>> conditions, it jump to 100% CPU and never goes down. It seems to be a >>>> problem when a connection is opened, and closed before the selector can >>>> see >>>> the close : the select() methods returns at least one selectedKey, but >>>> as >>>> the connection has been closed, it does nothing but loop again (as you >>>> can >>>> imagine, the loop is infinite). >>>> >>>> There is a fix for that, but it's experimental, in MINA branch >>>> http://svn.apache.org/repos/asf/mina/branches/select-fix/. I will >>>> commit >>>> this fix immediately in the MINA trunk, and you'll be able to bump up >>>> the >>>> MINA version to 2.0.0-RC2-SNAPSHOT in ADS. >>>> >>>> Not sure though that it's really your problem. >>>> >>>> >>>>> I've got an issue with an embedded instance of apacheds in a trivial >>>>> piece of java code. For reasons I have been unable to diagnose >>>>> so far, it will run happily for about a week or so, then it will >>>>> suddenly >>>>> ramp up the load on the server it's running on, with the only >>>>> way to recover it, being to delete the physical directory where the >>>>> records are stored and start from scratch. What's puzzling me is >>>>> that it's definitely not load related as the queries an operations to >>>>> LDAP are very lightweight and infrequent. What I do get in the logs >>>>> are loads of these >>>>> >>>>> >>>>> pool-4-thread-18 ERROR registries.DefaultAttributeTypeRegistry - >>>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>>> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >>>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>>> pool-4-thread-19 WARN context.SearchingOperationContext - Requested >>>>> attribute dn does not exist in the schema, it will be ignored >>>>> pool-4-thread-18 WARN context.SearchingOperationContext - Requested >>>>> attribute dn does not exist in the schema, it will be ignored >>>>> NioProcessor-2 WARN ldap.LdapProtocolHandler - Null LdapSession given >>>>> to >>>>> cleanUpSession. >>>>> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >>>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>>> pool-4-thread-17 ERROR registries.DefaultAttributeTypeRegistry - >>>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>>> >>>>> >>>>> and >>>>> >>>>> >>>>> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Unexpected exception >>>>> forcing session to close: sending disconnect notice to client. >>>>> java.lang.NullPointerException >>>>> at >>>>> >>>>> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:129) >>>>> at >>>>> >>>>> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) >>>>> at >>>>> >>>>> org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:232) >>>>> at >>>>> >>>>> org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:194) >>>>> at >>>>> >>>>> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:721) >>>>> at >>>>> >>>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:433) >>>>> at >>>>> >>>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47) >>>>> at >>>>> >>>>> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:801) >>>>> at >>>>> >>>>> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:71) >>>>> at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) >>>>> at >>>>> >>>>> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:480) >>>>> at >>>>> >>>>> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:434) >>>>> at java.lang.Thread.run(Thread.java:619) >>>>> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Null LdapSession >>>>> given >>>>> to cleanUpSession. >>>>> NioProcessor-3 WARN ldap.LdapProtocolHandler - Null LdapSession given >>>>> to >>>>> cleanUpSession. >>>>> >>>>> >>>>> The only thing I can think of causing the NPE's is a monitoring >>>>> application that we have, that connects and disconnects from ADS to >>>>> confirm >>>>> that it's still there...Apart from that I have no plausible explanation >>>>> for the high load. I'm currently using 1.5.6 compiled from source. >>>>> >>>>> Thanks, >>>>> >>>>> Yiannis >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> For more information please visit >>>> http://www.messagelabs.com/email______________________________________________________________________ >>>> >>>> >>> >>> >> >> -- >> Alex Karasulu >> My Blog :: http://www.jroller.com/akarasulu/ >> Apache Directory Server :: http://directory.apache.org >> Apache MINA :: http://mina.apache.org >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
Sure, I'll arrange this with our sysadm. Do you have anything particular in mind or will jvisualvm do? Y. On 10 Dec 2009, at 04:00, Alex Karasulu wrote: > It would be nice to run your server with a profiler to be able to > catch just > when it does get into this state. This would be very valuable since > we'd > see exactly where the code is getting stuck in this terrible loop > that eats > your CPU. > > You think you can give that a try Ioannis? If you can I'm sure we > can work > together to nip this bug quickly. > > Thanks, > Alex > > On Wed, Dec 9, 2009 at 11:04 AM, Ioannis Mavroukakis < > imavroukakis@gameaccount.com> wrote: > >> Hi Emmanuel, >> >> Don't think it is too, as the same behaviour persists when we shut >> down ADS >> and re-start it. Only clearing the ADS directory allows it to >> recover! I >> have kept the directory contents though, is there >> any way I can run any forensics on them ? >> >> Thanks, >> >> Y. >> >> On 9 Dec 2009, at 15:21, Emmanuel LŽcharny wrote: >> >> Ioannis Mavroukakis a écrit : >>> >>>> Hey fellow listers. >>>> >>> Hi Ioannis, >>> >>> if you get 100% loaded CPU the it might be MINA which is the >>> problem. >>> There is a painful bug in the way the JVM handle epoll, and in >>> certain >>> conditions, it jump to 100% CPU and never goes down. It seems to >>> be a >>> problem when a connection is opened, and closed before the >>> selector can see >>> the close : the select() methods returns at least one selectedKey, >>> but as >>> the connection has been closed, it does nothing but loop again (as >>> you can >>> imagine, the loop is infinite). >>> >>> There is a fix for that, but it's experimental, in MINA branch >>> http://svn.apache.org/repos/asf/mina/branches/select-fix/. I will >>> commit >>> this fix immediately in the MINA trunk, and you'll be able to bump >>> up the >>> MINA version to 2.0.0-RC2-SNAPSHOT in ADS. >>> >>> Not sure though that it's really your problem. >>> >>>> >>>> I've got an issue with an embedded instance of apacheds in a >>>> trivial >>>> piece of java code. For reasons I have been unable to diagnose >>>> so far, it will run happily for about a week or so, then it will >>>> suddenly >>>> ramp up the load on the server it's running on, with the only >>>> way to recover it, being to delete the physical directory where the >>>> records are stored and start from scratch. What's puzzling me is >>>> that it's definitely not load related as the queries an >>>> operations to >>>> LDAP are very lightweight and infrequent. What I do get in the logs >>>> are loads of these >>>> >>>> >>>> pool-4-thread-18 ERROR registries.DefaultAttributeTypeRegistry - >>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>> pool-4-thread-19 WARN context.SearchingOperationContext - >>>> Requested >>>> attribute dn does not exist in the schema, it will be ignored >>>> pool-4-thread-18 WARN context.SearchingOperationContext - >>>> Requested >>>> attribute dn does not exist in the schema, it will be ignored >>>> NioProcessor-2 WARN ldap.LdapProtocolHandler - Null LdapSession >>>> given to >>>> cleanUpSession. >>>> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>> pool-4-thread-17 ERROR registries.DefaultAttributeTypeRegistry - >>>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>>> >>>> >>>> and >>>> >>>> >>>> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Unexpected >>>> exception >>>> forcing session to close: sending disconnect notice to client. >>>> java.lang.NullPointerException >>>> at >>>> org >>>> .apache >>>> .directory >>>> .server >>>> .ldap >>>> .handlers >>>> .LdapRequestHandler.handleMessage(LdapRequestHandler.java:129) >>>> at >>>> org >>>> .apache >>>> .directory >>>> .server >>>> .ldap >>>> .handlers >>>> .LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) >>>> at >>>> org >>>> .apache >>>> .mina >>>> .handler >>>> .demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java: >>>> 232) >>>> at >>>> org >>>> .apache >>>> .directory >>>> .server >>>> .ldap >>>> .LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:194) >>>> at >>>> org.apache.mina.core.filterchain.DefaultIoFilterChain >>>> $TailFilter.messageReceived(DefaultIoFilterChain.java:721) >>>> at >>>> org >>>> .apache >>>> .mina >>>> .core >>>> .filterchain >>>> .DefaultIoFilterChain >>>> .callNextMessageReceived(DefaultIoFilterChain.java:433) >>>> at >>>> org.apache.mina.core.filterchain.DefaultIoFilterChain.access >>>> $1200(DefaultIoFilterChain.java:47) >>>> at >>>> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl >>>> $1.messageReceived(DefaultIoFilterChain.java:801) >>>> at >>>> org >>>> .apache >>>> .mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:71) >>>> at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) >>>> at >>>> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor >>>> $Worker.runTask(UnorderedThreadPoolExecutor.java:480) >>>> at >>>> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor >>>> $Worker.run(UnorderedThreadPoolExecutor.java:434) >>>> at java.lang.Thread.run(Thread.java:619) >>>> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Null >>>> LdapSession given >>>> to cleanUpSession. >>>> NioProcessor-3 WARN ldap.LdapProtocolHandler - Null LdapSession >>>> given to >>>> cleanUpSession. >>>> >>>> >>>> The only thing I can think of causing the NPE's is a monitoring >>>> application that we have, that connects and disconnects from ADS >>>> to confirm >>>> that it's still there...Apart from that I have no plausible >>>> explanation >>>> for the high load. I'm currently using 1.5.6 compiled from source. >>>> >>>> Thanks, >>>> >>>> Yiannis >>>> >>>> >>>> >>>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security >>> System. >>> For more information please visit http://www.messagelabs.com/email______________________________________________________________________ >>> >> >> > > > -- > Alex Karasulu > My Blog :: http://www.jroller.com/akarasulu/ > Apache Directory Server :: http://directory.apache.org > Apache MINA :: http://mina.apache.org > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________
It would be nice to run your server with a profiler to be able to catch just when it does get into this state. This would be very valuable since we'd see exactly where the code is getting stuck in this terrible loop that eats your CPU. You think you can give that a try Ioannis? If you can I'm sure we can work together to nip this bug quickly. Thanks, Alex On Wed, Dec 9, 2009 at 11:04 AM, Ioannis Mavroukakis < imavroukakis@gameaccount.com> wrote: > Hi Emmanuel, > > Don't think it is too, as the same behaviour persists when we shut down ADS > and re-start it. Only clearing the ADS directory allows it to recover! I > have kept the directory contents though, is there > any way I can run any forensics on them ? > > Thanks, > > Y. > > On 9 Dec 2009, at 15:21, Emmanuel LŽcharny wrote: > > Ioannis Mavroukakis a écrit : >> >>> Hey fellow listers. >>> >> Hi Ioannis, >> >> if you get 100% loaded CPU the it might be MINA which is the problem. >> There is a painful bug in the way the JVM handle epoll, and in certain >> conditions, it jump to 100% CPU and never goes down. It seems to be a >> problem when a connection is opened, and closed before the selector can see >> the close : the select() methods returns at least one selectedKey, but as >> the connection has been closed, it does nothing but loop again (as you can >> imagine, the loop is infinite). >> >> There is a fix for that, but it's experimental, in MINA branch >> http://svn.apache.org/repos/asf/mina/branches/select-fix/. I will commit >> this fix immediately in the MINA trunk, and you'll be able to bump up the >> MINA version to 2.0.0-RC2-SNAPSHOT in ADS. >> >> Not sure though that it's really your problem. >> >>> >>> I've got an issue with an embedded instance of apacheds in a trivial >>> piece of java code. For reasons I have been unable to diagnose >>> so far, it will run happily for about a week or so, then it will suddenly >>> ramp up the load on the server it's running on, with the only >>> way to recover it, being to delete the physical directory where the >>> records are stored and start from scratch. What's puzzling me is >>> that it's definitely not load related as the queries an operations to >>> LDAP are very lightweight and infrequent. What I do get in the logs >>> are loads of these >>> >>> >>> pool-4-thread-18 ERROR registries.DefaultAttributeTypeRegistry - >>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>> pool-4-thread-19 WARN context.SearchingOperationContext - Requested >>> attribute dn does not exist in the schema, it will be ignored >>> pool-4-thread-18 WARN context.SearchingOperationContext - Requested >>> attribute dn does not exist in the schema, it will be ignored >>> NioProcessor-2 WARN ldap.LdapProtocolHandler - Null LdapSession given to >>> cleanUpSession. >>> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>> pool-4-thread-17 ERROR registries.DefaultAttributeTypeRegistry - >>> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >>> >>> >>> and >>> >>> >>> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Unexpected exception >>> forcing session to close: sending disconnect notice to client. >>> java.lang.NullPointerException >>> at >>> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:129) >>> at >>> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) >>> at >>> org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:232) >>> at >>> org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:194) >>> at >>> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:721) >>> at >>> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:433) >>> at >>> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47) >>> at >>> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:801) >>> at >>> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:71) >>> at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) >>> at >>> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:480) >>> at >>> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:434) >>> at java.lang.Thread.run(Thread.java:619) >>> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Null LdapSession given >>> to cleanUpSession. >>> NioProcessor-3 WARN ldap.LdapProtocolHandler - Null LdapSession given to >>> cleanUpSession. >>> >>> >>> The only thing I can think of causing the NPE's is a monitoring >>> application that we have, that connects and disconnects from ADS to confirm >>> that it's still there...Apart from that I have no plausible explanation >>> for the high load. I'm currently using 1.5.6 compiled from source. >>> >>> Thanks, >>> >>> Yiannis >>> >>> >>> >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email______________________________________________________________________ >> > > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
Hi Emmanuel, Don't think it is too, as the same behaviour persists when we shut down ADS and re-start it. Only clearing the ADS directory allows it to recover! I have kept the directory contents though, is there any way I can run any forensics on them ? Thanks, Y. On 9 Dec 2009, at 15:21, Emmanuel LŽcharny wrote: > Ioannis Mavroukakis a écrit : >> Hey fellow listers. > Hi Ioannis, > > if you get 100% loaded CPU the it might be MINA which is the > problem. There is a painful bug in the way the JVM handle epoll, and > in certain conditions, it jump to 100% CPU and never goes down. It > seems to be a problem when a connection is opened, and closed before > the selector can see the close : the select() methods returns at > least one selectedKey, but as the connection has been closed, it > does nothing but loop again (as you can imagine, the loop is > infinite). > > There is a fix for that, but it's experimental, in MINA branch http://svn.apache.org/repos/asf/mina/branches/select-fix/ > . I will commit this fix immediately in the MINA trunk, and you'll > be able to bump up the MINA version to 2.0.0-RC2-SNAPSHOT in ADS. > > Not sure though that it's really your problem. >> >> I've got an issue with an embedded instance of apacheds in a >> trivial piece of java code. For reasons I have been unable to >> diagnose >> so far, it will run happily for about a week or so, then it will >> suddenly ramp up the load on the server it's running on, with the >> only >> way to recover it, being to delete the physical directory where the >> records are stored and start from scratch. What's puzzling me is >> that it's definitely not load related as the queries an operations >> to LDAP are very lightweight and infrequent. What I do get in the >> logs >> are loads of these >> >> >> pool-4-thread-18 ERROR registries.DefaultAttributeTypeRegistry - >> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >> pool-4-thread-19 WARN context.SearchingOperationContext - >> Requested attribute dn does not exist in the schema, it will be >> ignored >> pool-4-thread-18 WARN context.SearchingOperationContext - >> Requested attribute dn does not exist in the schema, it will be >> ignored >> NioProcessor-2 WARN ldap.LdapProtocolHandler - Null LdapSession >> given to cleanUpSession. >> pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - >> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >> pool-4-thread-17 ERROR registries.DefaultAttributeTypeRegistry - >> attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! >> >> >> and >> >> >> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Unexpected >> exception forcing session to close: sending disconnect notice to >> client. >> java.lang.NullPointerException >> at >> org >> .apache >> .directory >> .server >> .ldap >> .handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java: >> 129) >> at >> org >> .apache >> .directory >> .server >> .ldap >> .handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java: >> 56) >> at >> org >> .apache >> .mina >> .handler >> .demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:232) >> at >> org >> .apache >> .directory >> .server >> .ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java: >> 194) >> at org.apache.mina.core.filterchain.DefaultIoFilterChain >> $TailFilter.messageReceived(DefaultIoFilterChain.java:721) >> at >> org >> .apache >> .mina >> .core >> .filterchain >> .DefaultIoFilterChain >> .callNextMessageReceived(DefaultIoFilterChain.java:433) >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain.access >> $1200(DefaultIoFilterChain.java:47) >> at org.apache.mina.core.filterchain.DefaultIoFilterChain >> $EntryImpl$1.messageReceived(DefaultIoFilterChain.java:801) >> at >> org >> .apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java: >> 71) >> at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) >> at >> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor >> $Worker.runTask(UnorderedThreadPoolExecutor.java:480) >> at >> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor >> $Worker.run(UnorderedThreadPoolExecutor.java:434) >> at java.lang.Thread.run(Thread.java:619) >> pool-4-thread-19 WARN ldap.LdapProtocolHandler - Null LdapSession >> given to cleanUpSession. >> NioProcessor-3 WARN ldap.LdapProtocolHandler - Null LdapSession >> given to cleanUpSession. >> >> >> The only thing I can think of causing the NPE's is a monitoring >> application that we have, that connects and disconnects from ADS to >> confirm >> that it's still there...Apart from that I have no plausible >> explanation for the high load. I'm currently using 1.5.6 compiled >> from source. >> >> Thanks, >> >> Yiannis >> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________
Ioannis Mavroukakis a écrit : > Hey fellow listers. Hi Ioannis, if you get 100% loaded CPU the it might be MINA which is the problem. There is a painful bug in the way the JVM handle epoll, and in certain conditions, it jump to 100% CPU and never goes down. It seems to be a problem when a connection is opened, and closed before the selector can see the close : the select() methods returns at least one selectedKey, but as the connection has been closed, it does nothing but loop again (as you can imagine, the loop is infinite). There is a fix for that, but it's experimental, in MINA branch http://svn.apache.org/repos/asf/mina/branches/select-fix/. I will commit this fix immediately in the MINA trunk, and you'll be able to bump up the MINA version to 2.0.0-RC2-SNAPSHOT in ADS. Not sure though that it's really your problem. > > I've got an issue with an embedded instance of apacheds in a trivial > piece of java code. For reasons I have been unable to diagnose > so far, it will run happily for about a week or so, then it will > suddenly ramp up the load on the server it's running on, with the only > way to recover it, being to delete the physical directory where the > records are stored and start from scratch. What's puzzling me is > that it's definitely not load related as the queries an operations to > LDAP are very lightweight and infrequent. What I do get in the logs > are loads of these > > > pool-4-thread-18 ERROR registries.DefaultAttributeTypeRegistry - > attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! > pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - > attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! > pool-4-thread-19 WARN context.SearchingOperationContext - Requested > attribute dn does not exist in the schema, it will be ignored > pool-4-thread-18 WARN context.SearchingOperationContext - Requested > attribute dn does not exist in the schema, it will be ignored > NioProcessor-2 WARN ldap.LdapProtocolHandler - Null LdapSession given > to cleanUpSession. > pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry - > attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! > pool-4-thread-17 ERROR registries.DefaultAttributeTypeRegistry - > attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered! > > > and > > > pool-4-thread-19 WARN ldap.LdapProtocolHandler - Unexpected exception > forcing session to close: sending disconnect notice to client. > java.lang.NullPointerException > at > org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:129) > > at > org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) > > at > org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:232) > > at > org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:194) > > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:721) > > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:433) > > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47) > > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:801) > > at > org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:71) > > at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) > at > org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:480) > > at > org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:434) > > at java.lang.Thread.run(Thread.java:619) > pool-4-thread-19 WARN ldap.LdapProtocolHandler - Null LdapSession > given to cleanUpSession. > NioProcessor-3 WARN ldap.LdapProtocolHandler - Null LdapSession given > to cleanUpSession. > > > The only thing I can think of causing the NPE's is a monitoring > application that we have, that connects and disconnects from ADS to > confirm > that it's still there...Apart from that I have no plausible > explanation for the high load. I'm currently using 1.5.6 compiled from > source. > > Thanks, > > Yiannis > > >
It seems that the real problem is with the way we handle the uniqueMember AT. groupOfUniqueNames requires a uniqueMember and a cn groupOfNames requires a member and a cn. uniqueMember's Syntax is nameAndOptionalUID, when member's Syntax is DN. I will check what's going wrong with the nameAndOptionalUID's uniqueMemberMatch matchingrule. On Wed, Dec 9, 2009 at 1:04 PM, SCHEDENIG Marian < Marian.Schedenig@qualysoft.com> wrote: > > From: SCHEDENIG Marian [mailto:Marian.Schedenig@qualysoft.com] > > Sent: Freitag, 27. November 2009 15:50 > > > > Sorry for forgetting to mention the version: ApacheDS 1.5.5 (through > > Maven). > > Sorry for bumping my own thread, but can anyone shed some light on this? > > This fails with an exception: > (uniqueMember=uid=figaro,ou=users,o=infinica) > > But if I change my data model to use groupOfNames instead of > groupOfUniqueNames, the following query works fine: > (member=uid=figaro,ou=users,o=infinica) > > So it really seems to be a problem with groupOfUniqueNames. > > Thx, > Marian. > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Hey fellow listers.
I've got an issue with an embedded instance of apacheds in a trivial
piece of java code. For reasons I have been unable to diagnose
so far, it will run happily for about a week or so, then it will
suddenly ramp up the load on the server it's running on, with the only
way to recover it, being to delete the physical directory where the
records are stored and start from scratch. What's puzzling me is
that it's definitely not load related as the queries an operations to
LDAP are very lightweight and infrequent. What I do get in the logs
are loads of these
pool-4-thread-18 ERROR registries.DefaultAttributeTypeRegistry -
attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered!
pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry -
attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered!
pool-4-thread-19 WARN context.SearchingOperationContext - Requested
attribute dn does not exist in the schema, it will be ignored
pool-4-thread-18 WARN context.SearchingOperationContext - Requested
attribute dn does not exist in the schema, it will be ignored
NioProcessor-2 WARN ldap.LdapProtocolHandler - Null LdapSession given
to cleanUpSession.
pool-4-thread-19 ERROR registries.DefaultAttributeTypeRegistry -
attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered!
pool-4-thread-17 ERROR registries.DefaultAttributeTypeRegistry -
attributeType w/ OID 1.3.6.1.4.1.1466.115.121.1.12 not registered!
and
pool-4-thread-19 WARN ldap.LdapProtocolHandler - Unexpected exception
forcing session to close: sending disconnect notice to client.
java.lang.NullPointerException
at
org
.apache
.directory
.server
.ldap
.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:129)
at
org
.apache
.directory
.server
.ldap
.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
at
org
.apache
.mina
.handler
.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:232)
at
org
.apache
.directory
.server
.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:194)
at org.apache.mina.core.filterchain.DefaultIoFilterChain
$TailFilter.messageReceived(DefaultIoFilterChain.java:721)
at
org
.apache
.mina
.core
.filterchain
.DefaultIoFilterChain
.callNextMessageReceived(DefaultIoFilterChain.java:433)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access
$1200(DefaultIoFilterChain.java:47)
at org.apache.mina.core.filterchain.DefaultIoFilterChain
$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:801)
at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:
71)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor
$Worker.runTask(UnorderedThreadPoolExecutor.java:480)
at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor
$Worker.run(UnorderedThreadPoolExecutor.java:434)
at java.lang.Thread.run(Thread.java:619)
pool-4-thread-19 WARN ldap.LdapProtocolHandler - Null LdapSession
given to cleanUpSession.
NioProcessor-3 WARN ldap.LdapProtocolHandler - Null LdapSession given
to cleanUpSession.
The only thing I can think of causing the NPE's is a monitoring
application that we have, that connects and disconnects from ADS to
confirm
that it's still there...Apart from that I have no plausible
explanation for the high load. I'm currently using 1.5.6 compiled from
source.
Thanks,
Yiannis
> From: SCHEDENIG Marian [mailto:Marian.Schedenig@qualysoft.com] > Sent: Freitag, 27. November 2009 15:50 > > Sorry for forgetting to mention the version: ApacheDS 1.5.5 (through > Maven). Sorry for bumping my own thread, but can anyone shed some light on this? This fails with an exception: (uniqueMember=uid=figaro,ou=users,o=infinica) But if I change my data model to use groupOfNames instead of groupOfUniqueNames, the following query works fine: (member=uid=figaro,ou=users,o=infinica) So it really seems to be a problem with groupOfUniqueNames. Thx, Marian.
Hi Frank,
A very thorough email. Thanks for doing the work to make trouble shooting
this problem easier. I do however have one more think to ask of you. Let's
start ApacheDS in debug mode and setup the log4j.properties file so that the
frontend ldap wire protocol code is executing to see what's happening when
you hit it with httpd.
Just use the following log4j.properties file after backing up your original
configuration:
# --- start ---
log4j.rootCategory=WARN, stdout, R
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=apacheds-rolling.log
log4j.appender.R.MaxFileSize=1024KB
# Keep some backup files
log4j.appender.R.MaxBackupIndex=5
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=[%d{HH:mm:ss}] %p [%c] - %m%n
log4j.appender.stdout.layout.ConversionPattern=[%d{HH:mm:ss}] %p [%c] - %m%n
# with these we'll not get innundated when switching to DEBUG
log4j.logger.org.apache.directory.server.ldap.*=DEBUG
log4j.logger.org.springframework=WARN
log4j.logger.org.apache.directory.shared.codec=WARN
log4j.logger.org.apache.directory.shared.asn1=WARN
log4j.logger.org.apache.directory.server.schema.registries=WARN
#---- end ----
NOTE the following line ....
log4j.logger.org.apache.directory.server.ldap.*=DEBUG
When setup and ADS has restarted, hit the LDAPS port with httpd. Then send
me the logs so we can see if you're actually hitting the SSL port. This
configuration will also log output to a log file so if you loose data on the
screen don't worry it will be put into the apacheds-rolling.log file.
Send me the region of the logs where you're seeing the SSL port hit if at
all. Just as a test you might want to see what this looks like when you it
it with your client code which worked (right?).
Alex
On Tue, Dec 8, 2009 at 5:32 PM, Frank Rouse <plaidfarmer@gmail.com> wrote:
> I am having issues getting an Apache web server to authenticate users
> using the ldaps port of an ApacheDS server. I have been over and over
> these settings an I'm almost convinced that there is something simple,
> maybe hidden, that I am missing. I'm hoping the collective wisdom of
> the internet can succeed where I have failed. Any information would
> be appreciated.
>
> Environment
> Windows XP SP3
> Apache Web Server 2.2
> ApacheDS Server 1.5.5
>
> Current State
> 1. I can authenticate users from Apache using the unsecure ldap 10389
> port. Of course this means that userids/passwords are sent in
> plaintext.
> 2. I can connect to the secure ldap 10686 port with JExplorer client.
> It will prompt me to accept an SSL certificate. I have saved this
> certificate for later use.
> 3. I have written my own Java code that can access and modify ldap
> information using the secure 10686 port. In order for this code to
> work I have to import the SSL certificate I saved from JExplorer into
> my local jvm cacerts file.
> 4. There is an Openldap server that the Apache web server can
> authenticate users on the secure ldap port.
> 5. There is some text within the Apache web server error.log that
> states the following.
>
> LDAP: SSL support unavailable: LDAP: CA certificates cannot be set
> using this method, as they are stored in the registry instead.
>
> I looked into this and there was some reference to storing the
> certificate in windows registry using the certificate snap-in under
> mmc. I tried that and installed the certificate in the Certificates
> (Local Compter)->Trusted Root Certification Authorities->Certificates
> but nothing changed.
>
>
>
>
> Below are the relevant parts of my "server.xml" and "httpd.conf" files
> as well as part of the Apache Web Server error.log (there wasn't much
> useful information in the apacheds-rolling.log file).
>
> SERVER.XML
> <ldapServer id="ldapServer"
> allowAnonymousAccess="false"
> saslHost="ldap.example.com"
> saslPrincipal="ldap/ldap.example.com@EXAMPLE.COM"
> searchBaseDn="ou=users,ou=system"
> maxTimeLimit="15000"
> maxSizeLimit="1000"
> >
> <transports>
> <tcpTransport address="0.0.0.0" port="10389" nbThreads="8"
> backLog="50" enableSSL="false"/>
> <tcpTransport address="localhost" port="10686" enableSSL="true"/>
> </transports>
>
> <directoryService>#directoryService</directoryService>
>
> <!-- The list of supported authentication mechanisms.
> -->
> <saslMechanismHandlers>
> <simpleMechanismHandler mech-name="SIMPLE"/>
> <cramMd5MechanismHandler mech-name="CRAM-MD5" />
> <digestMd5MechanismHandler mech-name="DIGEST-MD5" />
> <gssapiMechanismHandler mech-name="GSSAPI" />
> <ntlmMechanismHandler mech-name="NTLM"
> ntlmProviderFqcn="com.foo.Bar"/>
> <ntlmMechanismHandler mech-name="GSS-SPNEGO"
> ntlmProviderFqcn="com.foo.Bar"/>
> </saslMechanismHandlers>
>
> <!-- The realms serviced by this SASL host, used by DIGEST-MD5 and
> GSSAPI. -->
> <saslRealms>
> <s:value>example.com</s:value>
> <s:value>apache.org</s:value>
> </saslRealms>
>
> <!-- the collection of extended operation handlers to install
> -->
> <extendedOperationHandlers>
> <startTlsHandler/>
> <gracefulShutdownHandler/>
> <launchDiagnosticUiHandler/>
> <!-- The Stored Procedure Extended Operation is not stable yet
> and it may cause security risks.-->
> <!--storedProcedureExtendedOperationHandler/-->
> </extendedOperationHandlers>
> </ldapServer>
>
> <apacheDS id="apacheDS">
> <ldapServer>#ldapServer</ldapServer>
> </apacheDS>
>
> HTTPS.CONF
>
> LDAPTrustedGlobalCert CA_DER "C:/Program Files/Apache Software
> Foundation/Apache2.2/certs/ApacheDS_9_28_2009_to_9_28_2010.der"
>
> <Directory "C:/Program Files/Apache Software
> Foundation/Apache2.2/htdocs/XXXXXX_Internal_FW_and_SW_Release_Repository">
> Order deny,allow
> Deny from All
> AuthType Basic
> AuthName "xxxxxx.com ldap"
> AuthBasicProvider ldap
> AuthLDAPUrl ldaps://localhost10:686/dc=xxxxxx,dc=com
> AuthzLDAPAuthoritative on
> AuthLDAPBindDN "cn=Frank Rouse,ou=Users,dc=xxxxxx,dc=com"
> AuthLDAPBindPassword xxxxxx
> Require valid-user
> Satisfy any
> </Directory>
>
> ERROR.LOG
>
> [Fri Dec 04 15:51:08 2009] [info] APR LDAP: Built with Microsoft
> Corporation. LDAP SDK
> [Fri Dec 04 15:51:08 2009] [info] LDAP: SSL support unavailable: LDAP:
> CA certificates cannot be set using this method, as they are stored in
> the registry instead.
> .
> .
> .
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
> 127.0.0.1] [4628] auth_ldap authenticate: using URL
> ldaps://localhost:10686/dc=sensus,dc=com
> [Tue Dec 08 16:13:58 2009] [warn] [client 127.0.0.1] [4628] auth_ldap
> authenticate: user frouse authentication failed; URI
> /Sensus_Internal_FW_and_SW_Release_Repository/ [LDAP:
> ldap_simple_bind_s() failed][Server Down]
>
> Thanks
> --
> Always look on the bright side of life.
> - M Python
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
I am having issues getting an Apache web server to authenticate users
using the ldaps port of an ApacheDS server. I have been over and over
these settings an I'm almost convinced that there is something simple,
maybe hidden, that I am missing. I'm hoping the collective wisdom of
the internet can succeed where I have failed. Any information would
be appreciated.
Environment
Windows XP SP3
Apache Web Server 2.2
ApacheDS Server 1.5.5
Current State
1. I can authenticate users from Apache using the unsecure ldap 10389
port. Of course this means that userids/passwords are sent in
plaintext.
2. I can connect to the secure ldap 10686 port with JExplorer client.
It will prompt me to accept an SSL certificate. I have saved this
certificate for later use.
3. I have written my own Java code that can access and modify ldap
information using the secure 10686 port. In order for this code to
work I have to import the SSL certificate I saved from JExplorer into
my local jvm cacerts file.
4. There is an Openldap server that the Apache web server can
authenticate users on the secure ldap port.
5. There is some text within the Apache web server error.log that
states the following.
LDAP: SSL support unavailable: LDAP: CA certificates cannot be set
using this method, as they are stored in the registry instead.
I looked into this and there was some reference to storing the
certificate in windows registry using the certificate snap-in under
mmc. I tried that and installed the certificate in the Certificates
(Local Compter)->Trusted Root Certification Authorities->Certificates
but nothing changed.
Below are the relevant parts of my "server.xml" and "httpd.conf" files
as well as part of the Apache Web Server error.log (there wasn't much
useful information in the apacheds-rolling.log file).
SERVER.XML
<ldapServer id="ldapServer"
allowAnonymousAccess="false"
saslHost="ldap.example.com"
saslPrincipal="ldap/ldap.example.com@EXAMPLE.COM"
searchBaseDn="ou=users,ou=system"
maxTimeLimit="15000"
maxSizeLimit="1000"
>
<transports>
<tcpTransport address="0.0.0.0" port="10389" nbThreads="8"
backLog="50" enableSSL="false"/>
<tcpTransport address="localhost" port="10686" enableSSL="true"/>
</transports>
<directoryService>#directoryService</directoryService>
<!-- The list of supported authentication mechanisms. -->
<saslMechanismHandlers>
<simpleMechanismHandler mech-name="SIMPLE"/>
<cramMd5MechanismHandler mech-name="CRAM-MD5" />
<digestMd5MechanismHandler mech-name="DIGEST-MD5" />
<gssapiMechanismHandler mech-name="GSSAPI" />
<ntlmMechanismHandler mech-name="NTLM" ntlmProviderFqcn="com.foo.Bar"/>
<ntlmMechanismHandler mech-name="GSS-SPNEGO"
ntlmProviderFqcn="com.foo.Bar"/>
</saslMechanismHandlers>
<!-- The realms serviced by this SASL host, used by DIGEST-MD5 and
GSSAPI. -->
<saslRealms>
<s:value>example.com</s:value>
<s:value>apache.org</s:value>
</saslRealms>
<!-- the collection of extended operation handlers to install -->
<extendedOperationHandlers>
<startTlsHandler/>
<gracefulShutdownHandler/>
<launchDiagnosticUiHandler/>
<!-- The Stored Procedure Extended Operation is not stable yet
and it may cause security risks.-->
<!--storedProcedureExtendedOperationHandler/-->
</extendedOperationHandlers>
</ldapServer>
<apacheDS id="apacheDS">
<ldapServer>#ldapServer</ldapServer>
</apacheDS>
HTTPS.CONF
LDAPTrustedGlobalCert CA_DER "C:/Program Files/Apache Software
Foundation/Apache2.2/certs/ApacheDS_9_28_2009_to_9_28_2010.der"
<Directory "C:/Program Files/Apache Software
Foundation/Apache2.2/htdocs/XXXXXX_Internal_FW_and_SW_Release_Repository">
Order deny,allow
Deny from All
AuthType Basic
AuthName "xxxxxx.com ldap"
AuthBasicProvider ldap
AuthLDAPUrl ldaps://localhost10:686/dc=xxxxxx,dc=com
AuthzLDAPAuthoritative on
AuthLDAPBindDN "cn=Frank Rouse,ou=Users,dc=xxxxxx,dc=com"
AuthLDAPBindPassword xxxxxx
Require valid-user
Satisfy any
</Directory>
ERROR.LOG
[Fri Dec 04 15:51:08 2009] [info] APR LDAP: Built with Microsoft
Corporation. LDAP SDK
[Fri Dec 04 15:51:08 2009] [info] LDAP: SSL support unavailable: LDAP:
CA certificates cannot be set using this method, as they are stored in
the registry instead.
.
.
.
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [debug] mod_authnz_ldap.c(377): [client
127.0.0.1] [4628] auth_ldap authenticate: using URL
ldaps://localhost:10686/dc=sensus,dc=com
[Tue Dec 08 16:13:58 2009] [warn] [client 127.0.0.1] [4628] auth_ldap
authenticate: user frouse authentication failed; URI
/Sensus_Internal_FW_and_SW_Release_Repository/ [LDAP:
ldap_simple_bind_s() failed][Server Down]
Thanks
--
Always look on the bright side of life.
- M Python
werner mueller a écrit : > Emmanuel LŽcharny schrieb: >> werner mueller a écrit : >>> hello >>> >>> I'm a little desparate at the moment: we had a server crash. after >>> rebooting the server i tried starting the apacheDS again but it >>> terminates with an Input/output error in the logs (see below). >>> >>> is there a way to repair the database or re-initialize it? >> The only way is to remove all the .db/.lg files and to reinject all >> the data into the server. In other words, starting back from a backup :/ >> >> We are working on a DSR system (Disaster Recovery System) in order to >> be able to restore a base when it has crashed like that, it will be >> present in 2.0. >> >> Sorry for the inconvenience ... >> >> > > hello > > thanks for the reply! > > i was a little scared because the backups where all hot copies of the > running server. but an older version did the job! the server came up > running again! > > it turned out the schema was broken in apacheds/data-default/schema/cn.db > that file could not even be copied anymore on the system itself (same > input/output error. FYI, the next version will have a ldif based schema, so it won't be possible to break it... We are currently working on that. > > can't wait for version 2.0 :-) So do I ! Glad you fixed your problem... -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Emmanuel LŽcharny schrieb: > werner mueller a écrit : >> hello >> >> I'm a little desparate at the moment: we had a server crash. after >> rebooting the server i tried starting the apacheDS again but it >> terminates with an Input/output error in the logs (see below). >> >> is there a way to repair the database or re-initialize it? > The only way is to remove all the .db/.lg files and to reinject all the > data into the server. In other words, starting back from a backup :/ > > We are working on a DSR system (Disaster Recovery System) in order to be > able to restore a base when it has crashed like that, it will be present > in 2.0. > > Sorry for the inconvenience ... > > hello thanks for the reply! i was a little scared because the backups where all hot copies of the running server. but an older version did the job! the server came up running again! it turned out the schema was broken in apacheds/data-default/schema/cn.db that file could not even be copied anymore on the system itself (same input/output error. can't wait for version 2.0 :-) best regards werner
werner mueller a écrit : > hello > > I'm a little desparate at the moment: we had a server crash. after > rebooting the server i tried starting the apacheDS again but it > terminates with an Input/output error in the logs (see below). > > is there a way to repair the database or re-initialize it? The only way is to remove all the .db/.lg files and to reinject all the data into the server. In other words, starting back from a backup :/ We are working on a DSR system (Disaster Recovery System) in order to be able to restore a base when it has crashed like that, it will be present in 2.0. Sorry for the inconvenience ...
hello
I'm a little desparate at the moment: we had a server crash. after
rebooting the server i tried starting the apacheDS again but it
terminates with an Input/output error in the logs (see below).
is there a way to repair the database or re-initialize it?
or is there another way?
we use apacheDS 1.5.4 with java 1.6 on Debian 4.0 (so far it was running
for months with no issues)
any tipps would be great!
thanks a lot
regards
werner
[23:40:16] DEBUG
[org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry]
- lookup with id2.5.4.3' of attributeType: <2.5.4.3, cn>
Exception in thread "main" java.io.IOException: Input/output error
at java.io.RandomAccessFile.readBytes(Native Method)
at java.io.RandomAccessFile.read(RandomAccessFile.java:322)
at jdbm.recman.RecordFile.read(RecordFile.java:402)
at jdbm.recman.RecordFile.get(RecordFile.java:160)
at
jdbm.recman.LogicalRowIdManager.fetch(LogicalRowIdManager.java:135)
at jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:337)
at jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:315)
at
jdbm.recman.BaseRecordManager.getNameDirectory(BaseRecordManager.java:457)
at
jdbm.recman.BaseRecordManager.getNamedObject(BaseRecordManager.java:393)
at
jdbm.recman.CacheRecordManager.getNamedObject(CacheRecordManager.java:370)
at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.<init>(JdbmTable.java:148)
at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.initTables(JdbmIndex.java:189)
at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.init(JdbmIndex.java:158)
at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmStore.setupUserIndices(JdbmStore.java:375)
at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmStore.init(JdbmStore.java:275)
at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.init(JdbmPartition.java:248)
at
org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1317)
at
org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:840)
at
org.apache.directory.server.configuration.ApacheDS.startup(ApacheDS.java:126)
at org.apache.directory.server.Service.init(Service.java:86)
at
org.apache.directory.server.UberjarMain.main(UberjarMain.java:56)
Craig Setera a écrit : > Are there any concerns with doing a directory "backup" by making a > copy of the contents of the partitions folder? Could this "backup" be > "restored" to a different directory server assuming that their > configuration is the same? Most certainly. If you don't have that many modifications, as each modification has a modification date, it should be possible to extract the latest mods since the last extraction, and apply them to a separate server. Although, it would be a tedious work to make it playing smoothly, and is really a workaround.
Craig Setera a écrit : > Does anyone have any experience building out a master/slave setup for > Apache DS (or any directory service)? Hi, as Kiran said, Mitosis was deadly bugged, and we deciced to remove the code from he server atm. We are working on writing a RFC 4533 replication based solution, giving our users the benefit of some proved replication system, as OpenLDAP has already implemented it. As an extra bonus, that will mean we will be able to replicate OpenLDAP and ApacheDS together. We don't have a timeline for this atm.
Hello, My company is looking at ApacheDS as a potential replacement for Active Directory as our primary authentication store and I had a couple of questions. What do most companies do for support related to ApacheDS? Are there any third party companies that provide ongoing support? Also, is it possible to support multi-master replication with ApacheDS? It is not clear from the documentation if this is supported or not. Thanks, Tim Carmical Platform Engineering Manager Phone: 301-228-7977 Cell: 240-344-9316
Are there any concerns with doing a directory "backup" by making a copy of the contents of the partitions folder? Could this "backup" be "restored" to a different directory server assuming that their configuration is the same? Thanks, Craig
Does anyone have any experience building out a master/slave setup for Apache DS (or any directory service)? Thanks again, Craig On 12/5/09 10:19 AM, Kiran Ayyagari wrote: > > hi Craig, > >> Hello, >> >> We are building a solution out around version 1.5.5 of Apache DS. As >> we've been developing the solution, I had assumed replication was >> working based on the commented-out sections in server.xml. Last >> night I came to the realization that Mitosis is "out" and that the >> team is moving to Syncrepl in the 2.0 timeframe. > > yes, syncrepl is going to be the replication system, mitosis is no > longer used and was removed > from code. >> >> While I see some of the syncrepl code in source control, am I correct >> in my assumption that it isn't in working condition in the 1.5.5 >> release? > yes, it was broken cause of various reasons (AFAICT refactoring of the > earlier code base was one reason) >> What option, if any, do we have for replication in version 1.5.5? Is >> there any way to bring mitosis "back to life" on top of 1.5.5? > am afraid, NO > > (I've >> read there were some problems in mitosis that might make it >> unsuitable for production use). At least in the short term a warm >> failover model (using master-slave replication) might be reasonable >> for us. Is there any way to set that up in 1.5.5 with what is >> available? > think no > > While it isn't >> my first choice, I'm in the process of completing a custom >> interceptor, so I suppose a replication interceptor (for >> master/slave) might also be an option. > yes > > HTH > Kiran Ayyagari
hi Craig, > Hello, > > We are building a solution out around version 1.5.5 of Apache DS. As > we've been developing the solution, I had assumed replication was > working based on the commented-out sections in server.xml. Last night I > came to the realization that Mitosis is "out" and that the team is > moving to Syncrepl in the 2.0 timeframe. yes, syncrepl is going to be the replication system, mitosis is no longer used and was removed from code. > > While I see some of the syncrepl code in source control, am I correct in > my assumption that it isn't in working condition in the 1.5.5 release? yes, it was broken cause of various reasons (AFAICT refactoring of the earlier code base was one reason) > What option, if any, do we have for replication in version 1.5.5? Is > there any way to bring mitosis "back to life" on top of 1.5.5? am afraid, NO (I've > read there were some problems in mitosis that might make it unsuitable > for production use). At least in the short term a warm failover model > (using master-slave replication) might be reasonable for us. Is there > any way to set that up in 1.5.5 with what is available? think no While it isn't > my first choice, I'm in the process of completing a custom interceptor, > so I suppose a replication interceptor (for master/slave) might also be > an option. yes HTH Kiran Ayyagari
Hello, We are building a solution out around version 1.5.5 of Apache DS. As we've been developing the solution, I had assumed replication was working based on the commented-out sections in server.xml. Last night I came to the realization that Mitosis is "out" and that the team is moving to Syncrepl in the 2.0 timeframe. While I see some of the syncrepl code in source control, am I correct in my assumption that it isn't in working condition in the 1.5.5 release? What option, if any, do we have for replication in version 1.5.5? Is there any way to bring mitosis "back to life" on top of 1.5.5? (I've read there were some problems in mitosis that might make it unsuitable for production use). At least in the short term a warm failover model (using master-slave replication) might be reasonable for us. Is there any way to set that up in 1.5.5 with what is available? While it isn't my first choice, I'm in the process of completing a custom interceptor, so I suppose a replication interceptor (for master/slave) might also be an option. I look forward to hearing any options that people might be able to provide. Thanks, Craig
Thank you sir, an appropriate fix :-) Downloaded 1.5.1 and it looks lovely. More excellent work from the Apache team. -Jason Stefan Seelmann wrote: > Hi Jason, > > Jason Hamilton wrote: > >> I'm new to the list so be gentle :-) > > Hey, we are always gentle :-) > >> I have no trouble manually applying an ldif or even via phpLDAPadmin >> to modify nisNetgroupTriple entries in my LDAP tree. When I attempt >> to add or modify then from Directory Studio I get the following: >> >> Error while executing LDIF >> - [LDAP: error code 18 - modify/add: nisNetgroupTriple: no equality >> matching rule] >> >> I'm running the latest build of Directory Studio 1.5 on x86_64, with >> OpenLDAP 2.4.18 on CentOS. I thought I heard murmurs on the Internet >> of a fix for this in studio at v1.5.5 but perhaps I dreamed that :-p > > Well, you are dreaming regarding "v1.5.5" because the newest version > is "v1.5.1" :-P > > To fix your issue you could change the "Modify Mode" for attributes > with "no equality matching rule" in the connection properties [1]. For > OpenLDAP you should use the option "Always REPLACE". > > Kind Regards, > Stefan > > [1]http://directory.apache.org/studio/static/users_guide/ldap_browser/tools_connection_properties.html#tools_connection_properties_edit_options > -- -Jason
Hi Jason, Jason Hamilton wrote: > I'm new to the list so be gentle :-) Hey, we are always gentle :-) > I have no trouble manually applying an ldif or even via phpLDAPadmin to > modify nisNetgroupTriple entries in my LDAP tree. When I attempt to add > or modify then from Directory Studio I get the following: > > Error while executing LDIF > - [LDAP: error code 18 - modify/add: nisNetgroupTriple: no equality > matching rule] > > I'm running the latest build of Directory Studio 1.5 on x86_64, with > OpenLDAP 2.4.18 on CentOS. I thought I heard murmurs on the Internet of > a fix for this in studio at v1.5.5 but perhaps I dreamed that :-p Well, you are dreaming regarding "v1.5.5" because the newest version is "v1.5.1" :-P To fix your issue you could change the "Modify Mode" for attributes with "no equality matching rule" in the connection properties [1]. For OpenLDAP you should use the option "Always REPLACE". Kind Regards, Stefan [1]http://directory.apache.org/studio/static/users_guide/ldap_browser/tools_connection_properties.html#tools_connection_properties_edit_options
Hi,
I'm new to the list so be gentle :-)
I have no trouble manually applying an ldif or even via phpLDAPadmin to
modify nisNetgroupTriple entries in my LDAP tree. When I attempt to add
or modify then from Directory Studio I get the following:
Error while executing LDIF
- [LDAP: error code 18 - modify/add: nisNetgroupTriple: no equality
matching rule]
javax.naming.directory.InvalidSearchFilterException: [LDAP: error code
18 - modify/add: nisNetgroupTriple: no equality matching rule];
remaining name 'cn=admin,ou=Netgroup,dc=simulexinc,dc=com'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3036)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2785)
at com.sun.jndi.ldap.LdapCtx.c_modifyAttributes(LdapCtx.java:1468)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_modifyAttributes(ComponentDirContext.java:273)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.modifyAttributes(PartialCompositeDirContext.java:190)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper$2.run(JNDIConnectionWrapper.java:454)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.runAndMonitor(JNDIConnectionWrapper.java:1272)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.checkConnectionAndRunAndMonitor(JNDIConnectionWrapper.java:1203)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.modifyEntry(JNDIConnectionWrapper.java:502)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifJob.importLdifRecord(ImportLdifJob.java:507)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifJob.importLdif(ImportLdifJob.java:267)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.run(ExecuteLdifRunnable.java:143)
at
org.apache.directory.studio.ldapbrowser.core.jobs.UpdateEntryRunnable.run(UpdateEntryRunnable.java:58)
at
org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:113)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
[LDAP: error code 18 - modify/add: nisNetgroupTriple: no equality
matching rule]
I'm running the latest build of Directory Studio 1.5 on x86_64, with
OpenLDAP 2.4.18 on CentOS. I thought I heard murmurs on the Internet of
a fix for this in studio at v1.5.5 but perhaps I dreamed that :-p
Any tips would be appreciated.
--
-Jason
The Apache Directory Team is pleased to announce the release of Apache Directory Studio 1.5.1, a bug fix and enhancement update of its Eclipse based LDAP Browser and Directory client. You can download Apache Directory Studio 1.5.1 as a standalone RCP application for Mac OS X, Linux and Windows here: http://directory.apache.org/studio/downloads.html You can install it directly in Eclipse using this update site: http://directory.apache.org/studio/update/1.x/ Here are a few highlights of this new version: * a bug where a modify operation could be sent to the server when refreshing the LDAP Browser view * correctly handling entries with a hash sign (#) in their DN * glitches and performance improvements in the UI * typos in the french translation Developed as a sub-project of the Directory Top Level Project, Apache Directory Studio is an Eclipse RCP application that takes full advantage of the benefits inherent in the Eclipse platform. Composed of several Eclipse (OSGi) plugins, Apache Directory Studio can be easily upgraded with additional plugins. Apache Directory Studio plugins can even run within a full installation of Eclipse itself. Apache Directory Studio contains 6 major features: * an LDAP Browser feature * an LDIF Editor feature * an ACI Editor feature for Apache Directory Server * a Schema Editor feature * an Apache DS feature * an Apache DS Configuration feature For more information about Apache Directory Studio, see our website: http://directory.apache.org/studio Below are the JIRA issues that were resolved since the release of Apache Directory Studio 1.5.0: * Bug - [DIRSTUDIO-576] - Context menu not shown after a right-click on a non-cached entry - [DIRSTUDIO-577] - LDIF editor doesn't notify Eclipse that the LDIF file has changed when saving - [DIRSTUDIO-580] - Setting "Validate certificates for secure LDAP connections" is not saved - [DIRSTUDIO-587] - UI flickers on quick search - [DIRSTUDIO-589] - InvalidNameException: unexpected token for user ids starting with hash sign - [DIRSTUDIO-590] - The 'Quick Search' string has not been externalized in the LDAP Browser view - [DIRSTUDIO-591] - Error reading objects with # in DN - [DIRSTUDIO-592] - LDAP Browser view is refreshed twice after the initialization of the children of an entry - [DIRSTUDIO-593] - Missing string and typo in the french translation of the Password Editor - [DIRSTUDIO-594] - The 'Show new password details' checkbox does not display the 'Enter new password' text field as clear text when checked in the Password Editor - [DIRSTUDIO-596] - Various typos in the french translation - [DIRSTUDIO-597] - Modification sent to the server while browsing through the DIT and refreshing entries - [DIRSTUDIO-598] - Base64 encoded DN marked as invalid in LDIF editor * Improvement - [DIRSTUDIO-595] - The icon of the entry in the 'Outline' view should be the same as the one in the 'LDAP Browser' view The Apache Directory Team
On Tue, Dec 1, 2009 at 8:30 AM, David R Robison < drrobison@openroadsconsulting.com> wrote: > Does Apache Directory Server support Virtual Directories? Not yet but it can easily be altered in the code to do so. > How would I expose my data through LDAP? You can have a partition implemented to show your data in your db as a branch in your DIT if you go with ApacheDS. Just write the partition to expose some hierarchy for your data after querying it and caching the db data. I can go into details if you like but we'd have to offline this conversation since it's a bit more specific to your situation rather than mainstream to this list. Alex > Thanks for the info. David > > > Alex Karasulu wrote: > >> On Mon, Nov 30, 2009 at 10:56 PM, David R Robison < >> drrobison@openroadsconsulting.com> wrote: >> >> >> >>> No, what are virtual directories? David >>> >>> >>> >>> >> http://en.wikipedia.org/wiki/Virtual_directory >> >> Sounds to me like you want to take data that you already have in a >> database >> and present it as LDAP to complete your directory. You may have put it >> there for proximity/performance sake but still need to have it presented >> via >> LDAP. A VD can help you do that. >> >> HTH, >> >> >> > > -- > > David R Robison > Open Roads Consulting, Inc. > 103 Watson Road, Chesapeake, VA 23320 > phone: (757) 546-3401 > e-mail: drrobison@openroadsconsulting.com > web: http://openroadsconsulting.com > blog: http://therobe.blogspot.com > book: > http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 > > This e-mail communication (including any attachments) may contain > confidential and/or privileged material intended solely for the individual > or entity to which it is addressed. If you are not the intended recipient, > you should immediately stop reading this message and delete it from all > computers that it resides on. Any unauthorized reading, distribution, > copying or other use of this communication (or its attachments) is strictly > prohibited. If you have received this communication in error, please notify > us immediately. > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
Does Apache Directory Server support Virtual Directories? How would I expose my data through LDAP? Thanks for the info. David Alex Karasulu wrote: > On Mon, Nov 30, 2009 at 10:56 PM, David R Robison < > drrobison@openroadsconsulting.com> wrote: > > >> No, what are virtual directories? David >> >> >> > http://en.wikipedia.org/wiki/Virtual_directory > > Sounds to me like you want to take data that you already have in a database > and present it as LDAP to complete your directory. You may have put it > there for proximity/performance sake but still need to have it presented via > LDAP. A VD can help you do that. > > HTH, > > -- David R Robison Open Roads Consulting, Inc. 103 Watson Road, Chesapeake, VA 23320 phone: (757) 546-3401 e-mail: drrobison@openroadsconsulting.com web: http://openroadsconsulting.com blog: http://therobe.blogspot.com book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 This e-mail communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. If you are not the intended recipient, you should immediately stop reading this message and delete it from all computers that it resides on. Any unauthorized reading, distribution, copying or other use of this communication (or its attachments) is strictly prohibited. If you have received this communication in error, please notify us immediately.
On Mon, Nov 30, 2009 at 10:56 PM, David R Robison < drrobison@openroadsconsulting.com> wrote: > No, what are virtual directories? David > > http://en.wikipedia.org/wiki/Virtual_directory Sounds to me like you want to take data that you already have in a database and present it as LDAP to complete your directory. You may have put it there for proximity/performance sake but still need to have it presented via LDAP. A VD can help you do that. HTH, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
No, what are virtual directories? David Alex Karasulu wrote: > You ever look into virtual directories? > > Alex > > On Mon, Nov 30, 2009 at 9:41 PM, David R Robison < > drrobison@openroadsconsulting.com> wrote: > > >> Thanks. Speaking of performance, we have records in our PostgreSQL database >> that references contacts in our LDAP. We want to do LFAP lookups as part of >> our database SQL calls. To do this we use a Perl lookup function but for >> large queries it is quite slow. If the records were already in a PostgreSQL >> database then we should be able to make better benefit of internal indexes >> and keys. Thanks again. David >> >> Emmanuel Lecharny wrote: >> >> >>> Hi, >>> >>> On Mon, Nov 30, 2009 at 11:06 PM, David R Robison >>> <drrobison@openroadsconsulting.com> wrote: >>> >>> >>> >>>> Is it possible (or are there plans) to use PostgreSQL as a backend >>>> database >>>> for Apache Directory Server? Thanks, David >>>> >>>> >>>> >>> Most certainly. We have an oracle backend being written by Andrea (see >>> the dev. ML on archives), it should be possible with some little >>> effort to port the code to Postgresql. We just need someone who has >>> time to do that. >>> >>> Note that I'm afraid the performance will be quite low... >>> >>> >>> >>> >> -- >> >> David R Robison >> Open Roads Consulting, Inc. >> 103 Watson Road, Chesapeake, VA 23320 >> phone: (757) 546-3401 >> e-mail: drrobison@openroadsconsulting.com >> web: http://openroadsconsulting.com >> blog: http://therobe.blogspot.com >> book: >> http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 >> >> This e-mail communication (including any attachments) may contain >> confidential and/or privileged material intended solely for the individual >> or entity to which it is addressed. If you are not the intended recipient, >> you should immediately stop reading this message and delete it from all >> computers that it resides on. Any unauthorized reading, distribution, >> copying or other use of this communication (or its attachments) is strictly >> prohibited. If you have received this communication in error, please notify >> us immediately. >> >> > > > > -- David R Robison Open Roads Consulting, Inc. 103 Watson Road, Chesapeake, VA 23320 phone: (757) 546-3401 e-mail: drrobison@openroadsconsulting.com web: http://openroadsconsulting.com blog: http://therobe.blogspot.com book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 This e-mail communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. If you are not the intended recipient, you should immediately stop reading this message and delete it from all computers that it resides on. Any unauthorized reading, distribution, copying or other use of this communication (or its attachments) is strictly prohibited. If you have received this communication in error, please notify us immediately.
You ever look into virtual directories? Alex On Mon, Nov 30, 2009 at 9:41 PM, David R Robison < drrobison@openroadsconsulting.com> wrote: > Thanks. Speaking of performance, we have records in our PostgreSQL database > that references contacts in our LDAP. We want to do LFAP lookups as part of > our database SQL calls. To do this we use a Perl lookup function but for > large queries it is quite slow. If the records were already in a PostgreSQL > database then we should be able to make better benefit of internal indexes > and keys. Thanks again. David > > Emmanuel Lecharny wrote: > >> Hi, >> >> On Mon, Nov 30, 2009 at 11:06 PM, David R Robison >> <drrobison@openroadsconsulting.com> wrote: >> >> >>> Is it possible (or are there plans) to use PostgreSQL as a backend >>> database >>> for Apache Directory Server? Thanks, David >>> >>> >> >> Most certainly. We have an oracle backend being written by Andrea (see >> the dev. ML on archives), it should be possible with some little >> effort to port the code to Postgresql. We just need someone who has >> time to do that. >> >> Note that I'm afraid the performance will be quite low... >> >> >> > > -- > > David R Robison > Open Roads Consulting, Inc. > 103 Watson Road, Chesapeake, VA 23320 > phone: (757) 546-3401 > e-mail: drrobison@openroadsconsulting.com > web: http://openroadsconsulting.com > blog: http://therobe.blogspot.com > book: > http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 > > This e-mail communication (including any attachments) may contain > confidential and/or privileged material intended solely for the individual > or entity to which it is addressed. If you are not the intended recipient, > you should immediately stop reading this message and delete it from all > computers that it resides on. Any unauthorized reading, distribution, > copying or other use of this communication (or its attachments) is strictly > prohibited. If you have received this communication in error, please notify > us immediately. > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
Thanks. Speaking of performance, we have records in our PostgreSQL database that references contacts in our LDAP. We want to do LFAP lookups as part of our database SQL calls. To do this we use a Perl lookup function but for large queries it is quite slow. If the records were already in a PostgreSQL database then we should be able to make better benefit of internal indexes and keys. Thanks again. David Emmanuel Lecharny wrote: > Hi, > > On Mon, Nov 30, 2009 at 11:06 PM, David R Robison > <drrobison@openroadsconsulting.com> wrote: > >> Is it possible (or are there plans) to use PostgreSQL as a backend database >> for Apache Directory Server? Thanks, David >> > > Most certainly. We have an oracle backend being written by Andrea (see > the dev. ML on archives), it should be possible with some little > effort to port the code to Postgresql. We just need someone who has > time to do that. > > Note that I'm afraid the performance will be quite low... > > -- David R Robison Open Roads Consulting, Inc. 103 Watson Road, Chesapeake, VA 23320 phone: (757) 546-3401 e-mail: drrobison@openroadsconsulting.com web: http://openroadsconsulting.com blog: http://therobe.blogspot.com book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 This e-mail communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. If you are not the intended recipient, you should immediately stop reading this message and delete it from all computers that it resides on. Any unauthorized reading, distribution, copying or other use of this communication (or its attachments) is strictly prohibited. If you have received this communication in error, please notify us immediately.
Hi, On Mon, Nov 30, 2009 at 11:06 PM, David R Robison <drrobison@openroadsconsulting.com> wrote: > Is it possible (or are there plans) to use PostgreSQL as a backend database > for Apache Directory Server? Thanks, David Most certainly. We have an oracle backend being written by Andrea (see the dev. ML on archives), it should be possible with some little effort to port the code to Postgresql. We just need someone who has time to do that. Note that I'm afraid the performance will be quite low... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Is it possible (or are there plans) to use PostgreSQL as a backend database for Apache Directory Server? Thanks, David -- David R Robison Open Roads Consulting, Inc. 103 Watson Road, Chesapeake, VA 23320 phone: (757) 546-3401 e-mail: drrobison@openroadsconsulting.com web: http://openroadsconsulting.com blog: http://therobe.blogspot.com book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526
If what you want to intercept is only the bind method you can just write
your own Authentication Interceptor or even you may just write your own
Authentication Method and integrate it into the existing Authentication
Interceptor.
Writing a partition makes sense when you want to control data storage as
well as taking advantage of the implemented services (as interceptors) such
as Access Control.
HTH,
On Mon, Nov 30, 2009 at 06:05, Jacques Oosthuizen <jacqueso@conor.co.za>wrote:
> I had a look at the interceptors, do you thing it will be better to write
> my
> own interceptor and not a partition ?
>
>
> On 2009/11/29 11:57 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
>
> > Well, the ultimate solution is to browse ApacheDS code in Eclipse and
> open
> > the type hierarchy for Interceptor interface. For all the classes in the
> > chain you need to check whether it overrides the bind method.
> >
> > A more advanced solution is to use AspectJ and analyzing all bind methods
> on
> > the fly.
> >
> > (I am currently unable to work on the code because I am not using my own
> > machine but in fact solving the problem is quite easy.)
> >
> > On Sun, Nov 29, 2009 at 17:54, Jacques Oosthuizen <jacqueso@conor.co.za
> >wrote:
> >
> >> Thanks for the help , I have removed the Autheniticator but my bind
> method
> >> still does not get called. I do see in the logs a lookup happening in
> the
> >> BindHandler and that it is failing because by dn for auth is not found.
> It
> >> is not calling my lookup in my partition. I am thinking of implementing
> my
> >> own BindHandler to handle this but that seems like too much work .
> >>
> >> On 2009/11/28 10:11 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
> >>
> >>> The interceptor's name should be AuthenticationInterceptor or
> >>> authenticationInterceptor.
> >>>
> >>> (You may just iterate over the interceptors and print their names.)
> >>>
> >>> On Sat, Nov 28, 2009 at 19:24, Jacques Oosthuizen <
> jacqueso@conor.co.za
> >>> wrote:
> >>>
> >>>> I still have tried to remove the interceptor like
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> directoryService.getInterceptorChain().remove("org.apache.directory.server.c
> >>>> ore.authn.AuthenticationInterceptor");
> >>>>
> >>>> I have also tried removing from actual list but if I print the list
> the
> >>>> interceptor is still there.
> >>>>
> >>>>
> >>>>
> >>>> On 2009/11/27 11:35 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
> >>>>
> >>>>> You need to call getInterceptorChain() if you really want to work
on
> >> the
> >>>>> chain. getInterceptors() just returns a clone of it. And removing
the
> >>>>> default Authn interceptor should really help, because it obviously
> >>>> prevents
> >>>>> the bind call being forwarded in the chain. (I just checked the
> code.)
> >>>>>
> >>>>> HTH,
> >>>>>
> >>>>> On Fri, Nov 27, 2009 at 15:12, Jacques Oosthuizen <
> >> jacqueso@conor.co.za
> >>>>> wrote:
> >>>>>
> >>>>>> Still not having luck , even if I remove the default authenticator
> >>>>>>
> >>>>>> List<Interceptor> interceptors =
> directoryService.getInterceptors();
> >>>>>> Iterator<Interceptor> iter = interceptors.iterator();
> >>>>>> while (iter.hasNext()) {
> >>>>>> Interceptor next = iter.next();
> >>>>>>
> >>>>>> if (next instanceof
> >>>>>> org.apache.directory.server.core.authn.AuthenticationInterceptor)
> >>>>>> {
> >>>>>>
> >>>>>> interceptors.remove(next);
> >>>>>> break;
> >>>>>> }
> >>>>>>
> >>>>>> }
> >>>>>>
> >>>>>> But my bind in my partition still does not get called . Any
help
> will
> >> be
> >>>>>> appreciated
> >>>>>>
> >>>>>> Jacques Oosthuizen
> >>>>>> Conor Information Technologies
> >>>>>> Director
> >>>>>> mobile : 0827699138
> >>>>>> web : http://www.conor.co.za
> >>>>>> mail : jacqueso@conor.co.za
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> Jacques Oosthuizen
> >>>> Conor Information Technologies
> >>>> Director
> >>>> mobile : 0827699138
> >>>> web : http://www.conor.co.za
> >>>> mail : jacqueso@conor.co.za
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> Jacques Oosthuizen
> >> Conor Information Technologies
> >> Director
> >> mobile : 0827699138
> >> web : http://www.conor.co.za
> >> mail : jacqueso@conor.co.za
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> Jacques Oosthuizen
> Conor Information Technologies
> Director
> mobile : 0827699138
> web : http://www.conor.co.za
> mail : jacqueso@conor.co.za
>
>
>
>
>
>
>
--
Ersin ER
http://www.ersiner.net
I had a look at the interceptors, do you thing it will be better to write my
own interceptor and not a partition ?
On 2009/11/29 11:57 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
> Well, the ultimate solution is to browse ApacheDS code in Eclipse and open
> the type hierarchy for Interceptor interface. For all the classes in the
> chain you need to check whether it overrides the bind method.
>
> A more advanced solution is to use AspectJ and analyzing all bind methods on
> the fly.
>
> (I am currently unable to work on the code because I am not using my own
> machine but in fact solving the problem is quite easy.)
>
> On Sun, Nov 29, 2009 at 17:54, Jacques Oosthuizen <jacqueso@conor.co.za>wrote:
>
>> Thanks for the help , I have removed the Autheniticator but my bind method
>> still does not get called. I do see in the logs a lookup happening in the
>> BindHandler and that it is failing because by dn for auth is not found. It
>> is not calling my lookup in my partition. I am thinking of implementing my
>> own BindHandler to handle this but that seems like too much work .
>>
>> On 2009/11/28 10:11 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
>>
>>> The interceptor's name should be AuthenticationInterceptor or
>>> authenticationInterceptor.
>>>
>>> (You may just iterate over the interceptors and print their names.)
>>>
>>> On Sat, Nov 28, 2009 at 19:24, Jacques Oosthuizen <jacqueso@conor.co.za
>>> wrote:
>>>
>>>> I still have tried to remove the interceptor like
>>>>
>>>>
>>>>
>>>>
>> directoryService.getInterceptorChain().remove("org.apache.directory.server.c
>>>> ore.authn.AuthenticationInterceptor");
>>>>
>>>> I have also tried removing from actual list but if I print the list the
>>>> interceptor is still there.
>>>>
>>>>
>>>>
>>>> On 2009/11/27 11:35 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
>>>>
>>>>> You need to call getInterceptorChain() if you really want to work on
>> the
>>>>> chain. getInterceptors() just returns a clone of it. And removing the
>>>>> default Authn interceptor should really help, because it obviously
>>>> prevents
>>>>> the bind call being forwarded in the chain. (I just checked the code.)
>>>>>
>>>>> HTH,
>>>>>
>>>>> On Fri, Nov 27, 2009 at 15:12, Jacques Oosthuizen <
>> jacqueso@conor.co.za
>>>>> wrote:
>>>>>
>>>>>> Still not having luck , even if I remove the default authenticator
>>>>>>
>>>>>> List<Interceptor> interceptors = directoryService.getInterceptors();
>>>>>> Iterator<Interceptor> iter = interceptors.iterator();
>>>>>> while (iter.hasNext()) {
>>>>>> Interceptor next = iter.next();
>>>>>>
>>>>>> if (next instanceof
>>>>>> org.apache.directory.server.core.authn.AuthenticationInterceptor)
>>>>>> {
>>>>>>
>>>>>> interceptors.remove(next);
>>>>>> break;
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> But my bind in my partition still does not get called . Any help
will
>> be
>>>>>> appreciated
>>>>>>
>>>>>> Jacques Oosthuizen
>>>>>> Conor Information Technologies
>>>>>> Director
>>>>>> mobile : 0827699138
>>>>>> web : http://www.conor.co.za
>>>>>> mail : jacqueso@conor.co.za
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Jacques Oosthuizen
>>>> Conor Information Technologies
>>>> Director
>>>> mobile : 0827699138
>>>> web : http://www.conor.co.za
>>>> mail : jacqueso@conor.co.za
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> Jacques Oosthuizen
>> Conor Information Technologies
>> Director
>> mobile : 0827699138
>> web : http://www.conor.co.za
>> mail : jacqueso@conor.co.za
>>
>>
>>
>>
>>
>>
>>
>
Jacques Oosthuizen
Conor Information Technologies
Director
mobile : 0827699138
web : http://www.conor.co.za
mail : jacqueso@conor.co.za
Well, the ultimate solution is to browse ApacheDS code in Eclipse and open
the type hierarchy for Interceptor interface. For all the classes in the
chain you need to check whether it overrides the bind method.
A more advanced solution is to use AspectJ and analyzing all bind methods on
the fly.
(I am currently unable to work on the code because I am not using my own
machine but in fact solving the problem is quite easy.)
On Sun, Nov 29, 2009 at 17:54, Jacques Oosthuizen <jacqueso@conor.co.za>wrote:
> Thanks for the help , I have removed the Autheniticator but my bind method
> still does not get called. I do see in the logs a lookup happening in the
> BindHandler and that it is failing because by dn for auth is not found. It
> is not calling my lookup in my partition. I am thinking of implementing my
> own BindHandler to handle this but that seems like too much work .
>
> On 2009/11/28 10:11 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
>
> > The interceptor's name should be AuthenticationInterceptor or
> > authenticationInterceptor.
> >
> > (You may just iterate over the interceptors and print their names.)
> >
> > On Sat, Nov 28, 2009 at 19:24, Jacques Oosthuizen <jacqueso@conor.co.za
> >wrote:
> >
> >> I still have tried to remove the interceptor like
> >>
> >>
> >>
> >>
> directoryService.getInterceptorChain().remove("org.apache.directory.server.c
> >> ore.authn.AuthenticationInterceptor");
> >>
> >> I have also tried removing from actual list but if I print the list the
> >> interceptor is still there.
> >>
> >>
> >>
> >> On 2009/11/27 11:35 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
> >>
> >>> You need to call getInterceptorChain() if you really want to work on
> the
> >>> chain. getInterceptors() just returns a clone of it. And removing the
> >>> default Authn interceptor should really help, because it obviously
> >> prevents
> >>> the bind call being forwarded in the chain. (I just checked the code.)
> >>>
> >>> HTH,
> >>>
> >>> On Fri, Nov 27, 2009 at 15:12, Jacques Oosthuizen <
> jacqueso@conor.co.za
> >>> wrote:
> >>>
> >>>> Still not having luck , even if I remove the default authenticator
> >>>>
> >>>> List<Interceptor> interceptors = directoryService.getInterceptors();
> >>>> Iterator<Interceptor> iter = interceptors.iterator();
> >>>> while (iter.hasNext()) {
> >>>> Interceptor next = iter.next();
> >>>>
> >>>> if (next instanceof
> >>>> org.apache.directory.server.core.authn.AuthenticationInterceptor)
> >>>> {
> >>>>
> >>>> interceptors.remove(next);
> >>>> break;
> >>>> }
> >>>>
> >>>> }
> >>>>
> >>>> But my bind in my partition still does not get called . Any help will
> be
> >>>> appreciated
> >>>>
> >>>> Jacques Oosthuizen
> >>>> Conor Information Technologies
> >>>> Director
> >>>> mobile : 0827699138
> >>>> web : http://www.conor.co.za
> >>>> mail : jacqueso@conor.co.za
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> Jacques Oosthuizen
> >> Conor Information Technologies
> >> Director
> >> mobile : 0827699138
> >> web : http://www.conor.co.za
> >> mail : jacqueso@conor.co.za
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> Jacques Oosthuizen
> Conor Information Technologies
> Director
> mobile : 0827699138
> web : http://www.conor.co.za
> mail : jacqueso@conor.co.za
>
>
>
>
>
>
>
--
Ersin ER
http://www.ersiner.net
Thanks for the help , I have removed the Autheniticator but my bind method
still does not get called. I do see in the logs a lookup happening in the
BindHandler and that it is failing because by dn for auth is not found. It
is not calling my lookup in my partition. I am thinking of implementing my
own BindHandler to handle this but that seems like too much work .
On 2009/11/28 10:11 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
> The interceptor's name should be AuthenticationInterceptor or
> authenticationInterceptor.
>
> (You may just iterate over the interceptors and print their names.)
>
> On Sat, Nov 28, 2009 at 19:24, Jacques Oosthuizen <jacqueso@conor.co.za>wrote:
>
>> I still have tried to remove the interceptor like
>>
>>
>>
>> directoryService.getInterceptorChain().remove("org.apache.directory.server.c
>> ore.authn.AuthenticationInterceptor");
>>
>> I have also tried removing from actual list but if I print the list the
>> interceptor is still there.
>>
>>
>>
>> On 2009/11/27 11:35 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
>>
>>> You need to call getInterceptorChain() if you really want to work on the
>>> chain. getInterceptors() just returns a clone of it. And removing the
>>> default Authn interceptor should really help, because it obviously
>> prevents
>>> the bind call being forwarded in the chain. (I just checked the code.)
>>>
>>> HTH,
>>>
>>> On Fri, Nov 27, 2009 at 15:12, Jacques Oosthuizen <jacqueso@conor.co.za
>>> wrote:
>>>
>>>> Still not having luck , even if I remove the default authenticator
>>>>
>>>> List<Interceptor> interceptors = directoryService.getInterceptors();
>>>> Iterator<Interceptor> iter = interceptors.iterator();
>>>> while (iter.hasNext()) {
>>>> Interceptor next = iter.next();
>>>>
>>>> if (next instanceof
>>>> org.apache.directory.server.core.authn.AuthenticationInterceptor)
>>>> {
>>>>
>>>> interceptors.remove(next);
>>>> break;
>>>> }
>>>>
>>>> }
>>>>
>>>> But my bind in my partition still does not get called . Any help will be
>>>> appreciated
>>>>
>>>> Jacques Oosthuizen
>>>> Conor Information Technologies
>>>> Director
>>>> mobile : 0827699138
>>>> web : http://www.conor.co.za
>>>> mail : jacqueso@conor.co.za
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> Jacques Oosthuizen
>> Conor Information Technologies
>> Director
>> mobile : 0827699138
>> web : http://www.conor.co.za
>> mail : jacqueso@conor.co.za
>>
>>
>>
>>
>>
>>
>>
>
Jacques Oosthuizen
Conor Information Technologies
Director
mobile : 0827699138
web : http://www.conor.co.za
mail : jacqueso@conor.co.za
The interceptor's name should be AuthenticationInterceptor or
authenticationInterceptor.
(You may just iterate over the interceptors and print their names.)
On Sat, Nov 28, 2009 at 19:24, Jacques Oosthuizen <jacqueso@conor.co.za>wrote:
> I still have tried to remove the interceptor like
>
>
>
> directoryService.getInterceptorChain().remove("org.apache.directory.server.c
> ore.authn.AuthenticationInterceptor");
>
> I have also tried removing from actual list but if I print the list the
> interceptor is still there.
>
>
>
> On 2009/11/27 11:35 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
>
> > You need to call getInterceptorChain() if you really want to work on the
> > chain. getInterceptors() just returns a clone of it. And removing the
> > default Authn interceptor should really help, because it obviously
> prevents
> > the bind call being forwarded in the chain. (I just checked the code.)
> >
> > HTH,
> >
> > On Fri, Nov 27, 2009 at 15:12, Jacques Oosthuizen <jacqueso@conor.co.za
> >wrote:
> >
> >> Still not having luck , even if I remove the default authenticator
> >>
> >> List<Interceptor> interceptors = directoryService.getInterceptors();
> >> Iterator<Interceptor> iter = interceptors.iterator();
> >> while (iter.hasNext()) {
> >> Interceptor next = iter.next();
> >>
> >> if (next instanceof
> >> org.apache.directory.server.core.authn.AuthenticationInterceptor)
> >> {
> >>
> >> interceptors.remove(next);
> >> break;
> >> }
> >>
> >> }
> >>
> >> But my bind in my partition still does not get called . Any help will be
> >> appreciated
> >>
> >> Jacques Oosthuizen
> >> Conor Information Technologies
> >> Director
> >> mobile : 0827699138
> >> web : http://www.conor.co.za
> >> mail : jacqueso@conor.co.za
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> Jacques Oosthuizen
> Conor Information Technologies
> Director
> mobile : 0827699138
> web : http://www.conor.co.za
> mail : jacqueso@conor.co.za
>
>
>
>
>
>
>
--
Ersin ER
http://www.ersiner.net
Ersin ER wrote: > One of the strengths of ApacheDS is its embeddable architecture. It's also > very modular so that you can even turn it into something really different > from an LDAP server. > > In order to embed it into your own app, you can check: > > http://directory.apache.org/apacheds/1.5/41-embedding-apacheds-into-an-application.html I just updated the page for ApacheDS 1.5.5. It should visible within the next hour. > You may also check the startup scripts installed with the distribution > package to see how it's started with java -jar ... Another option is to download the zip or tar.gz archive. It contains a simple start scirpt (apacheds.sh or apacheds.bat) where you could see how it is started with java -jar. > 2009/11/28 Darko Hojnik <hojnik@virtualizing.org> >> It is possible to ApacheDS with another Wrapper? Maybe with JSVC. Starts as >> Root runs as User. To get them on Port 389. I think the recommended approach is to use port forwarding from 389 to 10389: http://mail-archives.apache.org/mod_mbox/directory-users/200805.mbox/%3Ca32f6b020805220904r1fd4f820s8f026494e785b273@mail.gmail.com%3E Kind Regards, Stefan
I still have tried to remove the interceptor like
directoryService.getInterceptorChain().remove("org.apache.directory.server.c
ore.authn.AuthenticationInterceptor");
I have also tried removing from actual list but if I print the list the
interceptor is still there.
On 2009/11/27 11:35 PM, "Ersin ER" <ersin.er@gmail.com> wrote:
> You need to call getInterceptorChain() if you really want to work on the
> chain. getInterceptors() just returns a clone of it. And removing the
> default Authn interceptor should really help, because it obviously prevents
> the bind call being forwarded in the chain. (I just checked the code.)
>
> HTH,
>
> On Fri, Nov 27, 2009 at 15:12, Jacques Oosthuizen <jacqueso@conor.co.za>wrote:
>
>> Still not having luck , even if I remove the default authenticator
>>
>> List<Interceptor> interceptors = directoryService.getInterceptors();
>> Iterator<Interceptor> iter = interceptors.iterator();
>> while (iter.hasNext()) {
>> Interceptor next = iter.next();
>>
>> if (next instanceof
>> org.apache.directory.server.core.authn.AuthenticationInterceptor)
>> {
>>
>> interceptors.remove(next);
>> break;
>> }
>>
>> }
>>
>> But my bind in my partition still does not get called . Any help will be
>> appreciated
>>
>> Jacques Oosthuizen
>> Conor Information Technologies
>> Director
>> mobile : 0827699138
>> web : http://www.conor.co.za
>> mail : jacqueso@conor.co.za
>>
>>
>>
>>
>>
>>
>
Jacques Oosthuizen
Conor Information Technologies
Director
mobile : 0827699138
web : http://www.conor.co.za
mail : jacqueso@conor.co.za