I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue attributes of type 'Generalized Time'.
One my old LDAP server, i could set dates in this format: 20160215133951.842
389 DS 1.2.11 doesn't seem to allow this local time version. Is there any way to enable/allow this?
On 02/18/2016 03:43 PM, jfillman@central1.com wrote:
I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue attributes of type 'Generalized Time'.
One my old LDAP server, i could set dates in this format: 20160215133951.842
389 DS 1.2.11 doesn't seem to allow this local time version. Is there any way to enable/allow this?
Not that I know of, but "20160215133951.842" does not seem to comply with the LDAP RFC for generalized time:
https://tools.ietf.org/html/rfc4517#section-3.3.13
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
On 02/18/2016 03:55 PM, Mark Reynolds wrote:
On 02/18/2016 03:43 PM, jfillman@central1.com wrote:
I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue attributes of type 'Generalized Time'.
One my old LDAP server, i could set dates in this format: 20160215133951.842
389 DS 1.2.11 doesn't seem to allow this local time version. Is there any way to enable/allow this?
Not that I know of, but "20160215133951.842" does not seem to comply with the LDAP RFC for generalized time:
Actually it does allow for the period, so it should be valid... Please open a ticket to have this investigated:
https://fedorahosted.org/389/newticket
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
On 02/18/2016 01:00 PM, Mark Reynolds wrote:
On 02/18/2016 03:55 PM, Mark Reynolds wrote:
On 02/18/2016 03:43 PM, jfillman@central1.com wrote:
I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue attributes of type 'Generalized Time'.
One my old LDAP server, i could set dates in this format: 20160215133951.842
389 DS 1.2.11 doesn't seem to allow this local time version. Is there any way to enable/allow this?
Not that I know of, but "20160215133951.842" does not seem to comply with the LDAP RFC for generalized time:
Actually it does allow for the period, so it should be valid... Please open a ticket to have this investigated:
Not sure I'm reading this correctly, but according to this notation, g-time-zone needs to be there after fraction which contains dot or comma and is optional.
GeneralizedTime = century year month day hour [ minute [ second / leap-second ] ] [ fraction ] g-time-zone
And g-time-zone has to end with Z or g-differential.
g-time-zone = %x5A ; "Z" / g-differential g-differential = ( MINUS / PLUS ) hour [ minute ]
So, it looks to me the allowed formats are ...
Examples: 199412161032Z 199412160532-0500 199412160532+0500
as well as
20141006133000.0Z 20141006133000.0-0500 20141006133000.0+0500
Could it be possible to try adding 'Z' at the end of 20160215133951.842 and see how 389-ds-base-1.2.11.x reacts?
Thanks, --noriko
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
On 02/18/2016 02:10 PM, Noriko Hosoi wrote:
On 02/18/2016 01:00 PM, Mark Reynolds wrote:
On 02/18/2016 03:55 PM, Mark Reynolds wrote:
On 02/18/2016 03:43 PM, jfillman@central1.com wrote:
I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue attributes of type 'Generalized Time'.
One my old LDAP server, i could set dates in this format: 20160215133951.842
389 DS 1.2.11 doesn't seem to allow this local time version. Is there any way to enable/allow this?
Not that I know of, but "20160215133951.842" does not seem to comply with the LDAP RFC for generalized time:
Actually it does allow for the period, so it should be valid... Please open a ticket to have this investigated:
Not sure I'm reading this correctly, but according to this notation, g-time-zone needs to be there after fraction which contains dot or comma and is optional. GeneralizedTime = century year month day hour [ minute [ second / leap-second ] ] [ fraction ] g-time-zone And g-time-zone has to end with Z or g-differential. g-time-zone = %x5A ; "Z" / g-differential g-differential = ( MINUS / PLUS ) hour [ minute ] So, it looks to me the allowed formats are ... Examples: 199412161032Z 199412160532-0500 199412160532+0500 as well as
20141006133000.0Z 20141006133000.0-0500 20141006133000.0+0500
Could it be possible to try adding 'Z' at the end of 20160215133951.842 and see how 389-ds-base-1.2.11.x reacts?
Looks like that should do it: https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/synta...
Thanks, --noriko
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Hi Rich,
Is the code your referenced found in 389-ds-base-1.2.11 ?
On 02/18/2016 02:52 PM, jfillman@central1.com wrote:
Hi Rich,
Is the code your referenced found in 389-ds-base-1.2.11 ?
yes
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/synta...
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Damn. Then i don't know what's going on:
[jrf@vahclq01ldap tmp]$ cat testiserv.mod dn: cn=testusr,dc=xxxx,dc=xx changetype: modify replace: mdlastlogintime mdlastlogintime: 20160215133951.842 - [jrf@vahclq01ldap tmp]$ ldapmodify -v -h vahclq01ldap -p 389 -D "uid=me,dc=xxx,dc=xx" -y passfile -f testiserv.mod ldap_initialize( ldap://vahclq01ldap:389 ) replace mdlastlogintime: 20160215133951.842 modifying entry "cn=testusr,dc=xxxx,dc=xx" ldap_modify: Invalid syntax (21) additional info: mdlastlogintime: value #0 invalid per syntax
On 18/02/16 23:25, jfillman@central1.com wrote:
Damn. Then i don't know what's going on:
[jrf@vahclq01ldap tmp]$ cat testiserv.mod dn: cn=testusr,dc=xxxx,dc=xx changetype: modify replace: mdlastlogintime mdlastlogintime: 20160215133951.842
[jrf@vahclq01ldap tmp]$ ldapmodify -v -h vahclq01ldap -p 389 -D "uid=me,dc=xxx,dc=xx" -y passfile -f testiserv.mod ldap_initialize( ldap://vahclq01ldap:389 ) replace mdlastlogintime: 20160215133951.842 modifying entry "cn=testusr,dc=xxxx,dc=xx" ldap_modify: Invalid syntax (21) additional info: mdlastlogintime: value #0 invalid per syntax
Mhhh, "20160215133951.842" is not valid for generalizedTime. It must be "20160215133951.842-0500" for EST time zone or "20160215183951.842Z" for UTC.
J.
Hmm. There seems to be differing opinions on the valid format for Generalized Time. I've seen docs that allow for 20160215133951.842. Without a 'Z' or '-0500', the time is considered local time. RHDS 8.2 certainly allows this format.
If you know of an attribute change between RHDS 8.2 and beyond, could pass on this info so i can stop hoping there's a fix?
Thanks, James
On 02/18/2016 04:15 PM, jfillman@central1.com wrote:
Hmm. There seems to be differing opinions on the valid format for Generalized Time. I've seen docs that allow for 20160215133951.842.
Can you provide links to those docs? Because that is certainly not the valid LDAP format.
Without a 'Z' or '-0500', the time is considered local time. RHDS 8.2 certainly allows this format.
RHDS 8.2 had very poor syntax checking, if at all.
If you know of an attribute change between RHDS 8.2 and beyond, could pass on this info so i can stop hoping there's a fix?
The "attribute change between RHDS 8.2 and beyond" was to make the directory server LDAP v3 compliant with respect to standard syntaxes and matching rules. If you want a "fix" I suppose you can completely disable syntax checking.
Thanks, James -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
On 19/02/16 00:26, Rich Megginson wrote:
On 02/18/2016 04:15 PM, jfillman@central1.com wrote:
Hmm. There seems to be differing opinions on the valid format for Generalized Time. I've seen docs that allow for 20160215133951.842.
Can you provide links to those docs? Because that is certainly not the valid LDAP format.
Maybe it is because there is a Type generalizedTime in the ASN.1 standard as well? http://www.obj-sys.com/asn1tutorial/node14.html
That one allows a local time without TZ indication that the LDAP generalizedTime doesn't.
J.
Yeah, Jochen, you found the link that first led me astray.
I will update my code. Thanks for all your help. James
Hey Rich,
I was reading the wikipedia page on Generalized time as well as this: http://www.obj-sys.com/asn1tutorial/node14.html
Taking a closer look at the RFC4171, i can now see what part i was missing:
The LDAP definition for the Generalized Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
This syntax corresponds to the GeneralizedTime ASN.1 type from [ASN.1], with the constraint that local time without a differential SHALL NOT be used.
https://tools.ietf.org/html/rfc4517#section-3.3.13
I will have to have the code changes made to my apps to conform this.
Thanks for all your help. James
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.
James
On 18/02/16 23:30, jfillman@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@lists.fedoraproject.org