Re: Sponsoring the work on data corruption / Mavibot

[Kiran Ayyagari]

On Wed, May 26, 2021 at 10:26 PM Emmanuel Lécharny 
wrote:

> Hi,
>
>
>
> On 22/05/2021 22:43, Samuel wrote:
> > Hello,
> >
> > I may be able to convince my company to sponsor the work on data
> > corruption / Mavibot, the goal would be to get ApacheDS production-ready
> > from a stability point of view. I have a couple of questions:
> >
> > 1) How much money would be needed to sponsor this work?
> > 2) where would the money need to be sent?
>
> Kiran, interested?
>
Sorry, my hands are full at the moment.

Thank you Emmanuel.

>
> > 3) About how much time would be necessary from the moment financial
> > resources are in?
>
> Not necessarily a lot of time. I would say something around 1 month.
>
> --
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
> For additional commands, e-mail: dev-h...@directory.apache.org
>
> Kiran

Re: [VOTE] Apache DS 2.0.0.AM26 release

[Kiran Ayyagari]

+1, built the sources with Java 8 (1.8.0_162-b12)

Thanks Emmanuel.

P.S:- One observation, the root pom.xml refers to version 2.0.1-SNAPSHOT of
checkstyle-configuration.

On Fri, Feb 28, 2020 at 3:23 PM Emmanuel Lécharny 
wrote:

> Hi,
>
> This is a major release of ApacheDS. It brings many bug fixes, and is the
> first version implementing LDAP transactions,
> which are now used internally for atomic operations, but can also be used
> through an extended operation, to apply many
> operations in one transaction.
> We also have changed the Cache system we were using (ehcache) to use the
> more efficient and lighter Caffeine
> (https://github.com/ben-manes/caffeine/wiki).
> Otherwise, we don't anymore store certificates in the server by default,
> but use an external keystore.
>
> We can't anymore produce the Mac OSX installer package, we are working on
> finding a solution for that issue (Apple
> deprecated the MakePackage tool and is now applying way more stringent
> checks and controls for packages, like
> and Apple signature). This will most certainly be fixed in the next
> revision.
>
> It uses the Apache LDAP API 2.0.0 release
>
> Here are the fixed issues :
>
>
> Bugs :
> --
>
> * DIRSERVER-1414 - Normalization is not handling correctly (buit this has
> no impact)
> * DIRSERVER-1580 - Numerous JUnit tests failing on Windows, again.
> * DIRSERVER-1878 - Bad warning from 'maven-shade-plugin' when creating the
> 'apacheds-service' jar
> * DIRSERVER-1924 - The MavibotPartition entry cache is not correctly set
> * DIRSERVER-1974 - Rename Operation Issue - ApacheDS
> * DIRSERVER-2049 - Queries interrupted with delete/add operations
> * DIRSERVER-2066 - Maven 3.3.x produces Invalid installers/archives
> * DIRSERVER-2070 - Null pointer exception on kerberos password changing
> * DIRSERVER-2071 - MinaKerberosDecoder fails with NullPointerException if
> the kerberos message is split in multiple packets
> * DIRSERVER-2074 - small default TCP receive/send buffer size causing TCP
> packet fragmentation on some platforms
> * DIRSERVER-2089 - AttributeType breaks the equals/hashCode override
> contract
> * DIRSERVER-2099 - NOTICE and LICENSE files for DS 2.0.0-M20 are
> incorrect
> * DIRSERVER-2146 - Using special chars in uid makes problem
> * DIRSERVER-2197 - Debian installer package contains the binary 4 times
> * DIRSERVER-2237 - Application opens but can't 'Open Connection' -
> IllegalArgumentException
> * DIRSERVER-2247 - Invalid signature file digest for Manifest main
> attributes - When switching from 2.0.0-M24 to 2.0.0-AM25
> * DIRSERVER-2253 - NIS schema object class and attribute problem
> * DIRSERVER-2264 - missing schema type for NIS: nisMapName
> * DIRSERVER-2273 - Le serveur ne démarre plus
> * DIRSERVER-2275 - Les schemas LDIF générés à partir du schema browser
> font planter Directory au démarrage
> * DIRSERVER-2289 - Paging support to retrieve all the entries available in
> ApacheDS between different client and LDAP server connections
>
>
> Improvements :
> --
>
> * DIRSERVER-959 - We nedd a global cache
> * DIRSERVER-1639 - Add support for specifying cipher suites in
> LdapServer's configuration
> * DIRSERVER-1892 - We don't need to clone the full entry when returning it
> from the backen
> * DIRSERVER-1916 - Don't drop 'top' from ObjectClass index, it's never
> present in the BTree
> * DIRSERVER-2044 - The CacheService.initialize() method takes an unused
> InstanceID argument
> * DIRSERVER-2132 - Add the structuralObjectClass attribute to every
> returned entry
> * DIRSERVER-2133 - Add the hasSubordinates operational attribute to entries
> * DIRSERVER-2145 - A BIND request will do 2 lookups of the entry trying to
> bind
> * DIRSERVER-2168 - Possible performance improvement in the Add operation
> * DIRSERVER-2262 - The LdapServer.loadkeyStore() method do the work twice
> if there is no KeyStore defined
> * DIRSERVER-2270 - Inconsistent log level practices
>
>
> New features :
> --
>
> * DIRSERVER-279 - Transaction support
> * DIRSERVER-1422 - Delegation of Authentication
> * DIRSERVER-1956 - Add support for rfc4525 (increment)
> * DIRSERVER-2245 - Implement the transaction support in ApachedS
> * DIRSERVER-2248 - The server generates some errors when starting (Schema
> isues)
>
> Tasks :
> ---
>
> * DIRSERVER-1245 - Source audit
> * DIRSERVER-2063 - Automat testing of installers
> * DIRSERVER-2097 - Fix usage of default charset|locale|timezone and enable
> forbiddenapis check
> * DIRSERVER-2271 - Replace Ehcache with Caffeine
>
> Tests :
> ---
> * DIRSERVER-1847 - Introduce time provider for time dependent tests
>
>
>
>   Here are the associated links :
>
> ApacheDS 2.0.0.AM26
> ---
> - GIT tag :
>
>
> https://gitbox.apache.org/repos/asf?p=directory-server.git;a=commit;h=8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064
> <
> https://gitbox.apache.org/repos/asf?p=directory-server.git;a=commit;h=40ab08d93c6125ccb59d692b25759361307195d3
> >
>
> - Nexus rep

Re: [VOTE] Release Apache LDAP API 2.0.0

[Kiran Ayyagari]

+1, built using Java8 on OS X and verified SHA256 hash.

Thank you for taking care of this in the middle of a conference :).

On Wed, Nov 6, 2019 at 4:09 PM Emmanuel Lécharny 
wrote:

> Hi all,
>
> this is a vote for the release of Apache LDAP API 2.0.0
>
> This is a GA, at least !
>
> There are a couple important fixes :
>
> o DIRMINA-342  - Unbind breaks connection
>
> o DIRAPI-349 - DN with hex values aren't parsed properly when not schema
> aware
>
> and an improvement
>
> o DIRAPI-344 - Allow a LDIF entry loading to be accepted when the
> SchemaManager is in relaxed mode
>
>
> The revision :
>
>
> https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=commit;h=763ad553749e59cfb12259c8f58a75aee3653d1a
>
>
> The source and binary distribution packages:
> https://dist.apache.org/repos/dist/dev/directory/api/2.0.0
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1185
>
>
> Please cast your votes:
> [ ] +1 Release Apache LDAP API 2.0.0
> [ ] 0 abstain
> [ ] -1 Do not release Apache LDAP API 2.0.0
>
>
> Thanks !
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
> For additional commands, e-mail: dev-h...@directory.apache.org
>
> Kiran

Re: Existing ApacheDS containers?

[Kiran Ayyagari]

On Fri, Mar 29, 2019 at 10:03 PM Marc Boorshtein 
wrote:

>
>
>
> I did this last year, there wasn't anything special in it then but if I
>> have to do it again I will probably do it with https://quarkus.io/.
>>
>>>
> Interesting, why? Have you seen that apacheds benefits from it?
>
It generates a native binary and (according to doc) takes less time to
start. But more than that we don't need to install JRE inside
the container. Those are all at the moment appear to be good things, but
haven't tested these in a container yet.

Kiran

Re: Existing ApacheDS containers?

[Kiran Ayyagari]

On Fri, Mar 29, 2019 at 9:21 PM Marc Boorshtein 
wrote:

> All,
>
> I need a container that I can spin up quickly that i can just feed an LDIF
> file and be listening on 10636.  Has anyone containerized apacheds?  Can't
> imagine its hard but I thought I'd see if anyone else tried it already.
>
I did this last year, there wasn't anything special in it then but if I
have to do it again I will probably do it with https://quarkus.io/.

>
> Thanks
> Marc
>
Kiran

Re: Welcome to Lothar !

[Kiran Ayyagari]

Welcome Lothar!, been a while since we last welcomed one :)

On Mon, Dec 17, 2018 at 11:47 AM Emmanuel Lécharny 
wrote:

> I'm very please to have Lothar as a new Apache Directory project committer
> !
>
>
> A warm welcome !
>
>
> Emmanuel
>
> Kiran

[jira] [Assigned] (FC-258) Updating the way FortResponse is served

[Kiran Ayyagari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Ayyagari reassigned FC-258:
-

Assignee: Kiran Ayyagari

> Updating the way FortResponse is served
> ---
>
> Key: FC-258
> URL: https://issues.apache.org/jira/browse/FC-258
> Project: FORTRESS
>  Issue Type: Bug
>    Reporter: Kiran Ayyagari
>    Assignee: Kiran Ayyagari
>Priority: Major
>
> The FortResponse instance created as a result of operation exception is still 
> sent to the client with a HTTP status code of "200 OK" forcing clients to 
> rely on the {{errorCode}} field to figure out the actual status of the 
> operation.
> For example when the below request is sent to a stock Fortress REST service
> {code}
> curl -POST http://localhost:7070/fortress-rest/userAdd --header 
> "Content-Type: application/json" --header "Accept: application/json" --header 
> "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": 
> "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": 
> "non-existing-ou" }, "contextId": "HOME" }'
> {code}
> the below success response is received though the request was failed due to a 
> validation error which ideally should have been responded with a "400 bad 
> request" error.
> {code}
> *   Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 7070 (#0)
> > POST /fortress-rest/userAdd HTTP/1.1
> > Host: localhost:7070
> > User-Agent: curl/7.54.0
> > Content-Type: application/json
> > Accept: application/json
> > Authorization: Basic dGVzdDpwYXNzd29yZA==
> > Content-Length: 138
> > 
> * upload completely sent off: 138 out of 138 bytes
> < HTTP/1.1 200 
> < Date: Fri, 16 Nov 2018 15:05:04 GMT
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> < 
> * Connection #0 to host localhost left intact
> {"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected 
> invalid orgUnit name [non-existing-ou] adding user with userId 
> [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
> {code}
> I propose to add a new {{httpStatusCode}} field to FortResponse class which 
> can be set appropriately and modify/add the CXF interceptor to change the 
> outgoing response's status accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (FC-258) Updating the way FortResponse is served

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690570#comment-16690570
 ] 

Kiran Ayyagari edited comment on FC-258 at 11/17/18 2:31 PM:
-

So far mapped the below exceptions:

||Exception Class||HTTP Status Code||
|AuthorizationException|403|
|FinderException|404|
|PasswordException|400|
|ValidationException|400|

All other exceptions have status code 500 by default.


was (Author: akiran):
So far mapped the below exceptions:
FinderException - 404
PasswordException - 400
ValidationException - 400

All other exceptions have status code 500 by default.

> Updating the way FortResponse is served
> ---
>
> Key: FC-258
> URL: https://issues.apache.org/jira/browse/FC-258
> Project: FORTRESS
>  Issue Type: Bug
>Reporter: Kiran Ayyagari
>Priority: Major
>
> The FortResponse instance created as a result of operation exception is still 
> sent to the client with a HTTP status code of "200 OK" forcing clients to 
> rely on the {{errorCode}} field to figure out the actual status of the 
> operation.
> For example when the below request is sent to a stock Fortress REST service
> {code}
> curl -POST http://localhost:7070/fortress-rest/userAdd --header 
> "Content-Type: application/json" --header "Accept: application/json" --header 
> "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": 
> "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": 
> "non-existing-ou" }, "contextId": "HOME" }'
> {code}
> the below success response is received though the request was failed due to a 
> validation error which ideally should have been responded with a "400 bad 
> request" error.
> {code}
> *   Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 7070 (#0)
> > POST /fortress-rest/userAdd HTTP/1.1
> > Host: localhost:7070
> > User-Agent: curl/7.54.0
> > Content-Type: application/json
> > Accept: application/json
> > Authorization: Basic dGVzdDpwYXNzd29yZA==
> > Content-Length: 138
> > 
> * upload completely sent off: 138 out of 138 bytes
> < HTTP/1.1 200 
> < Date: Fri, 16 Nov 2018 15:05:04 GMT
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> < 
> * Connection #0 to host localhost left intact
> {"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected 
> invalid orgUnit name [non-existing-ou] adding user with userId 
> [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
> {code}
> I propose to add a new {{httpStatusCode}} field to FortResponse class which 
> can be set appropriately and modify/add the CXF interceptor to change the 
> outgoing response's status accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FC-258) Updating the way FortResponse is served

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/FC-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690570#comment-16690570
 ] 

Kiran Ayyagari commented on FC-258:
---

So far mapped the below exceptions:
FinderException - 404
PasswordException - 400
ValidationException - 400

All other exceptions have status code 500 by default.

> Updating the way FortResponse is served
> ---
>
> Key: FC-258
> URL: https://issues.apache.org/jira/browse/FC-258
> Project: FORTRESS
>  Issue Type: Bug
>Reporter: Kiran Ayyagari
>Priority: Major
>
> The FortResponse instance created as a result of operation exception is still 
> sent to the client with a HTTP status code of "200 OK" forcing clients to 
> rely on the {{errorCode}} field to figure out the actual status of the 
> operation.
> For example when the below request is sent to a stock Fortress REST service
> {code}
> curl -POST http://localhost:7070/fortress-rest/userAdd --header 
> "Content-Type: application/json" --header "Accept: application/json" --header 
> "Authorization: Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": 
> "org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": 
> "non-existing-ou" }, "contextId": "HOME" }'
> {code}
> the below success response is received though the request was failed due to a 
> validation error which ideally should have been responded with a "400 bad 
> request" error.
> {code}
> *   Trying ::1...
> * TCP_NODELAY set
> * Connected to localhost (::1) port 7070 (#0)
> > POST /fortress-rest/userAdd HTTP/1.1
> > Host: localhost:7070
> > User-Agent: curl/7.54.0
> > Content-Type: application/json
> > Accept: application/json
> > Authorization: Basic dGVzdDpwYXNzd29yZA==
> > Content-Length: 138
> > 
> * upload completely sent off: 138 out of 138 bytes
> < HTTP/1.1 200 
> < Date: Fri, 16 Nov 2018 15:05:04 GMT
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> < 
> * Connection #0 to host localhost left intact
> {"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected 
> invalid orgUnit name [non-existing-ou] adding user with userId 
> [test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
> {code}
> I propose to add a new {{httpStatusCode}} field to FortResponse class which 
> can be set appropriately and modify/add the CXF interceptor to change the 
> outgoing response's status accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FC-258) Updating the way FortResponse is served

[Kiran Ayyagari (JIRA)]

Kiran Ayyagari created FC-258:
-

 Summary: Updating the way FortResponse is served
 Key: FC-258
 URL: https://issues.apache.org/jira/browse/FC-258
 Project: FORTRESS
  Issue Type: Bug
Reporter: Kiran Ayyagari


The FortResponse instance created as a result of operation exception is still 
sent to the client with a HTTP status code of "200 OK" forcing clients to rely 
on the {{errorCode}} field to figure out the actual status of the operation.

For example when the below request is sent to a stock Fortress REST service
{code}
curl -POST http://localhost:7070/fortress-rest/userAdd --header "Content-Type: 
application/json" --header "Accept: application/json" --header "Authorization: 
Basic dGVzdDpwYXNzd29yZA==" -v -d '{ "entity": { "fqcn": 
"org.apache.directory.fortress.core.model.User", "userId": "test1", "ou": 
"non-existing-ou" }, "contextId": "HOME" }'
{code}
the below success response is received though the request was failed due to a 
validation error which ideally should have been responded with a "400 bad 
request" error.
{code}
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 7070 (#0)
> POST /fortress-rest/userAdd HTTP/1.1
> Host: localhost:7070
> User-Agent: curl/7.54.0
> Content-Type: application/json
> Accept: application/json
> Authorization: Basic dGVzdDpwYXNzd29yZA==
> Content-Length: 138
> 
* upload completely sent off: 138 out of 138 bytes
< HTTP/1.1 200 
< Date: Fri, 16 Nov 2018 15:05:04 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< 
* Connection #0 to host localhost left intact
{"errorCode":1035,"isAuthorized":null,"errorMessage":"validate detected invalid 
orgUnit name [non-existing-ou] adding user with userId 
[test1]","entity":null,"entities":null,"values":null,"valueSet":null,"session":null}
{code}

I propose to add a new {{httpStatusCode}} field to FortResponse class which can 
be set appropriately and modify/add the CXF interceptor to change the outgoing 
response's status accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FC-250) Update fortress-rest to Support JSON Data Format

[Kiran Ayyagari (JIRA)]

Kiran Ayyagari created FC-250:
-

 Summary: Update fortress-rest to Support JSON Data Format
 Key: FC-250
 URL: https://issues.apache.org/jira/browse/FC-250
 Project: FORTRESS
  Issue Type: Sub-task
Reporter: Kiran Ayyagari
Assignee: Kiran Ayyagari


Only XML data format is supported for both input and output as of now, adding 
support for JSON makes it easy to work with the data in Vue.JS



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FC-247) Create a New Webapp to Manage Fortress Entities

[Kiran Ayyagari (JIRA)]

Kiran Ayyagari created FC-247:
-

 Summary: Create a New Webapp to Manage Fortress Entities
 Key: FC-247
 URL: https://issues.apache.org/jira/browse/FC-247
 Project: FORTRESS
  Issue Type: Task
Reporter: Kiran Ayyagari
Assignee: Kiran Ayyagari


Fortress has a Apache Wicket based webapp that is used for managing various 
entities.

There is a new plan to re-write it using [Vue.JS|https://vuejs.org/].This task 
is intended for 
tracking the progress of this new experiment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: rm -rf *Decorator ;-)

[Kiran Ayyagari]

On Wed, Oct 3, 2018 at 7:42 PM Emmanuel Lécharny 
wrote:

> Hi !
>
> a quick mail as a follow up of my last night insomnias...
>
>
> Last week-end I wa scompleting my rewrite of the Message encoding part.
> The gain is clear :
> - simpler code (way simpler !!!)
> - faster code (way faster, too, 2.5x average)
>
> At the end of this refactoring, I faced some issues with the Controls.
>
> Controls are handled in a bit specific way :
> - we may have 'unknown' controls, which have to be accepted by the API
> - we use a factory to create them
> - they have a value that itself may need to be decoded and encoded.
>
> All in all, some inconsistencies pointed their nose, and some of the
> tests were simply failing (ClassCastException and such things...)
>
> I tried hard to draw the global Message hierarchy, same for Controls,
> but at the end of the day, the Decorator additions makes a full mess of it.
>
> I remember Alex reaction when he discovered those Decorator additions,
> which was kind of "what the HECK is THAT ??? Ok, your choice, I'm not
> going to touch it with a 10 feet pole..." (kind of. He may have been
> less polite...)
>
> 6 or 7 years later (I don't exactly remember), the whole stuff seems to
> me an insanity.
>
>
> Let's see why we added it (mainly following my lead)
> - At this time Pierre-Arnaud was working on implementing DSML
> - There are heavy simularity, and it sounded like a 'good idea' (read :
> 'really bad idea') to add a decorator to hide the encoding/decoding parts
> - There was no reason to expose the codec logic in LdapMessage
> - We wanted to decouple the encoding/decoding from the LdapMessage
> implementation, so that it was possible to encode in DSML or BER or
> anything (JSON anyone ?).
>
> The last point was quite appealing.
>
Yeah, but we aren't writing Spring framework :)

>
> The problem is that the implementation was really a nightmare (and still
> is). Anyone who wants to add a new extendedOperation or a nex Control
> has to go through many classes and is likely to get lost (I experienced
> it last month while implementing transactions).
>
and I had gone through the same while writing an extendedoperation for
certificate signing.

>
> Anyway, if you look at the LdapMessage current hierarchy (50 interfaces,
> 16 abstract classes, 13 final classes, 107 classes…), it simply makes no
> sense.
>
>
> So I'm currenly trying to get rid of all those Decorator non-sense.
>
> The idea is to have the message contain the method to get the encoded
> value at first. The decoding is still delegated to the codec package and
> for Controls, we use their factory for that purpose.
>
> Later on, I will move the encode() method out of the Ldap Message
> inmplementation to the LdapEncoder class, as encoding just need to have
> access to the messages data, which is exposed by the message interface.
> That would decouple encoding from the implementation (this will also
> allow the encoding in DSML or whatever, we will just need a DsmlEncoder,
> etc).
>
>
> At this point, it's still an experiment, but I'm pleased by the result
> so far. I'll keep going up to the point I have something that passes
> tests green for teh API *and* the server.
>
> Studio should not be impacted, nor should Fortress.
>
> Expect this work to take a couple of weeks !
>
> Thanks for taking care of it Emmanuel.

> Thanks !
>
> Kiran

Re: [VOTE] Apache Fortress 2.0.2 release

[Kiran Ayyagari]

+1
Built the source distribution using Java8 on OS X, tested against ApacheDS
using docker image and verified signatures.

On Sun, Sep 9, 2018 at 5:41 PM, Shawn McKinney  wrote:

> Hello,
>
> This is an announcement to vote for the next release of Apache Directory
> Fortress.
>
> The version, 2.0.2, has a tag created for git: ‘2.0.2’.
>
> and the sources may be pulled using git commands:
> git clone --branch 2.0.2 https://git-wip-us.apache.org/
> repos/asf/directory-fortress-core.git
> git clone --branch 2.0.2 https://git-wip-us.apache.org/
> repos/asf/directory-fortress-realm.git
> git clone --branch 2.0.2 https://git-wip-us.apache.org/
> repos/asf/directory-fortress-enmasse.git
> git clone --branch 2.0.2 https://git-wip-us.apache.org/
> repos/asf/directory-fortress-commander.git
>
> with their associated checksums:
> - core:  90912b0aff513d5ee3afca278801de60ee1413a1
> - realm: 3f945049973abde5f8472e22d11df8c31c31f67f
> - rest:  1b5291418da7bfc7cbe9656ed02b2a98e8a1a85d
> - web:   89612697e3ac57b05c9ae3dbec226d5e9a002751
>
> Or, source distros may be downloaded from SVN:
> - https://dist.apache.org/repos/dist/dev/directory/fortress/2.0.2/
>
> Or, source distros may be downloaded from this location:
> - http://home.apache.org/~smckinney/
>
> The staging repo on Nexus:
> - https://repository.apache.org/content/repositories/
> orgapachedirectory-1176
>
> Test against LDAP using one of these:
>  * https://github.com/apache/directory-fortress-core/blob/
> master/README-QUICKSTART-DOCKER-APACHEDS.md
>  * https://github.com/apache/directory-fortress-core/blob/
> master/README-QUICKSTART-DOCKER-SLAPD.md
>
> - Choose one of the above.  Complete (only) the sections leading up to and
> including the SECTION entitled: 'Apache Fortress Core Integration Test’
>
> Please vote:
> [ ] +1   | Release Fortress 2.0.2
> [ ] +/-0 | Abstain
> [ ] -1   | Do *NOT* Release Fortress 2.0.2
>
> Kiran

Re: [ApacheDS] converting PartitionReadTxn and PartitionWriteTxn to interfaces

[Kiran Ayyagari]

On Tue, Sep 11, 2018 at 3:49 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 11/09/2018 à 11:53, Kiran Ayyagari a écrit :
> > I propose to convert the classes PartitionReadTxn and PartitionWriteTxn
> > to interfaces so that new Txn implementations need not be restricted to
> > Java inheritance's single parent restriction.
> >
> > These classes currently do not hold any logic so making such a change
> will
> > not
> > break the existing code in the trunk.
> >
> > Please let me know if there are any objections to this.
>
> Actually, the problem is that the PartitionReadTxn class maydo nothing,
> but it has to be instanciated at some point, something thatis quite hard
> to do with an interface ;-)
>
>
> Now, the current logic is not necessarily the best.
>
> We could draw a better hierarchy, like :
>
> (PartitionTxn) o- [[AbstractPartitionTxn]]
>   o ^
>   | |
>   +-- (PartitionReadTxn) <--- [PartitionReadTxnImpl]
>   | ^
>   | |
>   +-- (PartitionWriteTxn) <-- [PartitionWriteTxnImpl]
>
> where PartitionTxn, PartitionReadTxn, PartitionWriteTxn are interfaces,
> with an abstract class that implement the common methods and Impl for
> the needed instanciation.
>
> wdyt ?
>
I just created additional impl classes after converting them into
interfaces. I do however think that it would
be better to distinguish a read txn from a write txn my using an internal
flag, but that will be a bigger change and subject to another thread.

>
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
> Kiran

[ApacheDS] converting PartitionReadTxn and PartitionWriteTxn to interfaces

[Kiran Ayyagari]

I propose to convert the classes PartitionReadTxn and PartitionWriteTxn
to interfaces so that new Txn implementations need not be restricted to
Java inheritance's single parent restriction.

These classes currently do not hold any logic so making such a change will
not
break the existing code in the trunk.

Please let me know if there are any objections to this.

Thank you.

Kiran

Re: LDAP API dependency & N/L

[Kiran Ayyagari]

On Mon, Sep 3, 2018 at 1:09 PM, Emmanuel Lécharny 
wrote:

> Hi !
>
> I have checked all the LDAP API dependencies this week-end. We don't
> have many being used in the resulting package, most of them are just
> used for tests.
>
> Here are the 'compile' scope dependencies :
>
> org.slf4j:slf4j-api:jar:1.7.25
> org.slf4j:slf4j-log4j12:jar:1.7.25
> log4j:log4j:jar:1.2.17
> antlr:antlr:jar:2.7.7
> org.apache.servicemix.bundles:org.apache.servicemix.bundles.
> antlr:jar:2.7.7_5
> org.apache.servicemix.bundles:org.apache.servicemix.bundles.
> dom4j:jar:1.6.1_5
> org.apache.servicemix.bundles:org.apache.servicemix.bundles.
> xpp3:jar:1.1.4c_7
> xml-apis:xml-apis:jar:1.0.b2
>
> That means the licenses for those dependencies must be present and
> up-todate in our N&L.
>
> o slf4j 1.7.25 : we are still referencing the slf4j 1.7.10 license. I
> changed that (note that the current version's license [1] date stops at
> 2017, I have contacted Ceki about it)
>
> o log4j 1.2.17: this is an apache project, and version 1.X has reached
> EOL in 2015 It's about time to upgrade to 2.11.1, the latest version
>
> I noticed so delay in startup time when log4j 2.x is used, I suspect that
latest log4j version takes a bit more
time to initialize, I have never encountered this with lg4j1.x.
In either case I think it is a good idea to limit the scope of log4j
dependency to tests and let the API users
decide on the logging implementation to plug.

It won't be an incompatible change because API code uses sl4j.

> o antlr 2.7.7: surprisingly, there is nothing about it in LICENSE, but
> OTOH, its license [2] does not require we add it. Credits is (lightly)
> given in the distribution NOTICE file. I do think we should give credit
> to antlr in a more visible place, like on the web site ([3])
>
> o xml-apis is an Apache jar, from xml-commons
>
> o servicemix bundle : those are the one that I have to investgate. Here,
> there are 3 transitive dependencies, and we need to check if we
> reference teh license properly
>
> [1] https://www.slf4j.org/license.html
> [2] http://www.antlr2.org/license.html
> [3] http://directory.apache.org/special-thanks.html
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
> Kiran

[jira] [Commented] (DIRSERVER-2206) RefinementEvaluator fails when "objectClass" attribute is not present in the list of attributes

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136802#comment-16136802
 ] 

Kiran Ayyagari commented on DIRSERVER-2206:
---

Added a test in SearchIT of core-integ module (rev. 1805759).

> RefinementEvaluator fails when "objectClass" attribute is not present in the 
> list of attributes
> ---
>
> Key: DIRSERVER-2206
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2206
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M24
>Reporter: Kiran Ayyagari
> Fix For: 2.0.0-M25
>
> Attachments: allowreadusers.ldif
>
>
> I have a ACI that filters entries based on the the {{classes}} protected item 
> but when
> the search request doesn't contain {{objectClass}} in the requested 
> attributes the below
> exception is thrown.
> {noformat}
> org.apache.directory.api.ldap.model.message.SearchRequestImpl@c452319: 
> ERR_296 objectClasses cannot be null:
> java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
>   at 
> org.apache.directory.server.core.api.subtree.RefinementEvaluator.evaluate(RefinementEvaluator.java:65)
>   at 
> org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.isRelated(RelatedProtectedItemFilter.java:213)
>   at 
> org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.filter(RelatedProtectedItemFilter.java:86)
>   at 
> org.apache.directory.server.core.authz.support.ACDFEngine.hasPermission(ACDFEngine.java:160)
>   at 
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.filter(AciAuthorizationInterceptor.java:1368)
>   at 
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.access$200(AciAuthorizationInterceptor.java:91)
>   at 
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor$AuthorizationFilter.accept(AciAuthorizationInterceptor.java:1428)
>   at 
> org.apache.directory.server.core.api.filtering.EntryFilteringCursorImpl.next(EntryFilteringCursorImpl.java:454)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.writeResults(SearchRequestHandler.java:380)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.doSimpleSearch(SearchRequestHandler.java:840)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleIgnoringReferrals(SearchRequestHandler.java:1164)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleWithReferrals(SearchRequestHandler.java:1258)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:212)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:92)
>   at 
> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:222)
>   at 
> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
>   at 
> org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:243)
>   at 
> org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
>   at 
> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
>   at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
>   at 
> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:476)
>   at 
> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:430)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Steps to reproduce:
> # Apply the allowreadusers.ldif
> # restart the server
> # run the command ldapsearch -H ldap://localhost:10389 -D "" -b 
> "uid=kayyagari,ou=Users,dc=example,dc=com" -s base -a always 
> "(objectClass=*)" "uid"
> Note that if you request "objectClass" attribute along with "uid" then the 
> request succeeds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DIRSERVER-2206) RefinementEvaluator fails when "objectClass" attribute is not present in the list of attributes

[Kiran Ayyagari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Ayyagari updated DIRSERVER-2206:
--
Description: 
I have a ACI that filters entries based on the the {{classes}} protected item 
but when
the search request doesn't contain {{objectClass}} in the requested attributes 
the below
exception is thrown.
{noformat}
org.apache.directory.api.ldap.model.message.SearchRequestImpl@c452319: ERR_296 
objectClasses cannot be null:
java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
at 
org.apache.directory.server.core.api.subtree.RefinementEvaluator.evaluate(RefinementEvaluator.java:65)
at 
org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.isRelated(RelatedProtectedItemFilter.java:213)
at 
org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.filter(RelatedProtectedItemFilter.java:86)
at 
org.apache.directory.server.core.authz.support.ACDFEngine.hasPermission(ACDFEngine.java:160)
at 
org.apache.directory.server.core.authz.AciAuthorizationInterceptor.filter(AciAuthorizationInterceptor.java:1368)
at 
org.apache.directory.server.core.authz.AciAuthorizationInterceptor.access$200(AciAuthorizationInterceptor.java:91)
at 
org.apache.directory.server.core.authz.AciAuthorizationInterceptor$AuthorizationFilter.accept(AciAuthorizationInterceptor.java:1428)
at 
org.apache.directory.server.core.api.filtering.EntryFilteringCursorImpl.next(EntryFilteringCursorImpl.java:454)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.writeResults(SearchRequestHandler.java:380)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.doSimpleSearch(SearchRequestHandler.java:840)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleIgnoringReferrals(SearchRequestHandler.java:1164)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleWithReferrals(SearchRequestHandler.java:1258)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:212)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:92)
at 
org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:222)
at 
org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
at 
org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:243)
at 
org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
at 
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
at 
org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:476)
at 
org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:430)
at java.lang.Thread.run(Thread.java:745)
{noformat}

Steps to reproduce:
# Apply the allowreadusers.ldif
# restart the server
# run the command ldapsearch -H ldap://localhost:10389 -D "" -b 
"uid=kayyagari,ou=Users,dc=example,dc=com" -s base -a always "(objectClass=*)" 
"uid"

Note that if you request "objectClass" attribute along with "uid" then the 
request succeeds.

  was:
I have a ACI that filters entries based on the the {{classes}} protected item 
but when
the search request doesn't contain {{objectClass}} in the requested attributes 
the below
exception is thrown.
{noformat}
org.apache.directory.api.ldap.model.message.SearchRequestImpl@c452319: ERR_296 
objectClasses cannot be null:
java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
at 
org.apache.directory.server.core.api.subtree.RefinementEvaluator.evaluate(RefinementEvaluator.java:65)
at 
org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.isRelated(RelatedProtectedItemFilter.java:213)
at 
org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.filter(RelatedProtectedItemFilter.java:86)
at 
org.apache.directory.server.core.

[jira] [Updated] (DIRSERVER-2206) RefinementEvaluator fails when "objectClass" attribute is not present in the list of attributes

[Kiran Ayyagari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Ayyagari updated DIRSERVER-2206:
--
Attachment: allowreadusers.ldif

> RefinementEvaluator fails when "objectClass" attribute is not present in the 
> list of attributes
> ---
>
> Key: DIRSERVER-2206
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2206
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M24
>Reporter: Kiran Ayyagari
> Fix For: 2.0.0-M25
>
> Attachments: allowreadusers.ldif
>
>
> I have a ACI that filters entries based on the the {{classes}} protected item 
> but when
> the search request doesn't contain {{objectClass}} in the requested 
> attributes the below
> exception is thrown.
> {noformat}
> org.apache.directory.api.ldap.model.message.SearchRequestImpl@c452319: 
> ERR_296 objectClasses cannot be null:
> java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
>   at 
> org.apache.directory.server.core.api.subtree.RefinementEvaluator.evaluate(RefinementEvaluator.java:65)
>   at 
> org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.isRelated(RelatedProtectedItemFilter.java:213)
>   at 
> org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.filter(RelatedProtectedItemFilter.java:86)
>   at 
> org.apache.directory.server.core.authz.support.ACDFEngine.hasPermission(ACDFEngine.java:160)
>   at 
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.filter(AciAuthorizationInterceptor.java:1368)
>   at 
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.access$200(AciAuthorizationInterceptor.java:91)
>   at 
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor$AuthorizationFilter.accept(AciAuthorizationInterceptor.java:1428)
>   at 
> org.apache.directory.server.core.api.filtering.EntryFilteringCursorImpl.next(EntryFilteringCursorImpl.java:454)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.writeResults(SearchRequestHandler.java:380)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.doSimpleSearch(SearchRequestHandler.java:840)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleIgnoringReferrals(SearchRequestHandler.java:1164)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleWithReferrals(SearchRequestHandler.java:1258)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:212)
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:92)
>   at 
> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:222)
>   at 
> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
>   at 
> org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:243)
>   at 
> org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
>   at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
>   at 
> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
>   at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
>   at 
> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:476)
>   at 
> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:430)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DIRSERVER-2206) RefinementEvaluator fails when "objectClass" attribute is not present in the list of attributes

[Kiran Ayyagari (JIRA)]

Kiran Ayyagari created DIRSERVER-2206:
-

 Summary: RefinementEvaluator fails when "objectClass" attribute is 
not present in the list of attributes
 Key: DIRSERVER-2206
 URL: https://issues.apache.org/jira/browse/DIRSERVER-2206
 Project: Directory ApacheDS
  Issue Type: Bug
Affects Versions: 2.0.0-M24
Reporter: Kiran Ayyagari
 Fix For: 2.0.0-M25


I have a ACI that filters entries based on the the {{classes}} protected item 
but when
the search request doesn't contain {{objectClass}} in the requested attributes 
the below
exception is thrown.
{noformat}
org.apache.directory.api.ldap.model.message.SearchRequestImpl@c452319: ERR_296 
objectClasses cannot be null:
java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
at 
org.apache.directory.server.core.api.subtree.RefinementEvaluator.evaluate(RefinementEvaluator.java:65)
at 
org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.isRelated(RelatedProtectedItemFilter.java:213)
at 
org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.filter(RelatedProtectedItemFilter.java:86)
at 
org.apache.directory.server.core.authz.support.ACDFEngine.hasPermission(ACDFEngine.java:160)
at 
org.apache.directory.server.core.authz.AciAuthorizationInterceptor.filter(AciAuthorizationInterceptor.java:1368)
at 
org.apache.directory.server.core.authz.AciAuthorizationInterceptor.access$200(AciAuthorizationInterceptor.java:91)
at 
org.apache.directory.server.core.authz.AciAuthorizationInterceptor$AuthorizationFilter.accept(AciAuthorizationInterceptor.java:1428)
at 
org.apache.directory.server.core.api.filtering.EntryFilteringCursorImpl.next(EntryFilteringCursorImpl.java:454)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.writeResults(SearchRequestHandler.java:380)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.doSimpleSearch(SearchRequestHandler.java:840)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleIgnoringReferrals(SearchRequestHandler.java:1164)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleWithReferrals(SearchRequestHandler.java:1258)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:212)
at 
org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:92)
at 
org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:222)
at 
org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
at 
org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:243)
at 
org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
at 
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
at 
org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:476)
at 
org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:430)
at java.lang.Thread.run(Thread.java:745)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [Mavibot] redux...

[Kiran Ayyagari]

On Tue, Jun 13, 2017 at 2:48 PM, Emmanuel Lécharny 
wrote:

> Hi guys !
>
>
> 3 months without touching this beast, I was quite busy enjoying the new
> little me, vacations and API/ApacheDS release (which took me one full
> week) ! So I have been able to put some thought on mental paper last weeks.
>
>
> I came to realize that teh way we process updates is not completly
> correct, and need to be amended. Here are two items that need to be
> refactored :
>
>
> BtreeOfBtrees
>
> -
>
> This B-tree is supposed to hold all the existing revisions for all the
> existing B-trees (until a B-tree/revision is not anymore in use). There
> are two problems with this approach :
>
> o although it's necessary to be able to retrieve an old revision for a
> given b-tree (because a read transaction is still alive and needs access
> to it), we don't need to store that information on disk, because if the
> system is stopped, then all those old revisions are simply useless - we
> just need the latest revision for each B-tree -. That means we most
> certainly don't need to keep a B-tree for that purpose, we can simply
> have a Map in memory that is serialiazed when a write
> transaction is committed. The serialized data would just be teh offset
>
+1

> of the latest B-tree rootPage, so 8 bytes. That will be a very dense way
> to store this information, and it means we will write way less pages on
> disk, compared to a standard B-tree update (we are talking about 1 page
> being written (for a 512 bytes page, which can hold 63 B-tree offsets),
> compared to a B-tree header plus as many nodes and leaves written for an
> updated B-tree.
>
> We would also save time at startup, as we won't have anymore to remove
> all the dead versions. Not that it's critical, but if we can avoid doing
> so, great. OTOH, we will have to fetch the info from the disk for each
> B-tree we haven't yet accessed. Not such a hassle though (either we do
> it for all teh B-trees at the beginning, or we wait until a B-tree is
> accessed teh first time to do so).
>
>
> o The more important problem is that we currently do updates on a B-tree
> instance, like :
>
> btree.insert( writeTxn, key, value );
>
> This is not good, because in a multi-threaded environment the btree may
> be used by more than one thread. Of course, we will have some locks
> pending for an update, but if the btree is used by readers, we can't
> conveniently make it using one specific version, unless we make the
> B-tree stateless and immutable (that means the btree instance doesn't
> know anything about its current revision, which is handled by the
> transaction).
>
> Another option would be to move the functionality to the RecordManager :
>
> recordManager.insert( writeTxn, "test", key, value );
>
> this model is identical to what many other popular KV stores do and should
definitely be the way to go IMO. Exposing the lower-layer (i.e BTree here)
makes
implementation unnecessarily complex.

> Here, we tell the RM to fetch the b-tree by its name, and to add the .
>
> This second flavor is easier to implement, because we have one single
> access point.
>
>
> OTOH, we can make teh first flavor working, but it's more complex, and
> it requires some substancial modifications on teh way the B-tree is
> implemented.
>
>
> I still have to think more about it.
>
>
> More to come later !
>
>
>
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
> Kiran

Re: [VOTE] Apache LDAP API 1.0.0 release

[Kiran Ayyagari]

The module api-integ-osgi2 failed to build(jdk8 on OS X) which I believe is
due to the surefire
plugin issue discussed earlier in this thread.

I am casting my +1 cause this is not a blocker.

On Fri, Jun 2, 2017 at 5:31 AM, Emmanuel Lecharny 
wrote:

> Hi,
>
>   This is a vote for the final release candidate of the 1.0.0 LDAP
> API/Shared.
>
> This is a bug fix release, and mainly a closure of the 1.0 version.
>
> One critical bug has been fixed :
>
>  Bugs :
> --
>
>   * [DIRAPI-227  
> ] -
> Bind user dn and password sent in clear after receiving PROTOCOL_ERROR 
> during ldaps connection 
> Some fixes have also been applied in the syntex-checkers, which are now 
> immutable.
>
>
> The revision :
> http://svn.apache.org/viewvc?rev=1797299&view=rev
>
>
> The SVN tag:http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0 
> 
>
> The source and binary distribution 
> packages:https://dist.apache.org/repos/dist/dev/directory/api/1.0.0 
> 
>
> The staging 
> repository:https://repository.apache.org/content/repositories/orgapachedirectory-1134
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Kiran

Re: [VOTE] Apache DS 2.0.0-M24 release

[Kiran Ayyagari]

+1
Built from tag using jdk8 on OS X.

Thanks Emmanuel and sorry for not being around these days.

On Sun, Jun 4, 2017 at 1:01 AM, Emmanuel Lecharny 
wrote:

