#49221 setup-ds-admin.pl -u with nsslapd-localhost changed
Closed: fixed 2 years ago Opened 2 years ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1442880

+++ This bug was initially created as a clone of Bug #1394006 +++

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

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1442880

2 years ago

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1442880

2 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

2 years ago

Metadata Update from @mreynolds:
- Custom field component adjusted to Install/Uninstall
- Custom field origin adjusted to RHCust
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to defect

2 years ago

Looks good to me. There are 3 more assigns with no checking. Are they ok?
$inf->{General}->{FullMachineName} = $entry->getValue("nsslapd-localhost");
$inf->{General}->{SuiteSpotUserID} = $entry->getValue("nsslapd-localuser");
$inf->{slapd}->{ServerPort} = $entry->getValue("nsslapd-port");
$inf->{slapd}->{ldapifilepath} = $entry->getValue("nsslapd-ldapifilepath");

Metadata Update from @nhosoi:
- Custom field reviewstatus adjusted to ack (was: review)

2 years ago

Looks good to me. There are 3 more assigns with no checking. Are they ok?
$inf->{General}->{FullMachineName} = $entry->getValue("nsslapd-localhost");
$inf->{General}->{SuiteSpotUserID} = $entry->getValue("nsslapd-localuser");
$inf->{slapd}->{ServerPort} = $entry->getValue("nsslapd-port");
$inf->{slapd}->{ldapifilepath} = $entry->getValue("nsslapd-ldapifilepath");

The localhost is kind of a special case for dealing with load balancers. I don't think we should allow changing the other values during an upgrade as it could break things (changing the port/user would have some nasty side effects). I suppose LDAPI would be a safe change, but i'm not sure why you want to change it during an upgrade.

Thanks for the explanation! It makes sense. No further questions from me... :)

Thanks for the review Noriko!

5e578de..8979cc6 master -> master

a8692b1..9132065 389-ds-base-1.3.5 -> 389-ds-base-1.3.5

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata