Ayron Jungren | 1 Oct 02:38 2009
Picon

Re: cherokee + phusion passenger + ruby enterprise

Not that I am an advocate of REE, but how is it non-free? The only way it could be considered remotely non-free is that the license of two files (which even according the the LEGAL file itself are rarely used, so can be deleted on 99% of platforms) is a BSD-style license that could be interpreted to mean that it prohibits collecting a fee, but only for the file in question, not REE itself.


PS: I use Mongrel myself, but I also believe that people should have the choice of using what they desire. With that being said, Passenger is an Apache module, and I believe it should stay that way. :)

On Wed, Sep 30, 2009 at 2:58 PM, Gunnar Wolf <gwolf <at> gwolf.org> wrote:
Actually, the only real feature gain that Passenger would bring is the
seamless application restarts — Given all the performance gain comes
from the (completely non-free) REE, you would be better off using
Mongrel.
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
psykosnake@onlinehome.de | 1 Oct 18:16 2009
Picon

How to do this in cherokee

Hello,
i this is about the deluge webui.
Normal it is started like the cherokee weadmin into an port but i want 
to have it into an forlder like /var/www/deluge/
Here its explained how to do it into apache but i dont know how to port 
that into cherokee. Link : 
http://forum.deluge-torrent.org/viewtopic.php?f=8&t=4075
Here its just what they wrote:

deluge_apache_config.py

Code: Select all <http://forum.deluge-torrent.org/viewtopic.php?f=8&t=4075#>
    |#!/usr/bin/env python

    #config ; EDIT THIS
    CONFIG_DIR =  '/home/martijn/.config/deluge' #No trailing slashes.
    BASE_URL = '/deluge' #the apache url /No trailing slashes.
    #/config

    #Do not edit this:
    from deluge.ui.webui import apache
    application = apache.get_wsgi_application(BASE_URL, CONFIG_DIR)|

/etc/apache2/apache2.conf

Code: Select all <http://forum.deluge-torrent.org/viewtopic.php?f=8&t=4075#>
    |### deluge
    # WSGIRestrictStdout must be Off , this will be fixed, eventually...
    # deluge only supports 1 process, but you are free to configure the
    number of threads.
    # more info:
    # http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives

    WSGIRestrictStdout Off
    WSGIProcessGroup deluge
    WSGIDaemonProcess deluge processes=1 threads=25
    Alias /deluge/static/
    /usr/lib/python2.5/site-packages/deluge-0.6.0.0-py2.5-linux-i686.egg/deluge/ui/webui/static/
    WSGIScriptAliasMatch ^/deluge/(.*)
    /home/martijn/prj/WebUi/scripts/deluge_apache_config.py/$1
    |

Note: make sure that the config-dir is writable by the webserver-process 
(configuring the wsgi daemon user is left as an exersize to the reader)
tail /var/log/apache2/error.log when you're encountering problems.
dev: webui, core, labels | irc:vonck7 |

Maybe this is also done over fastcgi but im not sure and i dont want to 
try around since my cherokee runs so nice at the moment :P
Maybe someone knows a solution :)
Paul Ciarfella | 1 Oct 18:49 2009
Picon

How to enable SSI includes?

I've been struggling with how to enable SSI includes to include a standard banner and footer on my pages.  I'm
looking for the correct rule that allows SSI includes.

The files are included when I have a directory rule on / with an SSI handler, but then I can't get the default
index.html page.

The default rule for / is directory with handle List and Send.

When I change the ssi rule to be either a directory rule on /ssi, or a fullpath rule on /ssi with an SSI handler,
I can get the default index.html page, but not the SSI includes.  

The include I have in my html files is: 
<!--#include virtual="banner.html" -->
or
<!--#include virtual="ssi/banner.html" -->
depending on what combination of rules I'm trying.

What is the correct set of rules to allow SSI includes and have a default page of index.html?  A real
cherokee.conf sample would be useful ...