> Hi,
>
> This is mainly a maintenance release, and it's needed to be able to
> release Studio with many fixes related to the server itself. The main fixes
> are related to SyntaxCheckers, which are now immutable, and the switch to
> LDAP 1.0.0 which fixes a critical SSL issue. Otherwise, the 'repair'
> command has been fixed, and a thread leak has been fixed.
>
>
> Here are the fixed issues :
>
>
> Bugs :
> --
>
>  * [DIRSERVER-2190 <https://issues.apache.org/jira/browse/DIRSERVER-2190>]
> - there is thread leak when did following operations:
> ADD,DELETE,MODIFY,MOVE,RENAME
> * [DIRSERVER-2173 <https://issues.apache.org/jira/browse/DIRSERVER-2173>]
> - Linux binary installation fails because RUN_AS_GROUP not used in chown
> commands
> * [DIRSERVER-2121 <https://issues.apache.org/jira/browse/DIRSERVER-2121>]
> - ApacheDS fails * * [DIRSERVER-2072 <https://issues.apache.org/
> jira/browse/DIRSERVER-2072>] - to start after upgrading to 2.0.0-M21
> Documentation For Kerberos Configuration Needs To Be Updated
>
>
>
> Improvements :
> --
>
>   * [DIRSERVER-2186 <https://issues.apache.org/jira/browse/DIRSERVER-2186>]
> - Fix repair command
>
>
>
>
> Here are the associated links :
>
> ApacheDS 2.0.0-M24
> --
> - SVN tag :
>
> http://svn.apache.org/viewvc?rev=1797497&view=rev
>
>
>
> https://svn.apache.org/repos/asf/directory/apacheds/tags/2.0.0-M24/
>
> - Nexus repository:
> https://repository.apache.org/content/repositories/
> orgapachedirectory-1235/
>
> - Distribution packages and sources :
> https://dist.apache.org/repos/dist/dev/directory/apacheds/2.0.0-M24/
>
>
> [ ] +1 : release ApacheDS 2.0.0-M24
> [ ] ± 0 : I don't care
> [ ] -1 : No, don't release ApacheDS 2.0.0-M24
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Kiran Ayyagari

Re: [vote] Gtant Brian Burch commit access to the apacheds-site

[Kiran Ayyagari]

+1

On Wed, Apr 19, 2017 at 6:47 PM, Shawn McKinney 
wrote:

> +1
>
> Shawn
>
> > On Apr 19, 2017, at 7:12 AM, Gerard Gagliano 
> wrote:
> >
> > +1
> >
> > --
> >> On Apr 19, 2017, at 2:42 AM, Colm O hEigeartaigh 
> wrote:
> >>
> >> +1.
> >>
> >> Colm.
> >>
> >> On Wed, Apr 19, 2017 at 6:35 AM, Stefan Seelmann <
> m...@stefan-seelmann.de> wrote:
> >> +1
> >>
> >> On 04/19/2017 04:15 AM, Emmanuel Lécharny wrote:
> >> > Hi guys,
> >> >
> >> >
> >> > we don't anymore have a real wiki, as the web site is stored in svn. I
> >> > would like to vote Biran Burch as committer on the apaceds-site branch
> >> > of the project
> >> >
> >> >
> >> > [ ] +1 Vote Brian in
> >> >
> >> > [ ] +/- O I don't hae an opinion
> >> >
> >> > [ ] -1 No, don't vote Brian in
> >> >
> >> >
> >> > Thanks !
> >> >
> >> >
> >>
> >>
> >>
> >>
> >> --
> >> Colm O hEigeartaigh
> >>
> >> Talend Community Coder
> >> http://coders.talend.com
> >
>
> Kiran Ayyagari

Re: [ApacheDS] ads-replSearchFilter not working

[Kiran Ayyagari]

On Tue, Mar 28, 2017 at 1:42 AM, Pittman, Michael 
wrote:

> Hi,
>
>
>
> I have set up replication between some ApacheDS instances and everything
> has been working fine. I had the configuration ‘ads-replSearchFilter’ set
> to (objectClass=*) and everything was replicating as expected.
>
>
>
> I have been given requirements recently not to replicate certain entries
> and I updated the ads-replSearchFilter configuration to do this, however,
> it is not working (everything is still being replicated). Here is what I
> did:
>
>
>
> 1.  I changed the configuration ‘ads-replSearchFilter’ to
> (&(objectClass=*)(!(organizationalUnitName=hardcodedValue)))
>
> 2.  When I create an entry that I don’t want replicated I give it the
> attribute ‘organizationalUnitName=hardcodedValue’
>
>
>
> This should prevent the new entry from being replicated. I DID restart all
> of the ApacheDS servers after I made the configuration change. I also
> performed an ldapsearch with the filter ‘(&(objectClass=*)(!(
> organizationalUnitName=hardcodedValue)))’ and it correctly returned only
> the entries without the attribute ‘organizationalUnitName=hardcodedValue’.
>
>
>
>
> It’s also worth noting that the entries that I want replicated do not have
> the attribute organizationalUnitName at all. I am using ApacheDS version
> 2.0.0-M21.
>
>
>
> Any ideas why my replication search filter is not working?
>
It appears to be a bug in SyncReplRequestHandler where the entry data is
not filtered as per
the specified filter.

Can you file a bug report with the details. I won't be able to look into it
right away but still it is worth
filing a bug.

Thank you.

>
>
> Thanks,
>
>
>
> *Michael Pittman*
>
> *Software Engineer*
>
> *CRITICAL NETWORKS / HARRIS CORPORATION*
>
> Mobile: (863) 517-1910 <0863%20517%201910>
>
>
>
Kiran Ayyagari

Re: ApacheDS Twitter account policy

[Kiran Ayyagari]

On Tue, Sep 27, 2016 at 7:52 PM, Emmanuel Lécharny 
wrote:

> Hi guy,
>
>
> we do have a twitter accout for ApacheDS, which is a good thing.
> However, I wonder if it makes sense that this project's account follows
> a few person and companies :
>
> - The ASF (pretty normal)
>
> - apache_fortress (also makes sense)
>
> - Kiran, Pierre and Shawn
>
> - Symas
>
>
> I do think the last two groups are spurious. First because I don't see
> why The Apache Directory project should follow a private company's
> tweets, second because I'm afraid that the Apache Directory timeline
> could be polluted by personal messages (there are some very
> controversial politcal campain going on atm, and I don't think one
> individual opinion should be propagated to the project's subscribers...).
>
>
> I would suggest we stp following anything but The ASF and apache-fortress.
>
> +1

>
> Any objection ?
>
> nope

>
> Thanks !
>
>
Kiran Ayyagari

Re: Search engine performances...

[Kiran Ayyagari]

On Thu, Aug 11, 2016 at 5:27 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
>
> I have checked the way we process a search as we have poor performances
> with search likes : (&(cn=abc*)(objectClass=person)) (see DIRSERVER-2062).
>
>
> I have found two issues.
>
> 1) for substring filters, as we have no way to know directly how many
> candidates we will have, we do a blind guess :
>
> public long greaterThanCount( K key ) throws IOException
> {
> // take a best guess
> return Math.min( count, 10L );
> }
>
> so if the count is greater than 10, we always pick 10, regardless of the
> index size. The resulting evaluation mighjt very well be totally wrong.
> Let say we have 11 candidates that match the (objectClass=person)
> filter, but 1 candidates that match the (cn=abc*) filter, we will
> still use this filter, pulling 1 entries from the database.
>
>
> 2) for an equality filter, where the attributeType is multi-valued, like
> (objectClass=person), we will try to count the candidates. If the values
> are stored in an array, or in a sub-btree, we will read the full
> array/btree and create a set of candidates. That can be costly when we
> have thousands of candidates.
>
>
> Actually, the search engine first annotate the filter, then process it.
> The annotation step will sometime construct a set of candidates, even if
> we don't use it, just because we need to compute an estimation of what
> would be the best index to use. In the filter I shown before, the
> substring filter will simply return a count, not a set of candidates,
> while the second filter will construct a set of candidates, when the
> count is immediately available. Moerover, we discard this set when it
> gets bigger than an arbitrary number (100).
>
> I would rather propose we don't build the candidate set if the number is
> above a threshold (100, for instance), and only return the real count.
> Later on, anyway, we will build the set of candidate if this index is
> selected.
>
>
> For the first problem, I would suggest we pick a better approximation
> than a magic number (10) : what about a percentage of the index size ?
> (like 10%). If the index contains 1 entries, then the count will be
> 1000. We can even start to create the set, based on the filter, and stop
> if it gets bigger than a given nulmber (100?). This would provide a
> better value that 'guess-timating' this number...
>
>
> wdyt ?
>
> +1 to make this change and see

Kiran

Re: Studio M11 Windows Installer Test Result, was: Creating partitions (Studio M10, ApacheDS 23)

[Kiran Ayyagari]

On Thu, Aug 11, 2016 at 1:40 PM, Emmanuel Lécharny 
wrote:

> Le 06/08/16 à 19:34, Stefan Seelmann a écrit :
> > On 08/05/2016 07:33 PM, Stefan Seelmann wrote:
> >> On 08/05/2016 03:56 PM, Emmanuel Lécharny wrote:
> >>> You can try the latest version using one of the installers :
> >>> https://dist.apache.org/repos/dist/dev/directory/studio/2.0.
> 0.v20160717-M11/
> >> May I ask what is missing? Should I test the installers? I think we
> >> should rename the (espcially deb and dmg) to follow the same naming
> >> schema? Also if we have a dmg I guess the macosx.tar.gz is no longer
> >> required.
> > I tested the Windows 64bit installer. The start menu entry doesn't work,
> > the shortcut is points to "C:\Program Files\Apache Directory
> > Studio\Apache Directory Studio.exe" (note the spaces in the .exe) while
> > the actual executable is called "ApacheDirectoryStudio.exe" without
> > spaces. But direct execution of executable works fine.
> Would it be enough to change this line :
>
>
>
> to
>
>
>
> in the org.apache.directory.studio.product file to solve this issue ?
>
> (sorry, I can't test on a windows machoine, I don't have any, nor do I
> have a VM with windows atm...°
>
I can be your assistant to do this :) just commit or send me the patch

Kiran Ayyagari

Re: VOTE : add Steve Moyer, Chris Harm, Shawn Smith and Alex Haskell as Apache Directory project committers

[Kiran Ayyagari]

+1

I have worked with Steve for a while back in 2013 first on ApacheDS
Kerberos related issue and later on eSCIMo (which we tried
to continue under "Igloo" name until the spec stabilizes but it didn't take
off as expected)

On Fri, Jul 1, 2016 at 7:26 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
>
> now that we have accepted the SCIM code contribution, we have to vote in
> the four contributors :
>
>
> Alex Askell
>
> Chris Harm
>
> Shawn Smith
>
> Steve Moyer
>
>
> I personally met Steve 2 years ago (time flies !!!), and Shawn McKinney
> have worked with them a lot recently (Shawn, you can probably confirm
> and bring some more information). I do think they will be good new
> committers, and they for sure understand what is Open Source.
>
>
> So :
>
>
> [ ] +1 : vote them as committers
>
> [ ] +/- 0 : no opinion
>
>
> [ ] -1 : No, don't vote them in.
>
>
> Thanks a lot !
>
>
>
> Kiran Ayyagari
http://keydap.com

Re: [Vote] Accept Scim contribution

[Kiran Ayyagari]

On Sat, Jun 25, 2016 at 5:14 AM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
>
> two months ago, Shawn Smith wrote us to inform the Apache Directory
> project that he wanted to contribute the project he is working on with
> Steve Moyer, Christopher Harm and Alex Haskell.
>
>
> We have discussed about this proposal one month ago, but due to some
> highly busy agenda on my side, I sadly forgot to start a vote (and I
> have to be frank : would have I started the vote, I would not have had
> teh time to deal with the consequences of a positive vote). Now that I'm
> done with teh API and ApacheDS releae, and my work on the API branch, my
> agenda has cleared up.
>
>
> So here is a formal vote for the integration of this project in the
> apache Directory project, as a sub project. My opinion is that this
> would replace eSCIMo that has never been released, unless Kiran decide
> otherwise. We would naturally use the existing eSCIMo project web-site
> as a plcae-holder. One idea would also be that we could keep the eSCIMo
> name, or use SCIMple-Identity, but it would be really up to the people
> to decide.
>
> I am fine with using eSCIMo name and site

>
> If we get a positive vote, we will then have to vote the 4 people who
> participated to the code as committer - if they want to pursue their
> work, of course ! -.  But first, let's vote
>
>
> [ ] +1, accept the SCIMple-Identity project as a subproject of Apache
> Directory
>
+1, however I may not be able to spend time on this cause of the work I am
doing on another SCIM server (written in Go) and other paid work.


> [ ] +/-0 No opinion
>
> [ ] -1 : don't accept the SCIMple-Identity project.
>
>
> For the record, the code base is available at
> https://github.com/PennState/SCIMple-Identity, and it's already under a
> AL 2.0 license
> (https://github.com/PennState/SCIMple-Identity/blob/develop/LICENSE)
>
> Many thanks, and trully sorry fo rthe delayed vote !
>
> Thank you

Kiran Ayyagari
http://keydap.com

Re: [VOTE] Apache DS 2.0.0-M22 release

[Kiran Ayyagari]

+1
Built the tag using java1.8 on OS X

Thanks Emmanuel

On Sat, Jun 25, 2016 at 3:40 AM, Emmanuel Lécharny 
wrote:

> Hi,
>
> long expected, here is the vote for ApacheDS 2.0.0-M22 release. We don't
> have a lot of changes in this release, except the addition
> of a included repair mode : you can start the server with the 'repair'
> parameter, which will fix the broken indexes.
>
> This release also fixed the painful problem we have in Studio, when trying
> to save the configuration.
>
> Here are the fixed issues :
>
>
> Bugs :
> --
>
>  * [DIRSERVER-2120 <https://issues.apache.org/jira/browse/DIRSERVER-2120>]
> - apacheds init.d script always returning 0
>  * [DIRSERVER-2125 <https://issues.apache.org/jira/browse/DIRSERVER-2125>]
> - More than one value has been provided for the single-valued attribute:
> pwdAccountLockedTime
>  * [DIRSERVER-2139 <https://issues.apache.org/jira/browse/DIRSERVER-2139>]
> - IBM with IPV6
>  * [DIRSERVER-2141 <https://issues.apache.org/jira/browse/DIRSERVER-2141>]
> - Some tests are declaring user index with reverse
>
>
>
> Improvements :
> --
>
>  * [DIRSERVER-2124 <https://issues.apache.org/jira/browse/DIRSERVER-2124>]
> - Add support for modular crypt format password
>  * [DIRSERVER-2128 <https://issues.apache.org/jira/browse/DIRSERVER-2128>]
> - Uplift dependency on commons-io from 2.4 to 2.5
>
>
> New Features :
> --
>
>  * [DIRSERVER-2113 <https://issues.apache.org/jira/browse/DIRSERVER-2113>]
> - Integrate the 'partition-plumber' into ApacheDS
>  * [DIRSERVER-2129 <https://issues.apache.org/jira/browse/DIRSERVER-2129>]
> - Add the number of descendant and the number of children to entries
>
> task :
> --
>
>  * [DIRSERVER-2123 <https://issues.apache.org/jira/browse/DIRSERVER-2123>]
> - Remove reference to commons.io and use the LDAP API Fileutils class
> instead
>
>
> Here are the associated links :
>
> ApacheDS 2.0.0-M22
> --
> - SVN tag :
>
> http://svn.apache.org/viewvc?rev=1749761&view=rev
>
> https://svn.apache.org/repos/asf/directory/apacheds/tags/2.0.0-M22/
>
> - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1096/
>
> - Distribution packages and sources :
> https://dist.apache.org/repos/dist/dev/directory/apacheds/2.0.0-M22/
>
>
> [ ] +1 : release ApacheDS 2.0.0-M22
> [ ] ± 0 : I don't care
> [ ] -1 : No, don't release ApacheDS 2.0.0-M22
>
> --
> Regards, Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> Kiran Ayyagari
http://keydap.com

Re: [VOTE] Apache LDAP API 1.0.0-RC1 release

[Kiran Ayyagari]

+1

Built the tag using Java 1.7.0_79 on OS X.

Thanks Emmanuel

On Tue, Jun 14, 2016 at 1:57 PM, Emmanuel Lécharny 
wrote:

> Hi,
>
>   This is a vote for the first release candidate of the 1.0.0 LDAP
> API/Shared, 1.0.0-RC1.
>
> The proposed release is a first step toward a GA, we have fixed numerous
> issues that were pending.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> --
>
>   * [DIRAPI-243 <https://issues.apache.org/jira/browse/DIRAPI-243>] -
> Cannot get AttributeType from Attribute
>   * [DIRAPI-244 <https://issues.apache.org/jira/browse/DIRAPI-244>] -
> Error in loading schema
>   * [DIRAPI-249 <https://issues.apache.org/jira/browse/DIRAPI-249>] -
> Performance issue LDAP API 1.0.0-M31
>   * [DIRAPI-265 <https://issues.apache.org/jira/browse/DIRAPI-265>] -
> Deserialized Dn loses bytes field resulting in null dn, treated as
> Root DSE when encoded in ModifyRequests
>   * [DIRAPI-266 <https://issues.apache.org/jira/browse/DIRAPI-266>] -
> ResultCodeEnum 'NO_SUCH_OBJECT' should have message 'noSuchObject'
>   * [DIRAPI-273 <https://issues.apache.org/jira/browse/DIRAPI-273>] -
> api-ldap-net-mina bundle remains in STARTING mode
>
>   * [DIRAPI-274 <https://issues.apache.org/jira/browse/DIRAPI-274>] -
> The AttributeTypeHolder.toLdif method does not convert the m-usage
> Attribute correctly
>   * [DIRAPI-275 <https://issues.apache.org/jira/browse/DIRAPI-275>] -
> Many AttributeType are defined with the wrong m-usage
>
>   * [DIRAPI-280 <https://issues.apache.org/jira/browse/DIRAPI-280>] -
> The LdapNetworkConnection.getTimeout() method is wrong
>
>
> Improvements :
> --
>
>   * [DIRAPI-282 <https://issues.apache.org/jira/browse/DIRAPI-282>] -
> Detection of timeout in cursor.next()
>
>
> New Features :
> --
>
>   * [DIRAPI-269 <https://issues.apache.org/jira/browse/DIRAPI-269>] -
> Add support for modular crypt format password
>
>
> Tasks :
> ---
>
>   * [DIRAPI-270 <https://issues.apache.org/jira/browse/DIRAPI-270>] -
> Remove the dependency on commons.io
>
> The revision :
>
> http://svn.apache.org/viewvc?rev=1748344&view=rev
>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-RC1
>
> The source and binary distribution packages:
> https://dist.apache.org/repos/dist/dev/directory/api/
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1095/
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-RC1
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-RC1
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> Kiran Ayyagari

Re: partition-plumber

[Kiran Ayyagari]

On Tue, Jun 14, 2016 at 5:50 AM, Devin Paulsen <
devin.paul...@prioritydispatch.net> wrote:

> To launch the tool, I cd into the directory where the jar resides. And
> then run this:
>
>
>
> sudo java -jar partition-plumber.jar -d
> /var/lib/apacheds-2.0.0_M19/default/ -p dc=prioritydispatch,dc=net -e
> /home/devinp/
>
>
>
> According to the file /var/lib/apacheds-2.0.0_M19/default/conf/config.ldif,
> the ‘simpleauthenticator’ entry exists and is ready for use. Any ideas?
>
this is likely cause the tool uses version 2.0.0-M20 of ApacheDS to fix the
partition

>
>
> *Devin Paulsen*
>
> *Web Specialist*
>
Kiran Ayyagari
http://keydap.com

Re: pass certificate to LdapConnectionConfig

[Kiran Ayyagari]

On Wed, Jun 8, 2016 at 5:59 PM, Emmanuel Lécharny 
wrote:

> Le 08/06/16 à 14:21, Christos Papoulas a écrit :
> > On 08/06/16 15:16, Kiran Ayyagari wrote:
> >>
> >>
> >> On Wed, Jun 8, 2016 at 5:41 PM, Christos Papoulas
> >> mailto:pachris...@gmail.com>> wrote:
> >>
> >> I'm trying to connect to my own ldap server with the Apache
> >> Directory LDAP API for
> >> java(http://directory.apache.org/api/downloads.html) and I would
> >> like to pass a certificate to that connection. Is it possible?
> >>
> >> the only way to pass certificate is through X509KeyManager
> > Are any tutorials' links or sample code how to do that?
>
> You need to create a TrustManager, and pass it to the
>
to send a certificate we need to setup KeyManager (TrustManager is to
verify the server's
certificate)

> LdapConnectionConfig instance :
>
>
> public void connectAndBind() throws Exception
> {
> config = new LdapConnectionConfig();
> config.setLdapHost( "localhost" );
> config.setLdapPort( 10389 );
> config.setName( bindusername );
> config.setCredentials( bindpassword );
>
> TrustManagerFactory tmf = TrustManagerFactory.getInstance(
> TrustManagerFactory.getDefaultAlgorithm() );
> tmf.init( ( KeyStore ) null );
>
> config.setTrustManagers( tmf.getTrustManagers() );
> config.setUseTls( true );
> config.setSslProtocol( "TLSv1" );
> ldapNetworkConnection = new LdapNetworkConnection( config );
>
> connectionStatus = ldapNetworkConnection.connect();
> System.out.println( ( connectionStatus ) ? "Connection
> Established" : "Connection ERROR" );
> ...
>
>
> This is just an example, you will have to tune it to use teh correct
> TrustManager accoringly to the algorithm you want to use, and teh
> KeyStore you want to use.
>
Kiran Ayyagari
http://keydap.com

Re: pass certificate to LdapConnectionConfig

[Kiran Ayyagari]

On Wed, Jun 8, 2016 at 5:41 PM, Christos Papoulas 
wrote:

> I'm trying to connect to my own ldap server with the Apache Directory LDAP
> API for java(http://directory.apache.org/api/downloads.html) and I would
> like to pass a certificate to that connection. Is it possible?
>
the only way to pass certificate is through X509KeyManager

>
> Thanks,
>
>
> On 08/06/16 15:03, Kiran Ayyagari wrote:
>
>
>
> On Wed, Jun 8, 2016 at 5:13 PM, Christos Papoulas < 
> pachris...@gmail.com> wrote:
>
>> Hello list,
>>
>> Is it possible to pass a certificate file like ssl-cert.pem to the
>> LdapConnectionConfig? My sample code right now is:
>>
>> are you connecting to Apache Directory Server? if yes, then certificate
> based authentication is
> not supported.
>
> If you are connecting to any other server that supports certificate based
> authentication then
> you need to set the TrustManager and KeyManager in LdapConnectionConfig
>
>> public static LdapConnection createConnection(String host, int port,
>> String user, String pass, boolean useSSL, boolean useSSLv3)
>> throws IOException, LdapException {
>> LdapConnectionConfig connectionConfig = new
>> LdapConnectionConfig();
>>
>> if (host == null || host.isEmpty()) {
>> throw new IllegalArgumentException("Hostname is not
>> specified");
>> }
>> if(port <= 0) {
>> throw new IllegalArgumentException("The ldap port is not
>> valid");
>> }
>> connectionConfig.setLdapHost(host);
>> connectionConfig.setLdapPort(port);
>>
>> if(user!= null && user.length() > 0) {
>> connectionConfig.setName(user);
>> }
>> if(pass != null && pass.length() > 0) {
>> connectionConfig.setCredentials(pass);
>> }
>> if(useSSL == true) {
>> connectionConfig.setUseSsl(true);
>>     }
>> if(useSSLv3 == true) {
>> connectionConfig.setSslProtocol("SSLv3");
>> }
>> LdapConnection connection = new
>> LdapNetworkConnection(connectionConfig);
>>
>> connection.connect();
>> connection.bind();
>>
>> return connection;
>> }
>>
> Kiran Ayyagari
> http://keydap.com
>
>
> Kiran Ayyagari
http://keydap.com

Re: pass certificate to LdapConnectionConfig

[Kiran Ayyagari]

On Wed, Jun 8, 2016 at 5:13 PM, Christos Papoulas 
wrote:

> Hello list,
>
> Is it possible to pass a certificate file like ssl-cert.pem to the
> LdapConnectionConfig? My sample code right now is:
>
> are you connecting to Apache Directory Server? if yes, then certificate
based authentication is
not supported.

If you are connecting to any other server that supports certificate based
authentication then
you need to set the TrustManager and KeyManager in LdapConnectionConfig

> public static LdapConnection createConnection(String host, int port,
> String user, String pass, boolean useSSL, boolean useSSLv3)
> throws IOException, LdapException {
> LdapConnectionConfig connectionConfig = new
> LdapConnectionConfig();
>
> if (host == null || host.isEmpty()) {
> throw new IllegalArgumentException("Hostname is not
> specified");
> }
> if(port <= 0) {
> throw new IllegalArgumentException("The ldap port is not
> valid");
> }
> connectionConfig.setLdapHost(host);
> connectionConfig.setLdapPort(port);
>
> if(user!= null && user.length() > 0) {
> connectionConfig.setName(user);
> }
> if(pass != null && pass.length() > 0) {
> connectionConfig.setCredentials(pass);
> }
> if(useSSL == true) {
> connectionConfig.setUseSsl(true);
> }
> if(useSSLv3 == true) {
> connectionConfig.setSslProtocol("SSLv3");
> }
> LdapConnection connection = new
> LdapNetworkConnection(connectionConfig);
>
> connection.connect();
> connection.bind();
>
> return connection;
> }
>
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIRSERVER-2134) cannot modify password and home if ads-pwdmustchange true

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189184#comment-15189184
 ] 

Kiran Ayyagari commented on DIRSERVER-2134:
---

Currently when ads-pwdmustchange is set to true then the list of modifications 
sent should not contain anything other than a password modification.
Try updating the home after changing the password.

> cannot modify password and home if ads-pwdmustchange true
> -
>
> Key: DIRSERVER-2134
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2134
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.0-M21
> Environment: CentOS 7
>Reporter: Peter Jamieson
>
> I wrote the following unit test to change password and home directory 
> (contrived from looking at code) and it fails to update: -
> {code}
> @Test
> public void testUpdatePasswordAndHome() throws Exception
> {
> Dn dnUser1 = new Dn("uid=x135_Y246,ou=users,dc=intervoice,dc=int");
> Attribute newPassword = new DefaultAttribute("userPassword");
> newPassword.clear();
> newPassword.add("five5five%");
> Modification mod  = new 
> DefaultModification(ModificationOperation.REPLACE_ATTRIBUTE, newPassword);
> 
> Attribute newHome = new DefaultAttribute("homeDirectory");
> newHome.clear();
> newHome.add("/transfer");
> Modification homeMod  = new 
> DefaultModification(ModificationOperation.REPLACE_ATTRIBUTE, newHome);
> BindOperationContext bindContext = new BindOperationContext( null );
> bindContext.setCredentials( DEFAULT_PASSWORD.getBytes() );
> bindContext.setDn( dnUser1.apply( service.getSchemaManager() ) );
> bindContext.setInterceptors( service.getInterceptors( 
> OperationEnum.BIND ) );
> bindContext.addRequestControl(new PasswordPolicyImpl());
> service.getOperationManager().bind( bindContext );
> bindContext.getSession().modify(dnUser1, mod, homeMod);
> }
> {code}
> The following stacktrace happens: -
> {noformat}
> org.apache.directory.api.ldap.model.exception.LdapNoPermissionException: 
> Password should be reset before making any changes to this entry
>   at 
> org.apache.directory.server.core.authn.AuthenticationInterceptor.checkPwdMustChange(AuthenticationInterceptor.java:1208)
>   at 
> org.apache.directory.server.core.authn.AuthenticationInterceptor.processPasswordPolicydModify(AuthenticationInterceptor.java:939)
>   at 
> org.apache.directory.server.core.authn.AuthenticationInterceptor.modify(AuthenticationInterceptor.java:889)
>   at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506)
>   at 
> org.apache.directory.server.core.normalization.NormalizationInterceptor.modify(NormalizationInterceptor.java:216)
>   at 
> org.apache.directory.server.core.DefaultOperationManager.modify(DefaultOperationManager.java:886)
>   at 
> org.apache.directory.server.core.shared.DefaultCoreSession.modify(DefaultCoreSession.java:625)
>   at 
> org.apache.directory.server.core.shared.DefaultCoreSession.modify(DefaultCoreSession.java:590)
>   at 
> com.intervoice.platform.apacheds.password.test.JunitCracklibPasswordValidator.testUpdatePasswordAndHome(JunitCracklibPasswordValidator.java:154)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at 
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunne

Re: [ApacheDS] Test failures with latest JDK

[Kiran Ayyagari]

On Mon, Feb 22, 2016 at 2:44 PM, Stefan Seelmann 
wrote:

> Hi,
>
> after update to latest JDK (1.8.0_74, 1.7.0_95) some tests in
> server-integ fail. I think the cause is that since 1.8.0_71 MD5 is
> disabled[1].
>
> I think we just need to change the algorithms used when generating the
> certificates, but I don't find the place in the code where that can be
> done. Any pointers?
>
the only class which we use for generating the default certificate is
TlsKeyGenerator.java
but I think we must upgrade to a new version of bouncycastle cause
certificate is
generated using this library.

>
> Thanks,
> Stefan
>
> [1]
> http://www.oracle.com/technetwork/java/javase/8u71-relnotes-2773756.html
>
Kiran

[jira] [Commented] (DIRSERVER-2116) ApacheDS failed to start after every reboot and throwing error ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140433#comment-15140433
 ] 

Kiran Ayyagari commented on DIRSERVER-2116:
---

Please remove the {{ads-contextentry}} attribute, this time from the file 
{{/conf/ou\=config/ads-directoryserviceid\=default/ou\=partitions/ads-partitionid\=system.ldif}}.

> ApacheDS failed to start after every reboot and throwing error 
> ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!
> -
>
> Key: DIRSERVER-2116
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2116
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
> Environment: Ubuntu 14.04.3 LTS trusty
>Reporter: AADI
> Fix For: 2.0.0-M21
>
>
> HI 
> I downloaded ApcheDS Debian Package (apacheds-2.0.0-M21-amd64.deb ) 
> and installed on Ubuntu server for my personal testing of LDAP .
> It worked very well after i installed and configured on my server .
> But problems arise when my server rebooted every-time . 
> After every reboot i have to start the  ApacheDS server manually  by follwing 
> command 
> *sudo /etc/init.d/apacheds-2.0.0-M21-default start
> And immediately i got following reply 
> Starting ApacheDS - default...
> ApacheDS - default is already running. *
> But this is not true. i observed there is no process running which are 
> associated with ApacheDS  in OS 
> After referring the one of the solution given in this list i just clear the 
> pid file contents ( 
> /var/lib/apacheds-2.0.0-M21/default/run/apacheds-default.pid) and overcome 
> the first problem .
> But still it failed to start and i observed below errors in log file 
> {color:red}
> {{jvm 1| [15:51:29] ERROR 
> [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper] - Failed to start 
> the service.
> jvm 1| org.apache.directory.api.ldap.model.exception.LdapOtherException: 
> ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!
> jvm 1|at 
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:94)
> jvm 1|at 
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1813)
> jvm 1|at 
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1250)
> jvm 1|at 
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:318)
> jvm 1|at 
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:182)
> jvm 1|at 
> org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:72)
> jvm 1|at 
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) 
> }}{color} 
> i would like to know that should i reinstall the ApacheDS evertyime when 
> server reboot ?
> i tried several solutions mentioned in web to overcome this none worked for 
> me except reinstall 
>  
>   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (DIRSERVER-2116) ApacheDS failed to start after every reboot and throwing error ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138995#comment-15138995
 ] 

Kiran Ayyagari edited comment on DIRSERVER-2116 at 2/9/16 2:36 PM:
---

Can you check if the file 
{{/conf/ou\=config/ads-directoryserviceid\=default/ou\=partitions/ads-partitionid\=example.ldif}}
 has the attribute {{ads-contextentry}} if yes, please remove it and restart 
the server. 
This is just a workaround for now.


was (Author: akiran):
Can you check if the file 
{{/conf/ou\=config/ads-directoryserviceid\=default/ou\=partitions/ads-partitionid\=example.ldif}}
 has 
the attribute {{ads-contextentry}} if yes, please remove it and restart the 
server. This is just a workaround for now.

> ApacheDS failed to start after every reboot and throwing error 
> ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!
> -
>
> Key: DIRSERVER-2116
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2116
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
> Environment: Ubuntu 14.04.3 LTS trusty
>Reporter: AADI
> Fix For: 2.0.0-M21
>
>
> HI 
> I downloaded ApcheDS Debian Package (apacheds-2.0.0-M21-amd64.deb ) 
> and installed on Ubuntu server for my personal testing of LDAP .
> It worked very well after i installed and configured on my server .
> But problems arise when my server rebooted every-time . 
> After every reboot i have to start the  ApacheDS server manually  by follwing 
> command 
> *sudo /etc/init.d/apacheds-2.0.0-M21-default start
> And immediately i got following reply 
> Starting ApacheDS - default...
> ApacheDS - default is already running. *
> But this is not true. i observed there is no process running which are 
> associated with ApacheDS  in OS 
> After referring the one of the solution given in this list i just clear the 
> pid file contents ( 
> /var/lib/apacheds-2.0.0-M21/default/run/apacheds-default.pid) and overcome 
> the first problem .
> But still it failed to start and i observed below errors in log file 
> {color:red}
> {{jvm 1| [15:51:29] ERROR 
> [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper] - Failed to start 
> the service.
> jvm 1| org.apache.directory.api.ldap.model.exception.LdapOtherException: 
> ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!
> jvm 1|at 
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:94)
> jvm 1|at 
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1813)
> jvm 1|at 
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1250)
> jvm 1|at 
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:318)
> jvm 1|at 
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:182)
> jvm 1|at 
> org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:72)
> jvm 1|at 
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) 
> }}{color} 
> i would like to know that should i reinstall the ApacheDS evertyime when 
> server reboot ?
> i tried several solutions mentioned in web to overcome this none worked for 
> me except reinstall 
>  
>   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRSERVER-2116) ApacheDS failed to start after every reboot and throwing error ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138995#comment-15138995
 ] 

Kiran Ayyagari commented on DIRSERVER-2116:
---

Can you check if the file 
{{/conf/ou\=config/ads-directoryserviceid\=default/ou\=partitions/ads-partitionid\=example.ldif}}
 has 
the attribute {{ads-contextentry}} if yes, please remove it and restart the 
server. This is just a workaround for now.

> ApacheDS failed to start after every reboot and throwing error 
> ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!
> -
>
> Key: DIRSERVER-2116
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2116
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M21
> Environment: Ubuntu 14.04.3 LTS trusty
>Reporter: AADI
> Fix For: 2.0.0-M21
>
>
> HI 
> I downloaded ApcheDS Debian Package (apacheds-2.0.0-M21-amd64.deb ) 
> and installed on Ubuntu server for my personal testing of LDAP .
> It worked very well after i installed and configured on my server .
> But problems arise when my server rebooted every-time . 
> After every reboot i have to start the  ApacheDS server manually  by follwing 
> command 
> *sudo /etc/init.d/apacheds-2.0.0-M21-default start
> And immediately i got following reply 
> Starting ApacheDS - default...
> ApacheDS - default is already running. *
> But this is not true. i observed there is no process running which are 
> associated with ApacheDS  in OS 
> After referring the one of the solution given in this list i just clear the 
> pid file contents ( 
> /var/lib/apacheds-2.0.0-M21/default/run/apacheds-default.pid) and overcome 
> the first problem .
> But still it failed to start and i observed below errors in log file 
> {color:red}
> {{jvm 1| [15:51:29] ERROR 
> [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper] - Failed to start 
> the service.
> jvm 1| org.apache.directory.api.ldap.model.exception.LdapOtherException: 
> ERR_250_ENTRY_ALREADY_EXISTS dc=example,dc=com already exists!
> jvm 1|at 
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:94)
> jvm 1|at 
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1813)
> jvm 1|at 
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1250)
> jvm 1|at 
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:318)
> jvm 1|at 
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:182)
> jvm 1|at 
> org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:72)
> jvm 1|at 
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) 
> }}{color} 
> i would like to know that should i reinstall the ApacheDS evertyime when 
> server reboot ?
> i tried several solutions mentioned in web to overcome this none worked for 
> me except reinstall 
>  
>   



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Database corruption repair tool

[Kiran Ayyagari]

On Fri, Jan 29, 2016 at 8:40 PM, Emmanuel Lécharny 
wrote:

> Le 29/01/16 15:51, Zheng, Kai a écrit :
> >>> I'm most certainly overdoing : the first step is to start the server,
> which is all but a good idea. I have to simply read the configuration
> instead, because this is all what I need.
> > You mean it doesn't have to use or start a server to run the repair
> process, right.
>
> Right. We just need to know where to find the data, and which index are
> to be recreated. This is described in the configuration partition. We
> also have to know about the schema, thus be able to read it.
>
> > If so it sounds good, because purely running a repair tool against the
> database would be easy to use. Later it can also be a healthy check tool.
>
> Ideally, we should be able to start the server in repair mode. This is
> what we do when we define a new index : you don't have to create the
> index files, it's done at startup (actually, this is automatic, we see
> that an index table is missing, and we create it).
>
> That makes me thing that a repair mode would be much simpler than
> starting the server with a 'repair' parameter : it's enough to delete
> all the indexes, they will be recreated at startup !!! (Actually, t
> won't work simply because we recreate the user index, not the system
> indexes, but the idea is brillant : we just have to check the system
> index and rebuild them if missing... I'll do that this week-end !)
>
it is not easy for the server to detect a corrupted database, and
"deleting" index files
is a manual step which requires internal knowledge about the installation
directory
instead passing a -repair flag is much easier.

Upon seeing the -repair flag the server can just delete the index files
before initializing
the partitions then the respective partitions can take care of re-building
the indices.

>
> Thanks Kai : you again proved that discussing a pb is the best way to
> see a better way to deal with it :-)
>
>

Re: [Fortress]Developers List

[Kiran Ayyagari]

On Thu, Jan 28, 2016 at 7:41 PM, Shawn McKinney 
wrote:

> Fellow Dev's,
>
> We’ve just added a new committer to fortress, and my goal is to add a few
> more before long.  My question is which list to use for communicating?  In
> the past, with our limited discussions, we’ve used the fortress list.  But
> that list is (supposed to be) for users.  We could use the directory dev
> list, with fortress label added to the subject line.  But I’m wondering if
> it is time to add a list specific to fortress dev topics.
>
> the traffic is limited on dev list at the moment, so I think your proposal
makes sense to follow at least for
a few months

> WDYT?
>
> Shawn
>
>
>
>
>
>

Welcome to Chris Pike, our new team member

[Kiran Ayyagari]

Hi Chris,

Your Apache account(cpike) has been created and you should be able to
commit to any of the Apache Directory sub-projects.

A good test to check if everything working fine is that you add yourself to
the list of committers at this location
https://svn.apache.org/repos/asf/directory/site/trunk/content/team.mdtext

The team page is generated from the website repository (
https://svn.apache.org/repos/asf/directory/site/trunk/).
You can view the changes you just made going here
http://directory.apache.org/team.html

A warm welcome to you!

Kiran Ayyagari
http://keydap.com

Re: Database corruption, some interesting finding !

[Kiran Ayyagari]

On Mon, Jan 25, 2016 at 5:09 PM, Emmanuel Lécharny 
wrote:

> Le 25/01/16 12:33, Kiran Ayyagari a écrit :
> > On Mon, Jan 25, 2016 at 4:51 PM, Emmanuel Lécharny 
> > wrote:
> >
> >> Hi guys,
> >>
> >> while working on the repair() function, iI found something very
> >> interesting.
> >>
> >> When we update a partition, at the end, we call the sync() method which
> >> writes down on disk all the updates which are pending in memory. This
> >> sync() method itself sync all the indexes :
> >>
> >> /**
> >>  * This method is called when the synch thread is waking up, to
> write
> >>  * the modified data.
> >>  *
> >>  * @throws Exception on failures to sync database files to disk
> >>  */
> >> public synchronized void sync() throws Exception
> >> {
> >> if ( !initialized )
> >> {
> >> return;
> >> }
> >>
> >> // Sync all system indices
> >> for ( Index idx : systemIndices.values() )
> >> {
> >> idx.sync();
> >> }
> >>
> > the above call should cover this case cause JdbmRdnIndex extends
> JdbmIndex
>
> Damn it, I'm wrong... The rdnIndex is covered. Here is the list of
> system indexes :
>
> {
> 2.5.4.0=Index,
> 1.3.6.1.4.1.18060.0.4.1.2.3=Index,
> 1.3.6.1.4.1.18060.0.4.1.2.5=Index,
> 1.3.6.1.4.1.18060.0.4.1.2.6=Index,
> 1.3.6.1.4.1.18060.0.4.1.2.7=Index<1.3.6.1.4.1.18060.0.4.1.2.7>, //
> The Alias index
> 1.3.6.1.4.1.4203.666.1.7=Index,
> 1.3.6.1.4.1.18060.0.4.1.2.50=Index<1.3.6.1.4.1.18060.0.4.1.2.50>, //
> The RDN index <
> 2.5.18.5=Index
> }
>
> Sorry...
>
nah, you uncovered a far more serious issue with the repair tool regarding
RDN index child counts

Re: Database corruption, some interesting finding !

[Kiran Ayyagari]

On Mon, Jan 25, 2016 at 4:51 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
> while working on the repair() function, iI found something very
> interesting.
>
> When we update a partition, at the end, we call the sync() method which
> writes down on disk all the updates which are pending in memory. This
> sync() method itself sync all the indexes :
>
> /**
>  * This method is called when the synch thread is waking up, to write
>  * the modified data.
>  *
>  * @throws Exception on failures to sync database files to disk
>  */
> public synchronized void sync() throws Exception
> {
> if ( !initialized )
> {
> return;
> }
>
> // Sync all system indices
> for ( Index idx : systemIndices.values() )
> {
> idx.sync();
> }
>
the above call should cover this case cause JdbmRdnIndex extends JdbmIndex

>
> // Sync all user defined userIndices
> for ( Index idx : userIndices.values() )
> {
> idx.sync();
> }
>
> // Sync the master table
> ( ( JdbmMasterTable ) master ).sync();
> }
>
> Sadly, the rdnIndex is *never* flushed explicitely - so it's done only
> periodically (every 2000 updates, the default):
>
> /**
>  * Commit the modification on disk
>  *
>  * @param recordManager The recordManager used for the commit
>  */
> private void commit( RecordManager recordManager ) throws IOException
> {
> if ( commitNumber.incrementAndGet() % 2000 == 0 )
> {
> sync();
> }
> }
>
>
> This is *BAD*. That means we may have some pending modifications of this
> RDN index that are not written on disk when we stop the server or when
> we have a crash :/
>
> Adding a rdnIdx.sync() might be just enough to eliminate the corruptions
> we see...
>
>
> In any case, we still need the repair tool.
>
>

Re: Package creation for Canonical PPA ?

[Kiran Ayyagari]

On Thu, Jan 21, 2016 at 3:39 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
> one person asked if we were to create a PPA package for Ubuntu. FTR (I
> had no idea what it was), a PPA is a Personal Package Archive
> (https://help.launchpad.net/Packaging/PPA), so basically, a repository
> that you can create and that wll contain your own packages. It may be
> useful in a company that develops their own packages, when they want to
> make them available to all their computers.
>
> IMHO, it seems totally overkilling, unless someone wants to take care of
> it and maintain it (I won't). And there is a coraletral problem : how
> will we manage to setup a correct version of Java if we provide an
> ApacheDS package ?
>
> this is the blocker when I tried to work on a PPA sometime ago, Oracle Java
is not available in the public repos and we have never tested the server
with IcedTea and OpenJDK.

Thoughts ?
>
>

Re: [VOTE] Apache DS 2.0.0-M21 release

[Kiran Ayyagari]

built the tag with java7 on OS X, (didn't encounter any errors that Stefan
had during build)

[X] +1 : release ApacheDS 2.0.0-M21

On Fri, Dec 18, 2015 at 8:34 PM, Emmanuel Lécharny 
wrote:

> Hi,
>
> now that the vote for a new Apache LDAP API 1.0.0-M33 is out, it's also
> time for a new release of ApacheDS 2.0.0-M21.
>
> Another bug fix release, nothing really important in it, but we need it
> for Studio.
>
>
> The list of fixed bugs and improvments is the following :
>
>
> Bugs :
> --
>
>  * [DIRSERVER-2108 <https://issues.apache.org/jira/browse/DIRSERVER-2108>]
> - Update Apache Commons Collections to 3.2.2 due to vulnerability in 3.2.1
> <https://issues.apache.org/jira/browse/DIRSERVER-2108>
>  * [DIRSERVER-2100 <https://issues.apache.org/jira/browse/DIRSERVER-2100>]
> - Zip file does not unpack cleanly on case-insensitive OSes
> <https://issues.apache.org/jira/browse/DIRSERVER-2100>
>  * [DIRSERVER-2085 <https://issues.apache.org/jira/browse/DIRSERVER-2085>]
> - The PasswordPolicyConfiguration holds the password attribute as a String
> <https://issues.apache.org/jira/browse/DIRSERVER-2085>
>  * [DIRSERVER-2082 <https://issues.apache.org/jira/browse/DIRSERVER-2082>]
> - User is allowed to perform all operations even when password must be
> reset <https://issues.apache.org/jira/browse/DIRSERVER-2082>
>  * [DIRSERVER-2075 <https://issues.apache.org/jira/browse/DIRSERVER-2075>]
> - apacheds.sh creates a file called '0' during stop action
> <https://issues.apache.org/jira/browse/DIRSERVER-2075>
>
>
> Improvements :
> --
>  * [DIRSERVER-1901 <https://issues.apache.org/jira/browse/DIRSERVER-1901>]
> - subschemaSubentry attribute only available under root DSE
> <https://issues.apache.org/jira/browse/DIRSERVER-1901>
>  * [DIRSERVER-2080 <https://issues.apache.org/jira/browse/DIRSERVER-2080>]
> - Add a way to politely stop apacheds from apacheds.sh
> <https://issues.apache.org/jira/browse/DIRSERVER-2080>
>  * [DIRSERVER-2084 <https://issues.apache.org/jira/browse/DIRSERVER-2084>]
> - Admin user should be exempt from the pwdHistory check
> <https://issues.apache.org/jira/browse/DIRSERVER-2084>
>
>
>
> Tasks :
> ---
>  * [DIRSERVER-2096 <https://issues.apache.org/jira/browse/DIRSERVER-2096>]
> - Fix violations of coding standards and enable checkstyle check
> <https://issues.apache.org/jira/browse/DIRSERVER-2096>
>
>
>
>
>  Here are the associated links :
>
> ApacheDS 2.0.0-M21
> --
> - SVN tag :
>
> http://svn.apache.org/viewvc?rev=1720754&view=rev
>
> https://svn.apache.org/repos/asf/directory/apacheds/tags/2.0.0-M21/
>
> - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1046/
>
> - Distribution packages:
> http://people.apache.org/~elecharny
>
>
> [ ] +1 : release ApacheDS 2.0.0-M21
> [ ] ± 0 : I don't care
> [ ] -1 : No, don't release ApacheDS 2.0.0-M21
>
> --
> Regards, Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [VOTE] Apache LDAP API 1.0.0-M33 release

[Kiran Ayyagari]

built the tag with java7 on OS X

[X] +1 Release Shared/LDAP API 1.0.0-M33

On Fri, Dec 18, 2015 at 2:25 PM, Emmanuel Lécharny 
wrote:

> Hi,
>
>   This is a vote for the 33th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M33.
>
> A bug fix releases. We have an improved version of the Ldif anonymizer
> that handles Change records, and a few other fixes (OID handling...)
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> --
>
> DIRAPI-245 https://issues.apache.org/jira/browse/DIRAPI-245 -
> LdifUtils.convertToLdif(LdifEntry, int) does not honor the 'length'
> parameter fully
> DIRAPI-258 https://issues.apache.org/jira/browse/DIRAPI-258 - Add
> support for the Microsoft LDAP server show deleted objects control
> <https://issues.apache.org/jira/browse/DIRAPI-258>
> DIRAPI-260 https://issues.apache.org/jira/browse/DIRAPI-260 - OID
> can't process nodes which are bigger than a long
> <https://issues.apache.org/jira/browse/DIRAPI-260>
> DIRAPI-261 https://issues.apache.org/jira/browse/DIRAPI-261 - OID
> don't encode corrctly joint-iso-itu-t arcs
> <https://issues.apache.org/jira/browse/DIRAPI-261>
> DIRAPI-262 https://issues.apache.org/jira/browse/DIRAPI-262 -
> misleading message "The matched Dn should not be set when the result
> code is one of..."? <https://issues.apache.org/jira/browse/DIRAPI-262>
>
>
> Task :
> --
>
> DIRAPI-257 <https://issues.apache.org/jira/browse/DIRAPI-257> - Fix
> usage of default charset|locale|timezone and enable forbiddenapis check
> <https://issues.apache.org/jira/browse/DIRAPI-257>
>
>
>
> The revision :
>
> http://svn.apache.org/viewvc?rev=1720705&view=rev
>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M33
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1045
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M33
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M33
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [API] I'll most certainly start to cut a new release this week-end

[Kiran Ayyagari]

On Fri, Nov 20, 2015 at 6:18 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
> we have injected some major fixes in the code recently, and I may start
> a release soon. This is mainly about the OID class fix (long numbers
> weren't handled correctly which is a real problem for some OID Radovan
> is manipulating), the LdifAnonymizer has been imrpoved and a few code
> fixes have been injected by Stefan.
>
> I have also pumpd up teh commons-collection to use teh one with the
> fixed security issue.
>
> ah great, +1

> Thoughts ?
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [Mavibot] Transaction support

[Kiran Ayyagari]

ny broken things.
> I'll commit asap (may be this week-end if I have time to work on my free
> time - familly comes first !)
>
please commit it even if it is broken, I might be able to understand the
above ideas
if I read it again after looking at code

thanks Emmanuel

>
> Thanks !
>

>
> BOB : Btree-Of-Btrees, the Btree that hold the revisions in use
> CPB : Copied-Pages-Btree, the btree that holds teh list of pages that
> have been copied during an update
> RMH : RecordManager Header, the data structure that maintains the
> pointers to the BOB and CPB, both the current and previous, plus some
> extra informations, like the FreeList page
> BH :  Btree Header, the structure that stors meta-information about a
> B-tree (serializers, comparators, nb elements, pointer to the root page,
> etc)
>
>


-- 
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIR-320) ACL/ACI documentation section missing, filled with TODOs.

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14981660#comment-14981660
 ] 

Kiran Ayyagari commented on DIR-320:


bq. I had been evaluating apache-ds as well, but I gather it's not ever going 
to be ready for primetime.
Thank You, and I rightfully assume that you(or your company) are looking for a 
free lunch, and there ain't one.

> ACL/ACI documentation section missing, filled with TODOs.
> -
>
> Key: DIR-320
> URL: https://issues.apache.org/jira/browse/DIR-320
> Project: Directory
>  Issue Type: Improvement
>  Components: sitedocs
>Reporter: Julia Smith
>Assignee: Emmanuel Lecharny
>
> I had to scrounge around on the web to find content for the authorization 
> sections. Your current release's documentation's chapters are simply filled 
> with "TODO" when it comes to defining grants/denials, which is a problem for 
> people evaluating studio for use and might limit its adaptation.
> Here is the version of documentation that actually still presents content. It 
> actually works with the current version of studio.
> https://directory.apache.org/apacheds/basic-ug/3.2-basic-authorization.html1
> You  might consider incorporating it into the current release's documentation.
> Also there is little or no apparent online discussion of ACI with the 
> exception of a PDF of what looks like a PPT presentation.
> http://people.apache.org/~ersiner/apachecon-us06/ac-us-06-FR20-ErsinEr-ApacheDS_Access_Control_Administration_The_X.500_Way.pdf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Mavibot] Cursor handling

[Kiran Ayyagari]

On Mon, Oct 19, 2015 at 5:57 PM, Emmanuel Lécharny 
wrote:

> Le 19/10/15 04:37, Emmanuel Lécharny a écrit :
> > Le 19/10/15 03:24, Howard Chu a écrit :
> >> Emmanuel Lécharny wrote:
> >>> Hi,
> >>>
> >>> some thoughts about the current implementation :
> >>>
> >>> Cursor support in Mavibot
> >>> -
> >>>
> >>> The current implementation is a bit unsastifactory, and it does not
> >>> necessarily fits with the simplifications we are introducing (namely,
> >>> the removal of duplicate values). Typically, the current cursor allows
> >>> the user to move forward and backward across keys and values, when we
> >>> only need to move across keys now.
> >>>
> >>> Moving
> >>> --
> >>>
> >>> First of all, we must be able to move backward and forward. Fetching an
> >>> element is a different operation than moving, but one should still be
> >>> able to get back an element when moving. This is done through 4
> methods,
> >>> 2 which are relative, and 2 which are absolute.
> >>>
> >>> Relative moves :
> >>> next() : move forward to the net key
> >>> prev() : move forward to the net key
> >>>
> >>> Absolute moves :
> >>> next(K) : move after the given key
> >>> prev(K) : move before the given key
> >> These absolute moves seem like an extravagance. I have never seen a
> >> dbm-style library with such methods. It's more natural to have an
> >> explicit seek() method and then do a relative next/prev after that.
> > It is used for searches like (age>20). If the key 20 does not exist in
> > the B-tree, next(20) will move to the closest key above 20, and prev(20)
> > will move to the closest key below 20. If the key 20 exists, then
> > next(20) will be moved after the key 20 and prev(20) before the key 20.
> >
> > Now, we may need a seek(K) to fetch an element we know exists in the
> > Btree, to avoid having to do things like prev(K); tuple = next();
> >
> > I have to thought a bit more about the real need for those before(K) and
> > after(K) methods, wil wait for my morning shower for that : insomnia is
> > not the best timing to have a clear thought about API design decisions
> ;-)
>
> Second thought :
>
> if we want to efficiently browse forward *and* backward, the seek(K)
> method is not sufficient to correctly guess what to do when doing the
> first next or prev move when the K is not present. Either we set the
> position after K, or before K, but in any case, we have to do annoying
> things like :
>
> (NOTE : we don't check the limits here, which means some extra checks
> have to be done to see if we are at the beginning or at the end of the
> B-tree. This can also be done using exceptions)
>
> (NOTE 2 : I assume the  position is set after K if K is not existent, or
> set on K if it exists)
>
> getting the previous key
> 
>
> tuple = seek(K);
>
> if ( tuple == null )
> {
> tuple = prev();
> }
>
> getting the next key
> 
>
> tuple = seek(K);
>
> if ( tuple == null )
> {
> tuple = get();
> }
>
> If the key is present, we are done, the seek(K) will return the value.
>
> OTOH, using the before(K)/after(K), it's easier :
>
> getting the previous key
> 
>
> tuple = before(K);
>
> getting the next key
> 
>
> tuple = after(K);
>
> the before(K) and after(K) are convenient to support filters with >= and
<=  operators

> No test, not need to remember if the seek(K) method set the position
> before or after K.
>
>
> Is that extravagant, or just spurious ? I mean, we can live with
> seek(K), it does the job, I just wonder if the additional methods don't
> mke the developer lifer easier.
>
> wdyt ?
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [VOTE] Apache LDAP API 1.0.0-M32 release

[Kiran Ayyagari]

+1, built the tag using java7 on OS X 10.10.3

On Thu, Oct 15, 2015 at 1:05 AM, Emmanuel Lécharny 
wrote:

> Hi,
>
>  This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
>
>
> Another bug fix release, with some huge modifications in the way we
> handle Values. The SchemaManager
> is now propagated down to the Ava and Value classes, which causes many
> tests to have been fixed.
>
> We also have added a LdifAnonymizer that can swallow a Ldif File and
> replace the values with a
> random text.
>
> We have also spent some time fixing many checkstyle violations.
>
> A few other issues have been fixed.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> --
>
> DIRAPI-90  <https://issues.apache.org/jira/browse/DIRAPI-90> -
> IllegalArgumentException: factory thrown when creating
> LdapNetworkConnection inside OSGi
> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> Reconsider interfaces and base classes for Registries
> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
> JUnit TemporaryFolder Rule
> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> DateUtils.toGeneralizedTime does not work with some Locales
> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
> GeneralizedTime(String) fails for fraction close to one
> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> Error in parsing LDIF file
> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> Compiling warnings while api-all is in dependencies
> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
> AVA class is not handling correctly the values wrt the SchemaManager
> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> Value don't have a apply(AttributeType) method
> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
> escaped space at the end of a RDN will not be kept due to a bug in the
> ComplexDNParser
>
>
> Task :
> --
>
> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
> violations of coding standards and enable checkstyle check
>
>
> New Feature:
> -
>
> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
> a way to Anonymize a LDIF file
>
>
> Question :
> --
>
> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
> to get attributes list according to objectClass
>
>
> The revision :
>
> http://svn.apache.org/viewvc?view=revision&revision=1708634<
> http://svn.apache.org/r1676503>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> <http://people.apache.org/%7Eelecharny/>
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> <
> https://repository.apache.org/content/repositories/orgapachedirectory-1031
> >
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [ApacheDS] Require client certificate for TLS connection (SASL EXTERNAL)

[Kiran Ayyagari]

On Mon, Oct 12, 2015 at 7:55 PM, Kiran Ayyagari 
wrote:

> Hi Mike,
>
> On Mon, Oct 12, 2015 at 7:03 PM,  wrote:
>
>> Hi developers!
>>
>> First: sorry for my bad english writing, but I’m not a native speaker and
>> usually most I’m reading english texts.
>>
>>
>>
>> Currently I’m evaluating the ApacheDS LDAP server to use with a software
>> project with some special requirements.
>>
>>
>>
>> 1.   The clients have to use LDAPv3.
>>
>> 2.   The clients have to use TLS for search operations.
>>
>> 3.   The clients have to use TLS with client certificates for modify
>> operations.
>>
>>
>>
>> Is it possible to realize that requirements with ApacheDS?
>>
>>
>>
>> And as I’ve heard,  the 3. Requirement is not supported, is there an
>> opportunity to transmit a client certificate to the server, to check this
>> using an interceptor?
>>
> its been a while since I last checked for this support in the MINA network
> library that we use
> I am gonna take a look at it again and let you know in a day
>
so, I looked at it, and it is not currently possible cause the
TrustManagers in StartTLSHandler and
LdapsInitializer are hardcoded, this is easy to fix, I will try to fix this
in trunk in the future (too many things
on my plate right now).

>
>>
>> I am looking forward to get mail from you.
>>
>>
>>
>> Regards,
>>
>> Mike.
>>
>>
>>
>>
>>
>> Mike Ettrich
>> Consultant
>> -
>> arvato Systems perdata GmbH
>> Joachim-Jungius-Str. 9
>> 18059 Rostock
>>
>> E-Mail: mike.ettr...@bertelsmann.de
>> Tel.: +49 (0) 5241 / 80 402 58
>> Fax: +49 (0) 381 / 44 03 53-33
>>
>> www.arvato-systems.de
>>
>> -
>>
>> arvato Systems perdata GmbH: Sitz Leipzig | Amtsgericht Leipzig HRB 15
>> 784
>>
>> Geschäftsführer: Dr. Percy Dahm | Matthias Moeller (Vorsitzender) |
>> Thomas Nautsch
>>
>>
>> -
>> Diese E-Mail und eventuelle Anlagen können vertrauliche und/oder
>> rechtlich geschützte Informationen enthalten. Wenn Sie
>> nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
>> haben, informieren Sie bitte sofort den Absender und
>> vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
>> Weitergabe dieser E-Mail sind nicht gestattet.
>>
>>
>> -
>> This e-mail and any attachments may contain confidential and/or
>> privileged information. If you are not the intended recipient
>>
>> (or have received this e-mail in error) please notify the sender
>> immediately and destroy this e-mail. Any unauthorized copying,
>>
>> disclosure or distribution of the material in this e-mail is forbidden.
>>
>> -
>>
>> Bitte denken Sie über Ihre Verantwortung gegenüber der Umwelt nach, bevor
>> Sie diese E-Mail ausdrucken!
>>
>>
>>
>>
>>
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>



-- 
Kiran Ayyagari
http://keydap.com

Re: [VOTE] Apache LDAP API 1.0.0-M32 release

[Kiran Ayyagari]

>
>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
>>> a way to Anonymize a LDIF file
>>>
>>>
>>> Question :
>>> --
>>>
>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
>>> to get attributes list according to objectClass
>>>
>>>
>>> The revision :
>>>
>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>>> http://svn.apache.org/r1676503>
>>>
>>> The SVN tag:
>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>>>
>>> The source and binary distribution packages:
>>> http://people.apache.org/~elecharny/
>>> <http://people.apache.org/%7Eelecharny/>
>>>
>>> The staging repository:
>>>
>>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>>> <
>>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>>> >
>>>
>>>
>>> Please cast your votes:
>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>>> [ ] 0 abstain
>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>>>
>>>
>>> Emmanuel
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com <http://www.iktek.com>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>
> I pulled the tag and attempted to "mvn clean install", but i get this
> exception in the integ-osgi module:
>
> Running org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
>
> Exception in thread "main" java.rmi.ConnectException: Connection
> refused to host: 92.242.140.21; nested exception is:
> java.net.ConnectException: Connection refused
> at
> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.(RemoteFrameworkImpl.java:77)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:579)
> at java.net.Socket.connect(Socket.java:528)
> at java.net.Socket.(Socket.java:425)
> at java.net.Socket.(Socket.java:208)
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
> at
> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
> ... 7 more
>
> This is a new build VM (CentOS 7) that i created just for builds because
> they never work on windows.  Could it be SELinux?  Or maybe firewall?  Is
> there a reason its using external IP instead of loopback IP?
>
h, it didn't happen on my machine (mac OS X)



-- 
Kiran Ayyagari
http://keydap.com

Re: JDBM corruptions...

[Kiran Ayyagari]

On Wed, Oct 14, 2015 at 9:13 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
> so we have clear case where the JDBM backend get corrupted, up to a
> point a full reimport of the data is required. Lucas also proved that a
> test will fail, after haing injected 1000 entries and doing 100 rename
> (https://issues.apache.org/jira/browse/DIRSERVER-1974).
>
> This is more than annoying...
>
> I have tested DIRSERVER-1974 with Mavibot, and I can't reproduce the
> problem, which means the server is safe. The resulting database is 14 Mb
> big with the 1000 entries being added, which is big, but acceptable.
>
> At this point, I wonder if it would not be a safe approach to switch to
> Mavibot right now ?
>
> The pros :
> - we know that we can't have a database corruption, because each update
> is a new revision
> - technically, mavibot is faster than JDBM
> - we aren't maintaining JDBM, while Mavibot is under development
>
> The cons :
> - Mavibot is still under developement : we still have to add teh
> cross-btree transactions, which means that if we have a brutal crash
> during an update, then we may have some inconsistancy in the base
> (inconsitancy != corruption, but still)
> - We will still need the global write locking strategy to protect the
> backend from concurrent reads and write when a update is processed
> - The database is growing fast due to the limited cleanup we currently do
>
> However, in the middle term, Mavibot will bring the following bonuses :
> - cross btree transaction support (actually, we may even support
> multiple updates within a single transaction, speeding up the update
> even more), which will allow us to remove the global RW lock we
> currently have
> - bulkloading capacity, increasing teh speed of injecting data by at
> leats 2 orders of magnitude (server being stopped)
>
>
> So, I'll ask you : what about releasing M21 with Mavibot as a default,
> but with a possibility for users to still pick JDBM on demand ?
>
> I am in favor of that, I have tested it with the server few months ago
after
adding free page reclaiming functionality and it was _working_

The addition of entries gets slower after a point of time, but other than
that
I have not seen any other issues, this is just from one user pov though.

Server needs to modify a bit to detect the type of storage used in an
existing partition
and initialize accordingly.

-- 
Kiran Ayyagari
http://keydap.com

Re: Value handling ideas

[Kiran Ayyagari]

On Tue, Oct 13, 2015 at 2:50 AM, Emmanuel Lécharny 
wrote:

> Thoughts about value handling in the API and Server
> ---
>
> We currently manage a quite complex hierarchy of classes to handle
> attribute's values :
>
> (Value)
>   o
>   |
>   +--[[AbstractValue]]
> ^
> |
> +-- [StringValue | T : byte[]]
> |
> +-- [BinaryValue | T : String]
>
> Every Value holds a wrappedValue (aka User Provided value) and a
> normalizedValue. This second aspect is absolutely mandatory, because we
> always return the UPValue back to the user, and we always compare values
> using the normalized value (well, we can discuss that too).
>
> DN and Filters are using a String representation of values that are a
> bit specific. Typically, some chars get escaped in both cases (but not
> the same way).
>
> That is quite complex...
>
> We probably can handle those values in a different way. First of all,
> binary values aren't modified by the normalization process, so we could
> most certainly save some space by not keeping a UpValue within a
> NormValue for such values. Second, everything in LDAP is using UTF-8,
> and we can easily convert UTF-8 to Unicode (which is the default format
> for char in Java). We so have a trivial UTF-8 <--> Unicode conversion
> that could be used if needed.
>
> Last, not least every value is written either as a byte[] (binary
> values) or as a UTF-8 String, which is also a byte[]. Knowing that we
> will send back the values to the client converting them from String to
> UTF-8, we can assume that most of the case, we are doing two conversions
> (from byte[] to UTF-8 to String and then from String to UTF-8 to
> byte[]), mostly wasting a lot of CPU...
>
> +1 to experiment with this change

> Another idea would be to simply hide the byte[] unless we need to
> convert them to a String, which can be done when needed. We need to
> convert the values when we do a normalize (this happens when we want to
> compare the value to another one), or a compare. We also need to run
> every value through the PrepareString methods (and PrepSASL for the
> userPassword) before saving them to the disk.
>
> but AFAIU this conversion happens multiple times if not stored, so I still
prefer converting once and use the stored value later onwards

>
> At this point, I can forsess some huge simplification in both the API
> and the serverbu switching to a simpler data structure, and a potential
> speedup (avoiding useless conversion).
>
> I'd like you to review what I just wrote and tell me if I'm off base, or
> if you feel like me that we can get a better server by changing those
> data strcture.
>
> changing the data structure idea sounds good to me

> Thanks !
>



-- 
Kiran Ayyagari
http://keydap.com

Re: [ApacheDS] Require client certificate for TLS connection (SASL EXTERNAL)

[Kiran Ayyagari]

Hi Mike,

On Mon, Oct 12, 2015 at 7:03 PM,  wrote:

> Hi developers!
>
> First: sorry for my bad english writing, but I’m not a native speaker and
> usually most I’m reading english texts.
>
>
>
> Currently I’m evaluating the ApacheDS LDAP server to use with a software
> project with some special requirements.
>
>
>
> 1.   The clients have to use LDAPv3.
>
> 2.   The clients have to use TLS for search operations.
>
> 3.   The clients have to use TLS with client certificates for modify
> operations.
>
>
>
> Is it possible to realize that requirements with ApacheDS?
>
>
>
> And as I’ve heard,  the 3. Requirement is not supported, is there an
> opportunity to transmit a client certificate to the server, to check this
> using an interceptor?
>
its been a while since I last checked for this support in the MINA network
library that we use
I am gonna take a look at it again and let you know in a day

>
>
> I am looking forward to get mail from you.
>
>
>
> Regards,
>
> Mike.
>
>
>
>
>
> Mike Ettrich
> Consultant
> -
> arvato Systems perdata GmbH
> Joachim-Jungius-Str. 9
> 18059 Rostock
>
> E-Mail: mike.ettr...@bertelsmann.de
> Tel.: +49 (0) 5241 / 80 402 58
> Fax: +49 (0) 381 / 44 03 53-33
>
> www.arvato-systems.de
>
> -
>
> arvato Systems perdata GmbH: Sitz Leipzig | Amtsgericht Leipzig HRB 15
> 784
>
> Geschäftsführer: Dr. Percy Dahm | Matthias Moeller (Vorsitzender) | Thomas
> Nautsch
>
>
> -
> Diese E-Mail und eventuelle Anlagen können vertrauliche und/oder rechtlich
> geschützte Informationen enthalten. Wenn Sie
> nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
> haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser E-Mail sind nicht gestattet.
>
>
> -
> This e-mail and any attachments may contain confidential and/or privileged
> information. If you are not the intended recipient
>
> (or have received this e-mail in error) please notify the sender
> immediately and destroy this e-mail. Any unauthorized copying,
>
> disclosure or distribution of the material in this e-mail is forbidden.
>
> -----
>
> Bitte denken Sie über Ihre Verantwortung gegenüber der Umwelt nach, bevor
> Sie diese E-Mail ausdrucken!
>
>
>
>
>



-- 
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIRSERVER-2104) Renaming an entry which uses a SINGLE-VALUE attribute in the RDN fails

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14952820#comment-14952820
 ] 

Kiran Ayyagari commented on DIRSERVER-2104:
---

bq. I see no reason why we should reject the operation, I think we should go 
for the first option.
That is not really intuitive for a user who has directed the server _not_ to 
delete, I prefer the operation to fail explicitly rather
than dropping the old RDN to user's surprise.

> Renaming an entry which uses a SINGLE-VALUE attribute in the RDN fails
> --
>
> Key: DIRSERVER-2104
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2104
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
> Fix For: 2.0.0-M21
>
>
> There is a test ({{LdifPartitionTest.testLdifRenameAndRetainOldDN}}) that 
> does a rename, trying to keep the old RDN present :
> {code}
> Rdn newRdn = new Rdn( "dc=renamedChild1" );
> RenameOperationContext renameOpCtx = new RenameOperationContext( 
> session, childDn1, newRdn, false );
> partition.rename( renameOpCtx );
> ...
> // the renamed LDIF must contain the old an new Rdn attribute
> String content = FileUtils.readFileToString( new File( wkdir, 
> "ou=test,ou=system/dc=renamedchild1.ldif" ) );
> assertTrue( content.contains( "dc: child1" ) );
> assertTrue( content.contains( "dc: renamedchild1" ) );
> {code}
> The past passes green which is really problematic : the {{DC}} AttributeType 
> is supposed to be SINGLE-VALUE !!!
> {code}
> attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' )
>   DESC 'RFC1274/2247: domain component'
>   EQUALITY caseIgnoreIA5Match
>   SUBSTR caseIgnoreIA5SubstringsMatch
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>   SINGLE-VALUE
>   USAGE userApplications
> )
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRSERVER-2104) Renaming an entry which uses a SINGLE-VALUE attribute in the RDN fails

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14952712#comment-14952712
 ] 

Kiran Ayyagari commented on DIRSERVER-2104:
---

Does the spec define anything about the behavior when the RDN is backed by a 
single valued attribute.

I wonder if any of the spec writers implemented a decent LDAP server while 
writing the spec.


> Renaming an entry which uses a SINGLE-VALUE attribute in the RDN fails
> --
>
> Key: DIRSERVER-2104
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2104
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
> Fix For: 2.0.0-M21
>
>
> There is a test ({{LdifPartitionTest.testLdifRenameAndRetainOldDN}}) that 
> does a rename, trying to keep the old RDN present :
> {code}
> Rdn newRdn = new Rdn( "dc=renamedChild1" );
> RenameOperationContext renameOpCtx = new RenameOperationContext( 
> session, childDn1, newRdn, false );
> partition.rename( renameOpCtx );
> ...
> // the renamed LDIF must contain the old an new Rdn attribute
> String content = FileUtils.readFileToString( new File( wkdir, 
> "ou=test,ou=system/dc=renamedchild1.ldif" ) );
> assertTrue( content.contains( "dc: child1" ) );
> assertTrue( content.contains( "dc: renamedchild1" ) );
> {code}
> The past passes green which is really problematic : the {{DC}} AttributeType 
> is supposed to be SINGLE-VALUE !!!
> {code}
> attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' )
>   DESC 'RFC1274/2247: domain component'
>   EQUALITY caseIgnoreIA5Match
>   SUBSTR caseIgnoreIA5SubstringsMatch
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>   SINGLE-VALUE
>   USAGE userApplications
> )
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DIRSERVER-1974) Rename Operation Issue - ApacheDS

[Kiran Ayyagari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Ayyagari updated DIRSERVER-1974:
--
Priority: Blocker  (was: Major)

> Rename Operation Issue - ApacheDS
> -
>
> Key: DIRSERVER-1974
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1974
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: ldap
>Affects Versions: 2.0.0-M15
> Environment: Window server 2008 R2
>Reporter: Mohd Usman
>Priority: Blocker
>  Labels: build, features, patch
> Attachments: ApacheDSSchemaBrowser.png, CNAttributeInSchema.png, 
> PostRename.png, PreRename.png, SchemaViewerLDAPAdminTool.png
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Whenever we perform Rename operation on an object entry (let’s say Person 
> object), the person gets renamed successfully but the issue is that the old 
> value of the person object still remains.
> The ‘cn’ attribute contains two values now - old value and also the new value.
>  
> Example:
> I have created a person object with DN 
> "cn=person,ou=Apache,dc=example,dc=com" and I want to rename this entry to 
> "cn=person_Rename,ou=Apache,dc=example,dc=com".
> The rename operation executes successfully and the person is renamed to 
> "cn=person_Rename,ou=Apache,dc=example,dc=com". 
> But, the ‘cn’ attribute now contains 
> “person”
> “person_Rename”.
> When verified the schema, ‘cn’ attribute show as ‘single valued’ but after 
> performing the rename operation – the ‘cn’ becomes ‘multi-valued’ and 
> contains two values.
> This an issue with Apache directory which needs to be resolved. Also find the 
> screenshots attached for your reference. Please look into the same.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: ApacheDS 2.0.0 - Start up Trouble finding custom Interceptors

[Kiran Ayyagari]

On Fri, Oct 9, 2015 at 5:16 AM, Lakshmi Narasimhan, Premkumar (RIS-ORL) <
premkumar.narasim...@lexisnexis.com> wrote:

> Hi,
>
>
>
> I am trying to setup custom Authentication interceptor and during server
> start up Apache DS is not loading the jar from APACHEDS_INSTALLDIR/lib/ext
> folder.  I followed steps provided in
> https://directory.apache.org/apacheds/advanced-ug/6-implementing-interceptor.html
> which says for ApacheDS 1.5.5 not sure if still holds good for 2.0.0.
> Please provide your valuable inputs to resolve this issue.
>
not sure how you are launching, but check the launch script and see if it
is adding your jars to the classpath

>
>
> org.apache.directory.server.config.ConfigurationException: Cannot
> initialize the com.aaa.ApacheDSMBSAuthenticator, error :
> java.lang.ClassNotFoundException: com.aaa.ApacheDSMBSAuthenticator
>
>at
> org.apache.directory.server.config.builder.ServiceBuilder.createInterceptors(ServiceBuilder.java:227)
>
>at
> org.apache.directory.server.config.builder.ServiceBuilder.createDirectoryService(ServiceBuilder.java:1435)
>
>at
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:300)
>
>at
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:182)
>
>at
> org.apache.directory.server.UberjarMain.start(UberjarMain.java:76)
>
>at org.apache.directory.server.UberjarMain.main(UberjarMain.java:54)
>
>
>
> Thanks,
>
> Prem
>
> --
>  The information contained in this
> e-mail message is intended only for the personal and confidential use of
> the recipient(s) named above. This message may be an attorney-client
> communication and/or work product and as such is privileged and
> confidential. If the reader of this message is not the intended recipient
> or an agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error and that
> any review, dissemination, distribution, or copying of this message is
> strictly prohibited. If you have received this communication in error,
> please notify us immediately by e-mail, and delete the original message.
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: Thanks!

[Kiran Ayyagari]

It was indeed a pleasure, glad that I got a chance to meet you all.

thanks everyone

On Sat, Oct 3, 2015 at 4:51 PM, Pierre Smits  wrote:

> Hi Guys,
>
> Thank you very much for your talks at the ApacheCon EU 2015 event in
> Budapest, Hungary, and having the opportunities to chat and laugh together.
>
> I feel confident that your talks will have a positive effect regarding
> adoption of the Apache Directory products and growth of our community.
>
> My apologies regarding not being able to say goodbyes and to wish you a
> safe and pleasant journey home in person.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>



-- 
Kiran Ayyagari
http://keydap.com

Re: [Mavibot] ApacheCon discussions

[Kiran Ayyagari]

On Sat, Oct 3, 2015 at 2:17 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
> we had some interesting discussion with Kiran and Shawn during the
> Apache Conference this week. We spent some time on Mavibot and here are
> a few thoughts we had about it :
>
> - We should not have a support of multiple^values in Mavibot. This makes
> the code too complex to handle, and this could be done at a upper level
> (like what we have for JDBM). At the end, Mavibot should only be a
> strict Key/Value store
> - We don't need to have two flavor of BTrees (Persisted and InMemory).
> This is the Manager role : we can have a PersistedManager and a
> InMemoryManager
> - The transaction support has been lenghtly discussed, and we think we
> have a valid specification for it :
> - hat we need to explicitely start and terminate a transaction,
> instead of have an implicit start (as we currently have)
> - we need a WorkingMemory to hold modified pages
> - as we are going to modify pages instead of copying them, we need a
> different implementation fo the very basic B-tree insert/remove
> operations for this case
> - revisions will be cross-btrees, and actually will reflect the
> transaction manager revision, so we may have holes in teh numbering for
> a goven btree
> - managing versions will be done using a list with no lock
> - Cleaning up the pages can be done at teh end of an update, by what we
> now call the Recycler. We can clean old revisions, starting by the
> oldest and up the list, until we meet a revision which is in use. We can
> also cleanup not use revisions, at least for the pages that have been
> copied in the revision immediately upper.
> - Last, not least, we discussed about the fact that we may have two
> threads to manage updates and recycling : the contention will be minimal
> and teh gain can be hudge, as we won't anymore have to process with the
> cleaning after the update is completed.
>
> I'll come with some more complete explaination and document on those
> specification when back home.
>
> I have created a branch to paly with those ideas :
> mavibot/branches/single-value. This branch is where we are going to
> experiment.
>
> Thanks !
>
that is a perfect summary of all things we discussed

thanks Emmanuel



-- 
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIRSERVER-2095) apacheds-2.0.0-M19: bogus block id error

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940910#comment-14940910
 ] 

Kiran Ayyagari commented on DIRSERVER-2095:
---

LDIF partition is only used internally, not ideal for use as a regular 
partition.

> apacheds-2.0.0-M19: bogus block id error
> 
>
> Key: DIRSERVER-2095
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2095
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Reporter: Shailesh K Mishra
>Priority: Critical
>
> We are getting following error when a concurrent test (mixed of read and 
> write scenarios) is run:
> Exception in thread "main" java.lang.Error: ERR_539_BAD_BLOCK_ID bogus block 
> id -5,938,146,449,721,577,426, it should not be negative
> at jdbm.recman.BlockIo.setBlockId(BlockIo.java:138)
> at jdbm.recman.RecordFile.getNewNode(RecordFile.java:442)
> at jdbm.recman.RecordFile.get(RecordFile.java:189)
> at jdbm.recman.PhysicalRowIdManager.fetch(PhysicalRowIdManager.java:128)
> at jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:323)
> at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:264)
> at jdbm.btree.BTree.getRoot(BTree.java:552)
> at jdbm.btree.BTree.find(BTree.java:405)
> at 
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.get(JdbmTable.java:344)
> at 
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.fetch(AbstractBTreePartition.java:1264)
> at 
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.lookup(AbstractBTreePartition.java:1192)
> at 
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.doInit(JdbmPartition.java:250)
> at 
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:89)
> at 
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.addContextPartition(DefaultPartitionNexus.java:800)
> at 
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.doInit(DefaultPartitionNexus.java:224)
> at 
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:89)
> at 
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1807)
> at 
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1244)
> at 
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:323)
> at org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:182)
> at org.apache.directory.server.UberjarMain.start(UberjarMain.java:76)
> at org.apache.directory.server.UberjarMain.main(UberjarMain.java:54)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DIR-319) Replication NullPointer at SyncReplRequestHandler.java:648

[Kiran Ayyagari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Ayyagari resolved DIR-319.

Resolution: Duplicate

> Replication NullPointer at SyncReplRequestHandler.java:648
> --
>
> Key: DIR-319
> URL: https://issues.apache.org/jira/browse/DIR-319
> Project: Directory
>  Issue Type: Bug
> Environment: apacheds-all-2.0.0-M19.jar:2.0.0-M19
>Reporter: Emanuele Forlano
>Assignee: Emmanuel Lecharny
>
> Hi 
> we have some problems with SyncRepl. Following Apache documentation we set up 
> two instances of embedded ApacheDs M19. 
> In the provider we have:
> val replRequestHandler = new SyncReplRequestHandler()
> server.setReplicationReqHandler(replRequestHandler)
> in the consumer: 
>   val replicationConf = new SyncReplConfiguration
>   replicationConf.setRemoteHost("localhost")
>   replicationConf.setRemotePort(1389)
>   replicationConf.setUseTls(false)
>   replicationConf.setReplUserDn("uid=admin,ou=system")
>   replicationConf.setReplUserPassword("secret".getBytes)
>   replicationConf.setBaseDn(“o=myDn”) //replaced
>   replicationConf.setFilter("(objectClass=*)")
>   replicationConf.setRefreshInterval(6)
>   replicationConf.setRefreshNPersist(true)
>   
> replicationConf.setAliasDerefMode(AliasDerefMode.NEVER_DEREF_ALIASES)
>   val consumer: ReplicationConsumer = new 
> ReplicationConsumerImpl()
>   consumer.setConfig(replicationConf)
>   server.setReplConsumers(ApacheDSUtils.buildConsumers(consumer))
> When we run both the server we get this error: 
> org.apache.directory.api.ldap.model.exception.LdapException: 
> java.lang.RuntimeException: java.lang.NullPointerException
>   at 
> org.apache.directory.server.core.shared.DefaultCoreSession.search(DefaultCoreSession.java:1157)
>  ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
>   at 
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler.doSimpleSearch(SyncReplRequestHandler.java:648)
>  ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
>   at 
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler.doInitialRefresh(SyncReplRequestHandler.java:562)
>  ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
>   at 
> org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler.handleSyncRequest(SyncReplRequestHandler.java:311)
>  ~[apacheds-all-2.0.0-M19.jar:2.0.0-M19]
>   at 
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleReplication(SearchRequestHandler.java:240)
>  [apacheds-all-2.0.0-M19.jar:2.0.0-M19]
> Note: when I use a more specific filter for example: cn=someCn it works fine. 
> Any idea?
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Expception inserting organizationalUnit

[Kiran Ayyagari]

Manager's cache size to 100
> [17:53:38] INFO [org.apache.directory.server.core.api.CacheService] -
> fetching the cache named alias
> [17:53:38] INFO [org.apache.directory.server.core.api.CacheService] -
> fetching the cache named piar
> [17:53:38] INFO [org.apache.directory.server.core.api.CacheService] -
> fetching the cache named entryDn
> [17:53:38] INFO
> [org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition]
> - Setting CacheRecondManager's cache size to 100
> [17:53:38] INFO [org.apache.directory.server.core.api.CacheService] -
> fetching the cache named system
> [17:53:38] INFO [org.apache.directory.server.core.api.CacheService] - No
> cache with name system exists, creating one
> [17:53:39] INFO
> [org.apache.directory.server.core.security.TlsKeyGenerator] - Keys and
> self signed certificate successfully generated.
> [17:53:40] INFO [org.apache.directory.server.core.api.CacheService] -
> fetching the cache named groupCache
> [17:53:40] INFO
> [org.apache.directory.server.core.event.EventInterceptor] - Initializing
> ...
> [17:53:40] INFO
> [org.apache.directory.server.core.event.EventInterceptor] -
> Initialization complete.
> [17:53:40] WARN
> [org.apache.directory.server.core.DefaultDirectoryService] - You didn't
> change the admin password of directory service instance 'Starbuck's LDAP
> server'.  Please update the admin password as soon as possible to
> prevent a possible security breach.
> [17:53:40] DEBUG [org.apache.directory.server.OPERATION_LOG] - >>
> LookupOperation : FilteringOperationContext for Dn 'uid=admin,ou=system', *
> [17:53:40] DEBUG [org.apache.directory.server.OPERATION_LOG] - <<
> LookupOperation successful
> [17:53:40] DEBUG [org.apache.directory.server.OPERATION_LOG] - >>
> LookupOperation : FilteringOperationContext for Dn 'uid=admin,ou=system', *
> [17:53:40] DEBUG [org.apache.directory.server.OPERATION_LOG] - <<
> LookupOperation successful
> [17:53:40] INFO [org.apache.directory.server.ldap.LdapServer] -
> Successful bind of an LDAP Service (11389) is completed.
> [17:53:40] INFO [org.apache.directory.server.ldap.LdapServer] - Ldap
> service started.
> [17:53:40] DEBUG [org.apache.directory.server.OPERATION_LOG] - >>
> AddOperation : AddContext for Dn 'dc=starwit,dc=de', added entry: Entry
> dn[n]: dc=starwit,dc=de
> objectClass: top
> objectClass: domain
> dc: starwit
>
> [17:53:41] DEBUG [org.apache.directory.server.OPERATION_LOG] - <<
> AddOperation successful
> [17:53:41] DEBUG [org.apache.directory.server.OPERATION_LOG] - >>
> hasEntryOperation : HasEntryContext for Dn 'dc=starwit,dc=de'
> [17:53:41] DEBUG [org.apache.directory.server.OPERATION_LOG] - <<
> HasEntryOperation successful
> checking true
> [17:53:41] DEBUG [org.apache.directory.server.OPERATION_LOG] - >>
> AddOperation : AddContext for Dn 'ou=users,dc=starwit,dc=de', added
> entry: Entry
> dn[n]: ou=users,dc=starwit,dc=de
> objectClass: top
> objectClass: organizationalUnit
> ou: users
>
> Exception in thread "main"
> org.apache.directory.api.ldap.model.exception.LdapNoSuchObjectException:
> ERR_251_PARENT_NOT_FOUND Parent dc=starwit,dc=de not found
> at
>
> org.apache.directory.server.core.exception.ExceptionInterceptor.add(ExceptionInterceptor.java:165)
> at
>
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
> at
>
> org.apache.directory.server.core.admin.AdministrativePointInterceptor.add(AdministrativePointInterceptor.java:1201)
> at
>
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
> at
>
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.add(AciAuthorizationInterceptor.java:515)
> at
>
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
> at
>
> org.apache.directory.server.core.referral.ReferralInterceptor.add(ReferralInterceptor.java:249)
> at
>
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
> at
>
> org.apache.directory.server.core.authn.AuthenticationInterceptor.add(AuthenticationInterceptor.java:337)
> at
>
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
> at
>
> org.apache.directory.server.core.normalization.NormalizationInterceptor.add(NormalizationInterceptor.java:131)
> at
>
> org.apache.directory.server.core.DefaultOperationManager.add(DefaultOperationManager.java:394)
> at
>
> org.apache.directory.server.core.shared.DefaultCoreSession.add(DefaultCoreSession.java:209)
> at
>
> org.apache.directory.server.core.shared.DefaultCoreSession.add(DefaultCoreSession.java:186)
> at de.starwit.DirectoryRunner.main(DirectoryRunner.java:103)
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [Studio] ModRDN support ?

[Kiran Ayyagari]

On Mon, Sep 14, 2015 at 8:49 PM, Emmanuel Lécharny 
wrote:

> Hi !
>
> I see we can rename an entry, or move it, but is it possible, using
> Studio, to move and rename the entry in one operation ? And is it
> possible also to enforce the deleteOldRdn flag ?
>
I think yes, I have seen a dialog(with all the above options) popping up
when
I attempted to copy and paste an entry under the same parent.

>
> Thanks !
>



-- 
Kiran Ayyagari
http://keydap.com

Re: [Mavibot] BtreeHeader management, transactions and other things...

[Kiran Ayyagari]

On Mon, Sep 14, 2015 at 4:31 PM, Emmanuel Lécharny 
wrote:

> Le 14/09/15 04:40, Kiran Ayyagari a écrit :
> > On Mon, Sep 14, 2015 at 5:44 AM, Emmanuel Lécharny 
> > wrote:
> >
> >> Hi,
> >>
> >> I have looked at the code today, and I found that the way we handle the
> >> BtreeHeader is a bit complex, and does not fit some other ideas I had
> >> regarding the management of transactions.
> >>
> >> Currently, we store a map of BH where for each BTree, we have the latest
> >> BH (ie, the one associated with the most recent revision). When we want
> >> to update a btree, or read it, we first check this map and use the
> >> returned BH to start updating or reading the BTREE.
> >>
> >> This is not good, IMO.
> >>
> >> Actually, we should always fetch the most recent revision for a given
> >> BTree from the BOB. That change the implementation of the
> >> getBtreeHeader() method.
> >>
> >> Why should we do it differently, and how does it connect with teh TXNs ?
> >> That simple (well, sort of). txns will hold in a working memory (WM) all
> >> the pages that will be updated from teh beginning to the end of the
> >> transaction, allowing us to avoid many updates on disk - currently, the
> >> way we process transaction is pretty brutal : we write teh modified
> >> pages on disk, until teh end of the txn, even if we might very well
> >> modify one of those pages -.
> >>
> >> So the 'new way' should update the pages we have in the WM. That is
> >> possible if we reference pages using their offset, but then that changes
> >> the way we process the pages (currently, we preemptively copy a page
> >> that we are going to modify). We will *not* anymore copy a page if it's
> >> present in the WM, we will just update it. At the end, teh WM will
> >> contain all the modified pages, and we will just have to write them on
> >> disc (or discard them) when we commit (or rollback) teh transaction.
> >>
> >> But the current code has only two way to fetch a page :
> >> - either it's in the cache, and we return it
> >> - or we read the page from disk
> >> (This is what the PersistedPageHolder.getValue() does)
> >>
> >> We need to add a third possibility : to get the page from the WM, when
> >> we are updating the BTree, and if it's not present in teh WM, then fetch
> >> it (from the cache or the disk) and put it into the WM.
> >> Then the update (insert or delete) must be done without creating a copy.
> >>
> >> That is a huge change in the code... But thsi is necessary if we want to
> >> have an efficient transaction handling. It also allow us to get rid of
> >> those synchronized Maps containing the BTreeHeaders.
> >>
> >> One more things (à la Apple) : we most certainly don't need to manage
> >> multiple values with sub-btrees in Mavibot : As soon as we have a fully
> >> working transaction system, we could perfectly expect the application to
> >> deal with such a specific case : all in all, in a Btree, where V
> >> is the user's data structure, it's up to the user to make V a BTree, and
> >> to deal with it. As we will have a cross- b-tree transaction system, it
> >> won't be expensive, plus this is already what we do with JDBM, so the
> >> ApacheDS code will not be difficult to port.
> >>
> > we should move to explicit begin() and commit() to support the cross
> Btree
> > transactions,
>
> Absolutely. The current transaction support is less than half baked, it
> only support per-BTree transaction, which is pretty much useless.
>
> Actually, we do need to pass a context to each Btree operation, context
> that holds the revision of each B-trees being part of the transaction.
> That also mean we have one common revision for each transaction,
> revision which ties all the Btrees' revisions that were part of the
> transaction.
>
> Typically, in a ApacheDS context, when we update an entry, we nt only
> update the master BTree, but the RDN btree and every btree associated
> with each index. And all those updates must be visible as a whole when
> we want to fetch an entry or an index for this revision.
>
> the solution would be to use the transaction ID (which will be
> incremental) as the revision number for all the b-trees being updated
> during that transaction. That saves us the pain of keeping a track of
> the various B-trees revisions when applying an operation to a given
> revision of a b-tree.
>
> +1 that is a good idea



-- 
Kiran Ayyagari
http://keydap.com

Re: [Mavibot] BtreeHeader management, transactions and other things...

[Kiran Ayyagari]

On Mon, Sep 14, 2015 at 5:44 AM, Emmanuel Lécharny 
wrote:

> Hi,
>
> I have looked at the code today, and I found that the way we handle the
> BtreeHeader is a bit complex, and does not fit some other ideas I had
> regarding the management of transactions.
>
> Currently, we store a map of BH where for each BTree, we have the latest
> BH (ie, the one associated with the most recent revision). When we want
> to update a btree, or read it, we first check this map and use the
> returned BH to start updating or reading the BTREE.
>
> This is not good, IMO.
>
> Actually, we should always fetch the most recent revision for a given
> BTree from the BOB. That change the implementation of the
> getBtreeHeader() method.
>
> Why should we do it differently, and how does it connect with teh TXNs ?
> That simple (well, sort of). txns will hold in a working memory (WM) all
> the pages that will be updated from teh beginning to the end of the
> transaction, allowing us to avoid many updates on disk - currently, the
> way we process transaction is pretty brutal : we write teh modified
> pages on disk, until teh end of the txn, even if we might very well
> modify one of those pages -.
>
> So the 'new way' should update the pages we have in the WM. That is
> possible if we reference pages using their offset, but then that changes
> the way we process the pages (currently, we preemptively copy a page
> that we are going to modify). We will *not* anymore copy a page if it's
> present in the WM, we will just update it. At the end, teh WM will
> contain all the modified pages, and we will just have to write them on
> disc (or discard them) when we commit (or rollback) teh transaction.
>
> But the current code has only two way to fetch a page :
> - either it's in the cache, and we return it
> - or we read the page from disk
> (This is what the PersistedPageHolder.getValue() does)
>
> We need to add a third possibility : to get the page from the WM, when
> we are updating the BTree, and if it's not present in teh WM, then fetch
> it (from the cache or the disk) and put it into the WM.
> Then the update (insert or delete) must be done without creating a copy.
>
> That is a huge change in the code... But thsi is necessary if we want to
> have an efficient transaction handling. It also allow us to get rid of
> those synchronized Maps containing the BTreeHeaders.
>
> One more things (à la Apple) : we most certainly don't need to manage
> multiple values with sub-btrees in Mavibot : As soon as we have a fully
> working transaction system, we could perfectly expect the application to
> deal with such a specific case : all in all, in a Btree, where V
> is the user's data structure, it's up to the user to make V a BTree, and
> to deal with it. As we will have a cross- b-tree transaction system, it
> won't be expensive, plus this is already what we do with JDBM, so the
> ApacheDS code will not be difficult to port.
>
we should move to explicit begin() and commit() to support the cross Btree
transactions, this will impact ApacheDS code a bit cause now we need
a txn handle to pass around

>
> A bit of work in our plates ;-)
>
yep

