openldap-software July 2008

openldap-software@openldap.org

72 participants
81 discussions

explain diff between multimaster and mirror mode
by Liutauras Adomaitis 20 Jul '08

20 Jul '08

Since English is not my mother tong, can someone explain me what is ment in http://www.openldap.org/doc/admin24/replication.html#Mixture%20of%20both%20… by saying "MirrorMode is not what is termed as a Multi-Master solution. This is because writes have to go to one of the mirror nodes at a time"? Is it that I have always write to the same master? Can I do writes some times to one sometimes to another, but not to both at the same time? Which way Multi-Mater or Mirror-Mode is easier to recover from broken replication. On Master-Slave I just delete Slave db and restart ldap, this is acceptible for me because there is no much data to replicate. I'm using Master-Slave replication now, but it seems that it is not good for some reason, which I don't know and can't explain. So trying to find an alternative, but don't want to learn on my own mistakes on production :) Liutauras

2 3

syncrepl failure logs/configuring alias deref
by Paul B. Henson 18 Jul '08

18 Jul '08

I recently installed some updates and configuration changes on one of my LDAP slaves. Replication broke mysteriously after that. I turned on full debugging on slapd and just saw this: ----------- Jul 11 12:42:51 pip slapd[30723]: =>do_syncrepl rid 001 Jul 11 12:42:51 pip slapd[30723]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jul 11 12:42:51 pip slapd[30723]: =>do_syncrep2 rid 001 Jul 11 12:42:51 pip slapd[30723]: do_syncrep2: rid 001 LDAP_RES_SEARCH_RESULT Jul 11 12:42:51 pip slapd[30723]: connection_get(12) Jul 11 12:42:51 pip slapd[30723]: connection_get(12): got connid=0 Jul 11 12:42:51 pip slapd[30723]: daemon: removing 12 Jul 11 12:42:51 pip slapd[30723]: daemon: activity on 1 descriptor Jul 11 12:42:51 pip slapd[30723]: daemon: activity on: Jul 11 12:42:51 pip slapd[30723]: Jul 11 12:42:51 pip slapd[30723]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jul 11 12:42:51 pip slapd[30723]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jul 11 12:42:51 pip slapd[30723]: daemon: activity on 1 descriptor Jul 11 12:42:51 pip slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left) ----------- The replica would continue to connect over and over again to the master, and the logs just kept saying "retrying". Finally, I ended up having to disable TLS on the replica and temporarily allow plaintext authentication on the master. On reviewing the packet capture, it was immediately obvious that the search Was failing with a protocol error because derefAliases was set to always. A quick Google search indicated that other people have had a similar problem, generally because they changed the global LDAP configuration file. Indeed, I had switched to NFS home directories with the auto mounter, and LDAP integration for my deployment required dereferencing aliases by the auto mount client, so I had set "DEREF always" in /etc/openldap/ldap.conf, which is being inherited by slapd. It would be useful if replication failure provided better error messages; something in the logs indicating that a protocol error had occurred because of an invalid dereferencing setting would have saved me a lot of time. Also, if alias dereferencing is not valid for a syncrepl query, shouldn't the server simply override that setting from the global configuration and do the right thing? In any case, I find myself stuck: the auto mounter requires alias dereferencing in order to work; while slapd requires alias dereferencing disabled. There appears to be three ways to define configuration: the global configuration file, a configuration file in the home directory, or an environment variable. The global configuration file will not work, as I require a different option setting for two processes. The home directory configuration file will not work, as both automount and slapd look in ~root. while I could probably kludge an init script to pass an environment variable to one or the other process, the init script framework does not allow for that and I would prefer something that fits within the intended operating system configuration. Any suggestions on how to best have a different LDAP configuration for two processes both running as root? Would there be any value in modifying slapd to ignore the alias dereferencing setting for the purposes of syncrepl? Or to enhance the slapd.conf file to allow setting general LDAP configuration options? Or perhaps a commandline option allowing the specification of either an alternate configuration file or LDAP configuration options on the command line? Thanks much for any suggestions or assistance... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson(a)csupomona.edu California State Polytechnic University | Pomona CA 91768

5 12

Request for Recommendation/Comments: adding another multimaster node
by Chris G. Sellers 17 Jul '08

17 Jul '08

I have two multimaster nodes. I would like to add a third node. I wondered if there is a best method that has been observed. Should I slapcat | slapadd , add the syncrpl lines, and start the servers 1 and 2 and then finally 3? Should I just add the syncrepl lines and let it autobuild on 3 (starting in 1 2 3 order) Should I do an ldapsearch and ldapadd and let the syncrepl fix the metadata attributes only ? Thoughts, comments, suggestions. I know I saw this on the list a while ago but I can't see to find it. (I'll document for the admin docs with what I find) Sellers ++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers(a)nitle.org Jabber: csellers(a)nitle.org | AIM: imthewherd

3 2

