Date: Thu, 28 Mar 2024 15:55:21 +0000 (UTC) Message-ID: <1338594347.6607.1711641321524@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6606_1771579967.1711641321523" ------=_Part_6606_1771579967.1711641321523 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Installing 389 on Centos or Redhat is actually very easy once Salt Minio= n is installed, because they both require the EPEL yum repository to be add= ed. From there the salt file that installs 389-DS is very easy and accompli= shed with the package module which already knows how to install and uninsta= ll rpm's from yum...
The 389-ds/init.sls file simply creates an ldap user, and installs 389-d= s.
It is when you want to install a directory into 389-ds where installatio= n gets more involved. Fortunately, we can do much of it from the command li= ne.
Essentially there are three parts to this, the setup perl script which i= s included in the 389-ds packages installed on the client, the setup.inf fi= le which it uses to configure the new directory, and multi-master.ldif whic= h initiates a dual multi-master connection between two nodes (one assumed t= o be ldap-dev1 and ldap-dev2).
Mullti-master.ldif uses Jinja templates to make slight alterations for w= hether it is going to ldap-dev1 or ldap-dev2.
In this way we can give our servers a sense of architecture, or where th= ey fit in a much greater whole. The challenge, which is a challenge with an= y configuration management program, is how to describe that architecture in= a dynamic way. How does the installation change if we add another ldap ser= ver so that they are all mutli-master? We can bypass this conundrum if we s= implify the multi-master role to simply be two servers, and make any extens= ion to them be copy-only. But only slightly, as the replication agreement i= s still requires actions on both members of that replication scheme.
Also perplexing at the moment is how to handle SSL files. We are using a= script which will generate new self-signed certs for each installation. Th= is would certainly be required for any additional ldap server iterated into= the cluster. However those certs will need to be added all over the cluste= r, and to the java servers authenticating to ldap, once created. how to do = that is an issue that we don't have a good answer to at the moment. One sol= ution would be to create our own certificate authority, which would be the = only cert required to add to every server.