From fgsch at lodoss.net Thu Apr 9 20:55:59 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Thu, 9 Apr 2015 21:55:59 +0100 Subject: [PATCH] Allow returning abandon from vcl_backend_error{} Message-ID: Hi, Currently if you want to have all your error handling in a single place, i.e. vcl_synth{}, and you end up in vcl_backend_error{} you have to either return retry and then abandon in vcl_backend_fetch{} or return deliver and in vcl_deliver{} return synth. I can't think of any reason for not allowing this so the attached patch lifts this restriction. Comments? OKs? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-returning-abandon-from-vcl_backend_error.patch Type: text/x-patch Size: 2499 bytes Desc: not available URL: From fgsch at lodoss.net Fri Apr 10 17:58:11 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Fri, 10 Apr 2015 18:58:11 +0100 Subject: [master] 15ec79c Concentrate the acceptor-setup-session code. In-Reply-To: <4450.1427445052@critter.freebsd.dk> References:

<68032.1426675779@critter.freebsd.dk> <73037.1426700405@critter.freebsd.dk> <4450.1427445052@critter.freebsd.dk> Message-ID: Yes, sorry. I was somewhat hasty when I sent this (I was boarding a plane). I'm not sure how we can get some metrics without implementing this though. Perhaps DocWilco has some numbers he can share? On Fri, Mar 27, 2015 at 8:30 AM, Poul-Henning Kamp wrote: > -------- > In message 9Ad6dOwf+z5aq3aFqROtzA8kdSowTOYgRRAMv05g at mail.gmail.com> > , Federico Schwindt writes: > > >Attached is a patch in that effect. > > > >I have no empirical evidence this will improve things but I believe Fastly > >and others are doing it with good results. > > As I understand the documentation of SO_REUSEPORT your patch is a no-op. > > See for instance: http://lwn.net/Articles/542629/ > > SO_REUSEPORT allows you to bind(2) multiple sockets to the same port > number[1]. > > Setting the option but not creating more sockets doesn't do anything. > > What we do fall somewhere in the middle between the two scenarios descriped > in the article above: We have a single acceptor thread per thread pool. > > I have no idea how that performs relative to having multiple sockets, but > I'd like to see some actual numbers before we start ripping things up. > > Poul-Henning > > [1] You can already do that with UDP under certain circumstances, but it > is not allowed for TCP. > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Apr 13 08:17:04 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 13 Apr 2015 10:17:04 +0200 Subject: Questions on backend allocations In-Reply-To: References: Message-ID: Hi, It turned out you couldn't properly create backends dynamically, or at least remove them. Please find attached a patch set that fixes that, and adds a "director" capability to the debug vmod with an initial test case. This is still incomplete, and I want to push this further. For example I've created a Backend_added log record, but nothing for deletion. Before I do anything else, I'll wait for feedback :) Cheers, Dridi PS. today I'm doing training and the customer is blocking IRC On Thu, Mar 19, 2015 at 12:26 AM, Dridi Boukelmoune wrote: > Hi, > > As discussed briefly during the last VDD in Hamburg, phk said that > everything should be in place to allow dynamic backend allocations > (ie. outside of pure VCL). > > I looked quickly at the code right after the VDD with fgs, and at the > time there was a couple backend-related commits that had just showed > up. But I came to the conclusion that you could only add/remove a > backend and a tcp pool in vcl_init and vcl_fini. > > Those operations can only be triggered by the CLI thread right now, so > it's not possible to programmatically add a backend at any arbitrary > time and still benefit from the existing facilities (stats, probes, > connection pools, etc). > > I haven't made any progress since then, so I'm asking first what the > comment was about. I think I misunderstood what it was supposed to > mean at the time. > > Also please find attached a tiny patch removing leftovers I found after the > VDD. > > Regards, > Dridi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-unsused-context-from-VRT-backend-functions.patch Type: text/x-patch Size: 2953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-new-Backend_added-log-event.patch Type: text/x-patch Size: 1379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-a-single-backend-director-to-the-debug-vmod.patch Type: text/x-patch Size: 6227 bytes Desc: not available URL: From dridi at varni.sh Mon Apr 13 10:17:15 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 13 Apr 2015 12:17:15 +0200 Subject: [PATCH] Allow returning abandon from vcl_backend_error{} In-Reply-To: References: Message-ID: Hi, This is kind of like how you may duplicate bereq manipulations between vcl_miss and vcl_pass with Varnish 3 (no there's vcl_backend_fetch). A current workaround would be to call custom vcl subs in both vcl_synth and vcl_backend_error. Otherwise the patch looks simple enough :) Dridi On Thu, Apr 9, 2015 at 10:55 PM, Federico Schwindt wrote: > Hi, > > Currently if you want to have all your error handling in a single place, > i.e. vcl_synth{}, and you end up in vcl_backend_error{} you have to either > return retry and then abandon in vcl_backend_fetch{} or return deliver and > in vcl_deliver{} return synth. > > I can't think of any reason for not allowing this so the attached patch > lifts this restriction. > > Comments? OKs? > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev From fgsch at lodoss.net Mon Apr 13 10:41:59 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 13 Apr 2015 11:41:59 +0100 Subject: [PATCH] Allow returning abandon from vcl_backend_error{} In-Reply-To: References:

Message-ID: They will need to be different subroutines though since the variables are different (resp vs beresp). This means they need to be in sync which adds extra complexity and is error prone IMO. On Mon, Apr 13, 2015 at 11:17 AM, Dridi Boukelmoune wrote: > Hi, > > This is kind of like how you may duplicate bereq manipulations between > vcl_miss and vcl_pass with Varnish 3 (no there's vcl_backend_fetch). > > A current workaround would be to call custom vcl subs in both > vcl_synth and vcl_backend_error. Otherwise the patch looks simple > enough :) > > Dridi > > On Thu, Apr 9, 2015 at 10:55 PM, Federico Schwindt > wrote: > > Hi, > > > > Currently if you want to have all your error handling in a single place, > > i.e. vcl_synth{}, and you end up in vcl_backend_error{} you have to > either > > return retry and then abandon in vcl_backend_fetch{} or return deliver > and > > in vcl_deliver{} return synth. > > > > I can't think of any reason for not allowing this so the attached patch > > lifts this restriction. > > > > Comments? OKs? > > > > _______________________________________________ > > 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 dridi at varni.sh Mon Apr 13 13:06:32 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 13 Apr 2015 15:06:32 +0200 Subject: [PATCH] Allow returning abandon from vcl_backend_error{} In-Reply-To: References:

Message-ID: On Mon, Apr 13, 2015 at 12:41 PM, Federico Schwindt wrote: > They will need to be different subroutines though since the variables are > different (resp vs beresp). I didn't think about that, in this case yes you can't implement a single error handling without duplication. > This means they need to be in sync which adds extra complexity and is error > prone IMO. Nevertheless, I still find your patch OK. > On Mon, Apr 13, 2015 at 11:17 AM, Dridi Boukelmoune wrote: >> >> Hi, >> >> This is kind of like how you may duplicate bereq manipulations between >> vcl_miss and vcl_pass with Varnish 3 (no there's vcl_backend_fetch). >> >> A current workaround would be to call custom vcl subs in both >> vcl_synth and vcl_backend_error. Otherwise the patch looks simple >> enough :) >> >> Dridi >> >> On Thu, Apr 9, 2015 at 10:55 PM, Federico Schwindt >> wrote: >> > Hi, >> > >> > Currently if you want to have all your error handling in a single place, >> > i.e. vcl_synth{}, and you end up in vcl_backend_error{} you have to >> > either >> > return retry and then abandon in vcl_backend_fetch{} or return deliver >> > and >> > in vcl_deliver{} return synth. >> > >> > I can't think of any reason for not allowing this so the attached patch >> > lifts this restriction. >> > >> > Comments? OKs? >> > >> > _______________________________________________ >> > varnish-dev mailing list >> > varnish-dev at varnish-cache.org >> > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Mon Apr 13 19:57:12 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Apr 2015 19:57:12 +0000 Subject: Varnish jails, priv-sep, packaging etc. Message-ID: <92310.1428955032@critter.freebsd.dk> I have spent time over Easter thinking about the jail/priv-sep thing, and in particular about the child process. (All of this applies only when varnishd is started as root.) Assume the worker process has been possesed. How can we prevent it from making the possession persistent ? For starters it should not be able to manipulate the compiled VCL shlib files. Today we use varnish:varnish ($params) for all the privsep subprocesses (ie: VCC/CC/DLOPEN/WORKER) This means that a possesed worker process in principle can replace the compiled VCL shlib files (because permissions allow CC to write them.) That could be remedied by changing the ownership of the -n directory and having the VCC/CC/DLOPEN operate out of a varnish:varnish owned subdirectory. But the possesed worker could just continously scan the -n directory and jump in when a VCL compilation was happening and corrupt the result. This limits the opportunities somewhat, but it doesn't close the hole. There is also the general question of file access, I don't think it is safe to assume that the worker should have access to anything VCC or CC have access to. This argues strongly for a separate uid for the worker process. The next question is the ownership of the default secret file. If people specify one with -S it is not our problem, but the default config it is. The worker should certainly not have access to this file and should absolutely not be able to write or replace it, which it can today because the -n directory is varnish:varnish. So the result I come up with is the following: Assume that varnishd is started as root:wheel Assume that we have a "varnish" group and "vadmin" and "vrun" users. -n directory root:varnish 755 We cannot make it 750, because then admins with wheel group can not get to the secret/vsm files. _.secret root:wheel 440 _.vsm vadmin:varnish 644 vcl$shlib vadmin:varnish 750 Subprocesses VCC and CC runs as vadmin:varnish. The master process creates a temporary compilation subdirectory under ${-n} with vadmin:varnish 750 and once the shlib is done, moves it up to ${-n} and changes m:o:g Subprocesses DLOPEN and WORKER runs as vrun:varnish and therefore cannot read the _.secret file, and cannot write or replace vcl shlib files. In addition: The -j arguments "ccgroup" is bestowed on the CC process The -j argument "secretgroup" overrides the primary group from the master process for the _secret file (Allowing it to be set for instance to "operator"). I have given up on using "nobody" instead of "vrun" for two reasons: First "nobody" is used for all sorts of stuff, and it's only a matter of time before there is an unintended consequence of that. But more importantly, by having a specific uid for the worker process, we give admins a way to control access to files VMODs needs, GEO-IP databases etc. etc, and it makes it possible to isolate directories which VMODs can create and write files to -- "nobody" would be very inappropriate for that. So is this acceptable from a packaging perspective ? What should we call the users ? The vadmin one could simply be "varnish", but what do we call the vrun user ? I think we have to respect the historical 7-char limit so "varnish-run" is out of reach, and "vrun" is only logical to VTLA afficionadios like us. Comments, inputs, ideas ? -- 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 stanhope at gmail.com Tue Apr 14 11:06:45 2015 From: stanhope at gmail.com (Phil Stanhope) Date: Tue, 14 Apr 2015 07:06:45 -0400 Subject: varnish-dev Digest, Vol 109, Issue 4 In-Reply-To: References: Message-ID: > Date: Mon, 13 Apr 2015 19:57:12 +0000 > From: Poul-Henning Kamp > To: varnish-dev at varnish-cache.org > Subject: Varnish jails, priv-sep, packaging etc. > Message-ID: <92310.1428955032 at critter.freebsd.dk> > Content-Type: text/plain; charset="us-ascii" > > I have spent time over Easter thinking about the jail/priv-sep thing, > and in particular about the child process. > > (All of this applies only when varnishd is started as root.) > > Assume the worker process has been possesed. > > How can we prevent it from making the possession persistent ? > > For starters it should not be able to manipulate the compiled VCL > shlib files. > > Today we use varnish:varnish ($params) for all the privsep subprocesses > (ie: VCC/CC/DLOPEN/WORKER) > > This means that a possesed worker process in principle can replace > the compiled VCL shlib files (because permissions allow CC to write them.) > > That could be remedied by changing the ownership of the -n directory > and having the VCC/CC/DLOPEN operate out of a varnish:varnish owned > subdirectory. > > But the possesed worker could just continously scan the -n directory > and jump in when a VCL compilation was happening and corrupt the result. > This limits the opportunities somewhat, but it doesn't close the hole. > > There is also the general question of file access, I don't think it is > safe to assume that the worker should have access to anything VCC or CC > have access to. > > This argues strongly for a separate uid for the worker process. > > > The next question is the ownership of the default secret file. If people > specify one with -S it is not our problem, but the default config it is. > > The worker should certainly not have access to this file and > should absolutely not be able to write or replace it, which it can today > because the -n directory is varnish:varnish. > > > So the result I come up with is the following: > > Assume that varnishd is started as root:wheel > > Assume that we have a "varnish" group and "vadmin" and "vrun" users. > > -n directory root:varnish 755 > We cannot make it 750, because then admins > with wheel group can not get to the secret/vsm > files. > > _.secret root:wheel 440 > > _.vsm vadmin:varnish 644 > > vcl$shlib vadmin:varnish 750 > > Subprocesses VCC and CC runs as vadmin:varnish. The master process creates > a temporary compilation subdirectory under ${-n} with vadmin:varnish 750 > and once the shlib is done, moves it up to ${-n} and changes m:o:g > > Subprocesses DLOPEN and WORKER runs as vrun:varnish and therefore cannot > read the _.secret file, and cannot write or replace vcl shlib files. > > In addition: > > The -j arguments "ccgroup" is bestowed on the CC process > > The -j argument "secretgroup" overrides the primary group > from the master process for the _secret file (Allowing it > to be set for instance to "operator"). > > I have given up on using "nobody" instead of "vrun" for two reasons: > > First "nobody" is used for all sorts of stuff, and it's only a matter > of time before there is an unintended consequence of that. > Agreed > > But more importantly, by having a specific uid for the worker process, > we give admins a way to control access to files VMODs needs, GEO-IP > databases etc. etc, and it makes it possible to isolate directories > which VMODs can create and write files to -- "nobody" would be very > inappropriate for that. > > Agreed > So is this acceptable from a packaging perspective ? > > I don't see why not. > What should we call the users ? > > The vadmin one could simply be "varnish", but what do we call the > vrun user ? I think we have to respect the historical 7-char limit > so "varnish-run" is out of reach, and "vrun" is only logical to VTLA > afficionadios like us. > vrun. There is a long history from my perspective of naming like this. It's straightforward and states the purpose in the name. > Comments, inputs, ideas ? > > -- > 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 > > End of varnish-dev Digest, Vol 109, Issue 4 > ******************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Tue Apr 14 22:23:50 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 15 Apr 2015 00:23:50 +0200 Subject: Questions on backend allocations In-Reply-To: References: Message-ID: Hi, It turns out my trainees were so quiet during exercises that I could explore this a bit more. I have come to the point where you don't need a backend declaration in your VCL, as long as you have a director that will dynamically create one. Once backend check was deferred to *after* vcl_init, it made very easy to allow a director to become the default backend. See the test d00007.vtc for a pure dynamic backend: varnish v1 -vcl { import ${vmod_debug}; sub vcl_init { new s1 = debug.dyn("${s1_addr}", "${s1_port}"); } } -start See the test d00008.vtc for a director as the default: varnish v1 -vcl+backend { import ${vmod_directors}; # no need for `set bereq.backend = default;` sub vcl_init { new default = directors.round_robin(); default.add_backend(s1); default.add_backend(s2); } } -start There are still caveats with the current implementation, and it's still not enough to implement a new dns director. Dynamically created backend won't receive events, which is not a problem *so far* since we can't pass probes to VMODs yet. Instead of emitting per-backend code for events, it could rely on backend_find() to fire events on both static and dynamic backends. Comments? Cheers, Dridi On Mon, Apr 13, 2015 at 10:17 AM, Dridi Boukelmoune wrote: > Hi, > > It turned out you couldn't properly create backends dynamically, or at > least remove them. Please find attached a patch set that fixes that, > and adds a "director" capability to the debug vmod with an initial > test case. This is still incomplete, and I want to push this further. For > example I've created a Backend_added log record, but nothing for > deletion. > > Before I do anything else, I'll wait for feedback :) > > Cheers, > Dridi > > PS. today I'm doing training and the customer is blocking IRC -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Rename-static-function-VCL_Load-to-vcl_load.patch Type: text/x-patch Size: 1474 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Defer-backend-existence-check-after-vcl_init.patch Type: text/x-patch Size: 3030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-VCL-doesn-t-require-static-backends-anymore.patch Type: text/x-patch Size: 2894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Built-in-directors-now-register-themselves.patch Type: text/x-patch Size: 4752 bytes Desc: not available URL: From varnish at bsdchicks.com Wed Apr 15 00:13:21 2015 From: varnish at bsdchicks.com (Rogier 'DocWilco' Mulhuijzen) Date: Wed, 15 Apr 2015 00:13:21 +0000 Subject: Varnish jails, priv-sep, packaging etc. In-Reply-To: <92310.1428955032@critter.freebsd.dk> References: <92310.1428955032@critter.freebsd.dk> Message-ID: On Mon, Apr 13, 2015 at 12:58 PM Poul-Henning Kamp phk at phk.freebsd.dk wrote: But the possesed worker could just continously scan the -n directory > and jump in when a VCL compilation was happening and corrupt the result. > This limits the opportunities somewhat, but it doesn't close the hole. > Yup, that is indeed scary. This argues strongly for a separate uid for the worker process. > Totally agreed. The worker should certainly not have access to this file and > should absolutely not be able to write or replace it, which it can today > because the -n directory is varnish:varnish. > Oh cripes, I hadn?t thought of that at all. -n directory root:varnish 755 > We cannot make it 750, because then admins > with wheel group can not get to the secret/vsm > files. > There?s a case to be made for adding those admins to the varnish group, but I don?t think it?s a big deal, as long as we nail down things within the directory. On the other hand, we could move the secret out of the directory, and use -n + _secret instead of -n + /_secret. _.secret root:wheel 440 > We write this before dropping privs, and don?t need to read it at all, right? _.vsm vadmin:varnish 644 > While we?re on the subject of security, I don?t think _.vsm should be world readable. There can be a ton of very valuable information in the VSM, like Cookie headers. Most of your email talks about the worker getting compromised, but you mentioned nobody. And there are possibly other processes running that are exposed to the outside world. Either because they talk to the network, or they are exposed through the world through Varnish. Requiring users to be part of the varnish group to be able to use VSM consuming utilities isn?t a stretch of the imagination. And if we do that, making the directory 750 makes a little more sense too, since they already need to be in the group to do much useful things with Varnish. What should we call the users ? > insert 2 hard things in software joke here The vadmin one could simply be "varnish", but what do we call the > vrun user ? I think we have to respect the historical 7-char limit > so "varnish-run" is out of reach, and "vrun" is only logical to VTLA > afficionadios like us. > I like using varnish for the vadmin part. Less change from a packaging/sysadmin perspective. As for vrun, vworker comes to mind. Or maybe vunpriv But I suck at naming, so I hope someone has brilliant ideas. Cheers, Doc ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Wed Apr 15 05:40:01 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 15 Apr 2015 07:40:01 +0200 Subject: Varnish jails, priv-sep, packaging etc. In-Reply-To: References: <92310.1428955032@critter.freebsd.dk> Message-ID: > As for vrun, vworker comes to mind. Or maybe vunpriv More straightforward maybe: vcache? From phk at phk.freebsd.dk Wed Apr 15 11:45:34 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 15 Apr 2015 11:45:34 +0000 Subject: Varnish jails, priv-sep, packaging etc. In-Reply-To: References: <92310.1428955032@critter.freebsd.dk> Message-ID: <258.1429098334@critter.freebsd.dk> -------- In message , "Rogier 'DocWilco' Mulhuijzen" writes: >There's a case to be made for adding those admins to the varnish >group, but I don't think it's a big deal, as long as we nail down things >within the directory. That would make gid=varnish the general restrictor for acces, such that it could also be used for VCL files etc. >On the other hand, we could move the secret out of the directory, and use >-n + _secret instead of -n + /_secret. You can put the secret file wherever you like (and have as many copies as you like) this is only about when people do not give a -S. I think keeping it in the -n directory makes sense, and giving it the same privs (uid/gid) as varnishd was started with is a good place to start. >We write this before dropping privs, and don't need to read it at all, >right? Wrong, we need to read it to authenticate every single CLI connection. (Remember you can change the content of the secret file on the fly if you want), but the master can re-raise privs (and now does). > _.vsm vadmin:varnish 644 >> >While we're on the subject of security, I don't think _.vsm should be world >readable. There can be a ton of very valuable information in the VSM, like >Cookie headers. Most of your email talks about the worker getting >compromised, but you mentioned nobody. And there are possibly other >processes running that are exposed to the outside world. Either because >they talk to the network, or they are exposed through the world through >Varnish. So 640 + vadmin:varnish ? >And if we do that, making the directory 750 makes a little more sense too, >since they already need to be in the group to do much useful things with >Varnish. That would be consistent, but what does everybody else say ? >I like using varnish for the vadmin part. Less change from a >packaging/sysadmin perspective. Agree. Dridi's suggestion of "vcache" is better than my "vrun". -- 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 varnish at bsdchicks.com Wed Apr 15 16:20:25 2015 From: varnish at bsdchicks.com (Rogier 'DocWilco' Mulhuijzen) Date: Wed, 15 Apr 2015 16:20:25 +0000 Subject: Varnish jails, priv-sep, packaging etc. In-Reply-To: <258.1429098334@critter.freebsd.dk> References: <92310.1428955032@critter.freebsd.dk> <258.1429098334@critter.freebsd.dk> Message-ID: On Wed, Apr 15, 2015 at 6:18 AM Poul-Henning Kamp wrote: > That would make gid=varnish the general restrictor for acces, such that > it could also be used for VCL files etc. > Yup, I think it's a very reasonable yet safe restriction. > You can put the secret file wherever you like (and have as many copies > as you like) this is only about when people do not give a -S. > > I think keeping it in the -n directory makes sense, and giving it the > same privs (uid/gid) as varnishd was started with is a good place to start. > Yeah, I was thinking it might work well as a default, but if we go with gid=varnish being needed for the tools, scratch making the default something else. So 640 + vadmin:varnish ? (_.vsm) > Yes. That would be consistent, but what does everybody else say ? > Quite. Anyone? :) Dridi's suggestion of "vcache" is better than my "vrun". > I agree. It's way more recognizable as being varnish related than "vrun" or "vworker". -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Wed Apr 15 17:31:45 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 15 Apr 2015 19:31:45 +0200 Subject: Questions on backend allocations In-Reply-To: References:

Message-ID: Hi, Last day of training, and probably the last patch set regarding dynamic backends operations (only during vcl.* commands). I'm almost satisfied with this batch, and it's basically all non disruptive changes I could do to make dynamic backends work to some extent. Cheers, Dridi On Wed, Apr 15, 2015 at 12:23 AM, Dridi Boukelmoune wrote: > Hi, > > It turns out my trainees were so quiet during exercises that I could > explore this a bit more. > > I have come to the point where you don't need a backend declaration in > your VCL, as long as you have a director that will dynamically create > one. Once backend check was deferred to *after* vcl_init, it made very > easy to allow a director to become the default backend. > > See the test d00007.vtc for a pure dynamic backend: > > varnish v1 -vcl { > import ${vmod_debug}; > > sub vcl_init { > new s1 = debug.dyn("${s1_addr}", "${s1_port}"); > } > } -start > > See the test d00008.vtc for a director as the default: > > varnish v1 -vcl+backend { > import ${vmod_directors}; > > # no need for `set bereq.backend = default;` > sub vcl_init { > new default = directors.round_robin(); > default.add_backend(s1); > default.add_backend(s2); > } > } -start > > There are still caveats with the current implementation, and it's still not > enough to implement a new dns director. Dynamically created backend > won't receive events, which is not a problem *so far* since we can't pass > probes to VMODs yet. Instead of emitting per-backend code for events, > it could rely on backend_find() to fire events on both static and dynamic > backends. > > Comments? > > Cheers, > Dridi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Fix-comment-in-a-test-case.patch Type: text/x-patch Size: 785 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Rename-backend_find-to-VBE_Find-and-make-it-public.patch Type: text/x-patch Size: 2434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Fire-events-to-all-the-backends-of-the-active-VCL.patch Type: text/x-patch Size: 7759 bytes Desc: not available URL: From bilbo at hobbiton.org Wed Apr 15 22:20:35 2015 From: bilbo at hobbiton.org (Leif Pedersen) Date: Wed, 15 Apr 2015 17:20:35 -0500 Subject: Varnish jails, priv-sep, packaging etc. In-Reply-To: References: <92310.1428955032@critter.freebsd.dk> <258.1429098334@critter.freebsd.dk> Message-ID: On Wed, Apr 15, 2015 at 11:20 AM, Rogier 'DocWilco' Mulhuijzen < varnish at bsdchicks.com> wrote: > Dridi's suggestion of "vcache" is better than my "vrun". >> > > I agree. It's way more recognizable as being varnish related than "vrun" > or "vworker". > Spell it out: "varnishcache"? Or are there actually relevant systems that still can't handle more than 8 bytes? (I hate to feel like I'm bikeshedding. I don't intend any statement about what the words are, just suggesting that they not be abbreviated.) -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Wed Apr 15 22:43:58 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 15 Apr 2015 22:43:58 +0000 Subject: Varnish jails, priv-sep, packaging etc. In-Reply-To: References: <92310.1428955032@critter.freebsd.dk> <258.1429098334@critter.freebsd.dk>

Message-ID: <11494.1429137838@critter.freebsd.dk> -------- In message , Leif Pedersen writes: >Spell it out: "varnishcache"? Or are there actually relevant systems that >still can't handle more than 8 bytes? Yes, there are... -- 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 Thu Apr 16 15:17:30 2015 From: geoff at uplex.de (Geoff Simmons) Date: Thu, 16 Apr 2015 17:17:30 +0200 Subject: [PATCH] restore the -r option to varnishncsa Message-ID: <552FD28A.5020005@uplex.de> Hello all, I had been using varnishncsa -r for testing in Varnish 3 -- for a tool whose output should be the same as varnishncsa in the default case -- and I'd like have it back for Varnish 4. Obviously not widespread use case, but since the patch is a one-liner, and everything else seems to work fine, I'd say that it does no harm. Thanks, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: ncsa_r.patch Type: text/x-patch Size: 315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From martin at varnish-software.com Thu Apr 16 16:07:24 2015 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 16 Apr 2015 18:07:24 +0200 Subject: [PATCH] restore the -r option to varnishncsa In-Reply-To: <552FD28A.5020005@uplex.de> References: <552FD28A.5020005@uplex.de> Message-ID: I have no objections. Martin On Apr 16, 2015 17:18, "Geoff Simmons" wrote: > Hello all, > > I had been using varnishncsa -r for testing in Varnish 3 -- for a tool > whose output should be the same as varnishncsa in the default case -- > and I'd like have it back for Varnish 4. > > Obviously not widespread use case, but since the patch is a one-liner, > and everything else seems to work fine, I'd say that it does no harm. > > > Thanks, > Geoff > -- > ** * * UPLEX - Nils Goroll Systemoptimierung > > Scheffelstra?e 32 > 22301 Hamburg > > Tel +49 40 2880 5731 > Mob +49 176 636 90917 > Fax +49 40 42949753 > > http://uplex.de > > _______________________________________________ > 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 fgsch at lodoss.net Sat Apr 18 17:14:40 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Sat, 18 Apr 2015 18:14:40 +0100 Subject: [PATCH] Change hash_data() input type to BLOB Message-ID: Hi, I had some time in my recent flights so I decided to give it a shot. As discussed at VDD15Q1, this changes the hash_data input to BLOB and adds automatic conversion from STRING to BLOB. There are a few downsides with this approach: 1. Every time we call hash_data() on something else than a BLOB we'll perform the conversion. If we assume that most people will not hash the body (a fair assumption I believe) we're doing extra work that only favours a minority, penalising the rest. 2. Adds more pressure to the already tight workspace. I guess we could use something else here if required. The other thing that bothers me somewhat is the naming behind the BLOBs, vmod_priv. If BLOBs will become a first class citizen we should rename it to something that is not coupled to vmods. This is regardless of the direction we take. A better alternative would be to teach vcc to issue two different calls depending on the input, e.g. for BLOBs it will use VRT_hashblob(), for anything else use VRT_hashstring(), so point 1 and 2 only affect users of hash_data(req.body). Comments? OKs? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-hash_data-input-type-to-BLOB.patch Type: text/x-patch Size: 8329 bytes Desc: not available URL: From fgsch at lodoss.net Sat Apr 18 17:30:17 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Sat, 18 Apr 2015 18:30:17 +0100 Subject: [PATCH] Expose the request body length to vcl_recv{} Message-ID: Another patch while on the plane. As discussed at VDD15Q1 this exposes the request body length via req.bodylen. A few open questions / observations: 1. This will only set the length after std.cache_req_body(). We might want to return content-length if std.cache_req_body() was not previously called. I suppose some people might want to use it for other purposes than retrying and if someone forgets calling cache_req_body() he/she might mistakenly believe that there is no body. OTOH exposing this without curation might be a bad idea. 2. This is only available in vcl_recv{}. Maybe it makes sense to expose this to client and/or the backend side. Comments? OKs? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Expose-the-request-body-length-to-vcl_recv.patch Type: text/x-patch Size: 2668 bytes Desc: not available URL: From phk at phk.freebsd.dk Mon Apr 20 04:54:22 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2015 04:54:22 +0000 Subject: busy week... Message-ID: <3458.1429505662@critter.freebsd.dk> I'll be away from Internet most of this week, but aim to get at some patches as time allows. Please give the new features in -trunk a good beating before we call it 4.1... -- 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 Apr 20 05:50:16 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2015 05:50:16 +0000 Subject: [PATCH] Change hash_data() input type to BLOB In-Reply-To: References: Message-ID: <4276.1429509016@critter.freebsd.dk> -------- In message , Federico Schwindt writes: >I had some time in my recent flights so I decided to give it a shot. >As discussed at VDD15Q1, this changes the hash_data input to BLOB and adds >automatic conversion from STRING to BLOB. > >There are a few downsides with this approach: Yes, that's been holding me from doing what you have done. >A better alternative would be to teach vcc to issue two different calls >depending on the input, e.g. for BLOBs it will use VRT_hashblob(), for >anything else use VRT_hashstring(), so point 1 and 2 only affect users of >hash_data(req.body). That's by far my preference and it becomes non-messy if we insist that you can never get vcc_Expr() to do anything with a BLOB, apart from returning it to you. That means that we will not do things like BLOB = BLOB + BLOB but we can do stuff like: BLOB = std.blob_concat(BLOB, blob("Hello World")) In practice we would need to pass a flag to vcc_Expr() saying "I want a FOO but BLOB is also OK" and I have a hard time seeing FOO take any other value than STRING/STRING_LIST. (The clean solution is to turn enum var_type into a bitmap, if anybody feels like 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 phk at phk.freebsd.dk Mon Apr 20 05:51:28 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2015 05:51:28 +0000 Subject: [PATCH] Expose the request body length to vcl_recv{} In-Reply-To: References: Message-ID: <4312.1429509088@critter.freebsd.dk> -------- In message , Federico Schwindt writes: >1. This will only set the length after std.cache_req_body(). We might want >to return content-length if std.cache_req_body() was not previously called. >I suppose some people might want to use it for other purposes than retrying >and if someone forgets calling cache_req_body() he/she might mistakenly >believe that there is no body. OTOH exposing this without curation might be >a bad idea. We need a magic value for "unknown" no matter what we do, with chunked req.body we have no idea until it is cached. -- 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 Apr 20 18:55:02 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2015 18:55:02 +0000 Subject: [PATCH] Change hash_data() input type to BLOB In-Reply-To: <4276.1429509016@critter.freebsd.dk> References: <4276.1429509016@critter.freebsd.dk> Message-ID: <5734.1429556102@critter.freebsd.dk> -------- In message <4276.1429509016 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >In practice we would need to pass a flag to vcc_Expr() saying "I want >a FOO but BLOB is also OK" and I have a hard time seeing FOO take >any other value than STRING/STRING_LIST. Actually... Isn't this where we just add a std.hash_blob(BLOB) Function ? -- 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 Mon Apr 20 20:27:22 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 20 Apr 2015 21:27:22 +0100 Subject: [PATCH] Change hash_data() input type to BLOB In-Reply-To: <5734.1429556102@critter.freebsd.dk> References: <4276.1429509016@critter.freebsd.dk> <5734.1429556102@critter.freebsd.dk> Message-ID: Duh! New diff attached. Documentation and tests remaining. Something like this? Should we keep hash_data() or rename it to hash_string() or something similar? On Mon, Apr 20, 2015 at 7:55 PM, Poul-Henning Kamp wrote: > -------- > In message <4276.1429509016 at critter.freebsd.dk>, "Poul-Henning Kamp" > writes: > > >In practice we would need to pass a flag to vcc_Expr() saying "I want > >a FOO but BLOB is also OK" and I have a hard time seeing FOO take > >any other value than STRING/STRING_LIST. > > Actually... > > Isn't this where we just add a > > std.hash_blob(BLOB) > > Function ? > > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hash_blob.patch Type: text/x-patch Size: 3768 bytes Desc: not available URL: From phk at phk.freebsd.dk Mon Apr 20 20:33:22 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2015 20:33:22 +0000 Subject: [PATCH] Change hash_data() input type to BLOB In-Reply-To: References: <4276.1429509016@critter.freebsd.dk> <5734.1429556102@critter.freebsd.dk> Message-ID: <8043.1429562002@critter.freebsd.dk> -------- In message , Federico Schwindt writes: >Duh! New diff attached. Documentation and tests remaining. Something like >this? I would prefer to put it in vmod_std, rather than special-case it in VCC... >Should we keep hash_data() or rename it to hash_string() or something >similar? I would just leave that alone, and add std.hash_blob() for the special use-cases. -- 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 Mon Apr 20 21:15:29 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Mon, 20 Apr 2015 22:15:29 +0100 Subject: [PATCH] Change hash_data() input type to BLOB In-Reply-To: <8043.1429562002@critter.freebsd.dk> References: <4276.1429509016@critter.freebsd.dk> <5734.1429556102@critter.freebsd.dk> <8043.1429562002@critter.freebsd.dk> Message-ID: Updated. On Mon, Apr 20, 2015 at 9:33 PM, Poul-Henning Kamp wrote: > -------- > In message < > CAJV_h0bcyLOktmbeg8xm35Z3ep_LrMWK4sMdYVuUHn-NnM5qaw at mail.gmail.com> > , Federico Schwindt writes: > > >Duh! New diff attached. Documentation and tests remaining. Something like > >this? > > I would prefer to put it in vmod_std, rather than special-case > it in VCC... > > >Should we keep hash_data() or rename it to hash_string() or something > >similar? > > I would just leave that alone, and add std.hash_blob() for the special > use-cases. > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hash_blob_v2.patch Type: text/x-patch Size: 3937 bytes Desc: not available URL: From fgsch at lodoss.net Tue Apr 21 06:55:52 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 21 Apr 2015 07:55:52 +0100 Subject: [PATCH] Expose the request body length to vcl_recv{} In-Reply-To: <4312.1429509088@critter.freebsd.dk> References: <4312.1429509088@critter.freebsd.dk> Message-ID: Right, Arianna pointed that too. She suggested: if (ctx->req->req_body_status != REQ_BODY_CACHED) { VSLb(ctx->vsl, SLT_VCL_Error, "Unbuffered req.body"); return (-1); } Do we want to do something like that only if content_length is 0 or regardless if it's not buffered? On Mon, Apr 20, 2015 at 6:51 AM, Poul-Henning Kamp wrote: > -------- > In message XOdPZs+SatfH7s6LnfYG++ZXNf4g at mail.gmail.com> > , Federico Schwindt writes: > > >1. This will only set the length after std.cache_req_body(). We might want > >to return content-length if std.cache_req_body() was not previously > called. > >I suppose some people might want to use it for other purposes than > retrying > >and if someone forgets calling cache_req_body() he/she might mistakenly > >believe that there is no body. OTOH exposing this without curation might > be > >a bad idea. > > We need a magic value for "unknown" no matter what we do, with > chunked req.body we have no idea until it is cached. > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at uplex.de Tue Apr 21 20:00:10 2015 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 21 Apr 2015 22:00:10 +0200 Subject: [PATCH] VSL_Arg rejects -L 0 Message-ID: <5536AC4A.3030300@uplex.de> Hello all, Currently a VSL tool such as varnishlog crashes with the option -L 0 when the first transaction is read -- AN(vtx) in vsl_dispatch.c, since the vslq->incomplete list is empty. Transaction limit 0 doesn't make any sense, so this patch enforces -L > 0. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: vsl_arg_L.patch Type: text/x-patch Size: 466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From geoff at uplex.de Tue Apr 21 20:05:07 2015 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 21 Apr 2015 22:05:07 +0200 Subject: [PATCH] vapi/vsl.h requires stdint.h Message-ID: <5536AD73.9080406@uplex.de> Hello, vsl.h requires stdint.h but currently doesn't include it, hence the patch. Best, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstra?e 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de -------------- next part -------------- A non-text attachment was scrubbed... Name: vsl_stdint.patch Type: text/x-patch Size: 281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From varnish at bsdchicks.com Tue Apr 21 21:05:07 2015 From: varnish at bsdchicks.com (Rogier 'DocWilco' Mulhuijzen) Date: Tue, 21 Apr 2015 21:05:07 +0000 Subject: [master] 15ec79c Concentrate the acceptor-setup-session code. In-Reply-To: References:

<68032.1426675779@critter.freebsd.dk> <73037.1426700405@critter.freebsd.dk> <4450.1427445052@critter.freebsd.dk> Message-ID: I talked to Artur, and he says that without kernel modifications it did nothing. Even with kernel modifications to tie specific NICs or flows from the NICs to specific CPU cores, you only notice a difference when under a flood. On Fri, Apr 10, 2015 at 10:59 AM Federico Schwindt wrote: > Yes, sorry. I was somewhat hasty when I sent this (I was boarding a plane). > > I'm not sure how we can get some metrics without implementing this though. > > Perhaps DocWilco has some numbers he can share? > > On Fri, Mar 27, 2015 at 8:30 AM, Poul-Henning Kamp > wrote: > >> -------- >> In message > 9Ad6dOwf+z5aq3aFqROtzA8kdSowTOYgRRAMv05g at mail.gmail.com> >> , Federico Schwindt writes: >> >> >Attached is a patch in that effect. >> > >> >I have no empirical evidence this will improve things but I believe >> Fastly >> >and others are doing it with good results. >> >> As I understand the documentation of SO_REUSEPORT your patch is a no-op. >> >> See for instance: http://lwn.net/Articles/542629/ >> >> SO_REUSEPORT allows you to bind(2) multiple sockets to the same port >> number[1]. >> >> Setting the option but not creating more sockets doesn't do anything. >> >> What we do fall somewhere in the middle between the two scenarios >> descriped >> in the article above: We have a single acceptor thread per thread pool. >> >> I have no idea how that performs relative to having multiple sockets, but >> I'd like to see some actual numbers before we start ripping things up. >> >> Poul-Henning >> >> [1] You can already do that with UDP under certain circumstances, but it >> is not allowed for TCP. >> >> -- >> 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: From martin at varnish-software.com Wed Apr 22 09:09:34 2015 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Wed, 22 Apr 2015 11:09:34 +0200 Subject: [PATCH] vapi/vsl.h requires stdint.h In-Reply-To: <5536AD73.9080406@uplex.de> References: <5536AD73.9080406@uplex.de> Message-ID: Thanks Geoff - applied Martin On 21 April 2015 at 22:05, Geoff Simmons wrote: > Hello, > > vsl.h requires stdint.h but currently doesn't include it, hence the patch. > > > Best, > Geoff > -- > ** * * UPLEX - Nils Goroll Systemoptimierung > > Scheffelstra?e 32 > 22301 Hamburg > > Tel +49 40 2880 5731 > Mob +49 176 636 90917 > Fax +49 40 42949753 > > http://uplex.de > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Mobile: +47 992 74 756 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at varnish-software.com Wed Apr 22 09:09:49 2015 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Wed, 22 Apr 2015 11:09:49 +0200 Subject: [PATCH] VSL_Arg rejects -L 0 In-Reply-To: <5536AC4A.3030300@uplex.de> References: <5536AC4A.3030300@uplex.de> Message-ID: Thanks Geoff - applied Martin On 21 April 2015 at 22:00, Geoff Simmons wrote: > Hello all, > > Currently a VSL tool such as varnishlog crashes with the option -L 0 > when the first transaction is read -- AN(vtx) in vsl_dispatch.c, since > the vslq->incomplete list is empty. > > Transaction limit 0 doesn't make any sense, so this patch enforces -L > 0. > > > Best, > Geoff > -- > ** * * UPLEX - Nils Goroll Systemoptimierung > > Scheffelstra?e 32 > 22301 Hamburg > > Tel +49 40 2880 5731 > Mob +49 176 636 90917 > Fax +49 40 42949753 > > http://uplex.de > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Mobile: +47 992 74 756 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kokoniimasu at gmail.com Wed Apr 29 08:11:18 2015 From: kokoniimasu at gmail.com (kokoniimasu) Date: Wed, 29 Apr 2015 17:11:18 +0900 Subject: [PATCH] varnishadm print VGC_ref Message-ID: Hi all, VCL_trace is useful at debugging. But, VCL_trace don't have source information. # varnishlog -g raw -i vcl_trace 224399237 VCL_trace c 41 134.3 224399237 VCL_trace c 42 136.1 ... This patch add -t option in the varnishadm vcl.show. -t option displays the VGC_ref. $ sudo varnishadm vcl.show -t boot index source line pos token 1 0 26 1 "}" 2 0 33 1 "}" 3 0 40 1 "}" 4 1 48 5 "if" 5 1 50 9 "return" 6 1 52 5 "if" 7 1 60 9 "return" 8 1 63 5 "if" ... Can know the exact position by combining the vcl.show -v. Regards, -- Shohei Tanaka(@xcir) http://xcir.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-varnishadm-print-VGC_ref-vcl.show-t.patch Type: application/octet-stream Size: 3509 bytes Desc: not available URL: