openldap-technical

openldap-technical@openldap.org

9 participants
9867 discussions

Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul 29 Jun '20

29 Jun '20

Hi Quanah Please find my answers inline a) Both servers have no DB, but are using these configs [Rahul] Both servers are started with an empty database. Both servers are in Provider and consumer mode. Our application is running on both servers as well. To start with our application is active on Server A, which means data will be written to server A database.and is synced/replicated to server B b) DB is added to server A and replicated to server B [Rahul] Yes since server A has our application in active mode hence data is written on server A and replicated to server B. c) server A is stopped [Rahul] yes we reboot the server A. d) You say "data is removed", I'm not sure what this means. A single entry? Multiple entries? The entire database? [Rahul] Now our application is active on Server B. Using server B removed "a Single Entry" which was removed from server B database as well. e) S1 is restarted, and the deleted data is replicated back to both nodes. [Rahul] Yes deleted data is replicated back to both nodes. when S1 is restarted slapd is configured in provider/consumer mode but our application is still active on server B which means writes will only happen at server B and should be synced to server A. Thank you for all the help so far. I have no intention of interrupting your work. Please look at my issue based on your convenience. Let me know if you have any other questions. Thanks Rahul On Tue, Jun 23, 2020 at 3:43 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, June 23, 2020 1:47 PM -0400 kumar rahul > <rahul2002mit(a)gmail.com> wrote: > > > Both the servers are set up as master as well as consumer so that > > sync works in both directions. So > > the sync setup is like "A -> B", > > and when A fails B is updated and the expectation is that "B -> A" should > > work because a multi master setup is already in place. Let me know based > > on the attached configuration files if my assumption is correct or not. > > > > > > Also Add data works when A fails and B is updated then sync "B -> A"works > > fine. > > > > After Delete data sync does not work when A fails and data is deleted > > from B. Once A comes back both databases have data which was deleted on > B. > > Hi, > > I'll see if I can reproduce your issue with the configs provided (Assuming > they look correct after I finish reviewing them in full), but I want to > confirm the exact steps: > > a) Both servers have no DB, but are using these configs > > b) DB is added to server A and replicated to server B > > c) server A is stopped > > d) You say "data is removed", I'm not sure what this means. A single > entry? Multiple entries? The entire database? > > e) S1 is restarted, and the deleted data is replicated back to both nodes. > > Note that I do have a paid job that keeps me busy, so this is a best > effort > when I have time available to investigate. > > Thanks, > Quanah > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

LMDB transaction flags
by Stefano Cossu 29 Jun '20

29 Jun '20

Hello, I'd like to be able to know if a LMDB transaction is active, valid, dirty, read-only, etc. From the documentation I read that such information is in mt_flags of the mdb_txn structure, which is opaque. I don't see any function exposing mt_flags. Is there any other way to read that information?

2 4

[Question]: Looking for updated ppolicy in v2.4.50
by Dave Macias 29 Jun '20

29 Jun '20

Hello, Using openldap v2.4.50 and noticed that there were some updates <https://github.com/openldap/openldap/commit/4bc54d104a9563d35f3d5fc2e69fe7a…> which were part of the 2.4.50 release. I installed openldap but cannot find those new attributes (pwdMaxLength, pwdStartTime, etc) > grep pwdMaxL /etc/openldap/schema/* > grep pwdStar /etc/openldap/schema/* Maybe I am missing something. Could someone please point me in the right direction? Thank you, Dave

2 1

Re: [Question]: centos8 install - looking for migrationtools package
by Dave Macias 29 Jun '20

29 Jun '20

Thank you for the reply! Decided to use the centos7 versions. They worked like a charm! Regards, Dave On Fri, Jun 26, 2020 at 2:56 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, June 25, 2020 1:01 PM -0400 Dave Macias <davama(a)gmail.com> > wrote: > > > > > Hello, > > > > > > Our production env is centos7 and we were testing to see how it would > > work on centos8. > > > > > > There were no issues using the symas pkgs. Thank you for providing them! > > > > > > I was wondering if someone knew where I could find the migrationtools for > > centos8? > > I think since rhel stopped supporting openldap-servers, it would make > > sense that the migrationtools package would disappear too. > > > > > > Perhaps this is not the right place to ask, but any input is much > > appreciated. > > What you would likely need to do is look at the Fedora git repository for > the migrationtools package and port it for CentOS8 and then build it > yourself. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

OpenLDAP results limited via SSL?
by a.leurs＠consense-gmbh.de 27 Jun '20

27 Jun '20

Hello, I have installed OpenLDAP on my Windows machine (Windows 10) and configured a connection to our company LDAP. The connection is via LDAPS. Here is my slapd.conf #LDAP Backend configuration file # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/nis.schema include ./schema/inetorgperson.schema pidfile ./run/slapd.pid argsfile ./run/slapd.args # Full log level loglevel 32768 16384 2048 1024 512 256 128 64 32 16 8 4 2 1 sizelimit 10000 timelimit 10000 # Enable TLS if port is defined for ldaps (to openldap) TLSVerifyClient never #TLSCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL TLSCipherSuite HIGH:MEDIUM:-SSLv2:-SSLv3 TLSProtocolMin 3.3 TLSCertificateFile ./secure/certs/maxcrc.cert.pem TLSCertificateKeyFile ./secure/certs/maxcrc.key.pem TLSCACertificateFile ./secure/certs/maxcrc.cert.pem # Configuration for Connection to company.local database meta suffix "DC=company,DC=local" rootdn "DC=company,DC=local" rebind-as-user yes uri ldaps://DC001.company.local:636/dc=company,DC=local lastmod off chase-referrals no idassert-bind bindmethod=simple binddn="cn=CN=User Name,OU=Users,OU=Orga,DC=company,DC=local" credentials=XXX tls_reqcert=never tls_cacert=./secure/certs/company-ca.pem tls ldaps tls_reqcert=allow tls_cacert=./secure/certs/company-ca.pem overlay rwm rwm-map attribute uid samaccountname rwm-map attribute member memberOf rwm-map attribute sn sn rwm-map attribute givenname givenname rwm-map attribute intials initials When I connect to the OpenLDAP server with Softerra LDAP-Browser and search the directory I don't get any results, when the results are more than 65 entries. When I use paging in the search (to restrict the results to only 65 results) then it works. On a machine of a colleague the limit is 70 results. We didn't find any information where an restriction on the LDAP server could be. Any idea why the results are limited? When I do a connection without SSL it works fine.

3 4

[Question]: centos8 install - looking for migrationtools package
by Dave Macias 26 Jun '20

26 Jun '20

Hello, Our production env is centos7 and we were testing to see how it would work on centos8. There were no issues using the symas pkgs. Thank you for providing them! I was wondering if someone knew where I could find the migrationtools for centos8? I think since rhel stopped supporting openldap-servers, it would make sense that the migrationtools package would disappear too. Perhaps this is not the right place to ask, but any input is much appreciated. Thank you, Dave

2 1

Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul 23 Jun '20

23 Jun '20

