Guillaume Rousse wrote:
> Pierangelo Masarati a écrit :
>> Your solution to the problem consists in sitting by the river until
>> anyone makes it compile straightforwardly and writes a man page.
> No, my solution consisted to evaluate different strategies, taking into
> account their initial cost f
Pierangelo Masarati a écrit :
> Your solution to the problem consists in sitting by the river until
> anyone makes it compile straightforwardly and writes a man page.
No, my solution consisted to evaluate different strategies, taking into
account their initial cost for testing, and their subsequent
Here, here.
Hear, hear! ;-)
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E [EMAIL PROTECTED]
Community developed LDAP software.
http://www.openldap.org/project/
Pierangelo Masarati wrote:
Guillaume Rousse wrote:
I'm not judging code quality (I have absolutly no clue), I'm judging
ease of deployment, and ease of maintainance, both for myself and the
rest of my colleagues.
OK, let me try to re-state it in yet another manner. It seems that what
you exa
Guillaume Rousse wrote:
> I'm not judging code quality (I have absolutly no clue), I'm judging
> ease of deployment, and ease of maintainance, both for myself and the
> rest of my colleagues.
OK, let me try to re-state it in yet another manner. It seems that what
you exactly need is collective a
Pierangelo Masarati a écrit :
> Guillaume Rousse wrote:
>> Gavin Henry a écrit :
>
>>> collect.c is just a demonstration of overlay code for developers, hence
>>> no docs.
>> That's what I understood also, hence my lack of motivation to consider
>> it as a viable implementation of collective attri
Pierangelo Masarati wrote:
Guillaume Rousse wrote:
Gavin Henry a écrit :
collect.c is just a demonstration of overlay code for developers, hence
no docs.
That's what I understood also, hence my lack of motivation to consider
it as a viable implementation of collective attributes for openldap
Guillaume Rousse wrote:
> Gavin Henry a écrit :
>> collect.c is just a demonstration of overlay code for developers, hence
>> no docs.
> That's what I understood also, hence my lack of motivation to consider
> it as a viable implementation of collective attributes for openldap 2.3
> currently.
Al
Guillaume Rousse a écrit :
> I've had a quick look at slapo-dynlist man page, it seems it could
> achieve it using 'see-also' attribute to refer to the group dn, and
> probably an additional schema to add 'secretary' and 'manager'
> attributes to my group entries (posixGroup + groupOfNames).
My fir
Gavin Henry a écrit :
>>> and a
>>> grep -i -r collective on the source code supplies lots of matches.
>> This doesn't really constitute documentation...
>>
>
> collect.c is just a demonstration of overlay code for developers, hence
> no docs.
That's what I understood also, hence my lack of motiva
Guillaume Rousse wrote:
Dieter Kluenter a écrit :
Guillaume Rousse <[EMAIL PROTECTED]> writes:
Dieter Kluenter a écrit :
Guillaume Rousse <[EMAIL PROTECTED]> writes:
Hello list.
I'm looking for a way to reduce information duplication in an LDAP
directory, using the equivalence of joint in
Dieter Kluenter a écrit :
> Guillaume Rousse <[EMAIL PROTECTED]> writes:
>
>> Dieter Kluenter a écrit :
>>> Guillaume Rousse <[EMAIL PROTECTED]> writes:
>>>
Hello list.
I'm looking for a way to reduce information duplication in an LDAP
directory, using the equivalence of joint
Guillaume Rousse <[EMAIL PROTECTED]> writes:
> Dieter Kluenter a écrit :
>> Guillaume Rousse <[EMAIL PROTECTED]> writes:
>>
>>> Hello list.
>>>
>>> I'm looking for a way to reduce information duplication in an LDAP
>>> directory, using the equivalence of joint in SQL databases. Basically,
>>> all
Dieter Kluenter a écrit :
> Guillaume Rousse <[EMAIL PROTECTED]> writes:
>
>> Hello list.
>>
>> I'm looking for a way to reduce information duplication in an LDAP
>> directory, using the equivalence of joint in SQL databases. Basically,
>> all my user entries (inetorgperson + posixAccount) need to
Guillaume Rousse <[EMAIL PROTECTED]> writes:
> Hello list.
>
> I'm looking for a way to reduce information duplication in an LDAP
> directory, using the equivalence of joint in SQL databases. Basically,
> all my user entries (inetorgperson + posixAccount) need to have a
> 'secretary' and a 'manage
Hello list.
I'm looking for a way to reduce information duplication in an LDAP
directory, using the equivalence of joint in SQL databases. Basically,
all my user entries (inetorgperson + posixAccount) need to have a
'secretary' and a 'manager' field, but given than all users from the
same gro
16 matches
Mail list logo
