Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 3 months
389DS very slow shutdown
by Diego Woitasen
Hi,
I have a weird problem with 389DS. It takes more than 5 minutes to
shutdown. The init script sends a SIGTERM to the process and it
finishes clean. That's clear looking at the log file too:
grep "slapd shutting down" errors
[10/Nov/2011:17:55:52 -0300] - slapd shutting down - waiting for 22
threads to terminate
[10/Nov/2011:17:55:52 -0300] - slapd shutting down - closing down
internal subsystems and plugins
[10/Nov/2011:17:55:52 -0300] - slapd shutting down - waiting for
backends to close down
[10/Nov/2011:18:01:41 -0300] - slapd shutting down - backends closed down
First I thought that I was related to my 150 DBs but I created a test
case with a clean server, 150 DBs and 10.000 entries and the shutdown
takes 2 seconds.
The only weird thing that I see is the dse.ldif.tmp file being
truncated and written and again and again... several times until
shutdown. Strace shows me that the process is writting configuration
entries too.
I'm using DS 1.2.9.9 (same problem with 1.2.8.3) on Debian Squeeze.
I set errorlevel to 1 but I don't know is there is something
interesting in the log. I upload the log here if someone want to have
a look: http://main.woitasen.com.ar/errors
What can I do to start to discover what's happening here?
Regards,
Diego
--
Diego Woitasen
11 years, 10 months
setup-ds.pl hangs with "Server failed to start !!! Please check errors log for problems"
by 馬小布
Hi, All:
When I run "yum install 389-ds" on Fedora 15 x64 and then run this command
to setup it ,
it displays the following error message:
root@test ~: setup-ds-admin.pl
xxxx
Pick a port number between 1024 and 65535 to run your Administration
Server on. You should NOT use a port number which you plan to
run a web or application server on, rather, select a number which you
will remember and which will not be used for anything else.
Administration port [9830]:
==============================================================================
The interactive phase is complete. The script will now set up your
servers. Enter No or go Back if you want to change something.
Are you ready to set up your servers? [yes]:
Creating directory server . . .
Server failed to start !!! Please check errors log for problems
/var/log/dirsvr/slapd-ldap/errors just shows
[31/Dec/2011:15:00:46 +0800] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access the
database
[31/Dec/2011:15:00:46 +0800] - check_and_set_import_cache: pagesize: 4096,
pages: 255648, procpages: 50503
[31/Dec/2011:15:00:46 +0800] - WARNING: After allocating import cache
409036KB, the available memory is 613556KB, which is less than the soft
limit 1048576KB. You may want to decrease the import cache size and rerun
import.
[31/Dec/2011:15:00:46 +0800] - Import allocates 409036KB import cache.
[31/Dec/2011:15:00:46 +0800] - import userRoot: Beginning import job...
[31/Dec/2011:15:00:46 +0800] - import userRoot: Index buffering enabled
with bucket size 100
[31/Dec/2011:15:00:46 +0800] - import userRoot: Processing file
"/tmp/ldifHPkSVg.ldif"
[31/Dec/2011:15:00:46 +0800] - import userRoot: Finished scanning file
"/tmp/ldifHPkSVg.ldif" (9 entries)
[31/Dec/2011:15:00:47 +0800] - import userRoot: Workers finished; cleaning
up...
[31/Dec/2011:15:00:47 +0800] - import userRoot: Workers cleaned up.
[31/Dec/2011:15:00:47 +0800] - import userRoot: Cleaning up producer
thread...
[31/Dec/2011:15:00:47 +0800] - import userRoot: Indexing complete.
Post-processing...
[31/Dec/2011:15:00:47 +0800] - import userRoot: Flushing caches...
[31/Dec/2011:15:00:47 +0800] - import userRoot: Closing files...
[31/Dec/2011:15:00:47 +0800] - All database threads now stopped
[31/Dec/2011:15:00:47 +0800] - import userRoot: Import complete. Processed
9 entries in 1 seconds. (9.00 entries/sec)
[31/Dec/2011:15:00:56 +0800] - Shutting down due to possible conflicts with
other slapd processes
the log file in /tmp doesn't seem to be any help either.
I've already uninstalled, and did this command :
root@test ~: rm -fr /etc/dirsrv /var/lock/dirsrv /var/run/dirsrv
/var/log/dirsrv
reinstalled -- same issue.
I'm really lost on this.
Could someone can give some help to me ? Thanks.....
11 years, 11 months
How to debug the 389 ds
by 馬小布
Hi, guys:
When I installed the 389 ds on Fedora 15 x64 via the rpm, but when I start
the admin console ,
the screen did not display the login name .
That's to say, it did not display the UserID and Password and
Administration URL .
The 389 console version is 1.1.7.1, and java version is 1.6.0.22
Is the java problem? Or maybe something cause it ....
Could anyone can give me some suggestions?
Thanks.....
11 years, 11 months
Adding an index: how is this achieved?
by Graham Leggett
Hi all,
I'm trying to add an index, and am currently epically failing at doing so.
The only documentation I can find is the obsolete Redhat Directory Server guide at http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin..., linked to from the 389-ds documentation website.
The docs recommend I use the db2index.pl script, which doesn't work for me:
/usr/lib64/dirsrv/slapd-myinstance/db2index.pl -D "cn=Directory Manager" -w `cat /etc/ldap.secret` -n myinstance -t myattribute
adding new entry cn=db2index_2011_12_28_14_49_34, cn=index, cn=tasks, cn=config
ldap_add: No such object
A look at the error log reveals this error:
[28/Dec/2011:14:50:35 -0600] - can't import to nonexistent backend myinstance
I am completely stumped. If my backend isn't called "myinstance" then I have no idea what it's referring to. Given there is only one instance on the server, I have no idea why 389ds can't figure this out for itself. In fact, I can't understand why 389ds didn't just handle indexes all on its own anyway.
The docs suggest doing this:
cd /etc/dirsrv/slapd-instance_name
db2index.pl-D "cn=Directory Manager" -w secret -n ExampleServer -t sn
No idea where "ExampleServer" comes from, and no idea why it's not the same as "instance_name".
I also find a shell script called db2index, as well as the perl script called db2index.pl. Any idea why there are two scripts that in theory do the same thing?
Is there an up to date recipe somewhere that explains how to add an index to 389ds?
Regards,
Graham
--
11 years, 11 months
entryDN attribute
by Ivanov Andrey (M.)
Hi,
The entryDN OID from the 389 schema (back-ldbm.h:#define LDBM_ENTRYDN_OID
"2.16.840.1.113730.3.1.602") is different from that defined by RFC5020 (
http://tools.ietf.org/html/rfc5020, "Object Identifier: 1.3.6.1.1.20"). Is
it an intended difference? Are there any technical reasons why it should be
different?
11 years, 11 months
replica="unknown": Unable to acquire replica: error: no such replica
by Jared Carter
Hopefully someone can help me out. I'm trying to build a new ldap server
and replicate the data from one of my current nodes.
If somebody can direct me to a howto on this that would be great. Right
now I've built the new ldap server, but when i setup the replication using
either the 389 client or a perl script I keep getting replica errors. Any
ideas, something simple I'm missing? Error logs below.
[30/Nov/2011:10:34:37 -0800] - dblayer_instance_start: pagesize: 4096,
pages: 9259981, procpages: 45973
[30/Nov/2011:10:34:37 -0800] - cache autosizing: import cache: 204800k
[30/Nov/2011:10:34:37 -0800] - li_import_cache_autosize: 50, import_pages:
51200, pagesize: 4096
[30/Nov/2011:10:34:37 -0800] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access the
database
[30/Nov/2011:10:34:37 -0800] - dblayer_instance_start: pagesize: 4096,
pages: 9259981, procpages: 46009
[30/Nov/2011:10:34:37 -0800] - cache autosizing: import cache: 204800k
[30/Nov/2011:10:34:37 -0800] - li_import_cache_autosize: 50, import_pages:
51200, pagesize: 4096
[30/Nov/2011:10:34:37 -0800] - import userRoot: Beginning import job...
[30/Nov/2011:10:34:37 -0800] - import userRoot: Index buffering enabled
with bucket size 100
[30/Nov/2011:10:34:37 -0800] - import userRoot: Processing file
"/tmp/ldifqNKrJP.ldif"
[30/Nov/2011:10:34:37 -0800] - import userRoot: Finished scanning file
"/tmp/ldifqNKrJP.ldif" (9 entries)
[30/Nov/2011:10:34:38 -0800] - import userRoot: Workers finished; cleaning
up...
[30/Nov/2011:10:34:38 -0800] - import userRoot: Workers cleaned up.
[30/Nov/2011:10:34:38 -0800] - import userRoot: Cleaning up producer
thread...
[30/Nov/2011:10:34:38 -0800] - import userRoot: Indexing complete.
Post-processing...
[30/Nov/2011:10:34:38 -0800] - import userRoot: Flushing caches...
[30/Nov/2011:10:34:38 -0800] - import userRoot: Closing files...
[30/Nov/2011:10:34:38 -0800] - All database threads now stopped
[30/Nov/2011:10:34:38 -0800] - import userRoot: Import complete. Processed
9 entries in 1 seconds. (9.00 entries/sec)
389-Directory/1.2.5 B2010.012.2034
tx-ds05.prd.cyberdyne.com:390 (/etc/dirsrv/slapd-tx-ds05)
[30/Nov/2011:10:34:38 -0800] - 389-Directory/1.2.5 B2010.012.2034 starting
up
[30/Nov/2011:10:34:38 -0800] - I'm resizing my cache now...cache was
209715200 and is now 8000000
[30/Nov/2011:10:34:38 -0800] - slapd started. Listening on All Interfaces
port 390 for LDAP requests
[30/Nov/2011:10:39:58 -0800] NSMMReplicationPlugin - conn=10 op=3
replica="unknown": Unable to acquire replica: error: no such replica
[30/Nov/2011:10:39:59 -0800] NSMMReplicationPlugin - conn=11 op=3
replica="unknown": Unable to acquire replica: error: no such replica
[30/Nov/2011:10:39:59 -0800] NSMMReplicationPlugin - conn=12 op=3
replica="unknown": Unable to acquire replica: error: no such replica
[30/Nov/2011:10:48:22 -0800] NSMMReplicationPlugin - conn=13 op=3
replica="unknown": Unable to acquire replica: error: no such replica
[30/Nov/2011:10:48:22 -0800] NSMMReplicationPlugin - conn=14 op=3
replica="unknown": Unable to acquire replica: error: no such replica
11 years, 11 months
Getting Started with the console
by Stephen More
I have looked through the documentation and have found references to
install package 389-admin so that I can run setup-ds-admin.pl and
389-console.
But I can only find the 389-ds-base package in the documented repo on:
http://repos.fedorapeople.org/repos/rmeggins/
[root@389 opt]# rpm -qa | grep 389
389-ds-base-libs-1.2.8.2-1.el6_1.3.x86_64
389-ds-base-1.2.8.2-1.el6_1.3.x86_64
[root@389 opt]#
What package and where would I get it from so I can use the console ?
-Thanks
Stephen More
11 years, 11 months
Re: [389-users] Replication trouble when promoting dedicated Consumer to Multiple master [SOLVED]
by Roland Schwingel
Hi.....
Finally I got it I don't know whether I did it the fully correct way, but
it works now.
I found that this mysterious replica id 3 was stored in dse.ldif of my
server-b:
To recap my scenario:
server A < ----- server B <-----> server
C -----> server D
(dedicated Consumer) (multiple Master replica ID:1) (multiple
Master replica ID:2) (Dedicated Consumer)
I wanted to promote my server D to become a multiple master - but it did
not work.
What did I do to get it going:
1. Removed all replication agreements to/from server D.
2. Stopped all LDAP services on all servers (I was a little desperate)
3. Found replica id 3 in dse.ldif of server B(?) - nowhere else (why B and
not C?)
4. Removed these bogus entries.
5. Restarted all LDAP services on all machines.
6. ldapsearch on server C still revealed the bogus replica id 3 (Where the
heck is that cached?).
7. Reinitialized consumer server C from server B and restarted ldap on
server C.
8. ldapsearch was clean by then.
9. removed my suffix on server D and removed changelog.
10. recreated suffix on server D and made server D a dedicated consumer
11. on server C created replication agreement to server D
12. initialized server D from server C.
13, Enabled changelog on server D
14. Changed server D to be Multiple Master with replica id 3
15, Created replication aggreement to server C from server D.
16. Worked. Restarted LDAP on server D and C.
17. Still works and replicates to all other machines along the path.
18. I need vacation....
Holy Moly!
Roland
__________________
Hi Reinhard,
Thanks for your reply!!
389-users-bounces(a)lists.fedoraproject.org wrote on 14.07.2011 16:25:10:
> From: Reinhard Nappert <rnappert(a)juniper.net>
> To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
> Date: 14.07.2011 16:28
> Subject: Re: [389-users] Replication trouble when promoting
> dedicated Consumer to Multiple master
> Sent by: 389-users-bounces(a)lists.fedoraproject.org
>
> Do a ldapsearch -b 'nsuniqueid=ffffffff-ffffffff-ffffffff-
> ffffffff,dc=mydomain,dc=com' -D <directory manager> -w <password> -s
> base objectclass=nstombstone
>
> This gives you all the configured (history) of replication ids. The
> following is the output in my setup.
>
> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
> objectClass: top
> objectClass: nsTombstone
> objectClass: extensibleobject
> nsds50ruv: {replicageneration} 4df7a107000000010000
> nsds50ruv: {replica 1 ldap://yale:389} 4df7a396000000010000
4e19ad950000000100
> 00
> nsds50ruv: {replica 3 ldap://norquay:389} 4df7a39d000000030000
4e1605650000000
> 30000
> nsds50ruv: {replica 4 ldap://mustrum:389} 4df7a3a0000000040000
4dfb93650000000
> 40000
> nsds50ruv: {replica 2 ldap://louise:389} 4df7a39a000000020000
4e171a0700000002
> 0000
> o: base
> nsruvReplicaLastModified: {replica 1 ldap://yale:389} 00000000
> nsruvReplicaLastModified: {replica 3 ldap://norquay:389} 00000000
> nsruvReplicaLastModified: {replica 4 ldap://mustrum:389} 00000000
> nsruvReplicaLastModified: {replica 2 ldap://louise:389} 00000000
> /\
> |
> replication-id
>
I issued that command on my server Server C. I get the following results:
# extended LDIF
#
# LDAPv3
# base <nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=mydomain,dc=com>
with scope baseObject
# filter: objectclass=nstombstone
# requesting: ALL
#
# ffffffff-ffffffff-ffffffff-ffffffff, mydomain.com
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, dc=mydomain,dc=com
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4bf162c6000000010000
nsds50ruv: {replica 2 ldap://server-c.mydomain.com:389} 4cd3fa1e00000002
0000 4e1ef45b000000020000
nsds50ruv: {replica 3 ldap://server-d.mydomain.de:389}
nsds50ruv: {replica 1 ldap://server-b.mydomain.de:389} 4bf16732000000010
000 4e1ffa3e000000010000
dc: mydomain
nsruvReplicaLastModified: {replica 2 ldap://server-c.mydomain.com:389} 4
e1ef445
nsruvReplicaLastModified: {replica 3 ldap://server-d.mydomain.de:389}
00000000
nsruvReplicaLastModified: {replica 1 ldap://server-b.mydomain.de:389} 4e
1ffa26
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
When I look at it I see that replica id 3 is assigned to my server-d
(which should get that replica id). I started over deleted my server-d
assigned it replica id 4 but nothing changes.
I also cannot get rid of the informations for server-d in that nsuniqueid
how can I do that?
Thanks,
Roland
11 years, 11 months
Protocol error in proxied operations
by Juan Asensio Sánchez
Hi
I am trying to test the proxied operations in 389 DS. For now, I have
written a small script using UnboundID LDAP SDK [1]:
ModifyRequest modifyRequest = new
ModifyRequest("uid=XXXXXXXX,ou=People,o=XXXXXXXX,dc=XXXXXXXX,dc=XXXXXXXX",
new Modification(ModificationType.REPLACE, "address", "Nueva
dirección"));
modifyRequest.addControl(new ProxiedAuthorizationV2RequestControl(
"dn:" + proxiedUserEntry.getDN()) );
try
{
LDAPResult modifyResult =
ldapConnectable.getConnection(session).modify(modifyRequest);
// If we got here, then the modify was successful.
}
catch (LDAPException le)
{
System.out.println(le.getDiagnosticMessage() + " (" +
le.getResultCode() + ")");
}
Although I have not yet assigned any ACIS as described in [2], I
supposed to get a denied response, not a protocol error as I get:
unable to parse proxied authorization control (2 (protocol error))
I think this error is returned by the LDAP server, although it is not
reported in the error LOG. Anyone has experienced with proxied
operations?
[1] http://www.unboundid.com/products/ldapsdk/docs/javadoc/index.html
[2] http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Admin...
11 years, 12 months
