On 18/02/16 23:30, jfillman(a)central1.com wrote:
Thanks for the help you provided so far. I'm really stumped on
this. Project's behind schedule, blah blah blah...
This is a major rode block. I've used replication to import a database of many users
with numerous 'generalizedtime' attributes. The import didn't complain of
invalid time attributes. an ldapsearch on all my users shows all the attributes in the
format i provided, but trying to modify one of them fails.
Is there a way to configure the "GeneralizedTime" plugin? Is that even the
right course of action. I went looking for a newer version of 389-ds and i seem to have
the same version available on epel for rhel6.
I'm not a LDAP guru by any stretch so thank in advance for any further help you can
provide.
Hi James,
there is not much syntax checking happening on the consumer side if you
initialize the 1.2.11 instance like that. So you might end up with lots
of entries containing syntax problems.
I would suggest to try the following steps:
Do a database dump of the old ds with db2ldif.
Try to import the ldif to the new 389 ds with ldif2db.
Identify any syntax errors in the ldif (there might be more than the one
with generalizedTime) and learn how to correct them.
Fix your tools (scripts or apps that write and modify the incorrect
attributes)
Fix the attribute values in your _current_ directory server instance (it
will not complain about correct generalizedTime values anyway).
Initialize the new 389 instance via replication.
As a _last resort_ there is an option to disable syntax checks altogether.
In cn=config set nsslapd-syntaxcheck to "off".
HTH,
J.