openldap-technical

openldap-technical@openldap.org

10 participants
9989 discussions

syncrepl randomly failing to sync
by Jay Christopherson 12 Jul '09

12 Jul '09

Hi- First of all, I hope I am not rehashing a topic that has been endlessly discussed. I know that syncrepl gets discussed a lot from my searches, but I have not found a specific topic on my issue. I started out with OpenLDAP 2.3, with a single provider and two consumers doing syncrepl using a refreshAndPersist type of replication. Periodically, I would see that one or more of the consumers would fail to synchronize a change made to the provider. A restart of the consumer would fix this and we could move on. It was annoying, but not critical at this point. Since then, I have become more dependent on OpenLDAP and syncrepl. I have upgraded to 2.4 to try to fix the replication issue, but it seems worse than ever. I now have one provider and six consumers. The consumers randomly fail to synchronize (as evidences by contextCSN monitoring). This happens several times a day. I'm thinking that maybe there is something wrong with my configuratiuon. This is what I am using: Provider: overlay syncprov syncprov-checkpoint 1 10 syncprov-sessionlog 100 syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=replica,o=users,dc=domain,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited Consumers (all consumers have the exact same config): syncrepl rid=123 provider=ldap://ldap.sea.corp.domain.com:389 binddn="uid=replica,o=users,dc=domain,dc=com" bindmethod=simple retry="10 +" credentials=secret searchbase="dc=domain,dc=com" schemachecking=off type=refreshAndPersist interval=00:00:00:05 updateref ldap://ldap.sea.corp.domain.com A few "weird" things: * After the upgrade, I notice that the Directory Type on the Root DSE is still OpenLDAP 2.3 * I notice that where previously I could simple create a new consumer by installing a fresh copy of openldap, copying the config from another consumer over, and starting up to get a full copy of the directoy, it now fails to completely replicate and I have to do a full slapcat/slapadd to do the initial population. Like I said, I hope it's just something stupid I am doing...

3 2

Problem with unusual tree structure ...
by Garry Glendown 10 Jul '09

10 Jul '09

Hi, I'm trying to authenticate users against an LDAP database ... now, I already have that running on several servers that use the "normal" tree setup, something like "cn=username,ou=somebranch,ou=domain,ou=tld", with a search_base of ou=domain,ou=tld. The place I'm trying to configure it for now is using a - AFAICT - rather unusal schema, as they have a tree that uses multiple top level o=, and start underneath there, so there may by user entries like cn=user1,ou=USERS,o=branch1 and cn=user2,ou=USERS,o=branch2 (historically, ldap trees from several locations were just merged together, which led to this) How can I get SASL to search in such a configuration? I already tried a "ou=USERS,o=*" syntax, which I didn't expect to work (and it didn't) Also, I know that saslauthd or other apps will need to check the resulting username/pw, so I tried binding with the DN and PW of an account, resulting in a "Confidentiality required" ... using ldaps:// notation didn't work, as the remote server (Novell eDirectory) probably isn't configured for that, and -Z for TLS also fails with ldap_start_tls: Server is unavailable (52) additional info: TLS services are not available >From what I can find, the message should come up if the server is configured for requiring secure queries, but then I would expect it to also be configured to SUPPORT either one of the methods ... Help appreciated, -garry

1 0

Multi master topology.
by Alejandro Leyva 10 Jul '09

10 Jul '09

Hi all. We are implementing a solution with multi master LDAP, we have 11 instances at different locations, and maybe we will grow to 21 or 31 instances before the end of the year, expecting to hold something like 200,000 or 300,000 user entries. What topology would be the best? Right now each server synch to all the other servers, is it possible to configure each server to synch only to a central LDAP? is it convenient? Thanks in advance.

1 0

bindmethod and credentials in slurpd replication.
by Sai 10 Jul '09

10 Jul '09

Hi All - Our server team does not want to update our openldap version beyond 2.2 because redhat supports 2.2 as the latest and greatest for RHEL4. So I am trying to configure slurpd replication for them. I got the replication to work. But when defining "replica", I got the following questions. 1) For credentials, can I use hashed password like for rootpw 2) If we could use hashed password, what should the bindmethod be? replica uri=<URL> binddn=<Bind DN> bindmethod=simple --> ??? credentials=XXXXXXXXX Thanks in advance. -Sai

3 5

ldapmodify is modifying my code
by Darryl Moore 10 Jul '09

10 Jul '09

