Setup-ds.pl has served us for a long time: But it's showing it's age.

It has some fragility in corner cases. We have to frequently shell out to other applications. It can be difficult to track down issues, and identify them. It's not laid out well.

This ticket will create and add an experimental python based ds-setup(.py).

Initially, it will not be installed and will be hidden so that it is not used.

The new installer is split into parts.

• ini config validation
• config validation
• preparation
• installation

This way we can assert, and validate all parts of the process before we make a single change to the system. This massively improves upon the process of setup-ds.pl, where we can assert system state early and rapidly.

Due to the design of the api there are many benefits.

Projects like freeipa will not need to write out an inf and call the ds-setup/setup-ds.pl. They can skip to 'create_from_args', which accepts a set of dictionaries which will configure the system. IE there is now a setup API available in lib389.

Other installers (such as ds-setup-rest) can now subclass the DsSetup. From there, ds setup is designed to trigger callbacks through out the installation process. This means that:

• ds ini config validation
• -> rest ini config
• config validation
• -> rest config validation
• preparation
• -> rest preparation
• installation
• -> installation

A failure for the rest admin to validate, prevents ds installing. failure for ds to validate prevents the admin installing. This means we have a clean, powerful way to extend the tools and installers of DS.

setup-ds.pl loads a lot of data by template replace / write / ldif2db. ds-setup does not.

ds-setup is designed to make the most minimal directory server possible, start it, and then use and trigger lib389 administration calls to configure the instance.

The opens the door to:

• Allowing admins to use more complex ldifs during the install (rather than just the text insertion style we already have)
• Install no backends or many backends. This is important for cloud / containers.
• Keep our dse.ldif as minimal as possible, while enriching lib389 as much as possible.
• Greater and more options avaliable for un-attended installations.

As this is experimental, I feel it should be reviewed and merged so that we can begin to test it more, and extend it. The next major step would be to allow unit tests from DirSrv.create() to use this api experimentally to really ensure that the DS created is correct.

Instances created with this tool at the moment can be removed with remove-ds.pl. In the future there will be a ds-remove(.py)

This tool is python 3 only at this time.

Note: Depends on #48820