I think version 1.2.x is not supported on EL7, unless there is something I'm not aware of? You probably should use 1.3.x which is supported with that configuration.

If this is the case, I have to check back with the admin who is responsible for the repositories. But as far as I know, this is the version provided by the official repos.

This is not true - 1.3.x is provided by RHEL7 and Centos7 repositories. Source - I'm a former Red Hat employee who worked on the 389 team :)

As a result, I think you should check with your admin, because it sounds like this is an unsupported and incorrect configuration.

Sorry :(

I researched what the problem is. If you install 389-ds you will get version 1.2.2 from the epel. If you install 389-ds-base, 389-ds-admin, etc. you will get the mentioned version 1.3. Maybe this should be corrected.

There is always confusion here. You guys are actually talking about two different things.

389-ds --> this is the 'layered product' , this package is just a set of dependences: 389-ds-base, 389-ds-base-libs, 389-admin, 389-adminutil, 389-ds-console, etc

389-ds-base -> this is the core server, and this the version number support/developers need to know.

Often admins of 389 Directory Server report the version they see for "389-ds" and not "389-ds-base". It's truly an honest mistake, and this is why I always ask for the version number by providing the exact command I want run (sorry a little off topic)

rpm -qa | grep 389-ds-base

Anyway, the 389-admin product is deprecated and is being replaced by a Cockpit plugin in RHEL 8. We are not maintaining the 389-admin packages any more except for security fixes.

The issue here is if this is a bug or config/environment issue. Now can you get this working outside of Ansible? Is there anything in the access & error log for the admin server: /var/log/dirsrv/admin-serv/ ?

So when there is this set of dependencies, why is it a set of deprecated dependencies? Wouldn't it be way nicer, of they were up to date?
So when one installs 389-ds there are all the packages needed to run a 389-ds setup? And ok, when these are packages for backwards compatibility with RHEL or smth., then why isn't there a set 389-ds and 389-ds-comp for compatibilty?

But I digress, I'm fully aware of this issue that 389-ds-admin is being replaced by Cockpit. But as there is no release date for CentOS8, it could be released tomorrow or also next year, therefore I have to work on this system like there will be no release in the next years. Problems could occure and the release could be delayed.

I checked back with the provided command, 389-ds-base is updated to version 1.3.8, the problem persists.

Nonetheless, yes I can get this to work outside of Ansible, but it's not how we do stuff normally. And no there is nothing directly related to this issue in the error or access log.

So when there is this set of dependencies, why is it a set of deprecated dependencies? Wouldn't it be way nicer, of they were up to date?

Not sure I follow. When I say dependencies I mean all the packages needed for the layered product, which means DS and the UI (the admin server and console).

So when one installs 389-ds there are all the packages needed to run a 389-ds setup?

Yes

And ok, when these are packages for backwards compatibility with RHEL or smth., then why isn't there a set 389-ds and 389-ds-comp for compatibilty?

Again, not sure I follow what you are complaining about. 389-ds is really just a "short cut" for installing everything you need for the console. It was provided as a convenience.

But I digress, I'm fully aware of this issue that 389-ds-admin is being replaced by Cockpit. But as there is no release date for CentOS8, it could be released tomorrow or also next year, therefore I have to work on this system like there will be no release in the next years. Problems could occure and the release could be delayed.

Understood, but not sure what to tell you. Paying customers can get extra support, but there are no known issues with the Admin Server. It's been stable for a very long time now.

I checked back with the provided command, 389-ds-base is updated to version 1.3.8, the problem persists.
Nonetheless, yes I can get this to work outside of Ansible, but it's not how we do stuff normally. And no there is nothing directly related to this issue in the error or access log.

So if it works outside of Ansible then it doesn't sound like a bug, but an issue with Ansible. No? We also have not verified or officially tested 389 (DS or admin server) in Ansible. Personally I have not worked with Ansible, so I do not know what tricks you have to perform to get it working.

I just verified Admin Server works fine for me using the traditional installation method (setup-ds-admin.pl -s -f ./setup.inf) on RHEL 7.

Here is my silent install file:

[General]
FullMachineName= localhost.localdomain
SuiteSpotUserID= dirsrv
SuiteSpotGroup= dirsrv
AdminDomain= example.com
ConfigDirectoryAdminID= admin
ConfigDirectoryAdminPwd= admin
ConfigDirectoryLdapURL= ldap://localhost.localdomain:389/o=NetscapeRoot
[slapd]
SlapdConfigForMC= Yes
UseExistingMC= 0
ServerPort= 389
ServerIdentifier= localhost
Suffix= dc=example,dc=com
RootDN= cn=dm
RootDNPwd= MY_PASSWORD
ds_bename=userroot
AddSampleEntries= No
[admin]
Port= 9830
ServerIpAddress= 127.0.0.1
ServerAdminID= admin
ServerAdminPwd= admin

Maybe you are running into a SELinux issue with the admin port number you are using? Perhaps @firstyear might have some other ideas?

I investigated further and found the problem.
This part of my .inf file was the problem:

UseExistingMC = 1

Because this was set in the [slapd] section some important files for the admin server weren't created. I really don't know why stuff in this section affects the admin server.

Thank you for your time and efforts to help me with this issue.

I investigated further and found the problem.
This part of my .inf file was the problem:
UseExistingMC = 1
Because this was set in the [slapd] section some important files for the admin server weren't created. I really don't know why stuff in this section affects the admin server.

That setting states that an admin server (or configuration server, aka Mission Control) already exists. Sorry I overlooked that when I looked at this issue, but I also did not know it would not install certain files. Anyway glad you got it working!

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/3406

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.