Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
rsync::server and rsync::server::global were in kind of a nasty circular dependency relationship wherein neither could be invoked decisively by the other using resource-style includes, because a circular inclusion relationship arose that would at a minimum break unit tests.
Shifting tcpwrappers from global back into server untied most of this gordian knot, allowing data (e.g., address and port config) to be owned by one and passed to the other rather than circulated between them. This allows configuration to be passed authoritatively from the last point of user contact for server configuration out through the remainder of the module without the need for awkward data pathing to circumvent what should have been easy to do as a clean pass.
No parameters were removed from any directly user-callable class.
I still have additional contributions to make on this branch that will definitely break backwards-compatibility in several of the most common edge cases, but also further strengthen the module while still allowing for things like rsyncd and stunnel having different ports, bind-to addresses, and trusted nets. I stopped here because as far as I have been able to determine (including a thorough read of
simplib::lookup()
and less-thorough read of the simp_options module), nothing altered or added here is likely to break the majority of existing use cases.SIMP-10740 #close