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
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
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
MMR referral list questions.
by Shardul Kerkar
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
11 years, 11 months
Password sync
by Viento .
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
11 years, 11 months
*;lang-en attributes in AD replication
by Juan Asensio Sánchez
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.
12 years
UID Number Limitations
by Tom Tucker
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
12 years
Setting account to inactive
by David Hoskinson
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/>
12 years
Re: [389-users] Multiple threads simultaneously working on connection's private buffer causes ns-slapd to abort
by Rich Megginson
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
>
>
>
>
>
>
>
>
>
>
>
>
12 years
