Re: mod_wsgi and turbogears

2 views
Skip to first unread message

Lukasz Szybalski

unread,
Jan 23, 2008, 6:02:57 PM1/23/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
Hello,
I run into small probablems in my configuration/placement.

- I have compiled and enabled mod_wsgi 1.8 with apache2 on debian.
http://lucasmanual.com/mywiki/TurboGears#head-36b7eef1526da4fe58c73738c925f34f6bc93c1d

I have a basic turbogears app that turbogears created using
quickstart. I am trying to run it in mod_wsgi.

I have installed my app using egg deploy.

easy_install myfirstapp-1.0-py2.4.egg

It put my turbogears app in
/usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp

I put my myfirstapp.wsgi in /etc/myfirstapp
/etc/myfirstapp# ls -l
total 8
-rw-r--r-- 1 root root 1157 2008-01-23 16:20 myfirstapp.wsgi
-rw-r--r-- 1 root root 2045 2008-01-22 00:22 prod.cfg

myfirstapp.wsgi looks like this:
-----------------------------
import sys
sys.path.append('/usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp')
sys.stdout = sys.stderr

import os
os.environ['PYTHON_EGG_CACHE'] =
'/usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp'

import atexit
import cherrypy
import cherrypy._cpwsgi
import turbogears

turbogears.update_config(configfile="/etc/myfirstapp/prod.cfg",
modulename="myfirstapp.config")
turbogears.config.update({'global': {'server.environment': 'production'}})
turbogears.config.update({'global': {'autoreload.on': False}})
turbogears.config.update({'global': {'server.log_to_screen': False}})

#For non root mounted wiki:
turbogears.config.update({'global': {'server.webpath': '/myfirstapp'}})

import myfirstapp.controllers

cherrypy.root = myfirstapp.controllers.Root()

if cherrypy.server.state == 0:
atexit.register(cherrypy.server.stop)
cherrypy.server.start(init_only=True, server_class=None)

#For root mounted app
#application = cherrypy._cpwsgi.wsgiAppi

#For none-root mounted app
def application(environ, start_response):
environ['SCRIPT_NAME'] = ''
return cherrypy._cpwsgi.wsgiApp(environ, start_response)


--------------
My apache file in:
/etc/apache2/conf.d/myfirstapp looks like:
WSGIScriptAlias /myfirstapp /etc/myfirstapp/myfirstapp.wsgi

<Directory /usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp>
Order deny,allow
Allow from all
</Directory>

