openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 01 Sep '17

01 Sep '17

--On Friday, September 01, 2017 11:48 AM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > Vinyl records are back in style. So it seems slapd.conf and bdb. Yeah, I got to spend 2+ hours with a customer today because they chose to use back-bdb, and it lacks subtree rename... so something that should have been trivial to resolve was a long drawn out process. There are good reasons things have progressed beyond slapd.conf and back-bdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP not starting using "systemctl start" but runs fine invoking slapd directly
by Michael.Haertel＠t-systems.com 01 Sep '17

01 Sep '17

Dear List, I hope that somebody can help me here. My OpenLDAP starts fine using “slapd -d -1 -F /etc/openldap/slapd.d”. Everything is OK if I start the service using that command. But if I try to use the service “/bin/systemctl start slapd.service” it fails to start. “/bin/systemctl start slapd.service Job for slapd.service failed because the control process exited with error code. See "systemctl status slapd.service" and "journalctl -xe" for details.” The output of “systemctl status slapd.service”: ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2017-09-01 10:37:55 CEST; 7s ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 45146 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=1/FAILURE) Process: 45132 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: Starting OpenLDAP Server Daemon... Sep 01 10:37:55 tmv2312.devlab.de.tmo runuser[45135]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Sep 01 10:37:55 tmv2312.devlab.de.tmo runuser[45135]: pam_unix(runuser:session): session closed for user ldap Sep 01 10:37:55 tmv2312.devlab.de.tmo slapd[45146]: @(#) $OpenLDAP: slapd 2.4.40 (Nov 3 2016 18:02:29) $ mockbuild@x86-ol7-builder-01:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/servers/slapd Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: slapd.service: control process exited, code=exited status=1 Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: Failed to start OpenLDAP Server Daemon. Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: Unit slapd.service entered failed state. Sep 01 10:37:55 tmv2312.devlab.de.tmo systemd[1]: slapd.service failed. Output of “journalctl -xe” Sep 01 11:24:06 tmv2312.devlab.de.tmo polkitd[772]: Registered Authentication Agent for unix-process:51631:336035477 (system bus name :1.16850 [/usr/bin/pkttyagent --notify-fd 5 --fall Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: Starting OpenLDAP Server Daemon... -- Subject: Unit slapd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit slapd.service has begun starting up. Sep 01 11:24:06 tmv2312.devlab.de.tmo runuser[51640]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Sep 01 11:24:06 tmv2312.devlab.de.tmo runuser[51640]: pam_unix(runuser:session): session closed for user ldap Sep 01 11:24:06 tmv2312.devlab.de.tmo slapd[51651]: @(#) $OpenLDAP: slapd 2.4.40 (Nov 3 2016 18:02:29) $ mockbuild@x86-ol7-builder-01:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/servers/slapd Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: slapd.service: control process exited, code=exited status=1 Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: Failed to start OpenLDAP Server Daemon. -- Subject: Unit slapd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit slapd.service has failed. -- -- The result is failed. Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: Unit slapd.service entered failed state. Sep 01 11:24:06 tmv2312.devlab.de.tmo systemd[1]: slapd.service failed. Sep 01 11:24:06 tmv2312.devlab.de.tmo polkitd[772]: Unregistered Authentication Agent for unix-process:51631:336035477 (system bus name :1.16850, object path /org/freedesktop/PolicyKit I don’t see any message that would help me to understand the reason for the failure. The content of slapd.service: “[Unit] Description=OpenLDAP Server Daemon After=syslog.target network-online.target Documentation=man:slapd Documentation=man:slapd-config Documentation=man:slapd-hdb Documentation=man:slapd-mdb Documentation=file:///usr/share/doc/openldap-servers/guide.html [Service] Type=forking PIDFile=/var/run/openldap/slapd.pid Environment="SLAPD_URLS=ldap:/// ldapi:///" "SLAPD_OPTIONS=" EnvironmentFile=/etc/sysconfig/slapd ExecStartPre=/usr/libexec/openldap/check-config.sh ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS [Install] WantedBy=multi-user.target” Where does the script take “${SLAPD_URLS}” and “$SLAPD_OPTIONS” from? Thank you very much, Michael

6 6

syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Sven Mäder 01 Sep '17

01 Sep '17

Hi We have a 3-way delta-mmr syncrepl setup (Debian Stretch with slapd 2.4.44+dfsg-5+deb9u1). 2 of those 3 hosts were powered off for about 4 hours. After the bootup and slapd start, the host which was running all the time during the downtime started to log: SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Purging the accesslog database fixed the issue. Could this have happened due to a timesync problem? We noticed, that right after boot, the ntpd service was oscillating in its time offset from 0.0192 to 0.0003 for ~3 minutes. Does somebody have experience with this? Do we need to delay slapd or force an `ntpdate` before slapd starts in the boot process? Because slapd has the following LSB headers in the init script # Required-Start: $remote_fs $network $syslog it is started (using systemd service file autogenerated from init.d script) right after network.target has been reached and simultaneously with ntpd. Whereas slapd only takes about 1 second to start, ntpd takes about 10 seconds and it might even take much longer to get the time in sync. Kind regards -- Sven Mäder IT Services Group Physics Department, ETH Zurich

2 2

Re: Antw: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 01 Sep '17

01 Sep '17

Vinyl records are back in style. So it seems slapd.conf and bdb. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Fri, Sep 1, 2017 at 10:46 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, August 31, 2017 9:51 AM +0200 Ulrich Windl > <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > > > Also note "olcDbConfig: <DB_CONFIG setting>" is probably the modern way > > to do it. > > The "modern" way of doing things is to not use back-{bdb|hdb} at all. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > iUdH-3oK-ghXbFvuOvVSpxIO_O7WDzVdOnpAuUxHEew&s=rb0zQFdfUxkSKj1ZW5SZegqif0- > UP53lXt084_p_UOE&e=> > >

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 01 Sep '17

01 Sep '17

--On Thursday, August 31, 2017 9:51 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Also note "olcDbConfig: <DB_CONFIG setting>" is probably the modern way > to do it. The "modern" way of doing things is to not use back-{bdb|hdb} at all. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: pwdfailuretime with multi-sync
by Quanah Gibson-Mount 01 Sep '17

01 Sep '17

--On Wednesday, August 30, 2017 9:21 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, August 30, 2017 2:49 PM +0800 Chris Leung > <chris(a)q-station.net> wrote: > >> Sometime, the user password is replicated without problem after switched >> to REFRESH, however, sometime password can't be sync. > > Error 16 means "no such attribute exists". My guess would be you have > ACLs that block your replica from replicating userPassword. I'd also > guess that you originally loaded the replica via a slapcat of the other > master, so some accounts have passwords, and others don't. This is all > guesswork of course, but it would match the behavior you're seeing. Also, I would confirm that you have identical overlay configurations between the two masters. It sounds like on has ppolicy and perhaps the other one doesn't? Also be sure and read the ppolicy manpage closely on replication behavior. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

N-Way replication configuration
by rammohan ganapavarapu 01 Sep '17

01 Sep '17

Hi, I have a basic question in N-Way Multi master replication configuration, For example i have 3 servers and i wanted to setup N-Way replication across those servers, in the "olcSyncRepl" configuration do i have to include the Nth server it self? On each server: olcSyncRepl: rid=001 provider=$URI1 olcSyncRepl: rid=002 provider=$URI2 olcSyncRepl: rid=003 provider=$URI3 VS Server1: olcSyncRepl: rid=002 provider=$URI2 olcSyncRepl: rid=003 provider=$URI3 Server2: olcSyncRepl: rid=001 provider=$URI1 olcSyncRepl: rid=003 provider=$URI3 Server3: olcSyncRepl: rid=001 provider=$URI1 olcSyncRepl: rid=002 provider=$URI2 Which one is the right way to do? Also what is the significance of "olcServerID" do we have keep every server "olcServerID" in each server? Thanks, Ram

1 0

Re: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 31 Aug '17

31 Aug '17

Thanks, a lot everyone! Performance looks good now. No deadlocks and nothing being purged from the cache. I have started pointing more sssd clients at the cluster. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Thu, Aug 31, 2017 at 2:51 AM, Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> Douglas Duckworth <dod2014(a)med.cornell.edu> schrieb am 30.08.2017 um > 16:06 in > Nachricht > <CAAKHBKm0FKBR4BLNpy6jrszFp35Eid_J2F19MKmfS+G47EKCJA(a)mail.gmail.com>: > [...] > > Only four clients are currently using this cluster so perhaps I should > > actually use DB_CONFIG before putting it into production. > > Maybe you could start considering this from a moderately loaded and sized > server: > set_cachesize 0 15000000 1 > set_lg_regionmax 262144 > set_lg_bsize 2097152 > set_flags DB_LOG_AUTOREMOVE > set_lk_max_locks 30000 > set_lk_max_objects 30000 > --- > > Also note "olcDbConfig: <DB_CONFIG setting>" is probably the modern way to > do it. > > Regards, > Ulrich > > >

1 0

Re: 2.4.45 slapadd segfault
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Thursday, August 31, 2017 4:49 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > Christopher Wood wrote: >> Good morning, long time no list. >> >> For backstory, I downloaded the 2.4.45 source tarball from >> https://www.openldap.org/software/download/, compiled, ran "make test" >> (which was fine as near as I can tell), but doing a slapadd of cn=config >> caused a segfault. >> >> I used the points on http://www.openldap.org/faq/data/cache/59.html to >> create the following backtrace: >> >> https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e >> >> And this is the ldif (temporary password is fakepass333): >> >> https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e >> >> Does anything jump out at you as obviously wrong or a good place to >> look? I've chopped the ldif down from the original with confidential >> data and am still reducing, but it's still segfaulting. > > Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if > it's still not obvious to you. > > Granted it shouldn't SEGV but the backtrace shows it was shutting itself > down already because it (correctly) rejected your input. There are a number of errors with that LDIF file, outside of what Howard already pointed out. ;) The objects in 54 & 62 are also missing their RDN as a value too. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: 2.4.45 slapadd segfault
by Howard Chu 31 Aug '17

31 Aug '17

Christopher Wood wrote: > Good morning, long time no list. > > For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. > > I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: > > https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e > > And this is the ldif (temporary password is fakepass333): > > https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e > > Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if it's still not obvious to you. Granted it shouldn't SEGV but the backtrace shows it was shutting itself down already because it (correctly) rejected your input. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical