> On 26 May 2022, at 09:16, tdarby@xxxxxxxxxxxxxxxxx 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%3AContainers%3A+container%3D.*suse%2F389-ds 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > 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 _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