Re: (ITS#5620) Compile problem with Berkeley DB 4.7.25
by Michael Ströder 17 Jul '08

17 Jul '08

marco.walther(a)sun.com wrote: > I'm more interested in the client libraries than the servers right now. Then use with OpenLDAP 2.3: configure --disable-slapd --disable-slurpd with OpenLDAP 2.4: configure --disable-slapd to only build the client lib and command-line tools. CIao, Michael.

1 0

replication crashes 1 of 2 servers - after working for months
by Chris G. Sellers 16 Jul '08

16 Jul '08

I have an Multimaster/mirrormode replication that has worked for months. Someone put some crappy data into the LDAP and then it crashed. I've spent weeks cleaning up the data, thinking that was causing my replication to crash and core dump one of my two LDAP servers I have cleaned up the data, loaded all the data from server1 to server2 and turned on the replication again, but I still get core dumps on server2. (server1 never has a problem) I'm not sure where to go from here. Any suggestions or anyone else who came across the same problem. Below are some log and config entries. Host OS is Solaris10 on server1 and OpenSolaris on server2. (I have three other openLDAP servers running two with the same replication so I'm somewhat experienced with getting this to work so I'm thinking it's a strange problem I hope someone has run across) log (server2): ========== Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "cn=manager,dc=nitle,dc=org" "obj ectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours cn=manager,dc=nitle,dc=org ours 20080702134355.493573Z#000000#002#000000, new 20080107224745.105385Z#000000#002#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (cn=manager,dc=nitle ,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID c76c7c0c-57fb-102c-9216-63c463e 7d505 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" request ed Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 688566 local4.debug] syncrepl_entry: rid=010 be_add (68) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "entry " requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "objectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours ou=guest,dc=nitle,dc=org ours 20080715143748.768257Z#000000#002#000000, new 20080115212254.445224Z#000000#001#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (ou=guest,dc=nitle,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID 3a055df6-54c8-102c-9c74-3bd710846f22 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 uid=jbeckelm(a)coe.edu,ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) (** CRASHES HERE EVERY TIME **) conf(server2): =========== syncrepl rid=010 provider=ldap://ldap1.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 schemachecking=off starttls=yes syncrepl rid=011 provider=ldap://ldap2.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist schemachecking=off scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes overlay syncprov serverID 2 mirrormode true Thanks in advance! Sellers ++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers(a)nitle.org Jabber: csellers(a)nitle.org | AIM: imthewherd

5 8

slapo-unique
by Alexander Kriventsov 16 Jul '08

16 Jul '08

Hello. I have some strange issue with unique overlay. When I use these directives in slapd.conf overlay unique unique_uri ldap:///"o=company"?uid?sub I've been got error Starting slapd. Assertion failed: (pretty != NULL), function dnPrettyNormal, file dn.c, line 724. Abort trap I'm using openldap v 2.4.9 and FreeBSD 7.0. Without any dn information in unique_uri slapd starts fine. Let me know if you need any more information. I didn't find any information about this error anywhere. Please help. Thanks -- Best Regards, Alexander Kriventsov .masterhost

3 4

ACL: write access allowed based on a user specific attribute
by Francois Marot 16 Jul '08

16 Jul '08

Hello all OpenLDAP users, I'm quite new to LDAP and I need to modify a currently existing LDAP database. There exist users in the database which can authentify, and I would like to add a specific parameter on some of those users to enable write access to them (for the moment they only have read access) For example I currently have 2 users: uid=user1,ou=Users,dc=myCompany,dc=fr uid=user2,ou=Users,dc=myCompany,dc=fr I changed my schema in order to be able to define an attribute admin="TRUE" on user1. Now, I would like that only user1 could change anything in the database, and not user2. How would I do that ? Is it possible to define an ACL based on the attribute of a DN ? Thanks Francois MAROT

2 2

Reading debug output
by Jeff Adams 14 Jul '08

14 Jul '08

Simple question (hopefully) about how to read the output of acl logging. In the following line -- access_allowed: read access granted by read(=rscxd) -- what does "rscxd" mean? Is this line really saying that only read access was granted?

3 2

Again ACL problems
by Sebastian Reinhardt 14 Jul '08

14 Jul '08

I have a problem by configuring access to an shared address book. Users and groups are defined in following structure: dc=mycompany,dc=org |--ou=abook | |----cn=adressbookentry1 | |----cn=adressbookentry2 | |----...... |--ou=groups | |----cn=group1 | |----cn=abook_rw | |----cn=abook_ro | |----........ |--ou=users | |----uid=user1(member of group "abook_rw") | |----uid=user2(member of group "abook_ro") | |----......... Now users of group "abook_rw" should be able to write/edit an entry into "ou=abook", but members of "abook_ro" should have read-only access. I tried this "slapd.conf" config entry: access to dn.subtree="ou=abook,dc=mycompany,dc=org" by group="cn=abook_rw,dc=mycompany,dc=org" write by group="cn=abook_ro,dc=mycompany,dc=org" read But only "ldaproot" can access "ou=abook" by using ldap- client software (KAdressbook, LDAP- Editor)! What is wrong? -- Mit freundlichen Grüßen Sebastian Reinhardt

3 2

Re: Problems with SASL EXTERNAL and ldapi:// on solaris
by Michael Ströder 13 Jul '08

13 Jul '08

David, please stay on the openldap-software mailing list! David Markey wrote: > I built it from scratch and also i got the packages off blastwave. If i > could enable it as a once off for this setup i would be able to deal > with the security concerns because no users would be on this machine. Is > there a way to force it to support EXTERNAL? Did you use this? configure --enable-local=yes Ciao, Michael.

4 5

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software July 2008