Looks like I lied, I must not have saved my config, or got lucky with a timestamp. Even using the right format I can't reproduce the success. It seems that anytime I use a dateFormat other then the default the interval is ignored and it sends many requests a second to the server.
Looking at the source the default is yyyyMMddHHmmss.'Z', I tried a few variations; including yyyyMMddHHmmss.S'Z' but none appear to work. Could there be a problem with lastSuccessfulSync not getting the proper format? I need to find a way to get this, or normal sync mode to work. I could start it in async, let it run x # of seconds, then kill it with lsc-agent, but that seems sorta hackerish. -Joel On Tue, Aug 7, 2012 at 1:26 PM, dunkan <[email protected]> wrote: > Turns out this was user error, I had: > > <dateFormat>yyyyMMddHHmmss.'0Z'</dateFormat> > > instead of > <dateFormat>yyyyMMddHHmmss.SZ</dateFormat> > > turns out that doesn't work very well, and breaks the world. > > Async is working very well now, thank you for the support! > > -Joel > > On Mon, Aug 6, 2012 at 11:51 PM, Sébastien Bahloul < > [email protected]> wrote: > >> Hi Dunkan, >> >> Yes you are completely right, that's why you can customize it. Look at >> the following page : >> >> >> http://lsc-project.org/wiki/documentation/2.0/configuration/service/sourceldap >> >> and set the "*dateFormat" value to the following setting (not tested) :* >> * >> * >> *yyyyMMddHHmmss.S'Z * >> >> The pattern to use is documented in standard Java documentation for >> SimpleDateFormat class: >> http://docs.oracle.com/javase/1.4.2/docs/api/java/text/SimpleDateFormat.html >> >> >> Regards, >> >> -- >> Sebastien BAHLOUL >> IAM / Security specialist >> Ldap Synchronization Connector : http://lsc-project.org >> Blog : http://sbahloul.wordpress.com/ >> >> >> >> 2012/8/7 dunkan <[email protected]> >> >>> Sorry to be spammy. From looking at tcpdumps I see it is checking the >>> modifytimestamp. It looks like the problem is the value is stored with a >>> decimal in the directory, but not in the filter. >>> >>> For example, it is looking for "(modifytimestamp>=20110807030345Z)", >>> and never gets any results. If I change that >>> to "(modifytimestamp>=20110807030345.0Z)" it returns the entries that are >>> modified. >>> >>> Thanks, >>> Joel >>> >>> >>> On Mon, Aug 6, 2012 at 9:00 PM, dunkan <[email protected]> wrote: >>> >>>> It looks like FORCE, with forcevalues will always put what I need, so >>>> that part is working out now. >>>> >>>> I'm not sure about the async job though. How does it determine that it >>>> needs to update? The logs give the indication that it is searching every 5 >>>> seconds, but changes don't show up. If I stop and re-run it again they are >>>> always picked up. >>>> >>>> -Joel >>>> >>>> >>>> On Mon, Aug 6, 2012 at 7:02 PM, dunkan <[email protected]> wrote: >>>> >>>>> Hey there, >>>>> >>>>> I am working on one way syncing AD to OpenLDAP. I am seeing a >>>>> difference in operation between using lsc in async vs sync mode. >>>>> >>>>> If I start lsc like so: >>>>> >>>>> # bin/lsc -f etc -a all >>>>> >>>>> users are read from active directory using my filter correctly, and >>>>> attributes are updated as I would expect. >>>>> >>>>> If I start lsc in async like so: >>>>> >>>>> # bin/lsc -f etc -s all >>>>> >>>>> lsc attempts to create users every time, and I will get a failure to >>>>> add as the entry already exists. >>>>> >>>>> From what I have read this sort of behavior shouldn't change using >>>>> sync vs async, is that correct? >>>>> It seems like an easy work around for now is to just use async and >>>>> trigger an event. >>>>> >>>>> >>>>> My second issue I believe is configuration. I have been using >>>>> http://lsc-project.org/wiki/documentation/2.0/configuration/syncoptions as >>>>> my guide for this. >>>>> >>>>> AD has a different objectclass than OpenLDAP. >>>>> >>>>> So in AD the objectClass will be OrgainzationalPerson, person >>>>> In OpenLDAP it is Account, PossixAccount. >>>>> >>>>> I want the values in OpenLDAP to always be the OpenLDAP values, >>>>> leave existing entries alone, and create new users with those values. >>>>> >>>>> I thought the way to do this would be to set policy to FORCE and >>>>> defaultvalues to my requested values. >>>>> This creates a new user ok, but existing users get trampled. >>>>> >>>>> If I set it to KEEP and defaultvalues to the requested values, >>>>> existing users don't get messed with, but new users use the AD >>>>> objectclass. >>>>> >>>>> I tried using forcevalues and createvalues with KEEP/FORCE as well, >>>>> but am not having any luck getting the behavior I am looking for. >>>>> >>>>> Any tips? >>>>> >>>>> Thanks, >>>>> Joel >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________________________ >>> Ldap Synchronization Connector (LSC) - http://lsc-project.org >>> >>> lsc-users mailing list >>> [email protected] >>> http://lists.lsc-project.org/listinfo/lsc-users >>> >>> >> >
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-users mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-users
