Problem with "force user to password reset at first login
by Rajagopal Rc
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
1 month, 1 week
Index seems to return wrong amount of candidate causing really poor search performance
by chrichardso27＠gmail.com
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!
2 years, 3 months
HDB to MDB migration results in higher CPU usage on openldap consumers
by paul.jc＠yahoo.com
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
3 years, 1 month
Modifying 'top' objectClass
by Zahoor Alizai
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?
3 years, 1 month
ldap_start_tls: Connect error - self signed certificate in certificate chain
by paul.jc＠yahoo.com
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
3 years, 2 months
What does "slapcat: error writing output" means?
by Dario García Díaz-Miguel
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.
3 years, 2 months
Issues with resetting user password
by CLARKE, ED C
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>
3 years, 2 months
delta-syncrepl "got search entry without Sync State control"
by Stefan Kania
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
3 years, 2 months
RE: What does "slapcat: error writing output" means?
by Dario García Díaz-Miguel
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.
3 years, 2 months