This is the error I am getting in my logs:
cat /var/log/apache2/error.log
-- resuming normal operations
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] mod_wsgi
(pid=4177): Target WSGI script '/etc/myfirstapp/myfirstapp.wsgi'
cannot be loaded as Python module.
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] mod_wsgi
(pid=4177): Exception occurred within WSGI script
'/etc/myfirstapp/myfirstapp.wsgi'.
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] Traceback (most
recent call last):
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] File
"/etc/myfirstapp/myfirstapp.wsgi", line 13, in ?
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1]
turbogears.update_config(configfile="/etc/myfirstapp/prod.cfg",
modulename="myfirstapp.config")
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] File
"/var/lib/python-support/python2.4/turbogears/config.py", line 207, in
update_config
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1]
configure_loggers(configdict)
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] File
"/var/lib/python-support/python2.4/turbogears/config.py", line 143, in
configure_loggers
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1]
_get_handlers(handlers, formatters)
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] File
"/var/lib/python-support/python2.4/turbogears/config.py", line 50, in
_get_handlers
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] raise
ConfigError("Missing or wrong argument to "
[Wed Jan 23 16:23:02 2008] [error] [client 127.0.0.1] ConfigError:
Missing or wrong argument to FileHandler in handler access_out ->
[Errno 13] Permission denied: 'server.log'


----
-What is wrong with this configuration?
-Configuration mentions writable cache folder? Where is that at? Do I need it?
- Is /usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp
prefered folder to link in apache?
- Is there a different way I should deploy my app? (not with
easy_install or some parameter for easy_install?)
- What should be the permissions on each of these files ,wsgi, prod.cfg,

Thanks,
Lucas

Graham Dumpleton

unread,
Jan 23, 2008, 6:44:04 PM1/23/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
On 24/01/2008, Lukasz Szybalski <szyb...@gmail.com> wrote:
> Hello,
> I run into small probablems in my configuration/placement.
>
> - I have compiled and enabled mod_wsgi 1.8 with apache2 on debian.
> http://lucasmanual.com/mywiki/TurboGears#head-36b7eef1526da4fe58c73738c925f34f6bc93c1d

Did you also check:

http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears

> I have a basic turbogears app that turbogears created using
> quickstart. I am trying to run it in mod_wsgi.
>
> I have installed my app using egg deploy.
>
> easy_install myfirstapp-1.0-py2.4.egg
>
> It put my turbogears app in
> /usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp

Manually, or did you properly install it using appropriate Python tools?

> I put my myfirstapp.wsgi in /etc/myfirstapp

That is a really bad place to put it, as it means you would have had
to allow Apache to serve up files in /etc. With a bit more Apache
misconfiguration and you could accidentally expose import system files
from your machine.

You are better off putting stuff under /usr/local or even in a
subdirectory of your personal account.

> /etc/myfirstapp# ls -l
> total 8
> -rw-r--r-- 1 root root 1157 2008-01-23 16:20 myfirstapp.wsgi
> -rw-r--r-- 1 root root 2045 2008-01-22 00:22 prod.cfg
>
> myfirstapp.wsgi looks like this:
> -----------------------------
> import sys
> sys.path.append('/usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp')

See comments below.

> sys.stdout = sys.stderr
>
> import os
> os.environ['PYTHON_EGG_CACHE'] =
> '/usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp'

See comments below.

Bad as noted above.

> <Directory /usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp>
> Order deny,allow
> Allow from all
> </Directory>

Not necessary.

That you haven't got a Directory block for /etc indicates the default
for your server maybe to allow access to everything, which is really
bad as Apache insecure by default.

> -What is wrong with this configuration?

What in your configuration mentions 'server.log'?

Because you are running in embedded mode, files and directories must
be accessible to user that Apache runs as. In this case, because it is
trying to write to the file, the directory actually needs to be
writable to Apache user. See section 'Access Rights Of Apache User'
of:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues

You may want to consider using mod_wsgi daemon mode and running
application as specific user.

Also, make sure you also read section 'Application Working Directory'
of the document above, as you need to also ensure you use absolute
path names, not relative path names.

> -Configuration mentions writable cache folder? Where is that at? Do I need it?

Are you talking about Python egg cache? See section 'User HOME
Environment Variable' of above document.

I would not recommend using:

os.environ['PYTHON_EGG_CACHE'] =
'/usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp'

as it pollutes your site-packages directory. Have it go somewhere else
if required.

> - Is /usr/lib/python2.4/site-packages/myfirstapp-1.0-py2.4.egg/myfirstapp
> prefered folder to link in apache?

Hmmm, if an egg version of application requires adding that
subdirectory of egg to sys.path explicitly, that is a bit of a pain.
If this is really required, may be better to use something like:

import myfirstapp.myfirstapp
sys.path.append(os.path.dirname(myfirstapp.myfirstapp.__file__))

Can some one on TG list explain the requirement here. Don't have
access to a TG installation at the moment to check.

> - Is there a different way I should deploy my app? (not with
> easy_install or some parameter for easy_install?)

You might investigate using virtual environments for a start so you
are installing your application into your OS Python installation. See:

http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

> - What should be the permissions on each of these files ,wsgi, prod.cfg,

See discussion about file permissions in the thread:
http://groups.google.com/group/modwsgi/browse_frm/thread/8b8f17d6b8bb8b59/f1eedcea6f43ea25?lnk=gst&q=rwx-----x#f1eedcea6f43ea25

Important things thus are, don't put stuff in /etc like you are. Fix
your Apache configuration so it doesn't allow access to all files on
your box by default. Then have a better read of documentation on
mod_wsgi site.

Graham

Graham Dumpleton

unread,
Jan 23, 2008, 7:54:07 PM1/23/08
to TurboGears


On Jan 24, 10:44 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> On 24/01/2008, Lukasz Szybalski <szybal...@gmail.com> wrote:
> > - Is there a different way I should deploy my app? (not with
> > easy_install or some parameter for easy_install?)
>
> You might investigate using virtual environments for a start so you
> are installing your application into your OS Python installation. See:
>
> http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

Obviously, meant to say 'so you aren't installing'.

Graham

Lukasz Szybalski

unread,
Jan 24, 2008, 12:51:32 AM1/24/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
ok lets get this working first.

> What in your configuration mentions 'server.log'?

ok I changed the 'server.log' to a full path.

>
My tg app is working but the static content is missing.
Normally when you start tgapp it expects the www.example.com/static/
How is that handled in mod_wsgi?

These are the current settings in app.cfg:
[/static]
static_filter.on = True
static_filter.dir = "%(top_level_dir)s/static"

Lucas

Graham Dumpleton

unread,
Jan 24, 2008, 2:22:26 AM1/24/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
On 24/01/2008, Lukasz Szybalski <szyb...@gmail.com> wrote:

I wouldn't expect serving up of static content to be affected unless
the location it is pointing at simply isn't where the files are
located.

In mod_wsgi, if you want Apache to serve up static files instead, so
that things are more effecient, then would use:

Alias /static /some/path/to/dir/static

<Directory /some/path/to/dir/static>
Order Allow,Deny
Allow from All
</Directory>

The Alias directive should appear before the WSGIScriptAlias directive
in the Apache configuration.

That directory and the files in it would need to be readable to user
that Apache runs as.

For more about static file serving see section 'Hosting Of Static Files' of:

http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines

It would be a good idea to read through the whole of that document as
explains various other configurations as well and may help to explain
things a bit better if you haven't already read it.

Graham

Lukasz Szybalski

unread,
Jan 24, 2008, 3:25:26 PM1/24/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
> In mod_wsgi, if you want Apache to serve up static files instead, so
> that things are more effecient, then would use:
>
> Alias /static /some/path/to/dir/static
>
> <Directory /some/path/to/dir/static>
> Order Allow,Deny
> Allow from All
> </Directory>
>
> The Alias directive should appear before the WSGIScriptAlias directive
> in the Apache configuration.
>
> That directory and the files in it would need to be readable to user
> that Apache runs as.
> For more about static file serving see section 'Hosting Of Static Files' of:
>
> http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
>
> It would be a good idea to read through the whole of that document as
> explains various other configurations as well and may help to explain
> things a bit better if you haven't already read it.

I read over the documentation but it seemed to much at one time so
these emails are really helping me to get the whole picture on
mod_wsgi configuration.

Lets talk folders.
- It seems as /var/www/myfirstapp is an optimal solution for folder choice.
- Since egg deploy puts stuff in python2.4/site-package it doesn't
seems as moving turbogears app via egg is fisable unless there is a
tg/egg command that I can specify which will allow me either
easy_install in /var/www/myfirstapp or to put my tg app in
/var/www/myfirstapp folder.
- I also put myfirstapp.wsgi in /var/www/myfirstapp/myfirstapp.wsgi
-Prod.cfg in /var/www/myfirstapp/prod.cfg
- The actual app is in /var/www/myfirstapp/myfirstapp/
- Static content is in /var/wwww/myfirstapp/myfirstapp/static
- Server.log is also in /var/www/myfirstapp/server.log (I am not sure
if this will be needed since I will be able to use apache logs to
monitor my app? Correct?) (If that is the case who knows how to
disable tg logs?)


Apache config:
----
Alias /static /var/www/myfirstapp/myfirstapp/static
WSGIScriptAlias /myfirstapp /var/www/myfirstapp/myfistapp.wsgi

<Directory /var/www/myfirstapp/myfirstapp >


Order deny,allow
Allow from all
</Directory>

------
Permissions for /var/www/myfirstapp would be apache user permissions (www-data)

-Does this folder structure sounds resonable?

-Now I run into problem where my app www.example.com/myfirstapp has a
login link that points to www.example.com/login How do I tell tg or
wsgi to use www.example.com/myfirstapp/login?

- What would be a apache/wsgi config for having http://myfirstapp.example.com?
- What would be the difference in wsgi and/or tg configuration for
myfirstapp.example.com vs example.com/myfirstapp?

Lucas

--
http://lucasmanual.com/mywiki/TurboGears#head-36b7eef1526da4fe58c73738c925f34f6bc93c1d

Graham Dumpleton

unread,
Jan 24, 2008, 8:12:06 PM1/24/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
On 25/01/2008, Lukasz Szybalski <szyb...@gmail.com> wrote:
> > In mod_wsgi, if you want Apache to serve up static files instead, so
> > that things are more effecient, then would use:
> >
> > Alias /static /some/path/to/dir/static
> >
> > <Directory /some/path/to/dir/static>
> > Order Allow,Deny
> > Allow from All
> > </Directory>
> >
> > The Alias directive should appear before the WSGIScriptAlias directive
> > in the Apache configuration.
> >
> > That directory and the files in it would need to be readable to user
> > that Apache runs as.
> > For more about static file serving see section 'Hosting Of Static Files' of:
> >
> > http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
> >
> > It would be a good idea to read through the whole of that document as
> > explains various other configurations as well and may help to explain
> > things a bit better if you haven't already read it.
>
> I read over the documentation but it seemed to much at one time so
> these emails are really helping me to get the whole picture on
> mod_wsgi configuration.
>
> Lets talk folders.
> - It seems as /var/www/myfirstapp is an optimal solution for folder choice.

Having the WSGI script file at least within a directory known to
Apache is necessary. This can be the main Apache document tree or some
other directory provided that configuration for Apache is made to know
about the directory.

> - Since egg deploy puts stuff in python2.4/site-package it doesn't
> seems as moving turbogears app via egg is fisable unless there is a
> tg/egg command that I can specify which will allow me either
> easy_install in /var/www/myfirstapp or to put my tg app in
> /var/www/myfirstapp folder.

Don't know much about egging TG applications so can't comment.

> - I also put myfirstapp.wsgi in /var/www/myfirstapp/myfirstapp.wsgi
> -Prod.cfg in /var/www/myfirstapp/prod.cfg

One would have to be careful about putting TG configuration there,
especially if it contains sensitive information such as database
passwords. The reason is that a misconfiguration of Apache could
result in the configuration file being downloadable by people thereby
exposing the sensitive information.

So, much better that the ONLY thing in the directory known to Apache
is the WSGI script file and possibly any static files.

> - The actual app is in /var/www/myfirstapp/myfirstapp/

Same issues as configuration file. You really want to not be placing
your main application Python code in the directory known to Apache.
The only exception is the WSGI script file which bridges to the
totally different location outside of the Apache document directories.

> - Static content is in /var/wwww/myfirstapp/myfirstapp/static

Reasonable.

> - Server.log is also in /var/www/myfirstapp/server.log (I am not sure
> if this will be needed since I will be able to use apache logs to
> monitor my app? Correct?) (If that is the case who knows how to
> disable tg logs?)

As with configuration files and main application Python code, don't
put logs in document tree as misconfiguration could result in it being
able to be downloaded, thus revealing sensitive information.

As to disabling logging, the config option:

turbogears.config.update({'global': {'server.log_to_screen': False}})

in WSGI script file should disable various TG logging so am not sure
where you log file comes into it. What is the option on configuration
where you are defining it? Maybe you shouldn't be defining that
configuration option to begin with.

> Apache config:
> ----
> Alias /static /var/www/myfirstapp/myfirstapp/static
> WSGIScriptAlias /myfirstapp /var/www/myfirstapp/myfistapp.wsgi
>
> <Directory /var/www/myfirstapp/myfirstapp >
> Order deny,allow
> Allow from all
> </Directory>
> ------
> Permissions for /var/www/myfirstapp would be apache user permissions (www-data)
>
> -Does this folder structure sounds resonable?

Still recommend that only thing in /var/www should be the WSGI script
file. Don't put configuration files, log files or main Python
application code/egg in that directory.

> -Now I run into problem where my app www.example.com/myfirstapp has a
> login link that points to www.example.com/login How do I tell tg or
> wsgi to use www.example.com/myfirstapp/login?

Possibly see:

http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears

it talks in there about mounting TG application on subURL of site.

Look for:

http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears

and the WSGI application wrapper to do SCRIPT_NAME fiddles.

> - What would be a apache/wsgi config for having http://myfirstapp.example.com?

That is shown in referenced document above.

> - What would be the difference in wsgi and/or tg configuration for
> myfirstapp.example.com vs example.com/myfirstapp?

That is shown in reference document above.

Graham

Lukasz Szybalski

unread,
Jan 24, 2008, 10:45:52 PM1/24/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
> > - I also put myfirstapp.wsgi in /var/www/myfirstapp/myfirstapp.wsgi
> > -Prod.cfg in /var/www/myfirstapp/prod.cfg
>
> One would have to be careful about putting TG configuration there,
> especially if it contains sensitive information such as database
> passwords. The reason is that a misconfiguration of Apache could
> result in the configuration file being downloadable by people thereby
> exposing the sensitive information.

I see your point. /var/www/ is indeed accessible from outside and
anything that is in it.
I will change it /usr/local/turbogears/myfirstapp/ then.

> > - Server.log is also in /var/www/myfirstapp/server.log (I am not sure
> > if this will be needed since I will be able to use apache logs to
> > monitor my app? Correct?) (If that is the case who knows how to
> > disable tg logs?)
>
> As with configuration files and main application Python code, don't
> put logs in document tree as misconfiguration could result in it being
> able to be downloaded, thus revealing sensitive information.
>
> As to disabling logging, the config option:
>
> turbogears.config.update({'global': {'server.log_to_screen': False}})

I have this set already.


> in WSGI script file should disable various TG logging so am not sure
> where you log file comes into it. What is the option on configuration
> where you are defining it? Maybe you shouldn't be defining that
> configuration option to begin with.

prod.cfg settings on server.log:

[[[access_out]]]
# set the filename as the first argument below
args="('/usr/local/turbogears/myfirstapp/server.log',)"
class='FileHandler'
level='INFO'
formatter='message_only'

[[loggers]]
[[[myfirstapp]]]
level='ERROR'
qualname='myfirstapp'
handlers=['error_out']

[[[access]]]
level='INFO'
qualname='turbogears.access'
handlers=['access_out']
propagate=0

Shouldn't the access_out be pointing to apache access.log? How would I
change it to do that?

Actually disabling it would be better I think or sending it to
/var/log/apache/warn.log assuming this would be handled by apache?


> > -Now I run into problem where my app www.example.com/myfirstapp has a
> > login link that points to www.example.com/login How do I tell tg or
> > wsgi to use www.example.com/myfirstapp/login?
>
> Possibly see:
>
> http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
>
> it talks in there about mounting TG application on subURL of site.

I have the settings set to:


turbogears.config.update({'global': {'server.webpath': '/myfirstapp'}})

The actual url works example.com/myfirstapp/login but I guess there is
a bug in html of master.kid in which there is a link href="/login"
instead of webpath+'/login'


> Look for:
>
> http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
>
> and the WSGI application wrapper to do SCRIPT_NAME fiddles.

I don't really get the SCRIPT NAME setting, what should I use it for?

I wasn't able to find how to setup myfirstapp.example.com to be an
access point for my app. Would that be an apache setting or wsgi?
Could you point me to the right documentation.

Other then that the tg seem to be working. I'll convert my real
applications over the weekend and will see how it goes.

As far as debuggin goes. If I set this to true:
turbogears.config.update({'global': {'server.log_to_screen': True}})
will errors if any show up on the actual page i'm accessing
example.com/myfirstapp ??


I updated my manual on mod_wsgi and turbogears:
http://lucasmanual.com/mywiki/TurboGears#head-36b7eef1526da4fe58c73738c925f34f6bc93c1d

Thanks,
Lucas

Graham Dumpleton

unread,
Jan 24, 2008, 11:02:36 PM1/24/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
On 25/01/2008, Lukasz Szybalski <szyb...@gmail.com> wrote:

Okay, you are using 'logging' module.

Most likely don't setup a FileHandler and instead allow it to log to
default of sys.stderr instead. This will automatically end up in
Apache error log.

> Actually disabling it would be better I think or sending it to
> /var/log/apache/warn.log assuming this would be handled by apache?

Okay, what I said above. :-)

