openldap-technical September 2020

openldap-technical@openldap.org

34 participants
34 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Index seems to return wrong amount of candidate causing really poor search performance
by chrichardso27＠gmail.com 18 Aug '21

18 Aug '21

Hi, Considering the following assumptions; - OpenLDAP version 2.4.51 - attributes objectClass and abc are indexed based on equality - the EQUALITY of attribute abc is based on distinguishedNameMatch - The database contains roughly 2 million entries - 2 entries have defined the attribute abc with a dn value cn=foo,dc=bar and objectClass=someClass - 2 entries have defined the attribute abc with a dn value cn=bar,dc=baz and objectClass=someClass Now, the issue started with really slow search performance using objectClass=someClass & abc=cn=foo,dc=bar as filter criteria. Debugging a while seems to indicate that the objectClass filter returns roughly 2 million entries as candidates. Now, one would expect that the second filter would return only the 2 potential candidates from the abc index, or a subset of the whole database but this is not the case. The second filter also returns nearly the whole database entries as potential candidates and causes really slow query performance. Interestingly, this only occurs when attribute abc has value cn=foo,dc=bar, but for some reason for the entry having attribute abc with value cn=bar,dc=baz the query returns immediately. In both cases, the actual entries matching the search return immediately but for the problematic search "(&(objectClass=someClass)(abc=cn=foo,dc=bar))", the completion of the search takes a long time (around 15 seconds to be precise). The issue started suddenly and wasn't a degradation of query performance over time. Few things I have tried - Rebuilt the whole database again - Reindex the existing database again - Testing with bdb and mdb as backends - Increased cache sizes for bdb to hold the whole database in cache - For bdb adjust the page size of the indexes according to suggestion by db_tuner - Change the order of the filters None of these made any difference. At the moment, there does not seem to be any good options to try. Any ideas or help would be greatly appreciated!

6 18

HDB to MDB migration results in higher CPU usage on openldap consumers
by paul.jc＠yahoo.com 09 Nov '20

09 Nov '20

Hello, I have migrated from HDB to MDB backend and I am seeing higher CPU usage on my MDB openldap consumers. Has anyone else seen the same? Testing in my stage environment showed MDB to use less or the same amount of CPU than HDB - but now with real traffic and a large dataset I see sustained high CPU utilization. My production environment has the following specs: 6 consumer servers with 8vCPU x 16G RAM openldap version 2.4.45 Syncrepl enabled (with a single openldap provider server which is also MDB and has no issues and no high cpu). The database has ~230K users. data.mdb is about 1.8G in size. MDB database directives include: olcDbCheckpoint: 102400 10 olcDbNoSync: TRUE The rest are defaults. Indexing includes: olcDbIndex: businessCategory eq olcDbIndex: cn eq,sub olcDbIndex: description eq olcDbIndex: displayName eq,sub olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: gidNumber eq olcDbIndex: givenName eq,sub olcDbIndex: mail eq olcDbIndex: member eq olcDbIndex: memberOf eq olcDbIndex: memberUid eq olcDbIndex: objectClass pres,eq olcDbIndex: sn eq,sub olcDbIndex: uid eq,sub olcDbIndex: uidNumber eq olcDbIndex: uniqueMember eq These consumer servers are used for reads only. The initial sync with the provider is ok but once the consumers are actively handling read requests, CPU jumps to 60% usage on average. Our HDB consumers had half the resources (4vCPU and 8GB RAM) and less than half the CPU usage (average of 25% utilization). I have tested adding other MDB directives (writemap, mapasync, nordahead) but cannot get CPU utilization to come down close to what we see with the HDB backend. I have also load tested in my stage environment and was unable to reproduce (MDB generally utilized the same or less resources than HDB, but never double). There has been no change in the data or traffic between migration. We have also reverted some servers back to HDB and then back to MDB to confirm the high utilization. Has anyone else come across this with MDB and if so, were you able to alleviate CPU utilization? I can provide more details if needed. Any input welcome. Thanks! Paul

4 13

Modifying 'top' objectClass
by Zahoor Alizai 16 Oct '20

16 Oct '20

Can I modify the 'top' objectClass in openLDAP to incorporate some activedirectory attributes. Existing schemas in '/etc/ldap/slapd.d/cn=config/cn=schema' can be modified using ldapmodify. But i cannot find 'top' objectClass in any of these. To my knowledge, 'top' is part of system schema but can it be modified?

4 3

ldap_start_tls: Connect error - self signed certificate in certificate chain
by paul.jc＠yahoo.com 30 Sep '20

30 Sep '20

