openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#5843) Multi-master doesn't replicate deletes under certain circumstances.
by ildefonso_camargo＠yahoo.com 02 Dec '08

02 Dec '08

Full_Name: Jose Ildefonso Camargo Tolosa Version: 2.4.13 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (190.73.138.178) Hi! I just configured multi-master replication (with N=3) for testing purposes, and I just found an annoying problem, under these conditions: 1. Configure a N number of "masters", and have them replicate happily (this is important). 2. Stop slapd service on all of the servers. 3. Start slapd service on any number of servers < N (ie, leave at least one stopped). 4. Delete any entry (yes, it only fails with deletes, you can combine changes: modify, add, and delete, and only deletes will fail to replicate). 5. Stop slapd service on *all of the servers again* (this is the most important part). 6. Start slapd service on all the servers. 7. Look for the deleted entry on the server(s) that you left stopped in steps 3 and 4, the entry is there!, but it isn't on the server(s) that were running in step 3 and 4. You will see that, on the servers that you left down on step 3, the deleted entries are still present. If you leave at least one server up, it replicates just fine, the problem is when you stop all of the masters, and then start them again. If you need further info, just ask! I hope this helps, Ildefonso Camargo

1 0

Re: (ITS#5839) overlay glue
by rein＠OpenLDAP.org 02 Dec '08

02 Dec '08

marin.lehouelleur(a)astrium.eads.net wrote: > Full_Name: Marin Le Houelleur > Version: 2.3.32 > OS: Linux RH5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.94.82.30) > > Working for one year now with this version of Openldap. I come to the point I > need to glue different branch of my master to the slaves to manage complexe > filtering that I'm unable to manage with overlay syncrepl filters First of all you should upgrade, preferrable to the latest 2.4 release. There have been a lot of syncrepl fixes since this version. But your config design is likely to not function, as only one syncrepl consumer can reliably be configured within a glued set of databases to replicate from the same consumer. You should instead configure syncrepl on the glue suffix with a simple filter that matches all you replicate (or just leave it out and use the default). Configure ACLs on the master that gives each consumer access to only those entries it should receive. Rein

1 0

Re: (ITS#5842) test049, test050 fail on Windows due to "con" filename
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Tuesday, December 02, 2008 3:59 PM +0000 test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.11 / HEAD > OS: Windows > URL: > Submission from: (NULL) (195.39.55.20) > > > ``make test'' on Cygwin fails with test049, test050, because "con" is a > special device name on Windows. Thanks, fixed in HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Monday, December 01, 2008 9:51 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 28, 2008 7:40 PM +0000 quanah(a)zimbra.com wrote: > >> >> >> --On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: > > Latest backtrace, with the patch from HEAD about idletimeout, we get: As a side note, here's a working teardown: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: connection_closing: readying conn=52 sd=22 for close Dec 2 17:45:05 ldap slapd[29835]: connection_close: deferring conn=52 sd=-1 Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: connection_resched: attempting closing conn=52 sd=22 Dec 2 17:45:05 ldap slapd[29835]: daemon: removing 22 Dec 2 17:45:05 ldap slapd[29835]: conn=52 fd=22 closed (idletimeout) Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 busy Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: listen=7, new connection on 22 Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: 22r Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: read active on 22 Dec 2 17:45:05 ldap slapd[29835]: daemon: added 22r (active) listener=(nil) Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: Dec 2 17:45:05 ldap slapd[29835]: Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=7 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: daemon: epoll: listen=8 active_threads=1 tvp=zero Dec 2 17:45:05 ldap slapd[29835]: conn=63 fd=22 ACCEPT from IP=192.168.61.36:49196 (IP=192.168.58.179:389) Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on 1 descriptor Dec 2 17:45:05 ldap slapd[29835]: daemon: activity on: As you can see, there's a break between the teardown and accept in this case, as compared to the scneario where it asserts. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5839) overlay glue
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Tuesday, December 02, 2008 1:41 PM +0000 marin.lehouelleur(a)astrium.eads.net wrote: > Full_Name: Marin Le Houelleur > Version: 2.3.32 > OS: Linux RH5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.94.82.30) The current OpenLDAP release is 2.4.13. The final OpenLDAP 2.3 release was 2.3.43. I suggest you try with either 2.3.43 if you don't want to move yet to OpenLDAP 2.4, or you switch to using OpenLDAP 2.4. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5842) test049, test050 fail on Windows due to "con" filename
by test.007＠seznam.cz 02 Dec '08

02 Dec '08

Full_Name: Test Seven Version: 2.4.11 / HEAD OS: Windows URL: Submission from: (NULL) (195.39.55.20) ``make test'' on Cygwin fails with test049, test050, because "con" is a special device name on Windows. Solution: simply use another name for consumer dir. --- test049-sync-config.orig Tue Feb 12 00:26:52 2008 +++ test049-sync-config Tue Dec 02 16:17:28 2008 @@ -25 +25 @@ -CONDIR=$TESTDIR/con +CONDIR=$TESTDIR/cons --- test050-syncrepl-multimaster.orig Mon May 05 23:42:54 2008 +++ test050-syncrepl-multimaster Tue Dec 02 16:25:52 2008 @@ -25 +25 @@ -CONDIR=$TESTDIR/con +CONDIR=$TESTDIR/cons