The main rules from cherokee.conf are below if that helps...

Thanks for your assistance.

Paul C

server!bind!1!port = 80
server!chunked_encoding = 1
server!iocache = 1
server!keepalive = 1
server!keepalive_max_requests = 500
server!panic_action = /usr/local/cherokee/bin/cherokee-panic
server!pid_file = /usr/local/cherokee/var/run/cherokee.pid
server!server_tokens = full
server!timeout = 15
vserver!10!collect_statistics = 1
vserver!10!directory_index = index.html
vserver!10!document_root = /home/pciarfella/www
vserver!10!keepalive = 1
vserver!10!logger = combined
vserver!10!logger!access!buffsize = 16384
vserver!10!logger!access!filename = /usr/local/cherokee/var/log/cherokee.access
vserver!10!logger!access!type = file
vserver!10!logger!error!filename = /usr/local/cherokee/var/log/cherokee.error
vserver!10!logger!error!type = file
vserver!10!logger!x_real_ip_access_all = 0
vserver!10!logger!x_real_ip_enabled = 0
vserver!10!nick = default
vserver!10!rule!1000!encoder!deflate = 0
vserver!10!rule!1000!encoder!gzip = 0
vserver!10!rule!1000!handler = fcgi
vserver!10!rule!1000!handler!balancer = round_robin
vserver!10!rule!1000!handler!balancer!source!1 = 1
vserver!10!rule!1000!handler!change_user = 0
vserver!10!rule!1000!handler!check_file = 1
vserver!10!rule!1000!handler!error_handler = 0
vserver!10!rule!1000!handler!pass_req_headers = 0
vserver!10!rule!1000!handler!xsendfile = 0
vserver!10!rule!1000!match = fullpath
vserver!10!rule!1000!match!final = 1
vserver!10!rule!1000!match!fullpath!1 = /logs
vserver!10!rule!1000!no_log = 0
vserver!10!rule!1000!only_secure = 0
vserver!10!rule!900!encoder!deflate = 0
vserver!10!rule!900!encoder!gzip = 0
vserver!10!rule!900!handler = fcgi
vserver!10!rule!900!handler!balancer = round_robin
vserver!10!rule!900!handler!balancer!source!1 = 1
vserver!10!rule!900!handler!change_user = 0
vserver!10!rule!900!handler!check_file = 0
vserver!10!rule!900!handler!error_handler = 0
vserver!10!rule!900!handler!pass_req_headers = 1
vserver!10!rule!900!handler!xsendfile = 0
vserver!10!rule!900!match = fullpath
vserver!10!rule!900!match!directory = /get
vserver!10!rule!900!match!final = 1
vserver!10!rule!900!match!fullpath!1 = /get
vserver!10!rule!900!no_log = 0
vserver!10!rule!900!only_secure = 0
vserver!10!rule!800!encoder!deflate = 0
vserver!10!rule!800!encoder!gzip = 0
vserver!10!rule!800!handler = fcgi
vserver!10!rule!800!handler!balancer = round_robin
vserver!10!rule!800!handler!balancer!source!1 = 1
vserver!10!rule!800!handler!change_user = 0
vserver!10!rule!800!handler!check_file = 0
vserver!10!rule!800!handler!error_handler = 1
vserver!10!rule!800!handler!pass_req_headers = 1
vserver!10!rule!800!handler!xsendfile = 0
vserver!10!rule!800!match = fullpath
vserver!10!rule!800!match!final = 1
vserver!10!rule!800!match!fullpath!1 = /pdp
vserver!10!rule!800!no_log = 0
vserver!10!rule!800!only_secure = 0
vserver!10!rule!700!encoder!deflate = 0
vserver!10!rule!700!encoder!gzip = 0
vserver!10!rule!700!handler = fcgi
vserver!10!rule!700!handler!balancer = round_robin
vserver!10!rule!700!handler!balancer!source!1 = 1
vserver!10!rule!700!handler!change_user = 0
vserver!10!rule!700!handler!check_file = 0
vserver!10!rule!700!handler!error_handler = 1
vserver!10!rule!700!handler!pass_req_headers = 1
vserver!10!rule!700!handler!xsendfile = 0
vserver!10!rule!700!match = fullpath
vserver!10!rule!700!match!directory = /getschema
vserver!10!rule!700!match!final = 1
vserver!10!rule!700!match!fullpath!1 = /getschema
vserver!10!rule!700!no_log = 0
vserver!10!rule!700!only_secure = 0
vserver!10!rule!600!handler = common
vserver!10!rule!600!match = directory
vserver!10!rule!600!match!directory = /
vserver!10!rule!600!match!final = 1
vserver!10!rule!500!encoder!gzip = 1
vserver!10!rule!500!handler = server_info
vserver!10!rule!500!handler!type = just_about
vserver!10!rule!500!match = directory
vserver!10!rule!500!match!directory = /about
vserver!10!rule!500!match!final = 1
vserver!10!rule!400!document_root = /usr/local/cherokee/lib/cgi-bin
vserver!10!rule!400!handler = cgi
vserver!10!rule!400!match = directory
vserver!10!rule!400!match!directory = /cgi-bin
vserver!10!rule!400!match!final = 1
vserver!10!rule!300!document_root = /usr/local/cherokee/share/cherokee/themes
vserver!10!rule!300!handler = file
vserver!10!rule!300!match = directory
vserver!10!rule!300!match!directory = /cherokee_themes
vserver!10!rule!300!match!final = 1
vserver!10!rule!200!document_root = /usr/local/cherokee/share/cherokee/icons
vserver!10!rule!200!handler = file
vserver!10!rule!200!match = directory
vserver!10!rule!200!match!directory = /icons
vserver!10!rule!200!match!final = 1
vserver!10!rule!100!encoder!deflate = 0
vserver!10!rule!100!encoder!gzip = 0
vserver!10!rule!100!expiration!time = 5m
vserver!10!rule!100!handler = common
vserver!10!rule!100!handler!allow_dirlist = 1
vserver!10!rule!100!handler!allow_pathinfo = 0
vserver!10!rule!100!handler!date = 1
vserver!10!rule!100!handler!group = 0
vserver!10!rule!100!handler!iocache = 0
vserver!10!rule!100!handler!size = 1
vserver!10!rule!100!handler!symlinks = 1
vserver!10!rule!100!handler!theme = default
vserver!10!rule!100!handler!user = 0
vserver!10!rule!100!match = default
vserver!10!rule!100!match!final = 1
vserver!10!rule!100!no_log = 0
vserver!10!rule!100!only_secure = 0
pub crawler | 2 Oct 18:44 2009
Picon