> > > -Now I run into problem where my app www.example.com/myfirstapp has a
> > > login link that points to www.example.com/login How do I tell tg or
> > > wsgi to use www.example.com/myfirstapp/login?
> >
> > Possibly see:
> >
> > http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
> >
> > it talks in there about mounting TG application on subURL of site.
> I have the settings set to:
> turbogears.config.update({'global': {'server.webpath': '/myfirstapp'}})
>
> The actual url works example.com/myfirstapp/login but I guess there is
> a bug in html of master.kid in which there is a link href="/login"
> instead of webpath+'/login'

Or not using URL functions as described in:

http://docs.turbogears.org/1.0/GettingStarted/URLs

as referenced from that mod_wsgi document.

> > Look for:
> >
> > http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
> >
> > and the WSGI application wrapper to do SCRIPT_NAME fiddles.
> I don't really get the SCRIPT NAME setting, what should I use it for?

In WSGI SCRIPT_NAME is the mount point of the application. TG ignores
this and uses instead its server.webpath configuration option. For
this to work, seems though that WSGI SCRIPT_NAME has to be set to be
empty.

In other words, TG is not a WSGI compliant application and doing this
is to work around that fact.

> I wasn't able to find how to setup myfirstapp.example.com to be an
> access point for my app. Would that be an apache setting or wsgi?
> Could you point me to the right documentation.

