slapcat doesn't return correct error status for bdb fatal error
by Guillaume Rousse
[root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr
...
bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument
bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument
bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error,
run database recovery
bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected;
run recovery
bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed:
DB_RUNRECOVERY: Fatal error, run database recovery (-30975)
[root@etoile ~]# echo $?
0
It makes a bit difficult to know if slapcat-based backup were successful.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
13 years, 10 months
Open LDAP 2.3.38 core dump when trying to add netgroup
by Eric Boehm
I am trying to create a minimal LDAP installation to test using LDAP
for netgroups.
My slapd.conf contains
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/misc.schema
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
database bdb
suffix "dc=nortel,dc=com"
rootdn "cn=Manager,dc=nortel,dc=com"
rootpw {SSHA}VszWHdlMt+txouAiBDwn0uKRII8OKzKc
directory /usr/local/openldap/var/openldap-data
index cn,sn pres,eq,approx,sub
index objectClass eq
I can add the following data without trouble
dn: dc=nortel,dc=com
objectClass: dcObject
objectClass: organization
dc: nortel
o: Nortel
description: Nortel Inc.
dn: cn=Manager,dc=nortel,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager
dn: ou=Netgroup,dc=nortel,dc=com
ou: Netgroup
objectClass: top
objectClass: organizationalUnit
dn: nisMapName=netgroup.byuser,dc=nortel,dc=com
nismapname: netgroup.byuser
objectClass: top
objectClass: nisMap
dn: nisMapName=netgroup.byhost,dc=nortel,dc=com
nismapname: netgroup.byhost
objectClass: top
objectClass: nisMap
However, when I try to add
dn: cn=sample,ou=netgroup,dc=nortel,dc=com
objectclass: nisNetGroup
objectclass: top
cn: sample
nisNetgroupTriple: (zrtps0q8,,)
nisNetgroupTriple: (zrtps0q8.us.nortel.com,,)
slapd dies and leaves a core dump
I built slapd with debugging and when I bring it up in the
debugger. It tells me
t@5 (l@1) terminated by signal BUS (invalid address alignment)
0xffffffff7efd2f3c: __lock_get_internal+0x08ac: ldx [%l1 + 0x18], %l0
Current function is bdb_id2entry
The source code line is 125 in id2entry.c
rc = cursor->c_get( cursor, &key, &data, DB_SET );
I can't figure out what I am doing wrong. I tried to strip things down
to the bare essentials.
I suspect I haven't created the LDAP database properly but I am unable
to determine what step or data I am missing.
--
Eric M. Boehm /"\ ASCII Ribbon Campaign
boehm(a)nortel.com \ / No HTML or RTF in mail
X No proprietary word-processing
Respect Open Standards / \ files in mail
13 years, 10 months
debugging syncrepl issue
by Guillaume Rousse
Hello list.
I'm facing a syncrepl issue really strange. Sofar, everytime I had sync
issue, I just had to stop the consumer, delete its database, and restart
it again to make it work. However, this time it seems unsufficient, and
synchronisation hangs on some entries.
In the consumer logs, with loglevel set to sync, starting with an empty
base, I get lots of successfully synced entries:
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123
uid=test,ou=users,dc=msr-inria,dc=inria,dc=fr
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_add (0)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 inserted
UUID 86a10a62-ddf2-102c-9dfe-558a8530d5ee
Then I get a warning for some strange entry:
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123
ou=kerberos,dc=msr-inria,dc=inria,dc=fr
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_add (68)
Oct 7 17:55:25 nation slapd[30453]: dn_callback : new entry is older
than ours ou=kerberos,dc=msr-inria,dc=inria,dc=fr ours
20080704085717.749336Z#000000#000#000000, new
20080704085416.079377Z#000000#000#000000
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 entry
unchanged, ignored (ou=kerberos,dc=msr-inria,dc=inria,dc=fr)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 inserted
UUID 504ed75a-e374-102c-8faa-7b1baeea81b3
then additional successfully synced entries:
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123 be_search (0)
Oct 7 17:55:25 nation slapd[30453]: syncrepl_entry: rid=123
uid=jabbour,ou=users,dc=msr-inria,dc=inria,dc=fr
Oct 7 17:55:26 nation slapd[30453]: syncrepl_entry: rid=123 be_add (0)
Oct 7 17:55:26 nation slapd[30453]: syncrepl_entry: rid=123
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 7 17:55:26 nation slapd[30453]: syncrepl_entry: rid=123 inserted
UUID f516b45c-e38c-102c-8953-f71742eb083b
And then something fails:
Oct 7 17:55:26 nation slapd[30453]: do_syncrep2: rid=123
LDAP_RES_SEARCH_RESULT
Oct 7 17:55:26 nation slapd[30453]: do_syncrep2:
cookie=rid=123,csn=20081003163733.899132Z#000000#000#000000
Oct 7 17:55:26 nation slapd[30453]: slap_queue_csn: queing 0x846f858
20081003163733.899132Z#000000#000#000000
Oct 7 17:55:26 nation slapd[30453]: slap_graduate_commit_csn: removing
0x8471120 20081003163733.899132Z#000000#000#000000
Oct 7 17:55:26 nation slapd[30453]: do_syncrep2:
cookie=rid=123,csn=20081006083018.748988Z#000000#000#000000
Oct 7 17:55:26 nation slapd[30453]: slap_queue_csn: queing 0x8386340
20081006083018.748988Z#000000#000#000000
Oct 7 17:55:26 nation slapd[30453]: slap_graduate_commit_csn: removing
0x841ad98 20081006083018.748988Z#000000#000#000000
Oct 7 17:55:26 nation slapd[30453]: syncrepl_message_to_op: rid=123
be_modify uid=rousse,ou=users,dc=msr-inria,dc=inria,dc=fr (0)
I'm unable to understand what's going wrong there.
On provider's side, all I have is the warning for the entry with an
apparent wrong timestamp:
Oct 7 17:55:22 etoile slapd[32640]: syncprov_search_response:
cookie=rid=123,csn=20081003163733.899132Z#000000#000#000000
Oct 7 17:55:26 etoile slapd[32640]: Entry
reqStart=20081003163733.000015Z,cn=log CSN
20081003163733.899132Z#000000#000#000000 older or equal to ctx
20081003163733.899132Z#000000#000#000000
Oct 7 17:55:26 etoile slapd[32640]: syncprov_search_response:
cookie=rid=123,csn=20081007080656.987198Z#000000#000#000000
I checked access permissions and limits for syncrepl user on provider
side, everything is OK. I'm using OpenLDAP 2.4.11 on both sides. And
here is my syncrepl configuration:
syncrepl rid=123
provider=ldaps://ldap1.msr-inria.inria.fr
type=refreshAndPersist
retry="60 +"
logbase="cn=log"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
searchbase="dc=msr-inria,dc=inria,dc=fr"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr"
credentials=XXXXX
Any hint welcome.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
13 years, 10 months
Fwd: Best method for redundant replication
by Brett ＠Google
On 10/15/08, Mark S <tokenrain(a)gmail.com> wrote:
> I would some advice and how best to go about setting up a redundant
> infrastructure for my ldap consumer servers.
>
> I work for a company that has remote offices around the world.
>
> In our main office we have setup 2 OpenLDAP servers running 4.x version of
> the software in a MirrorMode configuration. I have load balancer which
> points a single VIP to the server that I want to be the authoritative
writer
> at any point in time.
>
> Around the world I have around 42 servers that I would like to slave off
> these master servers.
>
> First off does anyone think having 42 slaves to a single master is going
to
> kill the server. It is an 8 core box with gobs of RAM.
>
> The other question is on how I obtain replication redundancy. Do I simply
> point my syncrepl provider to the VIP that hosts the master server. When
the
> VIP re points in case the a server failure the salvea should just
> reconnect? Has anyone ever used 2 syncrepl stanzas against the same DIT.
> Something like below. This way the slaves always has a connection to both
> servers in the MirrorMode config. If one goes down then the other
> replication thread will continue getting updates. Is this a supported
> configor does it create a lot of conflicts in deciding who to get the
> updates from since it will receive 2 updates when both servers are live.
my understanding of mirrormode was that you would point your servers
(for writing) at a vip (say master.yourname) or back-ldap server, which
refers to the preferred server master1.yourname, and only if that is
unavailable,
would the vip send traffic to master2.yourname.
in this case where one master is preferred, replication traffic between
servers
would predominately be in one direction, hence clock / replication issues or
who-updated-who-first issues, would reduce or go away, which is why it is
better than multimaster if your goal is redundancy.
reads can be directed at either master1.yourname or master2.yourname,
as both would be same for the purposes of reading. you can explicitly refer
writes to your master server, in the slap.conf of your distributed servers
above assumes writes are less frequent than reads, which is usually
typical with ldap data.. your mileage may vary.
Cheers
Brett
13 years, 10 months
Best method for redundant replication
by Mark S
I would some advice and how best to go about setting up a redundant
infrastructure for my ldap consumer servers.
I work for a company that has remote offices around the world.
In our main office we have setup 2 OpenLDAP servers running 4.x version of
the software in a MirrorMode configuration. I have load balancer which
points a single VIP to the server that I want to be the authoritative writer
at any point in time.
Around the world I have around 42 servers that I would like to slave off
these master servers.
First off does anyone think having 42 slaves to a single master is going to
kill the server. It is an 8 core box with gobs of RAM.
The other question is on how I obtain replication redundancy. Do I simply
point my syncrepl provider to the VIP that hosts the master server. When the
VIP re points in case the a server failure the salvea should just
reconnect? Has anyone ever used 2 syncrepl stanzas against the same DIT.
Something like below. This way the slaves always has a connection to both
servers in the MirrorMode config. If one goes down then the other
replication thread will continue getting updates. Is this a supported
configor does it create a lot of conflicts in deciding who to get the
updates from since it will receive 2 updates when both servers are live.
Thanks!
syncrepl rid=100
provider=ldap://master1.nyc.example.com:389
bindmethod=simple
binddn="cn=repl,dc=nyc,dc=example,dc=com"
credentials=secret
type=refreshAndPersist
searchbase="dc=nyc,dc=example,dc=com"
retry="5 5 10 10 60 +"
schemachecking=off
syncrepl rid=101
provider=ldap://master2.nyc.example.com:389
bindmethod=simple
binddn="cn=repl,dc=nyc,dc=example,dc=com"
credentials=secret
type=refreshAndPersist
searchbase="dc=nyc,dc=example,dc=com"
retry="5 5 10 10 60 +"
schemachecking=off
13 years, 10 months
Translucent overlays & replication.
by John Maddock
Hi.
With OpenLDAP 2.4.10 is it possible to replicate a translucent overlay's
local changes to another server?
Regards, John.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
13 years, 10 months
Re: Logging bind password
by Pierangelo Masarati
----- "Alfonsas Stonis" <alfonsasstonis(a)gmail.com> wrote:
> Hi,
>
> Is there any way to log password that was used during bind?
> I tried adding option
> loglevel 18446744073709551615
where did you find that documented? Since the log level is a mask, I doubt adding digits can help to any extent.
> and many other options. Nothing helps. I get the following output
> (without password)
>
> Oct 14 10:56:47 dr slapd[28331]: daemon: read activity on 12
> Oct 14 10:56:47 dr slapd[28331]: connection_get(12)
> Oct 14 10:56:47 dr slapd[28331]: connection_get(12): got connid=2
> Oct 14 10:56:47 dr slapd[28331]: connection_read(12): checking for
> input on id=2
> Oct 14 10:56:47 dr slapd[28331]: ber_get_next on fd 12 failed
> errno=11
> (Resource temporarily unavailable)
> Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=7
> active_threads=0 tvp=NULL
> Oct 14 10:56:47 dr slapd[28331]: do_bind
> Oct 14 10:56:47 dr slapd[28331]: >>> dnPrettyNormal:
> <cn=jbaker007,ou=users,o=arhub>
> Oct 14 10:56:47 dr slapd[28331]: <<< dnPrettyNormal:
> <cn=jbaker007,ou=users,o=arhub>, <cn=jbaker007,ou=users,o=arhub>
> Oct 14 10:56:47 dr slapd[28331]: do_bind: version=3
> dn="cn=jbaker007,ou=users,o=arhub" method=128
> Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 BIND
> dn="cn=jbaker007,ou=users,o=arhub" method=128
> Oct 14 10:56:47 dr slapd[28331]: ==> bdb_bind: dn:
> cn=jbaker007,ou=users,o=arhub
> Oct 14 10:56:47 dr slapd[28331]:
> bdb_dn2entry("cn=jbaker007,ou=users,o=arhub")
> Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access to
> "cn=jbaker007,ou=users,o=arhub" "userPassword" requested
> Oct 14 10:56:47 dr slapd[28331]: => acl_get: [1] attr userPassword
> Oct 14 10:56:47 dr slapd[28331]: => acl_mask: access to entry
> "cn=jbaker007,ou=users,o=arhub", attr "userPassword" requested
> Oct 14 10:56:47 dr slapd[28331]: => acl_mask: to all values by "",
> (=n)
> Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: ou=rba,o=arhub
> Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: self
> Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: *
> Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] applying auth(=x)
> (stop)
> Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] mask: auth(=x)
> Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access
> granted by auth(=x)
> Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: conn=2 op=0 p=3
> Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: err=49 matched=""
> text=""
> Oct 14 10:56:47 dr slapd[28331]: send_ldap_response: msgid=1 tag=97
> err=49
> Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 RESULT tag=97 err=49
> text=
> Oct 14 10:56:47 dr slapd[28331]: daemon: activity on 1 descriptors
> Oct 14 10:56:47 dr slapd[28331]: daemon: activity on:
>
> The problem is that I know that I have correct password but ldap
> keeps
> rejecting it. So, I need to test maybe application is somehow
> changing
> it, but I can not see it.
> Can someone help me?
Try "packets"; you'll get something like
slapd starting
ldap_read: want=8, got=8
0000: 30 2e 02 01 01 60 29 02 0....`).
ldap_read: want=40, got=40
0000: 01 03 04 1c 63 6e 3d 6d 61 6e 61 67 65 72 2c 64 ....cn=manager,d
0010: 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 6f 6d c=example,dc=com
0020: 80 06 73 65 63 72 65 74 ..secret
ldap_read: want=8 error=Resource temporarily unavailable
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
13 years, 10 months
slapadd newbie
by ELCIN HAKTANIR
Hi i am suffering from slow slapadd for a 100,000 subscriber.
It is 27 minutes.
this is not what i am expecting .
My test environment and the openLDAP release i have installed
symas-openldap-silver-2.4.11.0.sun4u.pkg
to a System Configuration:
Sun Microsystems sun4v SPARC Enterprise T5220
Memory size: 32640 Megabytes
Is it rational that slapadd took 26 minutes for 100,000 entries(23Kbyte
per subscriber i guess) without index.?
I think it is so slow.isn't it?
What have i done wrong then?Could you please help to reduce this time ?
And how can i learn what db_stat exactly mean to me while doing slapadd?
Configuration information about my Environment:
---------------------------------------------------------------------
symas-openldap-silver-2.4.11.0.sun4u.pkg installed on a System with
Configuration: Sun Microsystems sun4v SPARC Enterprise T5220
Memory size: 32640 Megabytes
My slapadd command:
-------------------------------------
/opt/symas/bin/sparcv9/slapadd -l
/opt/symas/etc/openldap/ldifs/subscribersPart100.ldif -f
/opt/symas/etc/openldap/slapd.conf -b o=sdftest -q
my DB_CONFIG file is:
---------------------------------------
set_cachesize 10 0 0
set_flags DB_LOG_AUTOREMOVE
set_flags DB_TXN_NOSYNC
set_lg_max 10485760
set_lg_bsize 2097152
set_lg_dir /opt/symas/etc/openldap/transactionlog
my slapd.conf file is:
---------------------------------
tool-threads 2
access to dn="" by * read
access to *
by self write
by users read
by anonymous auth
database bdb
suffix "o=sdftest"
rootdn "cn=sdf,o=sdftest"
rootpw admin234
index default eq
index objectClass
index cn
directory /var/symas/openldap-data/
checkpoint 256000 60
one of the db_stat result
root@typhoon:/# /opt/symas/bin/sparcv9/db_stat -h
/var/symas/openldap-data/ -m
2GB 25MB Total cache size
1 Number of caches
1 Maximum number of caches
2GB 25MB Pool individual cache size
0 Maximum memory-mapped file size
0 Maximum open file descriptors
0 Maximum sequential buffer writes
0 Sleep after writing maximum sequential buffers
0 Requested pages mapped into the process' address space
91M Requested pages found in the cache (99%)
294 Requested pages not found in the cache
307399 Pages created in the cache
294 Pages read into the cache
307935 Pages written from the cache to the backing file
31233 Clean pages forced from the cache
33201 Dirty pages forced from the cache
103701 Dirty pages written by trickle-sync thread
243256 Current total page count
243256 Current clean page count
0 Current dirty page count
262147 Number of hash buckets used for page location
90M Total number of times hash chains searched for a page (90995964)
2 The longest hash chain searched for a page
120M Total number of hash chain entries checked for page (120028164)
31 The number of hash bucket locks that required waiting (0%)
4 The maximum number of times any hash bucket lock was waited for
(0%)
9 The number of region locks that required waiting (0%)
0 The number of buffers frozen
0 The number of buffers thawed
0 The number of frozen buffers freed
307713 The number of page allocations
257629 The number of hash buckets examined during allocations
60205 The maximum number of hash buckets examined for an allocation
64434 The number of pages examined during allocations
5844 The max number of pages examined for an allocation
21 Threads waited on page I/O
Pool File: id2entry.bdb
16384 Page size
0 Requested pages mapped into the process' address space
2999318 Requested pages found in the cache (99%)
3 Requested pages not found in the cache
136414 Pages created in the cache
3 Pages read into the cache
136659 Pages written from the cache to the backing file
Pool File: dn2id.bdb
4096 Page size
0 Requested pages mapped into the process' address space
53M Requested pages found in the cache (99%)
2 Requested pages not found in the cache
168604 Pages created in the cache
2 Pages read into the cache
168607 Pages written from the cache to the backing file
Pool File: objectClass.bdb
4096 Page size
0 Requested pages mapped into the process' address space
25M Requested pages found in the cache (99%)
2 Requested pages not found in the cache
694 Pages created in the cache
2 Pages read into the cache
695 Pages written from the cache to the backing file
Pool File: cn.bdb
4096 Page size
0 Requested pages mapped into the process' address space
9191165 Requested pages found in the cache (99%)
287 Requested pages not found in the cache
1687 Pages created in the cache
287 Pages read into the cache
1974 Pages written from the cache to the backing file
--------------------------------------
Bu elektronik posta ve onunla iletilen bütün dosyalar gizlidir sadece
yukarıda isimleri belirtilen kişiler arasında özel haberleşme amacını
taşımaktadır. Size yanlışlıkla ulaşmıssa bu elektonik postanın içeriğini
açıklamanız , kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle
yasaktır. Lütfen mesajı geri gönderiniz ve sisteminizden siliniz. Vodafone
Teknoloji Hizmetleri A.Ş. bu mesajın içeriği ile ilgili olarak hiç bir
hukuksal sorumluluğu kabul etmez.
This electonic mail and any files transmitted with it are intended for the
private use of the persons named above. If you received this message in
error, forwarding, copying or use of any of the information is strictly
prohibited. Please immediately notify the sender and delete it from your
system. Vodafone Teknoloji Hizmetleri A.S. does not accept legal
responsibility for the contents of this message.
--------------------------------------
13 years, 10 months
OpenLDAP Kerberos Authentication fails
by Loren M. Lang
I am using OpenLDAP 2.4.9 on Ubuntu Linux 8.04.1 with MIT Kerberos
1.6.3. Created a keytab file dedicated to slapd and set the path to it
using the environment variable KRB5_KTNAME in my startup scripts. The
file is owned by root and read-only by the openldap group. When I
attempt to use ldapsearch with GSSAPI to login to slapd I get back a
implementation error 80. Checking the server logs, slapd reported the
following error:
Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (Resource temporarily unavailable)
I tried removing the group read permission on the keytab file and
restarted slapd as a test on the file to see if slapd was actually
reading it and the minor code on the former error message changed to
Permission denied. I then added a letter to the keytab file name in my
startup script and the error changed to File not found. After reseting
the keytab filename and permissions the error was once again Resource
temporarily unavailable. I tried deleting the keytab and re-extracting
the key using kadmin and setting the permissions appropriately including
making openldap the owner as well. I then destroyed my ccache and
reacquiring a ticket. When I ran ldapsearch, the error was still resource
temporarily unavailable. The client and server are the same computer.
The service principal is ldap/host.example.com(a)EXAMPLE.COM and klist shows
that is did acquire a service ticket for that principal. The hostname
command returns host.example.com for the hostname and that hostname is in
/etc/hosts as the first (primary) name for the server's ip address.
--
Loren M. Lang
lorenl(a)north-winds.org
http://www.north-winds.org/
Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc
Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B
13 years, 10 months
Logging bind password
by Alfonsas Stonis
Hi,
Is there any way to log password that was used during bind?
I tried adding option
loglevel 18446744073709551615
and many other options. Nothing helps. I get the following output
(without password)
Oct 14 10:56:47 dr slapd[28331]: daemon: read activity on 12
Oct 14 10:56:47 dr slapd[28331]: connection_get(12)
Oct 14 10:56:47 dr slapd[28331]: connection_get(12): got connid=2
Oct 14 10:56:47 dr slapd[28331]: connection_read(12): checking for input on id=2
Oct 14 10:56:47 dr slapd[28331]: ber_get_next on fd 12 failed errno=11
(Resource temporarily unavailable)
Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=6
active_threads=0 tvp=NULL
Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 14 10:56:47 dr slapd[28331]: do_bind
Oct 14 10:56:47 dr slapd[28331]: >>> dnPrettyNormal:
<cn=jbaker007,ou=users,o=arhub>
Oct 14 10:56:47 dr slapd[28331]: <<< dnPrettyNormal:
<cn=jbaker007,ou=users,o=arhub>, <cn=jbaker007,ou=users,o=arhub>
Oct 14 10:56:47 dr slapd[28331]: do_bind: version=3
dn="cn=jbaker007,ou=users,o=arhub" method=128
Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 BIND
dn="cn=jbaker007,ou=users,o=arhub" method=128
Oct 14 10:56:47 dr slapd[28331]: ==> bdb_bind: dn: cn=jbaker007,ou=users,o=arhub
Oct 14 10:56:47 dr slapd[28331]: bdb_dn2entry("cn=jbaker007,ou=users,o=arhub")
Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access to
"cn=jbaker007,ou=users,o=arhub" "userPassword" requested
Oct 14 10:56:47 dr slapd[28331]: => acl_get: [1] attr userPassword
Oct 14 10:56:47 dr slapd[28331]: => acl_mask: access to entry
"cn=jbaker007,ou=users,o=arhub", attr "userPassword" requested
Oct 14 10:56:47 dr slapd[28331]: => acl_mask: to all values by "", (=n)
Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: ou=rba,o=arhub
Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: self
Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: *
Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] applying auth(=x) (stop)
Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] mask: auth(=x)
Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access
granted by auth(=x)
Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: conn=2 op=0 p=3
Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: err=49 matched="" text=""
Oct 14 10:56:47 dr slapd[28331]: send_ldap_response: msgid=1 tag=97 err=49
Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 RESULT tag=97 err=49 text=
Oct 14 10:56:47 dr slapd[28331]: daemon: activity on 1 descriptors
Oct 14 10:56:47 dr slapd[28331]: daemon: activity on:
The problem is that I know that I have correct password but ldap keeps
rejecting it. So, I need to test maybe application is somehow changing
it, but I can not see it.
Can someone help me?
Alfas
13 years, 10 months
