On Mar 26, 11:18 am, Thierry <[email protected]> wrote:
> I tried with it, reverted back to another one...
> Just for the sake of testing it, I've tried it, and still no luck.
> My apache cfg is noe
> <VirtualHost *:80>
> ServerName aec.dev
> ServerAliaswww.aec.dev
> serverAlias tmain.ath.cx
> DocumentRoot /var/www/arc_en_ciel/htdocs/
> CustomLog /var/www/arc_en_ciel/log/access_log combined
> ErrorLog /var/www/arc_en_ciel/log/error_log
>
> RewriteEngine on
> RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
> RewriteRule .* - [F]
>
> include /etc/apache2/vhosts.d/expire
> include /etc/apache2/vhosts.d/defRoot
>
> #setEnv LOCATION dev
> #php_admin_value auto_prepend_file /var/www/arc_en_ciel/htdocs/libs/
> prepend/prepend.php
> #php_admin_value auto_append_file /var/www/arc_en_ciel/htdocs/libs/
> append/append.php
> #php_admin_value error_log /var/www/arc_en_ciel/log/php.log
> #php_admin_flag display_errors 1
> #php_admin_flag log_errors 1
>
> WSGIDaemonProcess tmain.ath.cx processes=2 threads=15 display-name=%
> {GROUP}
You have not supplied the 'user' and 'group' options to
WSGIDaemonProcess and with the exact same user and group that you are
running the webpy server as. That was the whole point of using daemon
mode in the first place. For further information on those options see:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
If when WSGI process runs as the exact same user, such that it has
exact same privileges, then we can discount directory/file
permissions.
Beyond that other problems may be:
1. When you run webpy server, webpy or sqlite is making use of user
environment variables you have set which aren't then available to the
application when run under Apache/mod_wsgi.
2. Your application has somewhere in its configuration or code a
dependence on the application being run in a specific directory. In
other words, it is using relative paths instead of absolute paths. One
way around that is to set the 'home' option to WSGIDaemonProcess to be
the same directory in which you were running the webpy server by hand.
Better still, eliminate dependencies on relative paths.
3. You are being affected by a clash between mod_cache in Apache and
sqlite which is causing sqlite to fail. This is a known issue due to a
class in symbol names. You need to disable mod_cache in Apache if
affected by this.
You should also set:
LogLevel info
for the VirtualHost. This way mod_wsgi will output more information in
Apache error logs, including information that can be used to confirm
that it is running in daemon mode.
Graham
> WSGIProcessGroup tmain.ath.cx
> WSGIScriptAlias / /var/www/arc_en_ciel/htdocs/base.py
> </VirtualHost>
>
> > > So, when you claim that permissions on directory where database is
> > > correct, what does that mean?
> > The directory and the sqlite db are chmoded to 664 and the owner of
> > both directory and db is apache:webdev
> > Which isn't what your 'ls' output below says. A directory would never
> > be 664 as it would block directory search.
>
> True, I've spotted it after sending the message, and had chmodded the
> whole path to 777, for testing.
> But still, it was the same.
>
> > Anyway, all academic now if you have gone back to PHP.
>
> Not at all. I have not totally ditched web.py, but I need to have
> something running in the next days, and I cannot waste more time on a
> configuration problem.
> I cannot replace apache with lighthttpd neither, as I have many sites
> running now on the future server, and I won't go in the hassle of
> updating them all just for that.
> I thought about running a second webserver on a different port, but
> not for now.
>
> The point is, that even with the bare session demo of web.py 0.3 and
> following the recommanded setup of apache+mod_wsgi, it don't work.
> I now have spent around 15 hours to try to have it working in apache,
> for around 5 hours of development.
> So, my quetion could be trivial, but does anyone have ever tried to
> use the sessions on an web.py 0.3 on apache with mod_wsgi with the
> recommanded settings?
>
> Maybe it's my apache configuration, maybe it's my wsgi directives,
> maybe it's my python install. I have absolutely no clues.
> I've reinstalled apache, tried worker and prefork mpm's.
> I've tried to install other session middleware, I've downgraded
> web.py. mod_wsgi and apache, and nothing have made it working.
> I've even tested the script on 3 servers, the same results on the 3.
>
> My impression is that the session object is only attached to the
> web.py object, not the wsgi object.
> If I try to attache it to the wsgi object, I've got an error telling
> me:
> AttributeError: 'function' object has no attribute 'add_processor'
> At this point, I stopped trying, and switched to PHP.
> But this saddens me...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web.py" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/webpy?hl=en
-~----------~----~----~----~------~----~------~--~---
