openldap-software

openldap-software@openldap.org

2719 discussions

problems setting up replication server
by Andrew Higginbotham 16 Nov '06

16 Nov '06

Hi, I am trying to setup a replication server using Openldap-2.3.27. I have set it up (detailed below) and I get on the slave TLS: can't accept. TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol s23_srvr.c:580 What is really strange is that I can log on and make manual modifications to the slave from the master as the replication user with the password specified in slapd.conf (yes, over tls!). I was thinking it might be because of differing ssl versions, but I tried switching to SSLv3 and the config file and it had no effect. Does any one have some tips that would help me additionally debug this problem or get an idea of where the failure is? // Relevant config file lines on master replica host=<<hostname>>:636 binddn="cn=replicator,dc=hmc,dc=edu" tls=yes bindmethod=simple credentials=<<password>> // Relevant config lines on slave TLSCipherSuite HIGH:MEDIUM:+SSLv3 updatedn "cn=replicator,dc=hmc,dc=edu" updateref ldaps://<<ref>> Thanks, Andrew

3 5

Re: How To Configure w/ FreeBSD
by Rachel Florentine 15 Nov '06

15 Nov '06

113118113----- Original Message ---- From: Howard Chu <hyc(a)symas.com> > This combination of switches makes no sense. See configure --help. > > There is no "--enable-openssl" option. > When you use "--disable-slapd" all backends and overlays are disabled. Thanks! Rachel

1 0

ldapsync fractional replication -- almost there
by Rok Papez 15 Nov '06

15 Nov '06

Hello OpenLDAP-software :)! I have a working syncrepl replication and even managed to do fractional replication (only a subset of attributes are replicated). The list of attributes that should be replicated is defined via ACL on the provider, like this: access to dn.subtree="ou=users,dc=org,dc=test,dc=si" attrs=entry,top,person,organizationalPerson,inetOrgPerson,eduPerson,schacContactLocation,schacEmployeeInfo,schacEntryConfidentiality,schacEntryMetadata,schacLinkageIdentifiers,schacPersonalCharacteristics,schacUserEntitlements by dn="cn=rep1,ou=replicators,dc=org,dc=test,dc=si" read by anonymous auth Consumer configuration looks like this: syncrepl rid=111 provider="ldap://master" type=refreshAndPersist retry="10 +" searchbase="ou=users,dc=org,dc=test,dc=si" bindmethod=simple binddn="cn=rep1,ou=replicators,dc=org,dc=test,dc=si" credentials="xxx" schemachecking=off =============================================================== Everything is working fine, however the problem is that provider is using some additional schema with attributes, which are of no interest to the consumer. The unwanted attributes are filtered out via provider ACL, however the data from the provider contains an additional objectClass with a custom schema name. Becouse consumer doesn't have this schema it denies replication with an error message: ... slapd[15143]: syncrepl_message_to_entry: mods check (objectClass: value #0 invalid per syntax) Which is logical... the entry has an unknown objectClass. Is it possible to somehow also filter out the unwanted "objectClass: unknownLocalStuff" ? I tried googling for the fractional replication but it seems to be an obscure topic. The OpenLDAP admin manual doesn't mention it so any help is welcome :). -- Best regards, Rok Papež.

2 1

Re: ports/105585: OpenLDAP should not be linked with BDB 4.3
by Howard Chu 15 Nov '06

15 Nov '06

Dave Horsfall wrote: > Can someone please provide a succint response that I can relay in turn? > They refuse to listen to reason. Two things: slapd is known to crash in various ways when using BDB 4.3 under heavy load. Also, there was no database format change between BDB 4.3 and 4.4. There was a logfile format change though, so you'll want to have a full checkpoint and remove all the obsolete log files. > > ---------- Forwarded message ---------- > Date: Wed, 15 Nov 2006 23:42:07 GMT > From: Xin LI <delphij(a)FreeBSD.org> > To: daveh(a)ci.com.au, delphij(a)FreeBSD.org, delphij(a)FreeBSD.org > Subject: Re: ports/105585: OpenLDAP should not be linked with BDB 4.3 > > Synopsis: OpenLDAP should not be linked with BDB 4.3 > > State-Changed-From-To: open->feedback > State-Changed-By: delphij > State-Changed-When: Wed Nov 15 23:41:22 UTC 2006 > State-Changed-Why: > Have you ever hit a bug with the current linkage? The > change would require a user to dump and re-import their > database, so I need some evidence that BDB 4.3 is causing > problem before I can make a change. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=105585 > > . -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

