From darix at web.de Sat Dec 2 17:39:36 2006 From: darix at web.de (Marcus Rueckert) Date: Sat, 2 Dec 2006 18:39:36 +0100 Subject: SUSE rpm (Mandriva/Fedora too) Message-ID: <20061202173936.GA5533@pixel.global-banlist.de> hi, i just want to point out that i provide rpms for SUSE/Fedora/Mandriva at: http://software.opensuse.org/download/server:/http/ The SUSE rpms are tested and working fine. Fedora/Mandriva should work too. But as i dont have fedora/mandriva installations i could not test those. I used the init/sysconfig script from the official rpm for those distros. (It at least starts in my local build chroot) If you know any debian packagers we can maintain debian/ubuntu packages there aswell. More informations about the build service can be found here: http://en.opensuse.org/Build_Service with kind regards, darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From jp at allbsd.de Tue Dec 5 14:31:55 2006 From: jp at allbsd.de (Joerg Pernfuss) Date: Tue, 5 Dec 2006 15:31:55 +0100 Subject: Cookie and X-Forwarded-For Interaction (1.0.2) Message-ID: <20061205153155.6f9ef11c@loki.starkstrom.lan> Hi, I just noticed on a varnishd 1.0.2 setup that X-Forwarded-For gets set if I do not send a cookie, but not if a cookie exists. Is that an architectural/design/rfc requirement or sth worth opening a trac ticket for? Regards, Joerg -- | /"\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against | 0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | X HTML in email | .the next sentence is true. | | / \ and news | .the previous sentence was a lie. | From phk at phk.freebsd.dk Tue Dec 5 14:57:08 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 05 Dec 2006 14:57:08 +0000 Subject: Cookie and X-Forwarded-For Interaction (1.0.2) In-Reply-To: Your message of "Tue, 05 Dec 2006 15:31:55 +0100." <20061205153155.6f9ef11c@loki.starkstrom.lan> Message-ID: <75589.1165330628@critter.freebsd.dk> In message <20061205153155.6f9ef11c at loki.starkstrom.lan>, Joerg Pernfuss writes: > >Hi, > >I just noticed on a varnishd 1.0.2 setup that X-Forwarded-For gets >set if I do not send a cookie, but not if a cookie exists. > >Is that an architectural/design/rfc requirement or sth worth opening >a trac ticket for? Yes, please do. -- 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 per.buer at linpro.no Thu Dec 7 21:13:49 2006 From: per.buer at linpro.no (Per Andreas Buer) Date: Thu, 07 Dec 2006 22:13:49 +0100 Subject: varnishadmin - a trivial perl helper Message-ID: <4578840D.2020807@linpro.no> Hi. Since telnetting into a host within an init scipt is cumbersome (btw, could we have a 'exit' command, please?) I've written a litte perl helper script. perbu at perbu:~/tmp$ ../bin/varnishadmin vcl.load foo ~/tmp/vcl.conf Running 'vcl.load foo /home/perbu/tmp/vcl.conf' on localhost:6082 (..) perbu at perbu:~/tmp$ ../bin/varnishadmin stats Running 'stats' on localhost:6082 200 1462 20 Client connections accepted 0 Client requests received (..) You get the idea. The script is available at http://fjase.net/~perbu/varnishadmin Its available under the same licence as varnish itself. -- Per Andreas Buer / Linpro AS t: 21 54 41 21 / m: 958 39 117 http://linpro.no/ - Ledende p? Linux og ?pen kildekode. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From knutroy at linpro.no Fri Dec 22 12:52:50 2006 From: knutroy at linpro.no (=?ISO-8859-1?Q?Knut_Aksel_R=F8ysland?=) Date: Fri, 22 Dec 2006 13:52:50 +0100 Subject: Using a parser generator in next generation VCL compiler Message-ID: <458BD522.3090304@linpro.no> Hi, Linpro AS recently assigned me to work part-time on Varnish development, and I have just started getting to know the docs and source. I have spent most time looking at the internals of the VCL-compiler. My understanding is that an extension of VCL is being planned for version 2, and so I think it might be a good idea to base the next generation compiler on a parser which is generated by a YACC-like parser generator. I think this will make the VCL grammar easier to verify and grasp (for new developers), as well as make it easier to extend. Any thoughts? I look forward to working more on Vanish in 2007. -- Knut Aksel R?ysland Linpro AS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From phk at phk.freebsd.dk Fri Dec 22 13:23:41 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 22 Dec 2006 13:23:41 +0000 Subject: Using a parser generator in next generation VCL compiler In-Reply-To: Your message of "Fri, 22 Dec 2006 13:52:50 +0100." <458BD522.3090304@linpro.no> Message-ID: <61738.1166793821@critter.freebsd.dk> In message <458BD522.3090304 at linpro.no>, =?ISO-8859-1?Q?Knut_Aksel_R=F8ysland?= writes: >I have spent most time looking at the internals of the VCL-compiler. >[...] >Any thoughts? I deliberately didn't use lex/yacc in v1 because the VCL language is so simple but mostly because I wanted strong error handling. YACC generated grammers and LEX generated lexers have horrible error detection and reporting. If you try to make up for that deficiency, your .y and .l files become unreadable as a result, more than negating any advantage of having used them in the first place. Remember that the people who are going to write VCL programs are not programmers, they are admins, they may know a bit of perl or php, but they are not programmers. We need to give them really good error messages, or they will hate VCL with a venegance. But since most of what we will be adding to VCL is the actions, it might very well be a good idea to spend some time on unifying their argument handling, and possibly, use a table driven matching of them, rather than the current swich {} in Action(), lest it become too horrible. I know this runs counter to conventional thinking in compiler circuits, but I'm not alone in thinking that lex/yacc is over- and under-kill for simple languages. See for instance the LCC book which provided a lot of my inspiration for the VCL compiler. 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 darix at web.de Fri Dec 22 15:13:13 2006 From: darix at web.de (Marcus Rueckert) Date: Fri, 22 Dec 2006 16:13:13 +0100 Subject: Using a parser generator in next generation VCL compiler In-Reply-To: <61738.1166793821@critter.freebsd.dk> References: <458BD522.3090304@linpro.no> <61738.1166793821@critter.freebsd.dk> Message-ID: <20061222151313.GB3344@pixel.global-banlist.de> On 2006-12-22 13:23:41 +0000, Poul-Henning Kamp wrote: > In message <458BD522.3090304 at linpro.no>, =?ISO-8859-1?Q?Knut_Aksel_R=F8ysland?= > writes: > > >I have spent most time looking at the internals of the VCL-compiler. > >[...] > > >Any thoughts? > > I deliberately didn't use lex/yacc in v1 because the VCL language > is so simple but mostly because I wanted strong error handling. > > YACC generated grammers and LEX generated lexers have horrible > error detection and reporting. did you look at ragel: http://www.cs.queensu.ca/home/thurston/ragel/ ? a real life example: http://rubyforge.org/viewvc/trunk/ext/http11/?root=mongrel darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From phk at phk.freebsd.dk Fri Dec 22 16:05:02 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 22 Dec 2006 16:05:02 +0000 Subject: Using a parser generator in next generation VCL compiler In-Reply-To: Your message of "Fri, 22 Dec 2006 16:13:13 +0100." <20061222151313.GB3344@pixel.global-banlist.de> Message-ID: <62290.1166803502@critter.freebsd.dk> In message <20061222151313.GB3344 at pixel.global-banlist.de>, Marcus Rueckert wri tes: >> YACC generated grammers and LEX generated lexers have horrible >> error detection and reporting. > >did you look at ragel: http://www.cs.queensu.ca/home/thurston/ragel/ ? >a real life example: http://rubyforge.org/viewvc/trunk/ext/http11/?root=mongrel No I didn't, because I also don't want Varnish to depend on everything and the kitchensink :-) -- 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 knutroy at linpro.no Fri Dec 22 16:16:01 2006 From: knutroy at linpro.no (=?ISO-8859-1?Q?Knut_Aksel_R=F8ysland?=) Date: Fri, 22 Dec 2006 17:16:01 +0100 Subject: Using a parser generator in next generation VCL compiler In-Reply-To: <61738.1166793821@critter.freebsd.dk> References: <61738.1166793821@critter.freebsd.dk> Message-ID: <458C04C1.7000709@linpro.no> * Poul-Henning Kamp >[...] > I deliberately didn't use lex/yacc in v1 because the VCL language > is so simple but mostly because I wanted strong error handling. Thanks for clearing up. Being a newcomer, it can be hard to determine the level of deliberate design which lies behind each part of the source. > YACC generated grammers and LEX generated lexers have horrible > error detection and reporting. >[...] Certainly, good error reporting should not be sacrificed. But having VCL abstracted into some kind of BNF'ish representation, appears attractive to me. Maybe this representation could be mixed with doc-strings, to form the basis for generating a 100% accurate VCL reference manual? This is AFAIK outside the scope of YACC anyway, but maybe there are more "modern" parser generators out there, also having better error reporting? But if the grammar is not going to become much more complex than today, I guess this might be overkill. -- Knut Aksel R?ysland (off for Christmas holiday) Linpro AS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From darix at web.de Fri Dec 22 16:29:36 2006 From: darix at web.de (Marcus Rueckert) Date: Fri, 22 Dec 2006 17:29:36 +0100 Subject: Using a parser generator in next generation VCL compiler In-Reply-To: <62290.1166803502@critter.freebsd.dk> References: <20061222151313.GB3344@pixel.global-banlist.de> <62290.1166803502@critter.freebsd.dk> Message-ID: <20061222162936.GC3344@pixel.global-banlist.de> On 2006-12-22 16:05:02 +0000, Poul-Henning Kamp wrote: > In message <20061222151313.GB3344 at pixel.global-banlist.de>, Marcus Rueckert wri > tes: > > >> YACC generated grammers and LEX generated lexers have horrible > >> error detection and reporting. > > > >did you look at ragel: http://www.cs.queensu.ca/home/thurston/ragel/ ? > >a real life example: http://rubyforge.org/viewvc/trunk/ext/http11/?root=mongrel > > No I didn't, because I also don't want Varnish to depend on everything > and the kitchensink :-) does it really matter whether you depend on the generated source of lex/yacc or ragel?:) you can run the ragel when creating a new release so you dont need ragel on the build hosts. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From phk at phk.freebsd.dk Fri Dec 22 17:16:56 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 22 Dec 2006 17:16:56 +0000 Subject: Using a parser generator in next generation VCL compiler In-Reply-To: Your message of "Fri, 22 Dec 2006 17:29:36 +0100." <20061222162936.GC3344@pixel.global-banlist.de> Message-ID: <62565.1166807816@critter.freebsd.dk> In message <20061222162936.GC3344 at pixel.global-banlist.de>, Marcus Rueckert wri tes: >> No I didn't, because I also don't want Varnish to depend on everything >> and the kitchensink :-) > >does it really matter whether you depend on the generated source of >lex/yacc or ragel?:) >you can run the ragel when creating a new release so you dont need ragel >on the build hosts. Maybe not, but it matters to me that I depend on none of the three. We are not talking about parsing ADA here, nor COBOL or PL/1 or for that matter C. We are talking about a quite small programming language. There is no rocket science involved. I do realize that all of you have been brainwashed by CS professors that yacc/lex is the holy grail of compiler construction. But I maintain that lex or yacc would be a step backwards for VCL. Primarily because error reporting sucks with code generated by those, but also because of both lex and yacc loose readability once you move from text-book examples to real-world code. So for anybody wanting to convince me that using lex/yacc/something else is a better path, here is the minimum hurdle to clear: 1. At least as good and precise error reporting facilities, including being able to quote the source code with a graphical marker of the trouble spot. 2. At least as readable and clear source code. As to deciding if it is a worthwhile use of the projects resources to do so, my vote is a no. There are far more important fish to fry. -- 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 jnebrera at eneotecnologia.com Tue Dec 26 09:21:32 2006 From: jnebrera at eneotecnologia.com (Jaime Nebrera) Date: Tue, 26 Dec 2006 10:21:32 +0100 (CET) Subject: New to Varnish Message-ID: <4197729.1661167124892708.JavaMail.root@correo> Hi all, First of all my biggest congratulations for this great effort. I have been unable to really test this but looks a the way to go, look for funding, do a great job and forget about keeping old technology around. I would like to make some comments to see if we can help in this great effort. We have a good contact within the local government and they are eager to sponsor Open Source Projects that really fit their needs. This in essence brings multiple opportunities: 1) We have good contacts within the local Computer Engineering University and could look for students to do their diploma jobs in Varnish. We currently have some students here doing jobs related to other products of the company. They will need some guidance and help, but surely is a good & cheap starting point 2) We could convince the local government to sponsor part of this effort, specially if we involve local companies / universities. In this sense, is there any estimation of how much "developer time" is needed to continue this development? 3) How well does Varnish compare to haproxy from a performance perspective? Yes, haproxy doesnt cache request, but neither varnish does a lot of stuff haproxy does. Would not be a good idea to just chain both? haproxy as balancer and varnish as accelerator? 4) How hard (please quote this one in particular :) would be to adapt varnish to become not only a "reverse" proxy but a forwarding with caching only proxy? I mean, no fuss with auth nor filtering nor ACLs. Nothing, just caching very fast requests going to the Internet for a network (maybe chaining with an upwards proxy using ICP and being able to work transparently) Thanks and regards PS.- I dont know if the devel list is the correct one to make this questions, but I understand is more restrictive than users :) PS2.- Sadly enough my Norwegian is even worse than my suhairy :) and can't read all the available stuff. Enough with Spanish and English -------------------------------------------- Jaime Nebrera - jnebrera at eneotecnologia.com Consultor TI - ENEO Tecnologia SL Pol. PISA - C/ Manufactura 6, P1, 3B Mairena del Aljarafe - 41927 - Sevilla Telf.- (+34) 955 60 11 60 / 619 04 55 18