Load VEXTs in manager #4172
Load VEXTs in manager #4172
Conversation
|
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. |
nigoroll
force-pushed
the
vext_early
branch
from
92c12f2
to
51447c4
Compare
I had another look. The problem is not that To allow VEXT VCAs but no VEXTs in mgt, we would need to move the It is my understanding that we have so far been operating under the principle of detecting configuration problems before even starting the child, in particular by test-loading the VCL. Do we want to (at least partly) give up this principle? One other example I see where loading VEXTs in mgt makes sense is a keyserver sidecar process. I think it should have a similar lifetime as mgt and be controlled by mgt. It needs to start with elevated privileges to load a wrapping key and then drop them. What would be reasons to for keeping VEXTs in the child only? |
|
I have added a change to this PR which is somehow unrelated, but needs the ability to plug an acceptor. See #4169 (comment) |
…y once This allows to re-use http1_new_session from custom implementations, in that it can serve as an entry point into the state machine also for existing sessions (without requiting 8 bytes of session workspace for each request served).
This allows code-reuse from custom implementations where only the deliver deliver callback differs.
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.
We add [%kind,] to the acceptor command line options to select the acceptor implementation. The syntax is now: [name=][%<kind>,][listen_address[,PROTO|,option=value,...]] Reasons are explained in varnishcache#4169
it actually just uses the TCP acceptor code, but tests plugging via an extension
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