Hello, I have recently upgraded from openldap 2.4.45 to 2.5.53. I are running into one issue when running ldapsearch wth StartTLS locally on the openldap servers. I get the following error whereas I did not prior to upgrade. Any input/suggestions welcome. $ ldapsearch -ZZ -LLL -H ldap://<uri> -x -D "cn=admin, dc=<test.dc,dc=com" -b "dc=test,dc=com" -w ${pw} ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) Here is the debug: -------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) -------------- This does not happen with the same ldapsearch done remotely - TLS works just fine with remote ldapsearch queries. Running ldapsearch without StartTLS locally on the server works just fine as well. Prior to this upgrade, we had built openldap with MozNSS (--with-tls=moznss) but now are using the recommended openssl. With our earlier version, running ldapsearch with StartTLS locally on the openldap servers worked without issue. Our certs are not self signed but it appears tls with ldapsearch is seeing the CA cert from our CA as self signed when running locally on the server. Is this even a problem since remote connectivity with TLS works fine? Since we were running moznss prior, I am not sure what the expected behavior is now but it seems that it should work the same as before. A few more details: ------------------ -Servers are CentOS Linux release 7.5 -We are running Openldap version: OpenSSL 1.0.2k-fips 26 Jan 2017 -We are using the same certs (no changes to the certs as part of the upgrade) -Here is partial output from openssl s_client -connect <hostname-here>:636 (same result with openssl s_client -connect <hostname-here>:389 -starttls ldap): This shows return code of 0 (ok): -------------- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Verify return code: 0 (ok) -------------- -Ran openssl s_client -verify 3 -connect localhost:636 (and with hostname as well) and openssl s_client -showcerts -connect localhost:636. Both return code 0 (ok): Verify return code: 0 (ok) -Checked the certs: openssl verify -verbose -x509_strict -CAfile ca.crt slapd.crt slapd.crt: OK -Here is our cert config: olcTLSCACertificateFile: /etc/openldap/certs/ca.crt olcTLSCertificateFile: /etc/openldap/certs/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/certs/slapd.key For reference, here is the debug output when running the same ldapsearch command locally on the server on our previous version (2.4.45 with moznss) and the same cert is validated. -------------- TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: certificate [CN=*<test-domain-here>,OU=Domain Control Validated] is valid TLS certificate verification: subject: CN=*<test-domain-here>,OU=Domain Control Validated, issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US, cipher: AES-256-GCM, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_sasl_bind -------------- Any suggestions are appreciated. Thanks. Paul

2 3

When will OpenLDAP 2.5 be released officially?
by junc76＠gmail.com 30 Sep '20

30 Sep '20

Out product is planned to support the ldap channel binding required by MS (ADV190023). It seems that the feature has been implemented. https://bugs.openldap.org/show_bug.cgi?id=9189. From the isse description above, the target milestone is 2.5.0. My question is when will the version 2.5.0 be released? Thank you very much.

2 1

What does "slapcat: error writing output" means?
by Dario García Díaz-Miguel 30 Sep '20

30 Sep '20

Hello everyone, I couldn't find an answer or explanation about this error, so I hope somebody could help me over here. I use slapcat with head, grep and awk to retrieve some information and store it into a variable for a shell/bash script. Whenever I use slapcat, the output prompts the following error: - slapcat: error writing output. However, the information looked for is correctly retrieved. What's the reason behind this message? Is there a way to address it or at least, ignore it and hiding it? I can't just redirect that output to /dev/null. Version: Openldap2-2.4.41-18.43.1 Suse 12 SP3 Thank you so much. Kind Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com P Please consider the environment before printing this e-mail.

2 1

Issues with resetting user password
by CLARKE, ED C 29 Sep '20

29 Sep '20

Hello, I am new to this arena, I have a Open LDAP installed on my Linux server RHEL 7.8. I am not able to reset user passwords, I have checked the systemctl status slapd.service And it is active & running. Below is an example of the resetpw.ldif: $ cat ResetPW.ldif # dn: uid=foxdiv,ou=People,dc=att,dc=com changetype: modify replace: pwdReset pwdReset: TRUE - replace: userPassword userPassword: xxxxxxxxxxxx Any help would be appreciated, also any help on client side commands to test communications. Thanks, Ed Ed Clarke Senior Software Engineer Operations Transformation, Real-time Automation & Predictive Insights<http://mysolutions.dev.att.com/GNFO_Solutions/index.jsp> "RAPID" Certified Quality Eng. - ISO 9000/1 Six Sigma - Yellow Belt AT&T Veterans AT&T "ATO" 1010 Pine ST. Shared, St. Louis, MO. 63101 m 636.639.0713 | o 314.335.3158 | ec4397(a)att.com<mailto:ec4397@att.com>

