[bitnami/openldap] post-read control

[azmeuk]

Name and Version

bitnami/openldap 2.6.9

What is the problem this feature will solve?

I plan to migrate from the unsupported Osixia OpenLDAP image to the bitnami.
After some tests, I see that my application fails when using the post-read control.
The main clue in the OpenLDAP log is get_ctrls failed

ldap-1      | 679f5b38.180313b8 0x78f8f33fd6c0 conn=1003 fd=13 ACCEPT from IP=172.18.0.3:46998 (IP=0.0.0.0:1389)
ldap-1      | 679f5b38.1803a585 0x78f8f3bfe6c0 conn=1003 op=0 BIND dn="cn=admin,dc=example,dc=org" method=128
ldap-1      | 679f5b38.18041d96 0x78f8f3bfe6c0 conn=1003 op=0 BIND dn="cn=admin,dc=example,dc=org" mech=SIMPLE bind_ssf=0 ssf=0
ldap-1      | 679f5b38.1804c64f 0x78f8f3bfe6c0 conn=1003 op=0 RESULT tag=97 err=0 qtime=0.000009 etime=0.000093 text=
ldap-1      | 679f5b38.18072745 0x78f8f33fd6c0 conn=1003 op=1 SRCH base="cn=subschema" scope=0 deref=0 filter="(objectClass=*)"
ldap-1      | 679f5b38.18077cf6 0x78f8f33fd6c0 conn=1003 op=1 SRCH attr=* +
ldap-1      | 679f5b38.181bb8de 0x78f8f33fd6c0 conn=1003 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000009 etime=0.001366 nentries=1 text=
ldap-1      | 679f5b38.19e74e65 0x78f8f3bfe6c0 conn=1003 op=2 SRCH base="cn=subschema" scope=0 deref=0 filter="(objectClass=*)"
ldap-1      | 679f5b38.19e7bc90 0x78f8f3bfe6c0 conn=1003 op=2 SRCH attr=* +
ldap-1      | 679f5b38.19fbf7c4 0x78f8f3bfe6c0 conn=1003 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000010 etime=0.001389 nentries=1 text=
ldap-1      | 679f5b38.1ae0e792 0x78f8f33fd6c0 conn=1002 op=2 RESULT tag=105 err=17 qtime=0.000011 etime=0.000115 text=attribute type undefined
ldap-1      | 679f5b38.1ae15886 0x78f8f33fd6c0 conn=1002 op=2 do_add: get_ctrls failed

What is the feature you are proposing to solve the problem?

I would suggest to enable the post-read control if possible.
Honestly, I am not even sure how to do this. The control had always been enabled by default on OpenLDAP instances I interacted with, and it appears to not be very documented.

[azmeuk]

Nervermind, this is probably something else.