Alvaro Lopez Ortega | 2 Aug 2007 23:27
Picon
Gravatar

PySCGI 1.2 released

PySCGI 1.2 released
===================

PySCGI is a 100% Python module implementing the SCGI protocol.
It can be used to write Python-based application servers.

Download
--------
  http://www.cherokee-project.com/download/pyscgi/cherokee_pyscgi-1.2.tar.gz

Changes
-------
  - Couple of bugs have been fixed
  - Code clean-up

--

-- 
Greetings, alo.
http://www.alobbs.com
das | 3 Aug 2007 03:47

PHP with cgi, phpcgi and fcgi

Hello,

I've set up cherokee today. I'm using Ubuntu Feisty Fawn AMD64, Cherokee
0.5.5 and php 5.2.1. I've tried three different ways to get php working:

Directory /foo {
  Handler fcgi {
    ChangeUser on
    Server localhost:8001 {
      Env PHP_FCGI_CHILDREN "5"
      Interpreter "/usr/bin/php5-cgi -b localhost:8001 -d
open_basedir=/foobar:/tmp"
    }
  }
}

Directory /bar {
  Handler cgi {
    ChangeUser on
    Interpreter "/usr/bin/php5-cgi -d open_basedir=/foobar:/tmp"
  }
}

Directory /foobar {
  Handler phpcgi {
    ChangeUser on
    Interpreter "/usr/bin/php5-cgi -d open_basedir=/foobar:/tmp"
  }
}

(Continue reading)

Gunnar Wolf | 13 Aug 2007 15:05
Gravatar

The 'admin' plugin in 0.5.6 - Usable?

tags 434940 confirmed,upstream
thanks

Hi,

Cherokee developers: Please take a look at Debian bug report #434940:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434940 

Rafal complains that we are shipping
/etc/cherokee/mods-available/admin, but whenever we link the file from
/etc/cherokee/mods-enabled, Cherokee refuses to start:

module_loader.c:226: ERROR: dlopen(/usr/lib/cherokee/libplugin_admin.so):
/usr/lib/cherokee/libplugin_admin.so: cannot open shared object file: No such file or directory
module_loader.c:378: ERROR: Can't open "admin" module
ERROR: Loading module 'admin'
Couldn't read the config file

Now, of course, this is intentional, as in the package building
session I held with Álvaro some years ago already, he asked me to
include this in debian/rules:

# FIX 6: This stuff is not ready to be used
  rm $(BUILD_DIR)/usr/lib/libcherokee-config*
  rm $(BUILD_DIR)/usr/lib/cherokee/libplugin_admin*
  rm $(BUILD_DIR)/usr/lib/cherokee/libplugin_fastcgi*

It seems we only forgot to remove the reference from
mods-available. Now, given this was made many years ago already:
What's the status, as of 0.5.6, of the admin module? Should I remove
(Continue reading)

Gunnar Wolf | 15 Aug 2007 14:21
Gravatar

Re: The 'admin' plugin in 0.5.6 - Usable?

A.D.F. dijo [Mon, Aug 13, 2007 at 07:29:46PM +0000]:
> IMHO I would remove the reference and all the *admin* files too,
> but of course this should be done by Alvaro.

Ok, thanks a lot - I will do it in the Debian packaging. 

> Version 0.5.6 was released almost 8 months ago and
> because everybody thought that the next release would have been 0.6.0,
> nobody cared about open bugs, etc.
> 
> If people maintaining stable versions of Cherokee 0.5.5 or 0.5.6
> would care to send to cherokee <at> cherokee-project.com or (better)
> to cherokee-http-dev <at> googlegroups.com their patches,
> I guess that Alvaro could rethink about releasing
> a stable 0.5.7 version (also because many people will not
> switch to 0.6.0 until it is really ready (i.e. documentation,
> administration interface, etc.) and so not before other 2 or 3 months.
> 
> I already backported to svn branch 0.5 a few fixes,
> so if there is some interest for a 0.5.7 release,
> I could backport many more from trunk.

I am aware of this situation, as well as I'm aware that Álvaro is tied
up with his many real-life activities now, and -quite explainably- his
sometimes unexplainable drive on Cherokee had to somehow
adjust. Anyway, that's why we act (and I include myself, if for
anything, for handling the Debian packaging) as a team :)

ADF: My personal opinion is that a 0.5.7 would be due and
welcome. There must have several accumulated fixes over the past 8
(Continue reading)

Brian Kerrick Nickel | 16 Aug 2007 00:21
Picon

Disabling handler_error for FastCGI

Hi,

