From arnoud at tumblr.com Wed Jul 9 13:05:07 2014 From: arnoud at tumblr.com (Arnoud Vermeer) Date: Wed, 9 Jul 2014 15:05:07 +0200 Subject: RedHat init script patch: disable transparent hugepage Message-ID: There is an advisement in the documentation about disabling redhat transparent hugepages. I think this patch would be a nice addition to the init script. Arnoud --- redhat/varnish.initrc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/redhat/varnish.initrc b/redhat/varnish.initrc index 0db3ab6..0e7a2e9 100755 --- a/redhat/varnish.initrc +++ b/redhat/varnish.initrc @@ -50,6 +50,13 @@ start() { fi echo -n "Starting Varnish Cache: " + if /bin/uname -r | /bin/grep -q el6 + then + # It is recommended to disable transparent hugepages on RHEL6 + # https://www.varnish-cache.org/docs/trunk/installation/platformnotes.html + echo "never" > /sys/kernel/mm/redhat_transparent_hugepage/enabled + fi + # Open files (usually 1024, which is way too small for varnish) ulimit -n ${NFILES:-131072} -- 1.8.5.2 (Apple Git-48) -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Jul 10 08:52:22 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Jul 2014 08:52:22 +0000 Subject: Varnish master-class at VUG9 ? Message-ID: <96677.1404982342@critter.freebsd.dk> If you develop on the Varnish source code or write your own VMODs, this may interest you. I'm thinking about doing a "master class" the day before VUG9 (which Ruben says will probably somewhere in the middle of Europe). I don't think regular courses works very well at this level of coding, it would just mean that N-1 students would be bored out of their skulls at any one time. But I feel there is a need for some kind of teaching, and have been thinking about how we could do it in a way that works best. The idea of a master-class is lifted from classical music: once you get to a particular level on your instrument, you start participating in master-classes, because what you need help to learn is specific to you, your instrument and your music. The main feature of a musical master-class is that students bring their own instrument and their own music, and gets the teachers undivided attention in turn the secondary feature being that you also get to listen on on everybody else, and pick up ideas, tricks and wisdom from their interaction with the teacher. The format I'm thinking of is something like this: Interested participants send me an email with the source code they want to bring. It can be a VMOD or it can be some feature or extension of one of the varnish programs. Please also tell me what areas/issues/problems you want us to focus on. You must be willing to show this code to the other participants, but for copyright purposes it will count as "a performance" and they do not get to steal your idea or your code without you (and your companys!) permission. Please make sure your boss is OK with this. We don't want any trouble. If there is enough interest, we will meet on the day before VUG9 and we will do something like: 15 min - student presents his code. (No interruptions) Short: What it does and why Longer: How it does it, (choice of algorithms etc) Most: Actual implementation, (problems, solutions) 15 min - Dialogue and discussion between student and me Focus: How to improve the students code and coding. Less so: Is this the right problem or right way to solve it. 10 min - Round-table, everybody gets to chime in All helpfull observations and suggestions welcome 5 min - Summary by me and student. 15 min - Break + next student gets projector working etc. (da capo al fine) I will warn you that this is a very scary experience first time you try it. Programmers, unlike musicians, are not used to having teachers and other students involved in our learning this way. You will feel your stomach knot once you and your code takes the floor. And you should realize that you and your code will get the undivided attention of a bunch of good programmers, and they will find mistakes, faults, errors flaws and misunderstandings in it -- no matter how good you think you are. You really want to polish your code and train for this, so you show us your very best -- show us that you are a master. It is important that you do not get defensive about the feedback, but apparoach this as a chance to learn from some very smart people who are trying to help you, and likewise, it is important that you try to help any of the other students when it becomes their turn. Since it can be a bit overwhelming to absorb so much so fast, you are welcome to audio/video record your own timeslot, so you can review it later, but you must arrange the recording yourself (ask a fellow student ?). You are not be allowed to record any other students, without their prior permission. Realistically we can go through 6-8 students on a single day before our brains are full. If there are more interested students than this, I get to pick who gets to participate. There will be a participation fee to cover expenses, probably less than 1000 EUR. Drop me an email if you are interested... Poul-Henning -- 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 slink at schokola.de Thu Jul 10 11:39:20 2014 From: slink at schokola.de (Nils Goroll) Date: Thu, 10 Jul 2014 13:39:20 +0200 Subject: RedHat init script patch: disable transparent hugepage In-Reply-To: References: Message-ID: <53BE7B68.2000906@schokola.de> I don't think we should change a global parameter when starting a specific service. Also this would need to be user-configurable - which it already is - in /etc/sysctl.conf On 09/07/14 15:05, Arnoud Vermeer wrote: > There is an advisement in the documentation about disabling redhat transparent > hugepages. From slink at schokola.de Thu Jul 10 15:19:06 2014 From: slink at schokola.de (Nils Goroll) Date: Thu, 10 Jul 2014 17:19:06 +0200 Subject: [PATCH] finally allow return(synth()) in vcl_deliver Message-ID: <53BEAEEA.90105@schokola.de> I have revisited https://www.varnish-cache.org/trac/ticket/1027 and IIUC phk has now done all the necessary groundwork to allow return(synth) in deliver: cnt_synth returns with either REQ_FSM_MORE for VCL_RET_RESTART or REQ_FSM_DONE after having called its custom delivery code path via V1D_Deliver_Synth(req). The rest of the calling code in cnt_deliver is identical for restart and synth. If you need historical background: Kristian had left helpful commit links and a summary in https://www.varnish-cache.org/trac/ticket/1027 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-allow-return-synth-.-in-vcl_deliver.patch Type: text/x-patch Size: 3536 bytes Desc: not available URL: From daghf at varnish-software.com Mon Jul 14 09:37:24 2014 From: daghf at varnish-software.com (Dag Haavi Finstad) Date: Mon, 14 Jul 2014 11:37:24 +0200 Subject: [PATCH] vcl.show expand includes Message-ID: Hi, As discussed on the Stockholm VDD, here's a proposal for #1457. Patch 1/2 makes the VCL compiler emit null pointer end markers to the 'srcname' and 'srcbody' arrays. Patch 2/2 adds a '-v' option to vcl.show, to have it also display all included files (including the implicitly included builtin VCL.) The output consists of a simple header for each file consisting of |. Then follows a newline and bytes which is the contents of that VCL verbatim, followed by a blank line. The idea is for this to be easy to parse, while still being in human readable form. 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. Regards, Dag -- Dag Haavi Finstad Software Developer | Varnish Software AS Mobile: +47 476 64 134 We Make Websites Fly! -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-an-endmarker-to-the-generated-srcbody-srcname-ar.patch Type: text/x-patch Size: 1443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-v-option-to-vcl.show-to-make-it-also-expand-in.patch Type: text/x-patch Size: 2579 bytes Desc: not available URL: From slink at schokola.de Mon Jul 21 12:36:03 2014 From: slink at schokola.de (Nils Goroll) Date: Mon, 21 Jul 2014 14:36:03 +0200 Subject: [PATCH 2/3] add VCL_MET_MASK_CLIENT and VCL_MET_MASK_BACKEND Message-ID: <53CD0933.2050706@schokola.de> needed for the next patch -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add-VCL_MET_MASK_CLIENT-and-VCL_MET_MASK_BACKEND.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: From slink at schokola.de Mon Jul 21 12:38:01 2014 From: slink at schokola.de (Nils Goroll) Date: Mon, 21 Jul 2014 14:38:01 +0200 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. Message-ID: <53CD09A9.9060204@schokola.de> I thought we probably won't want to bump the major version, so I kept rollback as a wrapper for rollback_req Fixes #1512 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Do-not-reset-bereq-on-retry.-Add-rollback_bereq-for-.patch Type: text/x-patch Size: 9802 bytes Desc: not available URL: From fgsch at lodoss.net Tue Jul 22 00:26:08 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 22 Jul 2014 01:26:08 +0100 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: <53CD09A9.9060204@schokola.de> References: <53CD09A9.9060204@schokola.de> Message-ID: I've changed your diff to avoid splitting rollback. I don't think we should make that distinction. Also added v_b_e to the test and renamed ws_snap to be more inline with other variables. ymmv. btw, your patches were 2/3 and 3/3. Is 1/3 missing? On Mon, Jul 21, 2014 at 1:38 PM, Nils Goroll wrote: > I thought we probably won't want to bump the major version, so I kept > rollback > as a wrapper for rollback_req > > Fixes #1512 > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 000-r01512.patch Type: text/x-patch Size: 4341 bytes Desc: not available URL: From fgsch at lodoss.net Tue Jul 22 00:31:57 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 22 Jul 2014 01:31:57 +0100 Subject: std.ip() with hostnames Message-ID: Hi, I'm writing a vmod and I noticed std.ip() will happily resolve its argument if a hostname is used. Feature or bug? If this is going to stay I wouldn't waste time implementing different methods to support both hostnames and VCL_IP. OTOH if this is a bug I might need to (and it'd be better to fix this sooner than later). Comments? f.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Jul 22 08:35:44 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Jul 2014 08:35:44 +0000 Subject: std.ip() with hostnames In-Reply-To: References: Message-ID: <69377.1406018144@critter.freebsd.dk> In message , Federico Schwindt writes: >I'm writing a vmod and I noticed std.ip() will happily resolve its argument >if a hostname is used. Feature or bug? std.ip() does a getaddrinfo(3) on its argument by design. -- 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 Tue Jul 22 09:08:37 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Jul 2014 09:08:37 +0000 Subject: Visibility of VCL source (Was: Re: [PATCH] vcl.show expand includes) In-Reply-To: References: Message-ID: <69611.1406020117@critter.freebsd.dk> In message , 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. From phk at phk.freebsd.dk Tue Jul 22 09:16:37 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Jul 2014 09:16:37 +0000 Subject: Visibility of VCL source (Was: Re: [PATCH] vcl.show expand includes) In-Reply-To: <69611.1406020117@critter.freebsd.dk> References: <69611.1406020117@critter.freebsd.dk> Message-ID: <69708.1406020597@critter.freebsd.dk> In message <69611.1406020117 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >In message >, 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 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 wolvverinepld at gmail.com Tue Jul 22 09:45:53 2014 From: wolvverinepld at gmail.com (wolvverine) Date: Tue, 22 Jul 2014 11:45:53 +0200 Subject: Patch for Nagios Varnish plugin - add multiinstances Message-ID: - add option for instance name -------------- next part -------------- A non-text attachment was scrubbed... Name: check_varnish.pl.patch Type: application/octet-stream Size: 2082 bytes Desc: not available URL: From fgsch at lodoss.net Tue Jul 22 10:06:40 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 22 Jul 2014 11:06:40 +0100 Subject: std.ip() with hostnames In-Reply-To: <69377.1406018144@critter.freebsd.dk> References: <69377.1406018144@critter.freebsd.dk> Message-ID: I appreciate that but you could use AI_NUMERICHOST to avoid lookups. Currently that's not the case. On Tue, Jul 22, 2014 at 9:35 AM, Poul-Henning Kamp wrote: > In message GpGOo1H-gnemYkoWDnJa5PLJbReYCu9qdWkMPwd8A at mail.gmail.com> > , Federico Schwindt writes: > > >I'm writing a vmod and I noticed std.ip() will happily resolve its > argument > >if a hostname is used. Feature or bug? > > std.ip() does a getaddrinfo(3) on its argument by design. > > > -- > 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 phk at phk.freebsd.dk Tue Jul 22 10:49:17 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Jul 2014 10:49:17 +0000 Subject: std.ip() with hostnames In-Reply-To: References: <69377.1406018144@critter.freebsd.dk> Message-ID: <70009.1406026157@critter.freebsd.dk> In message , Federico Schwindt writes: >I appreciate that but you could use AI_NUMERICHOST to avoid lookups. >Currently that's not the case. I wanted consistent behaviour -- 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 slink at schokola.de Tue Jul 22 11:38:36 2014 From: slink at schokola.de (Nils Goroll) Date: Tue, 22 Jul 2014 13:38:36 +0200 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: References: <53CD09A9.9060204@schokola.de> Message-ID: <53CE4D3C.3010305@schokola.de> Hi Federico, On 22/07/14 02:26, Federico Schwindt wrote: > I've changed your diff to avoid splitting rollback. I don't think we should make > that distinction. I had considered this approach also (see yesterday's irc log) but ditched it because I thought checking context in VCC would be better than checking at runtime - and VCC would have required more attention to become "context sensitive". Other than that I am fine with your change in principle - but I have not tested it. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From slink at schokola.de Tue Jul 22 11:40:56 2014 From: slink at schokola.de (Nils Goroll) Date: Tue, 22 Jul 2014 13:40:56 +0200 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: References: <53CD09A9.9060204@schokola.de> Message-ID: <53CE4DC8.6060201@schokola.de> On 22/07/14 02:26, Federico Schwindt wrote: > > btw, your patches were 2/3 and 3/3. Is 1/3 missing? Sorry, this is due to the fact that I had "[PATCH] finally allow return(synth()) in vcl_deliver" waiting to be pushed. @phk: Any chance you can have at look at this? https://www.varnish-cache.org/patchwork/patch/171/ From phk at phk.freebsd.dk Tue Jul 22 11:52:19 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Jul 2014 11:52:19 +0000 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: <53CE4DC8.6060201@schokola.de> References: <53CD09A9.9060204@schokola.de> <53CE4DC8.6060201@schokola.de> Message-ID: <76683.1406029939@critter.freebsd.dk> In message <53CE4DC8.6060201 at schokola.de>, Nils Goroll writes: > > >On 22/07/14 02:26, Federico Schwindt wrote: >> >> btw, your patches were 2/3 and 3/3. Is 1/3 missing? > >Sorry, this is due to the fact that I had "[PATCH] finally allow return(synth()) >in vcl_deliver" waiting to be pushed. > >@phk: Any chance you can have at look at this? >https://www.varnish-cache.org/patchwork/patch/171/ It's at the top of my pile. -- 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 Tue Jul 22 12:25:25 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 22 Jul 2014 13:25:25 +0100 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: <53CE4D3C.3010305@schokola.de> References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> Message-ID: I agree, it'd be better and if it's possible in the future we can switch to it but splitting rollback is a one way road. There are other places checking ctx->method so it should be fine. On Tue, Jul 22, 2014 at 12:38 PM, Nils Goroll wrote: > Hi Federico, > > On 22/07/14 02:26, Federico Schwindt wrote: > > I've changed your diff to avoid splitting rollback. I don't think we > should make > > that distinction. > > I had considered this approach also (see yesterday's irc log) but ditched > it > because I thought checking context in VCC would be better than checking at > runtime - and VCC would have required more attention to become "context > sensitive". > > Other than that I am fine with your change in principle - but I have not > tested it. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Tue Jul 22 15:33:36 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 22 Jul 2014 16:33:36 +0100 Subject: Visibility of VCL source (Was: Re: [PATCH] vcl.show expand includes) In-Reply-To: <69611.1406020117@critter.freebsd.dk> References: <69611.1406020117@critter.freebsd.dk> Message-ID: 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 wrote: > In message 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: From phk at phk.freebsd.dk Thu Jul 24 11:06:34 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Jul 2014 11:06:34 +0000 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> Message-ID: <49589.1406199994@critter.freebsd.dk> We chatted about this on IRC today, and this is just to keep everybody in the loop: In general, I'm trying to slim down VCC to be "just the language" and 'rollback' is one of the remaining bits I'd like to get out of there, so the new improved rollback goes into vmod.std. We leave the "rollback" which VCC implements alone for 4.x I have added a new VMOD data type "HTTP", which returns an entire HTTP request/response (struct http *), so that somebody can now implement the rollback functionality in vmod.std, so the end result will become: std.collect(req) std.collect(bereq) -- 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 Thu Jul 24 11:08:19 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Jul 2014 11:08:19 +0000 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: <49589.1406199994@critter.freebsd.dk> References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> <49589.1406199994@critter.freebsd.dk> Message-ID: <50127.1406200099@critter.freebsd.dk> In message <49589.1406199994 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >We chatted about this on IRC today, and this is just to keep everybody >in the loop: > >In general, I'm trying to slim down VCC to be "just the language" and >'rollback' is one of the remaining bits I'd like to get out of there, >so the new improved rollback goes into vmod.std. > >We leave the "rollback" which VCC implements alone for 4.x > >I have added a new VMOD data type "HTTP", which returns an entire >HTTP request/response (struct http *), so that somebody can now >implement the rollback functionality in vmod.std, so the end result >will become: > > std.collect(req) > > std.collect(bereq) and that of course should been: std.rollback(req) std.rollback(bereq) -- 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 Jul 24 13:50:06 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Thu, 24 Jul 2014 14:50:06 +0100 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: <50127.1406200099@critter.freebsd.dk> References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> <49589.1406199994@critter.freebsd.dk> <50127.1406200099@critter.freebsd.dk> Message-ID: Attached. OK? On Thu, Jul 24, 2014 at 12:08 PM, Poul-Henning Kamp wrote: > In message <49589.1406199994 at critter.freebsd.dk>, "Poul-Henning Kamp" > writes: > >We chatted about this on IRC today, and this is just to keep everybody > >in the loop: > > > >In general, I'm trying to slim down VCC to be "just the language" and > >'rollback' is one of the remaining bits I'd like to get out of there, > >so the new improved rollback goes into vmod.std. > > > >We leave the "rollback" which VCC implements alone for 4.x > > > >I have added a new VMOD data type "HTTP", which returns an entire > >HTTP request/response (struct http *), so that somebody can now > >implement the rollback functionality in vmod.std, so the end result > >will become: > > > > std.collect(req) > > > > std.collect(bereq) > > and that of course should been: > > std.rollback(req) > std.rollback(bereq) > > > -- > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 000-std_rollback.patch Type: text/x-diff Size: 5441 bytes Desc: not available URL: From fgsch at lodoss.net Thu Jul 24 19:33:57 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Thu, 24 Jul 2014 20:33:57 +0100 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> <49589.1406199994@critter.freebsd.dk> <50127.1406200099@critter.freebsd.dk> Message-ID: fwiw, change ws0 to ws_bo in this diff. On Thu, Jul 24, 2014 at 2:50 PM, Federico Schwindt wrote: > Attached. > > OK? > > > > > On Thu, Jul 24, 2014 at 12:08 PM, Poul-Henning Kamp > wrote: > >> In message <49589.1406199994 at critter.freebsd.dk>, "Poul-Henning Kamp" >> writes: >> >We chatted about this on IRC today, and this is just to keep everybody >> >in the loop: >> > >> >In general, I'm trying to slim down VCC to be "just the language" and >> >'rollback' is one of the remaining bits I'd like to get out of there, >> >so the new improved rollback goes into vmod.std. >> > >> >We leave the "rollback" which VCC implements alone for 4.x >> > >> >I have added a new VMOD data type "HTTP", which returns an entire >> >HTTP request/response (struct http *), so that somebody can now >> >implement the rollback functionality in vmod.std, so the end result >> >will become: >> > >> > std.collect(req) >> > >> > std.collect(bereq) >> >> and that of course should been: >> >> std.rollback(req) >> std.rollback(bereq) >> >> >> -- >> 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 wolvverinepld at gmail.com Fri Jul 25 15:34:28 2014 From: wolvverinepld at gmail.com (wolvverine) Date: Fri, 25 Jul 2014 17:34:28 +0200 Subject: Patch for Nagios Varnish plugin - add multiinstances In-Reply-To: References: Message-ID: - add option for instance name --- check_varnish.pl.orig 2014-07-22 11:12:36.141550908 +0200 +++ check_varnish.pl 2014-07-22 11:15:45.898193885 +0200 @@ -28,11 +28,14 @@ # Parse command line options my @specs; +my $instancename = $ENV{HOSTNAME}; my ( $list, $help ); + GetOptions( "spec|s=s" => \@specs, "list|l" => \$list, - "help|h" => \$help + "help|h" => \$help, + "instancename|n=s" => \$instancename ); # Print help if they asked for it @@ -41,7 +44,7 @@ } if ($list) { - print_list(); + print_list($instancename); } # Global vars that hold the parsed varnishstat output @@ -57,7 +60,7 @@ print_help(); } -parse_varnishstat(); +parse_varnishstat($instancename); foreach (@specs) { @@ -154,8 +157,9 @@ # Turn the varnishstat output into a Perl hash sub parse_varnishstat { + my ($instancename) = @_; - open (VARNISHSTAT, "/usr/bin/varnishstat -1 |"); + open (VARNISHSTAT, "/usr/bin/varnishstat -1 -n" . $instancename . " |"); while () { s/\s+/ /g; # normalise spaces @@ -216,8 +220,8 @@ Usage: - check_varnish.pl --spec=[spec definition] --spec=[spec definition] - check_varnish.pl --list + check_varnish.pl [--instancename=instance ] --spec=[spec definition] --spec=[spec definition] + check_varnish.pl --list [--instancename=instance ] check_varnish.pl --help Options: @@ -254,6 +258,9 @@ --help Displays this message. + --instancename + name of varnish instance + check_varnish.pl comes with absolutely NO WARRANTY either implied or explicit This program is licensed under the terms of the GNU General Public License (check source code for details) @@ -265,10 +272,11 @@ } sub print_list { + my ($instancename) = @_; # Print a list of all the varnishstat counters # and their (sometimes meaningless!) description - parse_varnishstat(); + parse_varnishstat($instancename); if ($list) { print "\nAvailable Varnish performance counters:\n\n"; From slink at schokola.de Mon Jul 28 18:14:12 2014 From: slink at schokola.de (Nils Goroll) Date: Mon, 28 Jul 2014 20:14:12 +0200 Subject: VRT_CacheReqBody without inline-C? Message-ID: <53D692F4.7030904@schokola.de> are there any plans for VRT_CacheReqBody ? move into std or the like? From phk at phk.freebsd.dk Wed Jul 30 07:57:12 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 30 Jul 2014 07:57:12 +0000 Subject: VRT_CacheReqBody without inline-C? In-Reply-To: <53D692F4.7030904@schokola.de> References: <53D692F4.7030904@schokola.de> Message-ID: <16357.1406707032@critter.freebsd.dk> -------- In message <53D692F4.7030904 at schokola.de>, Nils Goroll writes: >are there any plans for VRT_CacheReqBody ? move into std or the like? Yes, we should probably do that. Patch anyone ? -- 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 Wed Jul 30 08:01:26 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 30 Jul 2014 08:01:26 +0000 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> <49589.1406199994@critter.freebsd.dk> <50127.1406200099@critter.freebsd.dk> Message-ID: <16412.1406707286@critter.freebsd.dk> -------- In message , Federico Schwindt writes: Two things, on trivial-ish and the other serious-ish. The trivial thing is that I think we should put the actual rollback in VRT_Rollback() (give it an VCL_HTTP argument) so that std.rollback just wraps that. The other thing is that I'm not even close to being convinced that resetting the workspace is safe anymore, and I have no idea how I can convince myself that it is, in a world full of VMODs. We may have to give up on that, and only rollback the struct http. -- 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 jammy.linux at gmail.com Wed Jul 30 13:04:04 2014 From: jammy.linux at gmail.com (Meng Zhang) Date: Wed, 30 Jul 2014 21:04:04 +0800 Subject: Patch to fix the build issue on MacOS 10.9.4 Message-ID: Hi, @there, Here ( https://github.com/varnish/Varnish-Cache/pull/46 ) is a pull-request to fix the build issue on MacOS 10.9.4. Thanks Regards, Meng diff --git a/bin/varnishd/cache/cache_http1_fsm.c b/bin/varnishd/cache/cache_http1_fsm.c index 940dd9f..66063be 100644 --- a/bin/varnishd/cache/cache_http1_fsm.c +++ b/bin/varnishd/cache/cache_http1_fsm.c @@ -72,7 +72,6 @@ #include #include #include -#include #include "cache.h" #include "hash/hash_slinger.h" @@ -705,12 +704,12 @@ HTTP1_CacheReqBody(struct req *req, ssize_t maxsize) http_Unset(req->http0, H_Content_Length); http_Unset(req->http0, H_Transfer_Encoding); - http_PrintfHeader(req->http0, "Content-Length: %"PRIu64, + http_PrintfHeader(req->http0, "Content-Length: %ju", req->req_bodybytes); http_Unset(req->http, H_Content_Length); http_Unset(req->http, H_Transfer_Encoding); - http_PrintfHeader(req->http, "Content-Length: %"PRIu64, + http_PrintfHeader(req->http, "Content-Length: %ju", req->req_bodybytes); req->req_body_status = REQ_BODY_CACHED; -------------- next part -------------- An HTML attachment was scrubbed... URL: From jammy.linux at gmail.com Wed Jul 30 13:12:44 2014 From: jammy.linux at gmail.com (Meng Zhang) Date: Wed, 30 Jul 2014 21:12:44 +0800 Subject: Patch to fix the build issue on MacOS 10.9.4 In-Reply-To: References: Message-ID: <916BE76D-45E7-4E44-A7D1-5E66FAE75F8A@gmail.com> Sorry. The diff in the previous email is wrong. Resent here. From 52016e3dab92f617124964d275a6ea7c6157d220 Mon Sep 17 00:00:00 2001 From: ijammy Date: Wed, 30 Jul 2014 20:57:34 +0800 Subject: [PATCH] Eliminate the compiler complain against the format of vsprintf, e.g. format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] --- bin/varnishd/cache/cache_http1_fsm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bin/varnishd/cache/cache_http1_fsm.c b/bin/varnishd/cache/cache_http1_fsm.c index 66063be..940dd9f 100644 --- a/bin/varnishd/cache/cache_http1_fsm.c +++ b/bin/varnishd/cache/cache_http1_fsm.c @@ -72,6 +72,7 @@ #include #include #include +#include #include "cache.h" #include "hash/hash_slinger.h" @@ -704,12 +705,12 @@ HTTP1_CacheReqBody(struct req *req, ssize_t maxsize) http_Unset(req->http0, H_Content_Length); http_Unset(req->http0, H_Transfer_Encoding); - http_PrintfHeader(req->http0, "Content-Length: %ju", + http_PrintfHeader(req->http0, "Content-Length: %"PRIu64, req->req_bodybytes); http_Unset(req->http, H_Content_Length); http_Unset(req->http, H_Transfer_Encoding); - http_PrintfHeader(req->http, "Content-Length: %ju", + http_PrintfHeader(req->http, "Content-Length: %"PRIu64, req->req_bodybytes); req->req_body_status = REQ_BODY_CACHED; -- 2.0.1.442.g7fe6834 On 30 Jul, 2014, at 9:04 pm, Meng Zhang wrote: > > Hi, @there, > > Here ( https://github.com/varnish/Varnish-Cache/pull/46 ) is a pull-request to fix the build issue on MacOS 10.9.4. > > Thanks > > Regards, > Meng -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Eliminate-the-compiler-complain-against-the-format-o.patch Type: application/octet-stream Size: 1451 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Wed Jul 30 13:35:57 2014 From: fgsch at lodoss.net (Federico Schwindt) Date: Wed, 30 Jul 2014 14:35:57 +0100 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: <16412.1406707286@critter.freebsd.dk> References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> <49589.1406199994@critter.freebsd.dk> <50127.1406200099@critter.freebsd.dk> <16412.1406707286@critter.freebsd.dk> Message-ID: Attached. OK? On Wed, Jul 30, 2014 at 9:01 AM, Poul-Henning Kamp wrote: > -------- > In message 6CbiF0kow at mail.gmail.com> > , Federico Schwindt writes: > > Two things, on trivial-ish and the other serious-ish. > > The trivial thing is that I think we should put the actual > rollback in VRT_Rollback() (give it an VCL_HTTP argument) so that > std.rollback just wraps that. > > The other thing is that I'm not even close to being convinced that > resetting the workspace is safe anymore, and I have no idea how I > can convince myself that it is, in a world full of VMODs. > > We may have to give up on that, and only rollback the struct http. > > -- > 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: r1512v2.patch Type: text/x-diff Size: 7716 bytes Desc: not available URL: From phk at phk.freebsd.dk Wed Jul 30 13:55:02 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 30 Jul 2014 13:55:02 +0000 Subject: [PATCH 3/3] Do not reset bereq on retry. Add rollback_bereq for this, purpose. In-Reply-To: References: <53CD09A9.9060204@schokola.de> <53CE4D3C.3010305@schokola.de> <49589.1406199994@critter.freebsd.dk> <50127.1406200099@critter.freebsd.dk> <16412.1406707286@critter.freebsd.dk> Message-ID: <12148.1406728502@critter.freebsd.dk> -------- In message , Federico Schwin dt writes: >Attached. > >OK? Looks good, commit it if tested. -- 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 jammy.linux at gmail.com Wed Jul 30 14:54:59 2014 From: jammy.linux at gmail.com (Meng Zhang) Date: Wed, 30 Jul 2014 22:54:59 +0800 Subject: Patch to fix mgt_sandbox_unix if there're more than 10 groups Message-ID: Hi, @there Please review and commit the patch to fix mgt_sandbox_unix. Thanks Regards From 79b9db3ccb5dc5c8b3e441f7a89f1195e1d6c8b7 Mon Sep 17 00:00:00 2001 From: ijammy Date: Wed, 30 Jul 2014 22:53:36 +0800 Subject: [PATCH] mgt_sandbox_unix will break if there're more than 10 groups --- bin/varnishd/mgt/mgt_sandbox.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/bin/varnishd/mgt/mgt_sandbox.c b/bin/varnishd/mgt/mgt_sandbox.c index 973ec83..fe0ad11 100644 --- a/bin/varnishd/mgt/mgt_sandbox.c +++ b/bin/varnishd/mgt/mgt_sandbox.c @@ -53,6 +53,7 @@ #include #include #include +#include #include "mgt/mgt.h" #include "common/params.h" @@ -63,9 +64,8 @@ static void __match_proto__(mgt_sandbox_f) mgt_sandbox_unix(enum sandbox_e who) { -#define NGID 10 - gid_t gid_list[NGID]; - int i; + gid_t *gid_list = NULL; + int i,n; if (geteuid() != 0) { REPORT0(LOG_INFO, "Not running as root, no priv-sep"); @@ -76,11 +76,16 @@ mgt_sandbox_unix(enum sandbox_e who) XXXAZ(initgroups(mgt_param.user, mgt_param.gid)); if (who == SANDBOX_CC && strlen(mgt_param.group_cc) > 0) { + + /*If gidsetsize is 0, getgroups() returns the number of groups without modifying the grouplist[] array.*/ + n = getgroups(0,gid_list); + gid_list = calloc(n+1,sizeof(gid_t)); /* Add the optional extra group for the C-compiler access */ - i = getgroups(NGID, gid_list); + i = getgroups(n+1, gid_list); assert(i >= 0); gid_list[i++] = mgt_param.gid_cc; XXXAZ(setgroups(i, gid_list)); + free(gid_list); } XXXAZ(setuid(mgt_param.uid)); -- 2.0.1.442.g7fe6834 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-mgt_sandbox_unix-will-break-if-there-re-more-than-10.patch Type: application/octet-stream Size: 1590 bytes Desc: not available URL: -------------- next part -------------- From jammy.linux at gmail.com Wed Jul 30 15:00:41 2014 From: jammy.linux at gmail.com (Meng Zhang) Date: Wed, 30 Jul 2014 23:00:41 +0800 Subject: VRT_CacheReqBody without inline-C? In-Reply-To: <16357.1406707032@critter.freebsd.dk> References: <53D692F4.7030904@schokola.de> <16357.1406707032@critter.freebsd.dk> Message-ID: <32B2E540-68AE-460A-B544-0FEF4EAF29CB@gmail.com> Just created one, please review. From e6f95f0bafa656de41c25ecd74f6d626ab70c25f Mon Sep 17 00:00:00 2001 From: ijammy Date: Wed, 30 Jul 2014 22:56:40 +0800 Subject: [PATCH] Add std.cache_req_body for VRT_CacheReqBody --- lib/libvmod_std/vmod.vcc | 7 +++++++ lib/libvmod_std/vmod_std.c | 12 ++++++++++++ 2 files changed, 19 insertions(+) diff --git a/lib/libvmod_std/vmod.vcc b/lib/libvmod_std/vmod.vcc index fbee007..aa3c342 100644 --- a/lib/libvmod_std/vmod.vcc +++ b/lib/libvmod_std/vmod.vcc @@ -192,6 +192,13 @@ Description Example set req.url = std.querysort(req.url); +$Function VOID cache_req_body(REAL) + +Description + Cache the req.body if it is smaller than the given size +Example + std.cache_req_body(1000); + This will cache the req.body if its size is smaller than 1000B SEE ALSO diff --git a/lib/libvmod_std/vmod_std.c b/lib/libvmod_std/vmod_std.c index 718fb71..08fc13d 100644 --- a/lib/libvmod_std/vmod_std.c +++ b/lib/libvmod_std/vmod_std.c @@ -224,3 +224,15 @@ vmod_timestamp(const struct vrt_ctx *ctx, VCL_STRING label) VSLb_ts_req(ctx->req, label, VTIM_real()); } } + +VCL_VOID __match_proto__(td_std_cache_req_body) +vmod_cache_req_body(const struct vrt_ctx *ctx, VCL_REAL size) +{ + + long long llsize = (long long)size; + int result; + CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); + result = VRT_CacheReqBody(ctx,llsize); + VSLb(ctx->vsl, SLT_Debug,"VRT_CacheReqBody[size: %lld] result: %d",llsize,result); + +} -- 2.0.1.442.g7fe6834 On 30 Jul, 2014, at 3:57 pm, Poul-Henning Kamp wrote: > -------- > In message <53D692F4.7030904 at schokola.de>, Nils Goroll writes: > >> are there any plans for VRT_CacheReqBody ? move into std or the like? > > Yes, we should probably do that. > > Patch anyone ? > > > -- > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-std.cache_req_body-for-VRT_CacheReqBody.patch Type: application/octet-stream Size: 1489 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Jul 31 09:18:26 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 31 Jul 2014 09:18:26 +0000 Subject: Patch to fix the build issue on MacOS 10.9.4 In-Reply-To: References: Message-ID: <6506.1406798306@critter.freebsd.dk> -------- In message , Meng Zhang writes: >Here ( https://github.com/varnish/Varnish-Cache/pull/46 ) is a = >pull-request to fix the build issue on MacOS 10.9.4. I've fixed it slightly differently to avoid the unreadability of PRIu64 and friends. Let me know if there is anything else... -- 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 Thu Jul 31 09:50:39 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 31 Jul 2014 09:50:39 +0000 Subject: Patch to fix mgt_sandbox_unix if there're more than 10 groups In-Reply-To: References: Message-ID: <21832.1406800239@critter.freebsd.dk> -------- In message , Meng Zhang writes: >Please review and commit the patch to fix mgt_sandbox_unix. I just bumbped NGID to 2000 instead. :-) -- 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 jammy.linux at gmail.com Thu Jul 31 09:54:47 2014 From: jammy.linux at gmail.com (Meng Zhang) Date: Thu, 31 Jul 2014 17:54:47 +0800 Subject: Patch to fix the build issue on MacOS 10.9.4 In-Reply-To: <6506.1406798306@critter.freebsd.dk> References: <6506.1406798306@critter.freebsd.dk> Message-ID: <92D109D1-E88D-40AF-BE56-CE7A670321EE@gmail.com> Hi, Poul-Henning Fine as long as it is fixed in a reasonable way. Also, wonder if you can spend some time to look at this issue and commit => "mgt_sandbox_unix will break if there're more than 10 groups" https://github.com/varnish/Varnish-Cache/pull/48 Thanks, Meng On 31 Jul, 2014, at 5:18 pm, Poul-Henning Kamp wrote: > -------- > In message , Meng Zhang writes: > >> Here ( https://github.com/varnish/Varnish-Cache/pull/46 ) is a = >> pull-request to fix the build issue on MacOS 10.9.4. > > I've fixed it slightly differently to avoid the unreadability of PRIu64 and friends. > > Let me know if there is anything else... > > -- > 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: