Description of problem: register-ds-admin.pl -s -f /<silent file> throws the following error when registering a local DS instance which was setup via setup-ds.pl: Beginning registration of the Directory Server Error: could not find a Directory Server instance. Directory Server may not be set up yet. Please run setup-ds-admin.pl. Note: once you run setup-ds-admin.pl, the server is automatically registered. Exiting . . . Here is a copy of the silent file: [General] FullMachineName= <hostname.FQDN> SuiteSpotUserID= slapd SuiteSpotGroup= ds AdminDomain= <Admin Domain> ConfigDirectoryAdminID= admin ConfigDirectoryAdminPwd= <pwd> ConfigDirectoryLdapURL= ldap://<hostname.FQDN>:389/o=NetscapeRoot [admin] Port= 9830 ServerIpAddress= 127.0.0.1 ServerAdminID= admin ServerAdminPwd= <pwd> http://directory.fedoraproject.org/docs/389ds/design/console-remote-reg-design.html clearly stated under the "Silent mode" section: "There are two types of registration processes to consider. One, registering a local Directory Server instance with a local Admin Server. Two, registering with, or to, a remote server. If you are just doing a local registration, you only need the “General” and “admin” directive sections. If just registering with, or to, a remote server, you only need the “register” directive section (this option assumes there is already a local Admin Server installed)." The customer has two RHDS10 instances running on the same host: inst1 is the configuration instance, and inst2 was setup with setup-ds.pl. They would like to register inst2 with the o=netscaperoot reside on inst1. Version-Release number of selected component (if applicable): #which register-ds-admin.pl: /usr/sbin/register-ds-admin.pl #rpm -qf <path returned from above> 389-admin-1.1.42-1.el7dsrv.x86_64 rpm -qa |grep redhat-ds* redhat-ds-10.0.0-1.el7dsrv.x86_64 redhat-ds-admin-10.0.0-1.el7dsrv.x86_64 redhat-ds-base-10.0.0-1.el7dsrv.x86_64 redhat-ds-console-10.0.0-3.el7dsrv.noarch redhat-ds-console-doc-10.0.0-3.el7dsrv.noarch redhat-ds-base-devel-10.0.0-1.el7dsrv.x86_64 rpm -qa |grep 389-ds-* 389-ds-console-1.2.12-1.el7dsrv.noarch 389-ds-base-libs-1.3.4.0-33.el7_2.x86_64 389-ds-base-1.3.4.0-33.el7_2.x86_64 389-ds-base-devel-1.3.4.0-33.el7_2.x86_64 389-ds-console-doc-1.2.12-1.el7dsrv.noarch rpm -qa |grep 389-admin* 389-admin-1.1.42-1.el7dsrv.x86_64 389-admin-console-doc-1.1.10-1.el7dsrv.noarch 389-adminutil-1.1.22-1.el7dsrv.x86_64 389-adminutil-devel-1.1.22-1.el7dsrv.x86_64 389-admin-console-1.1.10-1.el7dsrv.noarch How reproducible: The issue can easily be reproduced Steps to Reproduce: 1. run setup-ds-admin.pl to create a configuration instance on a RHEL7.2 with RHDS10 installed 2. configure an addition instance with setup-ds.pl 3. put a template similar to the following in place: # more /tmp/register1.inf [General] FullMachineName=dell-r430-15.gsslab.pnq.redhat.com SuiteSpotUserID=dsuser SuiteSpotGroup=dsgroup AdminDomain=example.com ConfigDirectoryAdminID=admin ConfigDirectoryAdminPwd=password ConfigDirectoryLdapURL=ldap://dell-r430-15.gsslab.pnq.redhat.com:1389/o=NetscapeRoot [admin] Port=9830 ServerIpAddress=127.0.0.1 ServerAdminID=admin ServerAdminPwd=password 4. run register-ds-admin.pl -s -f /<silent file> Actual results: It instantly bombs out with: # register-ds-admin.pl -s -f register1.inf Beginning registration of the Directory Server Error: could not find a Directory Server instance. Directory Server may not be set up yet. Please run setup-ds-admin.pl. Note: once you run setup-ds-admin.pl, the server is automatically registered. Exiting . . . Log file is '/tmp/setup5l0Hvp.log' Expected results: It should register the additional local DS instance with the configuration instance Additional info:
Upstream ticket: https://fedorahosted.org/389/ticket/49015
Fixed upstream. Note - the new fix changed the silent install parameters slightly. The design doc has been updated: http://directory.fedoraproject.org/docs/389ds/design/console-remote-reg-design.html
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2907.html