389-ds-base

Clone
Source Code
GIT

#49015 register-ds-admin.pl -s doesn't work with silent file when registering a local instance
Closed: wontfix None Opened 7 years ago by mreynolds.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Directory Server): Bug 1387133

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=Netscap
eRoot

[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:

Very, very minor... line 229 is redundant?
{{{
120 @config_parts = split('::', $mysetup->{inf}->{register_local}->{configinst});

229 @config_parts = split('::', $setup->{inf}->{register_local}->{configinst});
}}}

Let me ask one question regarding this check.
{{{
199 if ($setup->{inf}->{register_remote} && $setup->{inf}->{register_local} ){
200 # You can't have both register_local and register_remote
201 $setup->msg($FATAL, 'error_silent_install_directives');
202 $setup->doExit(1);
}}}
For instance, if you have 3 servers as follows and want to register INSTANCE2 and 3 against the configinst, you have to run register-ds-admin twice? That is, you are supposed to run host-count times to register all the servers? I think that's fine. But I feel I misunderstood something... :)
'''local''':

configinst= slapd-INSTANCE::cn=directory manager::myPassword
instance= slapd-INSTANCE2::cn=directory manager::myPassword

'''remote''':

instance= slapd-INSTANCE3::cn=directory manager::myPassword

First time, you run register-ds-admin with inf file.
[register_local]
{{{
configinst= slapd-INSTANCE::cn=directory manager::myPassword
instance= slapd-INSTANCE2::cn=directory manager::myPassword
}}}
Then, you run the second round with this config?
{{{
[register_local]
configinst= slapd-INSTANCE::cn=directory manager::myPassword

[register_remote]
instance= slapd-INSTANCE2::cn=directory manager::myPassword
}}}

Actually that patch is obsolete (still working on it), but to answer your question:

If you have three instances it looks like this:

[register_local]
configinst= slapd-INSTANCE::cn=directory manager::myPassword
instance= slapd-INSTANCE2::cn=directory manager::myPassword
instance= slapd-INSTANCE3::cn=directory manager::myPassword

instance is multivalued

[register_remote] is only used if you are registering to or from a remote host.

Anyway there are still issues I'm working through. Then I need to rewrite the design doc. Then file a doc bug as the enhancements for this tool were never officially documented.

Ah... Sorry, you are still working on it!

Hmmm, even if slapd-INSTNACE and 2 are on hostA and INSTNACE3 is on hostB, we could still specify like this?
[register_local]
configinst= slapd-INSTANCE::cn=directory manager::myPassword
instance= slapd-INSTANCE2::cn=directory manager::myPassword
instance= slapd-INSTANCE3::cn=directory manager::myPassword

Yep, I'm waiting for your work done. So, no worry about my question. This time, I'll be more patient. ;)

Replying to [comment:5 nhosoi]:

Ah... Sorry, you are still working on it!

Hmmm, even if slapd-INSTNACE and 2 are on hostA and INSTNACE3 is on hostB, we could still specify like this?

In this case you "should" be able to to just use [register remote], but you wouldn't list the remote server (instance 3/host B)as an "instance". It would be the remote host/port, etc.

So [register_local] is for registering local servers with the local config server. This is restricted to the same host. This is how it used to work - before the enhancement of using remote servers.

[register_remote] directive for remote registrations, but you can include unregistered single instances. This can only be run once per remote host.

This is outdated now, but you will get the idea:

http://www.port389.org/docs/389ds/design/console-remote-reg-design.html

[register_local]
configinst= slapd-INSTANCE::cn=directory manager::myPassword
instance= slapd-INSTANCE2::cn=directory manager::myPassword
instance= slapd-INSTANCE3::cn=directory manager::myPassword

Yep, I'm waiting for your work done. So, no worry about my question. This time, I'll be more patient. ;)

I'm surprised you noticed I attached a patch :-)

Ok, thanks for helping me to understand!

I'm surprised you noticed I attached a patch :-)
Yeah, I was chasing the bugzilla side and came here to find out the status.
You haven't set "review?" flag, but I thought you were about to. ;)

I've changed things around, and updated the design/man pages.

Now we just have a single [register] section that can do both local and remote registrations. There were also issues with silent install and when an admin server needs to be installed locally. This worked when running in the interactive mode, but it failed in the silent install.

Looks okay to me, probably good to get Noriko to check this too.

Looks good!!

To ssh://git.fedorahosted.org/git/389/admin.git
b55fec1..32d3339 master -> master
commit 32d3339bd4f088da6cdb1a5f2441c5e57c184f96
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Oct 25 20:45:34 2016 -0400

Metadata Update from @nhosoi:
- Issue assigned to mreynolds
- Issue set to the milestone: 389-admin,console 1.1.44
7 years ago

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

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
3 years ago

Login to comment on this ticket.

Metadata
None
None
None
major
ack
RHCust
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.