synrepl error 69
by Sami
Hello Openldap community,
I have an openldap syncrepl consumer that started producing this error:
Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: syncrepl_entry:
rid=xxx be_add uid=xxxxx,ou=myou,dc=domain,dc=xx failed (69)
Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: do_syncrepl:
rid=xxx rc 69 retrying
I have a simple provider/consumer replication configured:
olcSyncrepl: {0}rid=xxx provider=ldap://<provider>:389 bindmethod=simple b
inddn="uid=<replicator>,ou=myou,dc=domain,dc=xx" credentials=secret se
archbase="dc=domain,dc=xx" scope=sub schemachecking=on
type=refreshAndPersis
t retry="5 10 300 +"
I couldn't find the error code on search engines. I'd like to know the
possible causes/solutions to this.
Thank you !
6 years, 8 months
Re: unique values
by Howard Chu
Quanah Gibson-Mount wrote:
> --On Monday, March 06, 2017 4:37 PM +0100 "A. Schulze" <sca(a)andreasschulze.de>
> wrote:
>
>>
>> Hello,
>>
>> while planning a data scheme update we found it handy to have a unique
>> value for each entry.
>> short time later we found "entryUUID" :-)
>> But we are still unsure.Should we simply use entryUUID or should we
>> extend our schema
>> to hold a new attribute similar to entryUUID.
>>
>
> entryUUID is defined in RFC4530, as an internal LDAP attribute. Personally, if
> you need a UUID for tracking, I would create your own specific to your
> application/needs. For example, when I was at Stanford, we used suRegID
> (stanford university registry ID) and when I was at zimbra, we used zimbraID
> (zimbra identifier). There have been format changes in the past that required
> wiping out some of the generated attributes when going between releases.
This is bad advice. If you actually want a UUID then use entryUUID. As noted,
it is defined in RFC4530 which means it isn't going to change. The format of
UUIDs is well-established in internet standards.
When an existing attribute has *exactly* the syntax and semantics that you
want, use it.
suRegID and zimbraID are not UUIDs are they?
> Using your own identifier ensures that will not be an issue. Also, if you do
> things like allow backing up/restoring user entries that have gotten deleted,
> a restored entry (depending on the method use) may end up with a new entryUUID.
Yes, you should only use the recommended backup procedures.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 8 months
dds overlay on mirrored master
by Dirk Kastens
Hi,
I'm running a mirrored master server and several read-only replicas. Now
I want to deal with dynamic objects, so I enabled the dds overlay.
Because the config is mirrored, the dds-state is TRUE on both master
servers. In my syncrepl statement I set schemachecking=off and
exattrs=entryTtl,entryExpireTimestamp. The replication of dynamic
objects is working.
My question is: will there be a conflict when both master servers are
trying to delete expired objects at the same time? What's the best way
to configure the dds overlay on a mirrored master?
Thanks in advance.
Dirk
6 years, 8 months
Re: Syncrepl losing connection
by Quanah Gibson-Mount
--On Thursday, March 02, 2017 1:08 PM +0200 Nick Milas
<nick(a)eurobjects.com> wrote:
> Since "only some systems support the customization of these values; the
> keepalive parameter is ignored otherwise", how can I make sure that this
> parameter has been configured successfully and is enabled on my system
> (CentOS 7)? I enabled "loglevel config stats sync"but I don't see any
> mention of configured syncrepl parameters during OpenLDAP start.
Hi Nick,
The keepalive parameter was added after the initial 2.4 release, and after
the current sections on replication in the admin guide were written. It
was created because I kept encountering issues at customer sites where load
balancers & packet shapers were closing the syncrepl connection.
I use the following: keepalive=240:10:30
The 240 because most of the hardware causing problems used a 5 minute
timeout, so 240 was nicely under that.
If setting this resolves your problem, then you have something in your
network monitoring and severing connections.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 8 months
Re: unique values
by Quanah Gibson-Mount
--On Monday, March 06, 2017 4:37 PM +0100 "A. Schulze"
<sca(a)andreasschulze.de> wrote:
>
> Hello,
>
> while planning a data scheme update we found it handy to have a unique
> value for each entry.
> short time later we found "entryUUID" :-)
> But we are still unsure.Should we simply use entryUUID or should we
> extend our schema
> to hold a new attribute similar to entryUUID.
>
entryUUID is defined in RFC4530, as an internal LDAP attribute.
Personally, if you need a UUID for tracking, I would create your own
specific to your application/needs. For example, when I was at Stanford,
we used suRegID (stanford university registry ID) and when I was at
zimbra, we used zimbraID (zimbra identifier). There have been format
changes in the past that required wiping out some of the generated
attributes when going between releases. Using your own identifier ensures
that will not be an issue. Also, if you do things like allow backing
up/restoring user entries that have gotten deleted, a restored entry
(depending on the method use) may end up with a new entryUUID.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount
--On Saturday, March 04, 2017 6:39 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
> It seems like this has something to do with duplicated operations? The
> first time this operation was applied, the eduPersonAffiliation
> attribute did exist, with a single value that was removed. Then for some
> reason it's like it tried to remove it again and went boom? But there
> was no operation that *actually* failed. Everything that the client
> tried to do was done.
>
> BTW, I opened the ITS for tracking, it's #8609. Thanks...
Great, thanks! Trying to get to a point where I can focus working on this.
Can you follow up to the ITS with the notes about the method being used by
your perl script to do the deletes as well as the link to the schema? Just
so it's all in one spot :)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
unique values
by A. Schulze
Hello,
while planning a data scheme update we found it handy to have a unique
value for each entry.
short time later we found "entryUUID" :-)
But we are still unsure.Should we simply use entryUUID or should we
extend our schema
to hold a new attribute similar to entryUUID.
so what are the pros and cons on using entryUUID for a second purpose?
+ entryUUID is implicit available for each and every entry
+ automatically generated
+ saved as part of our backup using slapcat
- what happen on a complete disaster restore?
will the entryUUID values remain if we build a new server from a
slapcat backup?
- a separate but similar attribute has to be defined
is there a suggested schema? "grep -ri uuid
/path/to/openldap-source/servers/slapd/schema/"
did not disclose the definition of entryUUID. It's somehow
defined in servers/slapd/schema_prep.c
- a separate but similar attribute has to be written while creating
a new entry
could that be automated somehow?
- what is 'NO-USER-MODIFICATION' in a schema definition and what
are the implications
if I define an attribute as NO-USER-MODIFICATION?
Do you have any thoughts or suggestions on this?
A quick search in the list-archive didn't helped me to answer my questions.
Thanks,
Andreas
6 years, 9 months
Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount
--On Wednesday, February 15, 2017 6:36 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
> On Wed, Feb 15, 2017 at 12:22:29PM -0800, Quanah Gibson-Mount wrote:
>
>> I would suggest filing an ITS with the full backtrace info, so I can
>> track it.
>
> Ok, will do.
>
>> It could be useful to have the entry data from the accesslog as
>> well for the failed replication op, as we can see the failed entry DN in
>> the output of your backtrace.
>
> That would be in the accesslog on the server that crashed? Hmm, the
> server that crashed is the master, and all updates were going to it. Am
> I confused, or did the update that caused the crash come in via syncrepl
> though, and hence originate from a different server? So the accesslog
> entry you want would be from that server, not the server that crashed?
> But given no other servers should have been receiving updates, how would
> an update have been received via replication? Or is this another issue
> like the memberOf problem where updates are being improperly replicated?
It appears to be crashing while writing the change to the accesslog
database. It's odd that the value for the attribute is NULL. Do we know
for sure what the client doing the write op to the server is sending?
> Hmm, looking at the logs that correspond with one of the crashes:
> This operation appears to succeed? Then there's this:
>
> Feb 14 04:00:13 fosse slapd[12524]: conn=37859 op=806 MOD
> dn="uid=vntruong,ou=user,dc=csupomona,dc=edu" Feb 14 04:00:13 fosse
> slapd[12524]: conn=37859 op=806 MOD attr=csupomonaEduPersonExpiration
Yeah, so this is the operation that actually failed... It'd be interesting
to know if it succeeded in the primary DB, but failed when writing to the
accesslog DB (I.e., the master and its consumers are now out of sync for
that entry), or if the entire write op failed (master and consumers are in
sync for the entry)
> when I restarted the server. I guess I am confused; the entryCSN has
> serverID 0, the ID of this server, so this isn't a replicated op, it's
> an op from this server. So why does the backtrace show the change coming
> in via syncrepl? It seems like it's getting applied twice. The change is
> deleting the attribute, so the second time it's getting applied you
> would get a no such attribute error...
Hm, so I guess my question would be is it doing the op like this:
dn: ...
changetype: modify
replace: csupomonaEduPersonExpiration
csupomonaEduPersonExpiration:
Or is it doing it like this:
dn: ...
changetype: modify
delete: csupomonaEduPersonExpiration
Because the NULL value seems to imply the former.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
Re: How correctly convert ldif dump size to mdb olcDbMaxSize value
by Quanah Gibson-Mount
--On Tuesday, February 28, 2017 2:48 PM +0300 Ikonta <ikonta(a)yandex.ru>
wrote:
> Hi everybody,
>
> I use simple OpenLDAP installation (two servers in mirror mode, something
> above 30000 leafs tree). Some time ago I've migrated it to mdb backend.
>
> The database dump in ldif weight about 300M.
> Initially I've set olcDbMaxSize to 2147483648 bytes (2G).
> Imported into directory it became about 450M data.mdb on node1 and after
> mirror synced — 1.5G replicated data.mdb on node2. Why instances
> database sizes are so different?
>
> Am I right guessing olcDbMaxSize is maximum size of data.mdb file?
> And how should I, starting with present and perspective ldif dump size,
> count proper value of olcDbMaxSize? For example, if I expect ldif dump
> may grow up to 500 M?
Generally, you just set it to something *very large*. I usually go with
80GB. You're not supposed to try and keep it down to a small value that's
"near" the actual DB size.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
Re: Long ldap session when ldap server failover
by Quanah Gibson-Mount
--On Friday, February 24, 2017 7:27 AM +0000 Huynh Phuoc Tai
<fucai1116(a)yahoo.com> wrote:
>
>
> Hi,
>
>
> I have an issue with long ldap session when ldap server failover.
> [01/Dec/2016:11:40:01 +0100] conn=7187095 op=4 msgId=5 - UNBIND
> [01/Dec/2016:11:40:01 +0100] conn=7187095 op=4 msgId=-1 - closing from
> 10.14.97.45:55287 - U1 - Connection closed by unbind client -
> [01/Dec/2016:11:40:01 +0100] conn=7187095 op=-1 msgId=-1 - closed.
>
>
>
> The openldap client didn't send UNBIND soon but sent after several
> minutes. Could you suggest me any way forward to find the root cause?
> openldap2-client-2.4.26-0.62.2
Well, it shows that the LDAP client didn't unbind until after 5 minutes.
We have no idea *what* that client is, only you do. What is
"cn=ProxyUser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com"? Are you
sure it's an *openldap* client or is it something else?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
