Discussion:
translucent overlay and local objects?
(too old to reply)
Eugene Vilensky
2012-04-09 21:34:02 UTC
Permalink
Greetings,

Pardon if this is an RTFM (I'd love a link), but is it possible to
store entities locally using the translucent overlay?

The overlay works for what we are trying to do when it comes to search
and modifying attributes on an entry, but I would like to create an
entire local groupofnames, consisting of remote UIDs.

For example, this LDIF imports OK:

#!RESULT OK
#!CONNECTION ldap://xxxxx
#!DATE 2012-04-09T16:01:33.961
dn: cn=instructors,ou=Groups,dc=xxxx,dc=zzz
changetype: add
objectClass: groupofnames
member: uid=nate
member: uid=penelope
member: uid=rhonda
cn: instructors


But searching for it does not bring back a result.

However, it must have gone somewhere since if I try to import the same
LDIF again:

#!RESULT ERROR
#!CONNECTION ldap://xxxxx
#!DATE 2012-04-09T16:21:28.221
#!ERROR [LDAP: error code 68 - Entry Already Exists]

Kind regards,
Eugene
Howard Chu
2012-04-09 22:15:58 UTC
Permalink
Post by Eugene Vilensky
Greetings,
Pardon if this is an RTFM
Yes.
Post by Eugene Vilensky
(I'd love a link),
Read slapo-translucent(5).
Post by Eugene Vilensky
but is it possible to
store entities locally using the translucent overlay?
No.
Post by Eugene Vilensky
The overlay works for what we are trying to do when it comes to search
and modifying attributes on an entry, but I would like to create an
entire local groupofnames, consisting of remote UIDs.
That is not supported.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Eugene Vilensky
2012-04-10 13:10:05 UTC
Permalink
Post by Howard Chu
Read slapo-translucent(5).
Thanks, it's a good read. Since it only mentions the remote Search
operation, my next questions might be moot...
Post by Howard Chu
Post by Eugene Vilensky
but is it possible to
store entities locally using the translucent overlay?
No.
Will entities created against the translucent overlay be created in
the 'upstream' directory, provided our bind dn to that directory has
necessary privileges?
Post by Howard Chu
Post by Eugene Vilensky
The overlay works for what we are trying to do when it comes to search
and modifying attributes on an entry, but I would like to create an
entire local groupofnames, consisting of remote UIDs.
That is not supported.
Would it be found anywhere on the roadmap?

Thanks again,
Eugene
David Arroyo
2012-04-10 22:33:45 UTC
Permalink
Hi Eugene,

All changes you make to a translucent proxy will be written to the
local database. They are not written upstream. I think you will want
to mess with the chain overlay to produce an affect like that.

I have been able to achieve what you are proposing by creating a
subordinate database for my entirely new objects. The translucent
proxy serves and modifies objects at dc=example,dc=org, and the
subordinate database lives at ou=ext,dc=example,dc=org.

Cheers,
David
Post by Howard Chu
Read slapo-translucent(5).
Thanks, it's a good read.  Since it only mentions the remote Search
operation, my next questions might be moot...
Post by Howard Chu
Post by Eugene Vilensky
but is it possible to
store entities locally using the translucent overlay?
No.
Will entities created against the translucent overlay be created in
the 'upstream' directory, provided our bind dn to that directory has
necessary privileges?
Post by Howard Chu
Post by Eugene Vilensky
The overlay works for what we are trying to do when it comes to search
and modifying attributes on an entry, but I would like to create an
entire local groupofnames, consisting of remote UIDs.
That is not supported.
Would it be found anywhere on the roadmap?
Thanks again,
Eugene
Eugene Vilensky
2012-04-11 14:49:37 UTC
Permalink
Hi David
Post by David Arroyo
Hi Eugene,
All changes you make to a translucent proxy will be written to the
local database. They are not written upstream. I think you will want
to mess with the chain overlay to produce an affect like that.
This would explain the behavior that objects already exist :) Thank you.
Post by David Arroyo
I have been able to achieve what you are proposing by creating a
subordinate database for my entirely new objects. The translucent
proxy serves and modifies objects at dc=example,dc=org, and the
subordinate database lives at ou=ext,dc=example,dc=org.
Is it possible you could share with me a skeleton of your
configuration? I am on RHEL5, slapd 2.3.43, hence I'm still working
with slapd.conf. (Learning the 2.4 dynamic configuration style is on
my to do list...I think I will want the memberof attribute overlay)

I implemented desired functionality minus translucency by having the
following database clauses -- (I can create entities within the
ou=groups and searches against the ou=Users are results from remote
LDAP.

----
database bdb
suffix "dc=dept,dc=example,dc=org"

database meta
suffix "dc=example,dc=org"

uri "ldap://remoteldap.example.org/ou=people,dc=example,dc=org"
uri "ldap://localhost/ou=groups,dc=dept,dc=example,dc="
Howard Chu
2012-04-12 11:01:11 UTC
Permalink
Post by Eugene Vilensky
I am on RHEL5, slapd 2.3.43, hence I'm still working
with slapd.conf. (Learning the 2.4 dynamic configuration style is on
my to do list...I think I will want the memberof attribute overlay)
The dynamic configuration mechanism was released in 2.3. It is documented in
the 2.3 Admin Guide. There is no reason to stay with slapd.conf.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
David N. Blank-Edelman
2012-04-12 14:40:14 UTC
Permalink
Hi Howard-
The dynamic configuration mechanism was released in 2.3. It is documented in the 2.3 Admin Guide. There is no reason to stay with slapd.conf.
As of several months ago, only back-sql and back-meta remain
incompatible. All of the overlays have already been converted.
The back-meta conversion was the thing holding us back from moving to the correct config method. Has that and back-sql been converted? If so, that would be great.

-- dNb
Howard Chu
2012-04-12 18:10:45 UTC
Permalink
Post by David N. Blank-Edelman
Hi Howard-
The dynamic configuration mechanism was released in 2.3. It is documented in the 2.3 Admin Guide. There is no reason to stay with slapd.conf.
As of several months ago, only back-sql and back-meta remain
incompatible. All of the overlays have already been converted.
The back-meta conversion was the thing holding us back from moving to the correct config method. Has that and back-sql been converted? If so, that would be great.
back-sql has been converted.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Eugene Vilensky
2012-04-17 13:20:00 UTC
Permalink
Post by Howard Chu
Post by David N. Blank-Edelman
Hi Howard-
Post by Howard Chu
The dynamic configuration mechanism was released in 2.3. It is documented
in the 2.3 Admin Guide. There is no reason to stay with slapd.conf.
As of several months ago, only back-sql and back-meta remain
incompatible. All of the overlays have already been converted.
The back-meta conversion was the thing holding us back from moving to the
correct config method. Has that and back-sql been converted? If so, that
would be great.
back-sql has been converted.
So the meta-backend cannot be used in 2.4 releases, which mandate
dynamic configuration?

Thank you,
Eugene
Howard Chu
2012-04-17 13:47:40 UTC
Permalink
Post by Eugene Vilensky
So the meta-backend cannot be used in 2.4 releases, which mandate
dynamic configuration?
2.4 still supports slapd.conf. Nobody has mandated anything.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Eugene Vilensky
2012-05-15 21:10:49 UTC
Permalink
Post by Eugene Vilensky
I implemented desired functionality minus translucency by having the
following database clauses -- (I can create entities within the
ou=groups and searches against the ou=Users are results from remote
LDAP.
----
database        bdb
suffix "dc=dept,dc=example,dc=org"
database meta
suffix  "dc=example,dc=org"
uri     "ldap://remoteldap.example.org/ou=people,dc=example,dc=org"
uri     "ldap://localhost/ou=groups,dc=dept,dc=example,dc="
It's probably bad form to reply to my own query, but maybe someone has
experience with this?:

Given the meta directory proposed above, what would be the best way to
add translucency as as well?

Thanks for any advice,
Eugene
David Arroyo
2012-05-17 00:28:49 UTC
Permalink
Hi Eugene,

I've gone through my config and pulled out the useful bits. It's in
the cn=config ldif format. I'm succesfully using this in production to
give Active Directory users under dc=company,dc=com the extra bits
(uid/gid, homeDir etc) needed to access our unix machines. We cannot
get the AD admins to put this information into AD itself. We can also
make "local" users, groups, nisMaps and anything else under
ou=local_ext,dc=company,dc=com.

# All I need from AD is the sAMAccountName, which I use as user's UID. I do not
# use AD groups but rather create my own groups under ou=local_ext.
dn: cn=ADext,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: ADext
olcAttributeTypes: {0}( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' DESC 'MS
User identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SY
NTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# Completeley new records go under ou=local_ext. Note the subordinate
declaration
# to define a glue database
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/ldap/local_ext
olcSubordinate: TRUE
olcSuffix: ou=local_ext,dc=company,dc=com
olcRootDN: cn=config

# The database to hold annotations to entries in the remote AD
dn: olcDatabase={3}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {3}bdb
olcDbDirectory: /var/lib/ldap/translucent
olcSuffix: dc=company,dc=com

# The translucentLocal declaration is important for nss_ldap to work
dn: olcOverlay={0}translucent,olcDatabase={3}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcTranslucentConfig
olcOverlay: {0}translucent
olcTranslucentLocal: uidNumber,gidNumber,loginShell,homeDirectory

# The IDAuthz

Loading...