Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chain overlay not supported #431

Open
nickurbanik opened this issue Aug 9, 2024 · 1 comment
Open

chain overlay not supported #431

nickurbanik opened this issue Aug 9, 2024 · 1 comment

Comments

@nickurbanik
Copy link

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 6.3.0
  • Ruby: 3.3.4
  • Distribution: CentOS 7
  • Module version: HEAD

How to reproduce (e.g Puppet code you use)

profiles::openldap::overlay:
    chain on ou=my-suffix:
        ensure: present
        options:
            olcChainReturnError: 'TRUE'

What are you seeing

Error: Could not prefetch openldap_database provider 'olc': No resource and no name in property hash in olc instance
Error: Failed to apply catalog: No resource and no name in property hash in olc instance

What behaviour did you expect instead

I expected this entry to be made in cn=config:

dn: olcOverlay={6}chain,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {6}chain
olcChainReturnError: TRUE

Any additional information you'd like to impart

https://github.com/voxpupuli/puppet-openldap/blob/master/lib/puppet/provider/openldap_overlay/olc.rb does not include the chain overlay, with objectClass olcChainConfig.

The chain overlay differs from other overlays in that it is built into the ldap backend, and is not a separate module. The OpenLDAP 2.6.8 code includes https://git.openldap.org/openldap/openldap/-/blob/master/tests/scripts/test022-ppolicy, which specifies two LDAP entries to implement the chain overlay:

dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain

dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDBURI: $URI1
olcDbIDAssertBind: bindmethod=simple
  binddn="cn=manager,dc=example,dc=com"
  credentials=secret
  mode=self
  • Please may we have support for the chain overlay (essential with ppolicy and where users interact with replicas)
  • How do we represent the second LDAP entry in our puppet manifest/YAML?
@gcoxmoz
Copy link
Contributor

gcoxmoz commented Feb 7, 2025

I spent some time on this, it's not-simple.

Adding an overlay that can do olcChainConfig is a simple one line change, no big deal.

However, since chains usually (always?) attach to olcDatabase={-1}frontend,cn=config, and all previous overlays are meant to use a plain-ol' 'data' database, the overlay provider doesn't know how to detect/use a chain overlay in a way that makes sense. That's actually not that hard either. We have some prior art from the openldap_access provider where they use the "it's not really named that but it makes sense kinda" convention of cn=frontend to mean "this applies to olcDatabase={-1}frontend,cn=config" , which I copied.

I've sent the above up as a PR, which on its own helps a bit, but doesn't solve the whole chaining problem.

The bigger issue is that provider openldap_database has at least three places where it assumes all olcDatabase=ldap databases are defined as olcDatabase={N}ldap,cn=config ('root level databases of type ldap') and the provider won't handle olcDatabase={N}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config ('chained databases of type ldap'). AND, since the module's knowledge of olcDatabase=frontend is suspect to begin with, the parsing is going to be a little exciting. The overlay provider being accepted/rejected can really frame how progress on editing the database provider looks in a future PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants