http://blog.gmane.org/gmane.comp.web.cherokee.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.cherokee.general/2479 What about the put mouth money thing. It is not difficult to write a handler. How difficult would it be for someone that really really likes mod_wsgi to put on a bounty or start coding? Maybe do it as information source, etc. So much debate, so few work. Stefan Stefan de Konink 2008-12-02T01:33:27 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2478 On Dec 2, 6:09 am, Alvaro Lopez Ortega <alv...< at >octality.com> wrote: If you didn't want to kick off the discussion again, then perhaps hold back on the FUD, especially since it seems you perhaps still don't understand how Apache/mod_wsgi really works. First off, as much as how Cherokee has made specific architectural decisions to achieve its aims, so has mod_wsgi. Just because the Cherokee goals and decisions are different, doesn't mean those for mod_wsgi are wrong. The decisions for mod_wsgi are just as valid because they pertain to the very different execution context of Apache. As to speed, embedding an interpreter certainly does not slow anything down in respect of the WSGI application itself. In theory how mod_wsgi works will actually perform better than FASTCGI/SCGI+FLUP as all the low level flup connection management and data handling code is written in Python, where as in Apache/mod_wsgi it is in C code. Being in C code means that it is quicker, plus the Python GIL is released for greater contiguous sections of functionality whereas in flup, being Python code it is continually acquiring/releasing the Python GIL while it does stuff. You therefore get better concurrent handling in Apache/ mod_wsgi, especially on multi core/processor machines when multithreading in use. Above that lowest level of dispatch, there is going to be no difference as it is all the same Python code executed by the same underlying interpreter. As to performance impact on the rest of the operation of the web server, since Python code only ever gets executed if a URL has to be handed off to a WSGI application, then impact is basically non existent. The only area which would be of concern would be process memory usage because of the persistent nature of WSGI application. For embedded case, such memory usage is going to not be much different to the impacts of running a memory hungry embedded PHP application. Thus in some respect it is an application design choice to run that model. For case of daemon mode of mod_wsgi, neither the execution of Python code or memory usage is an issue as the WSGI application executes in a separate process just like FASTCGI/SCGI solutions. Thus embedding doesn't really come into it at all. All that remains is really the prior issue of Apache's suitability for handling of static files and keep alive issues resulting from using threads over an event driven model. This has got nothing to do with mod_wsgi and mod_wsgi does not make it any worse. So, for static file handling on high performance site, recommendation would be the same. That is, look at offloading static file serving onto a separate server such as nginx, lighttpd or cherokee. Now for security, that also is a specious argument. Using mod_wsgi embedded mode for hosting disparate customer sites would certainly not be a good idea just like using mod_python for the same is not good, but for a self hosted site there would be nothing wrong and it would not reduce the security of your system any more than other common solutions. For shared hosting, or if you want to provide isolation for other reasons such as to allow different applications or parts of them to run as different users, one would simply use mod_wsgi daemon mode whereby you end up with the WSGI application running in distinct daemon processes just like FASTCGI. Latest mod_wsgi code in subversion even supports the concept of chrooting the daemon processes if you want that extra level of isolation. Just like with mod_wsgi daemon mode. In mod_wsgi daemon mode, Apache is merely acting as a process manager and proxy system, just like FASTCGI/SCGI systems, although some of the latter can't even do the process management. Only wrong in respect of Cherokee. As I have said before, I will agree that Cherokee shouldn't be going off trying to implement an equivalent of mod_wsgi. This is more to do with the architecture of Cherokee not being suitable for doing that sort of thing, not mod_wsgi's approach is wrong. The mod_wsgi approach is quite fine and works well for Apache. Overall these arguments about one method being better than another is such a waste of time, especially in respect of performance. This is because as soon as you load a fat WSGI application your request/sec performance is going to drop so much anyway, that any benefit from one hosting mechanism over another is completely swallowed up, being somewhat less than one percent of overall request time. When one realises this, what is more important is the ease in deployment and management. One also has to realise that no one single web server is going to be the answer to everything. Apache/mod_wsgi can be a really good solution for hosting dynamic Python web applications, but as I said before, for serious sites you may want to use a different web server for serving static content and large media files. Graham Graham Dumpleton 2008-12-02T01:11:46 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2477 Javier De Posada dijo [Mon, Dec 01, 2008 at 12:45:51PM +0100]: Neither does yours, it seems. Nor mine. I love the en-us layout. Try this: $ cat .Xmodmap keycode 115 = questiondown exclamdown keycode 116 = ntilde Ntilde keycode 117 = dead_acute dead_diaeresis keycode 94 = Multi_key remove Lock = Caps_Lock add Mod3 = Caps_Lock Not only I have my eñes and usual accents, but I also gain the Multi-key which allows me to write about čḣȩr°ĸəē as much as UTF allows me to, and I push away the useless Caps_Lock key ;-) Gunnar Wolf 2008-12-02T00:26:30 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2476 On Mon, Dec 1, 2008 at 11:09 AM, Alvaro Lopez Ortega <alvaro< at >octality.com> wrote: 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/ Michael Schurter 2008-12-01T21:29:30 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2475 Please don't call it a "missing wrapper". I'd rather suggest something like "right technical decision". 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_. 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/ Alvaro Lopez Ortega 2008-12-01T19:09:10 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2474 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: 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 Michael Schurter 2008-12-01T18:36:34 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2473 _______________________________________________ Cherokee mailing list Cherokee< at >lists.octality.com http://lists.octality.com/listinfo/cherokee Christopher Grebs 2008-12-01T18:25:43 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2472 On Mon, Dec 1, 2008 at 12:45 PM, Javier De Posada <jposada< at >e-commfactory.com> wrote: In English: "The keyboard will not have ' ñ ' key". I don't need it to code Cherokee! :P X-D Antonio Pérez 2008-12-01T16:00:30 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2471 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/ Alvaro Lopez Ortega 2008-12-01T14:25:50 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2470 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 2008-12-01T14:11:24 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2469 _______________________________________________ Cherokee mailing list Cherokee< at >lists.octality.com http://lists.octality.com/listinfo/cherokee Javier De Posada 2008-12-01T11:45:51 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2468 On Mon, Dec 1, 2008 at 12:00 PM, Alvaro Lopez Ortega <alvaro< at >octality.com> wrote: ¡Oe!, ¡oe, oe, oeeee! :-D Thank you guys!, thank you very much! :-) Thanks to Accenture too, of course! :-) Antonio Pérez 2008-12-01T11:37:36 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2467 Hi there, A few weeks ago, we announced a contest where the best project contribution would win an Asus EeePC [1]. The time has come to announce the contest winners, but before doing so, I'd like to let you know that our sponsor for this contest (Accenture [2]) has been kind enough to double the prize. That means, we are actually giving away two Asus EeePCs to two of our project contributors! Having said that, I'm delighted to announce that the winners of the notebooks are: Jonathan Hernandez and Antonio Perez. - Jonathan Hernandez has done an astonishing work on the upcoming new cherokee-admin interface. It hasn't been integrated yet, but I tell you guys, you're gonna love it! - Antonio Perez has played a very important role in the past few releases. He has reported and fixed some of the most nasty bugs we've ever had to face. His work and proactivity are helping Cherokee to improve each single day. I'd like to extend this recognition to the rest of the people who, in one way or the other, are working to make Cherokee a better server. I know that there are many other people who deserve to win the prize as well, so I will do my best to get new sponsorships to continue organizing this sort of contest. Congratulations to everybody. Accenture, thanks a million! Cheers! :-) 1.- http://lists.octality.com/pipermail/cherokee/2008-September/008861.html 2.- http://www.accenture.com/ -- Octality http://www.octality.com/ Alvaro Lopez Ortega 2008-12-01T11:00:24 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2466 Available in FreeBSD ports: www/cherokee Beech Beech Rintoul 2008-11-30T23:40:57 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2465 Debs for Ubuntu Intrepid and Hardy Ready at the usual Place : https://launchpad.net/~cherokee-webserver/+archive Saludos Leonel Leonel Nunez 2008-11-30T15:38:03 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2464 On Sat, Nov 29, 2008 at 6:25 PM, Alvaro Lopez Ortega <alvaro< at >octality.com> wrote: Sorry, I try both methods, my intention is to use sockets, but I see that in the conf files i send is listen to 127.0.0.1:3033, for both ways happens the same problem, look en the site.py file I just change the function to start to serve the project. Like I say I try both methods. Mario César 2008-11-30T11:47:28 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2463 =========================== Cherokee 0.11.2 released! =========================== Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, TLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly encoding, Apache compatible log files, HTTP load balancing, data base balancing, and much more. Cherokee also provides an easy to use configuration interface that allows to configure the server from top to bottom without having to edit a text configuration file. Please visit the Cherokee Web Server site for more information: http://www.cherokee-project.com/ Availability ------------ - Main site: http://ftp.cherokee-project.com/0.11/0.11.2/cherokee-0.11.2.tar.gz - US Mirror: http://cherokee.osuosl.org/0.11/0.11.2/cherokee-0.11.2.tar.gz MD5 (cherokee-0.11.2.tar.gz) = 11f442629d14be59d110e6aa3fe4e102 Changes ------- This is a bug fixing release of the stable branch. The following bugs have been fixed: - dirlist: 'Long File Support' fixed - dirlist themes use UTF-8 encoding now - cryptor_libssl: a license exemption for OpenSSL has been added Mailing lists ------------- You can find a list of our available mailing at: http://lists.cherokee-project.com/ Feedback -------- Bugs and Requests for features can be submitted too. We will be happy to take care of them. Your feedback is very valuable to us! http://bugs.cherokee-project.com/ Acknowledges ------------ A whole lot of people have contributed with the project during the last years; without their help Cherokee could not be possible. Many thanks to everybody who has contributed. Special acknowledges to our main contributors for this release: - Taher Shihadeh - Emil Renner Berthing - Gunnar Wolf - Antonio Perez - Stefan de Konink - Jędrzej Nowak - Tim Post ROCK ON!! -- Octality http://www.octality.com/ _______________________________________________ Cherokee mailing list Cherokee< at >lists.octality.com http://lists.octality.com/listinfo/cherokee Alvaro Lopez Ortega 2008-11-30T10:01:42 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2462 There are other libssl than openssl, do that isn't completely true. Anyway, I have already added the license exemption to the cryptor- libssl plug-in, so it should be just fine now. Gunnar, thanks for reporting! :-) -- Octality http://www.octality.com/ Alvaro Lopez Ortega 2008-11-30T09:45:27 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2461 Hi, chiming in: On Sat, 2008-11-29 at 23:19 +0100, Stefan de Konink wrote: The advertising clause in the original BSD license is probably the most obnoxious thing ever written into a software license. The advertising clause is just that, an advertising clause. If you set up a business around Cherokee that sold boxed / pre-compiled versions of Cherokee that were linked with OpenSSL ... then advertised your product in a magazine, the advertising clause would apply to you. It does not mean that you must advertise OpenSSL in Cherokee start up. This clause imposes additional restrictions beyond the GPL, hence its incompatibility. The Debian free software guidelines are very specific. This problem is easily fixable. The original BSD license conflicts with the GPL, so Debian can not distribute binary copies of Cherokee while obeying Cherokee's license. This has been raised on debian-legal many times. I thought OpenSSL had dropped that obnoxious clause or I would have raised this issue when the proposal to drop TLS was raised. OpenSSH is under the X11 license (aka modified BSD) which allows people to place additional restrictions on downstream recipients. Therefore, the two do not conflict. The GPL says "no additional restrictions", yet the terms of OpenSSL's license place additional restrictions. So, Debian would be (technically) violating the GPL2 by distributing Cherokee. It comes down to, while the advertising clause is obnoxious, the GPL is technically the more restrictive license, hence it must prevail. It can not prevail due to the advertising clause in the original BSD license. This is why its so much better to release any kind of library under the X11 or LGPL .. its so much less headache. Cheers, --Tim Tim Post 2008-11-30T01:34:35 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2460 Hello Mario, Please, correct me if I'm wrong.. but, I'd say that the problem is an inconsistency between the source file and the configuration: The SCGI application listens 127.0.0.1:3303, while Cherokee's been configured to use the /tmp/noentrar.socket unix socket to access the application. Am I missing something? On 29-nov-08, at 19:28, Mario César wrote: -- Octality http://www.octality.com/ Alvaro Lopez Ortega 2008-11-29T22:25:33 http://permalink.gmane.org/gmane.comp.web.cherokee.general/2459 I read them; and it seems not even OpenSSH is writing every startup: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" So basically if the readme stated we use OpenSSL that would be enough to allow linking to OpenSSL headers right? "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Clearly is talking about distribution of sourcecode. Not about executables or linking. It merely gives away the right to modify code that uses OpenSSL. But if I understand it right, Debian is *now* not shipping Cherokee because of this non-sence? So why is Debian angry in the first place? I guess, like ffmpeg, Debian could also have disabled crypto. Now that would have given an interesting situation. Please comment at my first issue. I don't see OpenSSH doing this, it is included in Debian, what makes *that* it more legal than Cherokee? Stefan _______________________________________________ Cherokee mailing list Cherokee< at >lists.octality.com http://lists.octality.com/listinfo/cherokee Stefan de Konink 2008-11-29T22:19:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.cherokee.general