Re: (ITS#6531) Modify updateref to generate referrals on the backend
by rein＠basefarm.no
On 04/25/2010 12:49 AM, hyc(a)symas.com wrote:
> Also in terms of logical abstraction the current behavior is wrong; the
> frontend should of course generate the default_referral responses but
> updateref is a per-backend item and should be generated at the backend layer.
> Ideally this would all have been fixed to behave correctly by moving all
> replication support into an overlay, where it properly belongs. As an interim
> step it would be trivial to write an updateref overlay that supersedes the
> current updateref behavior.
Updateref processing should imo be kept out of any replication modules,
it is needed in databases where syncrepl isn't configured too. I'm
using it on my subordinate databases (with an artificial updatedn so
that slapd accepts it..) when syncrepl is configured on the superior
glue database without managing all of the subordinate databases. I.e,
the infamous test058...
I was having the same "chain only on some of the databases" requirement
and is using a patch that allows it. I consider this patch more of a
hack than a correct solution, which is why I haven't contributed it. A
separate updateref overlay apear to me as the best solution. But for
what it's worth, my patch is now in:
ftp://ftp.openldap.org/incoming/rein-ITS6531.patch
An advantage with this patch over a new overlay is that it should be
usable without any configuration changes (provided the chain overlay
have already been configured in the databases and found to not work as
expected there that is ... ;-).
Rein
13 years, 7 months
Re: (ITS#6531) Modify updateref to generate referrals on the backend
by masarati＠aero.polimi.it
[snip]
>> Although redesigning referral generation in slapd could streamline
>> things,
>> I don't quite see what issues can't be addressed using a global instance
>> of slapo-chain. You can configure referral chasing differently for
>> different domains using the chain-uri directive. I favor fixing only
>> what's actually broken.
>
> The request revolves around having different behavior for different
> databases.
> With a global slapo-chain you cannot turn off referral chasing; URIs that
> are
> not explicitly configured will still be chased.
>
> Also in terms of logical abstraction the current behavior is wrong; the
> frontend should of course generate the default_referral responses but
> updateref is a per-backend item and should be generated at the backend
> layer.
> Ideally this would all have been fixed to behave correctly by moving all
> replication support into an overlay, where it properly belongs. As an
> interim
> step it would be trivial to write an updateref overlay that supersedes the
> current updateref behavior.
As I said, I recognize the usefulness of such a change: I first moved
replication into an overlay (ITS#4261). I'm questioning its need for the
case at hand. Perhaps allowing slapo-chain to ignore some URIs would be
easier to implement, and generally useful in other applications.
In any case, I might spare some time to revitalize (ITS#4261), now that
slurpd is no longer around and thus things simplify significantly.
p.
13 years, 7 months
(ITS#6533) add rid to syncrepl config logs
by jonathan＠phillipoux.net
Full_Name: Jonathan Clarke
Version: RE24
OS:
URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-syncrepl-log-20100425.patch
Submission from: (NULL) (88.164.187.72)
Hi,
Currently, when a syncrepl statement is added, the following is output on log
level config:
Config: ** successfully added syncrepl "ldap://localhost:9011/"
In the case of setups replicating several databases from the same server
(multimaster with cn=config and a database for example), this leads to confusing
identical messages.
I attach a patch to add the RID to this line, like this:
Config: ** successfully added syncrepl "ldap://localhost:9011/" (rid=001)
Please consider this for inclusion.
Thanks,
Jonathan
13 years, 7 months
Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
>> Full_Name: Ryan Steele
>> Version: 2.4.18
>> OS: Ubuntu Server
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (207.106.239.81)
>>
>>
>> Per conversation on the #openldap IRC channel on Freenode with Howard Chu,
>> it
>> has been deemed appropriate to modify the behavior of updateref to answer
>> referrals on the backend. This would allow one to use updateref to
>> automatically chase referrals for individual backends, instead of it being
>> all
>> or nothing. Here is the tail end of the channel conversation:
>>
>>
>> <hyc> when you configure an updateref on a backend, that referral is only
>> generated in the frontend so putting the overlay on the database, misses
>> it...
>>
>> <rgsteele> Well, I am intending to set an updateref on that backend
>>
>> <hyc> then you have a problem
>>
>> <rgsteele> Hm, so you can't do automatic referrals on individual backends
>> then?
>>
>> <rgsteele> That was my original question, or at least the intent of it.
>>
>> <hyc> not using updateref, no
>>
>> <rgsteele> Does your response imply there's another way?
>>
>> <hyc> probably we should fix updateref to be generated at the backend
>> level
>>
>> <rgsteele> That would be good - I'd be happy to write tests or something
>> to help
>> with that.
>>
>> <hyc> the "other way" is the normal referral mechanism - using referral
>> entries
>> inside a database
>>
>> <hyc> but like I said, updateref is a relic, we've carried it forward
>> without
>> really adapting it
>>
>> <hyc> probably should file an ITS about this
>>
>> <rgsteele> Interesting, I wasn't aware of that method. I'll have to do
>> some
>> research on that - thanks! Also, is there anything I can do to help get
>> the
>> process of fixing updateref to generate referrals on the backend?
>>
>> <rgsteele> I can file the ITS if you like?
>>
>> <hyc> go ahead
>
> It is correct that referrals are generated by the frontend, but the
> frontend uses information contained in the updateref of each database.
> The slapo-chain needs to be global, in order to intercept those referrals.
>
> Although redesigning referral generation in slapd could streamline things,
> I don't quite see what issues can't be addressed using a global instance
> of slapo-chain. You can configure referral chasing differently for
> different domains using the chain-uri directive. I favor fixing only
> what's actually broken.
The request revolves around having different behavior for different databases.
With a global slapo-chain you cannot turn off referral chasing; URIs that are
not explicitly configured will still be chased.
Also in terms of logical abstraction the current behavior is wrong; the
frontend should of course generate the default_referral responses but
updateref is a per-backend item and should be generated at the backend layer.
Ideally this would all have been fixed to behave correctly by moving all
replication support into an overlay, where it properly belongs. As an interim
step it would be trivial to write an updateref overlay that supersedes the
current updateref behavior.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 7 months
Re: (ITS#6531) Modify updateref to generate referrals on the backend
by masarati＠aero.polimi.it
> Full_Name: Ryan Steele
> Version: 2.4.18
> OS: Ubuntu Server
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (207.106.239.81)
>
>
> Per conversation on the #openldap IRC channel on Freenode with Howard Chu,
> it
> has been deemed appropriate to modify the behavior of updateref to answer
> referrals on the backend. This would allow one to use updateref to
> automatically chase referrals for individual backends, instead of it being
> all
> or nothing. Here is the tail end of the channel conversation:
>
>
> <hyc> when you configure an updateref on a backend, that referral is only
> generated in the frontend so putting the overlay on the database, misses
> it...
>
> <rgsteele> Well, I am intending to set an updateref on that backend
>
> <hyc> then you have a problem
>
> <rgsteele> Hm, so you can't do automatic referrals on individual backends
> then?
>
> <rgsteele> That was my original question, or at least the intent of it.
>
> <hyc> not using updateref, no
>
> <rgsteele> Does your response imply there's another way?
>
> <hyc> probably we should fix updateref to be generated at the backend
> level
>
> <rgsteele> That would be good - I'd be happy to write tests or something
> to help
> with that.
>
> <hyc> the "other way" is the normal referral mechanism - using referral
> entries
> inside a database
>
> <hyc> but like I said, updateref is a relic, we've carried it forward
> without
> really adapting it
>
> <hyc> probably should file an ITS about this
>
> <rgsteele> Interesting, I wasn't aware of that method. I'll have to do
> some
> research on that - thanks! Also, is there anything I can do to help get
> the
> process of fixing updateref to generate referrals on the backend?
>
> <rgsteele> I can file the ITS if you like?
>
> <hyc> go ahead
It is correct that referrals are generated by the frontend, but the
frontend uses information contained in the updateref of each database.
The slapo-chain needs to be global, in order to intercept those referrals.
Although redesigning referral generation in slapd could streamline things,
I don't quite see what issues can't be addressed using a global instance
of slapo-chain. You can configure referral chasing differently for
different domains using the chain-uri directive. I favor fixing only
what's actually broken.
p.
13 years, 7 months
cn=monitor attributes (monitorOpInitiated for example) missing in cn=Subschema
by Cannady, Mike
I'm using openldap-stable-20100219.tgz build. When I look at cn=Monitor
with browsing tools (like Softerra LDAP browser) I do see entries for
monitorOpInitiated and monitorOpCompleted in DN
cn=Operations,cn=Monitor.
When I look at cn=SubSchema, I do not see any definitions of these two
attributes.
Using (unfortunately) Microsoft's VBScript, ADODB, and ADsDSOOBJECT to
access to access cn=Monitor, I can access everything that is defined in
the subschema (entryDN, modifyTimestamp, etc); however, I cannot access
MonitorOpInitiated and such. Looking at the logs, It looks like the
query never gets to the ldap server because MS checks it against the
cn=subschema.
I saw ITS#4947 and ITS#5576 which sounds like what my problem is
(attributes not published). Is there a fix for this and what would that
fix be?
My OS for the ldap server is Redhat Enterprise 5.4.
At the end of this email is my redacted slapd.conf file.
---Thanks
Mike Cannady
Information Services
Horry Telephone Cooperative (HTC)
Phone: (843)369-8212
Email: Mike.Cannady(a)htcinc.net
[root@vmLDAPdev2 openldap]# cat slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/HTC/iaaa-radius.schema
include /usr/local/etc/openldap/HTC/radius.schema
include /usr/local/etc/openldap/HTC/users.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
loglevel 0x100
#loglevel any
sizelimit unlimited
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
ServerID 002
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
access to *
by dn.one="ou=replicants,ou=admin,dc=htc,dc=com" read
by * break
access to dn.subtree="dc=htc,dc=com"
by dn.one="ou=admin,dc=htc,dc=com" manage
by self write
by anonymous auth
access to *
by self write
by users read
by anonymous auth
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=htc,dc=com"
rootdn "cn=Manager,dc=htc,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
rootpw {xxxxxxx}xxxxxxxxxxxxxxxxxxxxxxxxxx
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/var/openldap-data
cachesize 50000
dncachesize 50000
idlcachesize 150000
checkpoint 1024 5
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN eq
index entryUUID eq
# Replicas of this database
syncrepl rid=001
provider=ldap://vmldapdev1.htc.external:389
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=htc,dc=com"
attrs="*,+"
bindmethod=simple
binddn="uid=vmldapdev2,ou=replicants,ou=admin,dc=htc,dc=com"
credentials=atest2
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 1000 1
database monitor
[root@vmLDAPdev2 openldap]
**********************************************************************
HTC Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
**********************************************************************
13 years, 7 months
(ITS#6531) Modify updateref to generate referrals on the backend
by ryans＠aweber.com
Full_Name: Ryan Steele
Version: 2.4.18
OS: Ubuntu Server
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (207.106.239.81)
Per conversation on the #openldap IRC channel on Freenode with Howard Chu, it
has been deemed appropriate to modify the behavior of updateref to answer
referrals on the backend. This would allow one to use updateref to
automatically chase referrals for individual backends, instead of it being all
or nothing. Here is the tail end of the channel conversation:
<hyc> when you configure an updateref on a backend, that referral is only
generated in the frontend so putting the overlay on the database, misses it...
<rgsteele> Well, I am intending to set an updateref on that backend
<hyc> then you have a problem
<rgsteele> Hm, so you can't do automatic referrals on individual backends then?
<rgsteele> That was my original question, or at least the intent of it.
<hyc> not using updateref, no
<rgsteele> Does your response imply there's another way?
<hyc> probably we should fix updateref to be generated at the backend level
<rgsteele> That would be good - I'd be happy to write tests or something to help
with that.
<hyc> the "other way" is the normal referral mechanism - using referral entries
inside a database
<hyc> but like I said, updateref is a relic, we've carried it forward without
really adapting it
<hyc> probably should file an ITS about this
<rgsteele> Interesting, I wasn't aware of that method. I'll have to do some
research on that - thanks! Also, is there anything I can do to help get the
process of fixing updateref to generate referrals on the backend?
<rgsteele> I can file the ITS if you like?
<hyc> go ahead
13 years, 7 months