In your VirtualHost for myfirstapp.example.com just use
WSGIScriptAlias with mount point as '/'. This is the first example in:

http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears

> Other then that the tg seem to be working. I'll convert my real
> applications over the weekend and will see how it goes.
>
> As far as debuggin goes. If I set this to true:
> turbogears.config.update({'global': {'server.log_to_screen': True}})
> will errors if any show up on the actual page i'm accessing
> example.com/myfirstapp ??

As far as I know, this just controls whether details of requests are
logged. Ie., equivalent to Apache access log. When it says
log_to_screen it actually means sys.stdout and nothing to do with
stuff being showed in a response page.

If you want tracebacks to appear in a error response page rather than
generic 500 error page, see error catching WSGI middleware in:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

Graham

Lukasz Szybalski

unread,
Jan 26, 2008, 3:04:33 PM1/26/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
I changed access_out to:

[[[access_out]]]
# set the filename as the first argument below

#args="(,)"
#class='FileHandler'
level='INFO'
formatter='message_only'


> > I wasn't able to find how to setup myfirstapp.example.com to be an
> > access point for my app. Would that be an apache setting or wsgi?
> > Could you point me to the right documentation.
>
> In your VirtualHost for myfirstapp.example.com just use
> WSGIScriptAlias with mount point as '/'. This is the first example in:
>

