Dear collectes list wisdom,
I'm running a ldap server whose main database holds a X500 style suffix (i.e. o=...,l=...,c=...). The organisations name does contain a non-ascii character 'ü'. So far this never has been a problem but now one of our partner institutions needs to access the server with tomcat/ndi/proprietary code and that fails misserably - no wonder: the send the bind DN with the wrong encoding. While I'm sure there is a solution on the Java/Tomcat side I'd like to provide the possibility to access the data under a different DN (with 'ü' replaced by 'ue'). My first attempt: I created a second database with the alternative suffix and placed an alias object as the topmost entry. That object points to the toplevel organisation object of the real database. But while I can see that object none of the child entries are found.
s there any to configure such an "alias suffix"?
TIA Ralf Mattes
Am Wed, 14 Sep 2016 16:00:33 +0200 schrieb "Ralf Mattes" rm@mh-freiburg.de:
Dear collectes list wisdom,
I'm running a ldap server whose main database holds a X500 style suffix (i.e. o=...,l=...,c=...). The organisations name does contain a non-ascii character 'ü'. So far this never has been a problem but now one of our partner institutions needs to access the server with tomcat/ndi/proprietary code and that fails misserably - no wonder: the send the bind DN with the wrong encoding. While I'm sure there is a solution on the Java/Tomcat side I'd like to provide the possibility to access the data under a different DN (with 'ü' replaced by 'ue'). My first attempt: I created a second database with the alternative suffix and placed an alias object as the topmost entry. That object points to the toplevel organisation object of the real database. But while I can see that object none of the child entries are found.
s there any to configure such an "alias suffix"?
There are quite a few possible solutions, 1. slapd-relay(5) 2. slapd-ldap(5) and a few more.
I would recommend slapd-relay, configuration could be:
... database relay suffix o=uebermut,c=XX relay o=übermut,c=XX ...
depending on your database design you may need the rwm overlay and some rewrite rules.
-Dieter
Am Mittwoch, 14. September 2016 16:54 CEST, Dieter Klünter dieter@dkluenter.de schrieb:
Am Wed, 14 Sep 2016 16:00:33 +0200 schrieb "Ralf Mattes" rm@mh-freiburg.de:
... s there any to configure such an "alias suffix"?
There are quite a few possible solutions,
- slapd-relay(5)
- slapd-ldap(5)
and a few more.
I would recommend slapd-relay, configuration could be:
... database relay suffix o=uebermut,c=XX relay o=übermut,c=XX ...
depending on your database design you may need the rwm overlay and some rewrite rules.
Thank you,
I _knew_ I read about that at some time. This (slapd-relay) looks exactly like what I need. Unfortunately this means I need to to dive down into the labyrinth of (not existing) dosumentation.
Cheers & thanks
Ralf Mattes
-Dieter
-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E
Am Wed, 14 Sep 2016 20:48:16 +0200 schrieb "Ralf Mattes" rm@mh-freiburg.de:
Am Mittwoch, 14. September 2016 16:54 CEST, Dieter Klünter dieter@dkluenter.de schrieb:
Am Wed, 14 Sep 2016 16:00:33 +0200 schrieb "Ralf Mattes" rm@mh-freiburg.de:
... s there any to configure such an "alias suffix"?
There are quite a few possible solutions,
- slapd-relay(5)
- slapd-ldap(5)
and a few more.
I would recommend slapd-relay, configuration could be:
... database relay suffix o=uebermut,c=XX relay o=übermut,c=XX ...
depending on your database design you may need the rwm overlay and some rewrite rules.
Thank you,
I _knew_ I read about that at some time. This (slapd-relay) looks exactly like what I need. Unfortunately this means I need to to dive down into the labyrinth of (not existing) dosumentation.
Just read manual pages slapd-relay(5) and slapo-rwm(5) that is all the documentation you should need.
-Dieter
First, juat to be clear: thank you for your valuable help and please don't take my comments personally.
Am Donnerstag, 15. September 2016 09:46 CEST, Dieter Klünter dieter@dkluenter.de schrieb:
I _knew_ I read about that at some time. This (slapd-relay) looks exactly like what I need. Unfortunately this means I need to to dive down into the labyrinth of (not existing) dosumentation.
Just read manual pages slapd-relay(5) and slapo-rwm(5) that is all the documentation you should need.
That's how it should be, but in reality:
- non of the documentation even mentions the "new" live configuration. Ironically, every time someone postsher/his old-style slapd configuration on this very list she/he's told "use the online configuration".
Oh, and changing from the old style configuration to the new one is _not_ just an "add 'olc' in front of the parameters". For example I can't find the rwm-suffixmassage parameter in the olc-Attributes.
- The documentation fails to mention some rather important prerequisits: the need to load 'back_relay', the need to load 'rwm'.
- The documentation really should mention that a (miss-)configured database can't be removed from the server. Better get it right the first time ... :-)
- While looking for more information I found out that the documentation in the manpage (slapd-relay(5)) is _not_ the same as the documentation in the source code:
.../openldap-2.4.44/servers/slapd/back-relay/README
mentions a "mapping" keyword that isn't mentioned in the manpage. Oh, and no mention of the olc-variants either.
BTW, the olcRelay attribute seems to be defined with the OMsDN syntax which seems to prevent Apache Directory Studio to edit this value to add the "mapping" keyword.
O.k. enough ranting and on with configuration.
Chers, RalfD
-Dieter
-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E
Am Thu, 15 Sep 2016 15:12:16 +0200 schrieb "Ralf Mattes" r.mattes@mh-freiburg.de:
First, juat to be clear: thank you for your valuable help and please don't take my comments personally.
Am Donnerstag, 15. September 2016 09:46 CEST, Dieter Klünter dieter@dkluenter.de schrieb:
I _knew_ I read about that at some time. This (slapd-relay) looks exactly like what I need. Unfortunately this means I need to to dive down into the labyrinth of (not existing) dosumentation.
Just read manual pages slapd-relay(5) and slapo-rwm(5) that is all the documentation you should need.
That's how it should be, but in reality:
- non of the documentation even mentions the "new" live
configuration. Ironically, every time someone postsher/his old-style slapd configuration on this very list she/he's told "use the online configuration".
Oh, and changing from the old style configuration to the new oneis _not_ just an "add 'olc' in front of the parameters". For example I can't find the rwm-suffixmassage parameter in the olc-Attributes.
- The documentation fails to mention some rather important
prerequisits: the need to load 'back_relay', the need to load 'rwm'.
- The documentation really should mention that a (miss-)configured
database can't be removed from the server. Better get it right the first time ... :-)
- While looking for more information I found out that the
documentation in the manpage (slapd-relay(5)) is _not_ the same as the documentation in the source code:
.../openldap-2.4.44/servers/slapd/back-relay/READMEmentions a "mapping" keyword that isn't mentioned in the manpage. Oh, and no mention of the olc-variants either.
BTW, the olcRelay attribute seems to be defined with the OMsDN syntax which seems to prevent Apache Directory Studio to edit this value to add the "mapping" keyword.
O.k. enough ranting and on with configuration.
That's why i still use slapd.conf for intial setup, and after final configuration transform slapd.conf into config database. slaptest -f /path/to/file -F path/to/directory, directory is most likely /etc/openldap/slapd.d
-Dieter
Am Donnerstag, 15. September 2016 15:38 CEST, Dieter Klünter dieter@dkluenter.de schrieb:
O.k. enough ranting and on with configuration.
That's why i still use slapd.conf for intial setup, and after final configuration transform slapd.conf into config database. slaptest -f /path/to/file -F path/to/directory, directory is most likely /etc/openldap/slapd.d
Yes, but as both a developer and administrator I feel humiliated beeing forced to such quirks :-)
And I this case I need to modify an existing/runing server (which, let's not forget is the whole point of an online configuration).
So, fornow, I'm stuck with a configured realy database or which I can't configure the relay (server log complains about "RESULT tag=103 err=19 text=<olcRelay> extra cruft after <relay>" Which is, if I might say, not the most revealing error message ....
Cheers, Ralf Mattes
Am Donnerstag, 15. September 2016 15:38 CEST, Dieter Klünter dieter@dkluenter.de schrieb:
Am Thu, 15 Sep 2016 15:12:16 +0200 schrieb "Ralf Mattes" r.mattes@mh-freiburg.de:
O.k. enough ranting and on with configuration.
O.k. - I found the culprit (but not the solution). Trying to configure a olcRelay attribut whose value is a DN containing one ore more spaces will fail. I tried all sorts of escaping that value but nothing seems o work.
Is this a bug?
Cheers, RalfD
Am Donnerstag, 15. September 2016 22:19 CEST, "Ralf Mattes" r.mattes@mh-freiburg.de schrieb:
O.k. - I found the culprit (but not the solution). Trying to configure a olcRelay attribut whose value is a DN containing one ore more spaces will fail. I tried all sorts of escaping that value but nothing seems o work.
Is this a bug?
Some more info: using the same value as olcSuffix will generate the same error, so some the olcSuffix value seems to be parsed different that olcRelay even so the are suppoed to have the same syntax.
... olcAttributeTypes: ( OLcfgDbAt:0.10 NAME 'olcSuffix' EQUALITY distinguishedNam eMatch SYNTAX OMsDN ) ... olcAttributeTypes: ( OLcfgDbAt:5.1 NAME 'olcRelay' DESC 'Relay DN' SYNTAX OMsDN SINGLE-VALUE )
??? How can this happen?
Cheers, RalfD
On Thu, Sep 15, 2016 at 10:36:18PM +0200, Ralf Mattes wrote:
Am Donnerstag, 15. September 2016 22:19 CEST, "Ralf Mattes" r.mattes@mh-freiburg.de schrieb:
O.k. - I found the culprit (but not the solution). Trying to configure a olcRelay attribut whose value is a DN containing one ore more spaces will fail. I tried all sorts of escaping that value but nothing seems o work.
Is this a bug?
Some more info: using the same value as olcSuffix will generate the same error, so some the olcSuffix value seems to be parsed different that olcRelay even so the are suppoed to have the same syntax.
This is ITS#8284. Fixed in OpenLDAP 2.4.43.
The following config seems to work for me:
dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcSuffix: o=ACME Corp olcDbDirectory: data
dn: olcDatabase={2}relay,cn=config objectClass: olcRelayConfig olcSuffix: o=Foobar Conglomerate olcRelay: o=ACME Corp
dn: olcOverlay=rwm,olcDatabase={2}relay,cn=config objectClass: olcRwmConfig olcRwmRewrite: rwm-suffixmassage "o=ACME Corp"
Hello Ryan,
Am Freitag, 16. September 2016 06:14 CEST, Ryan Tandy ryan@nardis.ca schrieb:
This is ITS#8284. Fixed in OpenLDAP 2.4.43.
Yes, I found this by comparing my current git against the Debian sources. Looks like I need to backport that (trivial) fix. Too bad, I hate local patches.
The following config seems to work for me:
dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcSuffix: o=ACME Corp olcDbDirectory: data
dn: olcDatabase={2}relay,cn=config objectClass: olcRelayConfig olcSuffix: o=Foobar Conglomerate olcRelay: o=ACME Corp
dn: olcOverlay=rwm,olcDatabase={2}relay,cn=config objectClass: olcRwmConfig olcRwmRewrite: rwm-suffixmassage "o=ACME Corp"
Thanks, yes that works in the curren version but not in Debian's version. BTW, that little snippet would be very useful in the manpage.
Cheers, Ralf Mattes
Ralf Mattes wrote:
Am Freitag, 16. September 2016 06:14 CEST, Ryan Tandy ryan@nardis.ca schrieb:
This is ITS#8284. Fixed in OpenLDAP 2.4.43.
Yes, I found this by comparing my current git against the Debian sources. Looks like I need to backport that (trivial) fix. Too bad, I hate local patches.
The Debian packages are way behind anyway, lack many important fixes and I also hate this back-port hell.
So better build your own Debian packages from upstream source release or use [1]. You can also get rid of GnuTLS issues. ;-)
[1] http://ltb-project.org/wiki/documentation/openldap-deb
Ciao, Michael.
Am Freitag, 16. September 2016 10:15 CEST, Michael Ströder michael@stroeder.com schrieb:
Thanks, but that repository dpesn't seem to have sources for jessie. Looks like I need to go with the Debian Git version.
Cheers, Ralf Mattes
Ralf Mattes wrote:
Am Freitag, 16. September 2016 10:15 CEST, Michael Ströder michael@stroeder.com schrieb:
Thanks, but that repository dpesn't seem to have sources for jessie.
Not true:
http://ltb-project.org/debian/jessie/
Ciao, Michael.
Am Sonntag, 18. September 2016 12:22 CEST, Michael Ströder michael@stroeder.com schrieb:
Ralf Mattes wrote:
Am Freitag, 16. September 2016 10:15 CEST, Michael Ströder michael@stroeder.com schrieb:
Thanks, but that repository dpesn't seem to have sources for jessie.
Not true:
Sorry, just did the following again:
$ wget -O - http://ltb-project.org/debian/wheezy/dists/wheezy/main/source/Sources.gz | zless Package: openldap-ltb Format: 3.0 (native) Binary: openldap-ltb, openldap-ltb-dbg, openldap-ltb-check-password, openldap-ltb-contrib-overlays, openldap-ltb-mdb-utils Architecture: any Version: 2.4.40-1
Fine, there are the sources for wheezy. Next:
wget -O - http://ltb-project.org/debian/jessie/dists/jessie/main/source/Sources.gz | zless (END)
No sources for jessie. Or did I miss something? And before you ask: there are no sources in http://ltb-project.org/debian/jessie/pool/main/o/openldap-ltb/
Cheers, Ralf Mattes
2016-09-18 10:06 GMT-04:00 Ralf Mattes r.mattes@mh-freiburg.de:
Am Sonntag, 18. September 2016 12:22 CEST, Michael Ströder michael@stroeder.com schrieb:
Ralf Mattes wrote:
Am Freitag, 16. September 2016 10:15 CEST, Michael Ströder michael@stroeder.com schrieb:
Thanks, but that repository dpesn't seem to have sources for jessie.
Not true:
Sorry, just did the following again:
$ wget -O - http://ltb-project.org/debian/wheezy/dists/wheezy/main/source/Sources.gz | zless Package: openldap-ltb Format: 3.0 (native) Binary: openldap-ltb, openldap-ltb-dbg, openldap-ltb-check-password, openldap-ltb-contrib-overlays, openldap-ltb-mdb-utils Architecture: any Version: 2.4.40-1
Fine, there are the sources for wheezy. Next:
wget -O - http://ltb-project.org/debian/jessie/dists/jessie/main/source/Sources.gz | zless (END)
No sources for jessie. Or did I miss something? And before you ask: there are no sources in http://ltb-project.org/debian/jessie/pool/main/o/openldap-ltb/
Hi,
you are right, we did not publish sources as Debian source packages and we should do it.
For the moment, you can get the source files here: http://tools.ltb-project.org/projects/ltb/repository/show/openldap-deb/trunk...
Clément.
Am Sonntag, 18. September 2016 16:55 CEST, Clément OUDOT clem.oudot@gmail.com schrieb:
Hi,
you are right, we did not publish sources as Debian source packages and we should do it.
For the moment, you can get the source files here: http://tools.ltb-project.org/projects/ltb/repository/show/openldap-deb/trunk...
Is this substantially different from
git://anonscm.debian.org/pkg-openldap/openldap.git
That one seems to compile fine on Debian stable and contains the patch for back-relay that I need so urgent.
Cheers, Ralf Mattes
BTW, your project looks rather interessting, I might switch to that at some point.
Clément.
2016-09-18 11:29 GMT-04:00 Ralf Mattes r.mattes@mh-freiburg.de:
Am Sonntag, 18. September 2016 16:55 CEST, Clément OUDOT clem.oudot@gmail.com schrieb:
Hi,
you are right, we did not publish sources as Debian source packages and we should do it.
For the moment, you can get the source files here: http://tools.ltb-project.org/projects/ltb/repository/show/openldap-deb/trunk...
Is this substantially different from
git://anonscm.debian.org/pkg-openldap/openldap.git
That one seems to compile fine on Debian stable and contains the patch for back-relay that I need so urgent.
Yes, LDAP Tool Box just takes the latest OpenLDAP stable release and publish RPM/Debian packages. It does not provide development versions of OpenLDAP, unless there is a big issue that need to be patched before OpenLDAP official release.
Clément.
Ralf Mattes wrote:
Am Freitag, 16. September 2016 10:15 CEST, Michael Ströder
michael@stroeder.com schrieb:
Thanks, but that repository dpesn't seem to have sources for jessie.
scroll down and you will find:
If you use jessie, as we only ship 64bits packages, you should restrict apt-get on amd64 arch: deb [arch=amd64] http://ltb-project.org/debian/jessie jessie main
Looks like I need to go with the Debian Git version.
Cheers, Ralf Mattes
Am Sonntag, 18. September 2016 14:46 CEST, Harry Jede harry.jede@arcor.de schrieb:
Ralf Mattes wrote:
Am Freitag, 16. September 2016 10:15 CEST, Michael Ströder
michael@stroeder.com schrieb:
Thanks, but that repository dpesn't seem to have sources for jessie.
scroll down and you will find:
If you use jessie, as we only ship 64bits packages, you should restrict apt-get on amd64 arch: deb [arch=amd64] http://ltb-project.org/debian/jessie jessie main
Hmm, sources don't use architectures. They are _sources_ after all ...
Cheers, Ralf Mattes
openldap-technical@openldap.org
-
Clément OUDOT -
Dieter Klünter -
Harry Jede -
Michael Ströder -
Ralf Mattes -
Ralf Mattes -
Ryan Tandy