Hello,
slightly related to the above ITS, I have found another issue. I am not sure though if this is a bug or if the behaviour is intended. I have a setup here were the pcache and rwm-overlay is used on top of back-ldap. rwm is used to rewrite some Attributetypes unknown to the Schema of the local server to Attributetypes that are defined in the local server. As the attribute values from unknown attribute types cannot be normalized by the proxy, I am wondering if rwm should normalize them during the Mapping process? Otherwise the Values will endup un-normalized in the cache database, and I get incomplete results when requests are answered from the cache.
I have a patch ready for this but I was wondering if the normalization step is left out by intention and wanted to ask before commiting my patch.
No comments on this? So I guess this means I can just go ahead and submit the patch to HEAD for testing?
On Monday 04 June 2007 17:13, Ralf Haferkamp wrote:
Hello,
slightly related to the above ITS, I have found another issue. I am not sure though if this is a bug or if the behaviour is intended. I have a setup here were the pcache and rwm-overlay is used on top of back-ldap. rwm is used to rewrite some Attributetypes unknown to the Schema of the local server to Attributetypes that are defined in the local server. As the attribute values from unknown attribute types cannot be normalized by the proxy, I am wondering if rwm should normalize them during the Mapping process? Otherwise the Values will endup un-normalized in the cache database, and I get incomplete results when requests are answered from the cache.
I have a patch ready for this but I was wondering if the normalization step is left out by intention and wanted to ask before commiting my patch.
Ralf Haferkamp wrote:
No comments on this? So I guess this means I can just go ahead and submit the patch to HEAD for testing?
On Monday 04 June 2007 17:13, Ralf Haferkamp wrote:
Hello,
slightly related to the above ITS, I have found another issue. I am not sure though if this is a bug or if the behaviour is intended. I have a setup here were the pcache and rwm-overlay is used on top of back-ldap. rwm is used to rewrite some Attributetypes unknown to the Schema of the local server to Attributetypes that are defined in the local server. As the attribute values from unknown attribute types cannot be normalized by the proxy, I am wondering if rwm should normalize them during the Mapping process? Otherwise the Values will endup un-normalized in the cache database, and I get incomplete results when requests are answered from the cache.
I have a patch ready for this but I was wondering if the normalization step is left out by intention and wanted to ask before commiting my patch.
It used to be a requirement that any data passing through back-ldap be defined in the local server's schema. Recently that requirement was relaxed. I don't see how you can normalize them safely, without knowing their schema constraints.
On Tuesday 19 June 2007 19:09, Howard Chu wrote:
Ralf Haferkamp wrote:
No comments on this? So I guess this means I can just go ahead and submit the patch to HEAD for testing?
On Monday 04 June 2007 17:13, Ralf Haferkamp wrote:
Hello,
slightly related to the above ITS, I have found another issue. I am not sure though if this is a bug or if the behaviour is intended. I have a setup here were the pcache and rwm-overlay is used on top of back-ldap. rwm is used to rewrite some Attributetypes unknown to the Schema of the local server to Attributetypes that are defined in the local server. As the attribute values from unknown attribute types cannot be normalized by the proxy, I am wondering if rwm should normalize them during the Mapping process? Otherwise the Values will endup un-normalized in the cache database, and I get incomplete results when requests are answered from the cache.
I have a patch ready for this but I was wondering if the normalization step is left out by intention and wanted to ask before commiting my patch.
It used to be a requirement that any data passing through back-ldap be defined in the local server's schema. Recently that requirement was relaxed. I don't see how you can normalize them safely, without knowing their schema constraints.
Yeah, there of course case were you can't normalize safely. Probably that feature should get a config-switch (defaulting to "no normalization"). But there are a lot of case where normalizing according to the constraints of the mapped attributetype should "just work". E.g. we have to proxy here for a directory that uses all kinds of strange attribute types instead of the well defined existing types (e.g. it uses an attributetype "fullname" instead of "displayname" or "cn") and we know that we can savely map them to one of the well defined attribute types. But we are a bit reluctant to pollute the schema of the server (which also host other databases) with those attribute types.
Ralf Haferkamp wrote:
On Tuesday 19 June 2007 19:09, Howard Chu wrote:
It used to be a requirement that any data passing through back-ldap be defined in the local server's schema. Recently that requirement was relaxed. I don't see how you can normalize them safely, without knowing their schema constraints.
Yeah, there of course case were you can't normalize safely. Probably that feature should get a config-switch (defaulting to "no normalization"). But there are a lot of case where normalizing according to the constraints of the mapped attributetype should "just work". E.g. we have to proxy here for a directory that uses all kinds of strange attribute types instead of the well defined existing types (e.g. it uses an attributetype "fullname" instead of "displayname" or "cn") and we know that we can savely map them to one of the well defined attribute types. But we are a bit reluctant to pollute the schema of the server (which also host other databases) with those attribute types.
OK. I guess if you're mapping it to a known attributeType, then one way or another it needs to conform to that type's rules, so yeah, normalizing that way makes sense.
Ralf Haferkamp wrote:
It used to be a requirement that any data passing through back-ldap be defined in the local server's schema. Recently that requirement was relaxed. I don't see how you can normalize them safely, without knowing their schema constraints.
Yeah, there of course case were you can't normalize safely. Probably that feature should get a config-switch (defaulting to "no normalization"). But there are a lot of case where normalizing according to the constraints of the mapped attributetype should "just work". E.g. we have to proxy here for a directory that uses all kinds of strange attribute types instead of the well defined existing types (e.g. it uses an attributetype "fullname" instead of "displayname" or "cn") and we know that we can savely map them to one of the well defined attribute types. But we are a bit reluctant to pollute the schema of the server (which also host other databases) with those attribute types.
The design of slapo-rwm(5) is based on: do things as correct as possible, but don't be too clever. What you mean makes sense; however, in most cases when slapo-rwm(5) is needed there are chances data has some quirk. So I'd leave an option whether or not to require strict normalization (this option could be per instance, or even per mapping rule). In fact, slapo-rwm(5) needs to be tolerant about cases where nothing is known about the source data, and mapping is sort of a hack.
Cheers, p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Tuesday 19 June 2007 20:32, Pierangelo Masarati wrote:
Ralf Haferkamp wrote:
It used to be a requirement that any data passing through back-ldap be defined in the local server's schema. Recently that requirement was relaxed. I don't see how you can normalize them safely, without knowing their schema constraints.
Yeah, there of course case were you can't normalize safely. Probably that feature should get a config-switch (defaulting to "no normalization"). But there are a lot of case where normalizing according to the constraints of the mapped attributetype should "just work". E.g. we have to proxy here for a directory that uses all kinds of strange attribute types instead of the well defined existing types (e.g. it uses an attributetype "fullname" instead of "displayname" or "cn") and we know that we can savely map them to one of the well defined attribute types. But we are a bit reluctant to pollute the schema of the server (which also host other databases) with those attribute types.
The design of slapo-rwm(5) is based on: do things as correct as possible, but don't be too clever. What you mean makes sense; however, in most cases when slapo-rwm(5) is needed there are chances data has some quirk. So I'd leave an option whether or not to require strict normalization (this option could be per instance, or even per mapping rule). In fact, slapo-rwm(5) needs to be tolerant about cases where nothing is known about the source data, and mapping is sort of a hack.
Ok, I will rework the stuff to have the possibility to enable/disable normalization.
regards, Ralf
On Wednesday 20 June 2007 12:17, Ralf Haferkamp wrote:
On Tuesday 19 June 2007 20:32, Pierangelo Masarati wrote:
[..]
The design of slapo-rwm(5) is based on: do things as correct as possible, but don't be too clever. What you mean makes sense; however, in most cases when slapo-rwm(5) is needed there are chances data has some quirk. So I'd leave an option whether or not to require strict normalization (this option could be per instance, or even per mapping rule). In fact, slapo-rwm(5) needs to be tolerant about cases where nothing is known about the source data, and mapping is sort of a hack.
Ok, I will rework the stuff to have the possibility to enable/disable normalization.
After having been disturbed by other things I found some time now to rework my patch to allow normalization of unknown mapped attribute types. The normalization step can be enabled/disabled via the "rwm-normalize-mapped-attrs" keyword in slapd.conf. Updates for the rwm-manpage will follow shortly.
regards, Ralf
-
Howard Chu -
Pierangelo Masarati -
Ralf Haferkamp