[EMAIL PROTECTED] wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files:
dyngroup.c 1.13 - 1.14
Log Message:
Add cn=config support
I thought this was going to be replaced by dynlist, whose functionality
it provides a subset. Note that in HEAD dynlist can
Buchan Milne writes:
I need the patch below (since 2.3.37, maybe before) to be able to compile
backglue.c on gcc 2.9x.
(...)
- int rc;
BackendDB *b0 = op-o_bd;
op-o_bd = glue_back_select( b0, dn );
+ int rc;
That breaks on C90 compilers. Declaration after
Buchan Milne wrote:
I need the patch below (since 2.3.37, maybe before) to be able to compile
backglue.c on gcc 2.9x.
Regards,
Buchan
--- servers/slapd/backglue.cThu Aug 23 14:48:24 2007
+++ servers/slapd/backglue.c.latedeclarationThu Aug 23 14:44:22 2007
@@ -619,9 +619,9 @@
Pierangelo Masarati writes:
I guess you need the reverse: the declaration of rc is incorrectly
placed after the invocation of glue_back_select() in current 2.3 code.
Ooh. I looked at HEAD:-)
--
Hallvard
Pierangelo Masarati wrote:
[EMAIL PROTECTED] wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files:
dyngroup.c 1.13 - 1.14
Log Message:
Add cn=config support
I thought this was going to be replaced by dynlist, whose functionality
it provides a subset.
Howard Chu wrote:
I thought this was going to be replaced by dynlist, whose
functionality it provides a subset. Note that in HEAD dynlist can
also be instantiated under the name dyngroup (see obsolete names),
with the same configuration syntax.
Hm, the last I remember we had agreed that
Pierangelo Masarati wrote:
Howard Chu wrote:
I thought this was going to be replaced by dynlist, whose
functionality it provides a subset. Note that in HEAD dynlist can
also be instantiated under the name dyngroup (see obsolete names),
with the same configuration syntax.
Hm, the last I
Howard Chu wrote:
I just went back and re-read ITS#3756. If dyngroup functionality is
working fine in dynlist now, then we should just cvs rm dyngroup and
drop it from 2.4.
I'll check.
In the meantime, I need to add support for dgIdentity to something. At
this point I guess that means I'll
Howard Chu wrote:
A dgPolicy flag could determine what behavior, in case of no compliance
with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the
group entry, that ought to be sufficient.
I disagree: by running an
Pierangelo Masarati wrote:
Howard Chu wrote:
A dgPolicy flag could determine what behavior, in case of no compliance
with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the
group entry, that ought to be sufficient.
I
Russ Allbery wrote:
So, that behavior of letting the dynlist or dyngroup overlay do a query
that the user querying the group tree is not themselves permitted to make
is exactly what we need, since we can then use the more granular access
control possible on the separate group dns to implement
Howard Chu wrote:
Pierangelo Masarati wrote:
Howard Chu wrote:
A dgPolicy flag could determine what behavior, in case of no compliance
with policy, should be taken: either (a) or (b), or none.
dgAuthz seems like overkill. If the user has read/search privs on the
group entry, that ought to be
Gavin Henry wrote:
Dear All,
I know Howard wrote this:
http://www.openldap.org/lists/openldap-software/200702/msg00277.html
But I'd like to gather a quick (if possible) list of 2.3 vs 2.4
features/differences/additions, so I can make sure we have a relevant
section in the Admin Guide
13 matches
Mail list logo