I'll have to play around with VirtualHost


> > Other then that the tg seem to be working. I'll convert my real
> > applications over the weekend and will see how it goes.
> >
> > As far as debuggin goes. If I set this to true:
> > turbogears.config.update({'global': {'server.log_to_screen': True}})
> > will errors if any show up on the actual page i'm accessing
> > example.com/myfirstapp ??
>
> As far as I know, this just controls whether details of requests are
> logged. Ie., equivalent to Apache access log. When it says
> log_to_screen it actually means sys.stdout and nothing to do with
> stuff being showed in a response page.
>
> If you want tracebacks to appear in a error response page rather than
> generic 500 error page, see error catching WSGI middleware in:
>
> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

Is there some kind of cache while running mod_wsgi?
I have updated my controller to not have /index anymore but I can
still access the website example.com/myfirstapp/index even after
restart of apache?

class Root(controllers.RootController):
@expose(template="myfirstapp.templates.myfirstapp")
# @identity.require(identity.in_group("admin"))
def myfirstapp(self):
import time
# log.debug("Happy TurboGears Controller Responding For Duty")
return dict(now=time.ctime())


Also,
One of my apps called ccc has a form page and submit form page but no index.

So if I access example.com/ccc/index I get 404 (good)
My form page is called ccc, and I should access it via
example.com/ccc/ccc but I still get 404. It seems as if the name of
the page is same as the name of the app then the page will default to
/ (example.com/myfirstapp/ ) Is that correct? Should it be that way?

