On 18/02/16 23:30, jfill...@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. -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
