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
OpenLDAP and dynalogin (two-factor auth with HOTP)
by Daniel Pocock
Some time ago I created the dynalogin ( http://www.dynalogin.org )
solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making it
convenient to use with OpenLDAP seems like a good strategy: can anyone
comment on that?
The initial thoughts that I have about the subject:
- SASL based solution (dynalogin has digest capability already, so it
could be adapted for SASL PLAIN or DIGEST-MD5)
- should not prevent password logins (user should be able to use either
password or HOTP code)
- should enable people to use it indirectly (e.g. if someone already has
pam_ldap working, they should be able to add dynalogin to their OpenLDAP
server and get immediate benefit)
- use cases: UNIX login, high-security webmail login, VPN and OpenID
provider backed by OpenLDAP
I know that SASL already supports OTP, but that is not HOTP, it is OPIE
(or S/Key) RFC 2289:
http://tools.ietf.org/html/rfc2289
whereas HOTP is RFC 4226:
http://www.ietf.org/rfc/rfc4226.txt
HOTP is considered more secure and more widely implemented.
8 years, 5 months
memberOf data in new replica servers 2.4.31
by Todd Stein
Hi,
I have a provider server and five consumer servers, all of which have the
memberOf overlay configured:
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
memberof-refint true
memberof-dangling ignore
syncrepl rid=005
provider=ldap://<server>:389
type=refreshAndPersist
interval=00:00:05:00
retry="60 10 600 +"
searchbase="dc=<removed>,dc=<removed>"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
starttls=no
bindmethod=simple
binddn="cn=replica,dc=<removed>,dc=<removed>"
credentials=<removed>
When I bring a new replica online, it appears that entries are replicated
in the order that they were created on the provider server which produces
many "memberof_value_modify failed err=32" messages in the log, and
incomplete memberOf data. To get around this, I wrote a script which
empties all groups prior to replication, and then recreates the memberships
after the initial replication. This seems to work, but is hardly ideal. Is
there a "more correct" way of replicating memberOf values without
manipulating my provider each time I bring up a new consumer?
Thank you very much,
Todd
11 years, 1 month
ldapsearch SASL/GSSAPI bind really slow
by Matthew B. Brookover
I am upgrading the openldap servers and ran into a bit of a problem.
SASL/GSSAPI binds to the new server are too slow. An ldapsearch to the
old server using GSSAPI to bind is much faster on the old server then
the same search on the new server.
I am not even sure where to start to debug this and am hoping that some
one will have some ideas.
First off, here are a few details:
The old LDAP server is running Openldap 2.3.43 on CentOS 5.2 with the
CentOS built MIT Kerberos(1.6.1) and saslauthd (2.1.22). This server is
configured with the slapd.conf file. The host name is
infinite.mines.edu in the example runs below.
The new LDAP server is running Openldap 2.4.31 on CentOS 6.3 with the
CentOS built MIT Kerberos (1.9) and saslauthd (2.1.23). This server is
configured with slapd-config (new dynamic configuration is very cool!)
The host name is infinte-temp.mines.edu in the example runs below.
Both the old and new servers are configured to use SASL for GSSAPI and
for simple binds.
First test, simple bind to new server and then the old server:
[testua@merlin ~]$ time ldapsearch -LLL -ZZ -Duid=testua,ou=People,dc=mines,dc=edu -y passwd -x -Hldap://infinite-temp.mines.edu/ -bou=People,dc=mines,dc=edu uid=testua
dn: uid=testua,ou=People,dc=mines,dc=edu
uid: testua
cn: estua, t
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12780
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
gidNumber: 11192
host: imagine.mines.edu
gecos: estua, t
homeDirectory: /u/ca/fl/testua
userPassword:: e1NBU0x9dGVzdHVhQE1JTkVTLkVEVQ==
uidNumber: 11192
real 0m0.324s
user 0m0.017s
sys 0m0.004s
[testua@merlin ~]$ time ldapsearch -LLL -ZZ -Duid=testua,ou=People,dc=mines,dc=edu -y passwd -x -Hldap://infinite.mines.edu/ -bou=People,dc=mines,dc=edu uid=testua
dn: uid=testua,ou=People,dc=mines,dc=edu
uid: testua
cn: estua, t
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12780
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
gidNumber: 11192
host: imagine.mines.edu
gecos: estua, t
homeDirectory: /u/ca/fl/testua
userPassword:: e1NBU0x9dGVzdHVhQE1JTkVTLkVEVQ==
uidNumber: 11192
real 0m0.163s
user 0m0.016s
sys 0m0.004s
[testua@merlin ~]$
As you can see, the new server takes nearly twice as long to perform the
search as the old server. Both servers are using saslauthd to send the
password to Kerberos for authentication.
Next test, GSSAPI bind to the new server and then the old server:
[testua@merlin ~]$ kinit
Password for testua(a)MINES.EDU:
[testua@merlin ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_11192_d1yOuC
Default principal: testua(a)MINES.EDU
Valid starting Expires Service principal
07/25/12 13:32:11 07/26/12 04:32:11 krbtgt/MINES.EDU(a)MINES.EDU
renew until 07/26/12 13:32:07
Kerberos 4 ticket cache: /tmp/tkt11192
klist: You have no tickets cached
[testua@merlin ~]$ time ldapsearch -LLL -ZZ -Hldap://infinite-temp.mines.edu/ -bou=People,dc=mines,dc=edu uid=testua
SASL/GSSAPI authentication started
SASL username: testua(a)MINES.EDU
SASL SSF: 56
SASL data security layer installed.
dn: uid=testua,ou=People,dc=mines,dc=edu
uid: testua
cn: estua, t
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12780
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
gidNumber: 11192
host: imagine.mines.edu
gecos: estua, t
homeDirectory: /u/ca/fl/testua
userPassword:: e1NBU0x9dGVzdHVhQE1JTkVTLkVEVQ==
uidNumber: 11192
real 0m1.145s
user 0m0.021s
sys 0m0.004s
[testua@merlin ~]$ time ldapsearch -LLL -ZZ -Hldap://infinite.mines.edu/ -bou=People,dc=mines,dc=edu uid=testua
SASL/GSSAPI authentication started
SASL username: testua(a)MINES.EDU
SASL SSF: 56
SASL data security layer installed.
dn: uid=testua,ou=People,dc=mines,dc=edu
uid: testua
cn: estua, t
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12780
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
gidNumber: 11192
host: imagine.mines.edu
gecos: estua, t
homeDirectory: /u/ca/fl/testua
userPassword:: e1NBU0x9dGVzdHVhQE1JTkVTLkVEVQ==
uidNumber: 11192
real 0m0.123s
user 0m0.021s
sys 0m0.003s
[testua@merlin ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_11192_d1yOuC
Default principal: testua(a)MINES.EDU
Valid starting Expires Service principal
07/25/12 13:32:11 07/26/12 04:32:11 krbtgt/MINES.EDU(a)MINES.EDU
renew until 07/26/12 13:32:07
07/25/12 13:32:33 07/26/12 04:32:11 ldap/infinite-temp.mines.edu(a)MINES.EDU
renew until 07/26/12 13:32:07
07/25/12 13:32:41 07/26/12 04:32:11 ldap/infinite.mines.edu(a)MINES.EDU
renew until 07/26/12 13:32:07
Kerberos 4 ticket cache: /tmp/tkt11192
klist: You have no tickets cached
[testua@merlin ~]$
The old server is 9 times faster then the new server.
This last test is to show that an anonymous bind is very fast and
indicates to me that the network, BDB, caching, etc are not the issue.
This test is to both servers, using a simple bind, first the old server
and then the new server:
[testua@merlin ~]$ time ldapsearch -LLL -ZZ -x -Hldap://infinite.mines.edu/ -bou=People,dc=mines,dc=edu uid=testua
dn: uid=testua,ou=People,dc=mines,dc=edu
uid: testua
cn: estua, t
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12780
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
gidNumber: 11192
host: imagine.mines.edu
gecos: estua, t
homeDirectory: /u/ca/fl/testua
userPassword:: e1NBU0x9dGVzdHVhQE1JTkVTLkVEVQ==
uidNumber: 11192
real 0m0.049s
user 0m0.017s
sys 0m0.005s
[testua@merlin ~]$ time ldapsearch -LLL -ZZ -x -Hldap://infinite-temp.mines.edu/ -bou=People,dc=mines,dc=edu uid=testua
dn: uid=testua,ou=People,dc=mines,dc=edu
uid: testua
cn: estua, t
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12780
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
gidNumber: 11192
host: imagine.mines.edu
gecos: estua, t
homeDirectory: /u/ca/fl/testua
userPassword:: e1NBU0x9dGVzdHVhQE1JTkVTLkVEVQ==
uidNumber: 11192
real 0m0.029s
user 0m0.014s
sys 0m0.006s
[testua@merlin ~]$
When using an anonymous bind, the old server takes longer then the new
server -- which is what I would expect given that the new server has
twice the number of faster processors and double the memory of the old
server.
Any ideas?
Thanks!
Matt
mbrookov(a)mines.edu
11 years, 3 months
In MirrorMode - proxy or external frontend needed?
by Pieter Baele
I've 2 servers in MirrorMode, a part of the tree wil also be partially
replicated to 3 slaves.
Do I really need an LDAP proxy or Load balancer(s) so writes are only
directed to one server?
In our LDAP, the number of writes will be very very low, most of them will
be reads (authentication, ssh keys, puppet nodes...)
Any benefit in using 'normal' n multimaster instead of MirrorMode?
11 years, 3 months
delta-syncrepl stopped receiving changes
by David Hawes
My environment consists of 1 provider and 6 consumer machines using
delta-syncrepl for replication. For some reason, one of the consumer
machines stopped receiving changes for several days and did not resume
syncing until a restart (SIGKILL).
All machines are running 2.4.30 with BerkeleyDB 4.7.25 (plus patches),
the hdb backend, and tcmalloc.
I notice that 2.4.31 has several syncrepl fixes, and I intend to upgrade
in the near future, but my issue seems different than the ITS issues
listed in the change log. I'm posting here to determine if this has been
fixed or if I need to create a new ITS issue.
When I noticed one of the machines was not syncing properly I first
ensured that I could still query it. When I verified that, I decided to
change the LogLevel to 'any' to make sure I wasn't missing any logs that
would help me figure out what the issue was. Unfortunately, this LDAP
modify caused OpenLDAP to hang. The operation never finished, and new
queries using ldapsearch would simply hang as well.
At this point I got a gdb backtrace and db_stat from BDB.
db_stat -c:
=====
Default locking region information:
640 Last allocated locker ID
0x7fffffff Current maximum unused locker ID
9 Number of lock modes
3000 Maximum number of locks possible
1500 Maximum number of lockers possible
1500 Maximum number of lock objects possible
80 Number of lock object partitions
47 Number of current locks
1262 Maximum number of locks at any one time
19 Maximum number of locks in any one bucket
0 Maximum number of locks stolen by for an empty partition
0 Maximum number of locks stolen for any one partition
340 Number of current lockers
341 Maximum number of lockers at any one time
44 Number of current lock objects
683 Maximum number of lock objects at any one time
6 Maximum number of lock objects in any one bucket
0 Maximum number of objects stolen by for an empty partition
0 Maximum number of objects stolen for any one partition
3799M Total number of locks requested (3799770221)
3799M Total number of locks released (3799714045)
0 Total number of locks upgraded
73 Total number of locks downgraded
73M Lock requests not available due to conflicts, for which we waited
(73026840)
5165 Lock requests not available due to conflicts, for which we did
not wait
50963 Number of deadlocks
0 Lock timeout value
0 Number of locks that have timed out
0 Transaction timeout value
0 Number of transactions that have timed out
1MB 400KB The size of the lock region
70M The number of partition locks that required waiting (1%)
15M The maximum number of times any partition lock was waited for (0%)
15018 The number of object queue operations that required waiting (0%)
54M The number of locker allocations that required waiting (2%)
0 The number of region locks that required waiting (0%)
6 Maximum hash bucket length
=====
The number of deadlocks was pretty shocking; I've never seen that value
non-zero.
I also have db_stat -C A output if that helps.
gdb (syncrepl thread):
=====
Thread 12 (Thread 0x444a9950 (LWP 16336)):
#0 0x00007f5e087f2b99 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#1 0x00007f5e08a274fb in __db_pthread_mutex_lock ()
from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so
#2 0x00007f5e08aa5dec in __lock_get_internal ()
from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so
#3 0x00007f5e08aa6d6a in __lock_vec ()
from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so
#4 0x00007f5e08aa72db in __lock_vec_pp ()
from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so
#5 0x000000000054da72 in hdb_cache_entry_db_relock (bdb=0xaec000,
txn=0x1031c20, ei=0x3d5e240, rw=1, tryOnly=0, lock=0x444a7b30)
at cache.c:198
#6 0x000000000054fe9e in hdb_cache_modify (bdb=0xaec000, e=0x7f5ccb945f58,
newAttrs=0x7f5ccf4c1ec0, txn=0x1031c20, lock=0x444a7b30) at cache.c:1231
#7 0x00000000004fc2bd in hdb_modify (op=0x444a86d0, rs=0x444a8040)
at modify.c:711
#8 0x00000000004db66f in overlay_op_walk (op=0x444a86d0, rs=0x444a8040,
which=op_modify, oi=0xace000, on=0x0) at backover.c:671
#9 0x00000000004db899 in over_op_func (op=0x444a86d0, rs=0x444a8040,
which=op_modify) at backover.c:723
#10 0x00000000004db9de in over_op_modify (op=0x444a86d0, rs=0x444a8040)
at backover.c:762
#11 0x00000000004c8c59 in syncrepl_message_to_op (si=0xb22000,
op=0x444a86d0,
msg=0x7f5cf7df5f80) at syncrepl.c:2316
#12 0x00000000004c40dd in do_syncrep2 (op=0x444a86d0, si=0xb22000)
at syncrepl.c:986
#13 0x00000000004c61a6 in do_syncrepl (ctx=0x444a8df0, arg=0xb768c0)
at syncrepl.c:1522
#14 0x0000000000449003 in connection_read_thread (ctx=0x444a8df0, argv=0x31)
at connection.c:1288
#15 0x0000000000591269 in ldap_int_thread_pool_wrapper (xpool=0xa741c0)
at tpool.c:688
#16 0x00007f5e087ee3f7 in start_thread () from /lib/libpthread.so.0
#17 0x00007f5e0794dbbd in clone () from /lib/libc.so.6
#18 0x0000000000000000 in ?? ()
=====
gdb (thread modifying cn=config):
=====
Thread 3 (Thread 0x48cb2950 (LWP 29597)):
#0 0x00007f5e087f2b99 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#1 0x0000000000592806 in ldap_pvt_thread_cond_wait (cond=0xa74220,
mutex=0xa741c8) at thr_posix.c:277
#2 0x000000000059162f in handle_pause (tpool=0x8b5420, pause_type=96)
at tpool.c:788
#3 0x00000000005916fa in ldap_pvt_thread_pool_pause (tpool=0x8b5420)
at tpool.c:831
#4 0x0000000000433ac4 in config_back_modify (op=0x7f5cdc507800,
rs=0x48cb1c90)
at bconfig.c:5837
#5 0x0000000000468e52 in fe_op_modify (op=0x7f5cdc507800, rs=0x48cb1c90)
at modify.c:303
#6 0x0000000000468761 in do_modify (op=0x7f5cdc507800, rs=0x48cb1c90)
at modify.c:177
#7 0x0000000000448a65 in connection_operation (ctx=0x48cb1df0,
arg_v=0x7f5cdc507800) at connection.c:1150
#8 0x0000000000448fe7 in connection_read_thread (ctx=0x48cb1df0, argv=0x15)
at connection.c:1286
#9 0x0000000000591269 in ldap_int_thread_pool_wrapper (xpool=0xa741c0)
at tpool.c:688
#10 0x00007f5e087ee3f7 in start_thread () from /lib/libpthread.so.0
#11 0x00007f5e0794dbbd in clone () from /lib/libc.so.6
#12 0x0000000000000000 in ?? ()
=====
I also have bt full output if needed.
Since restarting I have seen no issues with any of the instances and the
failed instance synced without issue.
Let me know if I should create an ITS.
Thanks,
Dave
11 years, 3 months
import ldif does not work
by Karntol Dernsef
Hi list,
I am fighting with openldap for some time now and I can't get it to work.
I started clean.
I've followed this tutorial, and everything works fine.
I used followed the example and only changed dc=company,dc=com into
dc=mycompany,dc=org.
Then I want to import this file, because I am busy with a WebSphere book
from Packtpub, and I need to follow along and setting up a LDAP server with
these contents:
--------------------------
dn: o=mycompany.org
objectclass: top
objectclass: organization
o: mycompany.org
dn: ou=users,o=mycompany.org
objectclass:organizationalunit
ou: users
description: generic users branch
dn: ou=groups,o=mycompany.org
objectclass:organizationalunit
ou: groups
description: generic groups branch
dn: ou=roles,o=mycompany.org
objectclass:organizationalunit
ou: roles
description: generic roles branch
dn: cn=wasadmin,ou=roles,o=mycompany.org
cn: wasadmin
uid: wasadmin
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
userpassword: wasadmin
sn: wasadmin
givenname: wasadmin
title: wasadmin
description: WAS Administrator
dn: cn=ldapbind,ou=users,o=mycompany.org
cn: ldapbind
uid: ldapbind
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
userpassword: ldapbind
sn: ldapbind
givenname: ldapbind
title: ldapbind
description: ldapbind
dn: cn=Bob Jackson,ou=users,o=mycompany.org
cn: Bob Jackson
uid: bjackson
mail: bjackson(a)mycompany.org
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
userpassword: password
sn: Jackson
givenname: Bob
telephonenumber: 123456789
title: WAS Administrator
description: LDAP test user
dn: cn=Mary Smith,ou=users,o=mycompany.org
cn: Mary Smith
uid: msmith
mail: msmith(a)mycompany.org
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
userpassword: password
sn: Smith
givenname: Mary
telephonenumber: 123456789
title: WAS Administrator
description: LDAP test user
dn: cn=wasadmins,ou=groups,o=mycompany.org
objectclass: groupofnames
cn: wasadmins
description: WAS Admins
# add the group members all of which are
# assumed to exist under people
member: cn=Bob Jackson,ou=users,o=mycompany.org
member: cn=Mary Smith,ou=users,o=mycompany.org
member: cn=wasadmin,ou=roles,o=mycompany.org
But when I want to import, I get this:
[root@CentOS-01 cn=config]# ldapadd -W -D cn=admin,dc=mycompany,dc=org -v
-x -f /tmp/mycompanyorg.ldif
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
add objectclass:
top
organization
add o:
mycompany.org
adding new entry "o=mycompany.org"
ldap_add: Server is unwilling to perform (53)
additional info: no global superior knowledge
When I do this:
[root@CentOS-01 cn=config]# ldapsearch -xLLWD cn=admin,dc=mycompany,dc=org
-b dc=mycompany,dc=org dn
Enter LDAP Password:
version: 1
No such object (32)
Something tells me it's wrong.
So, a friend who helped me said I had to create the company first, and that
I should use dc=company,dc=org instead of o=company.org.
I had to create the company first in the LDAP he said, so he passed me this
file:
# usergroups.ldif
#
#
dn: dc=mycompany,dc=org
dc: company
objectClass: top
objectClass: domain
dn: ou=users,dc=mycompany,dc=org
ou: Users
objectClass: top
objectClass: organizationalUnit
description: Central location for UNIX users
dn: ou=groups,dc=mycompany,dc=org
ou: Groups
objectClass: top
objectClass: organizationalUnit
description: Central location for UNIX groups
# EOF
But I can't add that:
[root@CentOS-01 cn=config]# ldapadd -W -D cn=admin,dc=mycompany,dc=org -v
-x -f /tmp/usergroup.ldif
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
add dc:
company
add objectClass:
top
domain
adding new entry "dc=mycompany,dc=org"
ldap_add: Naming violation (64)
additional info: value of single-valued naming attribute 'dc' conflicts
with value present in entry
I hope I will ever solve this, I can't complete my study now and have
wasted hours and hours on this ldap problem.
I hope you can help me out..
Karntol
11 years, 4 months
Issue with dynlist overlay
by Patrick Hemmer
So I just ran across an undocumented issue with slapo-dynlist. I'm not
sure if this is a bug, or just missing in the documentation.
The issue is that if the entry being dynamically added to the parent
entry has the objectClass slapo-dynlist is configured to use, that entry
is not dynamically added to the parent.
For example:
----
olcOverlay=dynlist,olcdatabase=hdb,cn=config
objectClass: olcDynamicList
objectClass: olcOverlayConfig
olcDlAttrSet: groupOfURLs memberUrl
----
dn: cn=parent,dc=example,dc=com
objectClass: groupOfNames
objectClass: groupOfURLs
member: uid=foo,dc=example,dc=com
memberUrl: ldap:///cn=child,dc=example,dc=com
dn: cn=child,dc=example,dc=com
objectClass: groupOfNames
objectClass: groupOfURLs
member: uid=bar,dc=example,dc=com
---
In the above example, I would "member: uid=bar,dc=example,dc=com" to be
added to cn=parent,dc=example,dc=com, but it isn't.
Now the documentation clearly states recursion is not allowed, so if
cn=child were to have a 'memberUrl', this memberUrl would not be
expanded. But this is not what is being done here, cn=child has no
memberUrl present. It also behaves perfectly fine if I pull the
"objetClass: groupOfURLs" off cn=child.
So is this supposed to behave this way? If so can the documentation be
updated to indicate this restriction?
If not I'd be happy to open an ITS on the issue.
-Patrick
11 years, 4 months
