Re: ldapi issue
thank you very much Ulf, it works.
Re: ldapi issue
--On Monday, February 12, 2024 5:09 PM + Chili Mili wrote: find / -type s find: '/proc/9/map_files': Permission denied /usr/var/run/ldapi The Unix socket file located inside the container is at /usr/var/run/ldapi. I have tried to mount it to the host system but encountered the same result. any idea? This sounds like the slapd process is being told to use a different location than the compile time default for the unix socket, which is why ldapi:/// doesn't work (it defaults to the compile time location). You'll have to explicitly pass the location OR change the startup to just use the default location. --Quanah
Re: ldapi issue
Le 12/02/2024 à 16:19, Chili Mili a écrit :
outside:
lsof -U |grep slapd
--> no output
Hi,
maybe I can help here
If lsof isn't installed inside the container you may use nsenter
("namespace enter") on the host
You'll need the PID of the running container
Details here
https://contractdesign.github.io/docker/2021/06/10/nsenter.html
--
Grégory Rocher
02 29 00 85 79 (8579)
Re: ldapi issue
Am 12.02.24 um 18:09 schrieb Chili Mili: find / -type s find: '/proc/9/map_files': Permission denied /usr/var/run/ldapi The Unix socket file located inside the container is at /usr/var/run/ldapi. I have tried to mount it to the host system but encountered the same result. Again, use it from inside of the container. You can put the socket after the -H ldapi://. If I remember correctly, you have to replace the slashes with %2F. So you will need something like -H ldapi://%2Fusr%2Fvar%2Frun%2Fldapi Best regards Ulf
Re: ldapi issue
find / -type s find: '/proc/9/map_files': Permission denied /usr/var/run/ldapi The Unix socket file located inside the container is at /usr/var/run/ldapi. I have tried to mount it to the host system but encountered the same result. any idea? thanks
Re: ldapi issue
Am 12.02.24 um 17:01 schrieb Chili Mili: it seems that Unix sockets aren't being used. I've compared the results with the old server, and they are consistent. Additionally, I've checked using lsof -U -a -p with the same outcome. Please keep in mind that the ldap is running in the docker container Yes, I aware of that. So you should look for the socket inside of the container. Best regards Ulf
Re: ldapi issue
it seems that Unix sockets aren't being used. I've compared the results with the old server, and they are consistent. Additionally, I've checked using lsof -U -a -p with the same outcome. Please keep in mind that the ldap is running in the docker container
Re: ldapi issue
Am 12.02.24 um 16:19 schrieb Chili Mili: inside the container: lsof -U |grep slapd bash: lsof: command not found That's quite sad. I assume, you have no experience using linux? Best regards Ulf
Re: ldapi issue
inside the container: lsof -U |grep slapd bash: lsof: command not found outside: lsof -U |grep slapd --> no output
Re: ldapi issue
Am 12.02.24 um 13:18 schrieb Chili Mili: per example : ourside of the container : docker exec -it lsof -U |grep slapd would be interesting. Best regards Ulf
Re: ldapi issue
per example : ourside of the container : docker exec -it
Re: olcLimits and groupOfURLs dynlist
Greetings. A summary, for the archive and for google The missing piece, from my point of view, is that it looks like the group selector, for the olcLimits option (which is what I started off looking at; and see slapd-config(5)) has similar semantics to that for the corresponding olcAccess option, more fully documented in slapd.access(5). In the documentation of the field there, we learn that 'The statement group= means that access is granted to requests whose DN is listed in the group entry whose DN is given by .' But despite slapo-dynlist saying 'Any time an entry with a specific objectClass is being returned...', this does _not_ apply here, since the next paragraph of slapd.access says 'For dynamic groups the attributeType must be a subtype of the labeledURI attributeType. Only LDAP URIs of the form ldap:///??? will be evaluated in a dynamic group, by searching the local server only.' That is, the olcAccess group processing is, in effect, restricted to the three-argument version of the attrset option of slapo-dynlist -- that's what I had missed. Presuming the olcLimits option has the same restriction, then the effect I was initially aiming to achieve -- setting a limit for members of a particular group which is dynamically populated -- is not possible for me by this route. The groups I'm aiming to set limits and access for are most naturally defined from the union of other groups. Such groups are easy to define via the two-argument dynlist-attrset value (which uses ldap:///?member?sub?), but not, as far as I can see, via the three-argument one. I can probably instead synthesise the groups I want, dynamically, by introducing a memberOf attribute attached to the groups' members, but I worry that has the potential to get a little messy in practice; I notice group.expand, which might help. I notice that the documentation of olcAccess doesn't actually mention the dynlist overlay, and thus may be entirely independent of it. Something for me to investigate. Best wishes, Norman -- Norman Gray : https://nxg.me.uk
