#5607 A failure in setup-ds.pl does not cause ipa install to fail
Closed: Duplicate Opened by firstyear.

  [2/42]: creating directory server instance
ipa         : CRITICAL failed to create ds instance Command ''/usr/sbin/setup-ds.pl' '--silent' '--logfile' '-' '-f' '/tmp/tmpc_aSj0' '--debug'' returned non-zero exit status 1
  [3/42]: adding default schema
  [4/42]: enabling memberof plugin
  [5/42]: enabling winsync plugin
  [6/42]: configuring replication version plugin
....
 [23/42]: adding default layout
ipa         : CRITICAL Failed to load bootstrap-template.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpJ6eL3X' '-H' 'ldap://avery.example.com:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpacGo13'' returned non-zero exit status 32
...
More failures.
}}
Expected result:
ipa-server-install should have failed to install at the moment the critical warning was encountered.

It is missing ipaserver-install.log, but looking at others logs the step '4/46' (enabling memberof plugin) is an online update. So step 2/42 may have failed because it already existed an instance.

Could it be triggered by a missing 'cleanup' phase ?

Looks as a dup for #2539 and #3720.

I trimmed the log because everything started to fail after that point.

If you look in the code:

./ipaserver/install/dsinstance.py

        if ipautil.file_exists(paths.SETUP_DS_PL):
            args = [paths.SETUP_DS_PL, "--silent", "--logfile", "-", "-f", inf_fd.name]
            root_logger.debug("calling setup-ds.pl")
        else:
            args = [paths.DS_NEWINST_PL, inf_fd.name]
            root_logger.debug("calling ds_newinst.pl")
        try:
            ipautil.run(args)
            root_logger.debug("completed creating ds instance")
        except ipautil.CalledProcessError as e:
            root_logger.critical("failed to create ds instance %s" % e)
        # check for open port 389 from now on
        self.open_ports.append(389)

Ipa does nothing with the CalledProcessError, even though setup-ds.pl has returned a non 0 exit status.

This is probably the dup of 2539, but it's also a trivial fix. You probably just need to call your "bail and clean up" handler in the except block.

closing as duplicate of the aforementioned bugs. And moving #2539 to 4.3.1.

Metadata Update from @firstyear:
- Issue assigned to someone
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

Metadata