example.com/ccc/saveccc works just fine.


Lucas

Graham Dumpleton

unread,
Jan 26, 2008, 11:45:54 PM1/26/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
> Is there some kind of cache while running mod_wsgi?
> I have updated my controller to not have /index anymore but I can
> still access the website example.com/myfirstapp/index even after
> restart of apache?

There is none which survives an Apache restart.

> class Root(controllers.RootController):
> @expose(template="myfirstapp.templates.myfirstapp")
> # @identity.require(identity.in_group("admin"))
> def myfirstapp(self):
> import time
> # log.debug("Happy TurboGears Controller Responding For Duty")
> return dict(now=time.ctime())
>
> Also,
> One of my apps called ccc has a form page and submit form page but no index.
>
> So if I access example.com/ccc/index I get 404 (good)
> My form page is called ccc, and I should access it via
> example.com/ccc/ccc but I still get 404. It seems as if the name of
> the page is same as the name of the app then the page will default to
> / (example.com/myfirstapp/ ) Is that correct? Should it be that way?
>
> example.com/ccc/saveccc works just fine.

I don't know how TurboGears itself is implemented and copes with
changes to code.

One thing to watch out for are old .pyc files laying around. If for
some reason these exist but where they contain compiled byte code for
older version of code file, it could be running it. So, start by
removing .pyc files in your application directories.

Graham

Lukasz Szybalski

unread,
Jan 28, 2008, 12:44:30 AM1/28/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
> I don't know how TurboGears itself is implemented and copes with
> changes to code.
>
> One thing to watch out for are old .pyc files laying around. If for
> some reason these exist but where they contain compiled byte code for
> older version of code file, it could be running it. So, start by
> removing .pyc files in your application directories.
>
I have removed pyc already.

Actually there is a weird property with paths.

