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, 6 months
Re: (ITS#6666) Feature Request: Triggers implementation
by Buchan Milne
On Thursday, 7 October 2010 20:32:49 Nick Milas wrote:
> It all started for me when I wanted to watch a serial number value from
> an ldap-stored SOArecord (using powerdns with openldap backend) and when
> it changes to fire a bash script. I reached the conclusion it was not
> easy to be done with higher-level means within openldap and I created a
> bash script which scans (using ldapsearch and other linux tools) the
> SOArecords regularly (using cron) to find out if any change has happend
> and do whatever is required. It would be much more elegant if I could
> get a trigger from openldap when the SOArecord changes.
Maybe you need this:
http://memberwebs.com/stef/software/slapi-dnsnotify/
A more generic solution would be nice, but as far as I can tell, this software
satisfies your current need.
Regards,
Buchan
12 years, 6 months
Replication monitoring
by Andreas Andersson
Hi!
I posted an announcement here about a year ago about my little LDAP monitoring project CN=Monitor.
Asked for feedback and received a lot. Thank you! Some feedback was related to adding replication verification for OpenLDAP so of course I gave it a try.
Unfortunately I don’t have a large scale OpenLDAP environment to verify this functionality on so I need your help :)
Is it working and can it be improved?
This is how it works:
The contextCSN is verified on all servers within the same environment. See attached image.
As always… I appreciate all feedback I can get and let me know if you have any suggestions on new features or something else that can approve this monitoring application.
Project page:
http://cnmonitor.sourceforge.net
Freshmeat:
http://freshmeat.net/projects/cnmonitor
Best Regards - Andreas
12 years, 9 months
Problem unexpected failing slapd
by Ruud Baart
Problem:
For a customer we use LDAP for many years. Last year suddenly the slapd
service just stopped without any traces in the logfiles. After a restart
of slapd everything works fine again. But the problem was there: it was
not an incident, now and then slapd just stops and always without any
traces in the logfiles. Sometime three times a day, sometime a week
without a failure. I can't find a pattern or any relation to any other
service on the linux server.
Environment:
- Several (debian squeeze) servers , several windows servers. We use bdb
database backend.
- There is one master LDAP server which provides syncprov and two
replica's LDAP servers (syncrepl). The master server is most intens used
(mainly samba as primary domain controller: a few hundred useraccounts,
lot of groupaccounts, workstations, acl's, etc.), one of the replica's
is not very busy but handles the mail for all users (lookup: amavis,
postfix, courier-imap, mailaccount settings etc). The third replica is
not busy at all, it is a remote location.
- Total LDAP is 3700 dn's, slapcat produces a file of 7,3 Mb.
- It is only the master LDAP with stops suddenly. I have never seen a
failure of a replica LDAP.
Because I have no clear idea about the problem I have no idea which
technical details are relevant:
DB_CONFIG
===========
set_cachesize 0 10485760 1
set_lk_max_objects 10000
set_lk_max_locks 10000
set_lk_max_lockers 10000
set_lg_dir /home/ldap-dbd
The database is stored on a ext3 filesystem, kernel 2.6.32. The server
has no problems, plenty of memory and a fast diskarray (SAS->SATA).
Never technical problems with this server. And it worked without
problems for a long period. Nothing has changed to the environment or
the LDAP setup (except of course with the upgrade to debian squeeze but
the problem was already there).
What we have tried:
- upgrade from openldap 2..4.17 (debian lenny+backports) to openldap
2.4.23 (debian squeeze). I saw in the release notes that problems
related to syncrepl were solved. Therefor we waited for version 2.4.23
te become available in debian. This upgrade made no difference.
- reindex, rebuilt the directory. When I rebuilt the LDAP with a clean
LDIF file on the master LDAP or an other machine with ldapadd there is
not one error or warning.
The workaround for the moment:
I have written a process monitor (perl daemon) which monitors the slapd
daemon and if it suddenly stops, slapd is restarted. It is of course not
a solution but the 300 user can work. If slapd stops without a restart
within 1 minute a few hundred people can't work because samba stops working.
I would like to receive suggestions what we can do to find the problem.
Because there is no pattern, nothing in the logfiles I don't know where
to start.
--
Regards,
Ruud Baart
12 years, 9 months
slapd 2.2.24 will not start as non root user
by Iain M Conochie
Good Afternoon,
I am attempting to upgrade my openldap 2.4.x installation to the latest
release 2.4.24. I am compiling from source. I can start slapd as the
root user but I am unable to start as a non-root user (e.g. ldap). I am
receiving the following error message:
/opt/openldap/libexec/slapd -u ldap -g ldap -h ldap://XXXXX.XXXXXXXX.XXX
slapd: sbind.c:76: ldap_simple_bind: Assertion `(
(ld)->ld_options.ldo_valid == 0x2 )' failed.
Aborted
Is the server attempting to bind to another ldap server? This is the
"secondary" server on the network an I have the main LDAP server in
/etc/ldap.conf. Running an strace I do see slapd referencing this file:
open("/etc/ldap.conf", O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=919, ...}) = 0
fstat64(8, {st_mode=S_IFREG|0644, st_size=919, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7fa1000
read(8, "#\n# LDAP Defaults\n#\n\n# See ldap."..., 4096) = 919
read(8, "", 4096) = 0
close(8) = 0
munmap(0xb7fa1000, 4096) = 0
stat64("/etc/ldap.conf", {st_mode=S_IFREG|0644, st_size=919, ...}) = 0
geteuid32() = 0
brk(0x82b2000) = 0x82b2000
stat64("/etc/ldap.conf", {st_mode=S_IFREG|0644, st_size=919, ...}) = 0
geteuid32() = 0
write(2, "slapd: sbind.c:76: ldap_simple_b"..., 95slapd: sbind.c:76:
ldap_simple_bind: Assertion `( (ld)->ld_options.ldo_valid == 0x2 )'
failed.
) = 95
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(9691, 9691, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
Process 9691 detached
Does anyone have any ideas here?
Regards
Iain M Conochie
12 years, 9 months
Poor performance on Solaris
by Juergen.Sprenger＠swisscom.com
Hi,
we had some performance issues on our ldap servers running Solaris 10 sparc.
I did some tests using slamd http://www.slamd.com/ and got disturbing results:
ldap-service: OpenLDAP 2.4.23, setup identical on both boxes, threads=64, identical content.
box1:
hardware: Sun Microsystems sun4v SPARC Enterprise T5120
memory:32 GB RAM
os: Solaris 10 s10s_u9wos_14a
searches (avg/second): 1521
box2:
hardware: AMD 64 phenom 9850
memory: 8 GB RAM
os: Linux dsv00000 2.6.36.2 #1 SMP Mon Dec 27 10:09:29 CET 2010 x86_64 AMD Phenom(tm) 9850 Quad-Core Processor AuthenticAMD GNU/Linux
searches (avg/second): 22968
I am looking for some hints to improve performance on box1 to a similar level as on box2 or an explanation why on box1 performance is so bad.
As slapd.conf, ldap.conf and DB_CONFIG are identical there should not be such a big gap in performance.
Juergen Sprenger
12 years, 9 months
Re: Problem unexpected failing slapd
by jekvb＠gmx.co.uk
"...now and then slapd just stops and always without any
traces in the logfiles. Sometime three times a day, sometime a week
without a failure. I can't find a pattern or any relation to any other
service on the linux server."
Is your LDAP environment installed on a VM or on plain metal box?
Regards, Kuba
----- Original Message -----
From: Ruud Baart
Sent: 27/02/11 12:57 PM
To: openldap-technical(a)openldap.org
Subject: Problem unexpected failing slapd
Problem: For a customer we use LDAP for many years. Last year suddenly the slapd service just stopped without any traces in the logfiles. After a restart of slapd everything works fine again. But the problem was there: it was not an incident, now and then slapd just stops and always without any traces in the logfiles. Sometime three times a day, sometime a week without a failure. I can't find a pattern or any relation to any other service on the linux server. Environment: - Several (debian squeeze) servers , several windows servers. We use bdb database backend. - There is one master LDAP server which provides syncprov and two replica's LDAP servers (syncrepl). The master server is most intens used (mainly samba as primary domain controller: a few hundred useraccounts, lot of groupaccounts, workstations, acl's, etc.), one of the replica's is not very busy but handles the mail for all users (lookup: amavis, postfix, courier-imap, mailaccount settings etc). The third replica is not busy at all, it is a remote location. - Total LDAP is 3700 dn's, slapcat produces a file of 7,3 Mb. - It is only the master LDAP with stops suddenly. I have never seen a failure of a replica LDAP. Because I have no clear idea about the problem I have no idea which technical details are relevant: DB_CONFIG =========== set_cachesize 0 10485760 1 set_lk_max_objects 10000 set_lk_max_locks 10000 set_lk_max_lockers 10000 set_lg_dir /home/ldap-dbd The database is stored on a ext3 filesystem, kernel 2.6.32. The server has no problems, plenty of memory and a fast diskarray (SAS->SATA). Never technical problems with this server. And it worked without problems for a long period. Nothing has changed to the environment or the LDAP setup (except of course with the upgrade to debian squeeze but the problem was already there). What we have tried: - upgrade from openldap 2..4.17 (debian lenny+backports) to openldap 2.4.23 (debian squeeze). I saw in the release notes that problems related to syncrepl were solved. Therefor we waited for version 2.4.23 te become available in debian. This upgrade made no difference. - reindex, rebuilt the directory. When I rebuilt the LDAP with a clean LDIF file on the master LDAP or an other machine with ldapadd there is not one error or warning. The workaround for the moment: I have written a process monitor (perl daemon) which monitors the slapd daemon and if it suddenly stops, slapd is restarted. It is of course not a solution but the 300 user can work. If slapd stops without a restart within 1 minute a few hundred people can't work because samba stops working. I would like to receive suggestions what we can do to find the problem. Because there is no pattern, nothing in the logfiles I don't know where to start. -- Regards, Ruud Baart
12 years, 9 months
Help needed with opeLDAP configuration
by sim123
Dear All,
I am new to LDAP and openLDAP, just installed and configured openLDAP 2.4.23
with Berkeley DB 4.8 on CentOS 5.4 using
http://www.openldap.org/doc/admin24/quickstart.html
make test gave an error on replication similar to this
http://www.openldap.org/lists/openldap-technical/201006/msg00256.html
So I think installation is correct but when I try to do a search as
described in the article, result is :
# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=example,dc=com
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Can someone please help me identifying the problem. Thanks for the help and
support.
12 years, 9 months
Re: Help needed with opeLDAP configuration
by sim123
Thanks for your response, I did ignore the error. However, the search result
is empty, not sure what could go wrong. my sladp.conf file is same as
described in quick start guide.
Thanks.
On Fri, Feb 25, 2011 at 12:36 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Friday, February 25, 2011 11:36 AM -0800 sim123 <Sim3159(a)gmail.com>
> wrote:
>
> Dear All,
>>
>>
>> I am new to LDAP and openLDAP, just installed and configured openLDAP
>> 2.4.23 with Berkeley DB 4.8 on CentOS 5.4
>> using http://www.openldap.org/doc/admin24/quickstart.html
>>
>> make test gave an error on replication similar to
>> this http://www.openldap.org/lists/openldap-technical/201006/msg00256.ht
>> ml
>>
>> So I think installation is correct but when I try to do a search as
>> described in the article, result is :
>>
>
> As noted repeatedly, even by the test itself, you should ignore any errors
> from test058. That's why it exists with success.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
12 years, 9 months
sortvals oddities - with more information and hopefully to the right list
by Andrew Elble
We are using sortvals on both member and memberUid. We have been
seeing duplicate member/memberUid attributes on some objects that have
been modified (as well as a lack of sorting on those attributes). It
seemed that there was a correlation between modifies to objects that
experienced deadlocks and the objects that had duplicate
member/memberUid attributes on them. We put the seqmod overlay in
place - and this reduced the number of occurrences of the issue but
did not eliminate them.
Upon further investigation, I discovered that it was possible to
bypass the sorting behavior if the object was not created with an
instance of the attribute with sorting enabled as a part of it.
It would seem that attr_merge() (in attr.c) should have something like this:
if ( *a == NULL ) {
*a = attr_alloc( desc );
if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) {
(*a)->a_flags |= SLAP_ATTR_SORTED_VALS;
}
} else {
Further pursuing the issue, I started to focus on the index deletion
code that was changed as a part of ITS#5183. Specifically, the
portion of code within bdb_modify_internal() (in back-bdb/modify.c)
that is commented:
/* Move deleted values to end of array */
This code modifies save_attrs, which is actually apparently a pointer
to memory that resides within the cache. If a deadlock occurs, these
changes are not reverted, thereby corrupting the entry in the cache. I
replaced this code with the pre-ITS#5183 code and I am no longer able
to 'break' the object and insert duplicate member/memberUids.
I also found it surprising that the call to bdb_idl_cache_del() in
bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to
the database?
I can answer any questions about the specifics of the environment
in which where we are seeing this - it is a somewhat difficult problem to
reproduce outside of our production environment. I'm not terribly
familiar with the code - I'm looking to see if I have collected enough
data here to open an ITS to have this fixed. (or if I'm just way off base)
Thanks,
Andy
--
Andrew W. Elble
aweits(a)discipline.rit.edu
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912
CONFIDENTIALITY NOTE: The information transmitted, including
attachments, is intended only for the person(s) or entity to which it
is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and destroy any
copies of this information.
12 years, 9 months
