Thank you William! That is great advice, and thank you for the link to the documentation.
--
-Jesse
On Wed, Feb 28, 2018 at 6:29 PM, William Brown <william@xxxxxxxxxxxxxxxx> wrote:
On Wed, 2018-02-28 at 11:45 -0500, JESSE LUNT wrote:
> Hey Kevin,
>
>
> I am doing a one-way replication (for now). I believe I have
> replication accounts on both machines. Honestly I didn't know to
> look. Are they local user accounts or is there accounts/ permissions
> in the directory? How can I tell? I would like to replicate all
> attributes.
Hi there,
Mark already linked some docs and resources. I realise this is probably
pretty stressful being dropped into some new software and not knowing
what's going on! We have fantastic documentation for the server, but
there is a lot of it, so it's hard to know where to start!
My advice is to take backups first. We provide a rich set of tools for
this, and at least if everything goes wrong, you have something to fall
back on. I recommend db2ldif, but others use db2bak. I like db2ldif as
it creates a human readable text file of the db content which is nice
for inspection also. You can read more here:
https://access.redhat.com/documentation/en-us/red_hat_ directory_server/
10/html/administration_guide/populating_directory_ databases-
exporting_data
So now that you have this, I'd really recommend trying to setup an
environment in parallel you can test on. Two small vms will suffice. Go
through and setup replication for the latest server version -
replication configuration has not changed a great deal, so the concepts
are still just as valid.
The trick to remember is where things are. In a simple setup you have
the replicated data, and you have some local data in cn=config
(dse.ldif). So if you think of it this way:
SERVER A SERVER B
cn=config cn=config
cn=replication manager... cn=replication manager...
[ Replicated Database ]
So content in the backend (like dc=example,dc=com) will be shared, but
the content in cn=config is local to each server.
The complexity comes from replication that an agreement from Server A
to replicate to server B, references things locgal to server B. For
example on server A I might an agreement (this is not syntax correct,
it's a demo)
cn=me_to_server_b,cn=replication,....
objectClass: nsds5replicationagreement
binddn: cn=replication manager
^ This means "replication manager ON server b" not the
local one.
Anyway, I hope that gives you some information to help get you moving.
Really do take some backups and know how to restore them, because at
the very least, that's your fallback and security.
I hope you manage to fix it! We are always here if you have more
qustions,
>
> On Wed, Feb 28, 2018 at 9:35 AM, Kevin C. Kelly <kck@xxxxxxx> wrote:
> > Hi Jesse,
> > Can you share some details about your replication agreement? For
> > example - what type of replication are you doing - one way or
> > multi-master, you have replication accounts on both servers, you
> > confirmed the replication passwords are correct, are you
> > replicating all of your attributes or only some of the attributes,
> > etc.
> > Other thoughts include:
> > 1. Do both servers have the same schema loaded?
> > 2. Are you seeing any errors in any of the logs?
> > - Kevin
> >
> > On 2/28/18 9:26 AM, JESSE LUNT wrote:
> > > Hello,
> > >
> > > I have inherited a 389 LDAP environment, which is running
> > > on RHEL 5.5 server. There are two RHEL 5.5 servers in the LDAP
> > > environment (389ds1 and 389ds2)
> > >
> > > Currently the directory is only on one system as the replication
> > > hasn't been working for aprox a year (yikes!!!) I am trying to
> > > create a replication agreement between two servers. When I add
> > > the replication agreement I receive an error " LDAP server is
> > > unwilling to perform"
> > >
> > > My thought is before I introduce a newer version of the LDAP I
> > > should try to get the replication between the two existing
> > > servers working.
> > >
> > > Any thoughts on where to begin troubleshooting this? I am a 389
> > > LDAP noob....
> > >
> > >
> > > Thanks,
> > >
> > > Jesse
> > >
> > > --
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproje
> > > ct.org
> >
> >
> > _______________________________________________
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject
> > .org
> >
>
>
>
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
> rg
--
Thanks,
William Brown
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Jesse Lunt
Director of Network and User Services
Office of Information Services
North Shore Community College
(978)-762-4014
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
