On 26 May 2022, at 09:16, tdarby(a)email.arizona.edu wrote:
Hi,
My team is preparing to move to containerized 389-ds instances after years of running on
two AWS EC2 instances in multi-master replication behind a AWS classic load balancer. All
data is on separate EBS volumes. The 389-ds version is 1.3.9.0. I'm mainly curious
about the right way to use the container, so questions:
1. Is the container considered production-ready?
We are supplying a production ready version here at SUSE, so that answer would be
"yes" :)
https://registry.suse.de/cgi-bin/cooverview?srch_term=project%3D%5ESUSE%3...
docker pull registry.suse.de/suse/containers/sle-server/15/containers/suse/389-ds:latest
2. I see that the container will create a new instance if it
doesn't find one. How does it determine that an instance exists?
Inside of the data volume, 389-ds will setup it's structure and an instance, and will
then drop in a "marker" file which is /data/config/container.inf that indicates
the first-setup is done.
3. What setup config options are available to the container? I see
mention of container.inf, but it's not clear what all I can put in that. For the
install of our current directory, we need to make dse.ldif changes, ACI changes, schema
changes and other things. I realize I can do all this after the container creates the bare
instance, but I'm wondering how much the container install could do for me.
So the container install does nothing to setup the dse.ldif, aci, schema. It just makes a
"minimal" instance. From there you can administer it like any other instance,
with the dsconf tools, ldapmodify, or editing the /data/config/dse.ldif by hand.
4. How big of a deal is it going to be moving from 1.3.9.0 to the
latest version?
Shouldn't be a big deal at all :)
Additionally, we were wondering if it's possible to have an AWS load balancer handle
the TLS exchanges instead of the LDAP instances. In other words, install the certificate
on the load balancer and have it talk unencrypted to the LDAP instances over port 389.
That's fine, it just means you can't enforce some properties on the ldap servers
but that's not a huge deal. Best practice is just to expose LDAPS on port 636 only
from your loadbalancers, as that guarantees all your traffic is secure.
Thanks,
Tim
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia