Thank you !
>> Remove the commend.
That's was a key of my problem.
Thank you very much.
21.09.09, 18:34, "Jonathan Clarke" :
>
> > syncrepl rid=<>
> > provider=ldap://server:389
> > type=refreshOnly
> > interval=00:00:05:00
> > searchbase="dc=company,dc=com"
> > filter="(objectClass=
On 09/20/2009 03:31 PM, Evgeniy wrote:
Hello.
Openldap 2.4.18, master-slave replication .
Slave server successfully replicates all data, except hashed {sha} passwords.
It is not problem with "access to attrs=userPassword " - I test ithis.
How I can solve it and sync passwords ?
[ slapd.conf
On 09/20/2009 03:31 PM, Evgeniy wrote:
Hello.
Openldap 2.4.18, master-slave replication .
Slave server successfully replicates all data, except hashed {sha} passwords.
It is not problem with "access to attrs=userPassword " - I test ithis.
How I can solve it and sync passwords ?
[ slapd.conf
On Mon, 21 Sep 2009, Evgeniy wrote:
Openldap 2.4.18, master-slave replication .
Slave server successfully replicates all data, except hashed {sha} passwords.
It is not problem with "access to attrs=userPassword " - I test ithis.
[...]
attrs="*"
syncrepl needs operational attributes, but those
Hello.
Openldap 2.4.18, master-slave replication .
Slave server successfully replicates all data, except hashed {sha} passwords.
It is not problem with "access to attrs=userPassword " - I test ithis.
How I can solve it and sync passwords ?
[ slapd.conf ]
master server:
#
index object
Howard Chu wrote:
It's difficult to tell from the sloppy formatting of your email, but
most likely you have white space in your slave's slapd.conf where it
does not belong, and are missing white space where it does belong.
Please read the slapd.conf(5) manpage again and pay attention to the
r
Did you add cn=Replicator,dc=nc,dc=com to your replica before trying
to do this?
Also, you might want to specify 'dn.exact="cn=Replicator,dc=nc,dc=com"
write' instead of just "cn=Replicator,dc=nc,dc=com" write in your
replica's ACL.
The slave ACLs are in the wrong order, so there is no way
It's difficult to tell from the sloppy formatting of your email, but
most likely you have white space in your slave's slapd.conf where it
does not belong, and are missing white space where it does belong.
Please read the slapd.conf(5) manpage again and pay attention to the
rules for white space
matthew sporleder wrote:
On 5/31/06, Sandeep A.S <[EMAIL PROTECTED]> wrote:
access to attrs=userPassword
by self write
by * auth
access to *
by self write
by * read
replica uri=ldap://192.168.128.248:
suffix="dc=nc,dc=com"
bind
On 5/31/06, Sandeep A.S <[EMAIL PROTECTED]> wrote:
access to attrs=userPassword
by self write
by * auth
access to *
by self write
by * read
replica uri=ldap://192.168.128.248:
suffix="dc=nc,dc=com"
binddn="cn=Replicator,dc=nc,dc
> binddn="cn=Replicator,dc=nc,dc=com"
> bindmethod=simple credentials=secret
[...]
> Error: ldap_simple_bind_s for 192.168.128.248: failed: Invalid
> credentials
Perhaps you need to add an entry "cn=Replicator,dc=nc,dc=com" with a
userPassword of "secret" (or a
Hi I am facing problem with replication:
I am using the version openldap-2-3-24
My relevent Master config is :
access to attrs=userPassword
by self write
by * auth
access to *
by self write
by * read
replica uri=ldap://192.168.128.248:
> replica uri=ldap://192.168.0.2:389
[...]
> replica uri=ldap://192.168.0.2:389
It's been quite a while since I've used slurpd, but I recall the uri (or
possibly just the hostname, like I said, it's been a while) was a primary
key for it. So in your config only one replica would run. I ended up
wo
--On Wednesday, April 26, 2006 8:41 PM -0300 Daniel Kobayashi Imori
<[EMAIL PROTECTED]> wrote:
Hi,
Can someone help me?
I have to configure many databases running in one openldap with
replication... But when I do that, only the replication of first
database worked...
1) I suggest you re
Hi,
Can someone help me?
I have to configure many databases running in one openldap with
replication... But when I do that, only the replication of first
database worked...
The master slapd.conf part:
---
database bdb
suffix "dc=db1"
rootdn "cn=Manager,dc=db1"
rootpw {SSHA}k6aHDkx/Q3aVNeL5WXVaf
I am having a problem with replication: On my master server the update
occurs but when slurpd passes the changes / modification the slave
responds in the log that no user modification is allowed.
-- Snip
Oct 12 12:22:14 anuket slapd[8094]: conn=5 fd=8 ACCEPT from IP=[IP
Removed]:32803 (IP=0.0.0.0
--On Tuesday, September 13, 2005 2:31 PM -0700 Johan A <[EMAIL PROTECTED]>
wrote:
Thanks, I wasn't aware that slapadd did indexing.
The error in .rej seems always to be
ERROR: Insufficient access
which I can't see makes much sense. The Replicator can
add new entries to the slave and hence se
Thanks, I wasn't aware that slapadd did indexing.
The error in .rej seems always to be
ERROR: Insufficient access
which I can't see makes much sense. The Replicator can
add new entries to the slave and hence seem to be able
to write to it. And this setup is using the same
access controls as the fi
--On Monday, September 12, 2005 11:55 PM -0700 Johan A <[EMAIL PROTECTED]>
wrote:
Hi,
I had 2 machines with a working OpenLDAP master/slave
setup. But due to harddisk crash I wanted to move this
to 2 new machines.
To do this I copied the both slapd.conf and edited the
"replica" section with
Hi,
I had 2 machines with a working OpenLDAP master/slave
setup. But due to harddisk crash I wanted to move this
to 2 new machines.
To do this I copied the both slapd.conf and edited the
"replica" section with the new hostnames. I also shut
down the old LDAP master and dumped it to an LDIF file
w
20 matches
Mail list logo
