Visibility of VCL source (Was: Re: [PATCH] vcl.show expand includes)
Federico Schwindt
fgsch at lodoss.net
Tue Jul 22 17:33:36 CEST 2014
When there are multiple VCLs loaded would they all be exposed via VSM?
I think kicking off a child to do the work only when necessary would be
better and you get the auth check bonus.
On Tue, Jul 22, 2014 at 10:08 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:
> In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=
> rZ1iTfr5EKzrR9tFyi9Hw at mail.gmail.com>
> , 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
> vcl.show(). 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.
>
> 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.
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140722/c4b4acca/attachment-0001.html>
More information about the varnish-dev
mailing list