error in log with dna plugin

[rduffner]

Using CentOS 8.3 amd64, 389-ds-base-1.4.3.17

I get this in the error log:

[23/Jan/2021:23:48:42.177303526 +0100] - ERR - dna-plugin - dna_parse_config_entry - Unable to locate shared configuration entry (cn=Account UIDs,ou=Ranges,dc=i,dc=ewsrv,dc=ch)
[23/Jan/2021:23:48:42.177841836 +0100] - ERR - dna-plugin - dna_parse_config_entry - Invalid config entry [cn=uid numbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped
[23/Jan/2021:23:48:42.178312560 +0100] - ERR - dna-plugin - dna_parse_config_entry - Unable to locate shared configuration entry (cn=Account GIDs,ou=Ranges,dc=i,dc=ewsrv,dc=ch)
[23/Jan/2021:23:48:42.178713577 +0100] - ERR - dna-plugin - dna_parse_config_entry - Invalid config entry [cn=gid numbers,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped

created with this configuration:

dirsrv_starttls_early: '{{ dirsrv_tls_enabled }}'
dirsrv_suffix: "dc=i,dc=dom,dc=com"
dirsrv_rootdn_password: "bla-blu-blap"

dirsrv_fqdn: "dir.i.dom.com"

dirsrv_serverid: "dir"

dirsv_role: "both"

dirsrv_plugins_enabled: 
  MemberOf Plugin: True
  Distributed Numeric Assignment Plugin: True

dirsrv_dna_plugin:
  gid_min: 200000
  gid_max: 999999
  uid_min: 200000
  uid_max: 999999

dirsrv_allow_other_schema_files: "True"
dirsrv_custom_schema: ["freeradius-ldap-schema.schema"]
dirsrv_create_suffix_entry: "True"

dirsrv_install_examples: True

[lvps]

I've just noticed that you defined dirsrv_role, but it should be dirsrv_replica_role, hopefully changing that should fix everything.

Otherwise, are you actually doing replication? Is that server both a supplier and consumer? Does cn=Account UIDs,ou=Ranges,... exist?

[rduffner]

Hi,

I plan on doing dual-master replication, but currently I only want to get the servers setup.

Unfortunately, setting dirsrv_replica_role did not fix the problem.

Do I need to have a fully working replication-setup before I can enable the DNA plugin?

[lvps]

I think it should work even without replication, it just won't be "distributed"... unfortunately I never used the DNA plugin in production, so I don't know a lot about it.

Can you try to git checkout v.1.4.0 of this role? Everything should work the same, except that it was setting up the DNA plugin differently. If that works there's probably some attribute that 389DS doesn't like in the new config.

[rduffner]

I've now tried to enable replication but because I tried to disabled TLS, it did not work.

[24/Jan/2021:02:06:38.017694751 +0100] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error 2 (Protocol error)

I will setup self-signed certificates.

Where would I find the cn=Account UIDs,ou=Ranges... dn?

[lvps]

I've enabled the DNA plugin in the automated tests and it seems to work fine - or at least it doesn't throw that error.
Vars for the test are:

https://github.com/lvps/389ds-server/blob/master/molecule/other_features/converge.yml#L5-L25

but I cannot see anything significant that's different from your vars.

Anyway, the cn=Account UIDs,ou=Ranges,... DN should be at cn=Account UIDs,ou=Ranges,dc=i,dc=dom,dc=com, it is defined as cn=Account UIDs,ou=Ranges,{{ dirsrv_suffix }} in configure_plugins.yml. Does it exist? Are there any attributes there?

[rduffner]

OK, I think you really need TLS. I tried with a (self-signed) certificate and it all ran through and the ou=ranges shows up.

However, when I tried to setup replication with a self-signed certificate, this failed because the certificate is self-signed. The cert.sh script doesn't really save the CA cert - and it looks like (from the comments) that there's currently no way to manually add it?

[lvps]

It's great that you solved the first part - I'd never have guessed TLS was required for those tasks.

When you're using self-signed certs, each server should indeed have other servers certificates in its NSS database. If you've used my cert.sh from 389ds-examples it only outputs a pem certificate and a private key, there's no CA at all. You just need to add the pem file to the other server and it will be trusted, see e.g. master-1.yml (or you can run the certutil command manually). If you have a self-signed CA, you can use the same tasks/commands to add its cert to each server, it should work in theory.

Just keep in mind that cert.sh is a simple a way to test TLS with 389DS and my roles, but I don't know if those settings are safe for production!

Personally, for production I use Let's Encrypt certificates, automated through Ansible: https://github.com/lvps/389ds-server#tls-with-lets-encrypt-or-other-acme-providers