--On Friday, February 17, 2017 2:44 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
> On Thu, Feb 16, 2017 at 03:53:40PM -0800, Quanah Gibson-Mount wrote:
>
>> 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?
>
> The code is in perl, and looks like this:
>
> $entry->…
[View More]replace(eduPersonAffiliation => \@eduPersonAffiliation);
>
> In this case, the array @eduPersonAffiliation is empty, effectively
> deleting the attribute. I'm not 100% sure what this generates on the
> wire, I'd have to debug it. I can say it's the same code that's been
> running for a decade or so with no issues.
Ok, I can see if I can reproduce something like this. Do you have a link
to the schema file in use that adds this attribute?
Also, can you confirm your patch matches
<https://github.com/Zimbra/packages/blob/master/thirdparty/openldap/patches/…>
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
[View Less]
Regarding this issue - our production servers are getting affected. Any help is greatly appreciated.
Is there anything I can try?
http://www.openldap.org/lists/openldap-technical/201702/msg00090.html
Regards,
Ping
PS: I've lost some of my emails - so don't have the email chain
--On Tuesday, February 21, 2017 1:04 PM +0000 Frank Swasey
<Frank.Swasey(a)uvm.edu> wrote:
> Years ago, I had code that did that and then I got a version of Net::LDAP
> that sent null attributes across the wire. Even back then OpenLDAP was
> upset by such behavior. I quickly updated my code to check if (in your
> case) @eduPersonAffiliation had zero entries and issue a proper
> $entry->delete('eduPersonAffiliation') call in that case. I've not had
> any issues …
[View More]since. Perhaps, your Net::LDAP module version has changed and
> it is sending what is being logged across the wire instead of the delete
> you are expecting.
Interesting... It would still be good for OpenLDAP to not crash in that
case, however. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
[View Less]
--On Saturday, February 18, 2017 9:57 AM +0800 Daniel Jung
<mimianddaniel(a)gmail.com> wrote:
>> Do you mean contextCSNs?
> No. ContextCSN is up to date. But some entries have old entryCSN compared
> to the master.
>>
>>
>>> I haven't been able to track the cause nor see anything in the log to
>>> indicate the problem. However, we have had slapd become non-responsive
>>> due to IO blocking on logging. Could this cause syncrepl to miss
&…
[View More]gt;>> updating the entries? Has anyone seen this behaviour?
>>
>>
>> If slapd gets locked up, hard to say what the side effects could be.
>> Do you have stats+sync logging enabled on all of the systems?
> I do have stats and sync enabled.
Well, theoretically slapd shouldn't lose changes, but it's really hard to
know the full ramifications/effects in this scenario. You can file an ITS
on the issue, for tracking, but it may be some time before it's
investigated in depth, as it's not a common scenario. I guess it may be
possible to emulate it by using iptables to drop packages from rsyslogd.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
[View Less]
Daniel Jung wrote:
> Hi Quanah,
>
> Speaking of logging, is openldap-3 going to support udp based logging? I saw
> while back that there is improved? syslog code that we can compile in the src.
> I was thinking of just adding udp into that code and test it out.
I have no plans to add UDP support. Could be done, but what's the benefit?
If you want to add it, feel free to submit a patch.
>
>
> On Feb 18, 2017 09:57, "Daniel Jung" <mimianddaniel(a)gmail.com
> <…
[View More]mailto:mimianddaniel@gmail.com>> wrote:
>
> On Feb 18, 2017 05:41, "Quanah Gibson-Mount" <quanah(a)symas.com
> <mailto:quanah@symas.com>> wrote:
> >
> > --On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung
> <mimianddaniel(a)gmail.com <mailto:mimianddaniel@gmail.com>> wrote:
> >
> >>
> >> Hi,
> >>
> >>
> >> I see that some entryCSN have not been synced properly with the
> >> provider.
> >> I run multimaster setup and with several slaves and sometimes i see that
> >> some slaves have old entryCSNs and I am syncing them manually with -c
> >> option.
> >
> >
> > Do you mean contextCSNs?
> No. ContextCSN is up to date. But some entries have old entryCSN compared
> to the master.
> >
> >
> >> I haven't been able to track the cause nor see anything in the log to
> >> indicate the problem. However, we have had slapd become non-responsive
> >> due to IO blocking on logging. Could this cause syncrepl to miss updating
> >> the entries? Has anyone seen this behaviour?
> >
> >
> > If slapd gets locked up, hard to say what the side effects could be. Do
> you have stats+sync logging enabled on all of the systems?
> I do have stats and sync enabled.
> >
> > --Quanah
> >
> >
> > --
> >
> > Quanah Gibson-Mount
> > Product Architect
> > Symas Corporation
> > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> > <http://www.symas.com>
> >
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
[View Less]
On Feb 18, 2017 05:41, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote:
>
> --On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung <
mimianddaniel(a)gmail.com> wrote:
>
>>
>> Hi,
>>
>>
>> I see that some entryCSN have not been synced properly with the
>> provider.
>> I run multimaster setup and with several slaves and sometimes i see that
>> some slaves have old entryCSNs and I am syncing them manually with -c
>> …
[View More]option.
>
>
> Do you mean contextCSNs?
No. ContextCSN is up to date. But some entries have old entryCSN compared
to the master.
>
>
>> I haven't been able to track the cause nor see anything in the log to
>> indicate the problem. However, we have had slapd become non-responsive
>> due to IO blocking on logging. Could this cause syncrepl to miss updating
>> the entries? Has anyone seen this behaviour?
>
>
> If slapd gets locked up, hard to say what the side effects could be. Do
you have stats+sync logging enabled on all of the systems?
I do have stats and sync enabled.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
[View Less]
Hi
I've been asked to configure a SLAPD/LDAP proxy with more than one LDAP Back-End. The users log into the LDAP client using their email address and the proxy uses the domain part of their UID to decide which slapd-ldap back-end to authenticate against. I have the proxy working - with two defined slapd-ldap back-ends. It's tested and works with one back-end at a time.
I need rwm to process a rewrite of both the searchFilter and searchDN using a key piece of information identified the …
[View More]searchFilter to decide the searchDN.
Original searchDN = "ou=people,ou=my,dc=proxy,dc=com"
Original searchFilter="(&(objectClass=posixAccount)(uid=john(a)domain.one.com))"
Rewritten searchDN = "ou=people,ou=domain,dc=one,dc=com"
Rewritten searchFilter = "(&(objectClass=posixAccount)(uid=john))"
I have:
dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: {0}rwm
olcRwmNormalizeMapped: FALSE
olcRwmRewrite: {0}rwm-rewriteEngine on
#
#Unix LDAP authentication requests arrive with these three components:
# searchDN: OU=people,DC=my,DC=proxy,DC=com - as defined on the LDAP client
# searchFilter: (&(objectClass=posixAccount)(uid=john(a)domain.one.com))
# attributes: userPassword cn gidNumber uidNumber
# loginShell objectClass gecos uid homeDirectory
#
# {1} searchFilter Context:
# {2} rewrite john(a)domain.one.com:
# Strip @domain.one.com part and set &&target to OU=people,DC=domain,DC=one,DC=com
# {3} rewrite jane(a)domain.two.com:
# Strip @domain.two.com part and set &&target to OU=people,DC=domain,DC=two,DC=com
# {4} searchDN Context:
# {5} rewrite OU=people,DC=my,DC=proxy,DC=com the value already defined in &&target
#
olcRwmRewrite: {1}rwm-rewriteContext SearchFilter
#
olcRwmRewrite: {2}rwm-rewriteRule "^(.+uid=[^,]+)(a)domain.one.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=one,dc=com\")}$1$2" ":"
#
olcRwmRewrite: {3}rwm-rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=two,dc=com\")}$1$2" ":"
#
olcRwmRewrite: {4}rwm-rewriteContext searchDN
#
olcRwmRewrite: {5}rwm-rewriteRule "OU=people,[ ]?DC=my,[ ]?DC=proxy,[ ]?DC=com " "${**target}" ":"
This results in a slapd crash because searchDN wants to use the **target variable, but its not yet defined because the searchFilter Context hasn't been run yet.
How do I change the order that the rwm-rewriteContexts are executed so that the context for searcFilter is run first ?
Thanks
Paul
[View Less]
After successful bind and some search actions my client is still bind to
server but as I can see from trace few seconds after successful operation
slapd shuts down connection. Why is that happening? Can I prevent it? We
have monitoring in our software which find that as server down and lots of
logs are generated.
229 1786.027248821 172.17.103.226 -> 10.50.200.191 LDAP 294
searchResEntry(49) "cn=config"
230 1786.027396894 172.17.103.226 -> 10.50.200.191 LDAP 68
searchResDone(49) success
…
[View More]231 1786.028152406 10.50.200.191 -> 172.17.103.226 TCP 60 56375 > ldap
[ACK] Seq=576 Ack=130237 Win=65280 Len=0
232 1798.039843259 172.17.103.226 -> 10.50.200.191 TCP 54 ldap > 56375
[FIN, ACK] Seq=130237 Ack=576 Win=30336 Len=0
233 1798.042231511 10.50.200.191 -> 172.17.103.226 TCP 60 56375 > ldap
[ACK] Seq=576 Ack=130238 Win=65280 Len=0
Br
Sasa
[View Less]
--On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung
<mimianddaniel(a)gmail.com> wrote:
>
> Hi,
>
>
> I see that some entryCSN have not been synced properly with the
> provider.
> I run multimaster setup and with several slaves and sometimes i see that
> some slaves have old entryCSNs and I am syncing them manually with -c
> option.
Do you mean contextCSNs?
> I haven't been able to track the cause nor see anything in the log to
> …
[View More]indicate the problem. However, we have had slapd become non-responsive
> due to IO blocking on logging. Could this cause syncrepl to miss updating
> the entries? Has anyone seen this behaviour?
If slapd gets locked up, hard to say what the side effects could be. Do
you have stats+sync logging enabled on all of the systems?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
[View Less]