Cherokee startup from cherokee-admin and setting environmental variables

Good day everyone!

Still wrestling with ulimit values causing Cherokee to 503 error crash.

Our solution has been to set ulimit for open files higher - to 9000 to be exact.

That has worked for a few weeks. However, we were smacked by the 503
error again today. What happened is simple, I turned Keep Alive back
on and ulimit for open files was 1024. Unsure why ulimit was set to
1024 again. So open file resources were eventually exhausted, never
released and Cherokee kept sending a 503. We long term need to build
intelligence into Cherokee to prune open kept alive connections when
such a resource contention exists.

For now, I need input on a workaround so we never get 503'd by this
again.  Here's what I propose:

We use cherokee-admin to run and restart Cherokee fairly often. We try
to avoid manually running Cherokee unless we really have to for some
reason like testing a specific release.

Is there a way to append to logic to the LAUNCH handler on the main
admin screen? When I click launch I want Cherokee to go ahead and step
up the ulimit as insurance that the environment it is running in has
same limits every time.

Anyone have any ideas about this or better way to accomplish this?

Thanks!
-Paul
Taher Shihadeh | 2 Oct 20:01 2009

Re: Cherokee startup from cherokee-admin and setting environmental variables

Excuse me if I'm missing the point and the answer seems simplistic. We 
will have to correctly deal with the 503 problem eventually, but 
answering the question about the workaround you are looking for: 
Wouldn't it be simpler just to have a cron task pumping ulimit values 
and gracefully restarting via the appropriate signal? Seems much more 
straight forward to me than making changes to the admin.

