gdsroka(a)hotmail.com wrote:
> Full_Name: Gabriel Sroka
> Version: 2.4.9
> OS: Ubuntu
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (130.150.113.161)
>
>
> ldapsearch and other tools include a -C (uppercase) option to enable referral
> chasing, but the option doesn't show up in the tool_common_usage() nor on the
> man pages
This is intentional. This ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Gabriel Sroka
Version: 2.4.9
OS: Ubuntu
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.150.113.161)
ldapsearch and other tools include a -C (uppercase) option to enable referral
chasing, but the option doesn't show up in the tool_common_usage() nor on the
man pages
Full_Name: Kostantinos Koukopoulos
Version: 2.4.11
OS: Solaris 9
URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch
Submission from: (NULL) (195.134.100.30)
When using the translucent overlay, if one tries to use set syntax in an ACL or
ACI rule, in order to dereference the bound user, like in the example below,
then the user's entry is fetched from the local database only.
Example <who> clause:
by set="user/eduPersonOrgUnitDN & [ou=someunit,dc=someorg,dc=somecountry]"
If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found
in the local database. I believe it would be better if the remote database was
also checked, like when a search operation is performed against the overlay.
I found the problem was due to that acl_set_gather2 tries to fetch the attribute
directly from the backend, but the translucent overlay does not support this, so
the backend is used instead. I've attached a patch which makes acl_set_gather
always use an internal search operation to fetch the attribute, instead of
calling acl_set_gather2.
I've also tried to hack the translucent overlay so that it would support the
bi_entry_get_rw callback but I haven't been able to provide something that would
even satisfy me. I suppose I would have to use some sort of callback mechanism
like translucent_search_cb but I haven't figured it out yet.
Full_Name: Kostantinos Koukopoulos
Version: 2.4.10
OS: Solaris 9
URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723.patch
Submission from: (NULL) (195.134.100.30)
It seems that while set syntax in ACIs is supported by aci_mask, it's impossible
to add a ACI value with set syntax. Debugging the problem I've found that in
OpenLDAPaciPrettyNormal, the subject part of the ACI value is stripped when the
type is 'set'. The included patch seems to correct the problem for me.
Full_Name: Gavin Henry
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.159.59.85)
Submitted by: ghenry
Just an ITS for syncing the online guide with what's in 2.4.11
Thanks.
Full_Name: Andrew Bartlett
Version: CVS HEAD
OS: Fedora 9
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (59.167.251.137)
>From thread on opendlap-technical:
> Hmm, I have the module loaded globally - perhaps I need a global rootdn
> of some kind defined?
>
> I have one per-database (now), but the documentation strongly encourages
> one not to have a rootdn at all.
The fix was to define rootdn globally (as the module operates globally),
and then to give it explicit manage access in an ACL. eg
access to dn.subtree="${DOMAINDN}"
by dn=cn=samba-admin,cn=samba manage
by dn=cn=manager manage
by * none
rootdn cn=Manager
Adding a rootdn to each database then quashed the warnings about 'rootdn
can always manage'.
Otherwise, if I had 'by * read' then this also allowed the module to operate
correctly (but without the secrecy I desired)
jclarke(a)linagora.org wrote:
> Full_Name: Jonathan Clarke
> Version:
> OS:
> URL: http://milopita.phillipoux.net/jonathan-clarke-20080716.patch
> Submission from: (NULL) (213.41.243.192)
>
>
> Hi,
>
> Reading through the admin guide (checked out via CVS), I have come across a few
> typos and inconsistencies (missing words, chapter references, etc). The patch at
> the URL below includes some very simple corrections for these.
>
> Regards,
> Jonathan
>
>
OK, thanks. I'll take a look. Sorry it's taken a week, I've been away.
Gavin.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/