#47992 Silent installs should have a way to specify separate instances
Closed: wontfix 3 years ago by mreynolds. Opened 9 years ago by mreynolds.

Currently INF files/args can only handle a single instance of Directory Server - this prevents "setup-ds.pl --update" and register-ds-admin.pl from using INF files/args.


For example, in an .inf file:
{{{
[slapd-inst1]
RootDN="cn=dm1"
RootDNPwd=pwd1
[slapd-inst2]
RootDN="cn=dm2"
RootDNPwd=pwd2
}}}
on the command line:
{{{
setup-ds.pl -u slapd-inst1.RootDN="cn=dm1" slapd-inst2.RootDN="cn=dm2" ...
}}}

Per triage, push the target milestone to 1.3.6.

Metadata Update from @rmeggins:
- Issue set to the milestone: 1.3.6.0

7 years ago

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to review
- Issue close_status updated to: None

7 years ago

This is needed in order to support updating more than one instance at once, or to support some register-ds-admin use cases.

I think that there are better ways to handle this. We are rethinking how the admin runs, and we have a new python instance installer already that is potentially going to replace the perl soon. Even the way we handle the admin, rather than multiple instances, I want to push that the admin tree is on the same instance as the server, and even then, the new server is api extensible.

As well, updating is maybe not such a big deal as it was. We can do seamless upgrades of settings now in the server by changing libglobs.c, and upgrading other components, can be done in other ways I think. I think this is a solution for a problem, that we can eliminate in other ways.

For example, if we are better about handling our plugin configs on upgrade, we don't need to automatically run the upgrade tool, the admin can do it as needed. There is no guarantee of consistency inside of an rpm transaction, so we should allow the admin to intervene to upgrade settings (if even).

See, using the external tool for upgrades will completely block us using containers. We need to make the system work in a way where we can not guarantee an rpm transaction was run on upgrade with the db or dse.ldif accessible.

So I think sinking time into this is a waste, when we should be solving better problems IMO.

I'm not sure why you are bringing up RPMs in this context. Being able to specify multiple instances in a setup .inf file solves some problems related to register-ds-admin and/or setup-ds-admin, both of which are run outside the rpm transaction. In fact, they are intended to be run outside of a yum update entirely. If you think this is issue is obviated by the new admin/setup code, fine, please close it. If you think the presence of this issue in the list of other issues is going to distract from doing other setup/admin/cleanup work, then I guess go ahead and close it for that reason too. But your explanation as to why this issue is closed doesn't lead me to believe that you fully understand why it was an issue, nor how you propose to solve it.

We can leave this alone if we need to because it's related to the perl installer tools, but I think that our direction is not to continue to improve these as the python tools mature. It's a question of where our energy is best spent. I think that the day that we start using python by default instead of the perl tools, we can close this because it won't be relevant.

Again - I'm not saying we should continue to invest in the old perl tools, we should not. I'm not saying we should not push to get the python tools done. I'm just saying that there is an issue with certain setup/registration scenarios in silent install mode, which could be fixed by adding support to the setup .inf file format for multiple instances.

Are you planning to scrap support for .inf files? If not, and you have a better way to handle this scenario, that's fine.

Their format is changing in the new tools, but inf is still supported.

I think that the new admin itself may avoid this problem by it's design, rather than needing this, but I think we can leave this alone until we know for sure.

We should definitely support multiple instance silent installations. The new admin server is not going to be requirement in the future. It will be a standalone product, and we can not force people to install the admin server in order to get this functionality. This is not a difficult feature to add so I see no reason to scrap this issue. Just my opinion :)

Metadata Update from @firstyear:
- Custom field reviewstatus reset

7 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)

6 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1323

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata