Custom Schema about docker-openldap

[miamilabs]

This image already supplies that schema, you don't need to do it.

If you check the other open issue that I reported, you'll see that I am already using the postfix-book.schema implicitly within the image, here's a quick snippet:

docker run --rm --name ldap-test \
  --env LDAP_ROOT='dc=example,dc=test' \
  --env LDAP_PORT_NUMBER=389 \
  --volume '/tmp/ldif/:/migrations/:ro' \
  --hostname 'ldap.example.test' \
  registry.gitlab.com/bitspur/rock8s/docker-openldap

I share the .ldif files I used there, and all was added into migrations/, but I later identified that was not necessary (also new to LDAP and was updating a project with existing files from an older no longer maintained OpenLDAP image).

I had an issue with ACLs that needed a separate migration to resolve as the linked issue shares as a solution. I'm not sure why as it is not required for the upstream bitnami/openldap, this variant has done something differently with the default ACL settings.

In the end, I managed to get bitnami/openldap working for me and went back to it as I didn't need any extra features / conveniences of this image (which is a bit too new for me to feel comfortable adopting).

You can find an example of using bitnami/openldap and the full .ldif data (including a postfix-book.schema converted to .ldif schema) in my PR here: docker-mailserver/docker-mailserver#3494

i just seen your contribution on docker-mailserver. Will try to run it later on.
Thank you again for the reply

[polarathene]

This image already supplies that schema, you don't need to do it.

If you check the other open issue that I reported, you'll see that I am already using the postfix-book.schema implicitly within the image, here's a quick snippet:

docker run --rm --name ldap-test \
  --env LDAP_ROOT='dc=example,dc=test' \
  --env LDAP_PORT_NUMBER=389 \
  --volume '/tmp/ldif/:/migrations/:ro' \
  --hostname 'ldap.example.test' \
  registry.gitlab.com/bitspur/rock8s/docker-openldap

I share the .ldif files I used there, and all was added into migrations/, but I later identified that was not necessary (also new to LDAP and was updating a project with existing files from an older no longer maintained OpenLDAP image).

I had an issue with ACLs that needed a separate migration to resolve as the linked issue shares as a solution. I'm not sure why as it is not required for the upstream bitnami/openldap, this variant has done something differently with the default ACL settings.

---

In the end, I managed to get bitnami/openldap working for me and went back to it as I didn't need any extra features / conveniences of this image (which is a bit too new for me to feel comfortable adopting).

You can find an example of using bitnami/openldap and the full .ldif data (including a postfix-book.schema converted to .ldif schema) in my PR here: docker-mailserver/docker-mailserver#3494

[miamilabs]

This image already supplies that schema, you don't need to do it.

If you check the other open issue that I reported, you'll see that I am already using the postfix-book.schema implicitly within the image, here's a quick snippet:

docker run --rm --name ldap-test \
  --env LDAP_ROOT='dc=example,dc=test' \
  --env LDAP_PORT_NUMBER=389 \
  --volume '/tmp/ldif/:/migrations/:ro' \
  --hostname 'ldap.example.test' \
  registry.gitlab.com/bitspur/rock8s/docker-openldap

I share the .ldif files I used there, and all was added into migrations/, but I later identified that was not necessary (also new to LDAP and was updating a project with existing files from an older no longer maintained OpenLDAP image).

I had an issue with ACLs that needed a separate migration to resolve as the linked issue shares as a solution. I'm not sure why as it is not required for the upstream bitnami/openldap, this variant has done something differently with the default ACL settings.

In the end, I managed to get bitnami/openldap working for me and went back to it as I didn't need any extra features / conveniences of this image (which is a bit too new for me to feel comfortable adopting).

You can find an example of using bitnami/openldap and the full .ldif data (including a postfix-book.schema converted to .ldif schema) in my PR here: docker-mailserver/docker-mailserver#3494

That is strange, for some reason the postfix items wont show up in my list.

Here are the attributes which i get.
https://ibb.co/D84mK32

Did i miss anything in my config above? Can it be that macOS docker ignore those schemas for some reason?

[polarathene]

That is strange, for some reason the postfix items wont show up in my list.

Here are the attributes which i get. https://ibb.co/D84mK32

I assume from the image link it's a GUI showing you LDAP information or some dropdown?

I only have experience with what I worked on which was just the LDIF text files (.ldif extension_), we only use it for a small test for LDAP compatibility, so it's easy to setup and experiment with. I assume a GUI app should be aware of the postfix-book schema attributes and 2 classes it adds, but you might find it easier to just confirm it's working with a small .ldif demo like the PR I linked demonstrates.

LDIF files for the full LDAP tree + converted postfix-book.schema are here: https://github.com/polarathene/docker-mailserver/tree/e05f4131b64d9758bb4e1fb57086c2b7fdc3ec5b/test/config/ldap/docker-openldap/bootstrap

Then just add those as volumes and run the same docker run used in the PR:

  docker run --rm -d --name ldap-test \
    --env LDAP_ADMIN_PASSWORD=admin \
    --env LDAP_ROOT='dc=localhost,dc=localdomain' \
    --env LDAP_PORT_NUMBER=389 \
    --env LDAP_SKIP_DEFAULT_TREE=yes \
    --volume './bootstrap/ldif/:/ldifs/:ro' \
    --volume './bootstrap/schemas/:/schemas/:ro' \
    bitnami/openldap:latest

• I removed the added network + hostname (was used for the main project container to connect to the LDAP container, this is why I needed to set the port number to 389 as well, since port mapping wouldn't help between two containers directly interacting on the same network).
• Shortened the volume paths to the referenced bootstrap folder.

Heads-up: a future PR will be adjusting the LDIF configs further as they contain inappropriate attributes (uniqueIdentifier via extensibleObject class workaround) and the localhost.localdomain will be changed to example.test. I just need to tackle some other tasks prior 😅

[polarathene]

Can it be that macOS docker ignore those schemas for some reason?

I am aware of Docker sometimes having some issues on macOS that aren't compatible, but it's probably unlikely in this case.

You can always setup a VM guest with VirtualBox or VMware Workstation Player, both are free and easy to use GUI. If you're comfortable with linux, it's fairly easy to setup a VM guest yourself and run Docker from that directly, as macOS is technically doing the same AFAIK when using Docker anyway... but this way you'd be able to better rule out any macOS compatibility issues.

---

If you were referring to this snippet:

docker run --rm --name ldap-test \
  --env LDAP_ROOT='dc=example,dc=test' \
  --env LDAP_PORT_NUMBER=389 \
  --volume '/tmp/ldif/:/migrations/:ro' \
  --hostname 'ldap.example.test' \
  registry.gitlab.com/bitspur/rock8s/docker-openldap

Make sure the volume mount is adjusted to whatever is relevant in macOS if using docker run (also to get relative ./ paths I think it needs to be at least Docker v23? docker compose has supported relative paths for much longer).

You can skip the hostname setting as it's not likely relevant to you (EDIT: Actually I saw you configure it in your compose.yaml, but you might want to use only hostname, not domainname, unless you understand that domainname is for NIS domain specifically).

BITNAMI_DEBUG=true should otherwise be providing you with plenty of log output where you can see if there is any errors, I found it very helpful for both this image and bitnami/openldap when they initially didn't like my .ldif files.

[clayrisser]

@miamilabs I've had trouble getting the Apache LDAP Studio to show the schemas. I don't know exactly why, but they should show up in PHPLdapAdmin and they will work for queries.

The only exception could be if you have bad schemas or duplicate schemas, then it could prevent other schemas from loading, so check the logs to make sure that doesn't happen.