Visibility of VCL source (Was: Re: [PATCH] expand includes)

Poul-Henning Kamp phk at
Tue Jul 22 11:16:37 CEST 2014

In message <69611.1406020117 at>, "Poul-Henning Kamp" writes:
>In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=rZ1iTfr5EKzrR9tFyi9Hw at>
>, Dag Haavi Finstad writes:
>>As discussed on the Stockholm VDD, here's a proposal for #1457.
>>The VCLs are output in the same order as they appear in the VCL
>>location/profiling table in the compiled VCL (the vcl->ref stuff used
>>in the VCL_trace records), so if someone wanted to do a VCL code
>>tracer thing, that should be possible.
>I'm not at all happy with the fact that we still dlopen() VCL's for
>  That exposes the master process in ways I don't like,
>even more so now we have VMODS which pull in strange libraries.
>One way to fix it is to accept that we cannot show the source
>unless the child process is running.  I can live with that.
>If that is not acceptable, we could fork a child of master to
>dlopen() the compiled VCL (we already do that for testing) and
>pull the source out of that.
>But all in all I prefer to make the child responsible, so that
>we don't dlopen() compiled VCL's unnecessarily.
>If we go that route, we can do as now, and only exposed it via
>VCL or we can expose the counters and VCL source via VSM to
>avoid the VCL overhead.

Sorry, meant: "... only expose it via CLI ..."

>The latter is probably best for interactive visuals, but does
>expose the VCL source without CLI auth check.  I'm not sure
>if that is OK.
>Input ?

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the varnish-dev mailing list