>
> Thoughts ?
>
>


-- 
Kiran Ayyagari
http://keydap.com

[jira] [Comment Edited] (DIRSERVER-2091) Server Side Sort Control Broken in 2.0.0 M20

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738972#comment-14738972
 ] 

Kiran Ayyagari edited comment on DIRSERVER-2091 at 9/10/15 3:56 PM:


I have just tried this on the latest trunk and worked as expected (see the 
attached files).
I have used the below command
{noformat}
ldapsearch -H ldap://localhost:10389 -E sss=-cn:2.5.13.2 -x -D 
"uid=admin,ou=system" -W -b "dc=example,dc=com" -s sub -a always -z 1000 
"(objectClass=inetOrgPerson)" "cn"
{noformat}

Note that the attribute on which you are sorting should be present in the set 
of requested attributes.

Which OS and java version are you using?




was (Author: akiran):
I have just tried this on the latest trunk and worked as expected.
I have used the below command
{noformat}
ldapsearch -H ldap://localhost:10389 -E sss=-cn:2.5.13.2 -x -D 
"uid=admin,ou=system" -W -b "dc=example,dc=com" -s sub -a always -z 1000 
"(objectClass=inetOrgPerson)" "cn"
{noformat}

Which OS and java version are you using?



> Server Side Sort Control Broken in 2.0.0 M20
> 
>
> Key: DIRSERVER-2091
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2091
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: ldap
>Affects Versions: 2.0.0-M20
>Reporter: Danil Flores
> Attachments: hunderd-users.ldif, sort-result.ldif
>
>
> Given a partition with several objects with objectClass=inetOrgPerson, we 
> want to be able to perform a search with a server-side-sort request control. 
> The following ldapsearch query was giving the correct results in ApacheDS 
> 2.0.0 M19:
> ldapsearch -H ldap://localhost:10389 -x -D "uid=admin,ou=system" -W -b 
> "dc=example,dc=com" -s sub -a always -z 1000 "(objectClass=inetOrgPerson)" 
> "objectClass" -E sss=-cn:2.5.13.2
> However in ApacheDS 2.0.0 M20, we get the following error upon running the 
> same query against a similar data set:
> # search result
> search: 2
> result: 54 Loop detected
> text: LOOP_DETECT: failed for MessageType : SEARCH_REQUEST
> Message ID : 2
>
>   SearchRequest
> baseDn : 'dc=example,dc=com'
> filter : '(objectCla
>  ss=inetorgperson:[5])'
> scope : whole subtree
> typesOnly : false
> Size Limit : 1000
> Time Limit : no limit
> Deref Aliases : deref Always
> attributes : 'objectClass'
> org.apache.directory.api.ldap.model.message.SearchRequestImpl@38b18ca0SortRequestControlImpl
>  [sortKeys=[SortKey : [cn, 2.5.13.2,reverse]]]: java.io.IOException: The 
> system cannot find the path specified



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DIRSERVER-2091) Server Side Sort Control Broken in 2.0.0 M20

