Re: fedora and openldap
by Judith Flo Gaya
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same
place, the system is able to do ldapsearch but all user auth is not
working, I do this in order to configure the auth in the clients
# authconfig --disablecachecreds --enableldaps --enableldapauth
--ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
--disablefingerprint --disablewinbind --disablewins --disablesssd
--disablesssdauth --disablenis --enablecache --enablelocauthorize
--disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok
try_first_pass use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
This is the message in ldap server when I do id <ldap_user>
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
IP=[::1]:36208 (IP=[::]:636)
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
tls_ssf=256 ssf=256
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
text=TLS already started
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known
Any ideas?
Thanks a lot!
j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
> Hello Aaron,
>
> On 04/13/2011 09:07 PM, Aaron Richton wrote:
>> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
>>
>>> I see, I also have those files that you mention... I created my own CA
>>> as lots of tutorials explain.. Then I transmitted it to the clients and
>>> used it in the ldap.conf file. Do you suggest me to send those to the
>>> server and use them instead of the ones I generated with openssl?
>>
>> Well, you'll need the CA on the client to match the CA that signed the
>> server's certificate. In other words...if you generated your own CA for
>> both the client and the server, trust issues would be completely
>> expected...
> I don't know if I understood you or I didn't make myself clear on that
> point. I created a CA in the server and the copied the file to the
> client, is that wrong?
>>
>>> What's your server?
>>
>> OpenLDAP software is on both sides of the equation; it's just that some
>> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
>> ALL servers are OpenSSL.
> I was talking about the operating system, for some reason I think that
> having red hat (with openldap compiled using openssl) and clients with
> fedora (openldap compiled against moznss) created my problems.
> Now that you said that this is your case (I think) then it may be
> something related to... I don't know what.
>>
>>> Well my final problem were not ldapsearch but the user autenticacion.
>>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
>>> with an ldap user to the machine, I get some TLS negotiation problem ;(
>>> That's when I was told that the problem may be caused by the
>>> implementation of the ldap client (with moznss support).
>>
>> Well, when troubleshooting, it's often easiest to look with a narrow
>> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
>> will probably offer a better debugging platform than an ssh
>> implementation? One step at a time...
> Yes, I totally agree, that's why I setup my own openldap installation
> and only care about ldapsearch working, then when ldapsearch finally
> worked, then I start looking at the user auth part, changing passw,
> etc.. as this part wasn't working and it appear to be a moznss problem,
> I got stuck... until you arrived, I will try what you suggest about
> using the pki certs instead of the openssl ones..
>
> Thanks a lot for the suggestion, hope this finally fix the issue.
> j
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo(a)imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org
13 years, 7 months
Re: Authenticate to ldap using Kerberos
by Wouter van Marle
On Thu, 2010-09-09 at 23:02 -0500, Dan White wrote:
> On 09/09/10 20:05 -0700, Russ Allbery wrote:
> >Wouter van Marle <wouter(a)squirrel-systems.com> writes:
> >> At this moment, I can connect to my ldap server from Evolution,
> >> authenticated. I have to enter a username and a password in my evo
> >> settings, which one way or another is communicated to openldap, which
> >> then checks this un/pw combo and considers it valid to give the
> >> information.
> >
> >If you are using Kerberos, you should never have to enter your username
> >and password into anything that isn't kinit or your initial authentication
> >to your system. If you do, that something is broken and is not using
> >Kerberos properly. Period.
>
> So if the poster had stated that he wanted to perform PAM authentication
> for his simple binds, I don't think he'd be confronted with such a violent
> reaction. However, from the standpoint of slapd, that's exactly what he's
> wanting to do.
Which is indeed what I have now slowly found out. I'm not an expert in
openldap or security; in the end I just want it to work. And
unfortunately evolution doesn't support all possible protocols; which is
of course why other applications try to support as many as possible, to
at least and up with one match.
Now Evolution can talk to openldap, and can authenticate, which is why I
can't call it "broken". Maybe it could be done better, maybe there are
newer protocols. But it's not broken in the sense of "doesn't work".
On top of that as long as it's on my own LAN, not out over the Internet,
I'm not worried about using plain passwords over unencrypted
connections. If an attacker manages to start sniffing passwords off of
my LAN (which is physically inside my office; all wired) then I have
worse security issues to worry about.
> Performing simple binds have precisely the same negative security footprint
> regardless of where his passwords may be stored. I'm assuming Evolution
> supports ldaps or STARTTLS,
Evolution does support encryption using TLS and SSH connections (that is
how it's called in the settings). And if I understand everything well
then plain authentication using one of those protocols is still pretty
secure.
Wouter.
> which would go a long way in mitigating that
> risk. If it didn't support TLS, I'd think that'd be a much more urgent
> focus (GSSAPI only provides 56 bits of encryption).
>
> >> Now basically the problem is that ldap is using the wrong authentication
> >> type. Wrong as in not the one that I want it to use. It is using it's
> >> own, internal authentication - this I want to change to an external
> >> system. It seems I need something like you guys call 'pass-through
> >> authentication'. And what I learnt over the last year or so when I
> >> looked more into this and related matter, Linux provides sasl and pam as
> >> general authentication libs, designed exactly for this purpose. Sasl and
> >> pam even can talk to each other.
>
> At this point, I'd agree with the above.
>
> >No. This is not correct.
>
> >SASL is what you do when you implement Kerberos properly. Evolution is
> >not doing this. It's either implementing a broken version of SASL where
> >it only implements a single mechanism (PLAIN), or it's actually not doing
> >SASL at all (most likely). The problem is exactly that Evolution is not
> >properly implementing Kerberos SASL mechanisms.
>
> Would you agree that any application which does not support the full range
> of SASL mechanisms is broken? What about simple binds? Would you suggest
> that OpenLDAP remove all support for simple binds? If not, why not?
>
> >PAM is indeed a way to verify passwords, but it has nothing to do with
> >SASL except in the very limited special case that there is one SASL
> >mechanism that communicates a password to the server, and once the
> >password is on the server, you might want to use PAM to check it. PAM is
> >not a network protocol; PAM is a way of plugging together password
> >verification systems on a local system and was really designed for either
> >console login or remote authentication that requires a password (such as
> >ssh without any Kerberos support). If you have Kerbeors and yet you're
> >resorting to using it with network services like LDAP, that means your
> >client software (in this case Evolution) is crappy and broken.
>
> Most protocols have support for legacy (pre-SASL) authentication. IMAP has
> login, POP has user/pass, LDAP has simple binds. (SMTP being one exception
> to this).
>
> In an ideal world we could just do away with all software that only
> has support for legacy authentication, but that'd break a good chunk of the
> ISP services I help to maintain. I'm not really a big fan of that.
>
> >Sadly, lots of client software is crappy and broken, so this is not an
> >uncommon thing to have to do, but that doesn't make Evolution any less
> >broken.
>
14 years, 2 months
Re: Problem with N-Way multimaster replication after an node fail and restore
by David Tello
Hi Ulrich,
Thank for your aswer. About the serverIDs, i think that are well
configured. I enable all trace in the servers an restart all nodes. I got
the below outs:
Node1:
May 13 11:04:36 wbsvisionNode1 slapd[27787]: olcServerID: value #0:
SID=0x001 (listener=ldap://wbsvisionNode1)
Node2:
May 13 11:05:43 wbsvisionNode2 slapd[17862]: olcServerID: value #1:
SID=0x002 (listener=ldap://wbsvisionNode2)
Node3:
May 13 11:06:27 wbsvisionNode3 slapd[6980]: olcServerID: value #2:
SID=0x003 (listener=ldap://wbsvisionNode3)
I understand that this outputs are the corrects.
I made the changes that Quanah indicated to me and i had the same behavior.
I continue searching...
Regards,
David Tello
El lun., 13 may. 2019 a las 8:04, Ulrich Windl (<
Ulrich.Windl(a)rz.uni-regensburg.de>) escribió:
> >>> David Tello <david.tello.wbsgo(a)gmail.com> schrieb am 09.05.2019 um
> 10:21
> in
> Nachricht
> <CADC8=Wxww4kTHyRS3_j+93VXRzc45fDrVLJxFwFTRjcH8QD_gQ(a)mail.gmail.com>:
> > I have a problem with the N-Way replication multimaster. My enviroiment
> is
> > debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch backports.
> >
> > I have configured a cluster with 3 nodes. I have configured to replicate
> > the config database and a normal data mdb database. I followed the
> > documentation and the cluster sync work correctly when all nodes are
> > started.
> >
> > If i made a change in any node, this change is replicated to the others.
> My
> > problem appears when i make a change whe one node is down. In this case,
> > the other two nodes repli correctly, and when the downed node start this
> > get all pending changes correctly. And in this point occurs the problem.
> > After the start of downed node, the changes mades in this node are not
> send
> > to the other two nodes. For other way, the changes mades in the other two
> > nodes (no shutdowned) are sended to all nodes correctly.
> >
> > I tried this config with a two nodes cluster and the behavior was the
> same,
> > after reboot slapd do not send more updates.
> >
> >
> > I have checked the olcServerId because i know that a mistake here can
> > produce similar problems. I really think that it is correct.
> >
> > The cmdlines of the proccess are:
> >
> > /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode1/ ldap://127.0.0.1/
> > ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> > /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode2/ ldap://127.0.0.1/
> > ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> > /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode3/ ldap://127.0.0.1/
> > ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> >
> >
> > The config database configuración is below:
> >
> > *DN: cn=config*
> > .....
> > olcServerID: 1 ldap://wbsvisionNode1/
> > olcServerID: 2 ldap://wbsvisionNode2/
> > olcServerID: 3 ldap://wbsvisionNode3/
>
> Are you sure your server IDs are assigned as intended? It is logged like
> "slapd[1493]: olcServerID: value " on start.
>
> >
> > *dn: olcDatabase={0}config,cn=config*
> > .......
> > olcMirrorMode: TRUE
> >
> > olcSyncUseSubentry: FALSE
> >
> > olcSyncrepl:
> >
> > {0}rid=001
> > provider=ldap://wbsvisionNode1
> > bindmethod=simple
> > binddn="cn=admin,cn=config"
> > credentials="TuoDqAG7UbCJx8H8gfMO"
> > starttls=no
> > tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> > tls_key=/etc/pki/private/wbsagnitio.local.es.key
> > tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> > tls_reqcert=never
> > searchbase="cn=config"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> > {1}rid=002
> > provider=ldap://wbsvisionNode2
> > bindmethod=simple
> > binddn="cn=admin,cn=config"
> > credentials="TuoDqAG7UbCJx8H8gfMO"
> > starttls=no
> > tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> > tls_key=/etc/pki/private/wbsagnitio.local.es.key
> > tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> > tls_reqcert=never
> > searchbase="cn=config"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> > {2}rid=003
> > provider=ldap://wbsvisionNode3
> > bindmethod=simple
> > binddn="cn=admin,cn=config"
> > credentials="TuoDqAG7UbCJx8H8gfMO"
> > starttls=no
> > tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> > tls_key=/etc/pki/private/wbsagnitio.local.es.key
> > tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> > tls_reqcert=never
> > searchbase="cn=config"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> > FALSE
> >
> > ------
> >
> > *dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config*
> > objectClass: olcSyncProvConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {0}syncprov
> > olcSpCheckpoint: 1000 1
> >
> >
> > The data database configuración is below:
> >
> >
> >
> > *dn: olcDatabase={1}mdb,cn=config*
> > objectClass: olcMdbConfig
> > objectClass: olcDatabaseConfig
> > olcDatabase: {1}mdb
> > ...
> > olcDbIndex: objectClass eq
> > olcDbIndex: entryCSN eq
> > ...
> > olcLastMod: TRUE
> >
> > olcSuffix: dc=local,dc=es
> > .........
> > olcMirrorMode: TRUE
> >
> > olcSyncrepl: {0}rid=004
> > provider=ldap://wbsvisionNode1
> > bindmethod=simple
> > binddn="cn=manager,dc=local,dc=es"
> > credentials="test"
> > starttls=no
> > searchbase="dc=local,dc=es"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> >
> > olcSyncrepl: {1}rid=005
> > provider=ldap://wbsvisionNode2
> > bindmethod=simple
> > binddn="cn=manager,dc=local,dc=es"
> > credentials="test"
> > starttls=no
> > searchbase="dc=local,dc=es"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> >
> > olcSyncrepl: {2}rid=006
> > provider=ldap://wbsvisionNode3
> > bindmethod=simple
> > binddn="cn=manager,dc=local,dc=es"
> > credentials="test"
> > starttls=no
> > searchbase="dc=local,dc=es"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> >
> > olcSyncUseSubentry: FALSE
> >
> > dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
> > objectClass: olcDynamicList
> > objectClass: olcOverlayConfig
> > olcOverlay: {0}dynlist
> > olcDlAttrSet: {0}virtualGroup memberDnURL uniqueMember
> > olcDlAttrSet: {1}virtualGroup memberUidURL memberUid:uid
> > olcDlAttrSet: {2}virtualGroup memberSidURL sambaSIDList:sambaSID
> >
> > dn: olcOverlay={1}lastbind,olcDatabase={1}mdb,cn=config
> > objectClass: olcLastBindConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {1}lastbind
> > olcLastBindPrecision: 30
> >
> > dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
> > objectClass: olcUniqueConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {2}unique
> > olcUniqueAttribute: uid
> > olcUniqueAttribute: uidNumber
> > olcUniqueAttribute: employeeNumber
> > olcUniqueBase: dc=local,dc=es
> >
> > dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config
> > objectClass: olcMemberOf
> > objectClass: olcOverlayConfig
> > olcOverlay: {3}memberof
> > olcMemberOfDangling: ignore
> > olcMemberOfGroupOC: groupOfUniqueNames
> > olcMemberOfMemberAD: uniqueMember
> > olcMemberOfMemberOfAD: memberOf
> > olcMemberOfRefInt: TRUE
> >
> > dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config
> > objectClass: olcAccessLogConfig
> > objectClass: olcOverlayConfig
> > olcAccessLogDB: cn=accesslog
> > olcOverlay: {4}accesslog
> > olcAccessLogOld:
> (|(objectClass=wbsagnitioGroup)(objectClass=wbsagnitioAccou
> > nt))
> > olcAccessLogOldAttr: roles
> > olcAccessLogOldAttr: objectClass
> > olcAccessLogOps: writes
> > olcAccessLogOps: bind
> > olcAccessLogPurge: 7+00:00 1+00:00
> >
> > dn: olcOverlay={5}ppolicy,olcDatabase={1}mdb,cn=config
> > objectClass: olcPPolicyConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {5}ppolicy
> > olcPPolicyDefault:
> cn=0-default,ou=passwordpolicies,ou=configuration,dc=loca
> > l,dc=es
> > olcPPolicyForwardUpdates: FALSE
> > olcPPolicyHashCleartext: FALSE
> > olcPPolicyUseLockout: FALSE
> >
> > dn: olcOverlay={6}syncprov,olcDatabase={1}mdb,cn=config
> > objectClass: olcSyncProvConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {6}syncprov
> > olcSpCheckpoint: 1000 1
> >
> > Below i show the sync log of some operations to show the behavior of my
> > cluster:
> > TEST 1: 3 Nodes up. Update in node 1 (correct):Log Node1:
> >
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> > Log Node2:
> >
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid 23fff700
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> > cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006
> > cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 CSN too
> > old, ignoring 20190507150322.383471Z#000000#001#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> > Log Node3:
> >
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid adbb2700
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> > cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> > cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 CSN too
> > old, ignoring 20190507150322.383471Z#000000#001#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> >
> >
> > TEST 2: 3 Nodes up. Update in node 2 (correct) (later this will be the
> down
> > node):Log Node1:
> >
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=005
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_message_to_entry:
> > rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid eaffd700
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > be_search (0)
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> > cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006
> > cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 CSN too
> > old, ignoring 20190507150531.748816Z#000000#002#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> >
> > Log Node2:
> >
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=001,
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> >
> > Log Node3:
> >
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> > rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid acbb0700
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > be_search (0)
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=001,
> > cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 CSN too
> > old, ignoring 20190507150531.748816Z#000000#002#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> >
> >
> > TEST 3: 2 Nodes up. The node 2 is down. Update in node 1:Log Node1:
> >
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> > cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> > cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> > Log Node3:
> >
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid a6ffd700
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> > cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
> >
> >
> > TEST 4: 3 Nodes up. Logs of the sync produced by the Node2 start. The
> node2
> > resync correctly the change made in TEST3 (when this node was down).
> > Log Node1:
> >
> > May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode1 slapd[14058]: syncprov_search_response:
> >
>
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> > Log Node2:
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slapd starting
> > May 7 17:13:52 wbsvisionNode2 slapd[435]: Starting OpenLDAP: slapd.
> > May 7 17:13:52 wbsvisionNode2 systemd[1]: Started LSB: OpenLDAP
> standalone
> > server (Lightweight Directory Access Protocol).
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=001
> > LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=003
> > LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> > LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> > LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f6021700
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> > rid=006 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f501f700
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: dn_callback : entries have
> > identical CSN cn=Usuarios,ou=grupos,dc=local,dc=es
> > 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> > be_search (0)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 entry
> > unchanged, ignored (cn=Usuarios,ou=grupos,dc=local,dc=es)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> > LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> >
>
> cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> > ou=personas,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> > ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> > ou=dominios,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn
> ou=dns,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b9eaaa-00ff-1039-8994-b1c1eec8fb13, dn
> > ou=forward,ou=dns,dc=local,dc=es
> > .................................
> >
> > Similar lines with other entries.
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > ...............................
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> > LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> >
>
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> > ou=personas,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> > ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> > ou=dominios,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn
> ou=dns,dc=local,dc=es
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > .............................
> >
> > Similar lines with other entries.
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
> >
> > Log Node3:
> >
> > May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode3 slapd[1100]: syncprov_search_response:
> >
>
> cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> >
> >
> > TEST 5: 3 Nodes up. Change is made in Node2 after resync and this is not
> > sended to the other nodes in the cluster.Log Node1:
> >
> > Empty.
> > Log Node2:
> >
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> > Log Node3:
> >
> > Empty.
>
>
>
>
5 years, 6 months
Re: Syncrepl only partially working
by Dieter Klünter
Am Fri, 28 Oct 2016 21:50:30 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
> Greetings all,
>
> I'm trying to figure out why Syncrepl is only syncing part of my
> provider's database when I use GSSAPI to connect. Both my provider
> and consumer are on 2.4.40. Here are all the steps I'm taking:
>
> My provider is working fine, I've been using it for months now
> without any issues. I added this to the provider:
>
> dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
> objectClass: olcSyncProvConfig
> olcOverlay: {0}syncprov
> olcSpCheckpoint: 100 10
> structuralObjectClass: olcSyncProvConfig
> entryUUID: b32ac160-29e6-1036-8d0a-07ef98fd592e
> creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> createTimestamp: 20161019012544Z
> olcSpSessionlog: 100
> entryCSN: 20161024233803.817199Z#000000#000#000000
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20161024233803Z
>
> I also indexed entryCSN and entryUUID on the provider. I have
> olcAuthzRegexp setup on the provider as well.
>
> olcAuthzRegexp: {0}"uid=admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
> "cn=admin,dc=harmonywave,dc=com" olcAuthzRegexp:
> {1}"uid=ldap/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
> "dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
> olcAuthzRegexp:
> {2}"uid=syncprov,cn=harmonywave.com,cn=GSSAPI,cn=auth"
> "cn=syncprov,dc=harmonywave,dc=com" #not using this. olcAuthzRegexp:
> {3}"uid=.*\/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth"
> "cn=admin,dc=harmonywave,dc=com" olcAuthzRegexp:
> {4}"uid=host\/([^.]*).harmonywave.com,cn=harmonywave.com,cn=GSSAPI,cn=auth"
> "cn=$1+ipHostNumber=.*,ou=Hosts,dc=harmonywave,dc=com"
> olcAuthzRegexp: {5}"uid=([^/]*),cn=harmonywave.com,cn=GSSAPI,cn=auth"
> "uid=$1,ou=End Users,ou=People,dc=harmonywave,dc=com"
>
> On the consumer I have slapd installed. The first thing I did was
> change the olcSuffix on my database. I'm not sure if this is required
> or not.
>
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> replace: olcSuffix
> olcSuffix: dc=harmonywave,dc=com
> -
> replace: olcRootDN
> olcRootDN: cn=admin,dc=harmonywave,dc=com
>
> Then I'm adding my ldap keytab for the consumer.
>
> kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/consumer.harmonywave.com
> consumer: ~# chown openldap:openldap /etc/ldap/ldap.keytab
> consumer: ~# chmod 0640 /etc/ldap/ldap.keytab
>
> I edited my /etc/default/slapd file and pointed the KRB5_KTNAME
> environment variable to the new keytab then restarted slapd. Next I
> installed kstart and created a ticket cache.
>
> consumer: ~# k5start -U -f /etc/ldap/ldap.keytab -K 10 -l 24h
> -k /tmp/krb5cc_108 -o openldap -b
>
> I can see the ldap service's keytab with klist.
>
> consumer: ~# klist /tmp/krb5cc_108
>
> Ticket cache: FILE:/tmp/krb5cc_108
> Default principal: ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM
>
> Valid starting Expires Service principal
> 10/28/2016 21:18:14 10/29/2016 07:18:14
> krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM renew until 10/29/2016 21:18:14
>
> Then I add my olcSaslRealm
>
> dn: cn=config
> changetype: modify
> add: olcSaslRealm
> olcSaslRealm: HARMONYWAVE.COM
>
> Here is what my database looks like right before I add olcSyncrepl:
>
> dn: olcDatabase={1}mdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcMdbConfig
> olcDatabase: {1}mdb
> olcDbDirectory: /var/lib/ldap
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
> anonym ous auth by * none
> olcAccess: {1}to dn.base="" by * read
> olcAccess: {2}to * by * read
> olcLastMod: TRUE
> olcRootPW:: ...
> olcDbCheckpoint: 512 30
> olcDbMaxSize: 1073741824
> structuralObjectClass: olcMdbConfig
> entryUUID: 9a091324-2e84-1036-8b7a-73db8891632a
> creatorsName: cn=admin,cn=config
> createTimestamp: 20161024222607Z
> olcSuffix: dc=harmonywave,dc=com
> olcRootDN: cn=admin,dc=harmonywave,dc=com
> olcDbIndex: cn,uid eq
> olcDbIndex: entryCSN eq
> olcDbIndex: entryUUID eq
> olcDbIndex: member,memberUid eq
> olcDbIndex: objectClass eq
> olcDbIndex: uidNumber,gidNumber eq
> entryCSN: 20161029033105.691204Z#000000#000#000000
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20161029033105Z
>
> then I add olcSyncrepl to the consumer.
>
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> add: olcSyncrepl
> olcSyncrepl: {0}rid=000
> provider=ldap://provider.harmonywave.com
> type=RefreshAndPersist
> retry="30 10 1800 +"
> searchbase="dc=harmonywave,dc=com"
> bindmethod=sasl
> saslmech=GSSAPI
> starttls=critical
> tls_cacert=/etc/ssl/certs/ca.harmonywave.com.pem
> tls_reqcert=demand
>
>
> After that I slapcat on the consumer and I only see about 1/3 of my
> data from the provider. When I watch the log on the provider this is
> what I get:
>
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 ACCEPT from
> IP=10.1.30.19:55992 (IP=0.0.0.0:389) Oct 28 21:39:02 baneling
> slapd[12540]: conn=4421 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 28
> 21:39:02 baneling slapd[12540]: conn=4421 op=0 STARTTLS Oct 28
> 21:39:02 baneling slapd[12540]: conn=4421 op=0 RESULT oid= err=0
> text= Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS
> established tls_ssf=128 ssf=128 Oct 28 21:39:02 baneling
> slapd[12540]: conn=1005 op=43768 SRCH base="dc=harmonywave,dc=com"
> scope=2 deref=0
> filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM))"
> Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH
> attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey
> krbmaxrenewableage krbmaxticketlife krbticketflags
> krbprincipalexpiration krbticketpolicyreference krbUpEnabled
> krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth
> krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange
> krbLastAdminUnlock krbExtraData krbObjectReferences
> krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]:
> conn=1005 op=43768 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct
> 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH
> base="dc=harmonywave,dc=com" scope=2 deref=0
> filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM))"
> Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH
> attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey
> krbmaxrenewableage krbmaxticketlife krbticketflags
> krbprincipalexpiration krbticketpolicyreference krbUpEnabled
> krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth
> krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange
> krbLastAdminUnlock krbExtraData krbObjectReferences
> krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]:
> conn=1005 op=43769 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct
> 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH
> base="dc=harmonywave,dc=com" scope=2 deref=0
> filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM))"
> Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH
> attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey
> krbmaxrenewableage krbmaxticketlife krbticketflags
> krbprincipalexpiration krbticketpolicyreference krbUpEnabled
> krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth
> krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange
> krbLastAdminUnlock krbExtraData krbObjectReferences
> krbAllowedToDelegateTo Oct 28 21:39:02 baneling slapd[12540]:
> conn=1005 op=43770 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct
> 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 BIND dn=""
> method=163 Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1
> RESULT tag=97 err=14 text=SASL(0): successful result: Oct 28 21:39:02
> baneling slapd[12540]: conn=4421 op=2 BIND dn="" method=163 Oct 28
> 21:39:02 baneling slapd[12540]: conn=4421 op=2 RESULT tag=97 err=14
> text=SASL(0): successful result: Oct 28 21:39:02 baneling
> slapd[12540]: conn=4421 op=3 BIND dn="" method=163 Oct 28 21:39:02
> baneling slapd[12540]: conn=4421 op=3 BIND
> authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
> authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM" Oct 28
> 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
> dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth"
> mech=GSSAPI sasl_ssf=56 ssf=128 Oct 28 21:39:02 baneling
> slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text= Oct 28
> 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH
> base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND Oct 28
> 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
>
> The only thing I really notice from this is near the end of the file.
> It when it searches the base with attributes "*+", but then
> immediately unbinds. I've seen people stating that authzid is
> required, but when I don't provide it I still get a partial sync, so
> I'm not sure about this. I've restored my consumer to a clean install
> of slapd and repeated the above steps with minor variations several
> times but the consumer always syncs the exact same amount of data and
> then seems to stop.
>
> Any help to point me in the right direction would be appreciated.
Note that there is a hard coded limit to 500 operations. If you have
more than 500 entries, syncrepl only recieves a limited set of entries.
Read slapd-config(5) on limits.
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
8 years
Segmentation Fault on ldap_chain_op
by Jeremy Diaz
Hi everyone,
I am currently looking into an issue with an environment that consists of 3 producers and 6 consumers all on OpenLdap 2.4.48. All the masters share an identical master config and all of the consumers share an identical consumer config. One consumer server in particular is crashing on a random time interval with no obvious reason. Each ldap server has sasl pass through auth setup and there is an additional slapd process on each server being used as a ldap meta to AD.
One server in particular, is crashing at seemingly random intervals. Upon initial inspection, we noticed that around the time of a crash, saslauthd logs would have an increase in failed write messages:
Dec 11 07:23:20 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out
Dec 11 07:23:30 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out
Dec 11 07:23:40 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out
Dec 11 07:23:56 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out
Dec 11 07:23:57 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out
Dec 11 07:23:57 {REDACTED} saslauthd[2719]: user ldap_search_st() failed: Timed out
Dec 11 07:24:05 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out
Dec 11 07:24:06 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out
Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write: Broken pipe
Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write: Broken pipe
Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write: Broken pipe
Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write: Broken pipe
Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write failure
Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write: Broken pipe
Initially we thought this meant that the crashes were caused by performance issues with AD, saslauthd or the ldap meta instance. We also ran slapd in full debugging mode to see if the logs have some kind of hints to the source of the issue.
The resulting slapd logs were normal. To obtain further information we obtained the following trace of the segfault using gdb:
starting
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
frames-invalid
[New Thread 0x7ffbf19be700 (LWP 22956)]
new-thread
[New Thread 0x7ffbf11bd700 (LWP 22957)]
new-thread
[New Thread 0x7ffbf09bc700 (LWP 22958)]
new-thread
[New Thread 0x7ffbebfff700 (LWP 22959)]
new-thread
[New Thread 0x7ffbeb7fe700 (LWP 22963)]
new-thread
[New Thread 0x7ffbe9cfb700 (LWP 22965)]
new-thread
[New Thread 0x7ffbd3fff700 (LWP 22966)]
new-thread
signal
Program received signal
signal-name
SIGSEGV
signal-name-end
,
signal-string
Segmentation fault
signal-string-end
.
[Switching to Thread 0x7ffbf09bc700 (LWP 22958)]
thread-changed
frame-begin 0 0x4e52e3
frame-function-name
ldap_chain_op
frame-args
(
arg-begin
op=op@entry
arg-name-end
=
arg-value *
0x7ffbe41f0870
arg-end
,
arg-begin
rs=rs@entry
arg-name-end
=
arg-value *
0x7ffbf09bbb20
arg-end
,
arg-begin
op_f
arg-name-end
=
arg-value *
0x4a845e <ldap_back_search>
arg-end
,
arg-begin
ref=ref@entry
arg-name-end
=
arg-value *
0x0
arg-end
,
arg-begin
depth=depth@entry
arg-name-end
=
arg-value -
0
arg-end
)
frame-source-begin
at
frame-source-file
chain.c
frame-source-file-end
:
frame-source-line
422
frame-source-end
source ${REDACTED DIR}/chain.c:422:11629:beg:0x4e52e3
frame-end
stopped
post-prompt
#0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422
#1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090
#2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237
#3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508
#4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583
#5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861
#6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558
#7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211
#11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251
#12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677
#13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402
#16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247
#20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158
#21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307
#23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbd3ffdc10 " aaf9: 04 3a 75 69 64 3d 53 49 41 53 47 52 50 2c 6f 75 .:uid=SIASGRP,ou \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbcd83df04 "0\203\n\036\273\004\funiqueMember1\203\n\036\250\004\071uid=wtso732,ou={REDACTED}“…, len=len@entry=663561) at bprint.c:202
#5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:276
#6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:247
#7 0x00000000005894c1 in ber_scanf (ber=0x7ffbcc122e20, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723
#8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbd3ffdf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbd3ffe320, msg=<optimized out>, op=0x7ffbd3ffe510, si=0xa3e9e0) at syncrepl.c:2658
#9 do_syncrep2 (op=op@entry=0x7ffbd3ffe510, si=si@entry=0xa3e9e0) at syncrepl.c:1043
#10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3e670) at syncrepl.c:1571
#11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbd3fff700) at pthread_create.c:307
#13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 0x00007ffff673e16d in write () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff66c91a3 in _IO_new_file_write (f=0x937c20, data=0x7ffff7ff8000, n=162) at fileops.c:1258
#2 0x00007ffff66ca9be in new_do_write (to_do=162, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., fp=0x937c20) at fileops.c:519
#3 _IO_new_do_write (fp=0x937c20, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., to_do=162) at fileops.c:495
#4 0x00007ffff66c87f8 in _IO_new_file_sync (fp=0x937c20) at fileops.c:869
#5 0x00007ffff66bd5f3 in __GI__IO_fflush (fp=0x937c20) at iofflush.c:40
#6 0x000000000058c21a in lutil_debug (debug=<optimized out>, level=level@entry=1, fmt=fmt@entry=0x59c7a6 ">>> dnPretty: <%s>\n") at debug.c:81
#7 0x000000000044c792 in dnPretty (syntax=syntax@entry=0x8c4810, val=val@entry=0x7ffbe9cf9d00, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at dn.c:539
#8 0x000000000046c614 in nameUIDPretty (syntax=0x8c4810, val=0x7ffbd9845600, out=0x7ffbe9cf9de0, ctx=0x0) at schema_init.c:1350
#9 0x000000000045383d in ordered_value_pretty (ad=ad@entry=0xa40470, val=0x7ffbd9845600, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at value.c:511
#10 0x000000000044f676 in slap_mods_check (op=op@entry=0x7ffbe9cfa510, ml=0x7ffbd992c410, text=text@entry=0x7ffbe9cf9f60, textbuf=textbuf@entry=0x7ffbe9cfa180 "H\034\032\330\373\177", textlen=textlen@entry=256, ctx=ctx@entry=0x0) at modify.c:575
#11 0x0000000000492e10 in syncrepl_message_to_entry (syncUUID=0x7ffbe9cf9f40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbe9cfa320, msg=<optimized out>, op=0x7ffbe9cfa510, si=0xa3fb20) at syncrepl.c:2715
#12 do_syncrep2 (op=op@entry=0x7ffbe9cfa510, si=si@entry=0xa3fb20) at syncrepl.c:1043
#13 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa40060) at syncrepl.c:1571
#14 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#15 0x00007ffff754cdd5 in start_thread (arg=0x7ffbe9cfb700) at pthread_create.c:307
#16 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbeb7fcc10 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbd576fee7 "0\027\004\002cn1\021\004\017CSC User Access0-\004\025structuralObjectClass1\024\004\022groupOfUniqueNames03\004\tentryUUID1&\004$13257271-b706-49bc-a2a9-a5f3e7f4a0dd0L\004\fcreatorsName1<\004:cn={REDACTED}”…, len=len@entry=61665) at bprint.c:202
#5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:276
#6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:247
#7 0x00000000005894c1 in ber_scanf (ber=0x7ffbd4319130, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723
#8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbeb7fcf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbeb7fd320, msg=<optimized out>, op=0x7ffbeb7fd510, si=0xa3f3b0) at syncrepl.c:2658
#9 do_syncrep2 (op=op@entry=0x7ffbeb7fd510, si=si@entry=0xa3f3b0) at syncrepl.c:1043
#10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3f8b0) at syncrepl.c:1571
#11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbeb7fe700) at pthread_create.c:307
#13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbebe6cf20 " b6c6: 03 0a 01 04 30 22 02 03 02 38 56 17 0d 31 38 30 ....0\"...8V..180 \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbe04282a0 "0\203UK\275\002\001\001d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202
#5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175
#6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe17f55b0, ber=ber@entry=0x7ffbebe6d0f0, freeit=freeit@entry=0) at io.c:240
#7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe41bd940, ber=ber@entry=0x7ffbebe6d0f0) at result.c:339
#8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe41bd940, rs=<optimized out>) at result.c:1430
#9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbebffeaa0) at search.c:1085
#10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#11 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#13 0x000000000043c33f in fe_op_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:402
#14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#15 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#17 0x000000000043bef6 in do_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:247
#18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbebffebd0, arg_v=arg_v@entry=0x7ffbe41bd940) at connection.c:1158
#19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbebffebd0, argv=<optimized out>) at connection.c:1294
#20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbebfff700) at pthread_create.c:307
#22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422
#1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090
#2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237
#3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508
#4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583
#5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861
#6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558
#7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211
#11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251
#12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677
#13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402
#16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247
#20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158
#21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307
#23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbf102af20 " e54c: 33 5a 30 0c 30 0a 06 03 55 1d 15 04 03 0a 01 04 3Z0.0...U....... \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbe42cc110 "0\203UK\275\002\001\021d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202
#5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175
#6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe422daa0, ber=ber@entry=0x7ffbf102b0f0, freeit=freeit@entry=0) at io.c:240
#7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe42197b0, ber=ber@entry=0x7ffbf102b0f0) at result.c:339
#8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe42197b0, rs=<optimized out>) at result.c:1430
#9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbf11bcaa0) at search.c:1085
#10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#11 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#13 0x000000000043c33f in fe_op_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:402
#14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#15 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#17 0x000000000043bef6 in do_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:247
#18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbf11bcbd0, arg_v=arg_v@entry=0x7ffbe42197b0) at connection.c:1158
#19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbf11bcbd0, argv=<optimized out>) at connection.c:1294
#20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf11bd700) at pthread_create.c:307
#22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 0x00007ffff674d603 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1 0x000000000043618b in slapd_daemon_task (ptr=<optimized out>) at daemon.c:2539
#2 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf19be700) at pthread_create.c:307
#3 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 0x00007ffff754df47 in pthread_join (threadid=140720067045120, thread_return=thread_return@entry=0x0) at pthread_join.c:90
#1 0x00000000005642b8 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at thr_posix.c:197
#2 0x0000000000437766 in slapd_daemon () at daemon.c:2932
#3 0x0000000000420b84 in main (argc=<optimized out>, argv=0x7fffffffe408) at main.c:1017
The above trace seems to suggest the source of the segfault is coming from the ldap_chain_op function at chain.c:422. We use chain forwarding for ppolicy operations on the consumers.
This is the line:
for ( ; !BER_BVISNULL( ref ); ref++ ) {
BER_BVISNULL is not a function but a macro which is defined (lber_pvt.h:216) as follows:
#define BER_BVISNULL(bv) ((bv)->bv_val == NULL)
The above seems suggests that ref is set to null at the time of the check.
When I double checked my chain configs I noticed there was an entry that did not contain the olcDbURI attribute that I did not create. It seems that this particular entry was created by the cn=config conversion for the following slapd.conf configuration:
Overlay chain
chain-proxy-whoami yes
chain-uri {REDACTED URI 1}
Chain-cache-uri FALSE
Chain-max-depth 1
Chain-return-error TRUE
Chain-idassert-bind bindmethod=“simple”
binddn={REDACTED}
credentials={REDACTED}
Chain-protocol-version 3
chain-uri {REDACTED URI 2}
Chain-cache-uri FALSE
Chain-max-depth 1
Chain-return-error TRUE
Chain-idassert-bind bindmethod=“simple”
binddn={REDACTED}
credentials={REDACTED}
Chain-protocol-version 3
chain-uri {REDACTED URI 3}
Chain-cache-uri FALSE
Chain-max-depth 1
Chain-return-error TRUE
Chain-idassert-bind bindmethod=“simple”
binddn={REDACTED}
credentials={REDACTED}
Chain-protocol-version 3
After the conversion to cn=config:
dn: olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {1}chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE
dn: olcDatabase={0}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: ldaps starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={1}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: “{REDACTED URI 1}“
olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/
cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={2}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {2}ldap
olcDbURI: “{REDACTED URI 2}“
olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/
cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={3}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {3}ldap
olcDbURI: “{REDACTED URI 3}“
olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/
cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
I am wondering if the following is causing the segfaults:
When setting up the configs during the slapd.d conversion, the slapd.conf -> cn=config converter added an extra unnecessary entry for the chain config (there are 4 ldap proxy entries instead of 3). This particular entry that was added does not have an olcDbURI value. Since the referral string is set by the olcDbURI attribute value the missing value results in NULL being set for ref.
However, I have not yet been able to manually trigger the segfault by invoking ppolicy.
I also found a red hat ticket that seemd to detail the same issue (see https://bugzilla.redhat.com/show_bug.cgi?id=1644654).
Any ideas on this? I can also obtain a trace of all the threads if needed.
Jeremy
--
Jeremy Diaz
Rex Consulting, Inc
5652 Florence Terrace, Oakland, CA 94611
email: jeremy.diaz(a)rexconsulting.net
web: [ http://www.rexconsulting.net/ | http://www.rexconsulting.net ]
phone, toll-free: +1 (888) 403-8996 EXT: 5
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited.
Rex Consulting, Inc. has been a California Corporation since 2001.
4 years, 10 months
Re: SSL handshake failure
by Rich Megginson
On 02/29/2012 01:29 PM, Bryce Powell wrote:
> I managed to get this working, mostly by following directions in:
> http://www.openldap.org/doc/admin24/tls.html
> http://www.openldap.org/faq/data/cache/1514.html
>
> Note that these steps work for my combination of OS and OpenLDAP package, as detailed in my initial posting.
>
> My server and CA certificates were in PEM format, along with a password protected private key:
>
> cso_root_ca.pem
> cso_functional_ca.pem
> cso_issuing_ca.pem
> FQHostName.cert.pem
> FQHostName.cert.keysecure.pem
>
> * Decrypt the private key:
> openssl rsa -in FQHostName.keysecure.pem -out FQHostName.key.pem
>
> When prompted, enter the pass phrase for the private key.
>
> * Convert the server cert/key pair to PKCS format:
> openssl pkcs12 -export -inkey FQHostName.key.pem -in FQHostName.cert.pem -out FQHostName.cert.p12 -nodes -name 'FQHostName'
>
> When prompted, enter a blank Export Password by hitting ENTER.
>
> * Create the certutil certificate database:
> certutil -N -d /etc/openldap/cacerts
>
> When prompted, enter a new password for the key database.
>
> * Remove the key database password:
> certutil -d /etc/openldap/cacerts -W
>
> When prompted, enter the current password for the key database.
> e.g. Enter Password or Pin for "NSS Certificate DB":
>
> When prompted, press ENTER to specify a blank new password.
> Enter new password:
> Re-enter password:
> Password changed successfully.
>
> * Import the CA chain:
> certutil -A -d /etc/openldap/cacerts -n "CSO Root CA" -t CT,, -a -i cso_root_ca.pem
> certutil -A -d /etc/openldap/cacerts -n "CSO Functional CA" -t CT,, -a -i cso_functional_ca.pem
> certutil -A -d /etc/openldap/cacerts -n "CSO Issuing CA" -t CT,, -a -i cso_issuing_ca.pem
>
> * Add the server certificate/key pair:
> pk12util -i FQHostName.cert.p12 -d /etc/openldap/cacerts
>
> When prompted, enter blank password by pressing ENTER.
>
> * list all the certificates, to confirm the imports:
> certutil -d /etc/openldap/cacerts -L
>
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
>
> FQHostName u,u,u
> CSO Root CA CT,,
> CSO Functional CA CT,,
> CSO Issuing CA CT,,
>
>
> * Ensure the correct permissions and ownership are set:
> ll /etc/openldap/cacerts
>
> -rw-r-----. 1 root ldap 65536 Feb 28 11:44 cert8.db
> -rw-r-----. 1 root ldap 16384 Feb 28 11:44 key3.db
> -rw-r-----. 1 root ldap 16384 Feb 24 15:46 secmod.db
>
> chmod and/or chown as necessary.
>
> * modify /etc/openldap/slapd.conf (I'm not using cn=config as defined in the slapd folder):
> TLSCACertificatePath /etc/openldap/cacerts
> TLSCertificateFile FQHostName
>
> Note that the certificate file specified above is the name of the server certificate 'Nickname' (the certificate Common Name) in the NSS certificate database.
> As a result, the following warning will be displayed after a slapd restart:
>
> $ sudo service slapd restart
> Stopping slapd: [ OK ]
> FQHostName is not readable by "ldap" [WARNING]
> Starting slapd: [ OK ]
>
> I believe this WARNING can safely be ignored. The OpenLDAP documentation for the TLSCertificateFile setting states:
> "When using Mozilla NSS, if using a cert/key database (specified with TLSCACertificatePath), this directive specifies the name of the certificate to use."
>
> I suspect there is still some code that is looking for the existence of an actual certificate file, and is not looking in the cert/key database.
Right. Just to be clear - this has nothing to do with openldap software
- it is purely a redhat/fedora thing. And you are correct, you can
ignore the warning.
>
> * Modify the ldap.conf file:
> TLS_CACERTDIR /etc/openldap/cacerts
>
> * Test connectivity using TLS:
> $ ldapsearch -x -ZZ -H ldap://FQHostName
>
> The ldap log file should contain entries that indicate a successful TLS connection:
>
> Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 STARTTLS
> Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 RESULT oid= err=0 text=
> Feb 28 14:18:21 HostName slapd[18833]: conn=1016 fd=26 TLS established tls_ssf=256 ssf=256
>
> Or,
> $ ldapwhoami -x -ZZ -H ldap://FQHostName
> anonymous
>
> Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 STARTTLS
> Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 RESULT oid= err=0 text=
> Feb 28 14:31:48 HostName slapd[18833]: conn=1017 fd=42 TLS established tls_ssf=256 ssf=256
>
>
>
>
> -----Original Message-----
> From: Rich Megginson [mailto:rich.megginson@gmail.com]
> Sent: February 23, 2012 4:12 PM
> To: Bryce Powell
> Cc: openldap-technical(a)openldap.org
> Subject: Re: SSL handshake failure
>
> On 02/23/2012 04:36 PM, Bryce Powell wrote:
>> Thanks, Howard. Would you know how I can find a suitable package that uses openssl?
>>
>> I also tried moving the CA certificate chain file to the /etc/openldap/cacerts/ folder, splitting the file into 3 separate certificates, and running c_rehash to generate the hashed links. After modifying ldap.conf to use the cacerts folder instead of the ca file:
>>
>> TLS: file cso_root_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
>> TLS: loaded CA certificate file /etc/openldap/cacerts/5de054ac.0 from CA certificate directory /etc/openldap/cacerts.
>> TLS: loaded CA certificate file /etc/openldap/cacerts/241dd1a5.0 from CA certificate directory /etc/openldap/cacerts.
>> TLS: loaded CA certificate file /etc/openldap/cacerts/95df54c4.0 from CA certificate directory /etc/openldap/cacerts.
>> TLS: file cso_functional_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
>> TLS: file cso_issuing_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
>> TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
>> TLS: can't connect: TLS error -5938:Encountered end of file.
>> ldap_err2string
>> ldap_start_tls: Connect error (-11)
>> additional info: TLS error -5938:Encountered end of file
>>
>> So I guess I'm stuck until I compile from scratch using openssl, or find a package that doesn't use Mozilla NSS.
> If you want to try to get it working with Mozilla NSS, I'm here to help.
> Can you provide the output from running the server with the -d 1 arguments?
>> Thanks
>>
>> -----Original Message-----
>> From: Howard Chu [mailto:hyc@symas.com]
>> Sent: February 23, 2012 1:04 PM
>> To: Bryce Powell
>> Cc: openldap-technical(a)openldap.org
>> Subject: Re: SSL handshake failure
>>
>> Bryce Powell wrote:
>>> Hi,
>>> I can't get slapd to respond successfully to TLS or SSL connections using an
>>> RSA 2048-bit PEM certificate:
>> You're using Mozilla NSS, so the fact that OpenSSL tools accept your cert
>> doesn't help you.
>>
>> While a lot of good work has gone into the Mozilla NSS support, I would still
>> say the MozNSS design is braindead and is not well suited for anything besides
>> the Netscape/Mozilla browser codebase and should be avoided. Rebuild OpenLDAP
>> using OpenSSL and I suspect these problems will disappear.
>>
>>> $ ldapsearch -x -ZZ -d1 -H ldap://FQDNhostname
>>> TLS: loaded CA certificate file /etc/openldap/cacerts/FQDNhostname.cacert.pem.
>>> TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
>>> TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
>>> TLS: can't connect: TLS error -5938:Encountered end of file.
>>> ldap_err2string
>>> ldap_start_tls: Connect error (-11)
>>> additional info: TLS error -5938:Encountered end of file
>>> $ openssl s_client -connect FQDNhostname:636 -CAfile
>>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>>> CONNECTED(00000003)
>>> 140457427965768:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>> failure:s23_lib.c:184:
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 0 bytes and written 113 bytes
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> ---
>>> The following packages are installed on CentOS 6.2:
>>> openldap-servers-2.4.23-20.el6.x86_64
>>> openldap-2.4.23-20.el6.x86_64
>>> openldap-clients-2.4.23-20.el6.x86_64
>>> openssl-1.0.0-20.el6_2.1.x86_64
>>> openssl-devel-1.0.0-20.el6_2.1.x86_64
>>> gnutls-2.8.5-4.el6.x86_64
>>> gnutls-devel-2.8.5-4.el6.x86_64
>>> nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64
>>> The /etc/openldap/ldap.conf file contains:
>>> TLS_CACERT /etc/openldap/cacerts/FQDNhostname.cacert.pem
>>> , which contains a chain of three certificates (root CA,
>>> intermediate/functional, and issuing).
>>> The /etc/openldap/slapd.conf file contains:
>>> TLSCipherSuite HIGH:+SSLv3
>>> TLSCertificateFile /etc/openldap/FQDNhostname.cert.pem
>>> TLSCertificateKeyFile /etc/openldap/FQDNhostname.key.pem
>>> The server is acting as a proxy to an Active Directory, and therefore I only
>>> have one LDAP database defined. My intention is to use LDAPS for communication
>>> between the client and LDAP proxy servers:
>>> database ldap
>>> suffix "dc=abc,dc=local"
>>> rebind-as-user
>>> uri "ldap://IPaddress1/ ldap://IPaddress2/ ldap://IPaddress3/ ldap://IPaddress4/"
>>> chase-referrals yes
>>> noundeffilter yes
>>> use-temporary-conn yes
>>> The certificate and private key are located in /etc/openldap/, with the
>>> following permissions :
>>> -r--r-----. 1 ldap ldap 2076 Feb 21 15:30 FQDNhostname.cert.pem
>>> -r--r-----. 1 ldap ldap 1675 Feb 21 15:35 FQDNhostname.sdi.key.pem
>>> The CN of the certificate matches the FQDN host name of the LDAP server.
>>> The private key is not password protected.
>>> Everything checks out OK by testing the certificate using openssl:
>>> $ openssl verify -purpose sslserver -CAfile
>>> /etc/openldap/cacerts/FQDNhostname.cacert.pem /etc/openldap/FQDNhostname.cert.pem
>>> /etc/openldap/FQDNhostname.cert.pem: OK
>>> OpenSSL client/server connections work fine too:
>>> openssl s_server -cert /etc/openldap/FQDNhostname.cert.pem -key
>>> /etc/openldap/FQDNhostname.key.pem -cipher 'HIGH:+SSLv3
>>> openssl s_client -connect FQDNhostname:4433 -CAfile
>>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>>> *Bryce Powell*
12 years, 9 months
Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Robert Heller
At Thu, 28 Sep 2017 22:21:51 -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote:
>
>
>
> SSSD should be configured to bind TLS with ldap:389 not ldaps:636.
> Increase SSSD log verbosity to get more information. I have also found
> that slapd logging can help determine bind issues.
Slapd is just loging a TLS negotiation failure and I don't know how to get
slapd to be more specific.
● slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2017-09-29 10:45:02 EDT; 12min ago
Docs: man:slapd
man:slapd-config
man:slapd-hdb
man:slapd-mdb
file:///usr/share/doc/openldap-servers/guide.html
Process: 20310 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
Process: 20271 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS)
Main PID: 20312 (slapd)
CGroup: /system.slice/slapd.service
└─20312 /usr/sbin/slapd -u ldap -h ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:/// -s 30
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1010 sd=13 for close
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1010 fd=13 closed (TLS negotiation failure)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 fd=13 ACCEPT from IP=192.168.250.98:47692 (IP=192.168.250.98:389)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 op=0 STARTTLS
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 op=0 RESULT oid= err=0 text=
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1011 sd=13 for close
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: conn=1011 fd=13 closed (TLS negotiation failure)
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:52:31 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 fd=13 ACCEPT from IP=192.168.250.98:47694 (IP=192.168.250.98:389)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 op=0 STARTTLS
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 op=0 RESULT oid= err=0 text=
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1012 sd=13 for close
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1012 fd=13 closed (TLS negotiation failure)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 fd=13 ACCEPT from IP=192.168.250.98:47696 (IP=192.168.250.98:389)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 op=0 STARTTLS
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 op=0 RESULT oid= err=0 text=
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1013 sd=13 for close
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: conn=1013 fd=13 closed (TLS negotiation failure)
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:53:55 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 fd=13 ACCEPT from IP=192.168.250.98:47698 (IP=192.168.250.98:389)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 op=0 STARTTLS
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 op=0 RESULT oid= err=0 text=
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1014 sd=13 for close
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1014 fd=13 closed (TLS negotiation failure)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 fd=13 ACCEPT from IP=192.168.250.98:47700 (IP=192.168.250.98:389)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 op=0 STARTTLS
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 op=0 RESULT oid= err=0 text=
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1015 sd=13 for close
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: conn=1015 fd=13 closed (TLS negotiation failure)
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:55:01 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 fd=13 ACCEPT from IP=192.168.250.98:47702 (IP=192.168.250.98:389)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 op=0 STARTTLS
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 op=0 RESULT oid= err=0 text=
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 busy
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1016 sd=13 for close
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1016 fd=13 closed (TLS negotiation failure)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: listen=9, new connection on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: added 13r (active) listener=(nil)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 fd=13 ACCEPT from IP=192.168.250.98:47704 (IP=192.168.250.98:389)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 2 descriptors
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: do_extended: oid=1.3.6.1.4.1.1466.20037
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 op=0 STARTTLS
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 op=0 RESULT oid= err=0 text=
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: 13r
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: read active on 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_get(13)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: connection_closing: readying conn=1017 sd=13 for close
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: removing 13
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: conn=1017 fd=13 closed (TLS negotiation failure)
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on 1 descriptor
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: activity on:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]:
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=8 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=10 active_threads=0 tvp=NULL
Sep 29 10:56:30 c764guest.deepsoft.com slapd[20312]: daemon: epoll: listen=11 active_threads=0 tvp=NULL
SSSD is just saying it is unable to get information from the provider (I'm
guessing slapd).
I am just about to give up on SSSD. As far as I can tell, it just does not
work. I don't think I really need SSSD for anything. It sounds like
nslcd/nss_pam_ldap will do what I need to do. CentOS7 / RHEL7 comes with SSSD
as the default, so somehow I need to get rid of it. I actually installed
nss_pam_ldap and it is in fact running, but I am guess it is not being used.
I guess I need to figure out the "magic" for authconfig to shove sssd out of
the way....
>
> How does one estalish their own CA that's trusted by other Root CA's?
> Perhaps try disabling verification of the chain then see if bind happens.
>
> On Sep 28, 2017 9:14 PM, "Robert Heller" <heller(a)deepsoft.com> wrote:
>
> > At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com>
> > wrote:
> >
> > >
> > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller
> > > <heller(a)deepsoft.com> wrote:
> > >
> > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <
> > quanah(a)symas.com>
> > > > wrote:
> > > >
> > > >>
> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
> > > >> <heller(a)deepsoft.com> wrote:
> > > >>
> > > >>
> > > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to
> > connect
> > > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I
> > guess
> > > >> > something is wrong with slapd's TLS configuration -- it is failing
> > to
> > > >> > do TLS Negotiation, either it is just not doing it or it is doing
> > it
> > > >> > wrong (somehow). Unless SSSD is not configured properly.
> > > >>
> > > >> You need to start with the following:
> > > >>
> > > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
> > > >>
> > > >> to test startTLS
> > > >>
> > > >> and
> > > >>
> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
> > > >>
> > > >> to test without startTLS
> > > >>
> > > >> If you can get those to work, then you can move on to SSSD.
> > > >
> > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D
> > > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11)
> > > > additional info: TLS error -8157:Certificate extension not
> > found.
> > >
> > > This may be of help:
> > > <https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__serverfault.com_questions_640910_my-2Dcertificate-
> > 2Ddoesnt-2Dwork-2Don-2Dall-2Dmachines&d=DwIBAg&c=
> > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-
> > CbhH6xUjnRkaqPFUS2wTJ2cw&m=fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=
> > h0ZJ27HydY4c7iw8uXd-1iadz94M-ZzNGL7KMfOsi2w&e=>
> > >
> > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D
> > > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password:
> > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> > >
> > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard
> > > to know for sure). It may also simply be a different manifistation of
> > the
> > > error above.
> >
> > I added a -d option (picked 10), and discovered that it wanted the full
> > name
> > as specificed in the certificate. That fixed ldapwhoami and I put that in
> > ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving
> > (samba
> > is though, mostly -- it might also be having issues since sssd is not
> > working)...
> >
> > >
> > > --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=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9-
> > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=4Jyip-
> > C583CeHTI2N1wXllUKzrjwwvY9tqyl3tZVq8w&e=>
> > >
> > >
> >
> > --
> > Robert Heller -- 978-544-6933
> > Deepwoods Software -- Custom Software Services
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.
> > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9-
> > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=
> > fNmr-KFWiEhP0yGMfSAsdSa6NOnIS_lb6cSsPujmQZ8&s=hf9o7fTr6iLSDpsS6xK6nGDWhZo-
> > N7aXcKoRAXfrPUE&e= -- Linux Administration Services
> > heller(a)deepsoft.com -- Webhosting Services
> >
> >
> >
>
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller(a)deepsoft.com -- Webhosting Services
7 years, 1 month
slapd on an interface alias
by Ulrich Windl
Hi!
I had sent a request for documentation to the ITS, because I feel that something is wrong with OpenLDAP 2.4.26 (as shipped with SLES11 SP2), but I was redirected:
I wrote:
> Full_Name: Ulrich Windl
> Version: 2.4.26
> OS: Linux (SLES11 SP2)
[...]
>
>
> I was able to set up a master LDAP server and a replication consumer using the
> physical host names and TLS. However when I tried to bind slapd on a virtual IP
> address ("interface alias"), I never got slapd working (even though I fixed the
> certificates for TLS, of course). Dynamic configuration ("cn=config") seems to
> make things very difficult, because slapd ends in a state where _nobody_ can
> make configuration changes.
Use the openldap-technical mailing list to ask for configuration help.
You talk about IP addresses and yet in your quoted text below you are using
hostnames. Be consistent when you post your question to the mailing list
otherwise no one will understand what you're asking for.
--> Obviously slapd listens to ports, not to names, and names were invented so that people don't have to remember IP addresses, but you know.
--> Only with X.509 certificates the relation between names and adresses are of some inportance, but you can believe me that I understand that.
Closing this ITS.
> It seems slapd tried to use the wrong URI (using the physical host where nobody
> is listening):
> slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error,
> ldap_start_tls failed (-1)
> slapd[10036]: do_syncrepl: rid=002 rc -1 retrying
>
> slapd is listening on ldap://vhost.domain.org/ however.
--> You should believe me if I say so.
>
> I read lots of procedures using Google, but could not find the solution for this
> problem. Thus I suggest to add documentation how to configure such a scenario:
>
> 1) Set up an LDAP Master server that provides service on a specific IP address
> using TLS
> 2) Set up a replication consumer that provides service on a specific IP address
> using TLS also
> 3) The replication consumer should use the address where the master server
> listens for replication
>
> It sounds like an every-day setup, but I failed multiple times, thus the request
> for documentation.
>
Still waiting for a procedure. Something seems to be non-obvious or broken.
Some details (randomly picked, with some names obfuscated):
(master server)
olcSyncrepl: {0}rid=2 provider="ldap://v07.domain.org/"
searchbase="dc=domain,dc=org" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=domain,dc=org" credent ials="wNkWudLd3ko8"
The process is started as "/usr/lib/openldap/slapd -h ldap://ds1.domain.org:389 ldaps://ds1.domain.org:636 ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off"
And syslog message sI'm seeing over and over are like this:
Jul 5 08:23:16 v07 slapd[25914]: slap_client_connect: URI=ldap://v07.domain.org/ Error, ldap_start_tls failed (-1)
Jul 5 08:23:16 v07 slapd[25914]: do_syncrepl: rid=002 rc -1 retrying
Obviously a connection to the "v07" address is not possible, because the server listens to the "ds1" address. The interface settings look like this:
eth0 Link encap:Ethernet HWaddr 00:16:3E:5C:DD:76
inet addr:172.20.16.38 Bcast:172.20.17.255 Mask:255.255.254.0
inet6 addr: fe80::216:3eff:fe5c:4d76/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6334378 errors:0 dropped:6 overruns:0 frame:0
TX packets:237667 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:421369553 (401.8 Mb) TX bytes:49452419 (47.1 Mb)
eth0:ds1 Link encap:Ethernet HWaddr 00:16:3E:5C:DD:76
inet addr:172.20.17.200 Bcast:172.20.17.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Basically I think I have to fix the "olcSyncrepl provider" and possibly the "olcServerID", but with dynamic configuration I cannot do it:
Using ldapmodify I get:
v07:~ # ldapmodify -v -ZZ -x -W -D cn=config -H ldap://ds1.domain.org -f /tmp/fix1.ldif
ldap_initialize( ldap://ds1.domain.org:389/??base )
Enter LDAP Password:
replace olcServerID:
1 ldap://ds1.domain.org
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
When editing the files in the slap.d directory, I get:
Jul 5 09:11:25 v07 slapd[15014]: @(#) $OpenLDAP: slapd 2.4.26 (Sep 26 2012 13:21:45) $ abuild@e71:/usr/src/packages/BUILD/openldap-2.4.26/servers/slapd
Jul 5 09:11:25 v07 slapd[15014]: ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif"
Jul 5 09:11:25 v07 slapd[15014]: ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif"
Jul 5 09:11:25 v07 slapd[15015]: hdb_monitor_db_open: monitoring disabled; configure monitor database to enable
Jul 5 09:11:25 v07 slapd[15015]: slapd starting
Jul 5 09:11:25 v07 slapd[15015]: slap_client_connect: URI=ldap://ds1.domain.org/ DN="uid=syncrepl,ou=system,dc=domain,dc=org" ldap_sasl_bind_s failed (49)
Jul 5 09:11:25 v07 slapd[15015]: do_syncrepl: rid=002 rc 49 retrying
Jul 5 09:11:25 v07 slapd[15015]: slap_client_connect: URI=ldap://ds1.domain.org/ DN="uid=syncrepl,ou=system,dc=domain,dc=org" ldap_sasl_bind_s failed (49)
Jul 5 09:11:25 v07 slapd[15015]: do_syncrepl: rid=001 rc 49 retrying
Jul 5 09:12:37 v07 nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
(So obviously the syncrepl provider has changed, but it still won't work)
Regards,
Ulrich
11 years, 4 months
additional info: objectClasses: value #0 invalid per syntax
by Jimmy Royer
Hello,
I am starting out with openldap and I don't know it that much. I got
the error mentioned in the title when trying to add an object class,
which is apparently a very common one per my google searches. I've
read that common causes are:
* extraneous white space (especially trailing white space)
* improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
* empty values (few syntaxes allow empty values)
This is the object class file I am trying to add, I picked it as an
example on some website, to have something minimal and make it easier
to test:
# cat exObjectClasses.ldif
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.2.9
NAME 'blogger'
DESC 'Someone who has a blog'
SUP inetOrgPerson STRUCTURAL
MAY blog )
I've checked if there was any trailing spaces at the end with the following:
# cat -vte exObjectClasses.ldif
dn: cn=schema$
changetype: modify$
add: objectClasses$
objectClasses: ( 2.16.840.1.113730.3.2.2.9$
NAME 'blogger'$
DESC 'Someone who has a blog'$
SUP inetOrgPerson STRUCTURAL$
MAY blog )$
I've made sure the file is UTF-8:
# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
And I don't think there are any empty values defined in the LDIF file.
So when I type this command, I still have the "invalid per syntax
error:
# ldapmodify -x -W -H "ldaps://127.0.0.1" -D
cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif
Enter LDAP Password:
modifying entry "cn=schema"
ldap_modify: Invalid syntax (21)
additional info: objectClasses: value #0 invalid per syntax
This is the content of the /etc/openldap/slapd.conf file:
# cat slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by running
# /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk
# at self-signed certificates, however.
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile "\"OpenLDAP Server\""
TLSCertificateKeyFile /etc/openldap/certs/password
# 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!
# enable on-the-fly configuration (cn=config)
database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
manage
by * none
# enable server status monitoring (cn=monitor)
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
read
by dn.exact="cn=Manager,dc=my-domain,dc=com" read
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=modelsolv,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=modelsolv,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw SECRET
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
I was able to add a few entries in LDAP so far. So I know I am able to
reach the server, the connection is fine, and LDAP is somewhat
functional. But I can't modify the schema with objectclasses.
Is there anything obvious that I am doing wrong? Do you have any
recommendation for debugging further?
Regards,
Jimmy Royer
11 years, 8 months
Re: Slapd Security based on port
by Chris Jackson
On Feb 16, 2011, at 3:46 AM, <harry.jede(a)arcor.de>
<harry.jede(a)arcor.de> wrote:
> Chris Jackson wrote:
>> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
>>
>> Is it possible to prevent anonymous and unauthenticated binds to
>> ldaps:// 636 but allow them on ldap:// 389?
>>
>> I want to allow staff to query my ldaps:// outside of my network
>> while requiring them to login to do so but allow anyone to bind
>> (anonymous, unauthenticated, or authenticated) internally on ldaps//:
>> 389.
>>
>> I know:
>> Anonymous bind can be disabled by "disallow bind_anon" and
>> Unauthenticated bind mechanism is disabled by default. But if I use
>> "disallow bind_anon it stops in on both ports.
> Sure, this are global directives.
>
>> I want to stop it just on ldaps://.
> You don't need ldaps:// in your local network? May be.
> I think a easier solution is to identify your Internet Gateway by IP.
>
>> Chris Jackson
>>
>>
>> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
>>
>> Stopping users that are "unauthenticated" makes no sense;
>> everything's unauthenticated at time=0. You might as well stop slapd
>> if you want a 100% inability to serve data.
>>
>> You can deny anonymous users that aren't plaintext, including any
>> ldaps:/// connections, with something like:
>>
>> access to *
>> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
>> by anonymous none
>>
>> early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
>> StartTLS users on 389, though; not sure if that's what you want. I
>> can't think of any way to use the slapd access language to
>> differentiate based on listeners, which would probably be the most
>> elegant way to handle what you asked. To be fair, this entire
>> exercise seems really odd from where I sit -- are you positive that
>> this will have the desired effect? (If somebody out in Peru is
>> permitted to connect in unencrypted and make anonymous queries, why
>> not allow them to make those same queries encrypted? What's the
>> difference?)
>>
>> here is a scenario:
>>
>> Site has a ldap server on ldap://389. Firewall blocks access to 389
>> from internet. Everyone queries the ldap via anonymous binds. Site
>> would like to allow staff the ability to query the ldap from outside
>> the firewall. This would be done via ldaps:// 636 to users who have
>> authenticated via username/password. They do not want to allow
>> anonymous queries outside the firewall.
>>
>> Using the "disallow bind_anon" would prevent anon binds on both
>> ldap:// and ldaps://. This would break the inside machines ability
>> to query. If we dont use "disallow bind_anon" then machines outside
>> of the firewall could query the ldap.
>>
>> ---Is the only option for them to setup two separate ldap servers?
> No. You should use ACLs to solve this problem. Read man slapd.access
> an/or search the openldap archives.
>
> Assuming you have a NAT gatway as Firewall machine.
>
> Replace all "by anonymous" statements with these 6 statements:
>
> by anonymous auth continue
> by peername.ip="127.0.0.1" read continue
> by peername.ip="10.0.0.0%255.0.0.0" read continue
> by peername.ip="172.16.0.0%255.240.0.0" read continue
> by peername.ip="192.168.0.0%255.255.0.0" read continue
> by peername.ip="gateway-ip" auth
>
> One may write these statements more effective, but in general they will
> do.
>
>
> Replace "gateway-ip" with yours.
>
> Put the above statements also in every ACL just before the
> by *
> when this ACL do NOT have an "by anonymous" statement.
>
> Maybe the last line could/should be:
> by ssf=56 peername.ip="gateway-ip" auth
>
> Caveats:
> Your gateway can no longer access your LDAP Server with
> the "gateway-ip". But this is a Firewall Design Question.
>
> I've tested this only with unencrypted sessions; anoymous and
> authenticated. But TLS or SSL will not grant more rights, if you do not
> tell the ACLs to do so.
>
>
> Here the output from the two searches:
>
> # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
> Insufficient access (50)
>
> # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
> cn=admin,dc=kronprinz,dc=xx -W
> dn: dc=kronprinz,dc=xx
>
> dn: cn=admin,dc=kronprinz,dc=xx
>
>> One with "disallow bind_anon" and one without. Then only open the
>> firewall for port 636 to the ldap server which has "disallow
>> bind_anon".
>>
>> Chris Jackson
>
>
>
> --
>
> Harry Jede
The above example got me started in the right direction. Everything appears to be doing exactly what I wanted to do. I did notice that the anonymous bind users from ip addresses not 10, give an error 32. Anyone see any flaws in this?
The below ACL should be allowing anon binds when ip address is 10.*.*.* or allow authenticated binds from any ip address.
access to attrs=userpassword
by anonymous auth
by self read
by * none
access to *
by anonymous auth continue
by users read
by peername.ip="10.0.0.0%255.0.0.0" read
by * none
Chris
13 years, 9 months