nsDS5ReplicaTransportInfo SSL vs TLS is not really clear, given that most libraries now support TLS as the default "SSL".
We should make this clear in nsDS5ReplicaTransportInfo by allowing:
ldaps -> SSL StartTLS -> TLS
Options. So that it's really clear what you are asking for when you configure it.
Metadata Update from @firstyear: - Issue set to the milestone: 1.3.7 backlog
Metadata Update from @firstyear: - Issue close_status updated to: None - Issue tagged with: Easyfix
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)
Metadata Update from @spichugi: - Issue assigned to spichugi
It is not difficult to fix and I've already started to go through the code and check the places with SSL and StartTLS.
But I think we need to discuss how we want to proceed here.
We have two options, at least: 1. Change 'SSL' to 'ldaps' and 'TLS' to 'StartTLS' directly. And then during the instance upgrade, we will take care of it (changing config values to the new ones in the existing instances) 2. Add 'ldaps' and 'StartTLS' but don't remove 'SSL' and 'TLS' for now. We can deprecate them in the later versions.
I think the second options is smoother. But if we have the upgrade mechanism and we have some exact policy for the cases like this - we should follow it.
Metadata Update from @spichugi: - Custom field reviewstatus adjusted to None
I prefer option two. We should be backwards compatible with older versions of DS. We should not have an upgrade script to change the existing agreements because if the customer needs to downgrade it will break those repl agmts.
@mreynolds We have a lot of things that fail on downgrade. TBH I think it's a bit of a high expectation to expect that downgrade will work when we add config parameters, add plugins, change defaults and more. Some things are easier than others to manage, but downgrades are an extreme case, and in a downgrade case you ALWAYS should be restoring your dse.ldif from a backup.
So I think that I would support option 2, with the migration to change the values, but I'd rather them be clearer. Right now we have a protocol AND a uri scheme. I think it would be better as:
As the options. These clearly communicate what we are doing.
e306a2d..ea033b6 master -> origin/master
Metadata Update from @spichugi: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
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/2168
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.