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@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproje > > > ct.org > > > > > > _______________________________________________ > > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject > > .org > > > > > > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Thanks, William Brown _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