You can, of course, rewire cherokee-admin and add whatever you please. 
Any logic on how it restarts the server can be found in 
admin/CherokeeManagement.py, which, by the way, is simply issuing the 
SIGHUP or SIGUSR1 signals mentioned  in the documentation [1]

[1] http://www.cherokee-project.com/doc/other_signals.html

pub crawler wrote:
> Good day everyone!
>
> Still wrestling with ulimit values causing Cherokee to 503 error crash.
>
> Our solution has been to set ulimit for open files higher - to 9000 to be exact.
>
> That has worked for a few weeks. However, we were smacked by the 503
> error again today. What happened is simple, I turned Keep Alive back
> on and ulimit for open files was 1024. Unsure why ulimit was set to
> 1024 again. So open file resources were eventually exhausted, never
> released and Cherokee kept sending a 503. We long term need to build
> intelligence into Cherokee to prune open kept alive connections when
> such a resource contention exists.
>
> For now, I need input on a workaround so we never get 503'd by this
> again.  Here's what I propose:
>
> We use cherokee-admin to run and restart Cherokee fairly often. We try
> to avoid manually running Cherokee unless we really have to for some
> reason like testing a specific release.
>
> Is there a way to append to logic to the LAUNCH handler on the main
> admin screen? When I click launch I want Cherokee to go ahead and step
> up the ulimit as insurance that the environment it is running in has
> same limits every time.
>
> Anyone have any ideas about this or better way to accomplish this?
>
> Thanks!
> -Paul
>   

--

-- 
taher <at> unixwars.com
http://unixwars.com/
Juan José Amor | 2 Oct 20:05 2009
Picon

Cherokee 0.99.24 segfaults when using fastcgi servers ...


Hello all,

Last weeks I tested with 0.99.22 that, if I try to use php-cgi with unix
socket as FastCGI server, cherokee segfaulted when it tried to launch
it. But not when using IP:port instead UX socket... some messages here
confirmed that by using tcp sockets is more stable.

Now, testing spawn-fcgi to launch Moinmoin fastcgi server (moin.fcg),
the behaviour is more strange: if I try to launch with IP:port pair it
faults. Example:

source!2!host = 127.0.0.1:25000
source!2!interpreter = /opt/cherokee/bin/spawn-fcgi -f
/var/www/moin-root/server/moin.fcg -a 127.0.0.1 -p 25000
source!2!nick = Moin FCGI
source!2!type = interpreter

But, changing to UX socket, it works!:

source!2!host = /tmp/moin-fcg.sock
source!2!interpreter = /opt/cherokee/bin/spawn-fcgi -f
/var/www/moin-root/server/moin.fcg -s /tmp/moin-fcg.sock
source!2!nick = Moin FCGI
source!2!type = interpreter

But more more strange: if I try to specify another parameter (-F 5, for
five child) it segfaults again:

source!2!host = /tmp/moin-fcg.sock
source!2!interpreter = /opt/cherokee/bin/spawn-fcgi -F 5 -f
/var/www/moin-root/server/moin.fcg -s /tmp/moin-fcg.sock
source!2!nick = Moin FCGI
source!2!type = interpreter

Cherokee 0.99.24 and spawn-fcgi v1.6.3 are running on Opensolaris
2009.06 Sparc64 (running on Sun Fire T2000 server), and were compiled
with gcc 3.4.3.

Any ideas?

Thanks in advance!

--

-- 

  Juan Jose Amor Iglesias  //  -+- ¡Vorágine! -+-
  jjamor -at- gmail.com // juanjo -at- dramor.net

