[Date Prev][Date Next]
Re: (ITS#4487) Problem with dereferencing aliases to remote DB with different suffix
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#4487) Problem with dereferencing aliases to remote DB with different suffix
- From: email@example.com
- Date: Wed, 12 Apr 2006 23:26:17 GMT
- Content-disposition: inline
Did I understand you correctly that the issue is going to be fixed in
further versions of OpenLDAP?
On 4/12/06, Pierangelo Masarati <firstname.lastname@example.org> wrote:
> On Wed, 2006-04-12 at 00:49 +0000, email@example.com wrote:
> > Irrelevant. Aliases are not the same as referrals. Aliases can only
> > point to other entries within the same database, you must use referrals
> > to point to something in a different database.
> The question may not be pointless: amorphous stuff like back-meta, in
> some cases could be used to mask the distribution of the database; in
> those cases, clients might want to be able to dereference aliases under
> the perception that the database is monolithic.
> So, if the existence of the alias is the result of a write operated by a
> client which was induced to believe that the database is monolithic, it
> would be reasonable to have that alias treated appropriately by back-
> meta; otherwise, it's just an indication of poor database
> design/maintenance: LDAP does not prevent writing dangling aliases, and
> one shouldn't rely on dangling aliases to work as incorrectly expected.
> In fact, I'm facing a number of problems in making a distributed
> database appear to clients as non-distributed. Currently, aliases
> cannot be distributed (and I don't think they'll ever be by back-meta)
> since back-meta doesn't really try to hide the fact that the database is
> actually distributed (except for allowing automatic referral chasing).
> One of the problems I had to deal with is cross-database renaming; I
> worked it around by copying the entry from the original to the new
> database while renaming, using manageDIT to preserve operationals as
> appropriate (and the whole operation is not ACID; I need to redesign it
> using LDAP transactions, and there likely remain ACID issues related to
> the commit sequence with the two databases). This feature is not in
> back-meta yet; will be merged in some time. A similar feature could be
> added to slapo-glue as well.
> Ing. Pierangelo Masarati
> Responsabile Open Solution
> OpenLDAP Core Team
> SysNet s.n.c.
> Via Dossi, 8 - 27100 Pavia - ITALIA
> Office: +39.02.23998309
> Mobile: +39.333.4963172
> Email: firstname.lastname@example.org