Load VEXTs in manager #4172
Open
Load VEXTs in manager #4172
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'm very much in favor for this change, this also allows us to define transports (like proxy) as VEXTs (without hacking too much) |
|
», VEXTs need to be present in the manager for opening privileged ports etc.« This is simply not true. VEXT's get a chance to bite before privileges are dropped right after the fork(). |
|
bugwash: I apologized for my mistake on the privileges, I probably had too much in mind what the solaris jail does, and need to look again at the privilege separation stuff. |
we foresaw this when we added VEXTs: while storage VEXTs have been happy with loading in the worker process *), to support pluggable acceptors, VEXTs need to be present in the manager for opening privileged ports etc. *) There are two reasons why restricting VEXTs to the child worked for the (only?) existing storage VEXT: It does not insist on creating the storage file with elevated privileges, and, as far as VCL is concerned, the storage gets configured even if its code is not yet present (See STV_Config())
... to enable acceptor implementations as extensions (and also allow storage to make use of manager privileges, but for this we probably need a new or repurposed STV callback). One test adjustment was required: c3.vtc tests invalid -a usage, but did not set up a good working directory. Now that -a is processed later, the test ran into a working directory error instead of the expected acceptor error.
nigoroll
force-pushed
the
vext_early
branch
from
92c12f2
to
51447c4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We foresaw this when we added VEXTs: while storage VEXTs have been happy with loading in the worker process, to support pluggable acceptors, VEXTs need to be present in the manager for opening privileged ports etc.
An implementation of a pluggable excceptor as a VMOD can be found in https://github.com/nigoroll/varnish-cache/commits/plugable_acceptors_rebase/, which is based upon #3976