First: if I set in apache:

WSGIScriptAlias /myfirstapp
/usr/local/turbogears/myfirstapp/apache/myfirstapp.wsgi

1. Instead of index I have myfirstapp page.
That apache config is all I need to access my
example.com/myfirstapp/myfirstapp
---domain-------apache-----myapp

(no need for webpath) myfistapp page is working properly.
a)example.com/myfirstapp/myfirstapp accesses my form (good)
example/com/myfirstapp/ gives me a 404 (good)
b)BUT now If click 'save' button it redirects me to
example.com/savemyfirstapp since it doesn't know about baser url!
(Shouldn't WSGIScriptAlias /myfirstapp step in here and redirect all
requests to /myfirstapp/xxxxx? Why yes or why not?)

Weird: I can also access:
example.com/myfirstapp/myfirstapp
example.com/myfirstapp/myfirstapp/myfirstapp
example.com/myfirstapp/myfirstapp/myfirstapp/myfirstapp


2. Since my save didn't work, this means that my turbogears app needs
to know the base url (server.webpath).
ok. I add this to my myfirstapp.wsgi config file:


turbogears.config.update({'global': {'server.webpath': '/myfirstapp'}})

weird:
now my first page doesn't work:
a)example.com/myfirstapp/myfirstapp (doesn't work)
b)but example.com/myfirstapp/myfirstapp/myfirstapp page works.???
-----domain-----------apache-----wsgi-------my-apps-page
c)my save works properly (good).

This means that webpath is needed internally to get all links working.
But what about my entry point. It seems as it the entry url now is
duplicated with apache and webpath.
example.com/myfirstapp/myfirstapp/myfirstapp
-----domain-------apache-----wsgi-------my-apps-page

This is a problem now because I cannot remove apache alias(because I
don't want / mounted app) I cannot remove my wsgi webpath(because my
links won't work) and I definitely can't remove my apps page(since
that is the main reason for the app).


So, what is going on here? Why apache WSGIScriptAlias+ webpath
represent (/myfirstapp/myfirstapp) and not (/myfirstapp)?
Aren't they talking about same path?

If I am setting something incorrectly please let me know what the
proper configuration should be?!

Lucas

Graham Dumpleton

unread,
Jan 28, 2008, 1:09:09 AM1/28/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
On 28/01/2008, Lukasz Szybalski <szyb...@gmail.com> wrote:
> > I don't know how TurboGears itself is implemented and copes with
> > changes to code.
> >
> > One thing to watch out for are old .pyc files laying around. If for
> > some reason these exist but where they contain compiled byte code for
> > older version of code file, it could be running it. So, start by
> > removing .pyc files in your application directories.
> >
> I have removed pyc already.
>
> Actually there is a weird property with paths.
>
> First: if I set in apache:
>
> WSGIScriptAlias /myfirstapp
> /usr/local/turbogears/myfirstapp/apache/myfirstapp.wsgi
>
> 1. Instead of index I have myfirstapp page.
> That apache config is all I need to access my
> example.com/myfirstapp/myfirstapp
> ---domain-------apache-----myapp
>
> (no need for webpath) myfistapp page is working properly.
> a)example.com/myfirstapp/myfirstapp accesses my form (good)
> example/com/myfirstapp/ gives me a 404 (good)
> b)BUT now If click 'save' button it redirects me to
> example.com/savemyfirstapp since it doesn't know about baser url!
> (Shouldn't WSGIScriptAlias /myfirstapp step in here and redirect all
> requests to /myfirstapp/xxxxx? Why yes or why not?)

The mod_wsgi package does the correct thing, if anything it is because
TurboGears isn't a WSGI compliant application. TG should if mounted at
a sub URL ensure it does trailing slash redirection for the top of the
TG application. Possibly you must use webpath configuration for that,
or my fiddle to try and get TG to behave properly when mounted at a
sub URL when running under WSGI isn't enough to make TG work properly.

That I can't comment on. Sounds like a problem with your TG URL
mapping configuration, or see below.