2 2

proxycache + back-shell
by Denis Gaertner 15 Nov '06

15 Nov '06

Hi, I got a problem with the proxycache. I am trying to use it together with back-shell. This is my configuration, partly take from the manual. --------------------------------------------------------------------- database shell suffix "c=de" search /usr/bin/php /opt/scripts/shell.php rootdn "uid=admin,c=de" rootpw "0545" overlay pcache proxycache shell 100000 1 1000 100 proxycachequeries 1000 proxyAttrset 0 objectClass cn sn mail postaladdress telephonenumber proxyTemplate (sn=) 0 3600 proxyTemplate (&(sn=)(givenName=)) 0 3600 proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600 index cn,sn,uid pres,eq,approx,sub index objectclass pres,eq ------------------------------------------------------------------------ If I try to search for (sn=sth.) with the cn attribute as the result attribute I get the result the first time from the script. The second time the proxy gets in and this is the result: result: 53 Server is unwilling to perform text: search not implemented Now I have to say that the script always returns all attributes, no matter what you put in the request. But the frontend filters it. Might that be a problem? Thank you

2 1

How To Configure w/ FreeBSD
by Rachel Florentine 15 Nov '06

15 Nov '06

Hi; This may be OT, but after 3 days of trying to get my question answered on FreeBSD lists, I figured I'd come back here where I know you guys have the answer ;) I would like to run the following env/options in building OpenLDAP: env \ CPPFLAGS=-I/usr/local/include/db42 LDFLAGS=-L/usr/local/lib/db42 CC=gcc \ ./configure \ --localstatedir=/var/run/slapd \ --enable-spasswd \ --enable-modules \ --enable-shared \ --enable-dynamic \ --with-tls \ --with-cyrus-sasl \ --enable-bdb \ --disable-slapd \ --enable-openssl \ --enable-monitor \ --enable-proxycache \ --enable-unique \ --enable-ppolicy \ --enable-accesslog \ --disable-cleartext *However*, one has to perform some mystical incantation when doing this with the FreeBSD port system. I need someone to initiate me into this mystery. That is, can someone just give me the command I need to issue to build OpenLDAP the way I want to? Rewrite the above with whatever necessary wrappers to get FreeBSD to swallow it? TIA, Rachel

4 3

Re: trouble with filter
by Kurt D. Zeilenga 15 Nov '06

15 Nov '06

At 04:15 AM 11/15/2006, Giulio Federici wrote: >test:~# ldapsearch -x -D "cn=admin,dc=burp" -w <xxx> -s sub -b "dc=burp" "(objectClass=*o*)" Substring assertions are only sensible where the attribute type's values are strings (as opposed to represented as strings) and has been defined with an appropriate substrings matching rule. Values of objectClass attribute are OIDs and sensibly the objectClass is defined with no substrings matching rule. Hence, slapd(8) properly regards the assertion as Undefined and the filter evaluates to False. -- Kurt

1 0

trouble with filter
by Giulio Federici 15 Nov '06

15 Nov '06

hi, i have a openldap 2.2.23 (official package 2.2.23-8 on debian stable): test:~# slapcat dn: dc=burp objectClass: top objectClass: dcObject objectClass: organization o: burp dc: burp structuralObjectClass: organization dn: cn=admin,dc=burp objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: <xxx> dn: ou=People,dc=burp objectClass: top objectClass: organizationalUnit ou: People structuralObjectClass: organizationalUnit dn: ou=Media,dc=burp objectClass: top objectClass: organizationalUnit ou: Media structuralObjectClass: organizationalUnit test:~# cat /etc/ldap/slapd.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb backend bdb checkpoint 512 30 database bdb suffix "dc=burp" directory "/var/lib/ldap" index objectClass eq lastmod on access to attrs=userPassword by dn="cn=admin,dc=burp" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=burp" write by * read test:~# ldapsearch -x -D "cn=admin,dc=burp" -w <xxx> -s sub -b "dc=burp" "(objectClass=*o*)" # extended LDIF # # LDAPv3 # base <dc=burp> with scope sub # filter: (objectClass=*o*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 test:~# test:~# slapd -d 6 @(#) $OpenLDAP: slapd 2.2.23 (May 30 2005 08:52:42) $ @pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.23 /debian/build/servers/slapd daemon_init: <null> bdb_db_init: Initializing BDB database bdb_db_open: dc=burp slapd starting connection_get(10) ldap_read: want=8, got=8 0000: 30 24 02 01 01 60 1f 02 0$...`.. ldap_read: want=30, got=30 0000: 01 03 04 10 63 6e 3d 61 64 6d 69 6e 2c 64 63 3d ....cn=admin,dc= 0010: 62 75 72 70 80 08 34 38 37 72 61 73 69 6d burp..<xxx> ldap_read: want=8 error=Resource temporarily unavailable ==> bdb_bind: dn: cn=admin,dc=burp send_ldap_result: err=0 matched="" text="" 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ connection_get(10) ldap_read: want=8, got=8 0000: 30 33 02 01 02 63 2e 04 03...c.. ldap_read: want=45, got=45 0000: 07 64 63 3d 62 75 72 70 0a 01 02 0a 01 00 02 01 .dc=burp........ 0010: 00 02 01 00 01 01 00 a4 12 04 0b 6f 62 6a 65 63 ...........objec 0020: 74 43 6c 61 73 73 30 03 81 01 6f 30 00 tClass0...o0. ldap_read: want=8 error=Resource temporarily unavailable SRCH "dc=burp" 2 0 0 0 0 filter: (?=undefined) attrs: bdb_idl_fetch_key: [b49d1940] send_ldap_result: err=0 matched="" text="" 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ connection_get(10) ldap_write: want=14, written=14 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ldap_read: want=8, got=0 slapd shutdown: waiting for 0 threads to terminate slapd stopped. test:~# any idea?

2 2

Re: Problem with replica.
by Pierangelo Masarati 15 Nov '06

15 Nov '06

