Re: [Cherokee-dev] Contest Results

On Mon, Dec 1, 2008 at 12:00 PM, Alvaro Lopez Ortega
<alvaro <at> octality.com> wrote:

> Having said that, I'm delighted to announce that the winners of
> the notebooks are: Jonathan Hernandez and Antonio Perez.

¡Oe!, ¡oe, oe, oeeee! :-D

Thank you guys!, thank you very much! 

> Congratulations to everybody.
> Accenture, thanks a million!

Thanks to Accenture too, of course! 

--

-- 
Saludos:
Antonio Pérez

Re: [Cherokee-dev] Contest Results

_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee

Zope Virtual Host Monster

Saludos!

I am experimenting with cherokee as a front end to Plone (Zope) web
server.

In Apache I achieved that by giving the following rule to the virtual
host conf:

RewriteEngine on
RewriteRule
^/(.*)
http://localhost:8080/VirtualHostBase/http/%{SERVER_NAME}:80/{PLONE_SITE_ID}/VirtualHostRoot/$1 [L,P]

Sinopsis:

from Zope Virtual Host monster documentation:

You add these names by rewriting incoming URLs

Visitors to your site don't see these special names, of course. You
insert them into the path using either an external rewriter, such as an
Apache RewriteRule or ProxyPass directive, or by setting up a mapping on
the "Mappings" tab.

For example, suppose Zope is running on port 8080 behind an Apache
running on port 80. You place a Virtual Host Monster in the Zope root
Folder, and use Apache to rewrite "/(.*)" to
http://localhost:8080/VirtualHostBase/http/www.buystuff.com:80/buystuff.com/VirtualHostRoot/$1

I am using apache right now and it works with that rule for our customer
sites, but I believe it's an overkill.

I tried to define a virtual host in cherokee with the following:

vserver!20!directory_index = index.php,index.html
vserver!20!document_root = /var/www
vserver!20!logger = combined
vserver!20!logger!access!buffsize = 16384
vserver!20!logger!access!filename = /var/log/cherokee.access
vserver!20!logger!access!type = file
vserver!20!logger!error!filename = /var/log/cherokee.error
vserver!20!logger!error!type = file
vserver!20!nick = cb.rbgsys.com
vserver!20!rule!700!encoder!deflate = 0
vserver!20!rule!700!encoder!gzip = 0
vserver!20!rule!700!handler = redir
vserver!20!rule!700!handler!rewrite!1!show = 0
vserver!20!rule!700!handler!rewrite!1!substring =
http://localhost:8080/VirtualHostBase/http/cb.rbgsys.com:80/cb/VirtualHostRoot/$1
vserver!20!rule!700!match = request
vserver!20!rule!700!match!request = ^/(.*)
vserver!20!rule!700!only_secure = 0
vserver!20!rule!600!encoder!gzip = 1
vserver!20!rule!600!handler = fcgi
vserver!20!rule!600!handler!balancer = round_robin
vserver!20!rule!600!handler!balancer!source!1 = 1
vserver!20!rule!600!match = extensions
vserver!20!rule!600!match!extensions = php
vserver!20!rule!500!encoder!gzip = 1
vserver!20!rule!500!handler = server_info
vserver!20!rule!500!handler!type = just_about
vserver!20!rule!500!match = directory
vserver!20!rule!500!match!directory = /about
vserver!20!rule!400!document_root = /usr/lib/cgi-bin/
vserver!20!rule!400!handler = cgi
vserver!20!rule!400!match = directory
vserver!20!rule!400!match!directory = /cgi-bin
vserver!20!rule!300!document_root = /usr/share/cherokee/themes/
vserver!20!rule!300!handler = file
vserver!20!rule!300!match = directory
vserver!20!rule!300!match!directory = /cherokee_themes
vserver!20!rule!200!document_root = /usr/share/cherokee/icons/
vserver!20!rule!200!handler = file
vserver!20!rule!200!match = directory
vserver!20!rule!200!match!directory = /icons
vserver!20!rule!100!encoder!deflate = 0
vserver!20!rule!100!encoder!gzip = 0
vserver!20!rule!100!handler = common
vserver!20!rule!100!match = default
vserver!20!rule!100!only_secure = 0

But have been unsuccessful so far with:

1) lynx http://cb.rbgsys.com/ from localhost

Result:
The requested URL
http://localhost:8080/VirtualHostBase/http/cb.rbgsys.com:80/cb/VirtualHostRoot/ was not found
on this server.

2) http://cb.rbgsys.com/ from remote

Result:
404 Not Found
The requested URL
http://localhost:8080/VirtualHostBase/http/cb.rbgsys.com:80/cb/VirtualHostRoot/ was not found
on this server. 

But if I try:

lynx
http://localhost:8080/VirtualHostBase/http/cb.rbgsys.com:80/cb/VirtualHostRoot/ from localhost

It will bring the correct Plone/Zope web page.

I am including the full Apache working conf file as an attachement.

Thanks in advanced for your advise!

--

-- 
Angel Berríos Dávila <aberrios <at> rbgsys.com>
RBG Information Systems

_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee

Re: Zope Virtual Host Monster

On 01-dic-08, at 15:11, Angel Berríos Dávila wrote:

> I am experimenting with cherokee as a front end to Plone (Zope) web
> server.
>
> In Apache I achieved that by giving the following rule to the virtual
> host conf:
>
> RewriteEngine on
> RewriteRule ^/(.*)
> http://localhost:8080/VirtualHostBase/http/%{SERVER_NAME}:80/ 
> {PLONE_SITE_ID}/VirtualHostRoot/$1 [L,P]

I don't think you want to redirect the request but make the request go  
through a reverse proxy.  In that way, you client wouldn't see those  
never-ending Zope URLs on the browser address bar.

In this case, it would go as follows:

============
- Directory /icons, Handler "file"
     -> Document root: /usr/share/cherokee/icons/

- Directory /cherokee_themes, Handler "file"
     -> Document root: /usr/share/cherokee/themes/

- Directory /about, Handler "server_info"

- Default, Handler "HTTP reverse proxy"
     -> Source: localhost:8080
     -> Rewrite /(.*)$ -> /VirtualHostBase/http/cb.rbgsys.com:80/cb/ 
VirtualHostRoot/$1
============

Remember that the order in the list does matter (requests are  
evaluated from top to bottom).

--
Octality
http://www.octality.com/

Re: [Cherokee-dev] Contest Results

On Mon, Dec 1, 2008 at 12:45 PM, Javier De Posada
<jposada <at> e-commfactory.com> wrote:

> Tu teclado no va a tener enyes! :P

In English: "The keyboard will not have ' ñ ' key".

I don't need it to code Cherokee! :P

X-D

--

-- 
Saludos:
Antonio Pérez

mod_wsgi for cherokee?

_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee

Re: mod_wsgi for cherokee?

On Mon, Dec 1, 2008 at 10:25 AM, Christopher Grebs <cg <at> webshox.org> wrote:
> I have read the discussion about the issue of a missing WSGI wrapper for
> Cherokee. I'm planning to push my whole infrastructure over to a Cherokee
> based setup. But since there are many wsgi applications running I would be
> pleased to let them run in the same way I did with my apache setup. But with
> all advantages Cherokee provides (Load Balancing, easy Administration etc.).
> I know that WSGI-Based applications can run without any code patching on
> CGI/SCGI/FastCGI and so on... But the way WSGI handles just everything is
> ingenious.
>
> Is there any progress on a WSGI module yet?

Are you sure you read the whole thread?  mod_wsgi is pretty counter to
the entire design philosophy of cherokee (all
applications/modules/whatever kept out-of-process).

From Alvaro's initial response to my mod_wsgi question:

> Firstly, from the architectural point of view it is simply madness...

> Second, it sounds hard to believe that mod_wsgi is faster than a plain
> an simple SCGI application writing to a Unix socket. (Remember that WSGI
> application can also use FastCGI and SCGI backends).

The following discussion basically breaks down to:

1.  In-process WSGI may be faster than out-of-process, but against the
design principles of Cherokee.
2.  If you're going to run your application out-of-process, why not
use a platform agnostic protocol like SCGI/FastCGI?

That being said I believe embedding WSGI into Cherokee *is* possible,
but then why not just use Apache+mod_wsgi?

Of course I could be wrong and am very interested in hearing any
further opinions/explanations.

Michael Schurter

Re: mod_wsgi for cherokee?

On 01-dic-08, at 19:25, Christopher Grebs wrote:

> I have read the discussion about the issue of a missing WSGI wrapper  
> for Cherokee.

Please don't call it a "missing wrapper". I'd rather suggest something  
like "right technical decision".

> I'm planning to push my whole infrastructure over to a Cherokee  
> based setup. But since there are many wsgi applications running I  
> would be pleased to let them run in the same way I did with my  
> apache setup. But with all advantages Cherokee provides (Load  
> Balancing, easy Administration etc.). I know that WSGI-Based  
> applications can run without any code patching on CGI/SCGI/FastCGI  
> and so on... But the way WSGI handles just everything is ingenious.