> 2. Since my save didn't work, this means that my turbogears app needs
> to know the base url (server.webpath).
> ok. I add this to my myfirstapp.wsgi config file:
> turbogears.config.update({'global': {'server.webpath': '/myfirstapp'}})
>
> weird:
> now my first page doesn't work:
> a)example.com/myfirstapp/myfirstapp (doesn't work)
> b)but example.com/myfirstapp/myfirstapp/myfirstapp page works.???
> -----domain-----------apache-----wsgi-------my-apps-page
> c)my save works properly (good).
>
> This means that webpath is needed internally to get all links working.
> But what about my entry point. It seems as it the entry url now is
> duplicated with apache and webpath.
> example.com/myfirstapp/myfirstapp/myfirstapp
> -----domain-------apache-----wsgi-------my-apps-page
>
> This is a problem now because I cannot remove apache alias(because I
> don't want / mounted app) I cannot remove my wsgi webpath(because my
> links won't work) and I definitely can't remove my apps page(since
> that is the main reason for the app).
>
>
> So, what is going on here? Why apache WSGIScriptAlias+ webpath
> represent (/myfirstapp/myfirstapp) and not (/myfirstapp)?
> Aren't they talking about same path?
>
> If I am setting something incorrectly please let me know what the
> proper configuration should be?!

People on TG list will need to help you out with this.

From what I can tell you have called a sub application of your site
the same name as the site. This to me would seem to be a very bad idea
because depending on how the Python module search path is defined all
sorts of weird things could happen.

This may actually be the cause of all your problems, so don't call
your sub application the same name as your site, call it something
different and start over again.

Graham

Lukasz Szybalski

unread,
Jan 29, 2008, 10:01:59 PM1/29/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears

After reading this I have tested it and it didn't make a difference,
but when I tested it today it DOES work. It had to be late the last
time or something.
Ok as long none of the functions/sub apps have the same name as my
webpath app name then we should be good.

Can I move /usr/lib/apache2/modules/mod_wsgi.so to my production
server? This file was compiled on Intel duo, and my server is amd
based? Both x86. If yes then there would be no need to install the
extra dev packages on the server as debian stable doesn't have the
package available yet (debian testing does apt-get install
libapache2-mod-wsgi)


Thanks for your help and for having this project.
As soon as all my apps go into production under mod_wsgi I will let you know.

Lucas

Graham Dumpleton

unread,
Jan 29, 2008, 10:07:44 PM1/29/08
to Lukasz Szybalski, mod...@googlegroups.com, TurboGears
On 30/01/2008, Lukasz Szybalski <szyb...@gmail.com> wrote:
> > From what I can tell you have called a sub application of your site
> > the same name as the site. This to me would seem to be a very bad idea
> > because depending on how the Python module search path is defined all
> > sorts of weird things could happen.
> >
> > This may actually be the cause of all your problems, so don't call
> > your sub application the same name as your site, call it something
> > different and start over again.
> >
>
> After reading this I have tested it and it didn't make a difference,
> but when I tested it today it DOES work. It had to be late the last
> time or something.
> Ok as long none of the functions/sub apps have the same name as my
> webpath app name then we should be good.
>
> Can I move /usr/lib/apache2/modules/mod_wsgi.so to my production
> server? This file was compiled on Intel duo, and my server is amd
> based? Both x86. If yes then there would be no need to install the
> extra dev packages on the server as debian stable doesn't have the
> package available yet (debian testing does apt-get install
> libapache2-mod-wsgi)

As long as they are same OS distribution, Apache major/minor version
(preferably close patch revision) and Python major/minor version. Also
would need to have been compiled as x86 and not x86_64 or amd64 as the
later two might see specific instructions for those CPU types being
used.

Graham

Lukasz Szybalski

unread,
Jan 31, 2008, 12:20:05 AM1/31/08
to Graham Dumpleton, mod...@googlegroups.com, TurboGears
> > Can I move /usr/lib/apache2/modules/mod_wsgi.so to my production
> > server? This file was compiled on Intel duo, and my server is amd
> > based? Both x86. If yes then there would be no need to install the
> > extra dev packages on the server as debian stable doesn't have the
> > package available yet (debian testing does apt-get install
> > libapache2-mod-wsgi)
>
> As long as they are same OS distribution, Apache major/minor version
> (preferably close patch revision) and Python major/minor version. Also
> would need to have been compiled as x86 and not x86_64 or amd64 as the
> later two might see specific instructions for those CPU types being
> used.
>
Instructions:
http://lucasmanual.com/mywiki/TurboGears#head-36b7eef1526da4fe58c73738c925f34f6bc93c1d

All went successful with deploying turbogears under mod_wsgi.
Automotive Recall Database: cars, trucks, all vehicles:
http://lucasmanual.com/recall
Vehicle Information Number. Check for authentic VIN
http://lucasmanual.com/vin

Thanks a lot,
Lucas

Reply all
Reply to author
Forward
0 new messages