[ https://issues.apache.org/jira/browse/DIRSTUDIO-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665378#comment-13665378
]
cj little commented on DIRSTUDIO-864:
-------------------------------------
I seem to be having the same issue with fresh (<2 days old) installs of both.
Using a default ApacheDS-2.0.0-M12 instance on Ubuntu + ApacheDirectoryStudio-macosx-x86_64-2.0.0.v20130308.dmg
on OSX ML.
> Error message appears: "ERR_04269 ATTRIBUTE_TYPE for OID ads-replenabled does not exist!"
when trying to open configuration
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-864
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-864
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-apacheds-configuration
> Affects Versions: 2.0.0-M3
> Environment: Windows 7 Home Basic, Service Pack 1, 32-bit,
> java version "1.7.0_11"
> Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
> Java HotSpot(TM) Client VM (build 23.6-b04, mixed mode, sharing)
> also:
> Windows 7 Enterprise, Service Pack 1, 64-bit,
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
> Reporter: Oleksij Lupandin
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0-M4, 2.0.0
>
>
> 1. Choose main menu — LDAP — Schema Browser.
> 2. Open tab Attribute Types.
> The list contains attribute "ads-replEnabled".
> 3. Choose a server in pane "Connections", right-click it and choose Open Configuration.
> Expected result:
> Configuration window opens.
> Actual result:
> The following exception is thrown:
> org.apache.directory.shared.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269
ATTRIBUTE_TYPE for OID ads-replenabled does not exist!
> at org.apache.directory.shared.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:317)
> at org.apache.directory.shared.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
> at org.apache.directory.shared.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1620)
> at org.apache.directory.shared.ldap.model.entry.DefaultEntry.<init>(DefaultEntry.java:310)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.readConfiguration(LoadConfigurationRunnable.java:358)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.getConfiguration(LoadConfigurationRunnable.java:182)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.run(LoadConfigurationRunnable.java:127)
> at org.apache.directory.studio.common.core.jobs.StudioJob.run(StudioJob.java:83)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.apache.directory.shared.ldap.model.exception.LdapException: ERR_04269
ATTRIBUTE_TYPE for OID ads-replenabled does not exist!
> at org.apache.directory.shared.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
> at org.apache.directory.shared.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:313)
> ... 8 more
> I suppose that Apache Directory Studio should search "ads-replEnabled" type, but searches
"ads-replenabled" instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665263#comment-13665263
]
Michael Witzel commented on DIRSERVER-1830:
-------------------------------------------
It seems that pwdMaxAge set as user attribute is also not working with connection pool. Would
be nice, if that could be fixed, because we go live soon.
> when ads-pwdMaxIdle > 0 no more authentication possible
> -------------------------------------------------------
>
> Key: DIRSERVER-1830
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1830
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 2.0.0-M11
> Environment: CentOS
> Reporter: Michael Witzel
>
> when I configure ads-pwdMaxIdle > 0 no authentication is possible, neither with admin,
nor with other users
> Eclipse Studio:
> Fehler beim Öffnen der Verbindung
> - [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate
user uid=admin,ou=system]
> java.lang.Exception: [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229
Cannot authenticate user uid=admin,ou=system]
> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279)
> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109)
> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:450)
> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1174)
> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:459)
> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:307)
> at org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
> [LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate
user uid=admin,ou=system]
> wrapper.log
> INFO | jvm 1 | 2013/04/18 14:24:06 | [14:24:06] ERROR
> [org.apache.directory.server.ldap.handlers.request.UnbindRequestHandler] - ERR_169 failed
to unbind session properly
> INFO | jvm 1 | 2013/04/18 14:24:06 | org.apache.directory.api.ldap.model.exception.LdapNoSuchObjectException:
ERR_268 Cannot find a partition for
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.getPartition(DefaultPartitionNexus.java:927)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.unbind(DefaultPartitionNexus.java:794)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.unbind(BaseInterceptor.java:266)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:690)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.authn.AuthenticationInterceptor.unbind(AuthenticationInterceptor.java:1159)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.DefaultOperationManager.unbind(DefaultOperationManager.java:1230)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.core.shared.DefaultCoreSession.unbind(DefaultCoreSession.java:1073)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.ldap.handlers.request.UnbindRequestHandler.handle(UnbindRequestHandler.java:50)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.ldap.handlers.request.UnbindRequestHandler.handle(UnbindRequestHandler.java:38)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:219)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:690)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:474)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:428)
> INFO | jvm 1 | 2013/04/18 14:24:06 | at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
sir use Apache Directory Studio LDAP Browser 2.0.0.v20130308 org.apache.directory.studio.ldapbrowser.feature.feature.group On Thu, May 23, 2013 at 7:12 PM, Pierre-Arnaud Marcelot <pa@marcelot.net>wrote: > This problem is totally independent of the other one. > > There's a bug in the current version available in the update which make > the update site fail. > > A new version fixing this issue is currently being voted on this mailing > list and should be out soon. > > In the meantime you can download and use the RCP application instead of > installing the plugins inside Eclipse. > > Regards, > Pierre-Arnaud > > > On 23 mai 2013, at 15:31, rahul bhalla <urcoolfriend18@gmail.com> wrote: > > when i tried to install mention plugins > > Apache Directory Studio Apache DS Configuration 2.0.0.v20130308 > org.apache.directory.studio.apacheds.configuration.feature.feature.group > Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 > org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group > Apache Directory Studio LDAP Browser 2.0.0.v20130308 > org.apache.directory.studio.ldapbrowser.feature.feature.group > Apache Directory Studio LDAP Servers 2.0.0.v20130308 > org.apache.directory.studio.ldapservers.feature.feature.group > Apache Directory Studio LDIF Editor 2.0.0.v20130308 > org.apache.directory.studio.ldifeditor.feature.feature.group > Apache Directory Studio RCP 2.0.0.v20130308 > org.apache.directory.studio.rcp.feature.feature.group > Apache Directory Studio Schema Editor 2.0.0.v20130308 > org.apache.directory.studio.schemaeditor.feature.feature.group > it gives > Cannot complete the install because one or more required items could not > be found. > Software currently installed: Apache Directory Studio ApacheDS 2.0 > Configuration 2.0.0.v20130308 > (org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group > 2.0.0.v20130308) > Missing requirement: ApacheDS Core 2.0.0.M11 > (org.apache.directory.server.core 2.0.0.M11) requires 'package > org.apache.directory.server.core.admin [2.0.0,3.0.0)' but it could not be > found > Cannot satisfy dependency: > From: Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 > (org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group > 2.0.0.v20130308) > To: org.apache.directory.serve > > > On Thu, May 23, 2013 at 6:59 PM, rahul bhalla <urcoolfriend18@gmail.com>wrote: > >> >> Sir Can you please tell me what is required first in order to run user >> ldap >> I have only eciplse juno and i only install *LDAP Browser* plug-in. >> After what more is required >> and thnks for the reply >> >> >> >> On Thu, May 23, 2013 at 6:54 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote: >> >>> Le 5/23/13 3:16 PM, rahul bhalla a écrit : >>> > Sir only install ldap Browser plugin >>> >>> How can you connect to a LDAP server if you don't have one running ? >>> As you've got a response, you necessarily have a LDAP server running, >>> and we need to know which one it is. >>> >>> -- >>> Regards, >>> Cordialement, >>> Emmanuel Lécharny >>> www.iktek.com >>> >>> >> >> >> -- >> Regards >> Rahul Bhalla >> >> > > > -- > Regards > Rahul Bhalla > (9953225211) > > > -- Regards Rahul Bhalla (9953225211)
This problem is totally independent of the other one. There's a bug in the current version available in the update which make the update site fail. A new version fixing this issue is currently being voted on this mailing list and should be out soon. In the meantime you can download and use the RCP application instead of installing the plugins inside Eclipse. Regards, Pierre-Arnaud On 23 mai 2013, at 15:31, rahul bhalla <urcoolfriend18@gmail.com> wrote: > when i tried to install mention plugins > > Apache Directory Studio Apache DS Configuration 2.0.0.v20130308 org.apache.directory.studio.apacheds.configuration.feature.feature.group > Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group > Apache Directory Studio LDAP Browser 2.0.0.v20130308 org.apache.directory.studio.ldapbrowser.feature.feature.group > Apache Directory Studio LDAP Servers 2.0.0.v20130308 org.apache.directory.studio.ldapservers.feature.feature.group > Apache Directory Studio LDIF Editor 2.0.0.v20130308 org.apache.directory.studio.ldifeditor.feature.feature.group > Apache Directory Studio RCP 2.0.0.v20130308 org.apache.directory.studio.rcp.feature.feature.group > Apache Directory Studio Schema Editor 2.0.0.v20130308 org.apache.directory.studio.schemaeditor.feature.feature.group > it gives > Cannot complete the install because one or more required items could not be found. > Software currently installed: Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 (org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group 2.0.0.v20130308) > Missing requirement: ApacheDS Core 2.0.0.M11 (org.apache.directory.server.core 2.0.0.M11) requires 'package org.apache.directory.server.core.admin [2.0.0,3.0.0)' but it could not be found > Cannot satisfy dependency: > From: Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 (org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group 2.0.0.v20130308) > To: org.apache.directory.serve > > > On Thu, May 23, 2013 at 6:59 PM, rahul bhalla <urcoolfriend18@gmail.com> wrote: > > Sir Can you please tell me what is required first in order to run user ldap > I have only eciplse juno and i only install LDAP Browser plug-in. > After what more is required > and thnks for the reply > > > > On Thu, May 23, 2013 at 6:54 PM, Emmanuel Lécharny <elecharny@gmail.com> wrote: > Le 5/23/13 3:16 PM, rahul bhalla a écrit : > > Sir only install ldap Browser plugin > > How can you connect to a LDAP server if you don't have one running ? > As you've got a response, you necessarily have a LDAP server running, > and we need to know which one it is. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > > > > -- > Regards > Rahul Bhalla > > > > > -- > Regards > Rahul Bhalla > (9953225211)
Hi Kiran,
while looking at Sonar reports
(https://analysis.apache.org/drilldown/violations), I found a weird
piece of code, which is likely ot be an error in SyncReplRequestHandler :
private void sendContentFromLog( LdapSession session, SearchRequest
req, ReplicaEventLog clientMsgLog,
String fromCsn )
throws Exception
{
...
switch ( event )
{
case ADD:
syncStateType = SyncStateTypeEnum.ADD;
break;
case MODIFY:
syncStateType = SyncStateTypeEnum.MODIFY;
break;
case MODDN:
syncStateType = SyncStateTypeEnum.MODDN;
<<<<--------------- No break, so the syncStateType will switch to DELETE
case DELETE:
syncStateType = SyncStateTypeEnum.DELETE;
break;
}
Am I correct to think that we must add a break ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
when i tried to install mention plugins Apache Directory Studio Apache DS Configuration 2.0.0.v20130308 org.apache.directory.studio.apacheds.configuration.feature.feature.group Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group Apache Directory Studio LDAP Browser 2.0.0.v20130308 org.apache.directory.studio.ldapbrowser.feature.feature.group Apache Directory Studio LDAP Servers 2.0.0.v20130308 org.apache.directory.studio.ldapservers.feature.feature.group Apache Directory Studio LDIF Editor 2.0.0.v20130308 org.apache.directory.studio.ldifeditor.feature.feature.group Apache Directory Studio RCP 2.0.0.v20130308 org.apache.directory.studio.rcp.feature.feature.group Apache Directory Studio Schema Editor 2.0.0.v20130308 org.apache.directory.studio.schemaeditor.feature.feature.group it gives Cannot complete the install because one or more required items could not be found. Software currently installed: Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 (org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group 2.0.0.v20130308) Missing requirement: ApacheDS Core 2.0.0.M11 (org.apache.directory.server.core 2.0.0.M11) requires 'package org.apache.directory.server.core.admin [2.0.0,3.0.0)' but it could not be found Cannot satisfy dependency: From: Apache Directory Studio ApacheDS 2.0 Configuration 2.0.0.v20130308 (org.apache.directory.studio.apacheds.configuration.v2.feature.feature.group 2.0.0.v20130308) To: org.apache.directory.serve On Thu, May 23, 2013 at 6:59 PM, rahul bhalla <urcoolfriend18@gmail.com>wrote: > > Sir Can you please tell me what is required first in order to run user ldap > I have only eciplse juno and i only install *LDAP Browser* plug-in. > After what more is required > and thnks for the reply > > > > On Thu, May 23, 2013 at 6:54 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote: > >> Le 5/23/13 3:16 PM, rahul bhalla a écrit : >> > Sir only install ldap Browser plugin >> >> How can you connect to a LDAP server if you don't have one running ? >> As you've got a response, you necessarily have a LDAP server running, >> and we need to know which one it is. >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >> >> > > > -- > Regards > Rahul Bhalla > > -- Regards Rahul Bhalla (9953225211)
Sir Can you please tell me what is required first in order to run user ldap I have only eciplse juno and i only install *LDAP Browser* plug-in. After what more is required and thnks for the reply On Thu, May 23, 2013 at 6:54 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote: > Le 5/23/13 3:16 PM, rahul bhalla a écrit : > > Sir only install ldap Browser plugin > > How can you connect to a LDAP server if you don't have one running ? > As you've got a response, you necessarily have a LDAP server running, > and we need to know which one it is. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Regards Rahul Bhalla
Le 5/23/13 3:16 PM, rahul bhalla a écrit : > Sir only install ldap Browser plugin How can you connect to a LDAP server if you don't have one running ? As you've got a response, you necessarily have a LDAP server running, and we need to know which one it is. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Sir only install ldap Browser plugin On Thu, May 23, 2013 at 6:45 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote: > Le 5/23/13 2:30 PM, rahul bhalla a écrit : > > Sir > > As i mention i install plugin in eclipse juno > > and i already entered secret in my password filed > > What is your LDAP server ? > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Regards Rahul Bhalla (9953225211)
Le 5/23/13 2:30 PM, rahul bhalla a écrit : > Sir > As i mention i install plugin in eclipse juno > and i already entered secret in my password filed What is your LDAP server ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Sir As i mention i install plugin in eclipse juno and i already entered secret in my password filed On Thu, May 23, 2013 at 5:55 PM, rahul bhalla <urcoolfriend18@gmail.com>wrote: > > > ---------- Forwarded message ---------- > From: rahul bhalla <urcoolfriend18@gmail.com> > Date: Thu, May 23, 2013 at 4:48 PM > Subject: Error while opening connection > To: dev@directory.apache.org > > > Error while opening connection > - [LDAP: error code 49 - Invalid Credentials] > java.lang.Exception: [LDAP: error code 49 - Invalid Credentials] > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) > > > > -- > Regards > Rahul Bhalla > > > > -- > Regards > Rahul Bhalla > (9953225211) > -- Regards Rahul Bhalla (9953225211)
Hi, I'm adding the mailing list in the answer (please make sure to do so as well in your next answer). Is it a fresh ApacheDS install? Which version? If so, the default password is secret and it should work. Regards, Pierre-Arnaud On 23 mai 2013, at 14:21, rahul bhalla <urcoolfriend18@gmail.com> wrote: > Sir > 1. I install plugin in eclipse juno // from http://directory.apache.org/studio/update/2.x > restart Eclipse > 2. I change my perspective to LDAP > 3. Click on new Connection i did > Connection Name:Apache Directory Studio > Hostname: localhost > port : 389 > After Click on next > Bind DN:uid=admin,ou=system > Password > "secret" (without double-quotes). > but still problem is same i am using linux and i am user(not sudo user) > > > > > > On Thu, May 23, 2013 at 5:26 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote: > Hi, > > Maybe try with the real "default" password of ApacheDS, which is: > "secret" (without double-quotes). > > Regards > Pierre-Arnaud > > (PS: Repost of my answer of you previous mail) > (Updated to fix a typo: 'without' instead of 'with') > > On 23 mai 2013, at 13:18, rahul bhalla <urcoolfriend18@gmail.com> wrote: > >> Error while opening connection >> - [LDAP: error code 49 - Invalid Credentials] >> java.lang.Exception: [LDAP: error code 49 - Invalid Credentials] >> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279) >> at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) >> >> >> >> -- >> Regards >> Rahul Bhalla > > > > > -- > Regards > Rahul Bhalla >
Hi, Maybe try with the real "default" password of ApacheDS, which is: "secret" (without double-quotes). Regards Pierre-Arnaud (PS: Repost of my answer of you previous mail) (Updated to fix a typo: 'without' instead of 'with') On 23 mai 2013, at 13:18, rahul bhalla <urcoolfriend18@gmail.com> wrote: > Error while opening connection > - [LDAP: error code 49 - Invalid Credentials] > java.lang.Exception: [LDAP: error code 49 - Invalid Credentials] > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) > > > > -- > Regards > Rahul Bhalla
Le 5/23/13 1:18 PM, rahul bhalla a écrit :
> Error while opening connection
> - [LDAP: error code 49 - Invalid Credentials]
> java.lang.Exception: [LDAP: error code 49 - Invalid Credentials]
^^^^^^^^^^^^^^^^^
This says it all...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Error while opening connection
- [LDAP: error code 49 - Invalid Credentials]
java.lang.Exception: [LDAP: error code 49 - Invalid Credentials]
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109)
--
Regards
Rahul Bhalla
Hi, Maybe try with the real "default" password of ApacheDS, which is: "secret" (with double-quotes). Regards Pierre-Arnaud On 23 mai 2013, at 12:18, rahul bhalla <urcoolfriend18@gmail.com> wrote: > Hi i am trying to make a new connection when i enter user as uid=admin,ou=system and password "" and click check authentication it gives mention below exception > > The authentication failed > - [LDAP: error code 49 - Invalid Credentials] > java.lang.Exception: [LDAP: error code 49 - Invalid Credentials] > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:450) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1174) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:459) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:307) > at org.apache.directory.studio.connection.core.jobs.CheckBindRunnable.run(CheckBindRunnable.java:79) > at org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:123) > at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) > > [LDAP: error code 49 - Invalid Credentials] > > > And if click on the finish it give mention below exception > Error while opening connection > - [LDAP: error code 49 - Invalid Credentials] > java.lang.Exception: [LDAP: error code 49 - Invalid Credentials] > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279) > at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) > > > What should i do > today is my first day to learn LDAP > Regards > Rahul Bhalla >
Hi i am trying to make a new connection when i enter user as
uid=admin,ou=system and password "" and click check authentication it gives
mention below exception
The authentication failed
- [LDAP: error code 49 - Invalid Credentials]
java.lang.Exception: [LDAP: error code 49 - Invalid Credentials]
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:450)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1174)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:459)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:307)
at
org.apache.directory.studio.connection.core.jobs.CheckBindRunnable.run(CheckBindRunnable.java:79)
at
org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:123)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
[LDAP: error code 49 - Invalid Credentials]
And if click on the finish it give mention below exception
Error while opening connection
- [LDAP: error code 49 - Invalid Credentials]
java.lang.Exception: [LDAP: error code 49 - Invalid Credentials]
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1279)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109)
What should i do
today is my first day to learn LDAP
Regards
Rahul Bhalla
> [X] +1 : Release Apache Directory Studio 2.0.0-M7 (2.0.0.v20130517) * Checked checksums and signatures * Built from zip source and started the application * Installed on Windows (64biy) and played a bit with Studio Kind Regards, Stefan
[ https://issues.apache.org/jira/browse/DIRSTUDIO-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664242#comment-13664242
]
Emmanuel Lecharny commented on DIRSTUDIO-916:
---------------------------------------------
In the mean time, if you need it urgently, the version being voted is available here : http://people.apache.org/~pamarcelot/ApacheDirectoryStudio-2.0.0.v20130517/
> Can not open configuration for fresh installed ApacheDS and Studio
> ------------------------------------------------------------------
>
> Key: DIRSTUDIO-916
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-916
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-apacheds
> Affects Versions: 2.0.0-M6
> Environment: ApacheDS 2-M12
> Reporter: Joe
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0-M7, 2.0.0
>
>
> Installed new ApacheDS 2.0 M12 with Studio 2.0 M-6. connected to the LDAP and right
click on the connection to open server configuration. Got following error:
> Looks like the schema not matches.
> Unable to load the configuration.
> - ERR_04269 ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
> org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269
ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:317)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
> at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1623)
> at org.apache.directory.api.ldap.model.entry.DefaultEntry.<init>(DefaultEntry.java:311)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.readConfiguration(LoadConfigurationRunnable.java:359)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.getConfiguration(LoadConfigurationRunnable.java:182)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.run(LoadConfigurationRunnable.java:127)
> at org.apache.directory.studio.common.core.jobs.StudioJob.run(StudioJob.java:83)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE
for OID ads-replpingersleep does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:313)
> ... 8 more
> ERR_04269 ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSTUDIO-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Arnaud Marcelot resolved DIRSTUDIO-916.
----------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
2.0.0-M7
Assignee: Pierre-Arnaud Marcelot
This issue is fixed in version 2.0.0-M7 which is currently being voted for release.
> Can not open configuration for fresh installed ApacheDS and Studio
> ------------------------------------------------------------------
>
> Key: DIRSTUDIO-916
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-916
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-apacheds
> Affects Versions: 2.0.0-M6
> Environment: ApacheDS 2-M12
> Reporter: Joe
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0-M7, 2.0.0
>
>
> Installed new ApacheDS 2.0 M12 with Studio 2.0 M-6. connected to the LDAP and right
click on the connection to open server configuration. Got following error:
> Looks like the schema not matches.
> Unable to load the configuration.
> - ERR_04269 ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
> org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269
ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:317)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
> at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1623)
> at org.apache.directory.api.ldap.model.entry.DefaultEntry.<init>(DefaultEntry.java:311)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.readConfiguration(LoadConfigurationRunnable.java:359)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.getConfiguration(LoadConfigurationRunnable.java:182)
> at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.run(LoadConfigurationRunnable.java:127)
> at org.apache.directory.studio.common.core.jobs.StudioJob.run(StudioJob.java:83)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE
for OID ads-replpingersleep does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:313)
> ... 8 more
> ERR_04269 ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Joe created DIRSTUDIO-916:
-----------------------------
Summary: Can not open configuration for fresh installed ApacheDS and Studio
Key: DIRSTUDIO-916
URL: https://issues.apache.org/jira/browse/DIRSTUDIO-916
Project: Directory Studio
Issue Type: Bug
Components: studio-apacheds
Affects Versions: 2.0.0-M6
Environment: ApacheDS 2-M12
Reporter: Joe
Installed new ApacheDS 2.0 M12 with Studio 2.0 M-6. connected to the LDAP and right click
on the connection to open server configuration. Got following error:
Looks like the schema not matches.
Unable to load the configuration.
- ERR_04269 ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269 ATTRIBUTE_TYPE
for OID ads-replpingersleep does not exist!
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:317)
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1623)
at org.apache.directory.api.ldap.model.entry.DefaultEntry.<init>(DefaultEntry.java:311)
at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.readConfiguration(LoadConfigurationRunnable.java:359)
at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.getConfiguration(LoadConfigurationRunnable.java:182)
at org.apache.directory.studio.apacheds.configuration.v2.jobs.LoadConfigurationRunnable.run(LoadConfigurationRunnable.java:127)
at org.apache.directory.studio.common.core.jobs.StudioJob.run(StudioJob.java:83)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE
for OID ads-replpingersleep does not exist!
at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:313)
... 8 more
ERR_04269 ATTRIBUTE_TYPE for OID ads-replpingersleep does not exist!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664209#comment-13664209
]
Emmanuel Lecharny commented on DIRSERVER-1056:
----------------------------------------------
All the LDAP API warnings but one have been cleared.
> Cleaning the warnings
> ---------------------
>
> Key: DIRSERVER-1056
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1056
> Project: Directory ApacheDS
> Issue Type: Task
> Affects Versions: 1.5.1
> Reporter: Emmanuel Lecharny
> Assignee: Emmanuel Lecharny
> Priority: Minor
> Fix For: 2.0.0-RC1
>
>
> We have around 1900 warnings in the whole ADS project (excluding Studio). If we exclude
antlr generated warnings, we still have around 1000 warnings.
> Again, if we exclude tests, we still have around 500 warnings. They are mainly Collections
not being typed. We should remove those warnings asap.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Sorry, I don't have any time to test. > [X] +/- 0 : I don't care Regards Felix
[ https://issues.apache.org/jira/browse/DIRSERVER-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1586:
-----------------------------------------
Fix Version/s: (was: 2.0.0-RC1)
2.1.0
We need to add a way for the DirectoryService to load some schemas we loaded with a SchemaLoader.
We also need to extend the SchemaLoader to accept not only directories, but also single files.
> 2.0 does not have a way to load external Ldifs (h.350)
> ------------------------------------------------------
>
> Key: DIRSERVER-1586
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1586
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0
> Environment: Running on windows XP and Windows 2003 server
> Reporter: Steve hammond
> Fix For: 2.1.0
>
> Attachments: commObject.ldif, XmppURIObject.ldif
>
>
> We need a method that is consistent with ldif files exported from Apache directory Studio,
that can be loaded to extend the schema of our server.
> In 1.5.3 I did ApacheDS.setLdifDirectory, then when the LDAP server started, it imported
and used the ldif definitions in that directory. I have exhausted all methods I could find
to load these LDIF files.
> I tried ApplyLdifs, but that takes a description parameter that is part of Junit, not
real good for production code, and the Description I can get out of Junit does not have the
getAnnotation method on it.
> I tried DSAnnotationProcessor.injectLdifFiles directly, but it could never open the file
names i gave it.
> I tried writing my own injectLdifFiles method, but always got an error when trying to
add attributes to an objectclass that I had just added, saying that this objectClass is not
yet loaded.
> I tried making my own implementation of AbstractSchemaLoader, but that pukes saying that
all schemas must have a valid creatorsName attribute.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1489.
------------------------------------------
Resolution: Fixed
Fixed with http://svn.apache.org/r1485239
> Provide access to remote connection info
> ----------------------------------------
>
> Key: DIRSERVER-1489
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1489
> Project: Directory ApacheDS
> Issue Type: Improvement
> Affects Versions: 1.5.5
> Reporter: Matt Doran
> Fix For: 2.0.0-RC1
>
> Attachments: connection-info-1.5.5.patch, connection-info-1.5.5-v2.patch
>
>
> I'm developing a custom partition and custom authentication handler to plug into ApacheDS,
and need to know the connection details of the client performing the requests. A reason
why this might be useful it to be able to log the source of invalid authentication requests.
> The CoreSession object has a getClientAddress() method, however it always returns null.
The CoreSession object is accessible from the places where it would be useful (i.e. via the
context objects passed into the Partition methods ... and also in the AuthenticationInterceptor.)
Upon further investigation it looks like the implementation in DefaultCoreSession is hard-coded
to return null. :(
> It also appears that the services main CoreSession object is reused alot (e.g. in the
authentication interceptor we use the same session object no matter who the caller is).
> I was interested in putting in a short-term patch to work-around this issue while a longer
term solution was considered. But I couldn't find anything obvious. I'd think it would
make sense to stuff the client address into the session somewhere up in one of the protocol
handlers (e.g. LdapRequestHandler.handleMessage) ... but there currently isn't anywhere to
put this info. Any ideas on a short-term (even if hacky) way to achieve this?
> (raising as requested by Emmanuel Lecharany on user's list)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1490.
------------------------------------------
Resolution: Fixed
I checked the code, and the groupCache is updated when doing a move.
> Not 100% sure, but the DN caches we have in the server might not be updated when doing
a Move
> ---------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1490
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1490
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.6
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0-RC1
>
>
> There are many different caches in the server. One of them is the group cache in the
ACI interceptor. This kind of cache might be invalid if we move an entry as the cache stores
the old DN.
> We have to check that all the caches are updated when a DN is modified.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1534.
------------------------------------------
Resolution: Invalid
This is an old issue, I'm not sure it's really accurate anymore.
There are two places were we can laod entries from LDIF files when starting the server :
- when we use @ApplyLdifFiles annotation
- when we have some test entries to load into the server at startup.
The first use case is not a problem : we process the entries one by one, they never stay in
memory.
The second use case is probably not a problem : it's quite rare that we have to load a multiple-gigabytes
file at startup to do tests.
I close this issue as 'invalid', but feel free to reopen if there is a more critical need.
> Improving implementation of loading LDIF files during startup
> -------------------------------------------------------------
>
> Key: DIRSERVER-1534
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1534
> Project: Directory ApacheDS
> Issue Type: Improvement
> Reporter: Kiran Ayyagari
> Assignee: Kiran Ayyagari
> Fix For: 2.0.0-RC1
>
>
> Currently the way we load LDIF file data during startup might lead to OOM, cause we prase
the LDIF file and keep all the LdifEntry objects in memory.
> This has to be handled in a better way by avoiding storing of all the LdifEntry objects
in memory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1816.
------------------------------------------
Resolution: Fixed
Fixed with http://svn.apache.org/r1485213
> Unable to enable SSL to the APACHE DS
> --------------------------------------
>
> Key: DIRSERVER-1816
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1816
> Project: Directory ApacheDS
> Issue Type: Task
> Components: ldap
> Affects Versions: 2.0.0-M10
> Environment: Windows
> Reporter: RakeshAcharya
> Priority: Blocker
> Labels: security
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Below are steps taken to enable SSL
> 1. Created a new valid Key pair using Portecle.
> 2. Placed the KeyStore in the conf directory
> 3. Added the below entry in the conf.ldif file
> ads-ldapServerCertificatePassword
> ads-ldapServerKeystoreFile
> also tried below entries
> keystoreFile ,certificatePassword
> ads-ldapServerKeystoreFile,ads-ldapServerCertificatePassword
> Facing below error while starting the server
> Error:
> ERR_04447_CANNOT_NORMALIZE_VALUE Cannot normalize the wrapped value ERR_04473_NOT_VALID_VALUE
Not a valid value 'C:\Users\rakeshacharya\.ApacheDirectoryStudio\.metadata\.plugins\org.apache.directory.studio.ldapservers\servers\f9ed386b-f8a9-4a79-be12-b5cfabf362be\conf\localhost.jks'
for the AttributeType 'ATTRIBUTE_TYPE ( 1.3.6.1.4.1.18060.0.4.1.2.308
> NAME 'ads-keystoreFile'
> DESC The keystore file to use to store certificates
> EQUALITY caseExactMatch
> ORDERING caseExactOrderingMatch
> SUBSTR caseExactSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
> SINGLE-VALUE
> USAGE userApplications
> ERR_04269 ATTRIBUTE_TYPE for OID certificatepassword does not exist
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1846.
------------------------------------------
Resolution: Fixed
Fixed with http://svn.apache.org/r1485213
> Configuring SSL/Start TLS keystore does not accept backward slash (\) in path
> -----------------------------------------------------------------------------
>
> Key: DIRSERVER-1846
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1846
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: schema
> Affects Versions: 2.0.0-M12
> Environment: Windows 7,
> 32 - Bit
> Reporter: ashwin kumar
> Priority: Blocker
> Labels: usability
> Fix For: 2.0.0-RC1
>
>
> *Usability failure*
> Creating a LDAPS configuration in Apache Directory studio does not accept backward slash
(\) in the path (winwdows path). After a much struggling and with help of forum support it
is pointed that Studio does not accept (\).
> This is usability issue. Normally, in windows, path is recognized by the backward slash
(\). This has to to be escaped implicitly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664044#comment-13664044
]
Pierre-Arnaud Marcelot commented on DIRSERVER-1816:
---------------------------------------------------
As explained in DIRSERVER-1846, the problem is the syntax used for the 'ads-keystoreFile'
attribute type.
The current syntax is 'Printable String' which does not allow the back-slash character ('\').
It should probably be changed to 'IA5 String' to allow support of this character.
> Unable to enable SSL to the APACHE DS
> --------------------------------------
>
> Key: DIRSERVER-1816
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1816
> Project: Directory ApacheDS
> Issue Type: Task
> Components: ldap
> Affects Versions: 2.0.0-M10
> Environment: Windows
> Reporter: RakeshAcharya
> Priority: Blocker
> Labels: security
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Below are steps taken to enable SSL
> 1. Created a new valid Key pair using Portecle.
> 2. Placed the KeyStore in the conf directory
> 3. Added the below entry in the conf.ldif file
> ads-ldapServerCertificatePassword
> ads-ldapServerKeystoreFile
> also tried below entries
> keystoreFile ,certificatePassword
> ads-ldapServerKeystoreFile,ads-ldapServerCertificatePassword
> Facing below error while starting the server
> Error:
> ERR_04447_CANNOT_NORMALIZE_VALUE Cannot normalize the wrapped value ERR_04473_NOT_VALID_VALUE
Not a valid value 'C:\Users\rakeshacharya\.ApacheDirectoryStudio\.metadata\.plugins\org.apache.directory.studio.ldapservers\servers\f9ed386b-f8a9-4a79-be12-b5cfabf362be\conf\localhost.jks'
for the AttributeType 'ATTRIBUTE_TYPE ( 1.3.6.1.4.1.18060.0.4.1.2.308
> NAME 'ads-keystoreFile'
> DESC The keystore file to use to store certificates
> EQUALITY caseExactMatch
> ORDERING caseExactOrderingMatch
> SUBSTR caseExactSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
> SINGLE-VALUE
> USAGE userApplications
> ERR_04269 ATTRIBUTE_TYPE for OID certificatepassword does not exist
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSTUDIO-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Arnaud Marcelot resolved DIRSTUDIO-906.
----------------------------------------------
Resolution: Fixed
Assignee: Pierre-Arnaud Marcelot
It should be fixed in trunk and a release vote is currently underway.
> No Apache DS installation available for Eclipse
> -----------------------------------------------
>
> Key: DIRSTUDIO-906
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-906
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-updatesite
> Affects Versions: 1.5.3, 2.0.0-M6
> Environment: Eclipse Marketplace, Eclipse Juno.
> Reporter: Mike McAngus
> Assignee: Pierre-Arnaud Marcelot
> Attachments: Apache DS Eclipse Marketplace Error.png
>
>
> The 2.x update site does not work from the Eclipse Marketplace, nor when directly accessing
http://directory.apache.org/studio/update/2.x/
> Because of the actions taken for bug DIRSTUDIO-894, the result is that there is no Apache
Directory Studio plugin available for Eclipse.
> I will add a screenshot of the error I'm getting from Eclipse Marketplace.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664037#comment-13664037
]
Pierre-Arnaud Marcelot commented on DIRSERVER-1846:
---------------------------------------------------
I just moved this issue to the ApacheDS project.
This is not typically an Apache Directory Studio issue.
What occurs is that the value for the SSL/Start TLS keystore file is stored in the 'ads-keystoreFile'
attribute type, which uses a 'Printable String' syntax.
The problem is that the 'Printable String' syntax does not allow backslash value ('\').
We should change the syntax to something which allows it ('IA5 String' is probably the right
solution).
> Configuring SSL/Start TLS keystore does not accept backward slash (\) in path
> -----------------------------------------------------------------------------
>
> Key: DIRSERVER-1846
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1846
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: schema
> Environment: Windows 7,
> 32 - Bit
> Reporter: ashwin kumar
> Priority: Blocker
> Labels: usability
>
> *Usability failure*
> Creating a LDAPS configuration in Apache Directory studio does not accept backward slash
(\) in the path (winwdows path). After a much struggling and with help of forum support it
is pointed that Studio does not accept (\).
> This is usability issue. Normally, in windows, path is recognized by the backward slash
(\). This has to to be escaped implicitly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Arnaud Marcelot updated DIRSERVER-1846:
----------------------------------------------
Fix Version/s: 2.0.0-RC1
Affects Version/s: 2.0.0-M12
> Configuring SSL/Start TLS keystore does not accept backward slash (\) in path
> -----------------------------------------------------------------------------
>
> Key: DIRSERVER-1846
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1846
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: schema
> Affects Versions: 2.0.0-M12
> Environment: Windows 7,
> 32 - Bit
> Reporter: ashwin kumar
> Priority: Blocker
> Labels: usability
> Fix For: 2.0.0-RC1
>
>
> *Usability failure*
> Creating a LDAPS configuration in Apache Directory studio does not accept backward slash
(\) in the path (winwdows path). After a much struggling and with help of forum support it
is pointed that Studio does not accept (\).
> This is usability issue. Normally, in windows, path is recognized by the backward slash
(\). This has to to be escaped implicitly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
RakeshAcharya closed DIRSERVER-1843.
------------------------------------
Resolution: Fixed
> Unable to Start/Stop Apache DS on RHEL
> --------------------------------------
>
> Key: DIRSERVER-1843
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1843
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 2.0.0-M10
> Environment: RHEL 6.1
> Reporter: RakeshAcharya
> Priority: Blocker
>
> Unable to start/Stop apache DS, there seems to be a stale process running even after
restarting the server it didn't resolve the issue.
> STOP:
> [root]# sudo service apacheds-2.0.0_M10-default restart
> Stopping ApacheDS - default...
> /opt/apacheds-2.0.0_M10/bin/apacheds: line 418: kill: (8440) - No such process
> Unable to stop ApacheDS - default.
> START:
> [root@]# sudo service apacheds-2.0.0_M10-default start
> Starting ApacheDS - default...
> ApacheDS - default is already running.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Le 5/22/13 9:30 AM, Emmanuel Lécharny a écrit :
> Le 5/22/13 9:20 AM, Stefan Seelmann a écrit :
>> On 21.05.2013 01:31, Emmanuel Lécharny wrote:
>>> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>>>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>>>> Hi Emmanuel,
>>>>>>
>>>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>>>> So the problem appears to be that we create an entry which
>>>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some
unknown
>>>>>>> reason, we are looking for an entry which kerberos principal
is
>>>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>>>
>>>>>>> It looks like that there is some name resolution occuring somewhere
on
>>>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal,
or we
>>>>>>> have a conversion we don't asked for.
>>>>>>>
>>>>>>> I'm investigating...
>>>>>>>
>>>>>> Please check the constructor of SaslBindIT. I remember that I added
some
>>>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>>>> 7 made some trouble.
>>>>> Yes, saw that.
>>>>>
>>>>> I just committed some code that fixes the issue on Mac OSX, it would
be
>>>>> cool to check if it still works on windows and linux !
>>>>> See
>>>>>
>>>>> http://svn.apache.org/r1484387
>>>>>
>>>> On Windows two GSSAPI SASL bind tests fail:
>>>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>>>
>>>>
>>>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>>>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>>>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>>>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>>>> following entry:
>>>>
>>>> 127.0.0.1 localhost.localdomain localhost
>>>>
>>>>
>>>> When I change that entry to the following the test works.
>>>>
>>>> 127.0.0.1 localhost
>>>>
>>>>
>>>> When I revert your commit the test also works as
>>>> InetAddress.getByName("127.0.0.1").getHostName() returns
>>>> "localhost.localdomain"
>>>>
>>>>
>>>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>>> Here is what I have :
>>>
>>> 127.0.0.1 localhost
>>>
>>>> More important: Somewhere in the production code the IP 127.0.0.1 is
>>>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>>>> Where does that happen? Does the KRB client does that and sends the
>>>> resolved name to the server? Or does the server resolve the name when a
>>>> connection is made? In the end the principal name contains
>>>> "localhost.localdomain". I think to have a stable test the test setup
>>>> needs to use the same mechanism to lookup the hostname as the production
>>>> code.
>>> The thing is that I think that the conversion to ldaphost is done
>>> internaly but some of the JDK code. It was working fine before I
>>> upgraded my JVM.
>> I found the place where the DNS lookup is done, it is in an JDK internal
>> class sun.security.krb5.PrincipalName. I changed the test again, now it
>> creates a KerberosPrincipal which internally calls the code and does the
>> DNS lookup. I started a Windows build on Jenkins, let's see if it works
>> there. Can you please also check if this works on your machine? If not
>> feel free to rollback.
> Running tests while I take my shower.
Works like a charm (except a failure in the middle on
CollectiveAttributeServiceIT tests :/)
I hate this issue. It's probably related to some pb with the cache we
use to manage Administrative model... It's really hard to investigate,
because it only happens randomly, and not frequently :/
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
[ https://issues.apache.org/jira/browse/DIRSERVER-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663928#comment-13663928
]
Emmanuel Lecharny edited comment on DIRSERVER-1816 at 5/22/13 8:36 AM:
-----------------------------------------------------------------------
I know this is not the right place to discuss all those interesting points, but still : you
are raising very valid concerns that need to be addressed !
QA is generally overated. As are Insurance ;-) What we have in the software industry is generally
extremely weak : basically, unit tests, integration tests, and user experiences ;-). We do
have something like 5 000 tests in ApacheDS and Ldap API, much less in Studio (I explained
why). We also have around 150 000 downloads of Studio every year (50 000 ApacheDS downloads)
but not all of them convert to real users. However, most of them are Windows users (75% I
would say).
I must say I'm a bit surprised this '/' vs '\' issue was raised recently, and not before.
Either we have broken something, or users weren't working with SSL and local keystore...
Regardless, we are now leaving a world where software are increasingly connected, with many
complex potential interactions leading to potential breakages and failures. Add that we don't
anymore live in a world of Windows dominance, as most of the servers are on Linux and many
clients are using Mac OSX or iOS/Android systems.
On our side, we don't really care if we don't release on schedule : we don't have schedules
at all ! ApacheDS 2.0 is expected for years now (since 2010, AFAIR), but we do think that
it's better to deliver something that actually *works*, even if it means we have to go through
many milestones and RC. This is not a mystery why we have already released 12 milestones for
ApacheDS 2.0, 6 for Studio 2.0 and 17 for Ldap API 1.0. I like to answer to people asking
when will the next release be cut : "When it's ready"
What drives us when we cut a release is that we consider it's urgent to get out with some
new milestone when we have detected and fixed a major bug, or added some critical new feature.
Now, it does not preclude that the GA will be perfect : this is impossible. Each new feature
adds some new bugs, and the only thing we can guarantee is that we will do our best to fix
them.
That being said, we are volunteers, most of us (talking about Apache in general). And it's
refreshing - and somehow mind blowing - to realize that we produce software which is by all
measures as good as many close source equivalent. Sometime better... But we also sometime
deliver crap ;-) At least, we don't pretend that we will make money out of this crap ;-)
One last thing : It's now 25 years I'm in the software industry, and I can assure you that
your complain about lack of quality, and lack of interest around this issue, has always been
a frequent moto. We, human beings, have a tendency to believe that "it was better when we
were young", and that "we could do better if only we had time/money/people". Sadly, this is
not true, to any extend...
was (Author: elecharny):
I know this is not the right place to discuss all those interesting points, but still
: you are raising very valid concerns that need to be addressed !
QA is generally overated. As are Insurance ;-) What we have in the software industry is generally
extremely weak : basically, unit tests, integration tests, and user experiences ;-). We do
have something like 5 000 tests in ApacheDS and Ldap API, much less in Studio (I explained
why). We also have around 150 000 downloads of Studio every year (50 000 ApacheDS downloads)
but not all of them convert to real users. However, most of them are Windows users (75% I
would say).
I must say I'm a bit surprised this '/' vs '\' issue was raised recently, and not before.
Either we have broken something, or users weren't working with SSL and local keystore...
Regardless, we are now leaving a world where software are increasingly connected, with many
complex potential interactions leading to potential breakages and failure. Add to that we
don't anymore live in a world of Windows dominance, as most of the server are on Linux and
many clients are using Mac OSX or iOS/Android systems.
On our side, we don't really care if we don't release on schedule : we don't have schedules
at all ! ApacheDS 2.0 is expected for years now (since 2010, AFAIR), but we do think that
it's better to deliver something that actually *work*, even if it means we have to go through
many milestones and RC. This is not a mistery why we have already released 12 milestones for
ApacheDS 2.0, 6 for Studio 2.0 and 17 for Ldap API 1.0. I like to answer to people asking
when will he next release be cut : "When it's ready"
What drives us when we cut a release is that we consider it's urgent to get out with some
new milestone when we have detected and fixed a major bug.
Now, it does not preclude that the GA will be perfect : this is impossible. Each new feature
adds some new bugs, and the only thing we can guarantee is that we will do our best to fix
them.
That being said, we are volunteers, most of us (talking about Apache in general). And it's
refreshing - and somehow mind blowing - to realize that we produce software which is by all
measure as good as many close source equivalent. Sometime better... But we also sometime deliver
crap ;-) At least, we don't pretend that twe will make money out of this crap ;-)
One last thing : It's now 25 years I'm in the software industry, and I can assure you that
your complain about lack of quality, and lack of interest around this issue, has always been
a frequent moto. We, human beings, have a tendency to believe that "it was better when we
were young", and that "we could do better if only we had time/money/people". Sadly, this is
not true, to any extend...
> Unable to enable SSL to the APACHE DS
> --------------------------------------
>
> Key: DIRSERVER-1816
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1816
> Project: Directory ApacheDS
> Issue Type: Task
> Components: ldap
> Affects Versions: 2.0.0-M10
> Environment: Windows
> Reporter: RakeshAcharya
> Priority: Blocker
> Labels: security
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Below are steps taken to enable SSL
> 1. Created a new valid Key pair using Portecle.
> 2. Placed the KeyStore in the conf directory
> 3. Added the below entry in the conf.ldif file
> ads-ldapServerCertificatePassword
> ads-ldapServerKeystoreFile
> also tried below entries
> keystoreFile ,certificatePassword
> ads-ldapServerKeystoreFile,ads-ldapServerCertificatePassword
> Facing below error while starting the server
> Error:
> ERR_04447_CANNOT_NORMALIZE_VALUE Cannot normalize the wrapped value ERR_04473_NOT_VALID_VALUE
Not a valid value 'C:\Users\rakeshacharya\.ApacheDirectoryStudio\.metadata\.plugins\org.apache.directory.studio.ldapservers\servers\f9ed386b-f8a9-4a79-be12-b5cfabf362be\conf\localhost.jks'
for the AttributeType 'ATTRIBUTE_TYPE ( 1.3.6.1.4.1.18060.0.4.1.2.308
> NAME 'ads-keystoreFile'
> DESC The keystore file to use to store certificates
> EQUALITY caseExactMatch
> ORDERING caseExactOrderingMatch
> SUBSTR caseExactSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
> SINGLE-VALUE
> USAGE userApplications
> ERR_04269 ATTRIBUTE_TYPE for OID certificatepassword does not exist
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/DIRSERVER-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663928#comment-13663928
]
Emmanuel Lecharny commented on DIRSERVER-1816:
----------------------------------------------
I know this is not the right place to discuss all those interesting points, but still : you
are raising very valid concerns that need to be addressed !
QA is generally overated. As are Insurance ;-) What we have in the software industry is generally
extremely weak : basically, unit tests, integration tests, and user experiences ;-). We do
have something like 5 000 tests in ApacheDS and Ldap API, much less in Studio (I explained
why). We also have around 150 000 downloads of Studio every year (50 000 ApacheDS downloads)
but not all of them convert to real users. However, most of them are Windows users (75% I
would say).
I must say I'm a bit surprised this '/' vs '\' issue was raised recently, and not before.
Either we have broken something, or users weren't working with SSL and local keystore...
Regardless, we are now leaving a world where software are increasingly connected, with many
complex potential interactions leading to potential breakages and failure. Add to that we
don't anymore live in a world of Windows dominance, as most of the server are on Linux and
many clients are using Mac OSX or iOS/Android systems.
On our side, we don't really care if we don't release on schedule : we don't have schedules
at all ! ApacheDS 2.0 is expected for years now (since 2010, AFAIR), but we do think that
it's better to deliver something that actually *work*, even if it means we have to go through
many milestones and RC. This is not a mistery why we have already released 12 milestones for
ApacheDS 2.0, 6 for Studio 2.0 and 17 for Ldap API 1.0. I like to answer to people asking
when will he next release be cut : "When it's ready"
What drives us when we cut a release is that we consider it's urgent to get out with some
new milestone when we have detected and fixed a major bug.
Now, it does not preclude that the GA will be perfect : this is impossible. Each new feature
adds some new bugs, and the only thing we can guarantee is that we will do our best to fix
them.
That being said, we are volunteers, most of us (talking about Apache in general). And it's
refreshing - and somehow mind blowing - to realize that we produce software which is by all
measure as good as many close source equivalent. Sometime better... But we also sometime deliver
crap ;-) At least, we don't pretend that twe will make money out of this crap ;-)
One last thing : It's now 25 years I'm in the software industry, and I can assure you that
your complain about lack of quality, and lack of interest around this issue, has always been
a frequent moto. We, human beings, have a tendency to believe that "it was better when we
were young", and that "we could do better if only we had time/money/people". Sadly, this is
not true, to any extend...
> Unable to enable SSL to the APACHE DS
> --------------------------------------
>
> Key: DIRSERVER-1816
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1816
> Project: Directory ApacheDS
> Issue Type: Task
> Components: ldap
> Affects Versions: 2.0.0-M10
> Environment: Windows
> Reporter: RakeshAcharya
> Priority: Blocker
> Labels: security
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Below are steps taken to enable SSL
> 1. Created a new valid Key pair using Portecle.
> 2. Placed the KeyStore in the conf directory
> 3. Added the below entry in the conf.ldif file
> ads-ldapServerCertificatePassword
> ads-ldapServerKeystoreFile
> also tried below entries
> keystoreFile ,certificatePassword
> ads-ldapServerKeystoreFile,ads-ldapServerCertificatePassword
> Facing below error while starting the server
> Error:
> ERR_04447_CANNOT_NORMALIZE_VALUE Cannot normalize the wrapped value ERR_04473_NOT_VALID_VALUE
Not a valid value 'C:\Users\rakeshacharya\.ApacheDirectoryStudio\.metadata\.plugins\org.apache.directory.studio.ldapservers\servers\f9ed386b-f8a9-4a79-be12-b5cfabf362be\conf\localhost.jks'
for the AttributeType 'ATTRIBUTE_TYPE ( 1.3.6.1.4.1.18060.0.4.1.2.308
> NAME 'ads-keystoreFile'
> DESC The keystore file to use to store certificates
> EQUALITY caseExactMatch
> ORDERING caseExactOrderingMatch
> SUBSTR caseExactSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
> SINGLE-VALUE
> USAGE userApplications
> ERR_04269 ATTRIBUTE_TYPE for OID certificatepassword does not exist
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Le 5/22/13 9:20 AM, Stefan Seelmann a écrit :
> On 21.05.2013 01:31, Emmanuel Lécharny wrote:
>> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>>> Hi Emmanuel,
>>>>>
>>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>>> So the problem appears to be that we create an entry which
>>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>>>>> reason, we are looking for an entry which kerberos principal is
>>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>>
>>>>>> It looks like that there is some name resolution occuring somewhere
on
>>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or
we
>>>>>> have a conversion we don't asked for.
>>>>>>
>>>>>> I'm investigating...
>>>>>>
>>>>> Please check the constructor of SaslBindIT. I remember that I added some
>>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>>> 7 made some trouble.
>>>> Yes, saw that.
>>>>
>>>> I just committed some code that fixes the issue on Mac OSX, it would be
>>>> cool to check if it still works on windows and linux !
>>>> See
>>>>
>>>> http://svn.apache.org/r1484387
>>>>
>>> On Windows two GSSAPI SASL bind tests fail:
>>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>>
>>>
>>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>>> following entry:
>>>
>>> 127.0.0.1 localhost.localdomain localhost
>>>
>>>
>>> When I change that entry to the following the test works.
>>>
>>> 127.0.0.1 localhost
>>>
>>>
>>> When I revert your commit the test also works as
>>> InetAddress.getByName("127.0.0.1").getHostName() returns
>>> "localhost.localdomain"
>>>
>>>
>>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>> Here is what I have :
>>
>> 127.0.0.1 localhost
>>
>>> More important: Somewhere in the production code the IP 127.0.0.1 is
>>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>>> Where does that happen? Does the KRB client does that and sends the
>>> resolved name to the server? Or does the server resolve the name when a
>>> connection is made? In the end the principal name contains
>>> "localhost.localdomain". I think to have a stable test the test setup
>>> needs to use the same mechanism to lookup the hostname as the production
>>> code.
>> The thing is that I think that the conversion to ldaphost is done
>> internaly but some of the JDK code. It was working fine before I
>> upgraded my JVM.
> I found the place where the DNS lookup is done, it is in an JDK internal
> class sun.security.krb5.PrincipalName. I changed the test again, now it
> creates a KerberosPrincipal which internally calls the code and does the
> DNS lookup. I started a Windows build on Jenkins, let's see if it works
> there. Can you please also check if this works on your machine? If not
> feel free to rollback.
Running tests while I take my shower.
What you have found confirm that the Java update I did causes the test
to fail on Mac. This is worrysome though, because the KrbPrincipalName
stored in the entry is hard wired. OTOH, it's an extremely wrong thing
to have a kerberosPrincipal containing localhost (except for tests...)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
On 21.05.2013 01:31, Emmanuel Lécharny wrote:
> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>> Hi Emmanuel,
>>>>
>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>> So the problem appears to be that we create an entry which
>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>>>> reason, we are looking for an entry which kerberos principal is
>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>
>>>>> It looks like that there is some name resolution occuring somewhere on
>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>>>>> have a conversion we don't asked for.
>>>>>
>>>>> I'm investigating...
>>>>>
>>>> Please check the constructor of SaslBindIT. I remember that I added some
>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>> 7 made some trouble.
>>> Yes, saw that.
>>>
>>> I just committed some code that fixes the issue on Mac OSX, it would be
>>> cool to check if it still works on windows and linux !
>>> See
>>>
>>> http://svn.apache.org/r1484387
>>>
>> On Windows two GSSAPI SASL bind tests fail:
>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>
>>
>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>> following entry:
>>
>> 127.0.0.1 localhost.localdomain localhost
>>
>>
>> When I change that entry to the following the test works.
>>
>> 127.0.0.1 localhost
>>
>>
>> When I revert your commit the test also works as
>> InetAddress.getByName("127.0.0.1").getHostName() returns
>> "localhost.localdomain"
>>
>>
>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>
> Here is what I have :
>
> 127.0.0.1 localhost
>
>>
>> More important: Somewhere in the production code the IP 127.0.0.1 is
>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>> Where does that happen? Does the KRB client does that and sends the
>> resolved name to the server? Or does the server resolve the name when a
>> connection is made? In the end the principal name contains
>> "localhost.localdomain". I think to have a stable test the test setup
>> needs to use the same mechanism to lookup the hostname as the production
>> code.
>
> The thing is that I think that the conversion to ldaphost is done
> internaly but some of the JDK code. It was working fine before I
> upgraded my JVM.
I found the place where the DNS lookup is done, it is in an JDK internal
class sun.security.krb5.PrincipalName. I changed the test again, now it
creates a KerberosPrincipal which internally calls the code and does the
DNS lookup. I started a Windows build on Jenkins, let's see if it works
there. Can you please also check if this works on your machine? If not
feel free to rollback.
Kind Regards,
Stefan
Hi Stefan,
I saw that you ave added some TODO in this class, which sounds like a
good idea. I will try to answer some of them :
+// TODO: all the SASL bind methods are not declared in this interface, but implemented in
LdapNetworkConnection. Is that intended?
No. I have added some of them lately, but dind't had time to add them in the interface. Although,
the CoreConnection does not support some of the SASL bind atm :
/**
* SASL PLAIN Bind on a server.
*
* @param authcid The Authentication identity
* @param credentials The password. It can't be null
* @return The BindResponse LdapResponse
* @throws {@link LdapException} if some error occurred
*/
// Not yet available on the CoreConnection
//BindResponse bindSaslPlain( String authcid, String credentials ) throws LdapException;
It should though : the SASL Plain authentication has been added last month.
+// TODO: why do connect() and bind() methods throw an IOException, the other methods not?
This can be safely removed IMO.
+// TODO: why do connect() and close() return a boolean? What is the difference between false
and an Exception?
Good question... No answer so far.
+// TODO: think about usage of abbrevisions (Dn/Rdn) vs. spelled out (relative distinguished
name) in javadoc
I prefer Rdn/Dn. Let's be consistant.
+// TODO: does method getCodecService() belong into the interface? It returns a LdapApiService,
should it be renamed?
I suspect it has to do with OSGi...
+// TODO: does method doesFutureExistFor() belong into the interface? Move to LdapAsyncConnection?
It's a LdapNetworkConnection method only. It would make sense to move to LdapAsyncConnection.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com