I have a FastCGI program that prints out its own messages when it has a
500 or 404 error, but when I use it in Cherokee, I get the standard
Cherokee error messages.

Is there a way to get around this?

Thanks,
Brian
Alvaro Lopez Ortega | 17 Aug 2007 20:11
Picon
Gravatar

Re: Disabling handler_error for FastCGI

Brian Kerrick Nickel wrote, On 16/08/07 00:21:

 > I have a FastCGI program that prints out its own messages when it
 > has a 500 or 404 error, but when I use it in Cherokee, I get the
 > standard Cherokee error messages.
 >
 > Is there a way to get around this?

Sure. You just need to use the ErrorHandler property (0.5.x) or the
equivalent "!error_handler = 1" in Cherokee 0.6.0-beta.

--

-- 
Greetings, alo.
http://www.alobbs.com
Vernon Mauery | 23 Aug 2007 07:27

Sample version 6 configuration

Hi,

I am testing out the 6.0 beta and have found documentation on the
config files to be rather sparse (read non-existent).  What I have so
far is cobbled together from various sources that google could
scrounge up for me, reading the 05to60.py script, and browsing the
cherokee source.

Alvaro, could you please post a sample configuration file that you use
for testing the parsing of the configuration files?

I finally did manage to get the scgi interface working to interface
with the pyscgi server (version 1.2) with the error_handler enabled,
so things are mostly working, but I would like to figure out how to do
virtual hosts (I only have vserver!default! right now) and how to get
logging working.

Any help would be appreciated.

--Vernon
Brian Rosner | 23 Aug 2007 17:08
Picon
Gravatar

Re: Sample version 6 configuration

On 2007-08-22 23:27:41 -0600, "Vernon Mauery" <vernon-web <at> mauery.com> said:

> Hi,
> 
> I am testing out the 6.0 beta and have found documentation on the
> config files to be rather sparse (read non-existent).  What I have so
> far is cobbled together from various sources that google could
> scrounge up for me, reading the 05to60.py script, and browsing the
> cherokee source.
> 
> Alvaro, could you please post a sample configuration file that you use
> for testing the parsing of the configuration files?
> 
> I finally did manage to get the scgi interface working to interface
> with the pyscgi server (version 1.2) with the error_handler enabled,
> so things are mostly working, but I would like to figure out how to do
> virtual hosts (I only have vserver!default! right now) and how to get
> logging working.
> 
> Any help would be appreciated.
> 
> --Vernon

vserver!default is for the default virtual server.  If you do 
vserver!example.com then you will have a vserver for example.com.

We are currently working on documenting Cherokee and will have that 
ready for the 0.6 release.

--

-- 
(Continue reading)

Sergio Cuéllar Valdés | 23 Aug 2007 18:04
Picon
Gravatar

Re: Sample version 6 configuration

2007/8/23, Brian Rosner <brosner <at> gmail.com>:

> We are currently working on documenting Cherokee and will have that
> ready for the 0.6 release.

Hi,

do you know when will be the release of 0.6 ?

Best regards,
Sergio Cuéllar

--

-- 
"Meine Hoffnung soll mich leiten
Durch die Tage ohne Dich
Und die Liebe soll mich tragen
Wenn der Schmerz die Hoffnung bricht"
Alvaro Lopez Ortega | 23 Aug 2007 19:50
Picon
Gravatar

Re: Sample version 6 configuration

Brian Rosner wrote, On 23/08/07 17:08:
 > On 2007-08-22 23:27:41 -0600, "Vernon Mauery" <vernon-web <at> mauery.com> said:
 >
 >> Hi,
 >>
 >> I am testing out the 6.0 beta and have found documentation on the
 >> config files to be rather sparse (read non-existent).  What I have so
 >> far is cobbled together from various sources that google could
 >> scrounge up for me, reading the 05to60.py script, and browsing the
 >> cherokee source.
 >>
 >> Alvaro, could you please post a sample configuration file that you use
 >> for testing the parsing of the configuration files?
 >>
 >> I finally did manage to get the scgi interface working to interface
 >> with the pyscgi server (version 1.2) with the error_handler enabled,
 >> so things are mostly working, but I would like to figure out how to do
 >> virtual hosts (I only have vserver!default! right now) and how to get
 >> logging working.
 >>
 >> Any help would be appreciated.
 >>
 >> --Vernon
 >
 > vserver!default is for the default virtual server.  If you do
 > vserver!example.com then you will have a vserver for example.com.

qa/021-VirtualHost2.py is a good example for that:

You have to define the domain names with !domain!<number> entries. You
(Continue reading)


Gmane