1 0

(ITS#5841) slapd hanging upon shutdown
by rhafer＠suse.de 02 Dec '08

02 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.134.124) After doing these two ldapmodify calls, shutting down slapd while the indexing task is running does not work anymore. slapd just keeps hanging. # ldapmodify -H ldapi:/// dn: olcDatabase={1}hdb,cn=config add: olcDbIndex olcDbIndex: cn eq,sub The above modification will trigger the indexing task. # ldapmodify -H ldapi:/// dn: cn=config replace: olcSizeLimit olcSizeLimit: 10000 When this operation is send while the indexing task is still running, it will wait for the task to complete. When slapd is shutdown during this timeframe, it will just lock up. Here is the backtrace of the hanging process: Thread 3 (Thread 0x7ff2ca2a5950 (LWP 13006)): #0 0x00007ff2ce07fd59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ff2d02f24fb in ldap_pvt_thread_pool_destroy (tpool=0x853688, run_pending=1) at ../../../libraries/libldap_r/tpool.c:570 pool = <value optimized out> pptr = (struct ldap_int_thread_pool_s *) 0x885540 task = <value optimized out> #2 0x0000000000431f9f in slapd_daemon_task (ptr=<value optimized out>) at ../../../servers/slapd/daemon.c:2591 l = 2 last_idle_check = 0 ebadf = 0 #3 0x00007ff2ce07c070 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007ff2cddef0ed in clone () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7ff2c9aa4950 (LWP 13007)): #0 0x00007ff2ce07fd59 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ff2d02f2a4d in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at ../../../libraries/libldap_r/tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x885540 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x1c ctx = {ltu_id = 140680742193488, ltu_key = {{ltk_key = 0x4337e0, ltk_data = 0xb0ee20, ltk_free = 0x4338b0 <conn_counter_destroy>}, { ltk_key = 0x488c10, ltk_data = 0xb0ef30, ltk_free = 0x488710 <slap_sl_mem_destroy>}, {ltk_key = 0x4478f0, ltk_data = 0xb0e9d0, ltk_free = 0x4476d0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = <value optimized out> keyslot = 829 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #2 0x00007ff2ce07c070 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007ff2cddef0ed in clone () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ff2d0714710 (LWP 12992)): #0 0x00007ff2ce07c7b5 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042ee3c in slapd_daemon () at ../../../servers/slapd/daemon.c:2656 listener_tid = 140680750586192 rc = 0 #2 0x000000000041cd95 in main (argc=7, argv=0x7fffd874b9e8) at ../../../servers/slapd/main.c:948 i = <value optimized out> no_detach = 1 rc = -12 urls = 0x854030 "ldap:/// ldapi:///" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x0 configdir = 0x854010 "/etc/openldap/slapd.d" serverName = 0x7fffd874d63b "lt-slapd" scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main"

1 0

(ITS#5840) bdb_online_index and shutdown
by rhafer＠suse.de 02 Dec '08

02 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.134.124) When slapd is shutdown while the online indexing task is active it will stop the indexing task immediately leaving a half created index files behind. Searches that use the index afterwards will return imcomplete results. I wonder if we should wait for the indexing task to complete when shutting down the daemon or if there are any other ways to put the databases and the configuration back into a consistant state. (Apart from manually running slapindex)

1 0

(ITS#5839) overlay glue
by marin.lehouelleur＠astrium.eads.net 02 Dec '08

02 Dec '08

Full_Name: Marin Le Houelleur Version: 2.3.32 OS: Linux RH5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.94.82.30) Working for one year now with this version of Openldap. I come to the point I need to glue different branch of my master to the slaves to manage complexe filtering that I'm unable to manage with overlay syncrepl filters Master : 1 db database bdb suffix dc=exemple,dc=com It contains following ou's : sites, applis and orgz sites itselfs contains site1, site2... and may contain more which should not be replicated to other sites overlay synchrorepl Slaves (1 per site) : 2 dbs database bdb suffix ou=sites,dc=exemple,dc=com synchrepl rid=111 searchbase ou=sites,dc=exemple,dc=com filter="(ou:dn:=site1)" database bdb suffix dc=exemple,dc=com synchrepl rid=222 searchbase dc=exemple,dc=com filter="(|(ou:dn:=orgz)(ou:dn:=applis))" overlay glue glue-sub ou=sites,dc=exemple,dc=com @ slapd start the directive glue-sub is ignored I tried on the first db to had directive "subordinate advertise" instead but it's documented not to be needed when using glue overlay. Nevertheless the 1st db is synchronised and searchable but not visible in tools such as ldapbrowser. best regards,

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 02 Dec '08

02 Dec '08

It seems OK with 2.4.13 > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : mardi 18 novembre 2008 22:39 > À : Emmanuel Duru > Cc : 'Hallvard Breien Furuseth'; openldap-its(a)openldap.org > Objet : Re: (ITS#5805) Problem when modifying access control > > Emmanuel Duru wrote: > > OK, my mistake, here follows a completely detailed description. > > I confirm HEAD and re24 behave as expected. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs