Bug 1394006

Summary: setup-ds-admin.pl -u with nsslapd-localhost changed
Product: Red Hat Directory Server Reporter: Brian J. Atkisson <batkisso>
Component: Command Line UtilitiesAssignee: mreynolds
Status: CLOSED DUPLICATE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 10.0CC: mreynolds, nhosoi, nkinder
Target Milestone: DS10.1.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1442880 (view as bug list) Environment:
Last Closed: 2017-04-20 15:31:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1442880, 1444951    

Description Brian J. Atkisson 2016-11-10 19:48:47 UTC
Description of problem:

This is a follow-on issue to bz#1153758.  When nsslapd-localhost is set to a load balancer FQDN to support GSSAPI ticket auth, it breaks running setup-ds-admin.pl -u.

When you have an existing server registered to an admin server for use with the 389 console, running setup-ds-admin.pl -u adds another host (named after the load balancer) to the 389 console gui rather than updating the server's console data.  This is required in order for the correct jar to be served up by 389 console.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.5.10-11.el7.x86_64

Steps to Reproduce:
1. install 389 replica, running setup-ds-admin.pl
2. update nsslapd-localhost with the load balancer fqdn
3. run setup-ds-admin.pl -s -u -f /tmp/setup.inf
4. see the new entry appear in 389 console rather than having the true replica's information updated.

setup.inf:

[General]
StrictHostCheck= False
FullMachineName= slave.example.com
SuiteSpotUserID= ldap
SuiteSpotGroup= ldap
AdminDomain= CORP_LDAP
ConfigDirectoryAdminID= admin
ConfigDirectoryAdminPwd= bleh
ConfigDirectoryLdapURL= ldaps://master.example.com:636/o=NetscapeRoot
UserDirectoryAdminID= cn=Directory Manager
UserDirectoryAdminPwd= bleh
UserDirectoryLdapURL= ldap://slave.example.com:389/o=NetscapeRoot

[slapd]
SlapdConfigForMC= No
SecurityOn= No
UseExistingMC= Yes
UseExistingUG= No
ServerPort= 389
ServerIdentifier= corpldap
Suffix= dc=example,dc=com
RootDN= cn=Directory Manager
AddSampleEntries= No
InstallLdifFile= none
AddOrgEntries= No
DisableSchemaChecking= No
RootDNPwd= bleh

[admin]
SysUser= ldap
Port= 9830
ServerAdminID= admin
ServerAdminPwd= bleh

Comment 1 Nathan Kinder 2017-04-20 15:31:22 UTC

*** This bug has been marked as a duplicate of bug 1442880 ***