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? 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? 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. 4. How big of a deal is it going to be moving from 1.3.9.0 to the latest version?
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.
Thanks, Tim
On 26 May 2022, at 09:16, tdarby@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:
- 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%3ACo...
docker pull registry.suse.de/suse/containers/sle-server/15/containers/suse/389-ds:latest
- 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.
- 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.
- 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... 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
Thanks! I've succeeded in getting all my configs scripted with Python, except for setting the nsslapd-db-locks attribute:
standalone.conig,set (fail) dse_ldif.replace (fail) dsconf works!
What's the magic here? Is there a Pythonic way to do this?
Also, I'm surpsised at how much I had to resort to Python LDAP to get things done. I kinda thought that lib389 would do most of it?
On 6 Jun 2022, at 12:12, tdarby@email.arizona.edu wrote:
Thanks! I've succeeded in getting all my configs scripted with Python, except for setting the nsslapd-db-locks attribute:
standalone.conig,set (fail) dse_ldif.replace (fail) dsconf works!
What's the magic here? Is there a Pythonic way to do this?
The magic is likely that dse.ldif, if changed while the server is running is will automatically revert your changes from "in memory". This is because 389-ds can "live" update it's config.
So dsconf is using the ldap-facing live update mechanism, which means ns-slapd writes the changes down to dse.ldif. That's probably what you are encountering.
Also, I'm surpsised at how much I had to resort to Python LDAP to get things done. I kinda thought that lib389 would do most of it?
What did you find was missing?
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
Thanks, so is there a way to change the nsslapd-db-locks attribute in Python? it would be nice to do it all there instead of having to shell out to dsconf.
I'll try to put together a list of lib389 things.
Hi Tim, FYI: There is an example about how to change nsslapd-db-locks using lib389 in one of our test: see https://github.com/389ds/389-ds-base/blob/master/dirsrvtests/tests/suites/mo... As you can see that is that is quite direct: bdb_config = BDB_LDBMConfig(inst) bdb_config.replace("nsslapd-db-locks", "11000") # Restart server inst.restart()
On Tue, Jun 7, 2022 at 6:29 AM tdarby@email.arizona.edu wrote:
Thanks, so is there a way to change the nsslapd-db-locks attribute in Python? it would be nice to do it all there instead of having to shell out to dsconf.
I'll try to put together a list of lib389 things. _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I've got things pretty well scripted now, but one thing I've never been sure of is what exactly maps to a database.
In our current dirsrv, we've got one databse for our base suffix "dc=eds,dc=arizona,dc=edu" and everything is contained in that (ou=people,dc=eds,dc=arizona,dc=edu, for example).
In the new directory, I'd like the base suffix to be "dc=arizona,dc=edu" (where some new objects will live) and then the additional suffix "dc=eds,dc=arizona,dc=edu", which will contain all the same stuff as the current directory (ou=people, etc.)
So my question is, if I make a database for "dc=arizona,dc=edu", can "dc=eds,dc=arizona,dc=edu" also reside in that database (by making an additional domain for it?) or does it have to have its own db.
On 6/13/22 1:31 PM, tdarby@email.arizona.edu wrote:
I've got things pretty well scripted now, but one thing I've never been sure of is what exactly maps to a database.
In our current dirsrv, we've got one databse for our base suffix "dc=eds,dc=arizona,dc=edu" and everything is contained in that (ou=people,dc=eds,dc=arizona,dc=edu, for example).
In the new directory, I'd like the base suffix to be "dc=arizona,dc=edu" (where some new objects will live) and then the additional suffix "dc=eds,dc=arizona,dc=edu", which will contain all the same stuff as the current directory (ou=people, etc.)
So my question is, if I make a database for "dc=arizona,dc=edu", can "dc=eds,dc=arizona,dc=edu" also reside in that database (by making an additional domain for it?) or does it have to have its own db.
Why not just use "dc=arizona,dc=edu" and move all the entries under it? Otherwise yes you need two databases and then you can make dc=eds,dc=arizona,dc=edu a subsuffix of the other. But if you don't need two databases then I would just merge the content under a single suffix (much much easier to maintain).
Mark
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Ok, so I think what you're saying is that each domain (dc=arizona,dc=edu and dc=eds,dc=arizona,dc=edu) requires its own database? Maybe I will rethink this plan just to keep things simple.
Well you can create "dc=arizona,dc=edu", and then create a regular entry under it: "dc=eds,dc=arizona,dc=edu". That will all be under a single suffix then. You just need to put your users under whatever branch you prefer. There is no right or wrong, as long as your LDAP clients use the correct search base when trying to find users, etc.
HTH,
Mark
On 6/13/22 2:12 PM, tdarby@email.arizona.edu wrote:
Ok, so I think what you're saying is that each domain (dc=arizona,dc=edu and dc=eds,dc=arizona,dc=edu) requires its own database? Maybe I will rethink this plan just to keep things simple. _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 14 Jun 2022, at 03:31, tdarby@email.arizona.edu wrote:
So my question is, if I make a database for "dc=arizona,dc=edu", can "dc=eds,dc=arizona,dc=edu" also reside in that database (by making an additional domain for it?) or does it have to have its own db.
It can all be in one database, as Mark said :)
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
389-users@lists.fedoraproject.org
-
Mark Reynolds -
Pierre Rogier -
tdarby＠email.arizona.edu -
William Brown