We are testing scenarios with Multi Master Replication (MMR) with many
replicas. We need to gather experience in this area.
The current scenario is a star topology with one central server with
replication agreements with all others, and the others only with the central
server. It is scaled up to
Hi William,
it's an old thread, but it's mine, so I will give an update to the situation
and a follow-up question.
We changed from StartTLS on 389 to SSL on 636 some time ago. Trying to
reconsider the topic we found that there is no plaintext password sent via
network between the replicants, whi
Hi,
many thanks for your answers. Can someone describe this test scenario with 60
masters? Is the topology available to have a look at?
I think this will not be a fully meshed scenario (multi-master with meshed
replication threads), right? It would be nice to have some insight into the
"test" s
Hi,
we want to setup a Multi Master Replication that represents a scenario with
several mobile environments which need to replicate with some immobile server
from time to time. Is it possible - and reasonable - to group the servers of a
mobile environment together to a kind of sub-level MMR whic
Hi,
We use the 389 Directory Server version 1.4.2.15.
In the documentation of the Red Hat Directory Server it says, as many as 20
masters are supported in an MMR. It sounds to be a hardcoded limitation defined
to avoid overloaded servers and network. Shouldn't it be depending on the MMR
topolog
Hi Simon,
does that mean that it is impossible to achieve the goal with the Account
Policy Plugin or some other plugin? It could be that the plugin indeed is
designed to achieve it but it could not because of bugs, or it simply is not
designed to do this.
Your idea means to go the other way roun
Hi Simon,
thanx for your help. But it is rather the other way round: The customer already
has the policy for special users that must not be forced to change the
password. In addition, the customer now wants "normal" users to be completely
locked out when the password has expired, only administr
We have the following scenario:
We use a "global" password policy at cn=config where a customer of ours defines:
passwordexp: on
passwordmaxage: 7776000
passwordwarning: 7344000
We provide as default configuration "passwordMustChage: on" to force a new user
to chage the initial password. In th
Hi,
we have set up a multi master replication (two peers, SIMPLE authentication)
and added a global password policy to cn=config. We included the
passwordMustChange attribute to cn=config, which led to the fact that the
server process could not authenticate to the replication manager of the peer
Hello William,
> I think you need the replication manager entries. So to explain. When the TLS
> connection
> is made by hostname1 to hostname2, on hostname2 the SASL mech of EXTERNAL is
> provided, so
> the bind code looks at other possible authentication factors. The client
> certificate
> pr
Hi William,
> Can you send in your certmap.conf and any of the relevant parts of dse.ldif
> so I can have
> a look at what you configured?
dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
CACertExtractFil
Hi William,
> I think there is also a test case somewhere in the server that uses TLS auth
> for the
> replication manager
>
> https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/suites/repl...
unfortunately we updated to the 1.4.1er 389ds which doesn't have the lib389
python module
Hi Mark,
> Replication does not use the server's certificate for SSL Client
> Authentication. It uses the client certificate in the "Replication
> Manager" entry. Sounds like you did not add a user certificate to this
> entry.
Your hint seems to clarify something. Thanx for that.
First this
I'm trying to setup a replication with a certificate based authentication
between supplier and consumer. The certificates in the certdb at
/etc/dirsrv/slapd-XXX contain the very same CA with which the respective server
certificates in the certdbs have been signed. The certificates all have the '
14 matches
Mail list logo
