Clément,


Sorry to spam you with my posts but, I tried to search through the directory 
using ldapsearch:



ldapsearch -h xxx.xxx.xxx.xxx -p 389 -b -x -D "test" -w "test"  -b "cn=PBX0" 
"cn=*"


And I get the correct results:



[...]

# TEST, PBX0
dn: cn=TEST,cn=PBX0
cn: TEST
e164: 3445
pbx:: PGRldmljZSBodz0iMzQ0NTY2NiIvPg==
pbx:: PHVzZXIgcmVwb3J0aW5nPSJ0cnVlIiB2b2ljZW1haWw9InRydWUiLz4=
guid:: 4wz0pVvZVwFrRwCQMykD1A==
usn: 60
objectClass: pbxObject

[...]


So there might be a specific request that LSC sends out, which is not catched 
by the LDAP server...

Will try to trace the packets using Wireshark.





Thanks.




Le 19 septembre 2016 à 11:23, Bruno MORAZZONI <brunomorazz...@mac.com> a écrit :


Hi Clément,



This is what I get when I set the timeout to 10sec.

So you are right, LSC expects something but doesn't get an answer...





sept. 19 11:08:21 - ERROR - Error while looking for (cn=TEST TEST) in cn=PBX0: 
javax.naming.CommunicationException: Request: 2 cancelled; remaining name ''
sept. 19 11:08:21 - WARN  - Communication error, retrying: Request: 2 cancelled
sept. 19 11:08:21 - DEBUG - Request: 2 cancelled
javax.naming.CommunicationException: Request: 2 cancelled
        at com.sun.jndi.ldap.LdapRequest.getReplyBer(Unknown Source) 
~[na:1.8.0_101]
        at com.sun.jndi.ldap.Connection.readReply(Unknown Source) 
~[na:1.8.0_101]
        at com.sun.jndi.ldap.LdapClient.getSearchReply(Unknown Source) 
~[na:1.8.0_101]
        at com.sun.jndi.ldap.LdapClient.search(Unknown Source) ~[na:1.8.0_101]
        at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source) ~[na:1.8.0_101]
        at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) ~[na:1.8.0_101]
        at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) ~[na:1.8.0_101]
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown 
Source) ~[na:1.8.0_101]
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown 
Source) ~[na:1.8.0_101]
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown 
Source) ~[na:1.8.0_101]
        at javax.naming.directory.InitialDirContext.search(Unknown Source) 
~[na:1.8.0_101]
        at org.lsc.jndi.JndiServices.doGetEntry(JndiServices.java:567) 
[lsc-core-2.1.3.jar:na]
        at org.lsc.jndi.JndiServices.getEntry(JndiServices.java:528) 
[lsc-core-2.1.3.jar:na]
        at org.lsc.jndi.JndiServices.getEntry(JndiServices.java:506) 
[lsc-core-2.1.3.jar:na]
        at 
org.lsc.jndi.AbstractSimpleJndiService.get(AbstractSimpleJndiService.java:258) 
[lsc-core-2.1.3.jar:na]
        at 
org.lsc.jndi.SimpleJndiDstService.getBean(SimpleJndiDstService.java:135) 
[lsc-core-2.1.3.jar:na]
        at org.lsc.SynchronizeTask.run(AbstractSynchronize.java:741) 
[lsc-core-2.1.3.jar:na]
        at org.lsc.SynchronizeTask.run(AbstractSynchronize.java:707) 
[lsc-core-2.1.3.jar:na]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
[na:1.8.0_101]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
[na:1.8.0_101]
        at java.lang.Thread.run(Unknown Source) [na:1.8.0_101]
sept. 19 11:08:21 - INFO  - Connecting to LDAP server 
ldap://xxx.xxx.xxx.xxx:389/cn=PBX0 as test


Le 19 septembre 2016 à 09:14, Bruno MORAZZONI <brunomorazz...@mac.com> a écrit :




Hi Clément,


There is a firewall in between, yes. But ldap ports (389 and 636) are opened so 
it shouldn't be an issue here. I will try to test the connection bypassing the 
FW just to be sure though.


I am not using ldapsearch here but with Apache Directory Studio, it works 
perfectly fine, at least to get the entries.
What I can't do though, is to create one.
It looks like Apache doesn't know the LDAP scheme of the server or cannot 
retrieve it and so, does not let me create anything. (Even though I have the 
rights to write into the directory...)
Don't know if LSC does the same thing, trying to retrieve the subschema object 
before creating an entry?


I guess I am trying to work with something which is not pure LDAP, and I will 
need to talk to their support team to troubleshoot further.


Thanks a lot for all your help on this however


Bruno. 



Le 16 sept. 2016 à 18:40, Clément OUDOT <clem.ou...@gmail.com> a écrit :


2016-09-15 13:06 GMT-04:00 Bruno MORAZZONI <brunomorazz...@mac.com>:

Hello Clément,



Sorry about that, I will try to stick with the registered one.

Do you know if there is a way to see what LSC does right after displaying

"Starting sync for MySyncTask" ?

I left the program running yesterday and it ended with the following logs:



sept. 15 16:29:34 - INFO  - Starting sync for MySyncTask

sept. 15 17:29:34 - INFO  - All entries: 1, to modify entries: 0,

successfully modified entries: 0, errors: 0

sept. 15 17:29:34 - INFO  - Starting clean for MySyncTask



Si it took exactly one hour to perform the first task, and stayed stuck at

the cleaning process.

It looks like LSC is expecting something from the destination LDAP but it

does not get any answer...

Since I am not able to access logs on this server, it will probably be

difficult to troubleshoot further.



You seem to hit a timeout. By default, LSC close a task after 3600
seconds. You can reduce this with -i option.

For example to wait for only 60s, do :
lsc -s all -c all -i 60

Now, why LSC can't contact your destination directory is another
issue. If the connection was refused, you would have a specific error
message. Here it seems that LSC tries to connect and never get answer.
Are you sure you don't have a firewall which DROP packets? Can you
connect to the directory with ldapsearch?



Clément.
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org

lsc-users mailing list
lsc-users@lists.lsc-project.org
http://lists.lsc-project.org/listinfo/lsc-users
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org

lsc-users mailing list
lsc-users@lists.lsc-project.org
http://lists.lsc-project.org/listinfo/lsc-users

Reply via email to