Hi Quanah Both the servers are set up as master as well as consumer so that sync works in both directions. So the sync setup is like "A -> B", and when A fails B is updated and the expectation is that "B -> A" should work because a multi master setup is already in place. Let me know based on the attached configuration files if my assumption is correct or not. Also Add data works when A fails and B is updated then sync "B -> A"works fine. After Delete data sync does not work when A fails and data is deleted from B. Once A comes back both databases have data which was deleted on B. Thanks Rahul On Tue, Jun 23, 2020 at 8:11 AM Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 22.06.2020 um 18:09 > in > Nachricht > <13855_1592842197_5EF0D7D5_13855_226_1_A497B27F9A5328340A4CDBAC@ > [192.168.1.144]> > > > > > > ‑‑On Monday, June 22, 2020 3:08 PM +0000 Kumar Rahul > > <rahul2002mit(a)gmail.com> wrote: > > > >> Hi Quanah > >> > >> Thank you for all the help so far. I am still seeing the original > >> issue reported. Let me know if you need fresh set of configuration > >> information. > > > > I've told you repeatedly what is necessary, you haven't provided it. > > > > To re‑iterate: > > > > Full configuration of both servers, not config snippets or LDAP modify > > change code. > > Actually (if I read the description correctly the sync setup is like "A -> > B", > and when A fails B is updated and expectation is that "B -> A" will work > automagically (which is not true IMHO). Then multi-master setup is needed. > > > > > Regards, > > Quanah > > > > > > > > ‑‑ > > > > Quanah Gibson‑Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <http://www.symas.com> > > > >

2 1

Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul 23 Jun '20

23 Jun '20

Hi Ulrich Both the servers are set up as master as well as consumer so that sync works in both directions. So the sync setup is like "A -> B", and when A fails B is updated and the expectation is that "B -> A" should work because a multi master setup is already in place. Let me know based on the attached configuration files if my assumption is correct or not. Also Add data works when A fails and B is updated then sync "B -> A"works fine. After Delete data sync does not work when A fails and data is deleted from B. Once A comes back both databases have data which was deleted on B. Thanks Rahul On Tue, Jun 23, 2020 at 8:11 AM Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 22.06.2020 um 18:09 > in > Nachricht > <13855_1592842197_5EF0D7D5_13855_226_1_A497B27F9A5328340A4CDBAC@ > [192.168.1.144]> > > > > > > ‑‑On Monday, June 22, 2020 3:08 PM +0000 Kumar Rahul > > <rahul2002mit(a)gmail.com> wrote: > > > >> Hi Quanah > >> > >> Thank you for all the help so far. I am still seeing the original > >> issue reported. Let me know if you need fresh set of configuration > >> information. > > > > I've told you repeatedly what is necessary, you haven't provided it. > > > > To re‑iterate: > > > > Full configuration of both servers, not config snippets or LDAP modify > > change code. > > Actually (if I read the description correctly the sync setup is like "A -> > B", > and when A fails B is updated and expectation is that "B -> A" will work > automagically (which is not true IMHO). Then multi-master setup is needed. > > > > > Regards, > > Quanah > > > > > > > > ‑‑ > > > > Quanah Gibson‑Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <http://www.symas.com> > > > >

1 0

syncrepl does not work as expected
by rahul2002mit＠gmail.com 22 Jun '20

22 Jun '20

Hi I am using LDAP protocol as front end and Berkeley DB as back end. I am observing a strange syncrepl issue type=refreshAndPersist is being used $OpenLDAP: slapd 2.4.44 OS: RHEL7U6 I have 2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. Added data D1 in database and that was synced with S2 database. Now I killed slapd process on server S1. At this point server S2 assumes provider role. Now I removed data D1 from database using server S2. Once deletion is complete validated that data was removed from server S2 database. Now i brought S1 slapd service back up and started the application which starts syncrepl. Here is what i see both server S1 and S2 has data D1 which was actually deleted. Expected behavior: Both server should sync properly and data D1 which was deleted using Server S2 should not be present in the database after sync. Request you guys to help. Thanks Rahul

5 45

Privileges for slapd service
by darkdragon 19 Jun '20

19 Jun '20

Dockerfile: ```Dockerfile FROM debian:buster ENV container docker # systemd RUN apt-get update && apt-get install -y \ systemd systemd-sysv && \ apt-get clean && \ rm -rf /var/lib/apt/lists/* RUN systemctl disable systemd-resolved.service RUN systemctl disable systemd-hostnamed.service STOPSIGNAL SIGRTMIN+3 CMD [ "/sbin/init" ] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \ slapd && \ apt-get clean && rm -rf /var/lib/apt/lists/* RUN systemctl enable slapd.service # Allow restart of slapd after dpkg-reconfigure (docker forbids this by default) RUN bash -c "install -m755 <(printf '#!/bin/sh\nexit 0') /usr/sbin/policy-rc.d" ``` Build command: ```sh docker build -t tmp . ``` Run command: ```sh docker run \ --name=tmp \ -it \ --tmpfs /run \ --tmpfs /run/lock \ --tmpfs /tmp \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ --rm \ tmp ``` Slapd restart (run within container): ```sh service slapd restart ``` Log (journalctl -u slapd): Jun 18 07:14:25 81bb7d58af2b systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)... Jun 18 07:14:25 81bb7d58af2b slapd[39]: @(#) $OpenLDAP: slapd (Apr 20 2020 18:19:54) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Jun 18 07:14:25 81bb7d58af2b slapd[40]: slapd starting Jun 18 07:14:25 81bb7d58af2b slapd[27]: Starting OpenLDAP: slapd. Jun 18 07:14:25 81bb7d58af2b systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). Jun 18 07:14:35 81bb7d58af2b systemd[1]: Stopping LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)... Jun 18 07:14:35 81bb7d58af2b slapd[72]: Stopping OpenLDAP: slapd. Jun 18 07:14:35 81bb7d58af2b systemd[1]: slapd.service: Succeeded. Jun 18 07:14:35 81bb7d58af2b systemd[1]: Stopped LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). Jun 18 07:14:40 81bb7d58af2b systemd[1]: slapd.service: Found left-over process 40 (slapd) in control group while starting unit. Ignoring. Jun 18 07:14:40 81bb7d58af2b systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Jun 18 07:14:40 81bb7d58af2b systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)... Jun 18 07:14:40 81bb7d58af2b slapd[99]: Starting OpenLDAP: slapd failed! Jun 18 07:14:40 81bb7d58af2b systemd[1]: slapd.service: Control process exited, code=exited, status=1/FAILURE Jun 18 07:14:40 81bb7d58af2b systemd[1]: slapd.service: Failed with result 'exit-code'. Jun 18 07:14:40 81bb7d58af2b systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). --- The problem seems to be an unclean stop (left-over process) which still occupies the port. Which capabilities [1] / seccomp [2] is needed by slapd? [1]: https://linux.die.net/man/7/capabilities [2]: https://docs-stage.docker.com/engine/security/seccomp/ --- My goal is to set the domain to "thisbox". Running the following code (within container): ```sh cat <<EOF >/tmp/slapd Name: slapd/domain Template: slapd/domain Value: thisbox Owners: slapd EOF DEBIAN_FRONTEND=noninteractive DEBCONF_DB_OVERRIDE=/tmp/slapd dpkg-reconfigure slapd ``` Log (journalctl -u slapd): -- Logs begin at Thu 2020-06-18 07:43:44 UTC, end at Thu 2020-06-18 07:44:57 UTC. -- Jun 18 07:43:44 fe1ddc01fdaf systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)... Jun 18 07:43:44 fe1ddc01fdaf slapd[38]: @(#) $OpenLDAP: slapd (Apr 20 2020 18:19:54) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Jun 18 07:43:44 fe1ddc01fdaf slapd[39]: slapd starting Jun 18 07:43:44 fe1ddc01fdaf slapd[28]: Starting OpenLDAP: slapd. Jun 18 07:43:44 fe1ddc01fdaf systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Stopping LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)... Jun 18 07:43:48 fe1ddc01fdaf slapd[160]: Stopping OpenLDAP: slapd. Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: slapd.service: Succeeded. Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Stopped LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)... Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: @(#) $OpenLDAP: slapd (Apr 20 2020 18:19:54) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: daemon: bind(8) failed errno=98 (Address already in use) Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: daemon: bind(8) failed errno=98 (Address already in use) Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: slapd stopped. Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: connections_destroy: nothing to destroy. Jun 18 07:43:48 fe1ddc01fdaf slapd[165]: Starting OpenLDAP: slapd failed! Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: slapd.service: Control process exited, code=exited, status=1/FAILURE Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: slapd.service: Failed with result 'exit-code'. Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol). So the problem indicates that the address is already in use. --- Setting the configuration within Dockerfile (no need to restart in container): ```Dockerfile RUN echo "" >> /tmp/slapd && \ echo "Name: slapd/domain" >> /tmp/slapd && \ echo "Template: slapd/domain" >> /tmp/slapd && \ echo "Value: thisbox" >> /tmp/slapd && \ echo "Owners: slapd" >> /tmp/slapd && \ echo "" >> /tmp/slapd && \ DEBIAN_FRONTEND=noninteractive \ DEBCONF_DB_OVERRIDE=/tmp/slapd \ dpkg-reconfigure slapd ``` doesn't throw any error, but doesn't seem to work either. ```sh ldapadd -Q -Y EXTERNAL -H ldapi:/// ``` logs to stdout: ``` adding new entry "ou=users,dc=thisbox" ldap_add: Server is unwilling to perform (53) additional info: no global superior knowledge ``` So for some reason the setup on container creation doesn't seem to be used. --- I am new to LDAP, so I am apologizing if I am using something completely wrongly. Just trying to fix https://salsa.debian.org/freedombox-team/freedombox/-/issues/1880. Any help appreciated!

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical