Quanah Gibson-Mount wrote:
>
> Wouldn't it be simpler to define ACLs on the master that limit what
> the replication identity has access to that matches your filters?
>
emm ... I was sure I can not do that on the master side ... just I try
do that, I receive full data ...
Quanah Gibson-Mount wrote:
> --On Friday, June 30, 2017 12:48 AM +0300 Zeus Panchenko
> wrote:
> ...
> > 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 (53) Server is unwilling
> > to perform Jun 29 22:45:30 ABC slapd[12593]: do_syncrepl: rid=000 rc -2
> >
--On Tuesday, June 27, 2017 2:04 AM -2100 Zeus Panchenko
wrote:
syncrepl rid=123
provider=ldap://master.example:389
starttls=critical
searchbase="ou=ABC,ou=Sendmail,dc=example"
bindmethod=simple
binddn="uid=replABC,ou=repl,dc=example"
credentials="***"
Actually, let me expand that question. I need to make changes to
everything in cn=config after switching to dynamic configuration. Is it
possible to do that without starting from scratch with a new slapd.conf
file. I deleted the slapd.conf I was working with because I didn't need
it anymore,
Thanks. One more related question: are special rules needed for the
config information, like an ACL just for cn=config so the ldapadmins can
make changes w/o needing a rootDN?
On 06/29/2017 06:11 PM, Quanah Gibson-Mount wrote:
--On Thursday, June 29, 2017 7:08 PM -0400 Prentice Bisbal
Andrew Findlay wrote:
>
> Try fixing the RIDs - use small numbers, all different. The exact values are
> not important.
> Also try commenting out the second syncrepl clause until you have the others
> working properly.
> You should be able to merge the first
--On Thursday, June 29, 2017 7:08 PM -0400 Prentice Bisbal
wrote:
Actually, let me expand that question. I need to make changes to
everything in cn=config after switching to dynamic configuration. Is it
possible to do that without starting from scratch with a new slapd.conf
--On Thursday, June 29, 2017 7:27 PM -0400 Prentice Bisbal
wrote:
Thanks. One more related question: are special rules needed for the
config information, like an ACL just for cn=config so the ldapadmins can
make changes w/o needing a rootDN?
You can certainly add an
--On Friday, June 30, 2017 12:48 AM +0300 Zeus Panchenko
wrote:
---[ slave slapd.log quotation start ]
Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000
LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 29
22:45:30 ABC
I got myself into a bit a of a Catch-22. I need to change the RootDN,
but I don't have permission to. How does one change the root DN using
dynamic configuration?
Prentice
--On Thursday, June 29, 2017 2:12 AM -0400 btb wrote:
i see, thanks. i tested this, and did a modify on each, but didn't see
replication resume. emulating the syncrepl connection with a manual
search against each master, there do seem to be accesslog entries now, on
both
[ This is a very old thread you are resurrecting! ]
On Fri, Sep 09, 2016 at 01:51:47PM +0300, Zeus Panchenko wrote:
> I have two posixGroup groups
>
> cn=admins,ou=group,dc=foo
> cn=coadmins,ou=group,dc=foo
>
> my users resides in ou=People,dc=foo
>
> so, in subtree ou=People,dc=foo I need
--On Thursday, June 29, 2017 5:07 PM +0100 Andrew Findlay
wrote:
It seems that the CA cert was never referenced in the syncrepl clause, so
it would have dropped back to whatever TLS config was in the LDAP *client*
config file (probably /etc/ldap/ldap.conf). I
On Mon, Jun 26, 2017 at 11:09:43AM -0700, Quanah Gibson-Mount wrote:
> Now you're switching topics. Your original mail did not include
> cert authentication, it used simple binds:
>
> syncrepl rid=000
> provider=ldaps://ldap.dannatu.ch:636
> type=refreshAndPersist
> retry="5 5 300 +"
>
--On Thursday, June 29, 2017 1:41 PM -0400 btb wrote:
On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote:
--On Thursday, June 29, 2017 2:12 AM -0400 btb wrote:
i see, thanks. i tested this, and did a modify on each, but didn't see
replication resume.
On Tue, Jun 27, 2017 at 01:04:38AM -2100, Zeus Panchenko wrote:
> Subject: [Q] can I replicate several branches to the same slave from one
> master?
> on master I see: consumer state is newer than provider
> on slave: LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
>
> so ... what
On Thu, Jun 29, 2017 at 03:47:07PM +0100, Andrew Findlay wrote:
> I suspect part of the trouble is that you have two syncrepl clauses using the
> same search base on the same master. The timestamps are likely to be stored
> in the same place, causing a clash.
>
> One definite error is that all
On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote:
--On Thursday, June 29, 2017 2:12 AM -0400 btb wrote:
i see, thanks. i tested this, and did a modify on each, but didn't see
replication resume. emulating the syncrepl connection with a manual
search against each master,
Le jeudi 29 juin 2017, 05:23:58 Emmanuel Dreyfus a écrit :
> Côme Chilliet wrote:
>
> > I'm currently working on a PHP RFC to add EXOP handling to php-ldap.
> > The draft is here: https://wiki.php.net/rfc/ldap_exop
>
> FWIW I have been maintaining Pierangelo Masarati's exop
19 matches
Mail list logo