Description of problem: Customer has several instances per server. Each uses a different ip address (server has several nics). The inbound communication works as expected. Instance 1 works on to x.x.x.a:389. Instance 2 works on x.x.x.b:389, ect. When the instances go to replicate, the communication follows the default route of the RHEL host. Version-Release number of selected component (if applicable): all How reproducible: consistent behavior Steps to Reproduce: 1.server with multiple ip/ vips 2.multiple databases on :389 and :686 - each inbound tied to a different ip/vip 3.setup replication Actual results: replication (outbound) traffic goes over default route Expected results: ability to select network Additional info: request comes from a large rhds customer.
(In reply to Rich Megginson from comment #11)
After some discussion with fche@redhat.com, we have come to the conclusion that we need to be able to call getaddrinfo(2)/bind(2) between the call to socket(2) and connect(2). Unfortunately, openldap provides a callback that can be used after the call to connect(2) (ldap_set_option(3) LDAP_OPT_CONNECT_CB). We might be able to use this to close the connection, then call socket(2) again, then getaddrinfo(2)/bind(2)/connect(2). If not, then we'll need to add some sort of post-socket/pre-connect callback to openldap.
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue close_status updated to: None - Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Custom field version adjusted to None - Issue tagged with: RFE
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/1942
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 - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.