[389-users] Re: Installing an instance of 389ds from scratch - how?

On 8/27/20 11:08 AM, Graham Leggett wrote:

On 27 Aug 2020, at 15:32, Mark Reynolds <mreynolds@redhat.com> wrote:

All of this works correctly for me:


[general]
config_version = 2
full_machine_name = localhost.localdomain
start = False

[slapd]
instance_name = graham
port = 389
root_dn = cn=dm
root_password = PASSWORD
self_sign_cert = False

[backend-userroot]
sample_entries = yes
suffix = dc=example,dc=com


Server is created, but not started, and TLS is disabled.  Did I miss a step?

No luck for me:

[root@gatekeeper dirsrv]# cat /etc/dirsrv/slapd-default.inf

[general]

config_version = 2

full_machine_name = localhost.localdomain

start = False

[slapd]

instance_name = default

port = 389

root_dn = cn=dm

root_password = PASSWORD

self_sign_cert = False

[backend-userroot]

sample_entries = yes

suffix = dc=example,dc=com

[root@gatekeeper dirsrv]# /usr/sbin/dscreate from-file /etc/dirsrv/slapd-default.inf

Starting installation...

Error: Can't contact LDAP server - 107 - Transport endpoint is not connected

[root@gatekeeper dirsrv]# ps -auxwww | grep slap

dirsrv     25283  1.6  2.4 971356 197544 ?       Ssl  16:55   0:02 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-default -i /run/dirsrv/slapd-default.pid

root       25360  0.0  0.0 221900  1092 pts/0    S+   16:58   0:00 grep --color=auto slap

Running dscreate through strace shows that despite being told the name of the server is localhost.localdomain, and despite being told not to start the server, dscreate tries to connect to the server using the FQDN of the machine on port 389, and not localhost.localdomain.

Can you run dscreate with "-v" to get the full stack trace?

Now dscreate does start the server to do some bootstrapping but then if start=False it will stop it at the end of the install.  So it does start it but it will stop it after it is installed.  I think in your case it's failing, so it never gets to the step where it stops the server.

I also doubled checked the code, if you set full_machine_name is does NOT override it.  So now sure what is going on.  Maybe try setting "strict_host_checking" to True in the "general" section and see if it complains about your host name.  And like I said the "-v" output should provide more info...

Thanks,

Mark

Regards,

Graham

—

--     389 Directory Server Development Team