Made a change to cn=schema,cn=config, can't revert?
by Sander Smeenk
Hi,
I'm trying to add an 'olcAttributeType' to an already existing LDAP
schema. I wrote this LDIF, which was wrong as it turns out:
| dn: cn=schema,cn=config
| changetype: modify
| add: olcAttributetypes
| olcAttributetypes: ( bitHttpAttribute:26.2008.07.29.1 NAME
| 'testEntry' DESC 'Test' EQUALITY integerMatch SYNTAX
| LDAPInteger SINGLE-VALUE )
This changed my 'dn: cn=schema,cn=config' from:
| dn: cn=schema,cn=config
| objectClass: olcSchemaConfig
| cn: schema
| structuralObjectClass: olcSchemaConfig
| entryUUID: 9faa0e66-41f5-1032-82e1-974d55020d34
| creatorsName: cn=config
| createTimestamp: 20130425131311Z
| entryCSN: 20130425131311.204787Z#000000#000#000000
| modifiersName: cn=config
| modifyTimestamp: 20130425131311Z
To:
| dn: cn=schema,cn=config
| objectClass: olcSchemaConfig
| cn: schema
| structuralObjectClass: olcSchemaConfig
| entryUUID: 9faa0e66-41f5-1032-82e1-974d55020d34
| creatorsName: cn=config
| createTimestamp: 20130425131311Z
| olcAttributeTypes: {0}( bitHttpAttribute:26.2008.07.29.1 NAME
| 'testEntry' DESC 'Test' EQUALITY integerMatch SYNTAX
| LDAPInteger SINGLE-VALUE )
| entryCSN: 20220525132055.795116Z#000000#000#000000
| modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
| modifyTimestamp: 20220525132055Z
Which is not what i wanted but it happened, so now i want it gone.
But it seems i can't remove that olcAttributeTypes entry?
This LDIF won't work:
| dn: cn=schema,cn=config
| changetype: modify
| delete: olcAttributeTypes
Yielding:
| # ldapmodify -Y EXTERNAL -H ldapi:/// -f kak.ldif
| [..]
| modifying entry "cn=schema,cn=config"
| ldap_modify: Other (e.g., implementation specific) error (80)
When i put in the exact olcAttributeType line i want to remove (instead
of all of 'em) like this:
| dn: cn=schema,cn=config
| changetype: modify
| delete: olcAttributeTypes
| olcAttributeTypes: ( bitHttpAttribute:26.2008.07.29.1 NAME 'testEntry' DESC 'Test' EQUALITY integerMatch SYNTAX LDAPInteger SINGLE-VALUE )
Now the same ldapmodify command yields:
| # ldapmodify -Y EXTERNAL -H ldapi:/// -f kak.ldif
| [..]
| modifying entry "cn=schema,cn=config"
| ldap_modify: Operations error (1)
Can anyone explain what i am doing wrong and how to revert my change
to the 'cn=schema,cn=config' dn?
Thanks a bunch!
Regards,
-Sander.
--
| I did a theatrical performance about puns. It was a play on words.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
3 days, 8 hours
consumer state is newer than provider
by Rallavagu Kon
Hello All,
Running OpenLDAP version 2.4.58 on Ubuntu 20.04 in multicaster mode.
Replication Configuration:
olcSyncrepl: {0}rid=101 provider=ldaps://<host1>:10636 binddn="<binddn>" bindm
ethod=simple credentials=<creds> searchbase="dc=company,dc=com" type
=refreshAndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive=
"240:10:30"
olcSyncrepl: {1}rid=102 provider=ldaps://<host2>:10636 binddn="<binddn>" bindm
ethod=simple credentials=<creds> searchbase="dc=company,dc=com" type
=refreshAndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive=
"240:10:30"
olcSyncrepl: {2}rid=103 provider=ldaps://<host3>:10636 binddn="<binddn>" bindm
ethod=simple credentials=<creds> searchbase="dc=company,dc=com" type
=refreshAndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive=
"240:10:30"
olcSyncrepl: {3}rid=104 provider=ldaps://<host4>:636 binddn="<binddn>" bindmethod=si
mple credentials=<creds> searchbase="dc=company,dc=com" type=refresh
AndPersist interval=00:00:00:30 retry="5 5 60 +" timeout=1 keepalive="240:10:
30"
olcMirrorMode: TRUE
# {1}syncprov, {2}mdb, config
dn: olcOverlay={1}syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 100 10
Under normal conditions, all operations perform normally in terms of replication consistency. However, when performing a stream of “ADD” operations eventually producer/consumer go out of sync where consumer thinks it has latest state than producer. All the write operations including ADD are pointed to a producer node (not load balancing the writes). Introduced 30 second delay to “ADD” operations (for the sake of testing) and experiencing the same behavior. The issue is manifesting after adding around 4k entries (sometimes even sooner).
Here are the log snippets.
May 4 23:06:47 openldap-service-0 slapd[199]: do_syncrep2: rid=102 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
May 4 23:06:47 openldap-service-0 slapd[199]: do_syncrep2: rid=102 (53) Server is unwilling to perform
May 4 23:06:37 openldap-service-1 slapd[199]: conn=1046 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider!
Checked for the clock synchronization and verified that all instances have NTP enabled. Wondering where and what I should be looking for.
Thanks in advance.
4 days, 12 hours
dynlist vs memberof performance issues
by Mark Cairney
Hi,
I've been out the LDAP loop for a bit but the recent discussion of the
memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
removed the memberof elements from the database and replaced the
memberof overlay with dynlist the queries appear to work as expected but
are both a) slow and b) heavily CPU-intensive on the LDAP server.
2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738
(IP=129.215.17.9:636)
2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256
tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms
2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014
etime=0.000214 nentries=1 text=
2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 BIND dn="" method=163
2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030
etime=0.009084 text=SASL(0): successful result:
2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 BIND dn="" method=163
2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031
etime=0.000181 text=SASL(0): successful result:
2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND dn="" method=163
2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK"
authzid="mcairney(a)EASE.ED.AC.UK"
2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND
dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk"
mech=GSSAPI bind_ssf=256 ssf=256
2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024
etime=0.000409 text=
2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH
base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0
filter="(uid=mcairney)"
2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH attr=* +
2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=5 UNBIND
2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031
etime=13.233679 nentries=1 text=
2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 closed
I'm guessing that as the values are computed that this will be heavier
on the CPU but it seems a bit excessive? Has anyone else noticed any
similar performance issues?
This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I
guess this could be a factor but there's no io waiting on the server and
no swapping?
The database is on a par in size with our Production service ( about
400K user objects with 1 group object per user and then about 80K actual
groups of users)
The config for the primary DB (ACLs and rootPW redacted) is:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /opt/openldap/var/openldap-data/authorise
olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 2
olcReadOnly: FALSE
olcSecurity: ssf=1
olcSecurity: update_ssf=112
olcSecurity: simple_bind=64
olcSizeLimit: unlimited
olcSyncUseSubentry: FALSE
olcTimeLimit: unlimited
olcMonitoring: TRUE
olcDbEnvFlags: writemap
olcDbEnvFlags: nometasync
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: eduniType eq
olcDbIndex: gecos pres,eq,sub
olcDbIndex: eduniCategory eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: eduniSchoolCode eq
olcDbIndex: eduniIDStatus eq
olcDbIndex: eduniCollegeCode eq
olcDbIndex: eduniOrgCode eq
olcDbIndex: memberOf pres,eq
olcDbIndex: eduniLibraryBarcode pres,eq
olcDbIndex: eduniOrganisation pres,eq,sub
olcDbIndex: eduniServiceCode pres,eq
olcDbIndex: krbName pres,eq
olcDbIndex: eduPersonAffiliation pres,eq
olcDbIndex: eduPersonEntitlement pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: eduniIdmsId pres,eq
olcDbIndex: member pres,eq
olcDbIndex: memberUid pres,eq
olcDbIndex: eduniRefNo pres,eq
olcDbIndex: eduniTitle pres,eq
olcDbIndex: title pres,eq,sub
olcDbIndex: eduniCardNumber pres,eq
olcDbIndex: eduniYearOfStudy eq
olcDbIndex: description pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: aliasedObjectName eq
olcDbIndex: yubiKeyId pres,eq
olcDbIndex: isMemberOf pres,eq
olcDbIndex: hasMember pres,eq
olcDbIndex: proxyAddresses pres,eq,sub
olcDbMaxReaders: 96
olcDbMaxSize: 32212254720
olcDbMode: 0600
olcDbSearchStack: 16
structuralObjectClass: olcMdbConfig
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 02+00:00 00+04:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: olcDynListConfig
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
*******************************/
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
4 days, 15 hours
slapo-syncprov on read-only consumers
by Michael Ströder
HI!
Is it still highly recommended to configure slapo-syncprov on read-only
consumers?
Background:
I have a tier of read-only consumers with "lastbind on" and
slapo-ppolicy configured, but no chaining to the writeable providers
(e.g. no ppolicy_forward_updates). All providers and consumers are 2.6.2.
In case of a simple bind to this read-only consumer it makes local
modification to the user's entry (pwdFailureTime and pwdLastSuccess) and
it's ok for me that this is local to this consumer.
But with slapo-syncprov configured on the consumer slapd generates a new
entryCSN with server ID 0 which results in a contextCSN value with SID
0. This is what I'd like to avoid. Hence my above question.
Ciao, Michael.
1 week
Solution for syncrepl & memberof replacement with non-dynamic group and users
by René Gallati
Hello list,
I have an openldap 2.4.49 (ubuntu 20.04 LTS) server pair running with
syncrepl. I also have memberof overlay activated and during a debug
session found out that this is a no-go. I was debugging a problem where
an user record that is in two groups only shows one memberOf attribute
value whereas other users show the expected amount of memberOf values.
Now I'm looking into replacing the memberof overlay but it appears that
for my use case there is no replacement at all.
dynlist seems made to create dynamic groups or lists respectively but
everything in my DIT is a static group and static users. They are
created by a commercial product and I am unable to add further specific
URL attributes there when new entries are created.
I stumbled upon
https://www.mail-archive.com/openldap-technical@openldap.org/msg26067.html
via google search, but blindly copying the dynlist-attrset merely causes
the slapd to reply with
"/etc/ldap/slapd.conf: line 149: "dynlist-attrset <oc> [uri] <URL-ad>
[[<mapped-ad>:]<member-ad> ...]": unable to find AttributeDescription #0
"member+memberOf@groupOfNames"#012. " on startup and stopping
immediately. I suppose it needs some schema extension but of what I
don't understand and neither will I have a trigger objectClass unless I
could just use inetOrgPerson as trigger and have it work.
Is there a way to get back "synthetic" memberOf entries on static user
records (which are inetOrgPerson) with static groups (which are
groupOfNames) on openldap 2.4.49 without adding any special attributes
into users and/or groups themselves ?
Kind regards,
René
--
rene.gallati(a)ergon.ch
T +41 44 268 83 10
Ergon Informatik AG, Merkurstrasse 43, CH-8032 Zürich
www.ergon.ch
smart people – smart software
* * * * * * * * * * * * * * * * * * * * * * * * *
DELIVERING TECHNOLOGY ADVANTAGE SINCE 1984
1 week, 4 days
changes in own schema in multi provider setup
by Stefan Kania
Good morning,
we having a own schema with a lot of own attributes. We have a multi
provider replication of cn=config. What is the right way to add a new
attribute to our schema and get it into the configuration?
Stefan
1 week, 4 days
Can a Bind result in a Referral?
by Mike Stevens
Good day.
I’m an LDAP novice and am attempting to modify an LDAP client to
accommodate an LDAP server environment that makes use of referrals.
I have installed openLDAP 2.4.44 on 2 RHEL 7.9 servers.
The initial entries in the tree on serverA contains :
# xxx.com
dn: dc=xxx,dc=com
description: xxx.com
dc: xxx
o: xxx.com
objectClass: top
objectClass: dcObject
objectClass: organization
# Users, xxx.com
dn: ou=Users,dc=xxx,dc=com
ou: Users
description: xxx Users
objectClass: organizationalUnit
# search reference
*ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub
<http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub>*
# mike, Users, xxx.com
dn: uid=mike,ou=Users,dc=xxx,dc=com
cn: mike
ou: Users
uid: mike
givenName: Mike
mail: mike(a)uk.xxx.com
objectClass: Person
objectClass: organizationalPerson
objectClass: inetOrgPerson
I believe the "ref" entry is known as a subordinate referral;
it was created by populating the tree from an LDIF file that contained the
following:
dn: dc=uk,dc=xxx,dc=com
objectClass: referral
objectClass: extensibleObject
dc: uk
ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com
The intent is to redirect any requests received by serverA that refer to
the subtree uk.xxx.com to serverB.
The tree on serverB contains:
# xxx.com
dn: dc=xxx,dc=com
description: xxx.com
dc: xxx
o: xxx.com
objectClass: top
objectClass: dcObject
objectClass: organization
# uk.xxx.com
dn: dc=uk,dc=xxx,dc=com
dc: uk
o: uk.xxx.com
description: xxx Users in the UK
objectClass: dcObject
objectClass: organization
# mike, uk.xxx.com
dn: uid=mike,dc=uk,dc=xxx,dc=com
cn: mike
uid: mike
givenName: Mike
mail: mike(a)uk.xxx.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
Now, if I perform a search on serverA specifying a base of uk.xxx.com, I
get an RC=10 Referral result as expected:
[root@serverA ~]# ldapsearch -x '(uid=mike)' -b dc=uk,dc=xxx,dc=com -LL
version: 1
Referral (10)
Matched DN: dc=uk,dc=xxx,dc=com
Referral: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub
... and I can chase that referral using the -C option to retrieve the entry
from serverB:
[root@Mike21 ~]# ldapsearch -x '(uid=mike)' -b dc=uk,dc=ibm,dc=com -LL -C
version: 1
dn: uid=mike,dc=uk,dc=xxx,dc=com
cn: mike
uid: mike
givenName: Mike
mail: mike(a)uk.xxx.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
But, if I attempt a bind to serverA using the user that exists in serverB,
I get an authentication failure:
[root@serverA ~]# ldapsearch -x -b 'dc=uk,dc=xxx,dc=com' -D
uid=mike,dc=uk,dc=xxx,dc=com -w passw0rD
ldap_bind: Invalid credentials (49)
Now, I realise that the failure would be expected as the bind DN doesn't
exist at serverA.
But I read that every request apart from unbind and abandon can result in a
referral.
So why doesn't the bind follow the "ref" to serverB?
Is that possible and have I not configured my server correctly?
Ultimately, what I'd like to do in my client is something like:
ld_user = ldap_init( "ldap://serverA:389/dc=uk,dc=xxx,dc=com" , 0 );
... followed by :
err = ldap_simple_bind_s( ld_user, "uid=mike,dc=uk,dc=xxx,dc=com"
, password);
... and have LDAP authenticate the given user against serverB based on the
referral in serverA.
Is this sort of set up possible?
Many thanks for your advice,
Mike
1 week, 5 days
issues with kqueue on OpenBSD
by Stuart Henderson
I'm working on updating the OpenBSD port of OpenLDAP to 2.6.2 (it's
currently stuck at 2.4.59).
In 2.5 kqueue support was added to slapd for BSDs, but it's not working
correctly on OpenBSD. If slapd runs as a daemon, errors like these are
seen:
slap_client_connect: URI=ldaps://XXX Warning, ldap_start_tls failed (1)
mdb_opinfo_get: err Invalid argument(22)
However if slapd is run in the foreground with -d, things are ok.
They are also OK if kqueue is disabled (by neutering the autoconf check)
so this isn't blocking me updating the port but I thought I'd write up what
I have in case someone has any ideas what might be up or anything they'd
like me to try and report back on.
Here are some log excerpts:
17:23:44.692: slapd starting
17:23:44.692: daemon: added 3r listener=0x0
17:23:44.692: daemon: added 6r listener=0x100263797200
17:23:44.692: daemon: added 7r listener=0x100263785400
17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero
17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero
17:23:44.692: daemon: activity on 1 descriptor
17:23:44.692: daemon: activity on:
17:23:44.692:
17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero
17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero
17:23:44.692: >>> dnNormalize: <cn=Consumer 101>
17:23:44.692: <<< dnNormalize: <cn=consumer 101>
17:23:44.692: =>do_syncrepl rid=101
17:23:44.763: slap_client_connect: URI=ldaps://XXXXXXXXXXXXXXX Warning, ldap_start_tls failed (1)
17:23:44.781: => mdb_entry_get: ndn: "dc=XXXXXXX,dc=XXX"
17:23:44.782: => mdb_entry_get: oc: "(null)", at: "contextCSN"
17:23:44.782: mdb_opinfo_get: err Invalid argument(22)
17:23:44.782: =>do_syncrep2 rid=101
17:23:44.782: daemon: added 9r listener=0x0
17:23:44.783: daemon: activity on 1 descriptor
17:23:44.783: daemon: activity on:
17:23:44.783:
17:23:44.783: daemon: kqueue: listen=6 active_threads=0 tvp=NULL
17:23:44.783: daemon: kqueue: listen=7 active_threads=0 tvp=NULL
17:23:44.800: daemon: activity on 1 descriptor
17:23:44.800: daemon: activity on:
17:23:44.800: 9r
17:23:44.800:
17:23:44.800: daemon: read active on 9
17:23:44.800: daemon: kqueue: listen=6 active_threads=0 tvp=NULL
17:23:44.800: daemon: kqueue: listen=7 active_threads=0 tvp=NULL
17:23:44.800: connection_get(9)
17:23:44.800: connection_get(9): got connid=0
17:23:44.801: =>do_syncrepl rid=101
17:23:44.801: =>do_syncrep2 rid=101
Not sure if it's any help but looking at kdump(1) output after a run
under ktrace(1) I didn't spot the immediate problem resulting in
"ldap_start_tls failed (1)" however the "mdb_opinfo_get: err Invalid
argument(22)" occurs after attempting to call fcntl with F_SETLK on the
fd 5 which is the kqueue fd:
65304 slapd RET write 97/0x61
65304 slapd CALL poll(0x89d39cb9004,1,INFTIM)
65304 slapd STRU struct kevent [2] { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=0, udata=0x231a1bea } { ident=9, filter=EVFILT_EXCEPT, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0x4<>, data=0, udata=0x231a1bea }
65304 slapd STRU struct kevent { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=36, udata=0x231a1bea }
65304 slapd STRU struct pollfd { fd=9, events=0x3<POLLIN|POLLPRI>, revents=0x1<POLLIN> }
65304 slapd RET poll 1
65304 slapd CALL read(9,0x89ccfb103e0,0x5)
65304 slapd GIO fd 9 read 5 bytes
"\^W\^C\^C\0\^_"
65304 slapd RET read 5
65304 slapd CALL read(9,0x89ccfb349c5,0x1f)
65304 slapd GIO fd 9 read 31 bytes
"\M^W\M-r\M-f\M^C\M-2\M^V\M-E\^O\M-hdgq\M-"\M-o\M-&\M^[*\M-9\M^E\M-Sd\M^A2\M-QE\M-cb
|\M^VI"
65304 slapd RET read 31/0x1f
65304 slapd CALL mmap(0,0x2000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
65304 slapd RET mmap 9468564512768/0x89c926ca000
65304 slapd CALL fcntl(5,F_SETLK,0x8ef465d0)
65304 slapd RET fcntl -1 errno 22 Invalid argument
65304 slapd CALL getpid()
65304 slapd RET getpid 65304/0xff18
65304 slapd CALL sendsyslog(0x89c8ef44040,59,0<>)
65304 slapd GIO fd -1 wrote 59 bytes
"<167>slapd[65304]: mdb_opinfo_get: err Invalid argument(22)"
Any suggestions would be welcome.
Thanks!
1 week, 6 days
set LDAPI_SOCK
by Michael Ströder
HI!
I'm trying to get rid of this old patch by Ralf Haferkamp:
https://build.opensuse.org/package/view_file/network:ldap/openldap2/0003-...
Background: Today Linux distros prefer that you place temporary run-time
files in a directory like
/run/<service-name>
with appropriate ownership and permissions. And also systemd can create
a temporary run-time directory on-the-fly and removes it after service
stopped.
But if I e.g. use
configure --runstatedir=/run/slapd
the default pathname of the LDAPI socket is
/run/slapd/run/ldapi
Any way to set LDAPI_SOCK directly during build?
Ciao, Michael.
1 week, 6 days
