Virtual list view problem
by Venish Khant
Hi all
I am using cpan Net::LDAP module to access LDAP entries. I want to
search LDAP entries using Net::LDAP search method. When I do search, I
want some limited number of entries from search result, for
this(searching) process I am using Net::LDAP::Control::VLV module. But
I get error on VLV response control. Please, any one have idea about
this error.
*
Error:* Died at vlv.pl line 50,
This is my example. I changed the font style of line 50
#!/usr/bin/perl -w
use Net::LDAP;
use Net::LDAP::Control::VLV;
use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE );
use Net::LDAP::Control::Sort;
sub procentry {
my ( $mesg, $entry) = @_;
# Return if there is no entry to process
if ( !defined($entry) ) {
return;
}
print "dn: " . $entry->dn() . "\n";
@attrs = $entry->attributes();
foreach $attr (@attrs) {
#printf("\t%s: %s\n", $attr, $entry->get_value($attr));
$attrvalue = $entry->get_value($attr,asref=>1);
#print $attr.":". $entry->get_value($attr)."\n";
foreach $value(@$attrvalue) {
print "$attr: $value\n";
}
}
$mesg->pop_entry;
print "\n";
}
$ldap = Net::LDAP->new( "localhost" );
# Get the first 20 entries
$vlv = Net::LDAP::Control::VLV->new(
before => 0, # No entries from before target entry
after => 19, # 19 entries after target entry
content => 0, # List size unknown
offset => 1, # Target entry is the first
);
my $sort = Net::LDAP::Control::Sort->new( order => 'cn' );
@args = ( base => "dc=example,dc=co,dc=in",
scope => "subtree",
filter => "(objectClass=inetOrgPerson)",
callback => \&procentry, # Call this sub for each entry
control => [ $sort, $vlv ],
);
$mesg = $ldap->search( @args );
# Get VLV response control
*($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;*
$vlv->response( $resp );
# Set the control to get the last 20 entries
$vlv->end;
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;
$vlv->response( $resp );
# Now get the previous page
$vlv->scroll_page( -1 );
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mes
# Now page with first entry starting with "B" in the middle
$vlv->before(9); # Change page to show 9 before
$vlv->after(10); # Change page to show 10 after
$vlv->assert("B"); # assert "B"
$mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or
die;
$vlv->response( $resp );
--
Venish Khant
www.deeproot.co.in
7 years
SASL passthrough - multiple domains
by Liam Gretton
I have a working configuration with pass-through auth to an AD domain
using saslauthd.
However now there is a requirement to be able to handle another domain
too, and I cannot work out how to do this. It seems that saslauthd
cannot deal with multiple Kerberos realms, no matter what hoops one
jumps through it eventually boils down to only using whatever
'default_realm' is set to in the krb5.conf file.
Using multiple saslauthd daemons isn't possible either as there's no way
(that I can work out) of getting OpenLDAP to use anything other than the
single socket specified in /etc/sasl2/slapd.conf.
My final idea was to run an LDAP instance per realm, each talking to the
separate saslauthd daemons, and have another outward facing LDAP service
with these as the backends but that's a non starter too because there's
no way of specifying the sasl slapd.conf file, it seems sasl always
looks in /etc/sasl2 for a file derived from the process name (a chroot
environment for each LDAP server is therefore the next thing to look at).
But this seems like a lot of work just to be able to authenticate users
against multiple domains. I appreciate this is a SASL issue rather than
a problem with OpenLDAP, but I'm hoping that someone here has cracked
this already. Googling hasn't thrown up an solution that I can find.
--
Liam Gretton liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services Tel: +44 (0)116 2522254
University of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
10 years, 11 months
Pass-though Authentication with Saslauthd and Kerberos
by Jeff B
I'm attempting to get pass-though auth to work against saslauthd and
kerberos and while the problem seems to be in sasl I think it's most
likely to be seen in this type of configuration with opendap which I
why I chose this mailing list.
When I run testsaslauthd it works but when I run ldapsearch it fails.
But the curious thing is where it is failing. in doing straces of
saslauthd and packet traces I've found that when ldapsearch calls
salsauthd, and not when I run saslauthd kerberos does not deliver the
AS-REP packets till just after saslauthd times out.
I can't find any difference in how I'm invoking saslauthd with
testdaslauthd and how ldapsearch is invoking saslauthd. However the
packet traces are quite different as you will see below.
I've seen these kind of errors here and there on google but no
resolutions that I can find.
(http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
Centos 6
openldap-2.4.23-15.el6_1.3.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
openldap-servers-2.4.23-15.el6_1.3.x86_64
openldap-devel-2.4.23-15.el6_1.3.x86_64
krb5-server-1.9-9.el6_1.2.x86_64
krb5-server-ldap-1.9-9.el6_1.2.x86_64
krb5-workstation-1.9-9.el6_1.2.x86_64
krb5-libs-1.9-9.el6_1.2.x86_64
cyrus-sasl-2.1.23-8.el6.x86_64
cyrus-sasl-lib-2.1.23-8.el6.x86_64
cyrus-sasl-gssapi-2.1.23-8.el6.x86_64
cyrus-sasl-plain-2.1.23-8.el6.x86_64
cyrus-sasl-devel-2.1.23-8.el6.x86_64
My slapd.conf contains nothing regarding kerberos / sasl /
pass-through authentication. I'm using a slapd.conf file for the time
being till i get it all worked out and plan on converting it to a
cn=config configuration.
In my DIT the userPassword field contains: {SASL}myuser@MYREALM where
myuser and my realm are replaced with the proper values.
/etc/sasl2/slapd.conf:
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
/etc/sysconfig/saslauthd
KRB5_KTNAME=/etc/krb5.keytab
SOCKETDIR=/var/run/saslauthd
MECH=kerberos5
Which builds a daemon command line of:
/usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
My system keytab is:
/etc/krb5.keytab (root.ldap 0640)
host/my.hostname@realm
ldap/my.hostname@realm
My socket parent dir is:
/var/run/saslauthd (root.ldap 0770)
When I run testsaslauthd I get a packet trace between saslauthd and
kerberos is all UDP and works:
> AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
> AS-REQ
< AS-REP
> TGS-REQ
< TGS-REP
When I run ldapsearch the packet trace between saslauthd and kerberos
is UDP and TCP communication. None of the kerberos replies come back
for 18 seconds, the time it takes saslauthd to time out.
> AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
> AS-REQ
> TCP SYN
< TCP SYN, ACK
> TCP ACK
> TCP AS-REQ
< TCP ACK
> AS-REQ
> AS-REQ
> TCP FIN, ACK <-- saslauthd times out and the AS-REPS all come back at once.
< AS-REP
< AS-REP
< AS-REP
< TCP AS-REP
> TCP RST
an strace of saslauthd supports this timeout theory as it shows the
the timeouts and backoffs.
I can't find any info regarding saslauthd and TCP or UDP or timeouts
like this. Any ideas?
11 years
DEL don't get synced
by Marc Patermann
Hi,
under some circumstances DEL don't get replicated to the consumers
(SyncRepl). I think this has to do with other changes at the some moment.
I attached two logs excepts in sync.log.
In the first except there is only a DEL
Jan 31 09:16:01 ldapserver slapd[10641]: conn=79138 op=2 DEL
dn="employeeNumber=19676,ou=humans,ou=foo"
For this there is a
Jan 31 09:16:01 ldapserver slapd[10641]: syncprov_sendresp:
cookie=rid=401,csn=20120131081601.377028Z#000000#000#000000
line for every connected consumer.
In the second step there is a MOD and a DEL
Jan 31 10:31:01 ldapserver slapd[10641]: conn=79938 op=2 MOD
dn="ou=FA-WF,ou=gruppen,ou=humans,ou=foo"
Jan 31 10:31:01 ldapserver slapd[10641]: conn=79938 op=3 DEL
dn="employeeNumber=24387,ou=humans,ou=foo"
As far as I can see, there is only sync activity for the MOD action, and
not for the DEL action. The DEL is not synced.
Marc
11 years, 1 month
ACL in dynamic configuration
by Nick Milas
Hello,
I have converted from static (slapd.conf) to dynamic (cn=config)
configuration using auto file conversion.
I would like to ask a couple of questions regarding ACL conversion. Here
follows one of the rules we have in initial form (a), and after
conversion (b):
(a)
access to
dn.subtree="dc=xxx.xxx.xxx.in-addr.arpa,ou=dns1,dc=example,dc=gr"
attrs="children,entry"
by group.exact="cn=TechAdmins,ou=Groups,dc=example,dc=gr" write
by group.exact="cn=Dept1Admins,ou=Groups,dc=example,dc=gr" read
by group.exact="cn=Dept2Admins,ou=Groups,dc=example,dc=gr" write
by group.exact="cn=Dept3Admins,ou=Groups,dc=example,dc=gr" read
by group.exact="cn=Dept4Admins,ou=Groups,dc=example,dc=gr" read
by group.exact="cn=Dept5Admins,ou=Groups,dc=example,dc=gr" read
by group.exact="cn=GuestAdmins,ou=Groups,dc=example,dc=gr" read
by dn.exact="uid=dnsauthusr,ou=System,dc=example,dc=gr" read
by * break
(b) as an olcAccess attribute value:
{10}to
dn.subtree="dc=xxx.xxx.xxx.in-addr.arpa,ou=dns1,dc=example,dc=gr"
attrs=children,entry by
group/groupOfNames/member.exact="cn=techadmins,ou=groups,dc=example,dc=gr"
write by
group/groupOfNames/member.exact="cn=Dept1Admins,ou=groups,dc=example,dc=gr"
read by
group/groupOfNames/member.exact="cn=Dept2Admins,ou=groups,dc=example,dc=gr"
write by
group/groupOfNames/member.exact="cn=Dept3Admins,ou=groups,dc=example,dc=gr"
read by
group/groupOfNames/member.exact="cn=Dept4Admins,ou=groups,dc=example,dc=gr"
read by
group/groupOfNames/member.exact="cn=Dept5Admins,ou=groups,dc=example,dc=gr"
read by
group/groupOfNames/member.exact="cn=guestadmins,ou=groups,dc=example,dc=gr"
read by dn.base="uid=dnsauthusr,ou=system,dc=example,dc=gr" read by *
+0 break
Question 1.
Why "group.exact" was changed to "group/groupOfNames/member.exact" ?
Yes, groups are defined as entries of groupOfNames objectClass, with
members defined as values of attribute "member". But should it be like
that? Should we change (manually) "group/groupOfNames/member.exact" back
to "group.exact" again or not (and why)?
Question 2.
Is there a way we can add (manually, since conversion removed the ones
which existed in initial configuration files) line breaks in olcAccess
attribute value so it can be more legible (for administrative purposes)?
Question 3.
What is the "+0" added before "break" and why is needed?
Thanks in advance,
Nick
11 years, 2 months
OpenLDAP 2.4 : replication doesn't work when customer is stopped
by PROST Frédéric
Hello,
I configured MirrorMode replication between 2 openldap 2.4 node installed on Debian (from apt).
Everything is working fine when the two nodes are online but if I stop the second node, and add new datas to the first node, then restart the second node, the new data are not synced.
However, if I then add new datas on node 1, they are replicated to node2 without problem.
Here is a scenario of this problem :
1/ node1 and node 2 are online : I add user1 to node 1 => user1 appears on node2 => ok
2/ node1 is online and node2 is off : I add user2 on node1 => nothing happens on node2 as it is off => ok
3/ I restart node2 => user2 is not replicated to node2 => not ok
4/ node1 and node 2 are online : I add user3 to node 1 => user3 appears on node2 => ok
At the end of this scenario, node1 contains user1, user2 and user3 and node2 contains only user1 and user3 (but not user2).
How can I slove this problem ?
Thank you for your help,
Best regards,
Fred
Here is my config :
version: 1
dn: cn=config
objectClass: olcGlobal
cn: config
olcAllows: bind_v2
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcServerID: 1 ldap://192.168.1.103
olcServerID: 2 ldap://192.168.1.104
olcSizeLimit: 1000000
olcToolThreads: 1
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModulePath: /usr/lib/ldap
dn: olcBackend={0}hdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}hdb
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=extern
al,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.exact="uid=syncrepl,dc=tracteur91,dc=local" read by
* break
olcAccess: {1}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
al,cn=auth manage by * break
olcLimits: {0}dn.exact="uid=syncrepl,dc=tracteur91,dc=local" size=unlimited
olcMirrorMode: TRUE
olcRootDN: cn=admin,cn=config
olcRootPW: {MD5}BkY718PMIcgBNjpfXmGpOA==
olcSyncrepl: {0}rid=001 provider="ldap://192.168.1.103" searchbase="cn=confi
g" type=refreshAndPersist bindmethod=simple binddn="uid=syncrepl,dc=tracteu
r91,dc=local" credentials="Tr@cteur91" retry="30 +" network-timeout=5 timeo
ut=30
olcSyncrepl: {1}rid=002 provider="ldap://192.168.1.104" searchbase="cn=confi
g" type=refreshAndPersist bindmethod=simple binddn="uid=syncrepl,dc=tracteu
r91,dc=local" credentials="Tr@cteur91" retry="30 +" network-timeout=5 timeo
ut=30
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 5
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to * by dn.exact="uid=syncrepl,dc=tracteur91,dc=local" read by
* break
olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by dn="cn=admin,dc=tracteur91,dc=local" write by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by self write by dn="cn=admin,dc=tracteur91,dc=local" wri
te by * read
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: ou eq
olcDbIndex: dc eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcLastMod: TRUE
olcLimits: {0}dn.exact="uid=syncrepl,dc=tracteur91,dc=local" size=unlimited
olcMirrorMode: TRUE
olcRootDN: cn=admin,dc=tracteur91,dc=local
olcRootPW: {SSHA}ZtvvlHUQYloI17cv2/cjPFmx51+Ut/+5
olcSuffix: dc=tracteur91,dc=local
olcSyncrepl: {0}rid=003 provider="ldap://192.168.1.103" searchbase="dc=tract
eur91,dc=local" type=refreshAndPersist bindmethod=simple binddn="uid=syncre
pl,dc=tracteur91,dc=local" credentials="Tr@cteur91" retry="30 +" network-ti
meout=5 timeout=30
olcSyncrepl: {1}rid=004 provider="ldap://192.168.1.104" searchbase="dc=tract
eur91,dc=local" type=refreshAndPersist bindmethod=simple binddn="uid=syncre
pl,dc=tracteur91,dc=local" credentials="Tr@cteur91" retry="30 +" network-ti
meout=5 timeout=30
dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 5
11 years, 2 months
memberOf and glued databases
by Marc Patermann
Hi,
short question first:
Is overlay memberOf supposed to work with glued databases in any direction?
I tried with 2.4.28 and get the following results:
slapd.conf with two databases
1. step
-------
This is simple. MemberOf overlay only in one database
ou=groups,ou=foo,ou=bar (subordinated).
database hbd
suffix ou=groups,ou=foo,ou=bar
subordinate
...
overlay memberof
memberof-group-ac groupOfNames
memberof-member-ad member
memberof-memberof-ad memberof
database bdb
suffix ou=bar
...
- created one inetOrgPerson object
employeenumber=11,ou=groups,ou=foo,ou=bar
- created one group
ou=2,ou=groups,ou=foo,ou=bar
with
member: employeenumber=11,ou=groups,ou=foo,ou=bar
=> memberOf in employeenumber=11,ou=groups,ou=foo,ou=bar is set and
unset just fine.
=> no modifications in superior database ou=bar
2. step
-------
overlay loaded in both databases
database hbd
suffix ou=groups,ou=foo,ou=bar
subordinate
...
overlay memberof
memberof-group-ac groupOfNames
memberof-member-ad member
memberof-memberof-ad memberof
database bdb
suffix ou=bar
...
overlay memberof
memberof-group-ac groupOfNames
memberof-member-ad member
memberof-memberof-ad memberof
=> modification in the subordinated database work in 1. step.
- created one inetOrgPerson object
employeenumber=1,ou=bar
- created one group
ou=1,ou=bar
with
member: employeenumber=1,ou=bar
=> memberOf in employeenumber=1,ou=bar is set and unset just fine.
memberOf is working in the superior database.
- setting group ou=1,ou=bar
member: employeenumber=11,ou=groups,ou=foo,ou=bar
=> memberOf in employeenumber=11,ou=groups,ou=foo,ou=bar is set and
unset just fine.
Changes in groups of superior databases work in subordinate
databases!
- setting group ou=2,ou=groups,ou=foo,ou=bar
member: employeenumber=1,ou=bar
=> does _not_ work:
memberof_value_modify DN="employeenumber=1,ou=bar" add memberOf
="ou=2,ou=groups,ou=foo,ou=bar" failed err=32
Changes in groups of subordinated databases do not work in the
superior database!
3. step
-------
setting "overlay glue" explicitly and removing overlay memberof from the
subordinate database:
database hbd
suffix ou=groups,ou=foo,ou=bar
subordinate
...
database bdb
suffix ou=bar
...
overlay memberof
memberof-group-ac groupOfNames
memberof-member-ad member
memberof-memberof-ad memberof
overlay glue
=> changes in the subordinated database are _not_ managed by the
overlay.
=> changes in groups of superior databases work in subordinate
databases and in the superior database!
3. step II
----------
if glue is located in slapd.conf before memberof (which is IMHO wrong)
and MOD on member in a group in the subordinated database is send, slapd
segfaults!
4. step
-------
setting "overlay glue" explicitly and overlay memberof in both databases:
database hbd
suffix ou=groups,ou=foo,ou=bar
subordinate
...
overlay memberof
memberof-group-ac groupOfNames
memberof-member-ad member
memberof-memberof-ad memberof
database bdb
suffix ou=bar
...
overlay memberof
memberof-group-ac groupOfNames
memberof-member-ad member
memberof-memberof-ad memberof
overlay glue
=> like 2. step
So the best I get is
- memberOf works in the database, where it is set
- memberOf works for group changes in superior database on members in
subordinated databases
- memberOf does not work for group changes in subordinated databases to
members in superior databases.
Is this the way it is supposed to work?
What I really wanted to achieve is to get memerOf to work between
database (under glue) of the same level. (Like ou=1,ou=foo and
ou=2,ou=foo both subordinated of ou=foo.) But while my testings above
did not succeed, it did not tried.
Marc
11 years, 3 months
Changing schema OID values in cn=config
by Nick Milas
Hello,
In my config there is:
DN: cn={5}postfix,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {5}postfix
olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME
'mailacceptinggeneralid' DESC 'Defines an address that we accept mail
for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC
'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser'
DESC 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive'
DESC 'A flag, for marking the alias as not in use' EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount'
DESC 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $
mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $
aliasInactive ) )
olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC
'Virtual account for holding mailing list info' STRUCTURAL MUST (
mailacceptinggeneralid $ maildrop $ cn ) MAY ( owner $ description $
aliasInactive ) )
olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC
'Email account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $
cn ) MAY ( mailacceptinggeneralid $ aliasInactive ) )
olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC
'Mailbox for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY
description )
When I try to change attribute OID value, for example:
1.3.6.1.4.1.25260.1.000 to 1.3.6.1.4.1.25260.1.0 (using a visual LDAP
client) then the server hangs and will not restart. (I had to restore
from backup and restart.)
What is the recommended way to do this change?
Thanks,
Nick
11 years, 3 months
OpenLDAP 2.4.23 killed by linux oom-killer
by Igor Zinovik
Hello, openldap-technical@ readers.
I'm running openSUSE 11.4 with openldap 2.4.23 and libdb-4_8
(berkeleydb) in vmware environment.
Last friday my slapd was killed by oom killer. Seems that it consumed
all available memory. It is
the first time i see that openldap was killed.
My database is rather small (15953 entries, 22 mb on disk id2entry.bdb
+ dn2id.bdb).
Could somebody point me to place where i can limit memory usage in openldap?
Here is part of log:
Jan 20 18:23:42 ldap kernel: [5636879.604870] slapd invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jan 20 18:23:42 ldap kernel: [5636879.604894] slapd cpuset=/ mems_allowed=0
Jan 20 18:23:42 ldap kernel: [5636879.604905] Pid: 11984, comm: slapd
Not tainted 2.6.37.6-0.5-desktop #1
Jan 20 18:23:42 ldap kernel: [5636879.604907] Call Trace:
Jan 20 18:23:42 ldap kernel: [5636879.605070] [<ffffffff810059b9>]
dump_trace+0x79/0x340
Jan 20 18:23:42 ldap kernel: [5636879.605144] [<ffffffff81521752>]
dump_stack+0x69/0x6f
Jan 20 18:23:42 ldap kernel: [5636879.605207] [<ffffffff810fd4e2>]
dump_header+0xa2/0x240
Jan 20 18:23:42 ldap kernel: [5636879.605234] [<ffffffff810fdbe4>]
oom_kill_process+0xa4/0x1d0
Jan 20 18:23:42 ldap kernel: [5636879.605246] [<ffffffff810fe03c>]
out_of_memory+0x10c/0x250
Jan 20 18:23:42 ldap kernel: [5636879.605251] [<ffffffff811030bb>]
__alloc_pages_nodemask+0x6fb/0x710
Jan 20 18:23:42 ldap kernel: [5636879.605281] [<ffffffff81139089>]
alloc_pages_current+0x99/0x110
Jan 20 18:23:42 ldap kernel: [5636879.605302] [<ffffffff81105bb1>]
__do_page_cache_readahead+0xe1/0x230
Jan 20 18:23:42 ldap kernel: [5636879.605313] [<ffffffff8110603c>]
ra_submit+0x1c/0x30
Jan 20 18:23:42 ldap kernel: [5636879.605317] [<ffffffff810fc937>]
filemap_fault+0x487/0x4a0
Jan 20 18:23:42 ldap kernel: [5636879.605337] [<ffffffff8111c202>]
__do_fault+0x52/0x560
Jan 20 18:23:42 ldap kernel: [5636879.605349] [<ffffffff81120cd1>]
handle_mm_fault+0x1a1/0x410
Jan 20 18:23:42 ldap kernel: [5636879.605369] [<ffffffff81527dd9>]
do_page_fault+0x1a9/0x520
Jan 20 18:23:42 ldap kernel: [5636879.605382] [<ffffffff8152520f>]
page_fault+0x1f/0x30
Jan 20 18:23:42 ldap kernel: [5636879.605481] [<00007ff68a86fffe>]
0x7ff68a86fffe
Jan 20 18:23:42 ldap kernel: [5636879.605483] Mem-Info:
Jan 20 18:23:42 ldap kernel: [5636879.605485] Node 0 DMA per-cpu:
Jan 20 18:23:42 ldap kernel: [5636879.605490] CPU 0: hi: 0,
btch: 1 usd: 0
Jan 20 18:23:42 ldap kernel: [5636879.605491] Node 0 DMA32 per-cpu:
Jan 20 18:23:42 ldap kernel: [5636879.605493] CPU 0: hi: 186,
btch: 31 usd: 31
Jan 20 18:23:42 ldap kernel: [5636879.605498] active_anon:55520
inactive_anon:55653 isolated_anon:0
Jan 20 18:23:42 ldap kernel: [5636879.605499] active_file:75
inactive_file:114 isolated_file:96
Jan 20 18:23:42 ldap kernel: [5636879.605500] unevictable:0 dirty:18
writeback:10 unstable:0
Jan 20 18:23:42 ldap kernel: [5636879.605500] free:1190
slab_reclaimable:1125 slab_unreclaimable:3921
Jan 20 18:23:42 ldap kernel: [5636879.605501] mapped:59 shmem:8
pagetables:4707 bounce:0
Jan 20 18:23:42 ldap kernel: [5636879.605503] Node 0 DMA free:2044kB
min:84kB low:104kB high:124kB active_anon:6072kB inactive_anon:6424kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:15684kB mlocked:0kB dirty:4kB writeback:0kB
mapped:8kB shmem:0kB slab_reclaimable:28kB slab_unreclaimable:588kB
kernel_stack:360kB pagetables:268kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:1 all_unreclaimable? yes
Jan 20 18:23:42 ldap kernel: [5636879.605515] lowmem_reserve[]: 0 489 489 489
Jan 20 18:23:42 ldap kernel: [5636879.605518] Node 0 DMA32 free:2716kB
min:2784kB low:3480kB high:4176kB active_anon:216008kB
inactive_anon:216188kB active_file:300kB inactive_file:456kB
unevictable:0kB isolated(anon):0kB isolated(file):384kB
present:500896kB mlocked:0kB dirty:68kB writeback:40kB mapped:228kB
shmem:32kB slab_reclaimable:4472kB slab_unreclaimable:15096kB
kernel_stack:1032kB pagetables:18560kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:1154 all_unreclaimable? yes
Jan 20 18:23:42 ldap kernel: [5636879.605527] lowmem_reserve[]: 0 0 0 0
Jan 20 18:23:42 ldap kernel: [5636879.605529] Node 0 DMA: 77*4kB 3*8kB
1*16kB 1*32kB 0*64kB 1*128kB 0*256kB 1*512kB 1*1024kB 0*2048kB
0*4096kB = 2044kB
Jan 20 18:23:42 ldap kernel: [5636879.605542] Node 0 DMA32: 677*4kB
1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 2716kB
Jan 20 18:23:42 ldap kernel: [5636879.605550] 20332 total pagecache pages
Jan 20 18:23:42 ldap kernel: [5636879.605551] 20056 pages in swap cache
Jan 20 18:23:42 ldap kernel: [5636879.605553] Swap cache stats: add
681283, delete 661227, find 13544302/13638161
Jan 20 18:23:42 ldap kernel: [5636879.605555] Free swap = 0kB
Jan 20 18:23:42 ldap kernel: [5636879.605556] Total swap = 262140kB
Jan 20 18:23:42 ldap kernel: [5636879.608604] 131056 pages RAM
Jan 20 18:23:42 ldap kernel: [5636879.608607] 5288 pages reserved
Jan 20 18:23:42 ldap kernel: [5636879.608609] 33759 pages shared
Jan 20 18:23:42 ldap kernel: [5636879.608610] 122516 pages non-shared
Jan 20 18:23:42 ldap kernel: [5636879.608612] [ pid ] uid tgid
total_vm rss cpu oom_adj oom_score_adj name
Jan 20 18:23:42 ldap kernel: [5636879.608627] [ 320] 0 320
5295 1 0 -17 -1000 udevd
Jan 20 18:23:42 ldap kernel: [5636879.608634] [ 816] 100 816
6904 1 0 0 0 dbus-daemon
Jan 20 18:23:42 ldap kernel: [5636879.608638] [ 1902] 0 1902
60161 1038 0 0 0 radiusd
Jan 20 18:23:42 ldap kernel: [5636879.608641] [ 1949] 0 1949
5142 28 0 0 0 master
Jan 20 18:23:42 ldap kernel: [5636879.608644] [ 1971] 51 1971
5225 26 0 0 0 qmgr
Jan 20 18:23:42 ldap kernel: [5636879.608648] [ 2030] 0 2030
3871 21 0 0 0 cron
Jan 20 18:23:42 ldap kernel: [5636879.608651] [ 2034] 0 2034
4179 16 0 0 0 rpcbind
Jan 20 18:23:42 ldap kernel: [5636879.608654] [ 2044] 0 2044
20429 76 0 0 0 vmtoolsd
Jan 20 18:23:42 ldap kernel: [5636879.608658] [ 2045] 0 2045
992 0 0 0 0 startpar
Jan 20 18:23:42 ldap kernel: [5636879.608661] [ 2049] 0 2049
990 2 0 0 0 mingetty
Jan 20 18:23:42 ldap kernel: [5636879.608664] [ 2050] 0 2050
990 2 0 0 0 mingetty
Jan 20 18:23:42 ldap kernel: [5636879.608667] [ 2051] 0 2051
990 2 0 0 0 mingetty
Jan 20 18:23:42 ldap kernel: [5636879.608670] [ 2052] 0 2052
990 2 0 0 0 mingetty
Jan 20 18:23:42 ldap kernel: [5636879.608674] [ 2053] 0 2053
990 2 0 0 0 mingetty
Jan 20 18:23:42 ldap kernel: [5636879.608677] [ 2054] 0 2054
990 2 0 0 0 mingetty
Jan 20 18:23:42 ldap kernel: [5636879.608689] [24805] 74 24805
3944 32 0 0 0 ntpd
Jan 20 18:23:42 ldap kernel: [5636879.608692] [24855] 0 24855
11339 27 0 -17 -1000 sshd
Jan 20 18:23:42 ldap kernel: [5636879.608695] [28273] 0 28273
29976 90 0 0 0 rsyslogd
Jan 20 18:23:42 ldap kernel: [5636879.608699] [ 5665] 105 5665
4121 9 0 0 0 nrpe
Jan 20 18:23:42 ldap kernel: [5636879.608702] [29623] 0 29623
2844 0 0 0 0 mysqld_safe
Jan 20 18:23:42 ldap kernel: [5636879.608706] [29744] 60 29744
55304 999 0 0 0 mysqld
Jan 20 18:23:42 ldap kernel: [5636879.608709] [30102] 0 30102
5294 2 0 -17 -1000 udevd
Jan 20 18:23:42 ldap kernel: [5636879.608713] [30103] 0 30103
5294 1 0 -17 -1000 udevd
Jan 20 18:23:42 ldap kernel: [5636879.608717] [30788] 0 30788
4127 1 0 0 0 automount
Jan 20 18:23:42 ldap kernel: [5636879.608721] [31053] 0 31053
31139 6849 0 0 0 puppetd
Jan 20 18:23:42 ldap kernel: [5636879.608724] [10627] 0 10627
63600 828 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608727] [23310] 76 23310
300113 76212 0 0 0 slapd
Jan 20 18:23:42 ldap kernel: [5636879.608737] [32555] 51 32555
13882 166 0 0 0 pickup
Jan 20 18:23:42 ldap kernel: [5636879.608742] [ 1137] 30 1137
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608745] [ 1156] 30 1156
67563 1004 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608748] [ 1158] 30 1158
67563 1004 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608752] [ 1160] 30 1160
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608755] [ 1161] 30 1161
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608758] [ 1164] 30 1164
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608761] [ 1166] 30 1166
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608765] [ 1169] 30 1169
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608769] [ 1171] 30 1171
67563 1005 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608777] [ 1172] 30 1172
67563 1003 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608780] [ 1175] 30 1175
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608786] [ 1181] 30 1181
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608789] [ 1183] 30 1183
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608792] [ 1188] 30 1188
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608795] [ 1189] 30 1189
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608798] [ 1190] 30 1190
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608802] [ 1191] 30 1191
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608805] [ 1192] 30 1192
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608808] [ 1193] 30 1193
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608811] [ 1194] 30 1194
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608814] [ 1195] 30 1195
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608822] [ 1196] 30 1196
67563 1001 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608825] [ 1197] 30 1197
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608829] [ 1198] 30 1198
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608832] [ 1199] 30 1199
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608835] [ 1200] 30 1200
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608838] [ 1201] 30 1201
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608841] [ 1202] 30 1202
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608844] [ 1203] 30 1203
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608847] [ 1204] 30 1204
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608851] [ 1205] 30 1205
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608859] [ 1206] 30 1206
67563 1003 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608862] [ 1207] 30 1207
67563 999 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608865] [ 1208] 30 1208
57304 1069 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608868] [ 1209] 30 1209
67563 963 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608872] [ 1210] 30 1210
67563 962 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608875] [ 1211] 30 1211
67563 963 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608878] [ 1212] 30 1212
67563 963 0 0 0 httpd2-prefork
Jan 20 18:23:42 ldap kernel: [5636879.608906] Out of memory: Kill
process 23310 (slapd) score 685 or sacrifice child
Jan 20 18:23:42 ldap kernel: [5636879.608912] Killed process 23310
(slapd) total-vm:1200452kB, anon-rss:304848kB, file-rss:0kB
Jan 20 18:23:42 ldap kernel: [5636879.645240] httpd2-prefork invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jan 20 18:23:42 ldap kernel: [5636879.645250] httpd2-prefork cpuset=/
mems_allowed=0
Jan 20 18:23:42 ldap kernel: [5636879.645254] Pid: 1206, comm:
httpd2-prefork Not tainted 2.6.37.6-0.5-desktop #1
Jan 20 18:23:42 ldap kernel: [5636879.645256] Call Trace:
Jan 20 18:23:42 ldap kernel: [5636879.645279] [<ffffffff810059b9>]
dump_trace+0x79/0x340
Jan 20 18:23:42 ldap kernel: [5636879.645285] [<ffffffff81521752>]
dump_stack+0x69/0x6f
Jan 20 18:23:42 ldap kernel: [5636879.645291] [<ffffffff810fd4e2>]
dump_header+0xa2/0x240
Jan 20 18:23:42 ldap kernel: [5636879.645296] [<ffffffff810fdbe4>]
oom_kill_process+0xa4/0x1d0
Jan 20 18:23:42 ldap kernel: [5636879.645301] [<ffffffff810fe03c>]
out_of_memory+0x10c/0x250
Jan 20 18:23:42 ldap kernel: [5636879.645305] [<ffffffff811030bb>]
__alloc_pages_nodemask+0x6fb/0x710
11 years, 3 months
Search on whole tree gives result, search on subtree not
by Karsten Heymann
Hi,
I've started playing around with slapd (2.4.23-7.2 from debian
squeeze) again and stumbled across a very strange phenomenon: When
searching the whole tree for an entry it is found immediately:
0|kheymann@ds1-01:~$ ldapsearch -x -h localhost -b o=mycompany uid=aaa uid
# extended LDIF
#
# LDAPv3
# base <o=mycompany> with scope subtree
# filter: uid=aaa
# requesting: uid
#
# aaa, 2, customers, marketing, mycompany
dn: uid=aaa,contractID=2,ou=customers,ou=marketing,o=mycompany
uid: aaa
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
But when searching any of the intermediate subtrees, no result is
returned after a short delay:
0|kheymann@ds1-01:~$ ldapsearch -x -h localhost -b
ou=marketing,o=mycompany uid=aaa uid
# extended LDIF
#
# LDAPv3
# base <ou=tc,o=mycompany> with scope subtree
# filter: uid=aaa
# requesting: uid
#
# search result
search: 2
result: 0 Success
# numResponses: 1
The uid attribute is indexed with
0|root@ds1-01:/etc/ldap/slapd.d/cn=config# grep -e ' uid ' *ldif
olcDatabase={1}hdb.ldif:olcDbIndex: uid eq
and slapindex generated the index without any error messages. This
also seems to happen only with entries created while the slapd is
running while the entries from the initial import do not whoe this.
This seems very weird to me. Any hints what could cause this behaviour
and what could possibly fix it?
Thanks in advance,
Karsten
11 years, 4 months