HELP I've been able to replace nis.schema with rfc2307bis.schema so that I can have groups with both member and memberUID attributes. when I try using ldapmodify to add members to the group such as: echo "dn: cn=newgrou1,ou=Groups,dc=moores,dc=ca changetype: modify add: memberUid memberUid: newuser1 replace: member member: uid=newuser1,ou=People,dc=moores,dc=ca" | /usr/bin/ldapmodify -v -y /etc/ldap.secret -D cn=admin,dc=moores,dc=ca -xH ldap://localhost it returns the following error message: ldap_initialize( ldap://localhost:389/??base ) modifying entry "cn=newgrou1,ou=Groups,dc=moores,dc=ca changetype: modify add: memberUid memberUid: newuser1 replace: member member: uid=newuser1,ou=People,dc=moores,dc=ca" ldap_modify: No such object (32) matched DN: ou=People,dc=moores,dc=ca The group and the user both exist. What is most interesting is that ldapmodify appears to modify my request because slapd itself gives this message: hdb_referrals: tag=102 target="cn=newgrou1,ou=Groups,dc=moores,dc=ca changetype: modify add: memberUid memberUid: newuser1 replace: member member: uid\3Dnewuser1,ou=People,dc=moores,dc=ca" matched="ou=People,dc=moores,dc=ca" bdb_dn2entry("cn=newgrou1,ou=groups,dc=moores,dc=ca changetype: modify add: memberuid memberuid: newuser1 replace: member member: uid\3Dnewuser1,ou=people,dc=moores,dc=ca") => hdb_dn2id("dc=ca changetype: modify add: memberuid memberuid: newuser1 replace: member member: uid\3Dnewuser1,ou=people,dc=moores,dc=ca") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) notice that the "uid=newuser" part of my request has been changed to "uid\3Dnewuser". I've tried a number of different combinations and it appears to me that the first '=' is always replace with \3D and then the silly thing tries to look up that element, and low and behold it does not exist. If I can make this work, then I think I will have group permissions for unix groups working on LDAP. Does anybody have any idea why ldapmodify would be doing this??????

3 6

integrate motd on openldap
by Alejandro Feijoo Fraga 10 Jul '09

10 Jul '09

Hi. i have a large number of users... from diferent language (spanish,english,etc...) all under the same ldap directory and i need change de /etc/motd if user speak spanish or english. I not found info if ldap can do that, i think put a new entry at ldap (like lenguage:es/en/ga/..) and de /etc/bashrc or similar make a if and compare that entry... any diferent idea? or any method more easy? thanks!

2 1

Re: slapd + tls problem
by Alessandro Baggi 10 Jul '09

10 Jul '09

Gavin Henry wrote: > > # openssl req -newkey rsa:1024 -nodes -keyout key.pem -out > >> newreq.pem /*for server/client certificate building and >> sing*/ >> # /usr/lib/ssl/misc/CA.pl -sign >> >> I've tried using only openssl with slapd and all work very good, but not >> with GnuTLS. My system is Debian Lenny. >> >> > > What version of OpenLDAP? > > > Hi there. The problem was solved. It works fine with tls, the problem was that TLS works on port 389 not 636 (ldaps). This is the first time for me to use openldap with gnutls support. With OpenSSL works very good. Then, there was an configuration mismatch. Thanks

1 0

Query several LDAP servers
by tmp123＠menta.net 10 Jul '09

10 Jul '09

Hello, Please, are you so kind of provide me a hint about how to configure or develop the following feature?: A proxy LDAP, like the ones with slapd-ldap, must forward all received queries to a LDAP server1. If this server contains the requested item, the answer is send backward and handling stops. If the server doesn't contains the requested item, the query must be sent to a second LDAP server2. In the worst case, a maximum of 5 different servers should be queried in sequence. Initially, any server can contain any item. Nowadays, there are no tree estructure. Thanks a lot.

1 0

Solaris LDAP Mapping
by Matthew.GARRETT＠external.total.com 09 Jul '09

09 Jul '09

Folks I hope this is the right list for this. I am trying to get our Solaris Machine use LDAP for automounts. Under Solaris the file I would normally change is /var/ldap/ldap_client_file for Solaris using Ldap Version 2.0 But I am not 100% sure what I need to get LDAP automount to work. The OpenLdap Server has the following entries dn: ou=auto.apps,dc=unix,dc=total objectClass: top objectClass: automountMap ou: auto.apps A typical Map entry is dn: cn=acrobat,ou=auto.apps,dc=unix,dc=total objectClass: automount cn: acrobat automountInformation: uk-abz-vgl:/apps/acrobat Can anybody suggest suitable entries for the above ? Thanks Matthew Registered in England and Wales No.811900 Registered Office 33 Cavendish Square, London W1G 0PW This e-mail and any attachments are intended only for the person or entity to whom it is addressed and may contain confidential or privileged information. If you are not the addressee, any disclosure, reproduction, copying, distribution, or use of this communication is strictly prohibited. If you are not the intended recipient or person responsible for delivering this message to the named addressee, please notify us immediately and delete this e-mail. It is the responsibility of the addressee to scan this email and any attachments for computer viruses or other defects. The sender does not accept liability for any loss or damage of any nature, however caused, which may result directly or indirectly from this email or any file attached.

2 1

replicating cn=config
by Matthew Edlefsen 09 Jul '09

09 Jul '09

Hi, I've been trying to use syncrepl to replicate my cn=config tree and have been running into some issues. After running into a number of things not working I completely stripped everything down and attempted to follow test049 by building it from scratch. I've gotten it to work by running two instances of slapd on the same machine, on both machines, but I still can't get it to work between the two machines. System info Provider: FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sat Nov 15 18:38:32 EST 2008 OpenLDAP 2.4.16 Consumer: FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #1: Mon Jun 1 12:29:14 EDT 2009 OpenLDAP 2.4.16 My process is this: First I create slapd.d directories for both servers and populate them with a basic config mkdir slapd.d slapadd -n 0 -F slapd.d <<END dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: Trace olcLogLevel: Config olcLogLevel: Stats olcLogLevel: Sync olcLogLevel: Args olcLogLevel: Conns dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcRootDN: $MANAGER olcRootPW: $CONFIGPW olcDatabase: {0}config dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov END chown -R ldap:ldap slapd.d Then I launch slapd with: /usr/local/libexec/slapd -h $URI -u ldap -g ldap on both machines. At this point I can do ldapsearch on both servers and get back the correct results. I then do: ldapmodify -D "$MANAGER" -x -w "$CONFIGPW" <<END dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$PROVIDER_URI binddn="$MANAGER" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="3 5 300 5" timeout=3 - add: olcUpdateRef olcUpdateRef: $PROVIDER_URI END At this point I start logging the same error over and over. Here are the log messages I get: Consumer: Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: >>> dnPrettyNormal: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPrettyNormal: <cn=config>, <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=subschema> Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 3 19:55:35 jet slapd[51003]: dn_callback : entries have identical CSN cn=config 20090603203325.264042Z#000000#000#000000 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_search (0) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 cn=config Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=config) Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: >>> dnPrettyNormal: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPrettyNormal: <cn=schema,cn=config>, <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=subschema> Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_search (0) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 cn=schema,cn=config Jun 3 19:55:35 jet slapd[51003]: conn=-1 op=0: config_add_internal: DN="cn=schema,cn=config" already exists Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=68 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_add cn=schema,cn=config (68) Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=1 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: null_callback : error code 0x1 Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_modify cn=schema,cn=config (1) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_modify failed (1) Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: do_syncrepl: rid=001 rc 1 retrying (4 retries left) Provider: Jun 3 17:02:36 rock slapd[75268]: slap_listener_activate(6): Jun 3 17:02:36 rock slapd[75268]: >>> slap_listener($PROV_URI) Jun 3 17:02:36 rock slapd[75268]: conn=391 fd=8 ACCEPT from IP=$CONS_IP:56003 (IP=$PROV_IP:389) Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 do_bind Jun 3 17:02:36 rock slapd[75268]: >>> dnPrettyNormal: <cn=manager,cn=config> Jun 3 17:02:36 rock slapd[75268]: <<< dnPrettyNormal: <cn=manager,cn=config>, <cn=manager,cn=config> Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 BIND dn="cn=manager,cn=config" method=128 Jun 3 17:02:36 rock slapd[75268]: do_bind: version=3 dn="cn=manager,cn=config" method=128 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 BIND dn="cn=manager,cn=config" mech=SIMPLE ssf=0 Jun 3 17:02:36 rock slapd[75268]: do_bind: v3 bind: "cn=manager,cn=config" to "cn=manager,cn=config" Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=0 p=3 Jun 3 17:02:36 rock slapd[75268]: send_ldap_response: msgid=1 tag=97 err=0 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 RESULT tag=97 err=0 text= Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 do_search Jun 3 17:02:36 rock slapd[75268]: >>> dnPrettyNormal: <cn=config> Jun 3 17:02:36 rock slapd[75268]: <<< dnPrettyNormal: <cn=config>, <cn=config> Jun 3 17:02:36 rock slapd[75268]: => get_ctrls Jun 3 17:02:36 rock slapd[75268]: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical) Jun 3 17:02:36 rock slapd[75268]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (critical) Jun 3 17:02:36 rock slapd[75268]: <= get_ctrls: n=2 rc=0 err="" Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 SRCH attr=* + Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=1 p=3 Jun 3 17:02:36 rock last message repeated 2 times Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={0}core,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={1}cosine,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={2}inetorgperson,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={3}nis,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcDatabase={-1}frontend,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcDatabase={0}config,cn=config" Jun 3 17:02:36 rock slapd[75/: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcOverlay={0}syncprov,olcDatabase={0}config,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=1 p=3 Jun 3 17:02:36 rock slapd[75268]: send_ldap_intermediate: err=0 oid=1.3.6.1.4.1.4203.1.9.1.4 len=56 Jun 3 17:02:36 rock slapd[75268]: send_ldap_response: msgid=2 tag=121 err=0 Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: ber_get_next on fd 8 failed errno=0 (Undefined error: 0) Jun 3 17:02:36 rock slapd[75268]: conn=391 op=2 do_unbind Jun 3 17:02:36 rock slapd[75268]: conn=391 op=2 UNBIND Jun 3 17:02:36 rock slapd[75268]: connection_close: conn=391 sd=8 Jun 3 17:02:36 rock slapd[75268]: conn=391 fd=8 closed As I said it works perfectly if it's two slapd instances on the same machine on different ports. The machines can talk to each other and can both ldapsearch the other one. Also the firewall is reporting no blocks. If anybody has seen this before or has some insight into what the problem might be it would be very much apprectiated. Thank you in advance, Matt Edlefsen Earlham College

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical