From guillaume at varnish-software.com Thu Oct 1 14:59:21 2015 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Thu, 1 Oct 2015 16:59:21 +0200 Subject: Build system patch In-Reply-To: References: <84577.1442836198@critter.freebsd.dk> Message-ID: Ok, here we go again. The previous patch had some problems regarding dependencies. So, I rebased it and tried all combinations of : parallel: -j 1 / -j 32 targets: all, dist, distcheck, install, html, man pages (*.1, *.7), and pretty much all compiled compiled objects (*.o, *.lo, *.la) make: bmake, gmake build: out-of-tree, in-tree That's a grand total of 2360 compilations. Each build was started for a clean, configured env, directly by typing "[b]make $TARGET". Everything worked except for the distchecks with bmake. But it doesn't work at all currently, so that's not a regression. I still want to address this later on. The dist tarball and install results are similar (except that I get an extra var/varnish folder). All the previous points from the first mail should apply. Except, as a bonus I added the "submks" target that will create Makefiles in (some) sub-directories, so you can type "make" from bin/varnishd and it will work. Feedback is of course welcome. -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-clean-submks-targets.patch Type: text/x-patch Size: 1442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-build-system-non-recursive.patch Type: text/x-patch Size: 79673 bytes Desc: not available URL: From fgsch at lodoss.net Thu Oct 1 16:36:16 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Thu, 1 Oct 2015 17:36:16 +0100 Subject: [PATCH] Convert arguments to strings as well Message-ID: Now that 4.1 is out of the way, I'd like to push this. Comments? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Convert-arguments-to-strings-as-well.patch Type: text/x-patch Size: 2368 bytes Desc: not available URL: From martin at varnish-software.com Tue Oct 6 18:33:07 2015 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Tue, 6 Oct 2015 20:33:07 +0200 Subject: Range handling in Varnish Message-ID: I've been dealing with ranges issues in Varnish lately, mostly trying to fix issues with the 4.0 behaviour. As part of that I've also looked carefully at the new implementation that went into Varnish 4.1. As this is a complex subject, I ended up trying to document how it is supposed to work. The following is a draft for a Varnish range handling page.Please read and give feedback if my descriptions are accurate, and if this is the functionality as we want to support it. BEGIN DRAFT DOCS Range handling ============== Range support allows client requests to retrieve only parts of an object by selecting the bytes needed in the Range request header. On a successful range request, the HTTP response code will be changed from 200 to 206, and the Content-Range response header describes the range delivered. Note that Varnish only supports specifying a single range in each request. The following applies only to cache hits. On passes, Varnish does not intervene with the range handling, but the handling is passed on to the backend server. Advertisement of range capability --------------------------------- Varnish will advertise range support for any cached object with a 200 status code, except if that object includes ESI instructions or when it's used as part of an ESI subdelivery (or range support is turned off by the http_range_support runtime parameter). Advertisement is done through a "Accept-Ranges: bytes" response header. Final object size knowledge --------------------------- The range handling in Varnish behaves differently based on whether Varnish is aware of the final size of the object being delivered. Varnish knows the final object size when either the backend provided a Content-Length header or the fetch operation has completed (non-streaming deliveries). If the delivery is for a client that does not support gzip, and the object is cached compressed, Varnish will uncompress the object as part of the client delivery. In this case Varnish will only know the final uncompressed object size after the fetch operation has completed, regardless if the backend provided a Content-Length header. Parsing of request range headers -------------------------------- A malformed client Range header results in a 416 "Request Range Not Satisfiable" response. The Varnish log will contain an error message describing the error. Range delivery ----------- Varnish only handles ranges when it has knowledge of final object size. Both closed (have both low and high byte) and open-ended (missing either low or high) are supported. The range is truncated if it falls outside the object space. Varnish responds with status 206, an appropriate Content-Range header and the corresponding range of bytes in the body. It is also always delivered with a Content-Length header matching the Content-Range. If Varnish does not have the final object size knowledge, it will not honour range requests. They are instead delivered as normal 200 responses with the complete object, as if the Range header was not present on the request in the first place. END DRAFT DOCS Some info on what it used to be: In our previous version (4.0), things behaved differently. Varnish would attempt to do range handling also when we did not know the final object size, using a snapshot of the current size instead, on the premise that the client could know something that Varnish doesn't. Open-ended ranges failed with this approach as the transient size was used to find the end of the object leading to completely wrong responses for e.g. "give me the last 50 bytes". Also closed ranges failed at least for some clients. The Content-Range response header has a total byte field, and we would report our transient object size in this field. Some clients would use this information and get a wrong impression of the final object size. RFC7233 states that it is legal to report an asterisk instead of the total bytes if the total bytes in unknown, and seems to offer a nice way to indicate that we are uncertain. Master used to behave this way until just before the 4.1 release. It was changed as part of #1777 as search crawler bots seemed to always ask a set range, and because we would then also provide a Content-Length the connection failed hard if the object happened to be smaller than the given range. I wonder if the resolution of #1777 is wrong, and that it would be viable to still do opportunistic ranges successfully with the uncertainty of the asterisk total length, but with chunked delivery applied instead of forcing a Content-Length. The resolution of #1777 also left some amount of dead code in cache_range.c, along with a kind of convoluted set of if-tests. The attached patch removes this if we are certain that we don't want that behaviour. Martin -- *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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-dead-code.patch Type: text/x-patch Size: 2060 bytes Desc: not available URL: From geoff at uplex.de Sun Oct 11 18:31:46 2015 From: geoff at uplex.de (Geoff Simmons) Date: Sun, 11 Oct 2015 20:31:46 +0200 Subject: [PATCH] (against 4.0.3) for response status 204, like 304, set the wantbody flag to false and remove the Content-Length header Message-ID: <561AAB12.3000402@uplex.de> Hello all, This patch is a one-liner that resolves issue #1761 for 4.0.3. We were intermittently getting responses with status 204 that were chunked-encoded with a single chunk of length 0, but a 204 response should have no body at all. We haven't seen the error since the patch was applied. phk's patch was against trunk at the time, well into the development for 4.1, and couldn't be backported to 4.0.3. So if there are any further maintenance releases for 4.0.x, I suggest that this patch be included. 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: 0001-for-response-status-204-like-304-set-the-wantbody-fl.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From fgsch at lodoss.net Tue Oct 13 16:14:00 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 13 Oct 2015 17:14:00 +0100 Subject: [PATCH] Expose accept_filter parameter to Linux Message-ID: Now that 4.1 is out of the door I'd like to get this in, disabled by default. We can nuke it before release if required and gives people time to play with it. Comments? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Expose-accept_filter-parameter-to-Linux.patch Type: text/x-patch Size: 1114 bytes Desc: not available URL: From fgsch at lodoss.net Tue Oct 13 16:14:29 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 13 Oct 2015 17:14:29 +0100 Subject: [PATCH] Convert arguments to strings as well In-Reply-To: References: Message-ID: Anyone? On Thu, Oct 1, 2015 at 5:36 PM, Federico Schwindt wrote: > Now that 4.1 is out of the way, I'd like to push this. > > Comments? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Oct 13 17:38:55 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Oct 2015 17:38:55 +0000 Subject: [PATCH] Expose accept_filter parameter to Linux In-Reply-To: References: Message-ID: <18037.1444757935@critter.freebsd.dk> -------- In message , Federico Schwindt writes: >Now that 4.1 is out of the door I'd like to get this in, disabled by >default. > >We can nuke it before release if required and gives people time to play >with it. > >Comments? I may have received the answer already, but forgotten it: Did somebody actually try to enable it to see that it works on at least one machine ? -- 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 rafaelfz at taghos.com.br Tue Oct 13 18:18:56 2015 From: rafaelfz at taghos.com.br (Rafael Zalamena) Date: Tue, 13 Oct 2015 15:18:56 -0300 Subject: [PATCH] Expose accept_filter parameter to Linux In-Reply-To: <18037.1444757935@critter.freebsd.dk> References: <18037.1444757935@critter.freebsd.dk> Message-ID: <20151013151856.51359fdd@taghos.com.br> On Tue, 13 Oct 2015 17:38:55 +0000 Poul-Henning Kamp wrote: > -------- > In message > , Federico Schwindt writes: > > >Now that 4.1 is out of the door I'd like to get this in, disabled by > >default. > > > >We can nuke it before release if required and gives people time to play > >with it. > > > >Comments? > > I may have received the answer already, but forgotten it: > > Did somebody actually try to enable it to see that it works on at least > one machine ? > > Yes, we have this option enabled in production since a few days after this mail: https://www.varnish-cache.org/lists/pipermail/varnish-dev/2015-September/008496.html We are using Linux 3.18.11 and varnish 4.1 (we had 4.0.3 before the 4.1 stable release). If you need more information just mail me. From phk at phk.freebsd.dk Wed Oct 14 10:23:25 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 Oct 2015 10:23:25 +0000 Subject: [PATCH] Expose accept_filter parameter to Linux In-Reply-To: <20151013151856.51359fdd@taghos.com.br> References: <18037.1444757935@critter.freebsd.dk> <20151013151856.51359fdd@taghos.com.br> Message-ID: <21454.1444818205@critter.freebsd.dk> -------- In message <20151013151856.51359fdd at taghos.com.br>, Rafael Zalamena writes: >> Did somebody actually try to enable it to see that it works on at least >> one machine ? > >Yes, we have this option enabled in production [...] >We are using Linux 3.18.11 and varnish 4.1 (we had 4.0.3 before the 4.1 >stable release). > >If you need more information just mail me. Is it faster/better ? -- 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 rafaelfz at taghos.com.br Wed Oct 14 16:11:48 2015 From: rafaelfz at taghos.com.br (Rafael Zalamena) Date: Wed, 14 Oct 2015 13:11:48 -0300 Subject: [PATCH] Expose accept_filter parameter to Linux In-Reply-To: <21454.1444818205@critter.freebsd.dk> References: <18037.1444757935@critter.freebsd.dk> <20151013151856.51359fdd@taghos.com.br> <21454.1444818205@critter.freebsd.dk> Message-ID: <20151014131148.47addf53@taghos.com.br> On Wed, 14 Oct 2015 10:23:25 +0000 Poul-Henning Kamp wrote: > -------- > In message <20151013151856.51359fdd at taghos.com.br>, Rafael Zalamena writes: > > > >> Did somebody actually try to enable it to see that it works on at least > >> one machine ? > > > >Yes, we have this option enabled in production [...] > >We are using Linux 3.18.11 and varnish 4.1 (we had 4.0.3 before the 4.1 > >stable release). > > > >If you need more information just mail me. > > Is it faster/better ? > It might not be faster (in response time), but it is better in resources usage. There is a notable lower cpu usage due to the decreased number of syscalls in busy workloads with many new connections per second. From martin at varnish-software.com Fri Oct 23 13:55:37 2015 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Fri, 23 Oct 2015 15:55:37 +0200 Subject: [PATCH] Log proxy related messages on the session, not on the request. Message-ID: <1445608537-8801-1-git-send-email-martin@varnish-software.com> The proxy log records were attempted to be logged on the request' log buffer, which at that point in time has not yet been set up and does not posess a VXID. This caused VXID==0 log records to be inserted in the beginning of the log for the first request on the session when using proxy protocol, and subsequently the VSL to fail picking them out as valid request log transactions. Fix by logging the PROXY handling related messages on the session, in which they belong. Fixes: #1804 --- bin/varnishd/proxy/cache_proxy_proto.c | 34 +++++++++++++++-------------- bin/varnishtest/tests/r01804.vtc | 39 ++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+), 16 deletions(-) create mode 100644 bin/varnishtest/tests/r01804.vtc diff --git a/bin/varnishd/proxy/cache_proxy_proto.c b/bin/varnishd/proxy/cache_proxy_proto.c index 433581e..954beef 100644 --- a/bin/varnishd/proxy/cache_proxy_proto.c +++ b/bin/varnishd/proxy/cache_proxy_proto.c @@ -62,8 +62,9 @@ vpx_proto1(const struct worker *wrk, struct req *req) CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC); CHECK_OBJ_NOTNULL(req, REQ_MAGIC); + CHECK_OBJ_NOTNULL(req->sp, SESS_MAGIC); - VSL(SLT_Debug, req->sp->fd, "PROXY1"); + VSL(SLT_Debug, req->sp->vxid, "PROXY1"); q = strchr(req->htc->rxbuf_b, '\r'); if (q == NULL) @@ -80,7 +81,7 @@ vpx_proto1(const struct worker *wrk, struct req *req) for (i = 0; i < 5; i++) { p = strchr(p, ' '); if (p == NULL) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: Too few fields"); return (-1); } @@ -89,7 +90,7 @@ vpx_proto1(const struct worker *wrk, struct req *req) } if (strchr(p, ' ')) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: Too many fields"); return (-1); } @@ -102,7 +103,7 @@ vpx_proto1(const struct worker *wrk, struct req *req) else if (!strcmp(fld[0], "TCP6")) pfam = AF_INET6; else { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: Wrong TCP[46] field"); return (-1); } @@ -113,14 +114,14 @@ vpx_proto1(const struct worker *wrk, struct req *req) i = getaddrinfo(fld[1], fld[3], &hints, &res); if (i != 0) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: Cannot resolve source address (%s)", gai_strerror(i)); return (-1); } AZ(res->ai_next); if (res->ai_family != pfam) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: %s got wrong protocol (%d)", fld[0], res->ai_family); freeaddrinfo(res); @@ -134,14 +135,14 @@ vpx_proto1(const struct worker *wrk, struct req *req) i = getaddrinfo(fld[2], fld[4], &hints, &res); if (i != 0) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: Cannot resolve destination address (%s)", gai_strerror(i)); return (-1); } AZ(res->ai_next); if (res->ai_family != pfam) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY1: %s got wrong protocol (%d)", fld[0], res->ai_family); freeaddrinfo(res); @@ -151,7 +152,7 @@ vpx_proto1(const struct worker *wrk, struct req *req) AN(VSA_Build(sa, res->ai_addr, res->ai_addrlen)); freeaddrinfo(res); - VSLb(req->vsl, SLT_Proxy, "1 %s %s %s %s", + VSL(SLT_Proxy, req->sp->vxid, "1 %s %s %s %s", fld[1], fld[3], fld[2], fld[4]); req->htc->pipeline_b = q; return (0); @@ -182,6 +183,7 @@ vpx_proto2(const struct worker *wrk, struct req *req) CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC); CHECK_OBJ_NOTNULL(req, REQ_MAGIC); + CHECK_OBJ_NOTNULL(req->sp, SESS_MAGIC); assert(req->htc->rxbuf_e - req->htc->rxbuf_b >= 16L); l = vbe16dec(req->htc->rxbuf_b + 14); @@ -191,7 +193,7 @@ vpx_proto2(const struct worker *wrk, struct req *req) /* Version @12 top half */ if ((p[12] >> 4) != 2) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY2: bad version (%d)", p[12] >> 4); return (-1); } @@ -205,7 +207,7 @@ vpx_proto2(const struct worker *wrk, struct req *req) /* Proxied connection */ break; default: - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY2: bad command (%d)", p[12] & 0x0f); return (-1); } @@ -214,14 +216,14 @@ vpx_proto2(const struct worker *wrk, struct req *req) switch(p[13]) { case 0x00: /* UNSPEC|UNSPEC, ignore proxy header */ - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY2: Ignoring UNSPEC|UNSPEC addresses"); return (0); case 0x11: /* IPv4|TCP */ pfam = AF_INET; if (l < 12) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY2: Ignoring short IPv4 addresses (%d)", l); return (0); } @@ -230,14 +232,14 @@ vpx_proto2(const struct worker *wrk, struct req *req) /* IPv6|TCP */ pfam = AF_INET6; if (l < 36) { - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY2: Ignoring short IPv6 addresses (%d)", l); return (0); } break; default: /* Ignore proxy header */ - VSLb(req->vsl, SLT_ProxyGarbage, + VSL(SLT_ProxyGarbage, req->sp->vxid, "PROXY2: Ignoring unsupported protocol (0x%02x)", p[13]); return (0); } @@ -286,7 +288,7 @@ vpx_proto2(const struct worker *wrk, struct req *req) SES_Set_String_Attr(req->sp, SA_CLIENT_IP, hb); SES_Set_String_Attr(req->sp, SA_CLIENT_PORT, pb); - VSLb(req->vsl, SLT_Proxy, "2 %s %s %s %s", hb, pb, ha, pa); + VSL(SLT_Proxy, req->sp->vxid, "2 %s %s %s %s", hb, pb, ha, pa); return (0); } diff --git a/bin/varnishtest/tests/r01804.vtc b/bin/varnishtest/tests/r01804.vtc new file mode 100644 index 0000000..c6705eb --- /dev/null +++ b/bin/varnishtest/tests/r01804.vtc @@ -0,0 +1,39 @@ +varnishtest "#1804: varnishapi transaction grouping fails for PROXY" + +server s1 { + rxreq + txresp +} -start + + +varnish v1 -proto "PROXY" -vcl+backend { +} -start + +logexpect l1 -v v1 -d 0 -g session { + expect * * Begin {^sess .* PROXY$} + expect * = Proxy {^1 } + expect * * Begin {^req} + expect * * Begin {^sess .* PROXY$} + expect * = Proxy {^2 } + expect * * Begin {^req} +} -start + +client c1 { + send "PROXY TCP4 1.2.3.4 5.6.7.8 1234 5678\r\n" + txreq + rxresp +} -run + +client c2 { + # good IPv4 + sendhex "0d 0a 0d 0a 00 0d 0a 51 55 49 54 0a" + sendhex "21 11 00 0c" + sendhex "01 02 03 04" + sendhex "05 06 07 08" + sendhex "09 0a" + sendhex "0b 0c" + txreq + rxresp +} -run + +logexpect l1 -wait -- 2.1.4 From geoff at uplex.de Fri Oct 23 14:21:10 2015 From: geoff at uplex.de (Geoff Simmons) Date: Fri, 23 Oct 2015 16:21:10 +0200 Subject: VMODs: PRIV_VCL objects and the event function's priv object Message-ID: <562A4256.9030306@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello all, Are those two things the same object, by any chance? That is, when a VMOD has functions or methods with a PRIV_VCL parameter, and also implements the event function, do the *vmod_priv's passed into their implementations point to the same location, per VCL instance? (Seems like it would be a good idea.) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWKkJWAAoJEOUwvh9pJNURrIYP/RS3FkCiINWGJrnv9UiiUbcI m4nB27Xtirh/q4cWfXkoPJ6V0rlNah5FnkwWeRBF9akbAa0mAl3eMUqZ6tNa3vY9 Y+0hcvjB0WwSEkBmVOUyDF4KO1HfxvQ+Cwh9UF11oFqBMlf28E57nNAbvNW8QmM/ Y8qyexd8CWDQ6Fan7/LOCEoiwOQByLEy2uOGRWFSty+FDgQp+T0EbhgdhuomUQuC WRGmzBMJUfeuLpEiNOEduWtxjNJnLmuAkAGUB15fIGqVx73hMhfC8wc7V9XAlo1D uJdxfM3tcxxST7jlyFIH74aZsOx5RwC1/VioRY/Lo1FkZvCwfLXPjkqbupuZSmyO a6UiC1ntKwHdK+sg9fwc2KXrXyRvW0xv7pGq9+1kvPyqQ0djk5/xisuB+JIfCLke /2qczd2mG5Z5utbsfv1hQyNKLiytGc4sGxx5QQ+cNeJbDo1n4jvnZUJKbPMqHqmN y1QH8DDzEWgi/BYEp1nCzC5E8vjRssn69hfPk8NK4lMczmGqVJ3S5lnrokgG5npp DXl9l2VF6D0e12E9w9Yovo8JK/nUFB04lurWesZzftKxKoyxQQ6RwtJpMIkL4aE2 STdxsHHk2kDmAswRnbGAeuiEPp1GBoAQ8oGNBEdmCYUqn3bXEoyRnipjeMLjoQYq nrSAjyq4dIHbOIqIDTLk =Q2XO -----END PGP SIGNATURE----- From daghf at varnish-software.com Sun Oct 25 18:38:39 2015 From: daghf at varnish-software.com (Dag Haavi Finstad) Date: Sun, 25 Oct 2015 19:38:39 +0100 Subject: VMODs: PRIV_VCL objects and the event function's priv object In-Reply-To: <562A4256.9030306@uplex.de> References: <562A4256.9030306@uplex.de> Message-ID: Hey Geoff They are indeed the same. The vmod_priv object passed to the event function is the PRIV_VCL object for that VMOD. On Fri, Oct 23, 2015 at 4:21 PM, Geoff Simmons wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello all, > > Are those two things the same object, by any chance? > > That is, when a VMOD has functions or methods with a PRIV_VCL > parameter, and also implements the event function, do the *vmod_priv's > passed into their implementations point to the same location, per VCL > instance? > > (Seems like it would be a good idea.) > > > 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJWKkJWAAoJEOUwvh9pJNURrIYP/RS3FkCiINWGJrnv9UiiUbcI > m4nB27Xtirh/q4cWfXkoPJ6V0rlNah5FnkwWeRBF9akbAa0mAl3eMUqZ6tNa3vY9 > Y+0hcvjB0WwSEkBmVOUyDF4KO1HfxvQ+Cwh9UF11oFqBMlf28E57nNAbvNW8QmM/ > Y8qyexd8CWDQ6Fan7/LOCEoiwOQByLEy2uOGRWFSty+FDgQp+T0EbhgdhuomUQuC > WRGmzBMJUfeuLpEiNOEduWtxjNJnLmuAkAGUB15fIGqVx73hMhfC8wc7V9XAlo1D > uJdxfM3tcxxST7jlyFIH74aZsOx5RwC1/VioRY/Lo1FkZvCwfLXPjkqbupuZSmyO > a6UiC1ntKwHdK+sg9fwc2KXrXyRvW0xv7pGq9+1kvPyqQ0djk5/xisuB+JIfCLke > /2qczd2mG5Z5utbsfv1hQyNKLiytGc4sGxx5QQ+cNeJbDo1n4jvnZUJKbPMqHqmN > y1QH8DDzEWgi/BYEp1nCzC5E8vjRssn69hfPk8NK4lMczmGqVJ3S5lnrokgG5npp > DXl9l2VF6D0e12E9w9Yovo8JK/nUFB04lurWesZzftKxKoyxQQ6RwtJpMIkL4aE2 > STdxsHHk2kDmAswRnbGAeuiEPp1GBoAQ8oGNBEdmCYUqn3bXEoyRnipjeMLjoQYq > nrSAjyq4dIHbOIqIDTLk > =Q2XO > -----END PGP SIGNATURE----- > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev -- Dag Haavi Finstad Software Developer | Varnish Software Mobile: +47 476 64 134 We Make Websites Fly! From guillaume at varnish-software.com Mon Oct 26 10:04:39 2015 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Mon, 26 Oct 2015 11:04:39 +0100 Subject: [PATCH] Remove check in REPLACE Message-ID: free(NULL) is already a nop. (Based on Dag's remark during a review on some other code) -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-unnecessary-check.patch Type: text/x-patch Size: 649 bytes Desc: not available URL: From phk at phk.freebsd.dk Mon Oct 26 10:26:19 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 26 Oct 2015 10:26:19 +0000 Subject: [PATCH] Remove check in REPLACE In-Reply-To: References: Message-ID: <3272.1445855179@critter.freebsd.dk> -------- In message , Guillaume Quintard writes: OK. >--089e011606c80a63d10522ff1875 >Content-Type: multipart/alternative; boundary=089e011606c80a63c90522ff1873 > >--089e011606c80a63c90522ff1873 >Content-Type: text/plain; charset=UTF-8 > >free(NULL) is already a nop. > >(Based on Dag's remark during a review on some other code) > >-- >Guillaume Quintard > >--089e011606c80a63c90522ff1873 >Content-Type: text/html; charset=UTF-8 > >
free(NULL) is already a nop.

