From slink at schokola.de Thu Aug 2 16:53:52 2012 From: slink at schokola.de (Nils Goroll) Date: Thu, 02 Aug 2012 18:53:52 +0200 Subject: [PATCHES] Fix build errors and sandbox bugs in the Solaris port In-Reply-To: <13166.1343661024@critter.freebsd.dk> References: <13166.1343661024@critter.freebsd.dk> Message-ID: <501AB0A0.30503@schokola.de> Hi Phk, > I have committed part 1, and generalized the idea in part 3 but > not attempted to implement the solaris sandbox with it, but I > hope it makes it easier to do so for you guys. Thanks for the refactoring, as always, your version of the same idea is cleaner. :) Here's a patch for the solaris sandbox, which also fixes a nit in mgt_sandbox.c Thanks, Nils -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-since-vcc-cc-are-running-with-privilege-seperation-n.patch URL: From slink at schokola.de Thu Aug 2 18:06:57 2012 From: slink at schokola.de (Nils Goroll) Date: Thu, 02 Aug 2012 20:06:57 +0200 Subject: [PATCHES] Fix build errors and sandbox bugs in the Solaris port In-Reply-To: <501AB0A0.30503@schokola.de> References: <13166.1343661024@critter.freebsd.dk> <501AB0A0.30503@schokola.de> Message-ID: <501AC1C1.2040303@schokola.de> Hi phk, testing the new sandbox code I noticed that the tmpdir should be owned by mgt_param.uid, otherwise unlinking the compiled .so will fail when setuid(mgt_param.uid) succeeds. Nils On 08/ 2/12 06:53 PM, Nils Goroll wrote: > Hi Phk, > >> I have committed part 1, and generalized the idea in part 3 but >> not attempted to implement the solaris sandbox with it, but I >> hope it makes it easier to do so for you guys. > > Thanks for the refactoring, as always, your version of the same idea is cleaner. :) > > Here's a patch for the solaris sandbox, which also fixes a nit in mgt_sandbox.c > > Thanks, Nils > > > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-give-away-the-tmpdir-to-the-privilege-seperation-use.patch URL: From geoff at uplex.de Sun Aug 5 12:13:01 2012 From: geoff at uplex.de (Geoff Simmons) Date: Sun, 05 Aug 2012 14:13:01 +0200 Subject: [PATCH] CLI "banner" command prints the version/revision string Message-ID: <501E634D.1020407@uplex.de> Hello all, The enclosed patch saves the version string in a vsb, which is retrieved in both version.c and mgt_cli.c for the "banner" command. Best, Geoff $ varnishadm -T 127.0.0.1:6082 banner ----------------------------- Varnish Cache CLI 1.0 ----------------------------- varnish-trunk revision f81aedd -sfile,-smalloc,-hcritbit Type 'help' for command list. Type 'quit' to close CLI session. -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 (ACHTUNG: neue Adresse) 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: banner.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 896 bytes Desc: OpenPGP digital signature URL: From phk at phk.freebsd.dk Mon Aug 6 08:13:44 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Aug 2012 08:13:44 +0000 Subject: [PATCH] CLI "banner" command prints the version/revision string In-Reply-To: Your message of "Sun, 05 Aug 2012 14:13:01 +0200." <501E634D.1020407@uplex.de> Message-ID: <58678.1344240824@critter.freebsd.dk> In message <501E634D.1020407 at uplex.de>, Geoff Simmons writes: >The enclosed patch saves the version string in a vsb, which is retrieved >in both version.c and mgt_cli.c for the "banner" command. I did it a little simpler: All the component strings are constant so there is no need for a VSB. Thanks! -- 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. From phk at phk.freebsd.dk Mon Aug 6 08:29:37 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Aug 2012 08:29:37 +0000 Subject: [PATCHES] Fix build errors and sandbox bugs in the Solaris port In-Reply-To: Your message of "Thu, 02 Aug 2012 18:53:52 +0200." <501AB0A0.30503@schokola.de> Message-ID: <68233.1344241777@critter.freebsd.dk> In message <501AB0A0.30503 at schokola.de>, Nils Goroll writes: >Thanks for the refactoring, as always, your version of the same idea is cleaner. :) > >Here's a patch for the solaris sandbox, which also fixes a nit in mgt_sandbox.c Committed. -- 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. From geoff at uplex.de Mon Aug 6 08:54:41 2012 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 06 Aug 2012 10:54:41 +0200 Subject: [PATCHES] Fix build errors and sandbox bugs in the Solaris port In-Reply-To: <68233.1344241777@critter.freebsd.dk> References: <68233.1344241777@critter.freebsd.dk> Message-ID: <501F8651.60404@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/ 6/12 10:29 AM, Poul-Henning Kamp wrote: > In message <501AB0A0.30503 at schokola.de>, Nils Goroll writes: > >> Thanks for the refactoring, as always, your version of the same >> idea is cleaner. :) >> >> Here's a patch for the solaris sandbox, which also fixes a nit in >> mgt_sandbox.c > > Committed. It's working on my machine. $ uname -a SunOS gsimmons 5.11 snv_134 i86pc i386 i86pc Solaris - -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 (ACHTUNG: neue Adresse) 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQH4ZRAAoJEOUwvh9pJNURy1UP/0VJ8QeVm9fGvSrzAjAAyRNM LqjsmGQfqBHemZ7mOPGriXH/QkQ+ybXPz6mst2cHp952PHnxPUrQ49CZHMWitEfL kdLrjAuYSvNOcvs2Sauj74yRe6X0n2H8rGOyhXM/2RRJ8EFuj89xph2PTLhiU1f0 eQ/pbO+onx4Zbh425kcE4GcknVtmCrcyLm7uP/m8RN2dd5Bn99dxaexkVPlqkhGY 7W8OuUDVJXGDrj7yEZHXOl1qHmw6r1JxYshf6nB4yhA8KF3dgI0BfrXaYFJeSHpP vnoMYPF1iB6QiqyeYrr9dXlntdG1Nfyx3Fyfe6K8VaKrUy6CpDd+29UrUuc+v9mK OGo80lKBCTQzl5tW5f1XHG9YT7aqTh2En5aUx/Tx1gAa9nVPWbao8J+sfeuO026P O1LgYlLHRXAdkW+RuQQkJ/aIHKkRwLbIv6sXFP8rdEeTaNwRjQukNlolO04jZ4+g saAZteGXvU7E+6VCm0cmCQLY1DbRyzc6Zrt22Xw4kFMS1ZgXt/jzXT/kErULMLK6 Xn6uYzyvgFhPq7IGxNCoX6pReGL5XFGoVcV930jKgM7hD3SbXU/VSPlCY3z6RgD8 MmosTkgRo7B51N1OSOToyBpMzazW+LKUAVGfQUf3y75jifZXWgyDSrVZKy9eVJT5 9S/M62JyaYYqXDyodvji =Vbg4 -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Mon Aug 6 09:23:21 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Aug 2012 09:23:21 +0000 Subject: Dynamic backends In-Reply-To: Your message of "Fri, 27 Jul 2012 09:21:43 +0200." Message-ID: <68560.1344245001@critter.freebsd.dk> In message , Per Buer writes: >We've gotten quite a bit of feedback on my blogpost outlining dynamic >backends. I don't think it is a good solution for a large number of reasons, but I will spare you the list (at least for now) because I suspect you will find my idea better: You are right that changing VCL is a hazzle, and mixing backends with VCL was probably a bad-ish idea, but it was also very convenient. I think the right solution is to bite the bullet and make backends first class objects which can either be instantiated statically in VCL, (like today) dynamically from the CLI or by VMODs on the fly. This allows us to move all directors to VMODS: import round_robin_director; sub vcl_init { backend.foobar = round_robin_director.new( // Not happy with passing params this way // a more useful syntax may be a good idea. // Possibly a type-tagged argv which the vmod // can complain about at compile time ? "host[1] = "192.168.60.1", "weight[1] = "12", "host[2] = "192.168.60.2", "weight[2] = "12", "host[3] = "192.168.60.3", "weight[3] = "24" ); } sub vcl_recv { set req.backend = backend.foobar; } The only real question that leaves behind, is what happens when you: sub vcl_recv { set req.backend = backend.foobar; } And there is no backend named foobar ? Today we can detect this at VCL compile time, but with dynamic backends it becomes a runtime error, and we should probably just fail the request with 50x. -- 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. From phk at phk.freebsd.dk Mon Aug 6 09:35:03 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 06 Aug 2012 09:35:03 +0000 Subject: [PATCHES] Fix build errors and sandbox bugs in the Solaris port In-Reply-To: Your message of "Thu, 02 Aug 2012 20:06:57 +0200." <501AC1C1.2040303@schokola.de> Message-ID: <68859.1344245703@critter.freebsd.dk> In message <501AC1C1.2040303 at schokola.de>, Nils Goroll writes: >testing the new sandbox code I noticed that the tmpdir should be owned by >mgt_param.uid, otherwise unlinking the compiled .so will fail when >setuid(mgt_param.uid) succeeds. I'm not sure I follow ? The .so file is unlinked from the mgt process with full privs, isn't it ? -- 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. From fgsch at lodoss.net Thu Aug 9 01:30:01 2012 From: fgsch at lodoss.net (Federico G. Schwindt) Date: Thu, 9 Aug 2012 02:30:01 +0100 Subject: [PATCH] Update tests Message-ID: <20120809023001.35bb057a1449f3414913c039@lodoss.net> debug.backend was removed. Update tests to reflect this. f.- diff --git a/bin/varnishtest/tests/v00006.vtc b/bin/varnishtest/tests/v00006.vtc index ca4c827..494007f 100644 --- a/bin/varnishtest/tests/v00006.vtc +++ b/bin/varnishtest/tests/v00006.vtc @@ -41,7 +41,7 @@ varnish v1 -expect n_backend == 2 varnish v1 -expect n_vcl_avail == 2 varnish v1 -expect n_vcl_discard == 0 -varnish v1 -cli "debug.backend" -cli "vcl.list" +varnish v1 -cli "vcl.list" # Discard the first VCL @@ -64,7 +64,7 @@ client c1 { # The workthread should have released its VCL reference now # but we need to tickle the CLI to notice -varnish v1 -cli "debug.backend" -cli "vcl.list" +varnish v1 -cli "vcl.list" varnish v1 -expect n_backend == 1 varnish v1 -expect n_vcl_avail == 1 diff --git a/bin/varnishtest/tests/v00012.vtc b/bin/varnishtest/tests/v00012.vtc index 285f2c1..e7c8d44 100644 --- a/bin/varnishtest/tests/v00012.vtc +++ b/bin/varnishtest/tests/v00012.vtc @@ -33,8 +33,6 @@ client c2 { expect resp.status == 503 } -run -varnish v1 -cli "debug.backend" - sema r2 sync 2 client c1 -wait From fgsch at lodoss.net Thu Aug 9 01:32:15 2012 From: fgsch at lodoss.net (Federico G. Schwindt) Date: Thu, 9 Aug 2012 02:32:15 +0100 Subject: [PATCH 1/2] Add OpenBSD support Message-ID: <20120809023215.28777ae2c5ce3bb54e0e25a4@lodoss.net> Trivial diff so I can compile varnish unchanged in OpenBSD. f.- diff --git a/autogen.sh b/autogen.sh index 07df626..d7e360d 100755 --- a/autogen.sh +++ b/autogen.sh @@ -15,6 +15,9 @@ FreeBSD) Linux) LIBTOOLIZE=libtoolize ;; +OpenBSD) + LIBTOOLIZE=libtoolize + ;; SunOS) LIBTOOLIZE=libtoolize ;; From fgsch at lodoss.net Thu Aug 9 01:45:59 2012 From: fgsch at lodoss.net (Federico G. Schwindt) Date: Thu, 9 Aug 2012 02:45:59 +0100 Subject: [PATCH 2/2] Add OpenBSD support Message-ID: <20120809024559.b61d3938ec0ef52aabd6c514@lodoss.net> With this all tests but one succeed in OpenBSD. As I've mentioned on irc, unless msync(2) is called a process reading from the underlying file might not see the same data as the process that mapped that file. I think having the msync here is harmless and should not affect performance since it's only required at startup but I'm happy to live with an ifdef. f.- diff --git a/bin/varnishd/mgt/mgt_shmem.c b/bin/varnishd/mgt/mgt_shmem.c index 79f8c41..ecce4c1 100644 --- a/bin/varnishd/mgt/mgt_shmem.c +++ b/bin/varnishd/mgt/mgt_shmem.c @@ -247,6 +247,9 @@ mgt_SHM_Create(void) (void)unlink(fnbuf); exit (-1); } + + /* Make sure changes are committed. */ + (void)msync(p, size, MS_SYNC); } /*-------------------------------------------------------------------- From phk at phk.freebsd.dk Thu Aug 9 08:06:55 2012 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 09 Aug 2012 08:06:55 +0000 Subject: [PATCH 2/2] Add OpenBSD support In-Reply-To: Your message of "Thu, 09 Aug 2012 02:45:59 +0100." <20120809024559.b61d3938ec0ef52aabd6c514@lodoss.net> Message-ID: <40777.1344499615@critter.freebsd.dk> In message <20120809024559.b61d3938ec0ef52aabd6c514 at lodoss.net>, "Federico G. S chwindt" writes: >With this all tests but one succeed in OpenBSD. > >As I've mentioned on irc, unless msync(2) is called a process >reading from the underlying file might not see the same data as the >process that mapped that file. I'm a bit surprised about this one, does this mean that OpenBSD still does not have a coherent buf/VM system ? -- 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. From martin at varnish-software.com Thu Aug 16 12:37:36 2012 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 16 Aug 2012 14:37:36 +0200 Subject: [PATCH] Log LRU attempts where no candidate objects were found, and add a varnishstat counter for these events. Message-ID: <1345120656-24800-1-git-send-email-martin@varnish-software.com> --- bin/varnishd/cache/cache_expire.c | 3 +++ include/tbl/vsc_f_main.h | 4 ++++ 2 files changed, 7 insertions(+) diff --git a/bin/varnishd/cache/cache_expire.c b/bin/varnishd/cache/cache_expire.c index 3d18d78..daf8f88 100644 --- a/bin/varnishd/cache/cache_expire.c +++ b/bin/varnishd/cache/cache_expire.c @@ -446,6 +446,9 @@ EXP_NukeOne(struct busyobj *bo, struct lru *lru) binheap_delete(exp_heap, oc->timer_idx); assert(oc->timer_idx == BINHEAP_NOIDX); VSC_C_main->n_lru_nuked++; + } else { + VSLb(bo->vsl, SLT_ExpKill, "LRU no candidates"); + VSC_C_main->n_lru_no_candidates++; } Lck_Unlock(&exp_mtx); Lck_Unlock(&lru->mtx); diff --git a/include/tbl/vsc_f_main.h b/include/tbl/vsc_f_main.h index d9c78ce..9aed160 100644 --- a/include/tbl/vsc_f_main.h +++ b/include/tbl/vsc_f_main.h @@ -314,6 +314,10 @@ VSC_F(n_lru_moved, uint64_t, 0, 'i', "N LRU moved objects", "" ) +VSC_F(n_lru_no_candidates, uint64_t, 0, 'c', + "LRU attemps with no candidates", + "Count of LRU attempts where no possible candidate objects were found" +) VSC_F(losthdr, uint64_t, 0, 'a', "HTTP header overflows", -- 1.7.9.5 From make.it.easy at gmail.com Fri Aug 31 13:48:29 2012 From: make.it.easy at gmail.com (Atanai Wuttisetpaiboon) Date: Fri, 31 Aug 2012 20:48:29 +0700 Subject: check response from varnish cache Message-ID: Hi, I am now start learning and thinking to use Varnish cache. I would like to know how can we know from the response whether the content is retrieved from the Varnish cache or from the web server? I have seen some cache devices, they returns HTTP AGE in HTTP header: - If Age is 0, it means the content is from web server - If Age is not 0 (greater than 0), means the content is from the cache device. I am not sure if Varnish cache has this ability? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jna at twitter.com Fri Aug 31 15:24:31 2012 From: jna at twitter.com (John Adams) Date: Fri, 31 Aug 2012 08:24:31 -0700 Subject: check response from varnish cache In-Reply-To: References: Message-ID: Just look at the X-Cache header. I believe this is in the default VCL, and it will return HIT or MISS depending if you hit the cache or not. -j On Fri, Aug 31, 2012 at 6:48 AM, Atanai Wuttisetpaiboon < make.it.easy at gmail.com> wrote: > Hi, > > I am now start learning and thinking to use Varnish cache. I would like to > know how can we know from the response whether the content is retrieved > from the Varnish cache or from the web server? > > I have seen some cache devices, they returns HTTP AGE in HTTP header: > - If Age is 0, it means the content is from web server > - If Age is not 0 (greater than 0), means the content is from the cache > device. > > I am not sure if Varnish cache has this ability? > > _______________________________________________ > 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: From make.it.easy at gmail.com Fri Aug 31 17:56:50 2012 From: make.it.easy at gmail.com (F) Date: Sat, 1 Sep 2012 00:56:50 +0700 Subject: check response from varnish cache In-Reply-To: References: Message-ID: <9EF39A7D-5EF0-412C-B2AE-FBF6E6811175@gmail.com> Can anyone confirm and show me the response in both cases? I have not yet using Varnish so I cannot try. F On 31 Aug 2555 BE, at 22:24, John Adams wrote: > Just look at the X-Cache header. I believe this is in the default VCL, and it will return HIT or MISS depending if you hit the cache or not. > > -j > > > On Fri, Aug 31, 2012 at 6:48 AM, Atanai Wuttisetpaiboon wrote: > Hi, > > I am now start learning and thinking to use Varnish cache. I would like to know how can we know from the response whether the content is retrieved from the Varnish cache or from the web server? > > I have seen some cache devices, they returns HTTP AGE in HTTP header: > - If Age is 0, it means the content is from web server > - If Age is not 0 (greater than 0), means the content is from the cache device. > > I am not sure if Varnish cache has this ability? > > _______________________________________________ > 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: