389-users November 2011

389-users@lists.fedoraproject.org

31 participants
27 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

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

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

MMR referral list questions.
by Shardul Kerkar 14 Dec '11

14 Dec '11

Hi , I am testing MMR on our QA ldap servers using version 1.1.2. Currently I have setup Master-1 and Master-2 as the two read-write suppliers. Hub-1 has replication agreements with Master-1 and Master-2. Rep-1 has replication to Hub-1. Consequently Hub-1 has Master-1 and Master-2 in its referral list. Anytime I do a write on rep, the change always takes place on Master-1 and flows down the tree. Only if I bring Master-1 down, does Master-2 take over. How do I tell Hub-1 to distribute writes equally to both Masters. Also if I want to intentionally do all changes on Master-2, is there a way for Hub to prefer one referral over the other? Thank you, Shar

2 1

Password sync
by Viento . 14 Dec '11

14 Dec '11

Hi all,I have installed a 389ds which sync entries from an Active Directory running on Windows 2003 R2 Enterprise Server. Everything works fine even Password Sync. But I have still 1 problems I don't get solved: 11/30/11 00:35:46: There are no entries that match: test3 11/30/11 00:35:46: Deferring password change for test3

2 1

*;lang-en attributes in AD replication
by Juan Asensio Sánchez 01 Dec '11

01 Dec '11

Hi In our directory, we have some users with attributes like cn;lang-en, sn;lang-en, with the same value than cn or sn, but without tildes (á, è) or "ñ". When I try to synchronize these users with Active Directory, I get this error: [30/Nov/2011:11:58:32 +0100] - Windows sync entry: Created new remote entry: dn:: XXXXXXX objectClass: top objectClass: person objectClass: organizationalperson objectClass: user userprincipalname: XXXXXXX(a)pruebas.local st: XXXXXXX postalCode: XXXXXXX postalAddress:: XXXXXXX streetAddress:: XXXXXXX facsimileTelephoneNumber: XXXXXXX telephoneNumber: XXXXXXX mail: XXXXXXX o: XXXXXXX l: XXXXXXX ou: XXXXXXX givenName: XXXXXXX sn:: XXXXXXX cn:: XXXXXXX sAMAccountName: XXXXXXX accountExpires: 0 codePage: 0 sn;lang-en: XXXXXXX [30/Nov/2011:11:58:32 +0100] - Attempting to add entry cn=XXXXXXX,ou=LDAPPeople,dc=pruebas,dc=local to AD for local entry uid=XXXXXXX,ou=People,o=XXXXXXX,dc=XXXXXXX,dc=XXXXXXX [30/Nov/2011:11:58:32 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXXXXX:636): Received result code 16 (00000057: LdapErr: DSID-0C090B38, comment: Error in attribute conversion operation, data 0, vece) for add operation If I remove the attribute "sn;lang-en", the sync works ok (well, not, but that is another story). Can I make the sync agreement exclude some attributes, like a normal agreement? Thanks in advance.

2 2

UID Number Limitations
by Tom Tucker 26 Nov '11

26 Nov '11

My environment has a mixture of Solaris 8-10 and RHEL 4-5. These clients are currently authenticating against a Sun One 5.X DS. I have migrated the Sun One DB to my lab 389 DS. Users with a three digit uidNumber are unable to login to Linux systems, however if they connect to a Solaris system it works fine. If I add a fourth digit to their uidNumber they are able access Linux systems just fine. Did I miss a setting somewhere? Thanks, Tom

4 4

Setting account to inactive
by David Hoskinson 21 Nov '11

21 Nov '11

I would like to script inactivating an account. From my investigation it looks like the nsaccountlock is set to true, and nsrole is set to cn=nsdisabledrole,dc=xxx,dc=yyy and nsroledn=cn=nsmanageddisabledrole,dc=xxx,dc=yyy. Can anybody confirm this for me that I haven't left out anything vital? Thanks David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson(a)datatrak.net<mailto:david.hoskinson@datatrak.net> | www.datatrak.net<http://www.datatrak.net/>

2 1

Re: [389-users] Multiple threads simultaneously working on connection's private buffer causes ns-slapd to abort
by Rich Megginson 20 Nov '11

20 Nov '11

