In message <[email protected]>, "Poul-Henning Kamp" writes: >In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=rz1itfr5ekzrr9tfyi...@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.
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 [email protected] | 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 [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
