openldap-technical September 2017

openldap-technical@openldap.org

54 participants
164 discussions

Strange behaviors on OpenLDAP proxy
by David Coutadeur 04 Sep '17

04 Sep '17

Hi community, I have implemented two "OpenLDAP mirror directories": ldaps://ldap1 and ldaps://ldap2 (version 2.4.44) and a LDAP proxy with back_ldap + overlay pcache (version 2.4.44). I am trying to understand behaviors on the LDAP proxy: 1 - I don't succeed to configure a failover switch between OpenLDAP backends. The proxy switches too quickly due to a network disconnection (for example, network stays unavailable during n second). I would be interested whether there is a way to better control the switch even after network failure, for example, adding LDAP new parameters in order to send 3 attempts before performing failover. 2 - After that, when the network is up again and the first directory "ldap1" is back, new requests with already established connection to ldap1 are directed again to directory "ldap1" Is it possible to make all the trafic stay on ldap2? Is there a way to close open connections to ldap1 directory when the proxy switches to the ldap2 directory? 3. Finally, Is there a way to switch to the second directory when queries are too slow in the first directory? Thanks in advance. David

1 0

N-Way Multi Master setup missing entries on consumers
by ping-shin ching 03 Sep '17

03 Sep '17

Hi Folks, I have 4 servers setup via N-Way multi master using 2.4.44. Updates go to a single provider. We have close to 20 consumers connected to each of the providers via delta syncrepl. Fairly busy system with about 10000 additions, 64000 modifications and 5000 delete on a busy day. Current database is about 15 million entries. We see that some changes are not sent down to the consumers. We miss about 100 entries a day. These entries appear in all 4 providers, but are randomly missing in the consumers. I am still investigating, but any insight/help will be greatly appreciated. The providers are on RHEL 6, the consumers are on solaris 10. configure options... --without-cyrus-sasl \ --disable-bdb \ --disable-hdb \ --enable-ldap \ --enable-mdb \ --enable-constraint Regards, Ping ========================= one of the provider config files ======================== # # FileName: slapd.conf # # Author: $Author: d639599 $ # Date: $Date: 2014-08-22 14:00:37 +1000 (Fri, 22 Aug 2014) $ # Revision: $Revision: 18625 $ # CVS Tag: $Name$ # CVS ID: $Id: slapd_master.conf.in 18625 2014-08-22 04:00:37Z d639599 $ # # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /data/openldap24/etc/openldap/schema/core.schema include /data/openldap24/etc/openldap/schema/cosine.schema include /data/openldap24/etc/openldap/schema/nis.schema include /data/openldap24/etc/openldap/schema/radius.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /data/openldap24/var/run/slapd.pid argsfile /data/openldap24/var/run/slapd.args #replica-pidfile /data/openldap/var/run/slurpd.pid loglevel 32768 threads 32 tool-threads 8 allow bind_v2 # The number of results to return in a search sizelimit unlimited serverID 02 access to dn=uid=newevdouser(a)xman.com,ou=users,ou=evdo,ou=data,o=company,c=org by dn=cn=infranet,ou=applicationusers,o=company,c=org read by dn=cn=activeorder,ou=applicationusers,o=company,c=org read by dn=cn=asap,ou=applicationusers,o=company,c=org read .......... .......... ####################################################################### # monitor database ####################################################################### database monitor rootdn "cn=monitoring,cn=Monitor" rootpw XXXXXXXXXXXXXXXXXX access to dn.subtree="cn=Monitor" by dn.exact="cn=Manager,o=company,c=org" read by * none ####################################################################### # primary database ####################################################################### database mdb suffix "o=company,c=org" rootdn "cn=Manager,o=company,c=org" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw XXXXXXXXXXXXXXXXXX #size of sparse file 64Gb maxsize 68719476736 #only required to receive data from slurpd #updatedn cn=directorymaster,ou=applicationusers,ou=radiusdata,o=company,c=org # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /data/openldap24/var/openldap-data #Allow dirmaster unlimited time for searches limits dn.exact="cn=directorymaster,ou=applicationusers,ou=radiusdata,o=company,c=org" time=unlimited # Indices to maintain index objectClass eq index uid eq index cn eq index macAddress eq index pinpoid eq index bpiPoid eq index target eq index interceptType eq index interceptValue eq index imei eq index ipHostNumber eq index homeLocation eq index sid eq index remoteId eq index parentDn eq # required for sessionlaog index entryCSN eq index entryUUID eq checkpoint 128 1 dbnosync # syncrepl directives for each of the other masters for primary db replication ####################################################################### ## Syncrepl entry for 01 syncrepl rid=01 provider=ldap://host1 type=refreshAndPersist retry="10 +" searchbase="o=company,c=org" bindmethod=simple type=refreshAndPersist binddn="cn=dirmaster,ou=appusers,a,o=company,c=org" credentials=YYYYY retry="60 10 300 +" schemachecking=on # Syncrepl entry for 02 syncrepl rid=02 provider=ldap://host3 type=refreshAndPersist retry="10 +" searchbase="o=company,c=org" bindmethod=simple type=refreshAndPersist binddn="cn=dirmaster,ou=appusers,a,o=company,c=org" credentials=YYYYY retry="60 10 300 +" schemachecking=on # Syncrepl entry for 03 syncrepl rid=03 provider=ldap://host4 type=refreshAndPersist retry="10 +" searchbase="o=company,c=org" bindmethod=simple type=refreshAndPersist binddn="cn=dirmaster,ou=appusers,a,o=company,c=org" credentials=YYYYY retry="60 10 300 +" schemachecking=on #need mirror mode to accept writes mirrormode on overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logbase writes o=company,c=org # scan the accesslog DB every day, and purge entries older than 14 days logpurge 14+00:00 01+00:00 #sycrepl provider config # define the provider to use the syncprov overlay # (last directives in database section) overlay syncprov syncprov-checkpoint 10000 10 # contextCSN saved to database every 10000 updates or ten minutes syncprov-sessionlog 10000 syncprov-nopresent TRUE ####################################################################### # accesslog database ####################################################################### database mdb suffix "cn=accesslog" rootdn "cn=Manager,o=company,c=org" #size of sparse file 16Gb maxsize 17179869184 directory /data/openldap24/var/openldap-data-accesslog #Allow dirmaster unlimited time for searches limits dn.exact="cn=dirmaster,ou=appusers,a,o=company,c=orgg" time=unlimited index entryCSN eq index objectClass eq index reqEnd eq index reqResult eq index reqStart eq #sycrepl provider config # define the provider to use the syncprov overlay # (last directives in database section) overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ====================================== consumer config ====================================== # # FileName: slapd.conf # # Author: $Author: d639599 $ # Date: $Date: 2014-08-22 14:00:37 +1000 (Fri, 22 Aug 2014) $ # Revision: $Revision: 18625 $ # CVS Tag: $Name$ # CVS ID: $Id: slapd_master.conf.in 18625 2014-08-22 04:00:37Z d639599 $ # # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /data/openldap24/etc/openldap/schema/core.schema include /data/openldap24/etc/openldap/schema/cosine.schema include /data/openldap24/etc/openldap/schema/nis.schema include /data/openldap24/etc/openldap/schema/radius.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /data/openldap24/var/run/slapd.pid argsfile /data/openldap24/var/run/slapd.args #replica-pidfile /data/openldap/var/run/slurpd.pid loglevel 32768 # #threads 64 # allow bind_v2 # # The number of results to return in a search sizelimit unlimited tool-threads 2 threads 8 # Load dynamic backend modules: # modulepath /data/openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! access to * by cn=dirmaster,ou=appusers,a,o=company,c=org write by dn=cn=radiusserver,ou=applicationusers,o=company,c=org read .......... .......... ####################################################################### # config database ####################################################################### database config # NOTE: the suffix is hardcoded as cn=config and # MUST not have a suffix directive # normal rules apply - rootdn can be anything you want # but MUST be under cn=config rootdn "cn=admin,cn=config" # use any of the supported password formats e.g. {SSHA} etc # or plaintext as shown rootpw XXXXXXXXXXXXXXXXXX ####################################################################### # monitor database ####################################################################### database monitor rootdn "cn=monitoring,cn=Monitor" rootpw {SHA}wauZJOzaG+r4u6oeuCOLg+DtjGM= access to dn.subtree="cn=Monitor" by dn.exact="cn=Manager,o=company,c=org" read by * none ####################################################################### # mdb database definitions ####################################################################### database mdb suffix "o=company,c=org" rootdn "cn=Manager,o=company,c=org" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw XXXXXXXXXXXXXXXX maxsize 68719476736 # To speedup further - possibly at the expense of data integrity # Only use for slappadd without slapd running #envflags nometasync #envflags writemap # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /data/openldap24/var/openldap-data # Indices to maintain index objectClass eq index uid eq index cn eq index macAddress eq index pinpoid eq index bpiPoid eq index target eq index interceptType eq index interceptValue eq index imei eq index ipHostNumber eq index homeLocation eq index sid eq index remoteId eq index parentDn eq index entryUUID eq index entryCSN eq checkpoint 128 1 dbnosync # syncrepl directives for primary db replication ####################################################################### ## Syncrepl entry for 01 syncrepl rid=01 provider=ldap://provider1 bindmethod=simple binddn="cn=dirmaster,ou=appusers,a,o=company,c=org" credentials=XXXXXXX searchbase="o=company,c=org" logbase="cn=accesslog" type=refreshAndPersist scope=sub retry="10 +" schemachecking=off logfilter="(&(objectClass=auditWriteObject)(reqResult=0)(|(reqDN:dnSubtreeMatch:=ou=radiusdata,o=company,c=org)(reqDN:dnSubtreeMatch:=ou=applicationusers,o=company,c=org)))" syncdata=accesslog filter="(|(entrydn:dnSubtreeMatch:=ou=radiusdata,o=company,c=org)(entrydn:dnSubtreeMatch:=ou=applicationusers,o=company,c=org))"

1 0

Re: Large scale traffic testing
by Quanah Gibson-Mount 03 Sep '17

03 Sep '17

--On Sunday, September 03, 2017 8:48 PM +0100 Tim <tim(a)yetanother.net> wrote: > I'm currently working with a dataset of in the region of 2,500,000 > objects and looking to test throughput up to somewhere in the region of > 15k/s searches alongside 1k/s modification/addition events - which is > beyond what the current basic scripts are able to achieve. Those are all miniscule numbers to achieve with such a tiny dataset, assuming you're using LMDB and have reasonable hardware. > So I was wondering what strategies other people have used to stress test > platforms elsewhere? The best stress testing software for OpenLDAP is something that is distributed, such as slamd or jmeter. Anything else will hit artificial limits. You may be interested in seeing already generalized published benchmarks, such as: <http://lanyrd.com/2013/ldapcon/sckyhr/> I also did some (read rate) benchmarks of OpenLDAP quite some years ago, on fairly weak commodity hardware: <https://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb…> Here are also single-threaded write rate tests I did for Zimbra: <https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance> Generally, you'll hit system limitations (disk write speed, network bandwidth) before you max out what OpenLDAP can actually do. Hope that helps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: N-Way replication configuration
by rammohan ganapavarapu 02 Sep '17

02 Sep '17

Thank you for clarification, now I am more clear. One more question, what is the best or recommended way of doing n-way rep, should we replicate both config db and user db as well ? Right now I am not replicating config. On Sep 1, 2017 7:34 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Friday, September 01, 2017 6:03 PM -0700 rammohan ganapavarapu < rammohanganap(a)gmail.com> wrote: > Quanah, > > > Thank you, so do we need to include olcServerID of all servers in every > server? for example if i have 3 servers MMR, then do i need to add > > > olcServerID 1 $URl1 > > olcServerID 2 $URl2 > > olcServerID 3 $URl2 > Sorry, let me clarify a bit on my earlier answer. For olcServerID, it only needs the URI *if* you are replicating cn=config. For the olcSyncrepl: lines, you never have to point at the master. It only needs olcSyncrepl lines for the other masters in the cluster. Pointing it at itself in olcSyncrepl just generates unnecessary overhead. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: N-Way replication configuration
by Quanah Gibson-Mount 01 Sep '17

01 Sep '17

--On Friday, September 01, 2017 6:03 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, so do we need to include olcServerID of all servers in every > server? for example if i have 3 servers MMR, then do i need to add > > > olcServerID 1 $URl1 > > olcServerID 2 $URl2 > > olcServerID 3 $URl2 Sorry, let me clarify a bit on my earlier answer. For olcServerID, it only needs the URI *if* you are replicating cn=config. For the olcSyncrepl: lines, you never have to point at the master. It only needs olcSyncrepl lines for the other masters in the cluster. Pointing it at itself in olcSyncrepl just generates unnecessary overhead. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

01 Sep '17

Quanah, Thank you, so do we need to include olcServerID of all servers in every server? for example if i have 3 servers MMR, then do i need to add olcServerID 1 $URl1 olcServerID 2 $URl2 olcServerID 3 $URl2 In all servers or just keep self ID? Ram On Fri, Sep 1, 2017 at 1:21 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, August 31, 2017 6:46 PM -0700 rammohan ganapavarapu < > rammohanganap(a)gmail.com> wrote: > > Which one is the right way to do? >> > > It depends. If you are replicating cn=config, then the provider=.... is > required, and it must include all providers. If you are not replicating > cn=config, then the provider= is not required at all, and can be left out. > > Also what is the significance of "olcServerID" do we have keep every >> server "olcServerID" in each server? >> > > olcServerID is required on all masters, and must be unique between every > master. This is how OpenLDAP knows which master a particular change > occurred on, and is mandatory for MMR to function correctly. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: N-Way replication configuration
by Quanah Gibson-Mount 01 Sep '17

01 Sep '17

--On Thursday, August 31, 2017 6:46 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > Which one is the right way to do? It depends. If you are replicating cn=config, then the provider=.... is required, and it must include all providers. If you are not replicating cn=config, then the provider= is not required at all, and can be left out. > Also what is the significance of "olcServerID" do we have keep every > server "olcServerID" in each server? olcServerID is required on all masters, and must be unique between every master. This is how OpenLDAP knows which master a particular change occurred on, and is mandatory for MMR to function correctly. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2017