On 11/18/2011 05:31 AM, "Reddy, Gandikota Rushendra (ES&N)" <gandikota-rushendra.reddy(a)hp.com> wrote: This was a bounce - please check your list membership before posting again. > On a multi CPU system, ns-slapd process aborts. Stack trace says it aborted calling PR_ASSERT() at the following location in connection.c (Release version of 389 dirsrv is 1.2.0). Is there any chance you could attempt to reproduce this issue with the latest 1.2.9.9 (stable) or 1.2.10.a5 (testing)? Or provide a reproducer. 1.2.0 is quite old. Also, please file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=389 > ----- > Connection.c > 1690 int connection_read_operation(Connection *conn, Operation *op, ber_tag_t *tag, int *remaining_data) > 1691 { > > 1734 } > 1735 /* If we still haven't seen a complete PDU, read from the network */ > 1736 while (*tag == LBER_DEFAULT) { > 1737 int ioblocktimeout_waits = config_get_ioblocktimeout() / CONN_TURBO_TIMEOUT_INTERVAL; > 1738 /* We should never get here with data remaining in the buffer */ > 1739 PR_ASSERT( !new_operation || 0 == (conn->c_private->c_buffer_bytes - conn->c_private->c_buffer_offset) );<------------------ aborted calling PR_ASSERT() > 1740 /* We make a non-blocking read call */ > ----- > > Using instrumented image I have collected data and found that: > > While a thread is working on connection's private buffer, another thread which belongs to older connection makes the connection readable again by modifying c_gettingber to zero. > This results in waking up one more thread. Finally more than one thread works simultaneously on connection's private buffer and results in aborting ns-slapd. > > > It happens as below: > > 1. Thead X is working on Connection-1's last opereration. > > 2. After performing the LDAP operation ( connection_dispatch_operation() ) decrementes the connection's c_refcnt by calling connection_release_nolock() in connection_threadmain() function. > > 3. Since this is the last operation, c_refcnt becomes zero. > > 4. Thread X yet to execute the code that updates c_threadnumber and c_gettingber. But as soon as c_refcnt of the connection becomes zero, main thread allocates the same connection object/structure to new incoming connection connection-2. Thread-Y started executing operation belongs to this newer connection (Connection-2). > > ----- > connection.c > > 2008 static void > 2009 connection_threadmain() > 2010 { > > > 2187 if (!thread_turbo_flag&& !more_data) { > 2188 connection_release_nolock (conn);<------------------ Thread-X decremented c_refcnt and now c_refcnt = 0 > 2189 } > 2190 PR_Unlock( conn->c_mutex ); > 2191 } > 2192 /* Since we didn't do so earlier, we need to make a replication connection readable again here */ > 2193 if ( ((1 == is_timedout) || (replication_connection&& !thread_turbo_flag))&& !more_data) > 2194 connection_make_readable(conn); > 2195 pb = NULL; > 2196 > 2197 if (!thread_turbo_flag&& !more_data) { /* Don't do this in turbo mode */ > 2198 PR_Lock( conn->c_mutex ); > 2199 /* if the threadnumber of now below the maximum, wakeup > 2200 * the listener thread so that we start polling on this > 2201 * connection again > 2202 */ > 2203 /* DBDB I think this code is bogus -- we already signaled the listener above here */ > 2204 if (conn->c_threadnumber == config_get_maxthreadsperconn()) > 2205 need_wakeup = 1; > 2206 else > 2207 need_wakeup = 0; > 2208 conn->c_threadnumber--; > 2209 PR_Unlock( conn->c_mutex ); > 2210 > 2211 if (need_wakeup) > 2212 signal_listner(); > 2213 } > 2214 > 2215 > 2216 } /* while (1) */ > 2217 } > ---- > > 5. Thread-Y started processing operation data belongs to newer connection Connection-2 (connection_read_operation() ). > > 6. Now Thread-X of connection-1 called make_connection_readable() and made the connection readable again by setting c_gettingbuffer to 0. > > 7. This wakes up another thread of connection-2 and it too starts processing operation data (connection_read_operation() ). > > 8. So at this point of time more than one thread is working on connection's private data. > > 9. As two threads are working on the connections c_buffer, c_bufferbytes and c_offset, at some time it meats conditions to abort() at the following location: > > Connection.c: connection_read_operation() > > 1734 } > 1735 /* If we still haven't seen a complete PDU, read from the network */ > 1736 while (*tag == LBER_DEFAULT) { > 1737 int ioblocktimeout_waits = config_get_ioblocktimeout() / CONN_TURBO_TIMEOUT_INTERVAL; > 1738 /* We should never get here with data remaining in the buffer */ > 1739 PR_ASSERT( !new_operation || 0 == (conn->c_private->c_buffer_bytes - conn->c_private->c_buffer_offset) );<------------------ aborted calling PR_ASSERT() > 1740 /* We make a non-blocking read call */ > ----- > > > > The probable fix could be: > > In the connection_threadmain() function, if it is CONN_DONE don't make the connection readable again after decrementing the c_refcnt. > > So should we handle CONN_DONE and CONN_TIMEDOUT situation differently as below? > > > > Present code: > > 2097 switch (ret) { > 2098 case CONN_DONE: > 2099 /* This means that the connection was closed, so clear turbo mode */ > 2100 /*FALLTHROUGH*/ > 2101 case CONN_TIMEDOUT: > 2102 thread_turbo_flag = 0; > 2103 is_timedout = 1; > > > new code: > > > 2097 switch (ret) { > 2098 case CONN_DONE: > 2099 /* This means that the connection was closed, so clear turbo mode */ > is_conn_done = 0;<----------------- > thread_turbo_flag = 0;<------------- > 2101 case CONN_TIMEDOUT: > 2102 thread_turbo_flag = 0; > 2103 is_timedout = 1; Note that you don't have to set thread_turbo_flag = 0 in the CONN_DONE case because it will be set when it falls through to the CONN_TIMEDOUT case. > > Present: > > 2193 if ( ((1 == is_timedout) || (replication_connection&& !thread_turbo_flag))&& !more_data ) > 2194 connection_make_readable(conn); > 2195 pb = NULL; > > > > new: > > 2193 ---------> if ( !is_conn_done&& ((1 == is_timedout) || (replication_connection&& !thread_turbo_flag))&& !more_data ) > 2194 connection_make_readable(conn); > 2195 pb = NULL; > > > > Is it right way to fix it? Please provide your inputs. If ret is CONN_DONE, but you set is_conn_done = 0, how does the code know the connection is really done? > > > Thanks& regards, > Rushendra > > > > > > > > > > > >

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2011