There is also an issue with dscreate template. sample_entries is commented out by default, so the domain object is not created. This leads to users' confusion, since backend is enabled, but ldap operations on that backend (like adding user, searching, etc.) are not working until dc object is created manually.
I'd like to propose 2 things:
1. enable sample entries by default.
2. separate top level domain and the actual sample entries (like users, groups and aci examples).

https://pagure.io/389-ds-base/pull-request/50044

There is also an issue with dscreate template. sample_entries is commented out by default, so the domain object is not created. This leads to users' confusion, since backend is enabled, but ldap operations on that backend (like adding user, searching, etc.) are not working until dc object is created manually.

I've added a simple Domain object with basic ACI to the dscreate installation.

I'd like to propose 2 things:
1. enable sample entries by default.

I am not sure why should it be by default. I think the more common situation will be that the administrator will create an instance and then import their own LDIF. Or he would like to create the tree as he wants.

If he still would like to have the sample entries he can use the installer option or create it with another CLI tool afterwords.

1. separate top level domain and the actual sample entries (like users, groups and aci examples).

Yeah, I've done something like this in the PR. Though we face some issues with versioning here...

This was really really really intentional. The issue is when you are creating a replica, you may NOT need a backend made with entries becaus you are about to nuke it anyway. It also affects container deployments because you need to run the setup with "backend free" so that you have an instance there that can be run and "pick up" the existing config.

As well, often what we would create with samples and stuff is ignored because people just migrate their old data anyway.

So having this as "blank slate" and you fill it in makes the entire experience better as an admin. SQL doesn't ship with tables, we shouldn't provide a backend.

If you want to do this by default, then make the example file just template out what the backend would look like, and interactive can just prompt. But it is imperative that we are able to create instances with no backends.

@firstyear, I understand the benefit of being able to create an instance without backend. But this ticket is when we create an instance and specify a backend/suffix, then to create the suffix entry as well. It is a concern for container deployements to create the suffix entry (e.g. "dc=example,dc=com") ?

If we decide to create the suffix entry, the set of ACI can be a subject.

Too late to the party here but I believe we should not create any entries when creating the backend (unless explicitly asked for it, we can have a checkbox for that as well). The suffix here tells the ns-slapd which DB to look into, not that the data is actually there. This would be same as with OpenLDAP, where you define the backend type (mdb/bdb), the suffix, and the slapd creates the necessary files for the DB to exist, however no entries are populated. And as Thierry wrote, if we create the entry we need to decide upon ACIs.

I would rather fix ppolicy handling to not cry (what's the difference between no suffix entry and suffix entry which does not contain any ppolicy configuration?). I'd rather raise some meaningful exception and handle it as required in the calling function according to expectations, than just ValueError.

Not sure how we do backups exactly (might align with William's concern about containers picking up data) or importing LDIFs in general, but I imagine the full dumps of databases to contain the root entry as well which would result in entry already existing when doing mere 'add' of the entries from LDIF. (I might be way off here, anywhere, so feel free to ignore in such a case :))

We should make the top node initialization optional. Maybe add a new "sample entries" config value (1) and update the UI and interactive installer to handle both (multiple) sample entry values.

Or even create multiple config levels (top node with no acis, and top node with generic acis, etc)

Created PR to make creating the top suffix entry optional:

https://pagure.io/389-ds-base/pull-request/50121

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3043

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.