Bug 1872910

Summary:	dscreate: start = False: Error: Can't contact LDAP server - 107 - Transport endpoint is not connected
Product:	Red Hat Enterprise Linux 8	Reporter:	Graham Leggett <minfrin>
Component:	389-ds-base	Assignee:	mreynolds
Status:	CLOSED DUPLICATE	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.4	CC:	spichugi, tbordaz, vashirov
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-08-31 12:35:55 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:

Description Graham Leggett 2020-08-26 21:51:32 UTC

Description of problem:

The "start = False" option in dscreate is ignored.

Version-Release number of selected component (if applicable):

389-ds-base-1.4.2.4-8.module_el8.2.0+366+71e3276f.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Create slapd-default.inf as follows:

[general]
start = False
[slapd]
instance_name = default
[backend-userroot]

2. Run "dscreate from-file slapd-default.inf"
3.

Actual results:

+ /usr/sbin/dscreate from-file /etc/dirsrv/slapd-default.inf
Starting installation...
Error: Can't contact LDAP server - 107 - Transport endpoint is not connected

Expected results:

Installation completes WITHOUT starting 389ds, as per docs, allowing further automated config to continue.

Additional info:

According to the docs in the generated template, if "start = False" is provided, the instance is (not) started.

# start (bool)
# Description: Starts the instance after the install completes. If false, the instance is created but started.
# Default value: True 
;start = True
start = False

It looks like the start function does not do anything.

This breaks automated installation of 389ds.

Comment 1 Graham Leggett 2020-08-27 15:44:13 UTC

Running dscreate through strace, this shows that despite the "start = False" flag being present, not only is the server started, but subsequent calls inside dscreate are trying to connect to the server.

In this case the FQDN does not yet work, and thus the connection fails. When the FQDN does exist, it looks like the dscreate ignores the start flag and starts anyway.

Comment 2 mreynolds 2020-08-31 12:35:55 UTC

Closing as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1872930

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

Comment 3 Graham Leggett 2024-02-18 22:20:58 UTC

Just noticed this was closed as a duplicate of an unrelated bug, and was never fixed.

Cries in further automation pain.