Add comments

[Firstyear]

Hey there,

I've added a stack of comments to your setup here. There may be some ways to simplify this on EL8 and fedora in the future. I've also noted some places where there are possible bugs, and things that can be better.

Hope it helps. Remember to email me!

[colbyprior]

Thanks for the review, you raise some great points. I am still pretty new to running a ldap server and you have been a huge help. I will start going through some of these changes and start fixing them up.

• I will change setup-ds-admin.pl to setup-ds.pl, good catch.
• This is a personal view but I don't like using the ansible cron module because it uses crontab instead of cron.d. If there is a compelling reason to change I am open to it.
• I will definitely change the consumer-supplier wording to "read only replica" and "read-write master". It really threw off my understanding of how multi master replication works.
• I think I am following you about the toreinit being dangerous, I have messed up a few dev servers with this. I really like this approach for deploying an initial cluster of ldap servers but as for adding to an existing ldap cluster it is probably a bit reckless. Is this what you were referring to?
• For Set nsslapd-security I am using a shell command so I guess its fine? To be honest I wasn't aware of the ansible ldap_attr plugin. 😅 I should add the reference to that issue either way so that mistake isn't made in the future.
• I see the file handlers are already set by default so I should just remove that part.
• The dirsrv group in ansible could be removed, it does come with the rpm.
• How would I pull in variables from defaults.inf for the backup shell script? Does it have a benefit over how I supply it via ansible?
• Replication on 636 is on the list 😄

[Firstyear]

• totreinit - Sorry, I should say "begin replica refresh" or whatever. So one of the metadata that exists in 389ds is that when you populate a backend, it also populates the "replica generation". So when you take two servers, like say X and Y. You create them and they both have dc=example,dc=com. Now X will have a db replica generation of say 1000, and Y may have a replica generation of 2000. You can't see this value, it's hidden in the DB/replication code.

So when you are doing a total reinit, you are pushing from the supplier to the consumer, and basically saying "discard your data, and take mine". This recreates the replica generation on the consumer. Lets say you did X -> Y for totreinit, now Y would have replica generation of 1000. If the replica generations don't match replication will not work. It will refuse to run.

So you start the first server (X) as your "first master". Then as you join new masters, you go from X -> consumer with a totreinit to get all the replica generations in sync. Note, provided you have done X -> Y, then Y -> Other can work because X and Y have the same generation.

So this is why you probably want to be careful about the totreinit. It really is a "full wipe and send" of data.

• The ldapmodifies are a bit gnarly, but they work. Ansible config changes won't work because of lack of ldapcompare on cn=config today (it's a special in-memory suffix actually). It's not hard to add, but just not done yet.

• Yeah, the server is now really good at "self tuning" out of the box. I think only the tcp/ip settings are needed and even then, we ship a sysctl file too ....

• How you do it is up to you. The benefit of defaults.inf is you gain portability across distros that may have different paths. It's our "build time" this is where you want all your stuff. All our python tools consume it to know "where" ds actually is. It's not such a big deal, but may help.

Do also look at testing 1.4.x on fedora, the new cli tools are magical :)