--------------------       Visit my Blog! ---------------------
 The Boring Stories Written By DrAmor: http://dramor.net/blog/
---------------------------------------------------------------
pub crawler | 2 Oct 21:00 2009
Picon

Re: Cherokee startup from cherokee-admin and setting environmental variables

Thanks for responding Taher,

Cron job was our first idea - we have lots of cron tasks already
munging various things and sanitizing our environment - like checking
for certain temp sub directories exist. Since I am unsure exactly what
determines the runtime values for Cherokee and having heard from
Alvaro that Cherokee attempts to bump the ulimit at start time I
thought it was best to make sure the ulimit was artificially high
already when Cherokee starts up.

Since our issue with the 503s is a runtime environmental value thought
it was best to link the ulimit increase/set to when Cherokee is
started from the admin.

I would hate to mess with Cherokee code as we often upgrade to the
latest releases.

Perhaps a setting in the admin for ulimit for open files would be the
good middle ground?

BTW: Ulimit issues are fairly common with many similar software
packages. Cherokee assumes a lower knowledge point to entry with the
simplified admin GUI. Having people run into the 503 error due to
ulimit is per se preventable by configuring the environmental variable
in the admin and pruning connections when limit hit. We could even
note the limit ceiling hit and put a message then in admin about
increasing the ulimit.

On Fri, Oct 2, 2009 at 2:01 PM, Taher Shihadeh <taher <at> unixwars.com> wrote:
> Excuse me if I'm missing the point and the answer seems simplistic. We will
> have to correctly deal with the 503 problem eventually, but answering the
> question about the workaround you are looking for: Wouldn't it be simpler
> just to have a cron task pumping ulimit values and gracefully restarting via
> the appropriate signal? Seems much more straight forward to me than making
> changes to the admin.
>
> You can, of course, rewire cherokee-admin and add whatever you please. Any
> logic on how it restarts the server can be found in
> admin/CherokeeManagement.py, which, by the way, is simply issuing the SIGHUP
> or SIGUSR1 signals mentioned  in the documentation [1]
>
> [1] http://www.cherokee-project.com/doc/other_signals.html
>
> pub crawler wrote:
>>
>> Good day everyone!
>>
>> Still wrestling with ulimit values causing Cherokee to 503 error crash.
>>
>> Our solution has been to set ulimit for open files higher - to 9000 to be
>> exact.
>>
>> That has worked for a few weeks. However, we were smacked by the 503
>> error again today. What happened is simple, I turned Keep Alive back
>> on and ulimit for open files was 1024. Unsure why ulimit was set to
>> 1024 again. So open file resources were eventually exhausted, never
>> released and Cherokee kept sending a 503. We long term need to build
>> intelligence into Cherokee to prune open kept alive connections when
>> such a resource contention exists.
>>
>> For now, I need input on a workaround so we never get 503'd by this
>> again.  Here's what I propose:
>>
>> We use cherokee-admin to run and restart Cherokee fairly often. We try
>> to avoid manually running Cherokee unless we really have to for some
>> reason like testing a specific release.
>>
>> Is there a way to append to logic to the LAUNCH handler on the main
>> admin screen? When I click launch I want Cherokee to go ahead and step
>> up the ulimit as insurance that the environment it is running in has
>> same limits every time.
>>
>> Anyone have any ideas about this or better way to accomplish this?
>>
>> Thanks!
>> -Paul
>>
>
> --
> taher <at> unixwars.com
> http://unixwars.com/
>
>
Alvaro Lopez Ortega | 3 Oct 02:48 2009

Re: Cherokee 0.99.24 segfaults when using fastcgi servers ...

2009/10/3 Juan José Amor jjamor <at> gmail.com
 

But more more strange: if I try to specify another parameter (-F 5, for
five child) it segfaults again:

source!2!host = /tmp/moin-fcg.sock
source!2!interpreter = /opt/cherokee/bin/spawn-fcgi -F 5 -f
/var/www/moin-root/server/moin.fcg -s /tmp/moin-fcg.sock
source!2!nick = Moin FCGI
source!2!type = interpreter
 
Sounds like a bug. Could you please log a bug for this?
 

Cherokee 0.99.24 and spawn-fcgi v1.6.3 are running on Opensolaris
2009.06 Sparc64 (running on Sun Fire T2000 server), and were compiled
with gcc 3.4.3.

Any ideas?
 
Dunno whether it has something to do, but.. have you tried to increase the spawning timeout limit?
 
--
Greetings, alo
http://www.alobbs.com/
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
Gunnar Wolf | 3 Oct 06:45 2009

Update on the .deb packaging

Hi,

Good news: 

After several months redoing the packaging from scratch, Cherokee
0.99.24 has been uploaded to Debian!

http://packages.qa.debian.org/c/cherokee/news/20091003T011724Z.html

http://packages.qa.debian.org/c/cherokee.html

I have not yet uploaded to Debian Unstable, as I am still unsure on
whether the packaging is sound — I made this upload to Experimental,
which means you will only get the packages if you explicitly ask
apt-get to use Experimental - And it is usually not too wise to
abuse. The packaging is still not prime quality, and I still have some
critical and important bugs to squish before uploading to unstable -
But I am sure it will be worth the wait.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=cherokee

Still, as the developer community, and as the community driving the
usage of this webserver, I invite you to test the packaging and to
comment on any weirdness. FWIW, I have already found a
non-concurrently-installable bug in some of the packages (some of them
are providing the same files)... Will be fixed soon.

Leonel: For building and playing with Ubuntu, I am building in the
'dh7' branch of the git repository.

I want to make my low library-fu obvious again: Álvaro and friends,
why are some libraries/modules/plugins compiled only to .so, and some
also to .a and to .la? As an example, out of a usual build, I get:

If I understand this correctly, I should be able to provide only the
.so files and ignore the others? (Debian frowns on statically linked
libraries) Or am I getting it all wrong and the .so should be provided
in the library, while the .a and .la in the development package
(allowing others to link to said library)?

Anyway, I'll also ask around within Debian. But still, if you have
some insight to give, please do so.

Thanks!

--

-- 
Gunnar Wolf • gwolf <at> gwolf.org • (+52-55)5623-0154 / 1451-2244
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
LinuxInsight | 3 Oct 14:47 2009
Picon

Re: Update on the .deb packaging

Gunnar Wolf wrote:
> Hi,
> 
> Good news: 
> 
> After several months redoing the packaging from scratch, Cherokee
> 0.99.24 has been uploaded to Debian!
> 
> http://packages.qa.debian.org/c/cherokee/news/20091003T011724Z.html
> 
> http://packages.qa.debian.org/c/cherokee.html
> 
> I have not yet uploaded to Debian Unstable, as I am still unsure on
> whether the packaging is sound — I made this upload to Experimental,
> which means you will only get the packages if you explicitly ask
> apt-get to use Experimental - And it is usually not too wise to
> abuse. The packaging is still not prime quality, and I still have some
> critical and important bugs to squish before uploading to unstable -
> But I am sure it will be worth the wait.
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=cherokee
> 
> Still, as the developer community, and as the community driving the
> usage of this webserver, I invite you to test the packaging and to
> comment on any weirdness. FWIW, I have already found a
> non-concurrently-installable bug in some of the packages (some of them
> are providing the same files)... Will be fixed soon.

Hello Gunnar!

Your announcement made me very happy as I've been waiting for a newer 
version of Cherokee in Debian. And you're right, there must be early 
adopters to weed the most nasty bugs before the package hits the 
official repositories.

So I went straight away to Debian FTP to download packages, but I 
couldn't find the i386 architecture package of cherokee 0.99.24, only 
amd64 is available for download, what happened?

Thanks for your work!
--

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

Gmane