4 19

delta-syncrepl "got search entry without Sync State control"
by Stefan Kania 29 Sep '20

29 Sep '20

I try to set up a delta-syncrepl configured via slapd.d. Building the configuration with Ansilbe. I got the following errormessages on my two consumers: ---------------- Sep 08 19:45:49 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:49 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) Sep 08 19:45:54 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:54 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (3 retries left) Sep 08 19:45:59 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:59 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (2 retries left) Sep 08 19:46:04 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:04 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (1 retries left) Sep 08 19:46:09 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:09 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying Sep 08 19:46:14 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:14 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying ---------------- Here is my configuration of the provider: ------------- # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapmaster-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapmaster-key.pem olcToolThreads: 1 # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}syncprov.la olcModuleLoad: {2}accesslog.la . . . # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb # {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500 # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb # {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2} to attrs=shadowLastChange by self write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824 # {0}syncprov, {1}mdb, config dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300 # {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcAccess: {0} to dn.sub=cn=accesslog by dn.exact=cn=repl-user,ou=users,dc=exa mple,dc=net read by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net read olcDbIndex: reqStart,reqEnd,reqMod,reqResult eq # {0}accesslog, {2}mdb, config dn: olcOverlay={0}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 01+00:00 00+04:00 olcAccessLogSuccess: TRUE ------------- As you can see, the syncrepl and accesslog overlays are configured. The database files are pressend and filepermission is ok. Here now the configuration of the consumer ------------- # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapslave-01-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapslave-01-key.pem olcToolThreads: 1 # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_md . . . # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb # {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500 # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb # {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2} to attrs=shadowLastChange by self write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcSyncrepl: {0}rid=1 provider=ldaps://ldapmaster.example.net type=refreshAndP ersist retry="5 5 300 +" filter="(ObjectClass=*)" scope=sub bindmethod=simple searchbase="dc=example,dc=net" binddn="cn=repl-user,ou=users,dc=example,dc=n et" credentials=geheim syncdata=accesslog logbase="cn=accesslog" logfilter="( &(objectClass=auditWriteObject)(reqResult=0)) olcUpdateRef: ldaps://ldapmaster.example.net olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824 ------------- I can access the accesslog-DB with ldapsearch as repl-user: ----------------- root@ldapslave-01:~# ldapsearch -x -D cn=repl-user,ou=users,dc=example,dc=net -w geheim -b cn=accesslog -H ldaps://ldapmaster.example.net -LLL dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=20200908174203.000008Z,cn=accesslog objectClass: auditAdd reqStart: 20200908174203.000008Z reqEnd: 20200908174203.000011Z reqType: add reqSession: 18446744073709551615 reqAuthzID: cn=accesslog reqDN: cn=accesslog reqResult: 0 reqMod: objectClass:+ auditContainer reqMod: cn:+ accesslog reqMod: structuralObjectClass:+ auditContainer ----------------- On the provider I see the following messages when accessing the accesslog: ----------------- Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 ACCEPT from IP=192.168.56.16:52338 (IP=0.0.0.0:636) Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 TLS established tls_ssf=256 ssf=256 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" method=128 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE ssf=0 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 RESULT tag=97 err=0 text= Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=2 UNBIND Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 closed ----------------- I see these messages even when I restart the consumer. So I think there is no problem with the access-permissions. any help is welcome :-) Stefan

4 16

RE: What does "slapcat: error writing output" means?
by Dario García Díaz-Miguel 28 Sep '20

28 Sep '20

About my last e-mail... I noticed that problem occurs when there is a head piped with the slapcat. I replaced: slapcat -d0 -c | head -n1 | awk -F "dn: " '{print $2}' With: slapcat -d0 -a "objectClass=dcObject" | grep ^dn | awk '{print $2}' And error disappeared. Thank you. Kind Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com -----Mensaje original----- De: Dario García Díaz-Miguel Enviado el: martes, 29 de septiembre de 2020 7:45 Para: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org> Asunto: What does "slapcat: error writing output" means? Hello everyone, I couldn't find an answer or explanation about this error, so I hope somebody could help me over here. I use slapcat with head, grep and awk to retrieve some information and store it into a variable for a shell/bash script. Whenever I use slapcat, the output prompts the following error: - slapcat: error writing output. However, the information looked for is correctly retrieved. What's the reason behind this message? Is there a way to address it or at least, ignore it and hiding it? I can't just redirect that output to /dev/null. Version: Openldap2-2.4.41-18.43.1 Suse 12 SP3 Thank you so much. Kind Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com P Please consider the environment before printing this e-mail.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2020