[Kiran Ayyagari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRSERVER-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Ayyagari updated DIRSERVER-2091:
--
Attachment: hunderd-users.ldif
sort-result.ldif

I have just tried this on the latest trunk and worked as expected.
I have used the below command
{noformat}
ldapsearch -H ldap://localhost:10389 -E sss=-cn:2.5.13.2 -x -D 
"uid=admin,ou=system" -W -b "dc=example,dc=com" -s sub -a always -z 1000 
"(objectClass=inetOrgPerson)" "cn"
{noformat}

Which OS and java version are you using?



> Server Side Sort Control Broken in 2.0.0 M20
> 
>
> Key: DIRSERVER-2091
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2091
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: ldap
>Affects Versions: 2.0.0-M20
>Reporter: Danil Flores
> Attachments: hunderd-users.ldif, sort-result.ldif
>
>
> Given a partition with several objects with objectClass=inetOrgPerson, we 
> want to be able to perform a search with a server-side-sort request control. 
> The following ldapsearch query was giving the correct results in ApacheDS 
> 2.0.0 M19:
> ldapsearch -H ldap://localhost:10389 -x -D "uid=admin,ou=system" -W -b 
> "dc=example,dc=com" -s sub -a always -z 1000 "(objectClass=inetOrgPerson)" 
> "objectClass" -E sss=-cn:2.5.13.2
> However in ApacheDS 2.0.0 M20, we get the following error upon running the 
> same query against a similar data set:
> # search result
> search: 2
> result: 54 Loop detected
> text: LOOP_DETECT: failed for MessageType : SEARCH_REQUEST
> Message ID : 2
>
>   SearchRequest
> baseDn : 'dc=example,dc=com'
> filter : '(objectCla
>  ss=inetorgperson:[5])'
> scope : whole subtree
> typesOnly : false
> Size Limit : 1000
> Time Limit : no limit
> Deref Aliases : deref Always
> attributes : 'objectClass'
> org.apache.directory.api.ldap.model.message.SearchRequestImpl@38b18ca0SortRequestControlImpl
>  [sortKeys=[SortKey : [cn, 2.5.13.2,reverse]]]: java.io.IOException: The 
> system cannot find the path specified



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRSTUDIO-1069) Cannot connect to LDAP server over SSL

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSTUDIO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728921#comment-14728921
 ] 

