000Z)
As the comments seems to comes from the RFC directly, I'd rather trust
the man page, but i've been unsucessful with both...
If it matters, i'm using openldap-servers-2.3.27 on mandriva linux 2007.0.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Andreas Hasenack a écrit :
> Em Qua, 2007-09-26 às 17:12 +0200, Guillaume Rousse escreveu:
>> So, I set up a very minimal default password policy object, as it seems
>> to be quite mandatory:
>> dn: cn=default,ou=policies,dc=futurs,dc=inria,dc=fr
>> cn: defaul
t periodically through cron.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
ynchronisation, if I need to fallback on a
safer mode ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Guillaume Rousse a écrit :
> Hello.
>
> I'm trying to follow change propagations errors using delta-synrepl in
> search & persist mode, by using an accesslog overlay both on master and
> on slaves.
About the error themselves, I clearly see changes commited in the master
(v
Quanah Gibson-Mount a écrit :
> --On Friday, October 05, 2007 4:20 PM +0200 Guillaume Rousse
> <[EMAIL PROTECTED]> wrote:
>
>> Guillaume Rousse a écrit :
>>> Hello.
>>>
>>> I'm trying to follow change propagations errors using delta-synrep
modificating operational attributes
at the same time than normal attributes should fail, or is it a bug ?
openldap version is 2.3.27.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
FRLinux a écrit :
> On 10/9/07, Guillaume Rousse <[EMAIL PROTECTED]> wrote:
>> So, it is an expected behaviour than modificating operational attributes
>> at the same time than normal attributes should fail, or is it a bug ?
>
> Hello,
>
> Don't think this
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
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 u
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 reduc
t'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.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
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 m
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
>&
ive solution (see my questions about repo-dyngroup), that didn't
involved recompilation, and finally implemented it outside ldap (we
already have external content synchronisation from outside sources).
I'll try to give a look at this extension later, tough.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
namic
group I think.
So, does anyone have suggestion on how to handle this better ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
some kind of server-side query rewriting, as
mod_rewrite does for apache ? I initially thought of setting up a
dynamic group, but this would create a single entry with multiple mail
attribute, whereas the copier expect a list of entries with single mail
attribute (didn't tested it tough).
--
sgusting, but it'd probably work.
Bind dn option failed because printer doesn't allow to install ca
certificates, nor to do ssl/tls without checking server certificates,
and autentication is only permitted through encrypted connection, so I
had to rely on copier IP.
Thanks !
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
N="var/run/ldap/ldapi" into a domain
-> NOK
[EMAIL PROTECTED] rousse]# ldapsearch -H
'ldapi://%2fvar%2frun%2fldap%2fldapi'
-> OK
is this intentional ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
#x27;t find any
description of this option.
Is this possible smbk5pwd author would have by mistake used a private
function, only working because he build heimdal on a host whose linker
doesn't support --version-script option ?
I'm using heimdal 1.1 and openldap 2.4.8 on mandriva linux.
-
Love Hörnquist Åstrand a écrit :
26 maj 2008 kl. 08.27 skrev Guillaume Rousse:
Hello list(s).
I'm having a crash as soon as I attempt to change my password when
smbk5pwd is activating. strace shows an unresolved symbol in
smbk5pwd.so: _kadm5_free_keys
Heimdal source code shows
Love Hörnquist Åstrand a écrit :
27 maj 2008 kl. 02.18 skrev Guillaume Rousse:
I tried this approach (patch attached).
Converting _kadm5_free_keys to hdb_free_keys is trivial, as the former
is just a wrapper over the second.
However, converting _kadm5_set_keys to
35 about
this issue.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Howard Chu a écrit :
Guillaume Rousse wrote:
Love Hörnquist Åstrand a écrit :
27 maj 2008 kl. 02.18 skrev Guillaume Rousse:
I tried this approach (patch attached).
Converting _kadm5_free_keys to hdb_free_keys is trivial, as the former
is just a wrapper over the second.
However, converting
Love Hörnquist Åstrand a écrit :
28 maj 2008 kl. 02.57 skrev Guillaume Rousse:
+hdb_entry_set_pw_change_time(context, &ent, 0);
+
+if (krb5_config_get_bool_default(context, NULL, FALSE,
+"kadmin", "save-password", NULL)) {
+ret
by * read
access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*)
by * none
map attribute telephoneNumber homePhone
map attribute telephoneNumber
Any hint welcome, either on the solution choice, or on the selected
solution troubles.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Pierangelo Masarati a écrit :
- "Aaron Richton" <[EMAIL PROTECTED]> wrote:
On Fri, 25 Jul 2008, Guillaume Rousse wrote:
First, using a distinct database doesn't allow to provide a virtual
view
from a branch in my original database to another branch in the same
ou need.
Meaning mapping homePhone to telephoneNumber, and hidding real
telephoneNumber, right. But it doesn't mask other attributes, so I guess
there is still an issue for not being able to preserve objectClass
attribute when masking all other ones. Am I correct ?
--
Guillaume Rousse
Moyens
Hello.
I successfully setup the chain overlay, so as to push changes from a
slave to a master, with something as:
overlay chain
chain-uri "ldap://ldap1.domain.tld";
chain-idassert-bind bindmethod="simple"
binddn="cn=chain,ou=roles,dc=domain,dc=tld"
Pierangelo Masarati a écrit :
Guillaume Rousse wrote:
Hello.
I successfully setup the chain overlay, so as to push changes from a
slave to a master, with something as:
overlay chain
chain-uri "ldap://ldap1.domain.tld";
chain-idassert-bind bindmeth
massage ou=users,dc=msr-inria,dc=inria,dc=fr
rwm-map attribute telephoneNumber homePhone
rwm-map attribute telephoneNumber
databasebdb
suffix "dc=msr-inria,dc=inria,dc=fr"
rootdn "cn=root,dc=msr-inria,dc=inria,dc=fr"
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Howard Chu a écrit :
Pierangelo Masarati wrote:
Guillaume Rousse wrote:
> Hello.
>
> I successfully setup the chain overlay, so as to push changes from a
> slave to a master, with something as:
> overlay chain
> chain-uri "ldap://ldap1.domain.
e way supported controls are
exposed. Please file an ITS.
Done, that's ITS #5724
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
syncdata=accesslog
searchbase="dc=msr-inria,dc=inria,dc=fr"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr"
credentials=X
Any hint welcome.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Quanah Gibson-Mount a écrit :
--On Tuesday, October 07, 2008 6:06 PM +0200 Guillaume Rousse
<[EMAIL PROTECTED]> wrote:
Hello list.
I'm facing a syncrepl issue really strange. Sofar, everytime I had sync
issue, I just had to stop the consumer, delete its database, and restart
it ag
dmins
access to dn.subtree="dc=msr-inria,dc=inria,dc=fr"
by group="cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr" write
by * break
This worked with a static group, it doesn't work anymore with a dynamic
one as I just presented.
I'm using OpenLDAP 2.4.11. Shou
te
by * read
your syncrepl ID doesn't need write access, and if you store password in
your directory, they are fully exposed...
None of the above answer your problem, tough.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Quanah Gibson-Mount a écrit :
--On Tuesday, October 07, 2008 6:06 PM +0200 Guillaume Rousse
<[EMAIL PROTECTED]> wrote:
Hello list.
I'm facing a syncrepl issue really strange. Sofar, everytime I had sync
issue, I just had to stop the consumer, delete its database, and restart
it ag
ackup were successful.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
seems to either
imply an openldap or a packaging issue. Should I report an ITS for this,
or rather provide more informations ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Aaron Richton a écrit :
Assuming you're still seeing this in 2.4.12/HEAD, I'd suggest an ITS for
discussion/tracking...
OK, that's ITS 5745
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Quanah Gibson-Mount a écrit :
--On Friday, October 17, 2008 4:22 PM +0200 Guillaume Rousse
<[EMAIL PROTECTED]> wrote:
Since I upgraded one of my server from 2.4.11 to 2.4.12, I'm facing heavy
database issues:
[EMAIL PROTECTED] ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr
...
bdb(dc=m
e) get redirected to
kerberos password for autentication, whereas only our users have
principals currently.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
uot;dc=msr-inria,dc=inria,dc=fr"
by
group/groupOfURLs/memberURL="cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr"
write
by * break
(please excuse any unintended line wrapping).
Indeed, many thanks.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password
storage scheme, I understand autentication can be delegated to an
external mechanisme. Such as, for instance, a kerberos server. In this
case, it is advised to
Guillaume Rousse a écrit :
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL password
storage scheme, I understand autentication can be delegated to an
external mechanisme. Such as, for instance, a kerberos server. In this
Howard Chu a écrit :
Guillaume Rousse wrote:
Guillaume Rousse a écrit :
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
Reading http://www.openldap.org/doc/admin24/security.html#SASL
password
storage scheme, I understand autentication can be delegated to an
external mechanisme
uldn't find
anything related to the topic. So, what's the proper way for doing this ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Philip Guenther a écrit :
On Tue, 2 Dec 2008, Guillaume Rousse wrote:
The code manipulates an opaque LDAP *ld connection handle. I had a quick
look at openldap code, in libraries/libldap/tls.c, to see how this
handle could be used to access the x509 certificate:
LDAPConn *conn = NULL
Guillaume Rousse a écrit :
And gdb shows it waiting in __kernel_vsyscall
(gdb) bt
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7d385c6 in pthread_join () from /lib/i686/libpthread.so.0
#2 0xb7f23d3f in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2
#3 0x0806e1b4 in slapd_daemon
yncrepl purpose.
I'm using openldap 2.4.13, with db 4.6.21, on mandriva linux 2008.1, 32
bits system. I'd be happy to provide additional informations if needed.
--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62
Quanah Gibson-Mount a écrit :
--On Friday, January 23, 2009 2:50 PM +0100 Guillaume Rousse
wrote:
Guillaume Rousse a écrit :
And gdb shows it waiting in __kernel_vsyscall
(gdb) bt
# 0 0xe410 in __kernel_vsyscall ()
# 1 0xb7d385c6 in pthread_join () from /lib/i686/libpthread.so.0
# 2
Quanah Gibson-Mount a écrit :
--On Friday, January 23, 2009 11:24 AM +0100 Guillaume Rousse
wrote:
Hello list.
Since a recent upgrade 2.4.12 -> 2.4.13, I'm facing recurrent slapd
hanging.
(a) build with debugging symbols (CFLAGS=-g)
It is, actually, I just forgot to install the
Hello.
I'm facing heavy ldap locking again, even after upgrading bdb 4.6 to
latest patch level (4.6.21.3). When the problem occurs, any ldap query
fails with this result:
[r...@etoile main]# ldapsearch -x
ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)'
failed.
Aband
rityObject
cn: chain
description: slave server proxy user
authzTo: dn:*
--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62
a way to first lock password server-side, the same
way pwdAccountLockedTime does, but with a fixed date, AND have a boolean
flag valid/invalid for easy selection of valid account in queries.
--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université,
Rahima Shaheen a écrit :
[..]
It gives an error “Invalid syntax (21) pwdAttribute: value #0 invalid
per syntax. Why it gives such error? My assumption is ppolicy.schema
attribute is not created successfully. Another point in core.schema
attributeType; userPassword is comment out. If I uncommen
rchbase="dc=msr-inria,dc=inria,dc=fr"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr"
credentials=XX
--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
I'm using delta-syncrepl in search-and-persist mode between my slaves
and my master server. And I'm using a nagios plugin to check sync
status, based on value of contextCSN attribute. But I'm often sync
alerts for unknown
Hello list.
Is there any way to perform a persistent query with ldapsearch, the same
way syncrepl refreshAndPersist does ? And if not, would an ITS for it
being accepted ? It would be very useful for following changes in logs
managed by slapo-accesslog.
--
BOFH excuse #379:
We've picked COBO
This server is frozen, and ldapsearch crashes:
[r...@etoile main]# ldapsearch -x
ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)'
failed.
Abandon
This is openldap 2.4.15 client, with this specific configuration:
TLS_CACERTDIR /etc/pki/tls/rootcerts
TLS_REQCERT dem
Howard Chu a écrit :
Guillaume Rousse wrote:
This server is frozen, and ldapsearch crashes:
[r...@etoile main]# ldapsearch -x
ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)'
failed.
Abandon
This is openldap 2.4.15 client, with this specific configur
Michael Ströder a écrit :
Guillaume Rousse wrote:
As 2.4.17 and 2.4.16 changelog doesn't show anything related, I guess
the pb is still there.
Please do not guess. You should test.
Unfortunatly, I have no way to reproduce the problem, and I couldn't
afford to let the ldap serve
Howard Chu a écrit :
Not sure what's the point of your email. Whatever 2.4.15 did is
uninteresting since it no longer occurs in 2.4.17. Your packet trace
shows a few TCP retries, so the remote server's network stack is not
responding, and you already said "this server is frozen." Naturally the
Hello list.
I successfuly configured OpenLDAP for kerberos autentication, and user
mapping:
authz-regexp "uid=([^,]+),cn=gssapi,cn=auth"
"ldap:///ou=users,dc=futurs,dc=inria,dc=fr??sub?(uid=$1)"
However, mapping doesn't work when autenticating with a user from a
different realm than the o
Le 11/01/2010 18:08, Gavin Henry a écrit :
So, let's say I'm crazy and I want to investigate putting ldap servers
on VMware Guests --- do I care about any of the directions in section
21.1.2 about separating the logs and the db or not?
Yes, that still applies for best performance.
I may be w
Hello list.
I had a look at section 18 of the admin manual, as I was trying to
figure difference between scenarios 18.2.2 (N-way multi-master) and
18.2.3 (mirror mode). Whereas the descriptions of both scenarios are
quite clear, given examples configuration are quite confusing (at least
for m
Hello list.
I'm trying to achieve multi-master setup, starting from a working
single-master setup. I took the master node configuration, added the
following directives, and distributed it identically on two nodes:
# global
serverID 1 ldap://10.202.11.8:389/
serverID 2 ldap://10.202.11.9:389
Le 13/01/2010 11:31, Guillaume Rousse a écrit :
It's hard to tell if the failure occurs on the provider (ber write
failed message) or consumer side (null_callback : error code 0x13).
I finally found the issue: a constraint violation preventing to use an
unknown gidNumber for any
Hello list.
That's not really an openldap issue, but I guess its developper knows
openssl behaviour better then myself: how could a simple
distribution-provided update of root certificates affect the way
openldap uses my own root certificate ?
Before the update, the root certificate is corre
Hello.
I'm trying to find the best way to conduct a consequent change in our
data model and servers topology, with the fewer service disturbing.
Before the reorganisation, we were a single entity, splitted on three
different sites. As a consequence, we had a single database for all our
users
Le 29/03/2010 10:26, Wolf-Agathon Schaly a écrit :
> If I leave the LDAP server listening on the TCP address of localhost
> (127.0.0.1) declips is cool.
> If I change the entry in /etc/openldap/ldap.conf from
> URI=ldap://127.0.0.1/
> to
> URI=ldap://10.1.1.1/
> I'm facing the same issue (g
Le 12/04/2010 19:14, Matt Ingram a écrit :
Hi All.
We're trying to implement acls that will allow our Admins to modify the
LDAP directory without using a generic admin account, and using their
own credentials within LDAP. Our requirement is that the Admins can
modify the mail, uid and userPasswo
Hello.
I'm having troubles with replication using sync-repl.
I first configured my provider and consumer servers as explained on
http://www.openldap.org/doc/admin22/syncrepl.html.
Additional directives for the provider:
# replication management
sessionlog 001 500
Additional directives for
Quanah Gibson-Mount wrote:
>
>
> --On Wednesday, April 12, 2006 3:42 PM +0200 Guillaume Rousse
> <[EMAIL PROTECTED]> wrote:
>
>> Hello.
>>
>> I'm having troubles with replication using sync-repl.
>>
>> I first configured
75 matches
Mail list logo
