389-users December 2011

389-users@lists.fedoraproject.org

20 participants
26 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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 2

389DS very slow shutdown
by Diego Woitasen 22 Jan '12

22 Jan '12

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

2 4

setup-ds.pl hangs with "Server failed to start !!! Please check errors log for problems"
by 馬小布 03 Jan '12

03 Jan '12

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.....

2 1

How to debug the 389 ds
by 馬小布 30 Dec '11

30 Dec '11

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.....

2 1

Adding an index: how is this achieved?
by Graham Leggett 30 Dec '11

30 Dec '11

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/Adminis…, 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 --

3 2

entryDN attribute
by Ivanov Andrey (M.) 30 Dec '11

30 Dec '11

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?

2 1

replica="unknown": Unable to acquire replica: error: no such replica
by Jared Carter 22 Dec '11

22 Dec '11

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

2 3

Getting Started with the console
by Stephen More 22 Dec '11

22 Dec '11

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

2 3

Re: [389-users] Replication trouble when promoting dedicated Consumer to Multiple master [SOLVED]
by Roland Schwingel 19 Dec '11

19 Dec '11

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

2 1

Protocol error in proxied operations
by Juan Asensio Sánchez 19 Dec '11

19 Dec '11

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/Adminis…

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users December 2011