openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 13 Feb '09

13 Feb '09

ando(a)sys-net.it wrote: > Also, please note that modifications to olcRwmRewrite is not allowed, > unless consisting in a full replace without {} idxes. The operation you > were trying, More about this: now slapo-rwm supports add/delete/modify olcRwmRewrite values (in a far from optimal manner). 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

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 13 Feb '09

13 Feb '09

ando(a)sys-net.it wrote: > Please forget my previous posting. Your issue should now be solved in > HEAD. Please test. p. Also, please note that modifications to olcRwmRewrite is not allowed, unless consisting in a full replace without {} idxes. The operation you were trying, 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- is not allowed. This is allowed, though: 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- note the missing {0}. Support for renumbering of olcRwmRewrite could be introduced by removing rewrite info and regenerating it from the saved values. 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

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > Howard Chu wrote: > >> hyc(a)symas.com wrote: >> >>> jclarke(a)linagora.com wrote: >>> >>>> I saw the comment in the code that clarifies this behaviour. However, it's a >>>> surprising behaviour, and I think there is code to parse this kind of thing in >>>> the serverID detection now. Maybe it could be reused? >>>> >> Oops, never mind. I was thinking of the serverID code, and you're talking >> about the syncrepl code. >> >> I'll have to think a bit about why the two aren't behaving identically; >> probably they should both use the same code. >> >> > Ah right. For the serverID code, we're doing a liberal match because anything > that matches the current name:port is obviously the current server, and we > want it to be identified as such. > > For syncrepl, we know full well that it may be the current server, but for > whatever reason you may want to replicate against yourself anyway (e.g., > against a different baseDN, etc...). > Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results. Jon

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

jclarke(a)linagora.com wrote: > Given a simple setup involving back-ldap with slapo-rwm on top, modifying the > attribute "olcRwmRewrite" causes a crash. This seems to happen both while > modifying an existing value, or when deleting one. Please forget my previous posting. Your issue should now be solved in HEAD. Please test. 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

Re: (ITS#5943) back-relay does not recognize when would call self
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Simply comparing the BackendDB pointers of the operation and of the operation's > DN does not detect when back-relay would call self, possibly resulting in > endless loop. should be fixed in HEAD. Please test. 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

(ITS#5943) back-relay does not recognize when would call self
by ando＠sys-net.it 12 Feb '09

12 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Simply comparing the BackendDB pointers of the operation and of the operation's DN does not detect when back-relay would call self, possibly resulting in endless loop. p.

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

Le Jeu 12 février 2009 20:41, Howard Chu a écrit : > jclarke(a)linagora.com wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi, >> >> When adding a syncrepl config, the function add_syncrepl performs a >> "check if >> URL points to current server". This check is based on an exact match >> between the >> provider parameter from the syncrepl config line, and the URIs given to >> slapd on >> startup. >> >> If this doesn't match when it should, the database is marked as a >> shadow, and >> all following updates fail with "shadow context; no update refs". This >> is quite >> a pain when it happens on cn=config :) >> >> There are multiple cases when this happens: >> 1) If no specific URI was specified on launch (no -h option) >> 2) Port numbers are explicitly specified or not (":389") >> 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") >> 4) IP is specified rather than DNS name ("ldap://localhost" != >> "ldap://127.0.0.1") >> >> I saw the comment in the code that clarifies this behaviour. However, >> it's a >> surprising behaviour, and I think there is code to parse this kind of >> thing in >> the serverID detection now. Maybe it could be reused? >> >> Otherwise, we should probably document this behaviour, to avoid >> headaches :) > > The manpage says the serverID URL must use an FQDN. We already do a number > of > guesses in the code, I don't see any reason to extend this further. I'm sorry, but I was not referring to the serverID URI matching. I'm referring to syncrepl provider matching to listeners. I mentioned the serverID matching since it seems to work like syncrepl provider matching should. Regards, Jonathan

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 12 Feb '09

12 Feb '09

The problem can be easily reproduced, no need for further testing. However, I don't see an easy and clear fix right now. In the meanwhile, you should stack something in between to obtain the desired result. Having another proxy in between that deals with rwm could help. 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

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

Howard Chu wrote: > hyc(a)symas.com wrote: >> jclarke(a)linagora.com wrote: >>> I saw the comment in the code that clarifies this behaviour. However, it's a >>> surprising behaviour, and I think there is code to parse this kind of thing in >>> the serverID detection now. Maybe it could be reused? > > Oops, never mind. I was thinking of the serverID code, and you're talking > about the syncrepl code. > > I'll have to think a bit about why the two aren't behaving identically; > probably they should both use the same code. > Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such. For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > jclarke(a)linagora.com wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi, >> >> When adding a syncrepl config, the function add_syncrepl performs a "check if >> URL points to current server". This check is based on an exact match between the >> provider parameter from the syncrepl config line, and the URIs given to slapd on >> startup. >> >> If this doesn't match when it should, the database is marked as a shadow, and >> all following updates fail with "shadow context; no update refs". This is quite >> a pain when it happens on cn=config :) >> >> There are multiple cases when this happens: >> 1) If no specific URI was specified on launch (no -h option) >> 2) Port numbers are explicitly specified or not (":389") >> 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") >> 4) IP is specified rather than DNS name ("ldap://localhost" != >> "ldap://127.0.0.1") >> >> I saw the comment in the code that clarifies this behaviour. However, it's a >> surprising behaviour, and I think there is code to parse this kind of thing in >> the serverID detection now. Maybe it could be reused? Oops, never mind. I was thinking of the serverID code, and you're talking about the syncrepl code. I'll have to think a bit about why the two aren't behaving identically; probably they should both use the same code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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