(Based on Dag's remark during a review on some other code)

--
Guillaume Quintard
>
> >--089e011606c80a63c90522ff1873-- >--089e011606c80a63d10522ff1875 >Content-Type: text/x-patch; charset=US-ASCII; name="0001-Remove-unnecessary-check.patch" >Content-Disposition: attachment; > filename="0001-Remove-unnecessary-check.patch" >Content-Transfer-Encoding: base64 >X-Attachment-Id: f_ig7ryaub0 > >RnJvbSA1ODMwZDE4OTAxNGQyNjI1MjEyZGRjN2IzOWIzZDBjNDk0ZDQxYzNlIE1vbiBTZXAgMTcg >MDA6MDA6MDAgMjAwMQpGcm9tOiBHdWlsbGF1bWUgUXVpbnRhcmQgPGd1aWxsYXVtZUB2YXJuaXNo >LXNvZnR3YXJlLmNvbT4KRGF0ZTogTW9uLCAyNiBPY3QgMjAxNSAxMDo1OTowNSArMDEwMApTdWJq >ZWN0OiBbUEFUQ0hdIFJlbW92ZSB1bm5lY2Vzc2FyeSBjaGVjawoKLS0tCiBpbmNsdWRlL21pbmlv >YmouaCB8IDMgKy0tCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDIgZGVsZXRpb25z >KC0pCgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9taW5pb2JqLmggYi9pbmNsdWRlL21pbmlvYmouaApp >bmRleCAzZGU0MDkxLi44YjRmMDQzIDEwMDY0NAotLS0gYS9pbmNsdWRlL21pbmlvYmouaAorKysg >Yi9pbmNsdWRlL21pbmlvYmouaApAQCAtNjEsOCArNjEsNyBAQAogCiAjZGVmaW5lIFJFUExBQ0Uo >cHRyLCB2YWwpCQkJCQkJXAogCWRvIHsJCQkJCQkJCVwKLQkJaWYgKChwdHIpICE9IE5VTEwpCQkJ >CQlcCi0JCQlmcmVlKHB0cik7CQkJCQlcCisJCWZyZWUocHRyKTsJCQkJCQlcCiAJCWlmICgodmFs >KSAhPSBOVUxMKSB7CQkJCQlcCiAJCQlwdHIgPSBzdHJkdXAodmFsKTsJCQkJXAogCQkJQU4oKHB0 >cikpOwkJCQkJXAotLSAKMi42LjIKCg== >--089e011606c80a63d10522ff1875 >Content-Type: text/plain; charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >_______________________________________________ >varnish-dev mailing list >varnish-dev at varnish-cache.org >https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev >--089e011606c80a63d10522ff1875-- > -- 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 arianna.aondio at varnish-software.com Mon Oct 26 12:32:52 2015 From: arianna.aondio at varnish-software.com (Arianna Aondio) Date: Mon, 26 Oct 2015 13:32:52 +0100 Subject: [PATCH] PRIV pointers available in vmod obj methods Message-ID: Hi, as discussed at bugwash today, I'm posting a patch that makes private pointers(PRIV_TASK, PRIV_TOP, PRIV_VCL) available in VMODS objects. Please refer to trac ticket #1800 for more details. -- Arianna Aondio Software Developer | Varnish Software AS Mobile: +47 98062619 We Make Websites Fly www.varnish-software.com -------------- next part -------------- A non-text attachment was scrubbed... Name: trac_1800.patch Type: text/x-diff Size: 9525 bytes Desc: not available URL: From geoff at uplex.de Mon Oct 26 12:58:10 2015 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 26 Oct 2015 13:58:10 +0100 Subject: [PATCH] PRIV pointers available in vmod obj methods In-Reply-To: References: Message-ID: <562E2362.2050104@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/26/2015 01:32 PM, Arianna Aondio wrote: > Hi, as discussed at bugwash today, I'm posting a patch that makes > private pointers(PRIV_TASK, PRIV_TOP, PRIV_VCL) available in VMODS > objects. Please refer to trac ticket #1800 for more details. As mentioned in the ticket, the patch has tests for the use of PRIV_TASK in an object method, but none for PRIV_TOP or PRIV_VCL. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWLiNiAAoJEOUwvh9pJNURbtYQAKw5CwnrBdDGd4vlCyLnT8kB n1eg4rzpI2KbIw7xOYEzw96GIN1Z8fddzb/ANr4lQxV+lwaa1OtXCC/sjaU5ohcx Ow9+kcA4vxF08QtNKMt9+WmcxIipYkeTNmSo+sULcQCVSCpTcQP32tg4ll1QVL4T s/17s+FOuoRUZwphEGuV/82XCCOu/ZRILzP9UGbQ988guiJvftePd9veAQj42M0E CwoDcJWSkL98ZT57vR1v5O6ycEprjYAil3RkRMZ2b8vFrucYee/gSsIEHiRaD/DB EEHzdlxpvkOaXwhclBVV3kYMKDJKSEPfpQM0203usz4G6rFIObbt5myZ5Keeir/S vaX55ICpdIMRFgBFB558WlVjE1uW8JP4KhbJO2v2hcCNm2C2W/FOpANTYP1djUi9 PTAvwURZvK8y4tIepF5anH3WkvaO+6TQc5mQTc0bib7YFUq4EJKIuWLvjPouCTFQ d7DDwslKbolIunbl+EvIjts66c5zADI3FEgO6TSCZ6Cg4a6i0CC2BJ2C5OtgQP3f aUruc6ZrAVp5T1318s6CTQnyKPwgw8Erf9sqObbCN9yewZXadtgvl9cPUtjLoYYi DoINhItcvEDpwxsRmIfin6PsujgPihEL1RU8qZcpF912DDUleuwvelzJ4d8I/C1h T89grx0bvDHklwckq3C9 =ZWoj -----END PGP SIGNATURE----- From geoff at uplex.de Mon Oct 26 15:31:02 2015 From: geoff at uplex.de (Geoff Simmons) Date: Mon, 26 Oct 2015 16:31:02 +0100 Subject: Preventing dup backend names with dynamic backends in VMODs Message-ID: <562E4736.5030708@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello all, I'd like to get back to some questions I asked in IRC earlier today. I guess I didn't make the problem clear, so let me try to explain why I think this is critical. struct director has the fields vcl_name and name, and struct backend has the field display_name -- when a backend is statically declared as "backend foo", those fields are all derived from "foo". Some uses for backend names are: display in backend.list; the strings against which a backend.set_health expression are matched; and construction of stats in the VBE.* namespace. Prior to 4.1, it was impossible for a VCL to have two backends with the same name, because the VCC compiler doesn't allow it. Now that backends are VMOD-able, they can be created dynamically at runtime, with any name you like. The points I want to make are: a serious implementation of dynamic backends would have to enforce the same restriction, no two backends with the same name per VCL; but it can't, because there's no way for a VMOD to determine if a backend with a certain name already exists in a VCL. I tried it out, and varnishd in fact has no problem using backends when there are duplicate names, since they are known internally by pointers to struct backend, which of course are distinct regardless of the name fields. So with something like this: import backend_dyn; backend be { .host="${s1_addr}"; .port="${s1_port}"; } sub vcl_backend_fetch { set bereq.backend = backend_dyn.create(name="be", host="${s2_addr}", port="${s2_port}"); } ... Varnish sends requests to the backend at s2_addr:s2_port and receives responses just fine. The problems are: - - The VBE.* stats don't seem to work correctly. For the above, I see VBE.vcl1.be.bereq_hdrbytes and .beresp_hdrbytes both == 0 after the backend has answered requests, but both >0 when the backend names are different. - - backend.list shows two backends with the same name, and you can't tell them apart. If one of them goes sick while the other is healthy, no telling which is which. - - There's no way to use an expression in backend.set_health that would change the health status of one but not the other. All of which are intolerable for operations and automatizations that depend on these things. So, a VMOD would almost certainly want to raise an error in this situation. But unless I'm missing something, it can't, because there's currently no interface available to a VMOD that tells you if a VCL already has a certain backend name. struct vcl is private to cache_vcl.c, so a VMOD can't inspect it's backend_list. And I don't see any function call that will do the job, not even in cache_priv.h (presumably because this has never been an issue before). Am I seeing this right? If so, I'd suggest adding something like VCL_HasBackend(vcl,name), and would be happy to submit a patch. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWLkc2AAoJEOUwvh9pJNURrrkP/2GoFo/0BekhUugLmt8XECmO +BnyWEMoe5SfQ+enIfz8dR0pIhsNZ3bDQ8hWQ6+bYxsdBc/AcrDnXiYT1Ia47YyR up1Q4HLNEEVuR+OjrbehuZ6Gg9kvn3UoxtS7FMfkC2z/w295MoK+eNcnGVgmTuHj HxzN/6odynKcU2dL7lEiXjuWaIPOmW0bP9vIwo6j83BJUHOS5QM/IbY2B0vCAmnk mNJaNerynmMne+eIRAxK5gHJb4zudIkNkiLbqQEjN2W5+iI8HNUqHqaIlNz/0/av 83JQOOzfF9nq+hgX6ZYZwUApbV2PbB/Vt/yuX0kr5EkBEBspZymVcBq/HNyiE4BT pHcHf6te/kVVVNaqwTbOWMG1zWggE0VeXRi+rgVSA41wv7xoDthAvS495V/gsL7N x8gJ3i/NSt7QFPC+4/UPwb8vnNu3bsUzkzvnRJ2pRIeaOEwT3wyYK1y4lqNviAav g1+O+wrnZCKu3Yd6j5GV1Q2tgVGJa33u41lc4UWW+7LlhstjS/UPLv4/rJrtOxgf mltzZuKNBTmUiPtzMjdTsbUSmWl7AGK4Jd2eHiq5dswJX/85UPUZbf7+/l30oiMh rkwM+h9yQYdNtV6FUDPK2D70bp0ndW1y5h/biKF+4+sr4dDl1o4JG+sY5HA7y9V6 2UPeAXdy0vcSLoSSANwm =8uwn -----END PGP SIGNATURE----- From phk at phk.freebsd.dk Tue Oct 27 12:25:29 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 27 Oct 2015 12:25:29 +0000 Subject: Preventing dup backend names with dynamic backends in VMODs In-Reply-To: <562E4736.5030708@uplex.de> References: <562E4736.5030708@uplex.de> Message-ID: <8599.1445948729@critter.freebsd.dk> Good catch Geoff. Yes, uniqueness of backend names affect only CLI and VSM. The former only if people get confused, the latter always because the VSM counter segment is named based on the backend name, so the two will clash. We've never had a really good model for backend names and we're probably about to make it even worse with dynamic backends. To _truly_ identify a backend, you need to know: VCL name (Soon: .. or global) VMOD name VMOD object name VMOD object instance (= vcl name of instantiated object) Backend name IPv4 IPv6 Needless to say, that doesn't work. (Previously we used {backend name, ipv4, ipv6} that didn't work either, and since then we grew vmods and dynamic backends.) My current thinking is that we'll name the backend whatever the user/vcl/vmod writer likes (ie: Backend name), and deal with the fall-out. That really only leaves one question: What do we do when some code tries to add a backend with a name which already exists. One option is to fail the backend creation, but since it is only CLI/VSM that can get confused, that seems too draconian to me. So I'm tempted to simply add a ".%d" suffix for ever increasing %d's until the name becomes unique. Would that work for people ? Poul-Henning PS: I also noted that backend names can become quite unwieldy, so it might be a good idea to give all backends a serial number which appears in CLI output, and can be used in CLI commands to refer to a particular backend. -- 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 Oct 27 14:48:28 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 27 Oct 2015 14:48:28 +0000 Subject: Varnish project autumn cleaning Message-ID: <28767.1445957308@critter.freebsd.dk> After some private consultations, this email is being sent to the -dev list, for notice and comment. After we have hashed it out here, I will write it up for announce@ and the world at large. As I have mentioned to a lot of you already, I have some changes in mind for the Varnish Project after 4.1-R and I am busy these days trying to get from "in mind" to "a plan". There are a number of drivers for this, which I will just quickly sketch out. (If you want more details, I can flesh it out further in the subsequent discussions, this email is long enough as it is.) The reasons =========== 1. We've gone from DevOps to Developers --------------------------------------- This is most evident in 4.1-R being so delayed mainly because of lack of real-life testing. Becuase none of the central group of developers actually run a Varnish production site, we have to persuade other people to do live tests for us. This means we cannot use the same "QA" strategy we did previously and that must be reflected in our release process. 2. The workshop have become cluttered ------------------------------------- The Trac wiki has become Hotel California. Patchwork never really worked for us. The Forum isn't exactly a noted social venue. The project homepage looks a lot like an advertising front end for Varnish Software - not from any sinister plan or hostile intent, but simply from the lack of any other content to put there. And to top it off we're stilling running Varnish version 3.0.something on varnish-cache.org. It's time to clean up the workshop, and prepare it for the next stretch of the projects life. 3. I don't have any live Varnish instances ------------------------------------------ Well, I *do* have one, but a search-engine request every 10 seconds is not enough for me to be well informed about choices in varnish development. In particular for the H2 development I need to be able to see what happens in real life. This has been a major annoyance for me during 4.1 but it will turn into a major problem developing H2 support, without any access to real-life traffic. 4. Varnish-Software and Varnish-Cache are too close --------------------------------------------------- This is a lot more perception than reality, but various people are concerned. It is well established that the perception that corruption *could* happen is as bad for confidence as actual corruption happening, so their concerns are not unreasonable. I want to make the distinction between V-S and V-C.O much more clear. A major sticking point is the project homepage, which V-S has been so kind to maintain for the project until now, but which therefore also looks a little bit too much like a V-S subsidiary. I don't mind giving major shoutouts to the various Varnish companies on the V-C.O homepage, but it needs to serve the project at least as much as the companies. So given these reasons, here is the plan I've come up with: The plan ======== 1. Release by date ------------------ In the future we will do two *major* Varnish releases a year, and we will put them in the calendar at least 6 months ahead of time. Whatever is in the tree and whatever works on that date will be in that release. If some feature or bug-fix isn't ready, it won't be in that release. The good news is that it will only have to wait six months for the next major release, and there may be minor releases before that. We make this change because we are no longer able, as developers, to run/orchestrate a comprehensive test-campaign before releases, and therefore we have to make it possible for our users to do this for us. By putting releases into the calendar rather than the wish-list, our users can plan ahead, and we minimize the consequence in terms of time if/when one of our releases turns out to be a "dud". We are not going to give any similar guarantees for *minor* releases, which we will roll out as needs arise. 2. Tool cleanup --------------- The Trac software has become a liability, and we want to get rid of it. In particular fighting spammers is a drain. The repository itself will move to github. Unless anybody has better ideas, Bugtracking will move to github also. I'm currently disinclined to have a Wiki in the future, it seems to never really have worked for us. If we later find out we need one, github or Wikia are obvious solutions. Patchwork will be discontinued. Either we fall back to patches on the -dev mailing list or github pull-requests or possibly both. We'll find out what works best. Personally I do like to use -dev because it works offline for me, and because it preserves the history in the mail-archives. The varnish-cache.org homepage will be generated from doc/sphinx in the repository, that saves us a CMS and a database. If we later find out we need something stronger, we can do that. The homepage will revert to a classic "here is our software, here is the doc, here is what's happening" FOSS project homepage, with due shoutouts to the rest of the Varnish community. By generating it out of doc/sphinx, all committers get ability to push content to the home page. I hope they do, time will show. In that respect, I will be happy to hand out commit bits for people who want to help maintain the home-page, (similar to FreeBSD's src/ports/doc distinctions). Jenkins seems to work, no need to do anything at present as far as I can tell. Coverity has never really struck gold for us, but it's simple for us to use and having the dog not bark works for me. As far as I can tell, the forum is not very productive, and it might be a better idea to focus that activity on Stackoverflow or similar, where the chances of more user-to-user support is higher. The mailing lists seems to work, as well as mailing lists can be expected to, and will be continued basically unchanged. The IRC channels also seems to work, we'll keep those. It's been suggested we move to a "real" IRC network, but that has both up and downsides in my view. 3. Growing up, moving out ------------------------- After careful consideration, I have reached the conclusion that it is high time Varnish-Cache.org moves away from its childhood home at Varnish-Software.com. There are no ill feelings intended on my part, I'm very grateful for all the time V-S has spent on the projects server, software and tools. But the time has simply come where co-habitation no longer is the best solution for either party. As V-S grew their company, they have chosen a strategy for their infrastructure which makes the project server the odd-ball box in the corner and the necessary exceptions and special rules for the V-C.O stuff have become a PITA for their sysadmins. Seen from the project point of view, the perfectly sensible limitations imposed by V-S corporate needs limits what we can do, and we are constrained by availability of time and resources at V-S. And there is that perception thing also. So it's time for the project to move out. Initially I will put up a new project server in my own lab, because it is cheap, accessible (which is important during the transition) and by definition neutral ground for the project. Once we've come through the transition and things have been shaken out and settled down, that server will be migrated to some friendly hosting service, affordable on the VML funds. It's important for me that this does not decrease the bus-quotient of the project to 1.0, so I still want to have a couple of "co-roots" for this machine. Making the transition ===================== Lasse has started an etherpad with notes, ideas and tasks, so there is no reason to repeat there here, go there instead: https://etherpad.wikimedia.org/p/vc-github-move We are not planning a "big-bang" transition, but rather taking it bit for bit as we go. Moving the repo to github will be the most visible part, but (famous last word candidate:) we don't foresee any trouble. My guess is that the order will roughly be: * Create github repo, slave it of existing repo. * Flip order: New github becomes master, existing repo becomes slave * Tell developers to push to new master repo. * Migrate (open) Trac tickets to github manually, or if the scripts Lasse found works: Migrate all tickets to github. Set Trac Read-Only. * Announce that future tickets must be opened on github. * Settling down period. * Close down patchwork * I (and others) create the future project homepage under doc/sphinx. * New homepage goes live on new project server. * Rescue whatever content deserves rescuing from Trac's Wiki * Close down Trac * Move mailing lists to new project server. ... or something like that. In total it will probably take quite some weeks before we're at the bottom of the list, which is why I'm not sweating the details too much yet. Summary ======= This is not a political issue. There are no hard feelings anywhere (I hope). It is simply me paying some long overdue attention to the FOSS project around the software, I hope you all agree and will help make this reorg as uneventful as possible. 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 geoff at uplex.de Tue Oct 27 15:01:46 2015 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 27 Oct 2015 16:01:46 +0100 Subject: Preventing dup backend names with dynamic backends in VMODs In-Reply-To: <8599.1445948729@critter.freebsd.dk> References: <562E4736.5030708@uplex.de> <8599.1445948729@critter.freebsd.dk> Message-ID: <562F91DA.8010104@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/27/2015 01:25 PM, Poul-Henning Kamp wrote: > > Yes, uniqueness of backend names affect only CLI and VSM. > > The former only if people get confused, the latter always because > the VSM counter segment is named based on the backend name, so the > two will clash. Something else I thought of since yesterday -- the backend names used in VSL for entries like Backend, BackendOpen, BackendClose and so forth. If you're using the log to diagnose a problem, doesn't help much to have to wonder which backend it's talking about. > My current thinking is that we'll name the backend whatever the > user/vcl/vmod writer likes (ie: Backend name), and deal with the > fall-out. At the very least, VMODs should have a way to discover if a backend name is already in use by a VCL -- the VCL_HasBackend(vcl,name) idea. Then a VMOD can choose to raise an error for duplicate names. Maybe add a sentence or two to the "Writing a Director" doc about backend names, what they're used for, and why this could be a problem. > That really only leaves one question: What do we do when some > code tries to add a backend with a name which already exists. > > One option is to fail the backend creation, but since it is only > CLI/VSM that can get confused, that seems too draconian to me. > > So I'm tempted to simply add a ".%d" suffix for ever increasing > %d's until the name becomes unique. > > Would that work for people ? If you thought that you called your backend "be", and then see "be.1" and "be.2" in backend.list, VSL, VBE.* stats and so forth, is it really any less confusing? The order would be probably result from which backend was created first, which may be difficult or impossible to determine after the fact. That would have the advantage that one set of VSC stats doesn't get lost altogether. So I guess the choices are: be draconian, or permit a situation that will probably create confusion, however much we try to minimize it. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWL5HaAAoJEOUwvh9pJNUR1OsQALGdQ5Dn/kDeBZkGymKX31z6 4/Z60CHK1lPMPsHJKumxLGp7D2deN00XmygecYshUBjjM26rnSg1f1JhFlwIMd9t Nb678+Zi3HXoOPJ+5a1KLjMSHfpqb95xZ9S0GR7B8eAHj4fZqKJWTPk5L0CRdeI3 ISxls4/OAmrHqccH/7RILbcwX/vQo/Za7HnPkgiABq9sts18HoLZik4Wrys7jjrR XtnKKI0TXchzxvOH+uzpSE+zVZWfGTWalK8RtyQw/+8nV7gWvtlkSmlYDJ6IMrGR buwf0GJPHGD8OSk2MHyBg3Z3JO3EuqiPK/sGGDPQZcCcjw9bSSwQlD0z+r9CjVcN FzjeH/3iRhFIYMsDoplxyPj1h9FcjyjPGTlJutnvlDsny1Mes8I0Rm2B8ilJL5GT wDHgduDsjh/IEi3sIes5Baj5rKPxTO1aOHg6iALIuZiExmcZ6f5XD54e1I2MYszW ypGWDDZcnwuvBVzplwQo/swUnKBu+I9gTVKkUqq5bQfZMUrCZ/wE/7SfqXJqBZfW JI6k28mxL8WZyO0HH5iWhfDr3QxYrumBYZPIAHEzHEkXSo5JfH0e4sMF31mfVJ21 2WzcdGZfeAilAzGJHALYGX9/HK8Hf9Bimw808V3vrdyZNBbpE+XyX8L52Qlur4pL sGt66SERJ3V0J9ULMZbO =6WOa -----END PGP SIGNATURE----- From lkarsten at varnish-software.com Tue Oct 27 16:14:28 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 27 Oct 2015 17:14:28 +0100 Subject: Varnish project autumn cleaning In-Reply-To: <28767.1445957308@critter.freebsd.dk> References: <28767.1445957308@critter.freebsd.dk> Message-ID: <20151027161427.GA1274@immer.varnish-software.com> On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: [cut] > I'm currently disinclined to have a Wiki in the future, it seems > to never really have worked for us. If we later find out we need > one, github or Wikia are obvious solutions. The wiki doesn't work because we've turned off user registrations to combat spammers. I strongly believe we should revive it when we have the chance. (==github move) It is a natural place to keep information that is too specific to go into the main documentation, or too small of a detail to warrant a documentation commit. Just making a (living) FAQ that we can use in #varnish for the normal questions would be a big improvement. I'm happy to take point on this, if that is what it is needed. -- Lasse Karstensen From kacperw at gmail.com Tue Oct 27 17:24:35 2015 From: kacperw at gmail.com (Kacper Wysocki) Date: Tue, 27 Oct 2015 18:24:35 +0100 Subject: Varnish project autumn cleaning In-Reply-To: <20151027161427.GA1274@immer.varnish-software.com> References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> Message-ID: On Tue, Oct 27, 2015 at 5:14 PM, Lasse Karstensen wrote: > On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: > [cut] >> I'm currently disinclined to have a Wiki in the future, it seems >> to never really have worked for us. If we later find out we need >> one, github or Wikia are obvious solutions. > > The wiki doesn't work because we've turned off user registrations > to combat spammers. > > I strongly believe we should revive it when we have the chance. (==github move) > > It is a natural place to keep information that is too specific to go > into the main documentation, or too small of a detail to warrant a > documentation commit. > > Just making a (living) FAQ that we can use in #varnish for the normal > questions would be a big improvement. I'm happy to take point on this, > if that is what it is needed. So good to hear that revamping the site will be a priority going forward. I'm happy to help in any way that I can. I agree with Lasse that the wiki has an important place as a living document, and that a whole lot of VCL snippets and varnish tricks are ending up on Other Peoples Blogs? because the trac wiki has been broken (by spammers). It may be useful in the future to give someone the wiki-admin-hat so they can mark out-of-date content, avoiding the old issue of vcl snippets for Varnish 2.0 still floating about. That being said, getting a nicer ticketing system would be super sweet and the old ticket system is definitely the first thing to deserve a bullet. cheers, 0K From fgsch at lodoss.net Tue Oct 27 17:37:58 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 27 Oct 2015 17:37:58 +0000 Subject: Varnish project autumn cleaning In-Reply-To: References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> Message-ID: I agree with Lasse as well, we should keep the wiki. It might be worth exploring https://help.github.com/articles/user-organization-and-project-pages/ for the website and/or wiki. I'm happy to co-admin/root any server if required but IMO if we can avoid any maintenance by using the above it'd be better. I'm also happy contributing towards some VPS solution, Digital Ocean being my preferred at the moment. One question that comes to my mind is what is going to happen with repo.varnish-cache.org after we move out of VS. Are we going to continue providing packages? On Tue, Oct 27, 2015 at 5:24 PM, Kacper Wysocki wrote: > On Tue, Oct 27, 2015 at 5:14 PM, Lasse Karstensen > wrote: > > On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: > > [cut] > >> I'm currently disinclined to have a Wiki in the future, it seems > >> to never really have worked for us. If we later find out we need > >> one, github or Wikia are obvious solutions. > > > > The wiki doesn't work because we've turned off user registrations > > to combat spammers. > > > > I strongly believe we should revive it when we have the chance. > (==github move) > > > > It is a natural place to keep information that is too specific to go > > into the main documentation, or too small of a detail to warrant a > > documentation commit. > > > > Just making a (living) FAQ that we can use in #varnish for the normal > > questions would be a big improvement. I'm happy to take point on this, > > if that is what it is needed. > > So good to hear that revamping the site will be a priority going forward. > I'm happy to help in any way that I can. > > I agree with Lasse that the wiki has an important place as a living > document, and that a whole lot of VCL snippets and varnish tricks are > ending up on Other Peoples Blogs? because the trac wiki has been > broken (by spammers). > > It may be useful in the future to give someone the wiki-admin-hat so > they can mark out-of-date content, avoiding the old issue of vcl > snippets for Varnish 2.0 still floating about. > > That being said, getting a nicer ticketing system would be super sweet > and the old ticket system is definitely the first thing to deserve a > bullet. > > cheers, > 0K > > _______________________________________________ > 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 geoff at uplex.de Tue Oct 27 17:57:51 2015 From: geoff at uplex.de (Geoff Simmons) Date: Tue, 27 Oct 2015 18:57:51 +0100 Subject: Varnish project autumn cleaning In-Reply-To: <28767.1445957308@critter.freebsd.dk> References: <28767.1445957308@critter.freebsd.dk> Message-ID: <562FBB1F.7050507@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/27/2015 03:48 PM, Poul-Henning Kamp wrote: > > The varnish-cache.org homepage will be generated from doc/sphinx in > the repository, that saves us a CMS and a database. If we later > find out we need something stronger, we can do that. Two important resources presently on v-c.o are the VMOD and Utilities directories. Any thoughts on what happens to them? As I understand the way that they work now, they depend a lot on having a CMS, and there are good reasons for that. Users with an account can post up their own descriptions and updates about their stuff, without requiring an editor or editors to do it all the time. The front-end controls for picking a technical category, maturity of the development, supported Varnish version, and also for the author to edit/delete the entry -- would any of that be possible with a site generated from the repo? Of course we could replace the directories with straight HTML generated from the repo and maintained by committers. If someone wants to add or change something, that too would be a pull request. But I'd be concerned about the risk of the info going stale, or that committers will keep their own stuff much more up-to-date than the contributions from "outsiders". 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWL7sfAAoJEOUwvh9pJNURZcIP/R8IiqqFeSuHbwD3OqC70kea 9TVReClwJQX389x/spHD+0CQ++Wo1ab5HZL4uezUd+vkaNNRwMR6rYV+T3zIBMDu GXmzsEgk33WNXlgqGd8F28hPHQtcId9EM87CMNfBj6QHYhWNTt/WLVY0eqF9/vRX ke2YIGYutuoVIrwCVICpjdiv4tY8cHsRrg+yhRnd49IrYgbsTd8MiVunVr6VB/eF n4EcmXWupF8V4R91h59rb/CEIiwJoBYdZ8KTcfsl+wCY9QzkzY0odIdUjKCypOTz vGke0Ej47rUKSbNt2vcRVr/GLmt9OtUz3WUplKmcsxp5qlZcYGXB3FH1OOuMHE5i eHxqITbV7oyQkSekv1LX5/OlWY0xSIR9pV3gNTzCu1nVW8xZl/d/F0KwyXPPC8HH DAYtbT1uLHyc0XwSKeKso6Nrv/hWoU0i3jcin6K20bK9GImQ0pQQOb+4Yrv6h62z bj3MsEe3gngkvwp0asaT9HBovcgZDRrTvJhHNarQ37oA8vaJJG9llpEf1gYTcI55 zAk9B1fpH6jafsPNLkzWrsUknxhiEs/QSAeyU62N/VnU9KQxT2H121Ne3XL5n/XF BqwzbxbdQ1c7uVNFafWHNI863eOQKgMP41145Sr5ctyPgwa4NSy3+neC77HyojOA 6jSo+Tysn4yo/2OaWdK/ =5pst -----END PGP SIGNATURE----- From perbu at varnish-software.com Tue Oct 27 18:35:45 2015 From: perbu at varnish-software.com (Per Buer) Date: Tue, 27 Oct 2015 19:35:45 +0100 Subject: Varnish project autumn cleaning In-Reply-To: <562FBB1F.7050507@uplex.de> References: <28767.1445957308@critter.freebsd.dk> <562FBB1F.7050507@uplex.de> Message-ID: On Tue, Oct 27, 2015 at 6:57 PM, Geoff Simmons wrote: > Two important resources presently on v-c.o are the VMOD and Utilities > directories. Any thoughts on what happens to them? > I've been thinking quite a bit about this. Basically we could maintain some sort of flat file structure and whenever we run "make" it will build the corresponding pages. So people will be able to add their own VMODs and then do a pull request to have it show up on the site. There are high quality "website building tools" out there that will allow us to keep full control over the markup while still making it possible to have the simplicity of something like RST (or markdown or whatever) for the main content. I've been looking at http://jekyllrb.com/ - and it looks rather nice. More alternatives are available at https://www.staticgen.com/ and a few other directories. As I understand the way that they work now, they depend a lot on > having a CMS, and there are good reasons for that. Users with an > account can post up their own descriptions and updates about their > stuff, without requiring an editor or editors to do it all the time. > > The front-end controls for picking a technical category, maturity of > the development, supported Varnish version, and also for the author to > edit/delete the entry -- would any of that be possible with a site > generated from the repo? > If they are willing to do a pull request it should be fine. But some maintenance on the listings will have to be done. I don't think this will be that much of a burden as long as the effort doesn't involve editing some shitty HTML table. -- *Per Buer* CTO | Varnish Software AS Cell: +47 95839117 We Make Websites Fly! www.varnish-software.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Tue Oct 27 20:14:38 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 27 Oct 2015 20:14:38 +0000 Subject: IPv[46] parsing Message-ID: Hi, Here's a resume of the current situation and the proposed plan to address it. While moving from 4.0.x to 4.1 I noticed that std.ip(..., "::1") doesn't work anymore. It errors out with: IP constant '"::1"' could not be resolved to an IP address: Servname not supported for ai_socktype (Sorry if that error message is gibberish.) Using [::1] works though. This changed when Resolve_Sockaddr() was modified to use VSS_Resolver(), in commit d86639568e660bbf272492659f85e271145903c6. I've opened a ticket to deal with this, https://www.varnish-cache.org/trac/ticket/1801. My first problem with this is the now mandatory []. They do make sense when you need to use a port with an IPv6, in fact that's the only way, but we do accept 1.2.3.4 as literal, so why not ::1? Using the [] notation for specifying an IPv6 address without a port is non-standard and something you won't find on the wild. It feels pretty much arbitrary too. Moving on, if you were to pass [::1] as the first argument to std.ip() it won't work, since getaddrinfo() doesn't know how to parse it. This is not consistent. First, I'd like to restore the pre 4.1 behaviour with a 2 lines patch (see attached). The patch is fairly small and if we parse it incorrectly it will fail down the line when we call getaddrinfo(). The other thing that I mentioned on Monday is modifying std.ip() to accept [::1] and [::1]:80 as well. The former might be needed when dealing with forward like headers (rfc 7239) for example and should be trivial. Before I proceed I'd like some consensus, time is scarce after all. So let the bike shedding begin. f.- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: r01801.patch Type: text/x-diff Size: 504 bytes Desc: not available URL: From fgsch at lodoss.net Tue Oct 27 20:19:11 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Tue, 27 Oct 2015 20:19:11 +0000 Subject: Varnish project autumn cleaning In-Reply-To: References: <28767.1445957308@critter.freebsd.dk> <562FBB1F.7050507@uplex.de> Message-ID: fwiw, my current favourite static generator is hugo, https://gohugo.io/. It's written in go but nobody is perfect. On Tue, Oct 27, 2015 at 6:35 PM, Per Buer wrote: > > > On Tue, Oct 27, 2015 at 6:57 PM, Geoff Simmons wrote: > >> Two important resources presently on v-c.o are the VMOD and Utilities >> directories. Any thoughts on what happens to them? >> > > I've been thinking quite a bit about this. Basically we could maintain > some sort of flat file structure and whenever we run "make" it will build > the corresponding pages. So people will be able to add their own VMODs and > then do a pull request to have it show up on the site. > > There are high quality "website building tools" out there that will allow > us to keep full control over the markup while still making it possible to > have the simplicity of something like RST (or markdown or whatever) for the > main content. > > I've been looking at http://jekyllrb.com/ - and it looks rather nice. > More alternatives are available at https://www.staticgen.com/ and a few > other directories. > > As I understand the way that they work now, they depend a lot on >> having a CMS, and there are good reasons for that. Users with an >> account can post up their own descriptions and updates about their >> stuff, without requiring an editor or editors to do it all the time. >> >> The front-end controls for picking a technical category, maturity of >> the development, supported Varnish version, and also for the author to >> edit/delete the entry -- would any of that be possible with a site >> generated from the repo? >> > > If they are willing to do a pull request it should be fine. But some > maintenance on the listings will have to be done. I don't think this will > be that much of a burden as long as the effort doesn't involve editing some > shitty HTML table. > > -- > *Per Buer* > CTO | Varnish Software AS > Cell: +47 95839117 > We Make Websites Fly! > www.varnish-software.com > > > _______________________________________________ > 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 stanhope at gmail.com Wed Oct 28 00:01:53 2015 From: stanhope at gmail.com (Phil Stanhope) Date: Wed, 28 Oct 2015 01:01:53 +0100 Subject: varnish-dev Digest, Vol 115, Issue 10 In-Reply-To: References: Message-ID: <59A739FD-AE10-465F-9A18-8701042ACAC8@gmail.com> I can give you live traffic. Let's talk. Definitely in Rotterdam. -phil @phone On Oct 27, 2015, at 18:38, varnish-dev-request at varnish-cache.org wrote: Send varnish-dev mailing list submissions to varnish-dev at varnish-cache.org To subscribe or unsubscribe via the World Wide Web, visit https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev or, via email, send a message with subject or body 'help' to varnish-dev-request at varnish-cache.org You can reach the person managing the list at varnish-dev-owner at varnish-cache.org When replying, please edit your Subject line so it is more specific than "Re: Contents of varnish-dev digest..." Today's Topics: 1. Re: Preventing dup backend names with dynamic backends in VMODs (Poul-Henning Kamp) 2. Varnish project autumn cleaning (Poul-Henning Kamp) 3. Re: Preventing dup backend names with dynamic backends in VMODs (Geoff Simmons) 4. Re: Varnish project autumn cleaning (Lasse Karstensen) 5. Re: Varnish project autumn cleaning (Kacper Wysocki) 6. Re: Varnish project autumn cleaning (Federico Schwindt) ---------------------------------------------------------------------- Message: 1 Date: Tue, 27 Oct 2015 12:25:29 +0000 From: "Poul-Henning Kamp" To: geoff at uplex.de Cc: Varnish Development Subject: Re: Preventing dup backend names with dynamic backends in VMODs Message-ID: <8599.1445948729 at critter.freebsd.dk> Content-Type: text/plain; charset="us-ascii" Good catch Geoff. Yes, uniqueness of backend names affect only CLI and VSM. The former only if people get confused, the latter always because the VSM counter segment is named based on the backend name, so the two will clash. We've never had a really good model for backend names and we're probably about to make it even worse with dynamic backends. To _truly_ identify a backend, you need to know: VCL name (Soon: .. or global) VMOD name VMOD object name VMOD object instance (= vcl name of instantiated object) Backend name IPv4 IPv6 Needless to say, that doesn't work. (Previously we used {backend name, ipv4, ipv6} that didn't work either, and since then we grew vmods and dynamic backends.) My current thinking is that we'll name the backend whatever the user/vcl/vmod writer likes (ie: Backend name), and deal with the fall-out. That really only leaves one question: What do we do when some code tries to add a backend with a name which already exists. One option is to fail the backend creation, but since it is only CLI/VSM that can get confused, that seems too draconian to me. So I'm tempted to simply add a ".%d" suffix for ever increasing %d's until the name becomes unique. Would that work for people ? Poul-Henning PS: I also noted that backend names can become quite unwieldy, so it might be a good idea to give all backends a serial number which appears in CLI output, and can be used in CLI commands to refer to a particular backend. -- 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. ------------------------------ Message: 2 Date: Tue, 27 Oct 2015 14:48:28 +0000 From: Poul-Henning Kamp To: varnish-dev at varnish-cache.org Subject: Varnish project autumn cleaning Message-ID: <28767.1445957308 at critter.freebsd.dk> Content-Type: text/plain; charset="us-ascii" After some private consultations, this email is being sent to the -dev list, for notice and comment. After we have hashed it out here, I will write it up for announce@ and the world at large. As I have mentioned to a lot of you already, I have some changes in mind for the Varnish Project after 4.1-R and I am busy these days trying to get from "in mind" to "a plan". There are a number of drivers for this, which I will just quickly sketch out. (If you want more details, I can flesh it out further in the subsequent discussions, this email is long enough as it is.) The reasons =========== 1. We've gone from DevOps to Developers --------------------------------------- This is most evident in 4.1-R being so delayed mainly because of lack of real-life testing. Becuase none of the central group of developers actually run a Varnish production site, we have to persuade other people to do live tests for us. This means we cannot use the same "QA" strategy we did previously and that must be reflected in our release process. 2. The workshop have become cluttered ------------------------------------- The Trac wiki has become Hotel California. Patchwork never really worked for us. The Forum isn't exactly a noted social venue. The project homepage looks a lot like an advertising front end for Varnish Software - not from any sinister plan or hostile intent, but simply from the lack of any other content to put there. And to top it off we're stilling running Varnish version 3.0.something on varnish-cache.org. It's time to clean up the workshop, and prepare it for the next stretch of the projects life. 3. I don't have any live Varnish instances ------------------------------------------ Well, I *do* have one, but a search-engine request every 10 seconds is not enough for me to be well informed about choices in varnish development. In particular for the H2 development I need to be able to see what happens in real life. This has been a major annoyance for me during 4.1 but it will turn into a major problem developing H2 support, without any access to real-life traffic. 4. Varnish-Software and Varnish-Cache are too close --------------------------------------------------- This is a lot more perception than reality, but various people are concerned. It is well established that the perception that corruption *could* happen is as bad for confidence as actual corruption happening, so their concerns are not unreasonable. I want to make the distinction between V-S and V-C.O much more clear. A major sticking point is the project homepage, which V-S has been so kind to maintain for the project until now, but which therefore also looks a little bit too much like a V-S subsidiary. I don't mind giving major shoutouts to the various Varnish companies on the V-C.O homepage, but it needs to serve the project at least as much as the companies. So given these reasons, here is the plan I've come up with: The plan ======== 1. Release by date ------------------ In the future we will do two *major* Varnish releases a year, and we will put them in the calendar at least 6 months ahead of time. Whatever is in the tree and whatever works on that date will be in that release. If some feature or bug-fix isn't ready, it won't be in that release. The good news is that it will only have to wait six months for the next major release, and there may be minor releases before that. We make this change because we are no longer able, as developers, to run/orchestrate a comprehensive test-campaign before releases, and therefore we have to make it possible for our users to do this for us. By putting releases into the calendar rather than the wish-list, our users can plan ahead, and we minimize the consequence in terms of time if/when one of our releases turns out to be a "dud". We are not going to give any similar guarantees for *minor* releases, which we will roll out as needs arise. 2. Tool cleanup --------------- The Trac software has become a liability, and we want to get rid of it. In particular fighting spammers is a drain. The repository itself will move to github. Unless anybody has better ideas, Bugtracking will move to github also. I'm currently disinclined to have a Wiki in the future, it seems to never really have worked for us. If we later find out we need one, github or Wikia are obvious solutions. Patchwork will be discontinued. Either we fall back to patches on the -dev mailing list or github pull-requests or possibly both. We'll find out what works best. Personally I do like to use -dev because it works offline for me, and because it preserves the history in the mail-archives. The varnish-cache.org homepage will be generated from doc/sphinx in the repository, that saves us a CMS and a database. If we later find out we need something stronger, we can do that. The homepage will revert to a classic "here is our software, here is the doc, here is what's happening" FOSS project homepage, with due shoutouts to the rest of the Varnish community. By generating it out of doc/sphinx, all committers get ability to push content to the home page. I hope they do, time will show. In that respect, I will be happy to hand out commit bits for people who want to help maintain the home-page, (similar to FreeBSD's src/ports/doc distinctions). Jenkins seems to work, no need to do anything at present as far as I can tell. Coverity has never really struck gold for us, but it's simple for us to use and having the dog not bark works for me. As far as I can tell, the forum is not very productive, and it might be a better idea to focus that activity on Stackoverflow or similar, where the chances of more user-to-user support is higher. The mailing lists seems to work, as well as mailing lists can be expected to, and will be continued basically unchanged. The IRC channels also seems to work, we'll keep those. It's been suggested we move to a "real" IRC network, but that has both up and downsides in my view. 3. Growing up, moving out ------------------------- After careful consideration, I have reached the conclusion that it is high time Varnish-Cache.org moves away from its childhood home at Varnish-Software.com. There are no ill feelings intended on my part, I'm very grateful for all the time V-S has spent on the projects server, software and tools. But the time has simply come where co-habitation no longer is the best solution for either party. As V-S grew their company, they have chosen a strategy for their infrastructure which makes the project server the odd-ball box in the corner and the necessary exceptions and special rules for the V-C.O stuff have become a PITA for their sysadmins. Seen from the project point of view, the perfectly sensible limitations imposed by V-S corporate needs limits what we can do, and we are constrained by availability of time and resources at V-S. And there is that perception thing also. So it's time for the project to move out. Initially I will put up a new project server in my own lab, because it is cheap, accessible (which is important during the transition) and by definition neutral ground for the project. Once we've come through the transition and things have been shaken out and settled down, that server will be migrated to some friendly hosting service, affordable on the VML funds. It's important for me that this does not decrease the bus-quotient of the project to 1.0, so I still want to have a couple of "co-roots" for this machine. Making the transition ===================== Lasse has started an etherpad with notes, ideas and tasks, so there is no reason to repeat there here, go there instead: https://etherpad.wikimedia.org/p/vc-github-move We are not planning a "big-bang" transition, but rather taking it bit for bit as we go. Moving the repo to github will be the most visible part, but (famous last word candidate:) we don't foresee any trouble. My guess is that the order will roughly be: * Create github repo, slave it of existing repo. * Flip order: New github becomes master, existing repo becomes slave * Tell developers to push to new master repo. * Migrate (open) Trac tickets to github manually, or if the scripts Lasse found works: Migrate all tickets to github. Set Trac Read-Only. * Announce that future tickets must be opened on github. * Settling down period. * Close down patchwork * I (and others) create the future project homepage under doc/sphinx. * New homepage goes live on new project server. * Rescue whatever content deserves rescuing from Trac's Wiki * Close down Trac * Move mailing lists to new project server. ... or something like that. In total it will probably take quite some weeks before we're at the bottom of the list, which is why I'm not sweating the details too much yet. Summary ======= This is not a political issue. There are no hard feelings anywhere (I hope). It is simply me paying some long overdue attention to the FOSS project around the software, I hope you all agree and will help make this reorg as uneventful as possible. 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. ------------------------------ Message: 3 Date: Tue, 27 Oct 2015 16:01:46 +0100 From: Geoff Simmons To: Poul-Henning Kamp Cc: Varnish Development Subject: Re: Preventing dup backend names with dynamic backends in VMODs Message-ID: <562F91DA.8010104 at uplex.de> Content-Type: text/plain; charset=windows-1252 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > On 10/27/2015 01:25 PM, Poul-Henning Kamp wrote: > > Yes, uniqueness of backend names affect only CLI and VSM. > > The former only if people get confused, the latter always because > the VSM counter segment is named based on the backend name, so the > two will clash. Something else I thought of since yesterday -- the backend names used in VSL for entries like Backend, BackendOpen, BackendClose and so forth. If you're using the log to diagnose a problem, doesn't help much to have to wonder which backend it's talking about. > My current thinking is that we'll name the backend whatever the > user/vcl/vmod writer likes (ie: Backend name), and deal with the > fall-out. At the very least, VMODs should have a way to discover if a backend name is already in use by a VCL -- the VCL_HasBackend(vcl,name) idea. Then a VMOD can choose to raise an error for duplicate names. Maybe add a sentence or two to the "Writing a Director" doc about backend names, what they're used for, and why this could be a problem. > That really only leaves one question: What do we do when some > code tries to add a backend with a name which already exists. > > One option is to fail the backend creation, but since it is only > CLI/VSM that can get confused, that seems too draconian to me. > > So I'm tempted to simply add a ".%d" suffix for ever increasing > %d's until the name becomes unique. > > Would that work for people ? If you thought that you called your backend "be", and then see "be.1" and "be.2" in backend.list, VSL, VBE.* stats and so forth, is it really any less confusing? The order would be probably result from which backend was created first, which may be difficult or impossible to determine after the fact. That would have the advantage that one set of VSC stats doesn't get lost altogether. So I guess the choices are: be draconian, or permit a situation that will probably create confusion, however much we try to minimize it. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWL5HaAAoJEOUwvh9pJNUR1OsQALGdQ5Dn/kDeBZkGymKX31z6 4/Z60CHK1lPMPsHJKumxLGp7D2deN00XmygecYshUBjjM26rnSg1f1JhFlwIMd9t Nb678+Zi3HXoOPJ+5a1KLjMSHfpqb95xZ9S0GR7B8eAHj4fZqKJWTPk5L0CRdeI3 ISxls4/OAmrHqccH/7RILbcwX/vQo/Za7HnPkgiABq9sts18HoLZik4Wrys7jjrR XtnKKI0TXchzxvOH+uzpSE+zVZWfGTWalK8RtyQw/+8nV7gWvtlkSmlYDJ6IMrGR buwf0GJPHGD8OSk2MHyBg3Z3JO3EuqiPK/sGGDPQZcCcjw9bSSwQlD0z+r9CjVcN FzjeH/3iRhFIYMsDoplxyPj1h9FcjyjPGTlJutnvlDsny1Mes8I0Rm2B8ilJL5GT wDHgduDsjh/IEi3sIes5Baj5rKPxTO1aOHg6iALIuZiExmcZ6f5XD54e1I2MYszW ypGWDDZcnwuvBVzplwQo/swUnKBu+I9gTVKkUqq5bQfZMUrCZ/wE/7SfqXJqBZfW JI6k28mxL8WZyO0HH5iWhfDr3QxYrumBYZPIAHEzHEkXSo5JfH0e4sMF31mfVJ21 2WzcdGZfeAilAzGJHALYGX9/HK8Hf9Bimw808V3vrdyZNBbpE+XyX8L52Qlur4pL sGt66SERJ3V0J9ULMZbO =6WOa -----END PGP SIGNATURE----- ------------------------------ Message: 4 Date: Tue, 27 Oct 2015 17:14:28 +0100 From: Lasse Karstensen To: Poul-Henning Kamp Cc: varnish-dev at varnish-cache.org Subject: Re: Varnish project autumn cleaning Message-ID: <20151027161427.GA1274 at immer.varnish-software.com> Content-Type: text/plain; charset=us-ascii > On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: > [cut] > I'm currently disinclined to have a Wiki in the future, it seems > to never really have worked for us. If we later find out we need > one, github or Wikia are obvious solutions. The wiki doesn't work because we've turned off user registrations to combat spammers. I strongly believe we should revive it when we have the chance. (==github move) It is a natural place to keep information that is too specific to go into the main documentation, or too small of a detail to warrant a documentation commit. Just making a (living) FAQ that we can use in #varnish for the normal questions would be a big improvement. I'm happy to take point on this, if that is what it is needed. -- Lasse Karstensen ------------------------------ Message: 5 Date: Tue, 27 Oct 2015 18:24:35 +0100 From: Kacper Wysocki To: Lasse Karstensen Cc: Varnish Development Subject: Re: Varnish project autumn cleaning Message-ID: Content-Type: text/plain; charset=UTF-8 On Tue, Oct 27, 2015 at 5:14 PM, Lasse Karstensen wrote: > On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: > [cut] >> I'm currently disinclined to have a Wiki in the future, it seems >> to never really have worked for us. If we later find out we need >> one, github or Wikia are obvious solutions. > > The wiki doesn't work because we've turned off user registrations > to combat spammers. > > I strongly believe we should revive it when we have the chance. (==github move) > > It is a natural place to keep information that is too specific to go > into the main documentation, or too small of a detail to warrant a > documentation commit. > > Just making a (living) FAQ that we can use in #varnish for the normal > questions would be a big improvement. I'm happy to take point on this, > if that is what it is needed. So good to hear that revamping the site will be a priority going forward. I'm happy to help in any way that I can. I agree with Lasse that the wiki has an important place as a living document, and that a whole lot of VCL snippets and varnish tricks are ending up on Other Peoples Blogs? because the trac wiki has been broken (by spammers). It may be useful in the future to give someone the wiki-admin-hat so they can mark out-of-date content, avoiding the old issue of vcl snippets for Varnish 2.0 still floating about. That being said, getting a nicer ticketing system would be super sweet and the old ticket system is definitely the first thing to deserve a bullet. cheers, 0K ------------------------------ Message: 6 Date: Tue, 27 Oct 2015 17:37:58 +0000 From: Federico Schwindt To: Kacper Wysocki Cc: Varnish Development Subject: Re: Varnish project autumn cleaning Message-ID: Content-Type: text/plain; charset="utf-8" I agree with Lasse as well, we should keep the wiki. It might be worth exploring https://help.github.com/articles/user-organization-and-project-pages/ for the website and/or wiki. I'm happy to co-admin/root any server if required but IMO if we can avoid any maintenance by using the above it'd be better. I'm also happy contributing towards some VPS solution, Digital Ocean being my preferred at the moment. One question that comes to my mind is what is going to happen with repo.varnish-cache.org after we move out of VS. Are we going to continue providing packages? > On Tue, Oct 27, 2015 at 5:24 PM, Kacper Wysocki wrote: > > On Tue, Oct 27, 2015 at 5:14 PM, Lasse Karstensen > wrote: >> On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: >> [cut] >>> I'm currently disinclined to have a Wiki in the future, it seems >>> to never really have worked for us. If we later find out we need >>> one, github or Wikia are obvious solutions. >> >> The wiki doesn't work because we've turned off user registrations >> to combat spammers. >> >> I strongly believe we should revive it when we have the chance. > (==github move) >> >> It is a natural place to keep information that is too specific to go >> into the main documentation, or too small of a detail to warrant a >> documentation commit. >> >> Just making a (living) FAQ that we can use in #varnish for the normal >> questions would be a big improvement. I'm happy to take point on this, >> if that is what it is needed. > > So good to hear that revamping the site will be a priority going forward. > I'm happy to help in any way that I can. > > I agree with Lasse that the wiki has an important place as a living > document, and that a whole lot of VCL snippets and varnish tricks are > ending up on Other Peoples Blogs? because the trac wiki has been > broken (by spammers). > > It may be useful in the future to give someone the wiki-admin-hat so > they can mark out-of-date content, avoiding the old issue of vcl > snippets for Varnish 2.0 still floating about. > > That being said, getting a nicer ticketing system would be super sweet > and the old ticket system is definitely the first thing to deserve a > bullet. > > cheers, > 0K > > _______________________________________________ > 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: ------------------------------ _______________________________________________ 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 115, Issue 10 ******************************************** From phk at phk.freebsd.dk Wed Oct 28 08:17:18 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 08:17:18 +0000 Subject: Preventing dup backend names with dynamic backends in VMODs In-Reply-To: <562F91DA.8010104@uplex.de> References: <562E4736.5030708@uplex.de> <8599.1445948729@critter.freebsd.dk> <562F91DA.8010104@uplex.de> Message-ID: <74085.1446020238@critter.freebsd.dk> -------- In message <562F91DA.8010104 at uplex.de>, Geoff Simmons writes: >> My current thinking is that we'll name the backend whatever the >> user/vcl/vmod writer likes (ie: Backend name), and deal with the >> fall-out. > >At the very least, VMODs should have a way to discover if a backend >name is already in use by a VCL -- the VCL_HasBackend(vcl,name) idea. >Then a VMOD can choose to raise an error for duplicate names. Agreed. >Maybe add a sentence or two to the "Writing a Director" doc about >backend names, what they're used for, and why this could be a problem. Also a good idea. I'm starting to think that maybe we should have a "name-spaces" section in the reference manual for stuff like this. >> So I'm tempted to simply add a ".%d" suffix for ever increasing >> %d's until the name becomes unique. > >If you thought that you called your backend "be", and then see "be.1" >and "be.2" in backend.list, VSL, VBE.* stats and so forth, is it >really any less confusing? Well, there are degrees of confusion, and I think people would generally be able to grok indicies like that. >The order would be probably result from >which backend was created first, which may be difficult or impossible >to determine after the fact. Not if we make it possible to query the full list of attributes from CLI, so that you can ask about be.3 and get told which VCL created, which VMOD in that VCL, and which object in that VMOD etc. Basically the full shopping-list from my first reply. >That would have the advantage that one set of VSC stats doesn't get >lost altogether. Yes. >So I guess the choices are: be draconian, or permit a situation that >will probably create confusion, however much we try to minimize it. The main reason I don't like draconian is that it is not necessary. If we're draconian, VMODS have to do a complex errorhandling, which in 3 cases out of 10 doesn't get implemented and therefore leads to backends not existing when they are expected to and worst case crashes. Varnish can run even with 98 backends all called "be" and the problem can be corrected with a new and more sensible VCL, without ever going out of production. Adding the .%u suffix makes the situation workable for people who make that mistake, and once they have sorted it out, it doesn't get in the way for them. -- 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 Oct 28 08:20:48 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 08:20:48 +0000 Subject: Varnish project autumn cleaning In-Reply-To: <20151027161427.GA1274@immer.varnish-software.com> References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> Message-ID: <74119.1446020448@critter.freebsd.dk> -------- In message <20151027161427.GA1274 at immer.varnish-software.com>, Lasse Karstensen writes: >On Tue, Oct 27, 2015 at 02:48:28PM +0000, Poul-Henning Kamp wrote: >The wiki doesn't work because we've turned off user registrations >to combat spammers. I'm not convinced about that, but I'm willing to test your hypotesis, provided we do it on some platform where we don't have to waste time on anti-spam. -- 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 Oct 28 08:49:19 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 08:49:19 +0000 Subject: Varnish project autumn cleaning In-Reply-To: References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> Message-ID: <74253.1446022159@critter.freebsd.dk> -------- In message , Federico Schwindt writes: >It might be worth exploring >https://help.github.com/articles/user-organization-and-project-pages/ for >the website and/or wiki. Or we could look at Wikia, which has been a Varnish-user from the very get go... >One question that comes to my mind is what is going to happen with >repo.varnish-cache.org after we move out of VS. >Are we going to continue providing packages? That's a very murky question for me. My preference would be for varnish itself to be OS packages, reachable by regular OS packaging tools. Some high-profile VMODs may be able to scale that barrier too, but the majority wont. So the question is rally: What do do with the "community VMODs" ? The keyword here is automation: We do not want to manually curate all the worlds VMODs. At the lowest level, I'd like to define a "protocol", something like "include a VMOD.README file in your project" (inspired by FreeBSD's portcollections ".desc" file) and have a google search which find all of those files on github and list the projects on the webpage. Ideally we'd also pull them and try to build them, so we only list those which can compile, and can tell which varnish versions they compile against. If they have .vtc files, we test them too. If they fail, we email the maintainer, and black-ball them until their next github commit. But that is both tedious and nasty business. You *really* don't want to pull random github projects and run their instructions unsupervised without some very strong boundary protections. On the other hand, with jails/containers/VMs, that is not as outrageous as it used to be, so it is a feasible project with a high payoff on the far side. In particular if we follow the compilation up with rolling a package. That 'vmod-package-engine' should obviously be as cross-platform as possible, even though the actual containment strategy would be different on different OS's. But without automation, it's a dead end: We don't have the manpower to manually curate them. Anybody want to attempt something like this ? (Here's the blueprint: http://www.dmi.dk/uploads/pics/stormp.gif) -- 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 Oct 28 08:58:29 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 08:58:29 +0000 Subject: IPv[46] parsing In-Reply-To: References: Message-ID: <74327.1446022709@critter.freebsd.dk> -------- In message , Federico Schwindt writes: >While moving from 4.0.x to 4.1 I noticed that std.ip(..., "::1") doesn't >work anymore. I agree this is very far from optimal, but adding special-casing IPv6 address by IPv6 address is certainly *not* the way forward. The real question is, what does "::1:8080" mean ? Please propose the exact algorithm you prose for turning strings into IP numbers, and bear in mind that we need to be able to include port numbers. -- 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 tfheen at fastly.com Wed Oct 28 09:32:08 2015 From: tfheen at fastly.com (Tollef Fog Heen) Date: Wed, 28 Oct 2015 10:32:08 +0100 Subject: IPv[46] parsing In-Reply-To: <74327.1446022709@critter.freebsd.dk> References: <74327.1446022709@critter.freebsd.dk> Message-ID: 2015-10-28 9:58 GMT+01:00 Poul-Henning Kamp : > -------- > In message > , Federico Schwindt writes: > >>While moving from 4.0.x to 4.1 I noticed that std.ip(..., "::1") doesn't >>work anymore. > > I agree this is very far from optimal, but adding special-casing > IPv6 address by IPv6 address is certainly *not* the way forward. > > The real question is, what does "::1:8080" mean ? It's the IPv6 address 0:0:0:0:0:0:1:8080. I don't see how it could mean anything else. > Please propose the exact algorithm you prose for turning strings > into IP numbers, and bear in mind that we need to be able to > include port numbers. I'm not Federico, and this is not an exact algorithm, but: If string contains four dots and 0 or 1 :-s ? parse as v4 (with or without port depending on presence of :) If string contains four dots and more than 1 and no []: ? parse as v4 mapped ipv6 (port is empty) If string contains four dots and more than 1 and []: ? parse as v4 mapped ipv6 with port If string contains :: and no [] ? parse as v6 (port is empty) If string contains 7 :s and no [], parse as v6 (port is empty). If string contains :: and [] ? parse as v6 with port If string contains 7 :s and [], parse as v6 with port Yes, this means you can't use 127.1 and similar as valid IPs. Don't do that, then. IMO, etc. -- Tollef Fog Heen | Engineer fastly.com | @fastly | Linkedin From guillaume at varnish-software.com Wed Oct 28 09:52:30 2015 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 28 Oct 2015 10:52:30 +0100 Subject: IPv[46] parsing In-Reply-To: References: <74327.1446022709@critter.freebsd.dk> Message-ID: I'm in favor of mandatory brackets for IPv6, but would this do ? - first char is [: it's IPv6 - if you find a letter or colon: it's IPv6 - if you get a dot or more than 3 numbers in a row: it's IPv4 and a colon announces a port if: - it comes right after a ']' in ipv6 - it comes after a number in IPv4 Once set on a version, error as soon as something is amiss. I'd refuse IPv6 with port without brackets is it will get confusing ("::1:8080" is clear, but what about "::1:80"?) -- Guillaume Quintard On Wed, Oct 28, 2015 at 10:32 AM, Tollef Fog Heen wrote: > 2015-10-28 9:58 GMT+01:00 Poul-Henning Kamp : > > -------- > > In message dCFHBtDL_XMzmGLu0q8mwWnCbSEZw at mail.gmail.com> > > , Federico Schwindt writes: > > > >>While moving from 4.0.x to 4.1 I noticed that std.ip(..., "::1") doesn't > >>work anymore. > > > > I agree this is very far from optimal, but adding special-casing > > IPv6 address by IPv6 address is certainly *not* the way forward. > > > > The real question is, what does "::1:8080" mean ? > > It's the IPv6 address 0:0:0:0:0:0:1:8080. I don't see how it could > mean anything else. > > > Please propose the exact algorithm you prose for turning strings > > into IP numbers, and bear in mind that we need to be able to > > include port numbers. > > I'm not Federico, and this is not an exact algorithm, but: > > If string contains four dots and 0 or 1 :-s ? parse as v4 (with or > without port depending on presence of :) > If string contains four dots and more than 1 and no []: ? parse as v4 > mapped ipv6 (port is empty) > If string contains four dots and more than 1 and []: ? parse as v4 > mapped ipv6 with port > If string contains :: and no [] ? parse as v6 (port is empty) > If string contains 7 :s and no [], parse as v6 (port is empty). > If string contains :: and [] ? parse as v6 with port > If string contains 7 :s and [], parse as v6 with port > > Yes, this means you can't use 127.1 and similar as valid IPs. Don't do > that, then. > > IMO, etc. > -- > Tollef Fog Heen | Engineer > fastly.com | @fastly | Linkedin > > _______________________________________________ > 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 Wed Oct 28 09:55:04 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 09:55:04 +0000 Subject: IPv[46] parsing In-Reply-To: References: <74327.1446022709@critter.freebsd.dk> Message-ID: <74648.1446026104@critter.freebsd.dk> -------- In message , Guillaume Quintard writes: >I'm in favor of mandatory brackets for IPv6, but would this do ? >- first char is [: it's IPv6 >- if you find a letter or colon: it's IPv6 Remember that it is not just numeric formats. In general this is about what we pass to the two fields of getaddrinfo(3), we don't convert to IP#s ourselves. -- 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 Oct 28 09:48:58 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 09:48:58 +0000 Subject: varnish-dev Digest, Vol 115, Issue 10 In-Reply-To: <59A739FD-AE10-465F-9A18-8701042ACAC8@gmail.com> References: <59A739FD-AE10-465F-9A18-8701042ACAC8@gmail.com> Message-ID: <74591.1446025738@critter.freebsd.dk> -------- In message <59A739FD-AE10-465F-9A18-8701042ACAC8 at gmail.com>, Phil Stanhope writ es: >I can give you live traffic. Let's talk. Definitely in Rotterdam. Noted and yes! -- 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 guillaume at varnish-software.com Wed Oct 28 10:15:04 2015 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Wed, 28 Oct 2015 11:15:04 +0100 Subject: IPv[46] parsing In-Reply-To: <74648.1446026104@critter.freebsd.dk> References: <74327.1446022709@critter.freebsd.dk> <74648.1446026104@critter.freebsd.dk> Message-ID: On Wed, Oct 28, 2015 at 10:55 AM, Poul-Henning Kamp wrote: > -------- > In message Q at mail.gmail.com> > , Guillaume Quintard writes: > > >I'm in favor of mandatory brackets for IPv6, but would this do ? > >- first char is [: it's IPv6 > >- if you find a letter or colon: it's IPv6 > > Remember that it is not just numeric formats. > > In general this is about what we pass to the two fields of getaddrinfo(3), > we don't convert to IP#s ourselves. > > Ah, my bad, then there's the question of how much error types we want to raise (vss_parse catches some of them, but far from all), because it could be as simple as: - find first colon (fc) - find last colon (lc) fc == lc => ipv4 with port fc != lc *(lc - 1) == ']' => IPv6 with port (and check the first char is indeed '[') else IPv6 without port -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkarsten at varnish-software.com Wed Oct 28 10:47:52 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Wed, 28 Oct 2015 11:47:52 +0100 Subject: VC release management in the future (Was: Re: Varnish project autumn cleaning) In-Reply-To: <74253.1446022159@critter.freebsd.dk> References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> <74253.1446022159@critter.freebsd.dk> Message-ID: <20151028104750.GC1274@immer.varnish-software.com> On Wed, Oct 28, 2015 at 08:49:19AM +0000, Poul-Henning Kamp wrote: [..] > My preference would be for varnish itself to be OS packages, reachable > by regular OS packaging tools. This is already the case. It is simply a matter of how old the Varnish versions out there should be. There is a significant amount of deployments out there running 3.0.2 with known bugs, because that is what debian wheezy is shipping. This Varnish version is a little over 4 years old today. Regarding the plan for timed releases, before this repo discussion proceeds, I'd love to hear Ingvar or Stig's input on how this will play out in the distros. I understand there will be no stable version, just a continous stream of make dist from git master every 6 months. Am I right to assume that distros would then just pick the one latest available 3-6 months before they cut a release, and then live with it for 3-5 years during the linux distro lifespan? Also, since we're not doing a stable release any longer, who is backporting the bugfixes all of these n packagers need to keep the Varnishes in their distro safe and reliable? [cut] > Some high-profile VMODs may be able to scale that barrier too, but > the majority wont. This is not correct. The majority of vmods in use are on the way into EPEL and Debian these days. I understand there is some work being done on the FreeBSD ports side as well. -- Lasse Karstensen Varnish Software AS From kly at redpill-linpro.com Wed Oct 28 10:51:32 2015 From: kly at redpill-linpro.com (Kristian Lyngstol) Date: Wed, 28 Oct 2015 11:51:32 +0100 Subject: VMOD packaging, repo.v-c.o, etc Message-ID: <20151028105132.GA6784@leia.redpill-linpro.com> We (Lasse, Ingvar, ssm and myself) recently had a productive workshop/brainstorming regarding vmod packaging going forward. It ended up also being about general packaging of Varnish. Since I saw repo.varnish-cache.org mentioned in the "Varnish project autumn cleaning" thread, I figured I'd update the -dev community with the parts of the outcome of those talks as they are highly relevant. In short: - There will be vmod packages for numerous vmods. They will not end up in repo.varnish-cache.org, but in official packaging and sites such as backports.debian.org. (And a PPA-like alternative for RHEL/EPEL - the details are left to Ingvar on that one). - Packaging of newer versions of Varnish will also be done in the same style. - 'repo.varnish-cache.org' will gradually become less important as the functions it has served will be gradually moved to more official locations. None of this will happen over night of course. Proper announcements and schedules and whatnot will be posted as they as they are established. I know Ingvar has begun work already [1] and I expect similar from ssm soon enough. This is still work in progress and as such not an official announcement of any kind. The motivation is simple: Reduce duplicated efforts and ensure the QA is as good as we can get it for the packaging. Since Ingvar and ssm have been packaging Varnish since about Varnish 1.0, I don't think we could ask for anyone better suited. [1] https://copr.fedoraproject.org/coprs/ingvar/varnish41/ - Kristian PS: My role in this is merely professional middle man. From phk at phk.freebsd.dk Wed Oct 28 11:59:06 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 11:59:06 +0000 Subject: VC release management in the future (Was: Re: Varnish project autumn cleaning) In-Reply-To: <20151028104750.GC1274@immer.varnish-software.com> References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> <74253.1446022159@critter.freebsd.dk> <20151028104750.GC1274@immer.varnish-software.com> Message-ID: <74977.1446033546@critter.freebsd.dk> -------- In message <20151028104750.GC1274 at immer.varnish-software.com>, Lasse Karstensen writes: >I understand there will be no stable version, just a continous stream of >make dist from git master every 6 months. No, I don't think we should drop stable versions, but we can't make all the head-releases into stable versions, that wouldn't scale. The process I see is that we do a head-release twice a year, and once we get to know them, because people on the bleeding edge have tried them out, we pick the ones we will support as stable releases for a longer time. >Am I right to assume that distros would then just pick the one latest >available 3-6 months before they cut a release, and then live with it >for 3-5 years during the linux distro lifespan? I have no idea, that would be entirely up to them. If we do as I propose above, they would likely pick the most recent annointed stable release. >Also, since we're not doing a stable release any longer, who is >backporting the bugfixes all of these n packagers need to keep the >Varnishes in their distro safe and reliable? That's a very important question, and the answer is as disappointing as it can be: Whoever has the time and inclination. A project of our size has to economize its resources, and one way to do that is to ruthlessly tell people to upgrade. >[cut] >> Some high-profile VMODs may be able to scale that barrier too, but >> the majority wont. > >This is not correct. > >The majority of vmods in use are on the way into EPEL and Debian these >days. I understand there is some work being done on the FreeBSD ports >side as well. That would be a lovely state of affairs, I hope you're right. -- 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 Oct 28 12:09:47 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 28 Oct 2015 12:09:47 +0000 Subject: VMOD packaging, repo.v-c.o, etc In-Reply-To: <20151028105132.GA6784@leia.redpill-linpro.com> References: <20151028105132.GA6784@leia.redpill-linpro.com> Message-ID: <75050.1446034187@critter.freebsd.dk> -------- In message <20151028105132.GA6784 at leia.redpill-linpro.com>, Kristian Lyngstol w rites: >- 'repo.varnish-cache.org' will gradually become less important as the > functions it has served will be gradually moved to more official > locations. I cross my fingers that this is true, it would be a much better situation for *everybody*. >The motivation is simple: Reduce duplicated efforts and ensure the QA is >as good as we can get it for the packaging. Since Ingvar and ssm have >been packaging Varnish since about Varnish 1.0, I don't think we could >ask for anyone better suited. Indeed, a big round of applause is long overdue. -- 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 dridi at varni.sh Wed Oct 28 13:29:12 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 28 Oct 2015 14:29:12 +0100 Subject: IPv[46] parsing In-Reply-To: References: Message-ID: > The other thing that I mentioned on Monday is modifying std.ip() to accept > [::1] and [::1]:80 as well. It is kind of weird to have an IP address (as in std.ip) accept a port. It would probably be better to have something like std.addr for that. The underlying VCL_IP is confusing with this regard. My two cents: - std.ip could revert back to expecting "::1" instead of "[::1]" - std.addr could be used for the ip:port notation (as in varnishd -a) - documentation should clarify the ambiguity Cheers, Dridi From fgsch at lodoss.net Wed Oct 28 13:38:56 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Wed, 28 Oct 2015 13:38:56 +0000 Subject: IPv[46] parsing In-Reply-To: <74327.1446022709@critter.freebsd.dk> References: <74327.1446022709@critter.freebsd.dk> Message-ID: Hi, Current functionality ---------------------------- 1. If the string starts with "[" we take everything up to "]" as the host, excluding the "[]". If there is a ":" following the "]" we take everything after it as the port. 2. If the string has a space, take everything up to the space (but excluding it) as the host. Anything after the space is the port. 3. If the string doesn't have a space, but has a ":" take everything up to the ":" (but excluding it) as a host, and anything after as the port. My proposal ----------------- Change 3 as follows: 3. If the string doesn't have a space, but has a single ":" take everything up to the ":" (but excluding it) as a host, and anything after as the port. If the string has 2 or more ":", take the whole string as a host without port. Examples -------------- 1.2.3.4 => host = 1.2.3.4 port = 1.2.3.4:80 => host = 1.2.3.4 port = 80 1.2.3.4 80 => host = 1.2.3.4 port = 80 foo.bar => host = foobar port = foo.bar:80 => host = foobar port = 80 foo.bar 80 => host = foobar port = 80 [::1] => host = ::1 port = [::1]:80 => host = ::1 port = 80 ::1 => host = ::1 port = ::1::2 => host = ::1::2 port = 1.2.3.4::80 => host = 1.2.3.4::80 port = With the current implementation ::1 would fail. It works with my patch. The last 2 would fail at getaddrinfo(), with or without my proposal. f.- On Wed, Oct 28, 2015 at 8:58 AM, Poul-Henning Kamp wrote: > -------- > In message dCFHBtDL_XMzmGLu0q8mwWnCbSEZw at mail.gmail.com> > , Federico Schwindt writes: > > >While moving from 4.0.x to 4.1 I noticed that std.ip(..., "::1") doesn't > >work anymore. > > I agree this is very far from optimal, but adding special-casing > IPv6 address by IPv6 address is certainly *not* the way forward. > > The real question is, what does "::1:8080" mean ? > > Please propose the exact algorithm you prose for turning strings > into IP numbers, and bear in mind that we need to be able to > include port numbers. > > -- > 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 lkarsten at varnish-software.com Thu Oct 29 11:47:44 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Thu, 29 Oct 2015 12:47:44 +0100 Subject: Varnish Cache contributor goodies (free!) Message-ID: <20151029114743.GA30903@immer.varnish-software.com> Hi all. For a while now I've been trying to put together some free goodies for our contributors. Specificly this means a branded coffee mug and a Varnish Cache contributor T-shirt, and we will deliver/ship it to you for free. The underlaying idea is to show our appreciation for the great work being done by the community. This will only be available to contributors. More information and a registration form for your shipping address can be found here: https://www.varnish-cache.org/contributor We aim to ship the first batch in the beginning of December 2015. -- Lasse Karstensen Varnish Software AS From fgsch at lodoss.net Thu Oct 29 11:54:37 2015 From: fgsch at lodoss.net (Federico Schwindt) Date: Thu, 29 Oct 2015 11:54:37 +0000 Subject: [PATCH] Convert arguments to strings as well In-Reply-To: References: Message-ID: Ping. On Tue, Oct 13, 2015 at 5:14 PM, Federico Schwindt wrote: > Anyone? > > On Thu, Oct 1, 2015 at 5:36 PM, Federico Schwindt > wrote: > >> Now that 4.1 is out of the way, I'd like to push this. >> >> Comments? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kacperw at gmail.com Thu Oct 29 12:20:04 2015 From: kacperw at gmail.com (Kacper Wysocki) Date: Thu, 29 Oct 2015 13:20:04 +0100 Subject: [PATCH] Convert arguments to strings as well In-Reply-To: References: Message-ID: It seems very uncontroversial to include this type conversion. On Thu, Oct 29, 2015 at 12:54 PM, Federico Schwindt wrote: > Ping. > > On Tue, Oct 13, 2015 at 5:14 PM, Federico Schwindt wrote: >> >> Anyone? >> >> On Thu, Oct 1, 2015 at 5:36 PM, Federico Schwindt >> wrote: >>> >>> Now that 4.1 is out of the way, I'd like to push this. >>> >>> Comments? From dridi at varni.sh Thu Oct 29 14:47:28 2015 From: dridi at varni.sh (Dridi Boukelmoune) Date: Thu, 29 Oct 2015 15:47:28 +0100 Subject: [PATCH] Convert arguments to strings as well In-Reply-To: References: Message-ID: On Thu, Oct 29, 2015 at 1:20 PM, Kacper Wysocki wrote: > It seems very uncontroversial to include this type conversion. +1 From lkarsten at varnish-software.com Thu Oct 29 15:19:17 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Thu, 29 Oct 2015 16:19:17 +0100 Subject: New guidelines for maintenance branches Message-ID: <20151029151916.GA3602@immer.varnish-software.com> Hi all. I'm easing up the policy on how and who can commit to the maintenance branches of Varnish Cache. Typically 4.0 and 4.1. The policy is defined by this wiki node: https://www.varnish-cache.org/trac/wiki/Maintenance_branch_guidelines Contents copied from the wiki for your review: """ * The maintenance branches shall represent stable and consistent solutions for users. Users requiring the latest functionality have other options. * The branches should always be possible to build. * Pushed commits shall stand on their own. Documentation, test cases and any build system changes shall accompany the functional change. * Functionality shall not be removed in minor releases. * Functionality shall always be commited in master before any porting to maintenance branches. * Changes requiring sign-off on email from the release manager: - New features or additions ported in from master. - Changes to global header files (cache.h in particular). - Anything involving VRT ABI version. - Output changes where it is reasonable to think users may parse it programmatically. * Commits on the following can be commited by everyone freely: - Documentation changes. - Test case stabilization. Commit rights will be given to active project members that request it. The release manager decides exceptions, and may update this procedure as required. If you are unsure, ask. """ -- Lasse Karstensen (Release manager hat on.) From lkarsten at varnish-software.com Fri Oct 30 09:49:32 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Fri, 30 Oct 2015 10:49:32 +0100 Subject: Varnish project autumn cleaning In-Reply-To: References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> Message-ID: <20151030094930.GA14933@immer.varnish-software.com> On Tue, Oct 27, 2015 at 05:37:58PM +0000, Federico Schwindt wrote: [..] > One question that comes to my mind is what is going to happen with > repo.varnish-cache.org after we move out of VS. > Are we going to continue providing packages? Consensus seem to be no on the package building. Possible migration plan: * We move tarballs of releases onto https://varnish-cache.org/source/ . * https://repo.v-c.o/source/(.*) perm-redirects to https://www.varnish-cache.org/source/\1 . (for 6 months) * We'll tar up the current /redhat and /debian and keep them in /source/ for 12 months. * Access to repo.v-c.o returns with a 403 and "Repository discontinued, see http://blah/" This way non-https repo.v-c.o can be handled in vcl_recv/synth with minimal effort, wherever the site ends up running. -- Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Fri Oct 30 11:23:07 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Fri, 30 Oct 2015 12:23:07 +0100 Subject: Fryer is being retired. Message-ID: <20151030112306.GA16968@immer.varnish-software.com> Hi all. I'm retiring the fryer load testing suite. Reasons for this are shifted priorities and no time to maintain it. Fryer had a nice run, from Kristians original tool to the version running last two years. It has probably found 30-40 Varnish Cache bugs, if not more. -- Lasse Karstensen Varnish Software AS From phk at phk.freebsd.dk Fri Oct 30 11:26:15 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 30 Oct 2015 11:26:15 +0000 Subject: Fryer is being retired. In-Reply-To: <20151030112306.GA16968@immer.varnish-software.com> References: <20151030112306.GA16968@immer.varnish-software.com> Message-ID: <58387.1446204375@critter.freebsd.dk> -------- In message <20151030112306.GA16968 at immer.varnish-software.com>, Lasse Karstense n writes: >I'm retiring the fryer load testing suite. > >Reasons for this are shifted priorities and no time to maintain it. > >Fryer had a nice run, from Kristians original tool to the version >running last two years. It has probably found 30-40 Varnish Cache bugs, >if not more. I'm very sad to see it dropped, anybody else want to pick it up ? -- 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 kacperw at gmail.com Fri Oct 30 16:19:30 2015 From: kacperw at gmail.com (Kacper Wysocki) Date: Fri, 30 Oct 2015 17:19:30 +0100 Subject: Preventing dup backend names with dynamic backends in VMODs In-Reply-To: <74085.1446020238@critter.freebsd.dk> References: <562E4736.5030708@uplex.de> <8599.1445948729@critter.freebsd.dk> <562F91DA.8010104@uplex.de> <74085.1446020238@critter.freebsd.dk> Message-ID: On Wed, Oct 28, 2015 at 9:17 AM, Poul-Henning Kamp wrote: > In message <562F91DA.8010104 at uplex.de>, Geoff Simmons writes: > >>> My current thinking is that we'll name the backend whatever the >>> user/vcl/vmod writer likes (ie: Backend name), and deal with the >>> fall-out. >> >>At the very least, VMODs should have a way to discover if a backend >>name is already in use by a VCL -- the VCL_HasBackend(vcl,name) idea. >>Then a VMOD can choose to raise an error for duplicate names. >>Maybe add a sentence or two to the "Writing a Director" doc about >>backend names, what they're used for, and why this could be a problem. > [snip] > Adding the .%u suffix makes the situation workable for people who > make that mistake, and once they have sorted it out, it doesn't get > in the way for them. slightly related to this, could we possibly allow accessing the name in VCL, like if(req.backend_hint ~ "zool") { /* do something */ } or even std.log("backend was " + req.backend_hint); ? I can imagine this might get tricky with directors, but I for one would find this useful, even subject to the restrictions/confusions of duplicate backend names etc 0K From lkarsten at varnish-software.com Sat Oct 31 08:34:34 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Sat, 31 Oct 2015 09:34:34 +0100 Subject: Continuous integration moves to Travis CI Message-ID: <20151031083433.GA5176@immer.varnish-software.com> Hi all. I'm changing continuous integration system for Varnish Cache to the online Travis CI system. (https://travis-ci.org/ ) Travis is integrated with Github, and can build on Linux and OS X. We've been testing it on vmods and VC for a while, but not as the main CI system. Here is the new build job: https://travis-ci.org/varnishcache/varnish-cache One nice thing about travis is that they build pull requests for us automatically. Patch sets failing the tests will ble clearly marked as such. This also means that we will sunset the Jenkins CI instance that Varnish Software has been running for the project. Basis for this is the same as before, shifting priorities and no time to maintain it. -- Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Sat Oct 31 09:25:07 2015 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Sat, 31 Oct 2015 10:25:07 +0100 Subject: Varnish project autumn cleaning In-Reply-To: <20151030094930.GA14933@immer.varnish-software.com> References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> <20151030094930.GA14933@immer.varnish-software.com> Message-ID: <20151031092506.GB5176@immer.varnish-software.com> On Fri, Oct 30, 2015 at 10:49:32AM +0100, Lasse Karstensen wrote: > On Tue, Oct 27, 2015 at 05:37:58PM +0000, Federico Schwindt wrote: [..] > > Are we going to continue providing packages? > Consensus seem to be no on the package building. I've had a look at Varnish Cache platform support after this. Debian wheezy has 3.0.2, (stable) jessie has 4.0.2 and (testing) stretch has 4.1.0. Debian will still have a credible alternative. This is should credited to Stig's excellent work. Ubuntu does 3.0 in precise 12.04 and trusty 14.04. xenial (16.06/next LTS) has 4.1.0. No stable/LTS alternative exists right now. Build from source. RHEL7/el7: nothing in base system. epel7 has 4.0.3-3. Ingvar has made this happen, and I understand there is work underway getting 4.1.0 in here. RHEL6/el6: Nothing in base system. epel6 has 2.1.5-5. No stable alternative will exist. Build from source or upgrade to el7. With my VS hat on: Varnish Plus customers using community Varnish Cache should contact support to find alternatives. -- Lasse Karstensen Varnish Software AS From phk at phk.freebsd.dk Sat Oct 31 09:51:21 2015 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 31 Oct 2015 09:51:21 +0000 Subject: Varnish project autumn cleaning In-Reply-To: <20151031092506.GB5176@immer.varnish-software.com> References: <28767.1445957308@critter.freebsd.dk> <20151027161427.GA1274@immer.varnish-software.com> <20151030094930.GA14933@immer.varnish-software.com> <20151031092506.GB5176@immer.varnish-software.com> Message-ID: <44520.1446285081@critter.freebsd.dk> -------- In message <20151031092506.GB5176 at immer.varnish-software.com>, Lasse Karstensen writes: >With my VS hat on: Varnish Plus customers using community Varnish Cache >should contact support to find alternatives. The obvious alternative is to build from source. That also ensures that any bugfixes or security patches are accessible with no undue delay. -- 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.