Re: Syncrepl and multipe values
by Quanah Gibson-Mount
--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio
Morais <matheus_morais(a)sicredi.com.br> wrote:
>
>
>
> Issue 8559 opened.
>
>
>
> I'm trying to work on a patch but I'm not sure if the best solution is to
> fix accesslog to avoid duplicated values or if the sample LDIF (in its
> description) should result in a constraint violation. What do you think?
The accesslog should never write an operation that can't be replicated. If
the MOD is a valid LDAP operation (which I think it is), then it should be
accepted at the frontend. The issue may be more in delta-syncrepl's
handling of the write op than anything else.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 3 months
syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Sven Mäder
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
5 years, 9 months
Re: pwdfailuretime with multi-sync
by Quanah Gibson-Mount
--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>
5 years, 9 months
Re: Re: Removing Berkeley DB Log Files
by Douglas Duckworth
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
>
>
>
5 years, 9 months
Re: 2.4.45 slapadd segfault
by Quanah Gibson-Mount
--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>
5 years, 9 months
2.4.45 slapadd segfault
by Christopher Wood
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.
More details:
OpenLDAP 2.4.45 Release (2017/06/01)
[root@poc209 ~]# uname -a
Linux poc209 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@poc209 ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
/ and /var are ext4.
Configure was like this, albeit on one line:
./configure
--enable-debug
--enable-dynamic
--enable-syslog
--enable-proctitle
--enable-ipv6
--enable-local
--enable-slapd
--enable-dynacl
--enable-aci
--enable-cleartext
--enable-crypt
--enable-lmpasswd
--enable-spasswd
--enable-modules
--enable-rewrite
--enable-rlookups
--enable-slapi
--disable-slp
--enable-wrappers
--enable-backends=mod
--enable-bdb=yes
--enable-hdb=yes
--enable-mdb=yes
--enable-monitor=yes
--disable-ndb
--enable-overlays=mod
--disable-static
--enable-shared
--with-cyrus-sasl
--without-fetch
--with-threads
--with-pic
--with-tls=openssl
--with-gnu-ld
--prefix=/opt/openldap
5 years, 9 months
Re: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Quanah Gibson-Mount
--On Wednesday, August 30, 2017 3:51 PM +0200 Sven Mäder
<maeder(a)phys.ethz.ch> wrote:
> SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is
> newer than provider!
This would generally indicate that the accesslog DB was empty at startup,
and it generated a new CSN. This is a general problem with delta-syncrepl
-- If the accesslog DB goes empty, there are a host of issues that can
ensue (See ITS#8100 for example).
Generally you need a script that writes a change on all masters in your
cluster on a regular interval so that the DB is never purged, and there is
always an active contextCSN value that's stored in the DB for each serverID.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 9 months
Re: Removing Berkeley DB Log Files
by Douglas Duckworth
Thanks for the reply, Howard.
Thanks for pointing me in the right direction. From what I have read there
are two options.
1) Copy /usr/share/openldap-servers/DB_CONFIG.example to /var/lib/domain
then rebuild the database.
2) Enable checkpointing in slapd.conf
Does enabling checkpointing in slapd.conf require rebuilding the database
or can I simply restart slapd.conf? We are not using online configuration.
Best
Doug
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, Aug 25, 2017 at 8:55 AM, Howard Chu <hyc(a)symas.com> wrote:
> Douglas Duckworth wrote:
> > Hi
> >
> > I am running openldap-servers-2.4.40-16.el6.x86_64 cluster on Centos
> 6.9. My
> > /var/lib/ldap directory contains many 10MB log files. /var partition
> rather
> > small...
> >
> > I've read they can be removed either by running "sudo db_archive -d -h
> > /var/lib/ldap/domain" or by defining "DB_LOG_AUTOREMOVE" within the file
> > "DB_CONFIG." That file does not presently exist whereas the db_archive
> > command does not actually remove any of the log files.
>
> If the db_archive command doesn't remove anything, that means it thinks
> all of
> the log files are still in active use.
>
> Read the docs more carefully.
> https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.
> oracle.com_cd_E17076-5F05_html_programmer-5Freference_
> transapp-5Flogfile.html&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=
> Kfi27b4v7vABZjPQYMkeo4xBqUyDGZeyB8pHAFin8xY&e=
>
> >
> > Can I remove the old log files manually using rm?
>
> Not if the above is true, you will corrupt the logs and the DB will fail to
> open on a subsequent restart.
>
> > If not should I create
> > /var/lib/ldap/DB_CONFIG then restart slapd to make this removal
> automatic?
>
> > Do you have any idea why db_archive does not work or produce any helpful
> error
> > to stdout?
>
> There's no error message because there's no error, everything is working as
> designed.
>
> You need to do periodic checkpoints to allow log files to be closed, and
> then
> db_archive will be able to remove some of them.
>
> --
> -- Howard Chu
> CTO, Symas Corp. https://urldefense.proofpoint.
> com/v2/url?u=http-3A__www.symas.com&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9-
> RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=IT7tNF72SCugdO8WpRd-
> oNsk4nPNpdjE2aUFL4R4X_M&e=
> Director, Highland Sun https://urldefense.proofpoint.
> com/v2/url?u=http-3A__highlandsun.com_hyc_&d=DwICaQ&
> c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=
> XqfYCnjG9ibPbeW05QZOlWdl9u0ZH-7IXkxx0gh238k&e=
> Chief Architect, OpenLDAP https://urldefense.proofpoint.
> com/v2/url?u=http-3A__www.openldap.org_project_&d=DwICaQ&c=
> lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=-
> tGdeTJRpeaRbljBBUq49XgfNWzVElqiGEgv0LeqspU&e=
>
5 years, 9 months