Please keep replies on the mailing list. Paul Shevtsov wrote: > On Tue, Nov 14, 2006 at 06:12:18PM +0100, Pierangelo Masarati wrote: > >> Apparently, your client tries to chase referrals anonymously, and this >> fails as expected. I don't see any software malfunction here (on the >> OpenLDAP side, at least); there might be a missing or misimplemented >> feature in the client, though. >> > > Ok. I try on slave side > Client message > ------------------------------------------------------------------------- > #ldapadd -W -x -D "cn=root,dc=dgb,dc=local" -f bbb1.ldif > #Enter password: > adding new entry "uid=bbb1,ou=users,dc=dgb,dc=local" > ldap_add: Referral (10) > refferals: > ldap://ldap.dgb.local/uid=bbb1,ou=users,dc=dgb,dc=local > ------------------------------------------------------------------------- > Server message (loglevel stats sycn) > ------------------------------------------------------------------------- > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 fd=12 ACCEPT from IP=127.0.0.1:61526 (IP=0.0.0.0:389) > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 op=0 BIND dn="cn=root,dc=dgb,dc=local" method=128 > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 op=0 BIND dn="cn=root,dc=dgb,dc=local" mech=SIMPLE ssf=0 > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 op=0 RESULT tag=97 err=0 text= > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 op=1 ADD dn="uid=bbb1,ou=users,dc=dgb,dc=local" > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 op=1 RESULT tag=105 err=10 text= > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 op=2 UNBIND > Nov 15 09:10:51 casablanca slapd[63235]: conn=863 fd=12 closed > --------------------------------------------------------------------------- > And from master side i look tcmpdump and not received any > packets. > This is native ldapadd. :( > This question has been asked (and answered!) so many times... OpenLDAP tools solve the problem of authenticated referral chasing by delegating it to the user. They simply return a referral and don't even try to chase it anonymously (as supposed to be useless for writes) nor by propagating credentials to the referred DSA (it would be a very poor decision, as the client has no means to determine whether the referred DSA is trusted or not; or, whenever distributed authentication is implemented, it is very likely that the referred DSA has no means to authenticate an otherwise valid user for the initially contacted DSA. > > When i try use smbldap-useradd i got: > ------------------------client message------------------------------------- > smbldap-useradd bbb2 > Error: Referral received at /usr/local/lib/perl5/site_perl/5.8.8/smbldap_tools.pm line 1056 > ---------------------------------------------------------------------------- > > --------------------------server message------------------------------------ > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 fd=21 ACCEPT from IP=127.0.0.1:50523 (IP=0.0.0.0:389) > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=0 BIND dn="cn=root,dc=dgb,dc=local" method=128 > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=0 BIND dn="cn=root,dc=dgb,dc=local" mech=SIMPLE ssf=0 > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=0 RESULT tag=97 err=0 text= > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=1 SRCH base="dc=dgb,dc=local" scope=2 deref=2 filter="(&(objectClass=posixAccount)(uid=bbb2))" > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=2 SRCH base="sambaDomainName=dgb,dc=dgb,dc=local" scope=0 deref=2 filter="(objectClass=sambaUnixIdPool)" > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=3 MOD dn="sambaDomainName=dgb,dc=dgb,dc=local" > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=3 MOD attr=uidNumber > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 op=3 RESULT tag=103 err=10 text= > Nov 15 09:40:24 casablanca slapd[63235]: conn=885 fd=21 closed (connection lost) > ------------------------------------------------------------------------------ > > And again any packets on master side. > > I should solve a problem of synchronization of passwords > for samba from slave to master LDAP. > And not find the decision. :( > > Help me please.... :) > Where i am mistaken? > > I think OpenLDAP has little to do with smbldap-useradd; however, it looks like that that tool is working as expected, since it behaves the same as ldapadd... p.

2 1

several replication questions (2nd try)
by Sepp 14 Nov '06

14 Nov '06

Hello, here is our three-level concept for replication, 1 provider, 2 subproviders, 10 consumers: * the provider should replicate most of his subtrees to both subproviders * a few subtrees should be replicated from the 2 subproviders to the provider * subprovider no1 should replicate his whole tree to 5 consumers * subprovider no2 should replicate his whole tree to the other 5 consumers * a few user entries (eg. the replication manager) should be replicated from subprovider no.1 to subprovider no.2, and from 1 consumer to the other 9 comsumers Here are the questions concerning this config: 1.) Is the best (and perhaps only ?) way for an implementation to devide the DITs in subordinate databases with the according syncrepl statements (similar to openldap-2.3.28/tests/data/slapd-glue-syncrepl*.conf, we have a successful test config for that) 2.) Do we need the glue overlay in this context (I don't think so) ? 3.) Is it necessary that one subordinate have all indexes from all other subordinates (I do think so, to prevent "index_param failed" error messages when searching from top level) 4.) Sorry, when that's a FAQ: Is it a must that the updatedn is not the same like the rootdn or is it only a recommendation ? Is this for security reasons or why ? 5.) With slurpd it is possible to replicate more than one subtrees from one database with several "suffix"-statements. How can I do that with syncrepl ? I didn't find a way to define more than one "searchbase" per "syncrepl rid" or to define more than one "syncrepl rid" per "database". I thank you for help in advance ! Regards Sepp

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software