Kiran Ayyagari commented on DIRSTUDIO-1069:
---

bq. Could it be the issue?
Yes it is the reason.

> Cannot connect to LDAP server over SSL
> --
>
> Key: DIRSTUDIO-1069
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1069
> Project: Directory Studio
>  Issue Type: Bug
>Affects Versions: 2.0.0-M9 (2.0.0.v20150606-M9)
>Reporter: Steven Nguyen
>Priority: Minor
> Attachments: Directory Studio connect failed.jpg, Directory Studio 
> connect successfully.jpg
>
>
> Hi Team,
> I'm using Directory Studio to connect to LDAP host over SSL. The host and 
> port (636) are configured correctly. SSL is also enabled on LDAP host. I also 
> added the server certificate to Certificate Validation list.
> However, I could not connect to the LDAP server. The error I got is "Unable 
> to connect".
> It's weird that on another PC with same settings in Directory Studio, in same 
> LAN, I could connect to the LDAP host successfully.
> Could you please let me know what I'm missing?
> Thanks and Best Regards,
> Steven Nguyen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DIRSTUDIO-1069) Cannot connect to LDAP server over SSL

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSTUDIO-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728780#comment-14728780
 ] 

Kiran Ayyagari commented on DIRSTUDIO-1069:
---

[~snguyen] What version of java is used on both machines?

> Cannot connect to LDAP server over SSL
> --
>
> Key: DIRSTUDIO-1069
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1069
> Project: Directory Studio
>  Issue Type: Bug
>Affects Versions: 2.0.0-M9 (2.0.0.v20150606-M9)
>Reporter: Steven Nguyen
>Priority: Minor
> Attachments: Directory Studio connect failed.jpg, Directory Studio 
> connect successfully.jpg
>
>
> Hi Team,
> I'm using Directory Studio to connect to LDAP host over SSL. The host and 
> port (636) are configured correctly. SSL is also enabled on LDAP host. I also 
> added the server certificate to Certificate Validation list.
> However, I could not connect to the LDAP server. The error I got is "Unable 
> to connect".
> It's weird that on another PC with same settings in Directory Studio, in same 
> LAN, I could connect to the LDAP host successfully.
> Could you please let me know what I'm missing?
> Thanks and Best Regards,
> Steven Nguyen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [ApacheDS] Connecting to an Apache DS installed on a Ubuntu Server

[Kiran Ayyagari]

On Mon, Aug 31, 2015 at 7:10 PM, Pawan Thakur 
wrote:

> Hello,
>
>
>
> I have used apache DS on a Ubuntu Machine (Desktop) and was able to create
> connection using Apache Studio and test my use case.
>
>
>
> Right now I have a slightly different Environment and I am struggling how
> to get things going.
>
>
>
> I have a Ubuntu Server (no GUI) where I installed Apache DS *
> apacheds-2.0.0-M20. * Now I have started the default instance up using
>
>
>
> sudo /etc/init.d/apacheds-2.0.0-M20-default start
>
>
>
> and I assume it is started.
>
>
>
> Now as I dun have GUI here I am trying to connect to this Server using
> Apache DS Installed on my local machine and I am using the Ubuntu Host’s IP
> to create the Connection but it is failing to connect.
>
> Reading config.ldif I can see a few ports like
>
>
>
> ads-systemport: 80464
>
this is a wrong port, it should be <= 65535
modify that value and restart then try to connect using the new port

>
>
> But doesn’t makes much sense to me.
>
>
>
> Can anyone please help me with how to make a connection and proceed for
> the environment I have ?
>
>
>
> Cheers,
>
> Pawan
>



-- 
Kiran Ayyagari
http://keydap.com

Welcome Yaning Xu!

[Kiran Ayyagari]

Hi Yaning,

Your Apache account(yaning) has been created and you should be able to
commit to any of the Apache Directory sub-projects.

A good test to check if everything working fine is to add yourself to the
list of committers at this location http://directory.apache.org/team.html

The team page is generated from the website repository (
https://svn.apache.org/repos/asf/directory/site/trunk/).
The file is located at
https://svn.apache.org/repos/asf/directory/site/trunk/content/team.mdtext

A warm welcome to you on behalf of Apache Directory Team!

-- 
Kiran Ayyagari
http://keydap.com

[ANNOUNCE] Apache Mavibot 1.0.0-M8

[Kiran Ayyagari]

The Apache Directory team is pleased to announce the release of Apache
Mavibot 1.0.0-M8, the seventh milestone towards a 1.0 version.

Mavibot is a MVCC B-tree implementation in Java.

This release contains complete support for free page management (reusing
the copied and unused pages)

The next version will have support for cross BTree atomic updates.

You can read more about Mavibot at http://directory.apache.org/mavibot

You can download the latest sources and binary from

http://directory.apache.org/mavibot/downloads.html

Thank You!

-- 
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIRSERVER-2088) Add the ability to specify additional fields that should be hashed by the hashing interceptors

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701022#comment-14701022
 ] 

Kiran Ayyagari commented on DIRSERVER-2088:
---

bq. ... already introduced a pretty hefty migration (at least for me it did). 
Perhaps vote on this?
Perhaps we can have a migration script (using sed?) to change this, and include 
this in release notes. 
The error message can also be added/changed to hint the user about running this 
script in case if the 
user forgets to run the script before starting.

> Add the ability to specify additional fields that should be hashed by the 
> hashing interceptors
> --
>
> Key: DIRSERVER-2088
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2088
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: lucas theisen
> Attachments: oid_map.json, oid_map.pl
>
>
> This 
> [discussion|http://mail-archives.apache.org/mod_mbox/directory-dev/201507.mbox/%3cbn1pr09mb019635837eb5b0c564a0e955cd...@bn1pr09mb0196.namprd09.prod.outlook.com%3E]
>  went over the topic.  Per the suggestion from [~akiran], this should be done 
> with some new attributes:
> {quote}
> what I would do is to add support for configuring one or more attributes in
> this interceptor
> something like, 'ads-hashAttibute' a multi valued attributes
> {quote}
> Per [~elecharny], a new {{objectClass}} should be created:
> {quote}
> The idea is to add some configuration in the HashInterceptor
> configuration. You can create a new ObjectClass for that and add some
> new AttributeType to store the OID to be hashed.
> {quote}
> And given that we will create a new {{objectClass}} with its own 
> configuration attribute for {{ads-hashAttribute}} it is also reasonable to 
> add {{ads-hashAlgorithm}}.  With this, _ALL_ of the individual classes could 
> be implemented as one simple {{HashingInterceptor}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Mavibot 1.0.0-M8

[Kiran Ayyagari]

I am closing this vote, it was passed with 4 binding votes.

Stefan
Emmanuel
Shawn
Kiran

I'll publish the artifacts, update the website, and prepare the annoucemail.

thank you all.


On Mon, Aug 10, 2015 at 11:24 PM, Shawn McKinney 
wrote:

> +1
>
> Built from source using Java 8 on ubuntu14.
>
> Next I’ll test with fortress using apacheds/mavibot M8.  Will let you know
> how it goes but no reason to hold up the vote.
>
> Shawn
>
> > On Aug 10, 2015, at 1:43 AM, Emmanuel Lécharny 
> wrote:
> >
> > My +1.
> >
> >
> > I do agree that a 4096 keys is better for releases, although the current
> > requirement is "Committers with a DSA key or an RSA key of length *less
> > than* 2048 bits should generate a new key for signing releases" .
> >
> > Kiran's ky is 2048 bits long, whihc is strictly speaking, the bare
> > minimum to cut a release. I suspect this will not hold for ever, it's
> > probably a good move to generate this 4096 bits long key before the next
> > release.
> >
> >
> > Packages and tag checked, signature checked.
> >
> > Note that the sign.sh script is not part of the release, and it's hust a
> > tool that is provided to release managers, for convenience. Also note
> > that the XXX.asc files get signed too, which is unnecessary : tis is a
> > by-product of the release+sign.sh script. I usually remove them before
> > pushing the package son people.a.o...
> >
> > Thanks Kiran !
> >
>
>


-- 
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIRSERVER-2088) Add the ability to specify additional fields that should be hashed by the hashing interceptors

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681156#comment-14681156
 ] 

Kiran Ayyagari commented on DIRSERVER-2088:
---

Here is a doc that I followed in the beginning. 
https://cwiki.apache.org/confluence/display/DIRxPMGT/OID+Assignment+Scheme

> Add the ability to specify additional fields that should be hashed by the 
> hashing interceptors
> --
>
> Key: DIRSERVER-2088
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2088
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: lucas theisen
> Attachments: oid_map.json, oid_map.pl
>
>
> This 
> [discussion|http://mail-archives.apache.org/mod_mbox/directory-dev/201507.mbox/%3cbn1pr09mb019635837eb5b0c564a0e955cd...@bn1pr09mb0196.namprd09.prod.outlook.com%3E]
>  went over the topic.  Per the suggestion from [~akiran], this should be done 
> with some new attributes:
> {quote}
> what I would do is to add support for configuring one or more attributes in
> this interceptor
> something like, 'ads-hashAttibute' a multi valued attributes
> {quote}
> Per [~elecharny], a new {{objectClass}} should be created:
> {quote}
> The idea is to add some configuration in the HashInterceptor
> configuration. You can create a new ObjectClass for that and add some
> new AttributeType to store the OID to be hashed.
> {quote}
> And given that we will create a new {{objectClass}} with its own 
> configuration attribute for {{ads-hashAttribute}} it is also reasonable to 
> add {{ads-hashAlgorithm}}.  With this, _ALL_ of the individual classes could 
> be implemented as one simple {{HashingInterceptor}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Temporary Passwords

[Kiran Ayyagari]

ask him for
> directions
> [09:58]  sounds good.
> [09:59]  we also need to figure out how to enable/disable
> this...
> [09:59]  you mean, globally ?
> [10:00]  is it a new control that says the pwd reset should
> enable the temp policy, or is it system wide config that whenever the admin
> sets a pwd it gets the temp pwd policy (which is probably bad)
> [10:00]  in other words, should EVERY admin pwd reset
> trigger this behavior (other than self of course)?
> [10:00]  I think it should be enough to simply update the
> entry by adding the tmpPasswordPolicySubentry
> [10:01]  but this should only be done by an admin
> [10:01]  so make it a DSA operational attribute
> [10:01]  well, how do you know that the last pwd reset was
> temp?
> [10:01]  because you don't set the last reset
> [10:01]  h
> [10:01]  interesting idea :
> [10:02]  actually, when you reset the password and want to
> user to reset it in a certain delay,
> [10:02]  what you can do is *just* to change the
> pwdPolicySubentry to point to the short-time one
> [10:02]  then when the user changes it, you switch back to the
> long one
> [10:03]  thats what i was initially thinking...
> [10:03]  you just have to detect that the PP subentry is a
> temp one or or lon-term one
> [10:04]  but still need to decide how to trigger the
> initial switch...
> [10:04]  switching back is a simple decision... if a self
> pwd reset and is temp, then switch to long term...
> [10:04]  yeah, you need to know that you were depending on a
> temp PP
> [10:04]  but what should trigger the switch from long term
> to short?
> [10:05]  maybe adding a AT in the PP subentry that says "hey,
> I'm a temp PP"
> [10:05]  like tempPasswordPolicy AT, a Boolean one.
> [10:06]  but you also need to have an other additional PP, to
> know which permanent PP you want to switch to
> [10:06]  in any case, this is not something you can do without
> changing the spec
> [10:07]  could be done at the client level... just switch
> the pwdPolicySubentry along with the userPassword in the modify request (or
> more likely 2 separate requests)
> [10:07]  that would mean the client is aware of the PP
> [10:08]  all the PP AT are operational, because they are not
> expected to be updated by the client : that would be a security breach
> [10:10]  that much is certainly true...
> [10:18]  I suggest you write a proposal based on this convo
> and post it on the ML so that Kiran can see it
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: [VOTE] Release Apache Mavibot 1.0.0-M8

[Kiran Ayyagari]

Hi Stefan,

On Sun, Aug 9, 2015 at 9:09 PM, Stefan Seelmann 
wrote:

> Hi Kiran,
>
> The packages are signed with key A591AB7A which is only 2048 bits DSA
> key. According to [1] minimum strength should be 4096 RSA. I'm not sure
> if that is a blocker but please consider to use another key for next
> release.
>
> yes, I realized it very late at the time of closing repo in Nexus,
I will use a different key from the next release.


> Please also add your key(s) to our KEYS file [2].
>
> just added

> The source and binary packages at
> https://people.apache.org/~kayyagari/mavibot-1.0.0-M8/ miss the md5 and
> sha1 checksum, can you please add them? I hope those are automatically
> generated during the release process?
>
they weren't generated automatically, I have just added them manually.

All,

Please let me know if signing with 2048 bit key is not acceptable, I
will regenerate the packages.

thanks Stefan.

>
> Kind Regards,
> Stefan
>
> [1] https://www.apache.org/dev/release-signing.html
> [2] https://dist.apache.org/repos/dist/release/directory/KEYS
>
>
> On 08/09/2015 01:54 PM, Kiran Ayyagari wrote:
> > Hello Dev,
> >
> > This is the eighth release of Apache Mavibot, the MVCC BTree in Java !
> >
> > This release contains complete support for free page management (reusing
> > the copied and unused pages)
> >
> > Please cast your vote !
> >
> > The revision :
> >
> > http://svn.apache.org/r1694862
> >
> > The SVN tag:
> > https://svn.apache.org/repos/asf/directory/mavibot/tags/1.0.0-M8/
> >
> > The source and binary distribution packages:
> > https://people.apache.org/~kayyagari/mavibot-1.0.0-M8/
> >
> > The staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachedirectory-1040/
> >
> > Please cast your votes:
> > [ ] +1 Release Mavibot 1.0.0-M8
> > [ ] 0 abstain
> > [ ] -1 Do not release Mavibot 1.0.0-M8
> >
>
>


-- 
Kiran Ayyagari
http://keydap.com

[VOTE] Release Apache Mavibot 1.0.0-M8

[Kiran Ayyagari]

Hello Dev,

This is the eighth release of Apache Mavibot, the MVCC BTree in Java !

This release contains complete support for free page management (reusing
the copied and unused pages)

Please cast your vote !

The revision :

http://svn.apache.org/r1694862

The SVN tag:
https://svn.apache.org/repos/asf/directory/mavibot/tags/1.0.0-M8/

The source and binary distribution packages:
https://people.apache.org/~kayyagari/mavibot-1.0.0-M8/

The staging repository:
https://repository.apache.org/content/repositories/orgapachedirectory-1040/

Please cast your votes:
[ ] +1 Release Mavibot 1.0.0-M8
[ ] 0 abstain
[ ] -1 Do not release Mavibot 1.0.0-M8

-- 
Kiran Ayyagari
http://keydap.com

[Mavibot] releasing v1.0.0-M8

[Kiran Ayyagari]

Hi All,

  I am planning to release a new version of Mavibot today.
  This will be cut from the trunk. Will send out a vote soon.

-- 
Kiran Ayyagari
http://keydap.com

Re: [Studio] Assigning String to Text widget even if it's null

[Kiran Ayyagari]

On Tue, Aug 4, 2015 at 6:19 PM, Emmanuel Lécharny 
wrote:

> Hi,
>
> a Text widget does not accept null values. It forces us to test if the
> value is null, and if so, we inject a "".
>
how about extending the TextWidget to make this automatically happen?
(not sure whether there is any practical limitation for doing this in SWT)

>
> I'm willing to add a method in common-ui CommonUIUtils class that do
> this check instead of having to test that all over the code. May be
> tehre is already such a method spmewhere else ?
>
> Here is what I want to add :
>
>
>
> /**
>  * An utility method that return a String which is never null.
>  *
>  * @param value The incoming value, which can be null
>  * @return The String if it's not null, "" otherwise
>  */
> public static String getTextvalue( String value )
> {
> if ( value == null )
> {
> return "";
> }
> else
> {
>     return value;
> }
> }
>
> Dead simple...
>
> Let me konw if it's ok.
>
> Thanks !
>



-- 
Kiran Ayyagari
http://keydap.com

Re: Leveraging Kerby Kerberos library in ApacheDS

[Kiran Ayyagari]

Hi Kai,

On Mon, Aug 3, 2015 at 11:03 PM, Zheng, Kai  wrote:

> Hi Kiran,
>
>
>
> Sorry for the late response. I got your point and agree we can have a
> standard configuration format like
>
np

> JSON or YAML in addition to krb5.conf format. Maybe we don’t have to get
> it done before the first cut of release? How about doing it in 1.0.0-rc2?
> If ok let me fire an issue to bookmark this proposal. Thanks.
>
> I think we don't need to support anything else, cause we are already
supporting the krb5.conf

so I think we are good without any additional config formats (except the
LDAP format which we can take
care of later)

wdyt?

>
>
> Regards,
>
> Kai
>
>
>
> *From:* Kiran Ayyagari [mailto:kayyag...@apache.org]
> *Sent:* Friday, July 31, 2015 2:46 PM
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Leveraging Kerby Kerberos library in ApacheDS
>
>
>
>
>
>
>
> On Fri, Jul 31, 2015 at 1:27 PM, Zheng, Kai  wrote:
>
> >> once Kerby is matured enough then we can add a dependency on it in
> ApacheDS and integrate.
>
> Is there any good sign in your view for the maturity? It looks reasonable,
> but should we wait and do it then? I guess some pioneering work in ApacheDS
> side would be tried first.
>
> my point was only w.r.t standardizing the configuration and stick to
> one/two formats
>
>
>
> >> The current code base tries to support way too many configuration
> formats and I would like to see it support only one format, well and
> complete.
>
> Well, kerby-config may attempt to support various formats, but in the
> main/Kerberos part, only MIT format is used right now. I agree we may
> support a ‘standard’ format if krb5.conf isn’t any good standard. In your
> view, what’s left to be complete? Writing or generating of configuration
> file in a format? Or whatever?
>
> I am totally fine with using krb5.conf and perhaps we can just stick to
> it, ignoring all other formats.
>
> I have only checked various implementations present in the code, not
> checked if they are in use
>
> so proposed to support an additional format.
>
>
>
> If we are already supporting krb5.conf then let us stick to it, and our
> effort can be diverted to other parts
>
>
>
> >> And then we can add a GUI config editor in Studio easily.
>
> Did you mean we need to generate a config file after some editing using
> the GUI tool? Kerby-config module allows to load configuration items from a
> Java Map/Properties, which may work here. I mean, the edited values can be
> stored in any form and then all the values can be loaded in a map for
> config to use.
>
>
> no, no, just mentioning that if we have one format writing a config editor
> becomes easier
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Kiran Ayyagari [mailto:kayyag...@apache.org]
> *Sent:* Friday, July 31, 2015 12:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Leveraging Kerby Kerberos library in ApacheDS
>
>
>
>
>
>
>
> On Fri, Jul 31, 2015 at 6:49 AM, Zheng, Kai  wrote:
>
> Hi all,
>
>
>
> I’m thinking about what would be next steps after Kerby 1.0.0 out. We
> originally discussed when Kerby is ready, we’ll replace existing Kerberos
> related codes to simplify the code base in ApacheDS. This will include both
> the server and the studio. I thought this is important for the parent
> project, IMHO, the code base with so many external dependencies is rather
> complicated to move on (checking styles etc.), and also not easy to use.
> For example, so many modules, just hard to figure out the combination when
> only need a part of it in my app.
>
>
>
> once Kerby is matured enough then we can add a dependency on it in
> ApacheDS and integrate.
>
>
>
> The concern that I have at the moment is Kerby's configuration, The
> current code base tries to support
>  way too many configuration formats and I would like to see it support
> only one format, well and complete.
>
> I am fine if we plan to support MIT krb5.conf format in _addition_ to our
> standard format
>
> but having more than these two formats slows us down.
>
>
>
> My personal preference would be to support JSON or YAML besides the
> krb5.conf. And then we can add
>  a GUI config editor in Studio easily.
>
>
>
> Any thoughts?
>
>
>
> Regards,
>
> Kai
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>



-- 
Kiran Ayyagari
http://keydap.com

Re: Leveraging Kerby Kerberos library in ApacheDS

[Kiran Ayyagari]

etter.
> How do we substitute ApacheDS Kerberos code with Kerby ? There are a few
> parts that need love :
> - the kerberos server
> - the configuration
> - the GUI
>
> ApacheDS Kerbeors code is a layer on top of Directory Service, which
> means it relies on three components : the backend (LDAP), the Network
> and the configuration. Note that the configuration is a differnet beast,
> as it just glues all the other elements. As Kerby means to be also a
> complete independent component, we need to be careful in the way we move
> it inside ApacheDS. This is were we should have some work done, and it
> won't be easy.
>
> 3) In parallel : the GUI
>
> Probably the easiest part. We just have to revamp what we have, but we
> probably also need to make it separate. ATM, Kerberos config and
> ApacheDS config are tightly coupled, and it's not necessarily a good
> think. I can imagine having a complete new plugin for Kerby (standalone
> Kerby or Kerby in ApacehDS).
>
> It's not funny to develop - I'm in the middle of some Studio work, and I
> know that !) but it's probably a couple of month of work, max.
>
>
>
> So, to be clear : there is a lot of work in front of us, but I can see a
> clear path on how this can be done, and I can see the HUGE benefit we
> can all get out of this work, either from Kerby POV and from ApacheDS POV.
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: Leveraging Kerby Kerberos library in ApacheDS

[Kiran Ayyagari]

On Fri, Jul 31, 2015 at 1:27 PM, Zheng, Kai  wrote:

> >> once Kerby is matured enough then we can add a dependency on it in
> ApacheDS and integrate.
>
> Is there any good sign in your view for the maturity? It looks reasonable,
> but should we wait and do it then? I guess some pioneering work in ApacheDS
> side would be tried first.
>
my point was only w.r.t standardizing the configuration and stick to
one/two formats

>
>
> >> The current code base tries to support way too many configuration
> formats and I would like to see it support only one format, well and
> complete.
>
> Well, kerby-config may attempt to support various formats, but in the
> main/Kerberos part, only MIT format is used right now. I agree we may
> support a ‘standard’ format if krb5.conf isn’t any good standard. In your
> view, what’s left to be complete? Writing or generating of configuration
> file in a format? Or whatever?
>
I am totally fine with using krb5.conf and perhaps we can just stick to it,
ignoring all other formats.
I have only checked various implementations present in the code, not
checked if they are in use
so proposed to support an additional format.

If we are already supporting krb5.conf then let us stick to it, and our
effort can be diverted to other parts


>
> >> And then we can add a GUI config editor in Studio easily.
>
> Did you mean we need to generate a config file after some editing using
> the GUI tool? Kerby-config module allows to load configuration items from a
> Java Map/Properties, which may work here. I mean, the edited values can be
> stored in any form and then all the values can be loaded in a map for
> config to use.
>

no, no, just mentioning that if we have one format writing a config editor
becomes easier


>
> Regards,
>
> Kai
>
>
>
> *From:* Kiran Ayyagari [mailto:kayyag...@apache.org]
> *Sent:* Friday, July 31, 2015 12:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Leveraging Kerby Kerberos library in ApacheDS
>
>
>
>
>
>
>
> On Fri, Jul 31, 2015 at 6:49 AM, Zheng, Kai  wrote:
>
> Hi all,
>
>
>
> I’m thinking about what would be next steps after Kerby 1.0.0 out. We
> originally discussed when Kerby is ready, we’ll replace existing Kerberos
> related codes to simplify the code base in ApacheDS. This will include both
> the server and the studio. I thought this is important for the parent
> project, IMHO, the code base with so many external dependencies is rather
> complicated to move on (checking styles etc.), and also not easy to use.
> For example, so many modules, just hard to figure out the combination when
> only need a part of it in my app.
>
>
>
> once Kerby is matured enough then we can add a dependency on it in
> ApacheDS and integrate.
>
>
>
> The concern that I have at the moment is Kerby's configuration, The
> current code base tries to support
>  way too many configuration formats and I would like to see it support
> only one format, well and complete.
>
> I am fine if we plan to support MIT krb5.conf format in _addition_ to our
> standard format
>
> but having more than these two formats slows us down.
>
>
>
> My personal preference would be to support JSON or YAML besides the
> krb5.conf. And then we can add
>  a GUI config editor in Studio easily.
>
>
>
> Any thoughts?
>
>
>
> Regards,
>
> Kai
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>



-- 
Kiran Ayyagari
http://keydap.com

Re: Leveraging Kerby Kerberos library in ApacheDS

[Kiran Ayyagari]

On Fri, Jul 31, 2015 at 6:49 AM, Zheng, Kai  wrote:

> Hi all,
>
>
>
> I’m thinking about what would be next steps after Kerby 1.0.0 out. We
> originally discussed when Kerby is ready, we’ll replace existing Kerberos
> related codes to simplify the code base in ApacheDS. This will include both
> the server and the studio. I thought this is important for the parent
> project, IMHO, the code base with so many external dependencies is rather
> complicated to move on (checking styles etc.), and also not easy to use.
> For example, so many modules, just hard to figure out the combination when
> only need a part of it in my app.
>
>
>
once Kerby is matured enough then we can add a dependency on it in ApacheDS
and integrate.

The concern that I have at the moment is Kerby's configuration, The current
code base tries to support
 way too many configuration formats and I would like to see it support only
one format, well and complete.

I am fine if we plan to support MIT krb5.conf format in _addition_ to our
standard format
but having more than these two formats slows us down.

My personal preference would be to support JSON or YAML besides the
krb5.conf. And then we can add
 a GUI config editor in Studio easily.

Any thoughts?
>
>
>
> Regards,
>
> Kai
>



-- 
Kiran Ayyagari
http://keydap.com

Re: Sudo Schema for Apache DS

[Kiran Ayyagari]

On Tue, Jul 28, 2015 at 7:06 AM, Ananth Ravi 
wrote:

> Hello,
> I'm trying to configure Apache DS and came across a post that said that
> ApacheDS supported the Sudo schema, how do I enable this on the latest
> release?
>
any schema can be supported if loaded, but this sudo schema is not included
in ApacheDS, you
need to create/load it

> Also is there a schema for storing ssh public keys?
>
 there is a 'publicKey' attribute in "apache" schema (cn=apache,ou=schema)
that can be used
 for storing public key, you may make use of that

> Thanks!
> Ananth
>



-- 
Kiran Ayyagari
http://keydap.com

Re: Error in LDAP CLient Test

[Kiran Ayyagari]

On Mon, Jul 27, 2015 at 10:58 PM, Emmanuel Lécharny 
wrote:

> Hi guys,
>
> does any one you get the same error I get :
>
> I didn't get it, tested with java 7

> Tests in error:
>   LightweightLdapConnectionPoolTest.testSmallPool:535 »
> InvalidConnection Cannot...
>
>
>
> testSmallPool(org.apache.directory.shared.client.api.LightweightLdapConnectionPoolTest)
> Time elapsed: 0.011 sec  <<< ERROR!
> org.apache.directory.ldap.client.api.exception.InvalidConnectionException:
> Cannot connect to the server: Connection refused
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:658)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1265)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1185)
> at
>
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:127)
> at
>
> org.apache.directory.ldap.client.api.AbstractLdapConnection.bind(AbstractLdapConnection.java:112)
> at
>
> org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory.bindConnection(DefaultLdapConnectionFactory.java:64)
> at
>
> org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory.newLdapConnection(DefaultLdapConnectionFactory.java:107)
> at
>
> org.apache.directory.ldap.client.api.AbstractPoolableLdapConnectionFactory.makeObject(AbstractPoolableLdapConnectionFactory.java:110)
> at
>
> org.apache.directory.ldap.client.api.AbstractPoolableLdapConnectionFactory.makeObject(AbstractPoolableLdapConnectionFactory.java:38)
> at
>
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188)
> at
>
> org.apache.directory.ldap.client.api.LdapConnectionPool.getConnection(LdapConnectionPool.java:123)
> at
>
> org.apache.directory.shared.client.api.LightweightLdapConnectionPoolTest.testSmallPool(LightweightLdapConnectionPoolTest.java:535)
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at
>
> org.apache.mina.transport.socket.nio.NioSocketConnector.finishConnect(NioSocketConnector.java:221)
> at
>
> org.apache.mina.transport.socket.nio.NioSocketConnector.finishConnect(NioSocketConnector.java:47)
> at
>
> org.apache.mina.core.polling.AbstractPollingIoConnector.processConnections(AbstractPollingIoConnector.java:459)
> at
>
> org.apache.mina.core.polling.AbstractPollingIoConnector.access$700(AbstractPollingIoConnector.java:65)
> at
>
> org.apache.mina.core.polling.AbstractPollingIoConnector$Connector.run(AbstractPollingIoConnector.java:527)
> at
>
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: svn commit: r1692562 - in /directory/apacheds/trunk: interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java server-integ/src/test/java/org/apache/director

[Kiran Ayyagari]

On Sat, Jul 25, 2015 at 10:25 PM, Lucas Theisen 
wrote:

>
> On Jul 25, 2015 10:01 AM, "Kiran Ayyagari"  wrote:
> >
> >
> >
> > On Sat, Jul 25, 2015 at 9:54 PM, Lucas Theisen 
> wrote:
> >>
> >>
> >> On Jul 25, 2015 9:26 AM, "Kiran Ayyagari"  wrote:
> >> >
> >> >
> >> > Lucas,
> >> >
> >> > On Sat, Jul 25, 2015 at 2:11 AM,  wrote:
> >> >>
> >> >> Author: lucastheisen
> >> >> Date: Fri Jul 24 18:11:38 2015
> >> >> New Revision: 1692562
> >> >>
> >> >> URL: http://svn.apache.org/r1692562
> >> >>
> >> >> Log:
> >> >> fixed leak of information when password policy fails authentication
> attempt
> >> >>
> >> >> Modified:
> >> >>
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> >> >>
> directory/apacheds/trunk/server-integ/src/test/java/org/apache/directory/server/ppolicy/PasswordPolicyIT.java
> >> >>
> >> >> Modified:
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> >> >> URL:
> http://svn.apache.org/viewvc/directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java?rev=1692562&r1=1692561&r2=1692562&view=diff
> >> >>
> >> >>
> ==
> >> >> ---
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> (original)
> >> >> +++
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> Fri Jul 24 18:11:38 2015
> >> >> @@ -25,8 +25,10 @@ import java.security.MessageDigest;
> >> >>  import java.security.NoSuchAlgorithmException;
> >> >>  import java.util.Arrays;
> >> >>
> >> >> +
> >> >>  import javax.naming.Context;
> >> >>
> >> >> +
> >> >>  import org.apache.commons.collections.map.LRUMap;
> >> >>  import
> org.apache.directory.api.ldap.model.constants.AuthenticationLevel;
> >> >>  import
> org.apache.directory.api.ldap.model.constants.LdapSecurityConstants;
> >> >> @@ -45,6 +47,7 @@ import org.apache.directory.server.core.
> >> >>  import org.apache.directory.server.core.api.InterceptorEnum;
> >> >>  import org.apache.directory.server.core.api.LdapPrincipal;
> >> >>  import
> org.apache.directory.server.core.api.authn.ppolicy.PasswordPolicyConfiguration;
> >> >> +import
> org.apache.directory.server.core.api.authn.ppolicy.PasswordPolicyException;
> >> >>  import org.apache.directory.server.core.api.entry.ClonedServerEntry;
> >> >>  import
> org.apache.directory.server.core.api.interceptor.context.BindOperationContext;
> >> >>  import
> org.apache.directory.server.core.api.interceptor.context.LookupOperationContext;
> >> >> @@ -222,11 +225,27 @@ public class SimpleAuthenticator extends
> >> >>  // Get the stored password, either from cache or from
> backend
> >> >>  byte[][] storedPasswords = principal.getUserPasswords();
> >> >>
> >> >> +PasswordPolicyException ppe = null;
> >> >> +try
> >> >> +{
> >> >> +checkPwdPolicy( bindContext.getEntry() );
> >> >> +}
> >> >> +catch ( PasswordPolicyException e )
> >> >> +{
> >> >> +ppe = e;
> >> >> +}
> >> >> +
> >> >
> >> > the information that checkPwdPolicy() throws is anyway meant to send
> out through the ppolicy response
> >> > control, so there is nothing to prevent here from leaking and it is
> not clear to me why you wait till comparing
> >> > the credentials to throw the exception.
> >> >
> >>
> >> It's not the information inside of the exception that is leaking.  It's
> the fact that a PasswordPolicyException is thrown rather than invalid
> credentials.  This would tell a potential attacker that scans through
> possible names when they have found a valid one.  They co

Re: svn commit: r1692562 - in /directory/apacheds/trunk: interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java server-integ/src/test/java/org/apache/director

[Kiran Ayyagari]

On Sat, Jul 25, 2015 at 9:54 PM, Lucas Theisen 
wrote:

>
> On Jul 25, 2015 9:26 AM, "Kiran Ayyagari"  wrote:
> >
> >
> > Lucas,
> >
> > On Sat, Jul 25, 2015 at 2:11 AM,  wrote:
> >>
> >> Author: lucastheisen
> >> Date: Fri Jul 24 18:11:38 2015
> >> New Revision: 1692562
> >>
> >> URL: http://svn.apache.org/r1692562
> >>
> >> Log:
> >> fixed leak of information when password policy fails authentication
> attempt
> >>
> >> Modified:
> >>
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> >>
> directory/apacheds/trunk/server-integ/src/test/java/org/apache/directory/server/ppolicy/PasswordPolicyIT.java
> >>
> >> Modified:
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> >> URL:
> http://svn.apache.org/viewvc/directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java?rev=1692562&r1=1692561&r2=1692562&view=diff
> >>
> >>
> ==
> >> ---
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> (original)
> >> +++
> directory/apacheds/trunk/interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java
> Fri Jul 24 18:11:38 2015
> >> @@ -25,8 +25,10 @@ import java.security.MessageDigest;
> >>  import java.security.NoSuchAlgorithmException;
> >>  import java.util.Arrays;
> >>
> >> +
> >>  import javax.naming.Context;
> >>
> >> +
> >>  import org.apache.commons.collections.map.LRUMap;
> >>  import
> org.apache.directory.api.ldap.model.constants.AuthenticationLevel;
> >>  import
> org.apache.directory.api.ldap.model.constants.LdapSecurityConstants;
> >> @@ -45,6 +47,7 @@ import org.apache.directory.server.core.
> >>  import org.apache.directory.server.core.api.InterceptorEnum;
> >>  import org.apache.directory.server.core.api.LdapPrincipal;
> >>  import
> org.apache.directory.server.core.api.authn.ppolicy.PasswordPolicyConfiguration;
> >> +import
> org.apache.directory.server.core.api.authn.ppolicy.PasswordPolicyException;
> >>  import org.apache.directory.server.core.api.entry.ClonedServerEntry;
> >>  import
> org.apache.directory.server.core.api.interceptor.context.BindOperationContext;
> >>  import
> org.apache.directory.server.core.api.interceptor.context.LookupOperationContext;
> >> @@ -222,11 +225,27 @@ public class SimpleAuthenticator extends
> >>  // Get the stored password, either from cache or from backend
> >>  byte[][] storedPasswords = principal.getUserPasswords();
> >>
> >> +PasswordPolicyException ppe = null;
> >> +try
> >> +{
> >> +checkPwdPolicy( bindContext.getEntry() );
> >> +}
> >> +catch ( PasswordPolicyException e )
> >> +{
> >> +ppe = e;
> >> +}
> >> +
> >
> > the information that checkPwdPolicy() throws is anyway meant to send out
> through the ppolicy response
> > control, so there is nothing to prevent here from leaking and it is not
> clear to me why you wait till comparing
> > the credentials to throw the exception.
> >
>
> It's not the information inside of the exception that is leaking.  It's
> the fact that a PasswordPolicyException is thrown rather than invalid
> credentials.  This would tell a potential attacker that scans through
> possible names when they have found a valid one.  They could then use that
> information to cause account lockout, or other nefarious things.
>
there is nothing to hide here, cause the ppolicy response control is here
to send out the status
of the account, and this control is created based on the details present in
this exception.

Note that when a bind request comes with ppolicy request control the server
must send out a response
control with the details like time before expiration, remaining grace
logins etc.

> In general, I don't think we should provide any information other than
> invalid credentials, until the user has successfully authenticated.
>
> >>  // Now, compare the passwords.
> >>  for ( byte[] storedPassword : storedPasswords )
> >>  {
> &

Re: svn commit: r1692562 - in /directory/apacheds/trunk: interceptors/authn/src/main/java/org/apache/directory/server/core/authn/SimpleAuthenticator.java server-integ/src/test/java/org/apache/director

[Kiran Ayyagari]

nnection, userDn, "badPassword", 3,
>  "INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot
> authenticate user cn=userLockout,ou=system" );
>
> -checkBind( userConnection, userDn, "badPassword", 1,
> +checkBind( userConnection, userDn, "12345", 1,
>  "INVALID_CREDENTIALS: Bind failed: account was permanently
> locked" );
>
>  userConnection.close();
>
>
>


-- 
Kiran Ayyagari
http://keydap.com

Re: PasswordHashingInterceptor

[Kiran Ayyagari]

On Fri, Jul 24, 2015 at 3:31 AM, Theisen, Lucas  wrote:

>  I have need to hash more than just the userPassword attribute (I store
> the answers to security questions as well), and figured other people may
> need the same feature.  I would add it to the source branch, but my
> solution was to hard code the list of hashed OID’s in classes similar those
> in the interceptors-hash module.  In order to make it generic enough to add
> to the project, I would need a better way to feed in the list of OID’s
> (rather than compile).  I know that binary attributes are set on the client
> via org.apache.directory.api.ldap.codec.api.BinaryAttributeDetector, but
> since this would be server side, that approach would not work.  All server
> config seems to be ldif oriented, but this would require a custom attribute
> for this new option, perhaps something like:
>
> ads-interceptorconfig: any-config-string-here
>
>
>
> Or an even more generic:
>
> ads-customconfig: any-config-string-here
>
>  That would be allowed in any config (not just interceptors).  I could do
> it without the additional attribute using system properties, but that seems
> wonky…
>
> Anyway, my questions are:
>
> Is anybody else interested in this feature?
>
sounds like a reasonable addition

>  Do we have a common approach to adding new configuration attributes?
>
not really, but the general common sense prevails, like 'ads-' prefix in
the name

>  Is this a valid case for new attributes?
>
> Any other suggestions?
>
what I would do is to add support for configuring one or more attributes in
this interceptor
something like, 'ads-hashAttibute' a multi valued attributes

>  And if I do this, should we change the base class from
> PasswordHashingInterceptor to HashingInterceptor?
>
how about creating HashingInterceptor by extracting common functionality
out of
PasswordHashingIntereceptor and make later a subclass of former?

>  If we change the base class name, any idea what other
> classes/config/anything would be impacted?
>
Let us avoid renaming the classes, this makes migration much easier.
Except for a small change to the migration code to add the new schema
attributes to already
extracted schema, I do not see any issues.

>
>
> Thank You,
>
> Lucas Theisen
>
>
>



-- 
Kiran Ayyagari
http://keydap.com

[jira] [Commented] (DIRSERVER-2080) Add a way to politely stop apacheds from apacheds.sh

[Kiran Ayyagari (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRSERVER-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627461#comment-14627461
 ] 

Kiran Ayyagari commented on DIRSERVER-2080:
---

bq. ... If the user specifies a port for the shutdown listener that is already 
in use ...
This is a valid case, and I have handled it here 
http://svn.apache.org/r1691123. Now the server is gracefully stopped if the 
shutdown listener
couldn't be started for any reason.

> Add a way to politely stop apacheds from apacheds.sh
> 
>
> Key: DIRSERVER-2080
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2080
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M20
>Reporter: lucas theisen
> Fix For: 2.0.0-M21
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Studio] Bug with Mac version of Directory Studio

[Kiran Ayyagari]

On Wed, Jul 15, 2015 at 5:12 AM, Luca Sokoll  wrote:

> ​uninstalling java 8 and trying java 7 didn't work. you may be right in
> that Apache DS is looking at the default Mac java version which is:
>
> luca at Lucas-MBP in ~
> $ java -version
>
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)​
>
> If I run a version check on the java site, I get:
>
> Congratulations!
> You have the recommended Java installed (Version 8 Update 51).
>
this is not necessarily what is on your path, cause this check is based on
the java plugin version
registered in your browser.

the reliable test is to run the command

java -version

in your terminal and see the version reported there


> So I'm not sure what's going on here. All I originally did was uninstall
> the old version of Apache DS, and install the most recent one - and it
> crashed as described, so I updated java to see if it fixed the issue, it
> didn't. I have done nothing abnormal whilst 'upgrading' Apache DS, so I
> believe it more so on the Apache DS development side that's causing this.
>
> Cheers,
> Luca
>
> On 14 July 2015 at 10:06, Emmanuel Lécharny  wrote:
>
>> Le 14/07/15 16:49, Luca Sokoll a écrit :
>> > I haven't tried yet, I will have a go at fixing it today.
>>
>> Okie. Let us know !
>>
>>
>
>
> --
>
> *Luca Sokoll*
>
> IT Systems Administrator | Linaro IT Services | irc: *sokoll*
>



-- 
Kiran Ayyagari
http://keydap.com

Re: Changing a users password when on last grace authentication was used

[Kiran Ayyagari]

On Tue, Jul 14, 2015 at 11:05 AM, Kiran Ayyagari 
wrote:

>
>
> On Tue, Jul 14, 2015 at 5:45 AM, Theisen, Lucas 
> wrote:
>
>>  In my application, I use the an ldap connection pool.  The login page
>> checks out a connection, binds as the user, returns the connection and then
>> decides what to do based upon the response.  Standard stuff…  However, we
>> allow a single grace authentication.  The desired behavior is that they
>> attempt to log in, we
>>
> see it is their one grace authentication and we redirect them to the
>> change password page.  However, the grace authentication was used up during
>> the authentication process, so I can no longer bind as that user to get a
>> connection to change the password.  I COULD bind as admin to change the
>> password but that would avoid all of the password policy settings.  I could
>> bind as admin, delete the grace authentication operation attribute, but
>> what if there are more than one (a more generic situation).  I could reset
>> as admin to a temporary password, then bind as the user with that temporary
>> password and reset to the supplied password.  But I would then have to
>> remember that temporary password for some unknown period in case their new
>> password violated the policy in any way and they have to try again (or do
>> the admin thing again).  In this case I would be adding to the password
>> history which would violate that rule in that we are not preserving the
>> required number of passwords (effectively half or fewer).
>>
>>
>>
>> So the question really boils down to this: how do I reset a different
>> users password when I cannot bind as that user, but I still need to follow
>> that users password policy?  Any suggestions?  Right now I am leaning
>> toward resetting with admin to a temporary value, deleting the most recent
>> pwdHistory attribute, binding as the user, and attempting the reset.  That
>> should work, but is there a better way?
>>
> you can configure to allow at least >1 grace login attempts and the
> redirect the user to change password
> page when only one is remaining, but this again falls back to the same
> situation if user doesn't utilize this
> session and logs in again later, to handle this case bind as admin and set
> the pwdMustChange attribute
> server will allow the user to connect and modify his password (it forbids
> him from performing anything
> other than modify password, bind, unbind, abandon and StartTLS)
>
> and now the interesting part, there is a bug* in checkPwdReset() due to
> which this flag doesn't
> work as expected. I will fix it.
>
> * the not operator should not be used, I guess this is a side effect of
> changing the isPwdPolicyDisabled()
>   to isPwdPolicyEnabled() but the ! operator was never removed.
>
> P.S:- the use of a HashSet to hold all the DNs is also a bad idea, this
> was probably overlooked before
> committing, I will fix this.
>
fixed both issues here https://issues.apache.org/jira/browse/DIRSERVER-2082

>
>>
>> Thank You,
>>
>> Lucas Theisen
>>
>> lthei...@mitre.org
>>
>>
>>
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>



-- 
Kiran Ayyagari
http://keydap.com