you must create a certificate with additional hostnames with -8 option.
you can view an example here:
----- Missatge original -----
> After having read through the Howto:SSL document on the 389 wiki, i
> went ahead and set up SSL for my master instance - it works great, and
> i couldn't be happier. :)
> I have a slave set up to do read-only replication from the master ;
> now, the wiki document has information on how to integrate the
> certificate into a slave so that the replication can occur over SSL,
> which i'll no
> doubt do, but that's not what i'm looking for advice on now.
> What i'm interested in is actually duplicating the new SSL setup that
> currently exists on the master. I realise that this sounds funny, but
> the reason is simple : in our environment, all of the clients and
> LDAP-aware applications are configured to send requests to a given
> hostname (which is not the base FQDN of the LDAP server - it's
> another, separate hostname entirely). If the master goes down, the
> slave automatically has this separate hostname assigned to it.
> (Put another way, it's a sort of poor-man's failover. It's far from
> perfect, and everybody knows it, but that's what's there, so for now
> we live with it. :P )
> What i would appear to need, therefore, is to have the slave be able
> to respond to incoming SSL requests with exactly the same credentials
> as the master. Is this even possible, and if so, how would i got about
> doing it ?
> Thank you, all.
> -- Daniel Maher <dma + 389users AT witbe DOT net>
> -- 389 users mailing list
Last evening we experienced server corruption inside our replicated
Three users got moved from ou=People,dc=scripts,dc=mit,dc=edu to dc=scripts,
and another user got moved from ou=People,dc=scripts to
ou=People,ou=People,dc=scripts. We also couldn't fix it because it claimed
that the correct DN existed.
We also saw replication conflicts using , as the
thing after nsuniqueid instead of +.
P.S. Our dirsrvs have been crashing and segfaulting because of the GSSAPI bugs,
so if you want to blame it on that, ok, though dirsrv should not be corrupting
data when it gets interrupted.
Is 389 DS working fine using 5 - 10 root suffixes? I know its not very common as you usually only need one root suffix for your organization.
The reason why I'm asking is that I want to consolidate several test environments into one single LDAP environment.
I know its possible in 389 but are there any technical issues or limitations I might run into doing this?
Regards - Andreas