Well, WSGI is certainly a really interesting thing. It allows  
developer to write web applications without having to worry about the  
protocol it uses underneath to communicate with the web server. That's  
a very good thing, actually.

So, allow me to clarify things a little bit: The only purpose of WSGI  
is to provide an API with which developers could write protocol  
independent (as in SCGI, FastCGI, AJP 1.3, etc) applications.

And here is where Apache's mod_wsgi comes into scene: it basic idea is  
to sunk a Python interpreter within the server, so the application  
calls go through a intermediate conversion layer to get converted to  
something the web server can deal with.

IMHO mod_wsgi is simply a module that implements many wrong technical  
decisions altogether. I wouldn't like to kick off this discussion  
again, but basically, linking a whole interpreter within a web server  
is a clumsy approach: it's insecure and slow, aside of its flawed  
architectural design.

I do think that your current approach is the way to go:  The  
application server (your WSGI application) runs in a different process  
that communicates with the server through a local (unix?) socket.   
That is in fact a faster and much more secure and reliable way of  
working.  _Give it a try, and you will see what I mean_.

> Is there any progress on a WSGI module yet?

Progress? No. It isn't simply on the roadmap.
You can currently run WSGI applications by launching them as  
application servers (with either SCGI, FastCGI or HTTP access). Let's  
forget about all the hacks Apache had to come up with in order to ease  
its performance issues!

So, summing up: WSGI is a really good thing. However, the mod_wsgi's  
approach is simply wrong.. and I'm willing to reproduce any of those  
Apache's bulky modules in Cherokee. 

--
Octality
http://www.octality.com/

Re: mod_wsgi for cherokee?

On Mon, Dec 1, 2008 at 11:09 AM, Alvaro Lopez Ortega
<alvaro <at> octality.com> wrote:
> On 01-dic-08, at 19:25, Christopher Grebs wrote:
>> I'm planning to push my whole infrastructure over to a Cherokee
>> based setup. But since there are many wsgi applications running I
>> would be pleased to let them run in the same way I did with my
>> apache setup. But with all advantages Cherokee provides (Load
>> Balancing, easy Administration etc.). I know that WSGI-Based
>> applications can run without any code patching on CGI/SCGI/FastCGI
>> and so on... But the way WSGI handles just everything is ingenious.
>
> Well, WSGI is certainly a really interesting thing. It allows
> developer to write web applications without having to worry about the
> protocol it uses underneath to communicate with the web server. That's
> a very good thing, actually.

Ah this is a very important distinction that I think confuses many
people coming from a mod_wsgi vs. FastCGI world.

Proxying/FastCGI/SCGI all define a language/platform agnostic protocol
for relaying HTTP requests & responses between a frontend server and
backend applications.

WSGI[1] defines a common Python interface for web applications.  Think
of it as the thinnest possible web framework.  Many (most?  hopefully
all?) Python web frameworks implement WSGI.  However, these frameworks
may in turn use FastCGI/SCGI to actually communicate with the frontend
web server because WSGI isn't a protocol.  Its an API.

So think of mod_wsgi as mod_python + a builtin WSGI API (although this
is an analogy, *not* a technical description!).  Maybe we should call
it "Mod Python: WSGI Edition."  

If you really like the idea of having HTTP + Python in the same
process, use a Python HTTP server like CherryPy[2] to replace
Apache+mod_wsgi in your stack.  Then simply Proxy HTTP requests
between CherryPy & Cherokee.

Running a busy site on a multi-core server?  Simply start multiple
CherryPy instances and let Cherokee load balance between them.  Need
to scale more?  Move the CherryPy instances to other servers and keep
Cherokee as the load balancer.  There was a good demonstration of this
principle at PyCon a few years ago.[3]

You could always use Apache+mod_wsgi behind Cherokee while you
migrate.  It would be the same as the CherryPy solution but with the
HTTP & WSGI bits implemented in C instead of Pure Python.[4]

If you don't really care about HTTP & Python living in the same
process (I'm guessing you really just like how easy mod_wsgi is to
setup compared to say, mod_python), take a deep breath and switch to
FastCGI/SCGI.  

Disclaimer:  Like I've mentioned before.  I'm no FastCGI/WSGI pro.
Just someone going through the same thought process as the OP.  

[1] http://www.python.org/dev/peps/pep-0333/\
[2] http://cherrypy.org
[3] http://www.polimetrix.com/pycon/slides/