slapd.d and back-sql
by Robson, Alan
Hi all,
I'm trying to set up back-sql on Ubuntu using openldap version 2.4.39 that uses slapd.d as its configuration store.
All of the config examples I can find online use slapd.conf. A 2011 email from this mailing list explains that it simply is not possible to use the slapd.d config method to specify a dbname. Is that still the case ?
I am trying to add an entry for my mysql database using ldapadd and the following ldif...
# order value not present so entry will be appended
# to current children
dn: olcDatabase=sql,cn=config
objectClass: olcDatabaseConfig
olcDatabase: mysql
dbName: ldap
olcSuffix: dc=nodomain
The response I get is...
adding new entry "olcDatabase=sql,cn=config"
ldap_add: Undefined attribute type (17)
additional info: dbName: attribute type undefined
I tried dbname (no capital N) as well, but I get the same result.
As you may be able to tell, I have a very loose grip on what to do here ! I'd appreciate some guidance. I am confident that I have odbc and the database/user set up as it describes in the manual section on back-sql. My database connection is called "ldap" in odbc.ini.
/etc/odbcinst.ini:
[mysql]
Description = ODBC for MySQL
Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libodbcmyS.so
FileUsage = 1
/etc/odbc.ini:
[ldap]
Description = MySQL connection to 'test' database
Driver = mysql
Database = ldap
UserName = ldap
Password = ldap
Server = localhost
Port = 3306
Socket = /var/run/mysqld/mysqld.sock
If I need to go back to using slapd.conf, how can I generate one from my slapd.d setup ?
Many thanks
Alan
9 years, 8 months
OpenLDAP compatibility between client and server of different versions
by Fabien C.
Hello,
I have a few questions about OpenLDAP versions compatibility:
- How to know what version of OpenLDAP client is compatible with what version of the server?
- Is there backward or forward compatibility tables from the client and/or server point of view?
- For a given version of the server, how to know which clients are compatible, and conversely?
- And most important: what about replication?
Thank you!
Fabien C.
9 years, 8 months
RE: Syncrepl and mmr
by Quanah Gibson-Mount
--On Friday, January 31, 2014 2:37 PM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> I am using OpenSSL 0.9.8 (CentOS rpm version -- CentOS 5.9),
> unfortunately and I cannot upgrade it. Oddly it works for all other
> connections between these systems and clients...I don't understand why it
> isn't for this portion.
Well, you're at a point where I don't know how to help you further.
Something's definitely wrong with your TLS stack, but I've no idea what. ;)
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 8 months
Re: Syncrepl and mmr
by Michael Ströder
Borresen, John - 0442 - MITLL wrote:
> I'm not trying to implement partial replication.
Missed the smiley?
Your *first* ACL should give read access to the whole tree to the group of
replicas and then pass on all other access checking to the subsequent ACLs (by
* break).
Something like:
limits
group="cn=replicas,dc=example,dc=com"
time=unlimited
size=unlimited
access to
dn.subtree="ou=ampua"
by group="cn=replicas,dc=example,dc=com" read
by * break
Ciao, Michael.
> -----Original Message-----
> From: Michael Ströder [mailto:michael@stroeder.com]
> Sent: Friday, January 31, 2014 2:15 PM
> To: Quanah Gibson-Mount; Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: Re: Syncrepl and mmr
>
> Quanah Gibson-Mount wrote:
>> --On Friday, January 31, 2014 1:20 PM -0500 "Borresen, John - 0442 - MITLL"
>> <John.Borresen(a)ll.mit.edu> wrote:
>>
>>> Thanks, Quanah
>>>
>>> Not sure what you meant by " Well, it may not have been this issue, but
>>> it definite would become an issue then."
>>>
>>> Was what I did a good thing or not? Curious minds want to know. <lol>
>>
>> The lack of read permissions for the replication user would absolutely be an
>> issue at some point. ;)
>
> To put it the other way round:
> It's very hard to implement partial replication correctly. ;-}
>
> Ciao, Michael.
9 years, 8 months
RE: Syncrepl and mmr
by Quanah Gibson-Mount
--On Friday, January 31, 2014 2:25 PM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> I'm not trying to implement partial replication. Throwing darts from 100
> miles away and trying to hit a penny nailed to the opposite side of
> tree...yes that is what I feel like I'm doing. :
At this point, I've no idea what you've done to break your servers in
relation to TLS. I would ask what SSL implementation you are linked to
(Openssl, GnuTLS, or MozNSS).
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 8 months
RE: Syncrepl and mmr
by Quanah Gibson-Mount
--On Friday, January 31, 2014 1:20 PM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> Thanks, Quanah
>
> Not sure what you meant by " Well, it may not have been this issue, but
> it definite would become an issue then."
>
> Was what I did a good thing or not? Curious minds want to know. <lol>
The lack of read permissions for the replication user would absolutely be
an issue at some point. ;)
> MM Server1:
># ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D
># cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl
What CA cert is your ldapsearch command using?
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 8 months
RE: Syncrepl and mmr
by Quanah Gibson-Mount
--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> Thanks Quanah
>
> I'm sure it isn't 100% correct, but I added the following ACL to my
> accesslog DB on both MM servers:
>
> olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none
Well, it may not have been this issue, but it definite would become an
issue then. ;)
> I'm still seeing
> gp42-admin3 (MM server1)
> Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH
> base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN reqType
> reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]:
> do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3
> slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection lost
> on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: rid=002
> got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Your masters are unable to talk to each other. You need to determine why.
This will take debugging on your part, as I've never seen anything like
this before.
> gp42-admin4 (MM server2)
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from
> IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 Jan
> 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 err=13
> text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap"
> method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1
> RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19
> gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 closed
> Jan 31 08:25:51 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty
> syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4
> slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
This says that your consumer is connecting without sending a startTLS,
while you've configured the master to require startTLS. Clearly you need
to either enable startTLS in the syncrepl statement, or not require
starttls on your master.
--Quanah
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Thursday, January 30, 2014 5:10 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 -
> MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>
>> Well, that was helpful -- lol
>
>
> Looking at your previously supplied configuration, it is clearly apparent
> that you provided your replication user no ACLs to read the accesslog DB,
> so the error you see makes sense. It can't read the data out of
> accesslog, so it throws an error stating that fact.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 8 months
RE: Syncrepl and mmr
by Quanah Gibson-Mount
--On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 -
MITLL" <John.Borresen(a)ll.mit.edu> wrote:
> Well, that was helpful -- lol
Looking at your previously supplied configuration, it is clearly apparent
that you provided your replication user no ACLs to read the accesslog DB,
so the error you see makes sense. It can't read the data out of accesslog,
so it throws an error stating that fact.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 8 months
Re: Overlay ppolicy not found
by Dieter Klünter
Am Thu, 30 Jan 2014 12:13:04 +0000
schrieb Rodrigo Coutinho <Rodrigo.Coutinho(a)ifap.pt>:
> Hi again,
>
> Th result was:
>
> Included static overlays:
> syncprov
> Included static backends:
> config
> ldif
> monitor
> bdb
> hdb
> mdb
> relay
>
> What now?
Check with your OS Distribution whether there are additional dynamic
loadable modules.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
9 years, 8 months
