Re: Difficulty getting Django working with Apache and mod_python

[Graham Dumpleton]

On Oct 22, 2:23 am, projecktzero <[EMAIL PROTECTED]> wrote:
> On Oct 20, 4:17 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Mon, Oct 20, 2008 at 5:15 PM, projecktzero <[EMAIL PROTECTED]>wrote:
> > > I'm pretty new to Django. I'm having trouble getting my Django
> > > app/web-site to run under Apache2 and Mod_Python. I'm running Django
> > > 0.96. I installed Apache2 and Mod_Python and tested both, and they
> > > seem to work properly.
>
> > > In my http.conf, I have the following:
>
> > > 
> > >    Python Path "['/usr/local/apache2/htdocs/hwsw2','/usr/lib/
> > > python2.3/site-packages/django'] + sys.path"
> > >    SetHandler python-program
> > >    PythonHandler django.core.handlers.modpython
> > >    SetEnv DJANGO_SETTINGS_MODULE hwsw2.settings
> > >    PythonDebug On
> > > 
>
> > > The file permissions appear to be correct.(apache owns the .py files
> > > and they are executable, the .html templates are all ready-only for
> > > the world.)
>
> > > Unfortunately, I get the following error:
>
> > > EnvironmentError: Could not import settings 'hwsw2.settings' (Is it on
> > > sys.path? Does it have syntax errors?): No module named hwsw2.settings
>
> > > Does anyone have any ideas on what I did to mis-configure this?
>
> > First, you've got a space in the PythonPath setting in your Location
> > directive. Every example I've seen has no space there so I don't think a
> > space is allowed (though I did not actually verify that a space breaks
> > things).
>
> > Second you've specified 'hwsw2' in both the PythonPath and the SetEnv for
> > the settings module, so the file names that will be searched for are
> > /usr/local/apache2/htdocs/hwsw2/hwsw2/settings.py, etc.  If you are going to
> > specify the settings module as hwsw2.settings then
> > '/usr/local/apache2/htdocs', without the trailing hwsw2, needs to be on your
> > python path.  Whether you need both directories on the path depends on how
> > you import things in your code. If you always specify hwsw2 in your imports
> > than you don't need to have it be specified explicitly in the python path,
> > just its parent.
>
> > Third you don't need to specify anything under site-packages (site-packages
> > is automatically searched) in the PythonPath, so you should remove
> > '/usr/lib/python2.3/site-packages/django' from the PythonPath setting.
>
> > Karen
>
> Thanks Karen
>
> I had caught the PythonPath issue after sending the post. Here's what
> worked:
>
> 
>     PythonPath "['/usr/local/apache2/htdocs'] + sys.path"
>     SetHandler python-program
>     PythonHandler django.core.handlers.modpython
>     SetEnv DJANGO_SETTINGS_MODULE hwsw2.settings
>     PythonDebug On
> 

It is bad practice to put Django source code under Apache document
root (htdocs). If you do this and Apache gets misconfigured, you can
expose all your source code to the world, including any sensitive
information in it like database passwords.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Python on Windows re-using old .pyc files?

[Graham Dumpleton]

On Oct 21, 10:51 pm, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Ulf Kronman schrieb:> I'm using Django trunk and I have set the 
> MaxRequestsPerChild 1
> > directive in httpd.conf. I'm running on Windows XP (sp3?).
>
> Here a guess:
>
> Apache creates several threads (or worker processes) and after one
> request the thread/process gets killed. But the other are still alive and
> have the old code loaded.

On Windows there is only one Apache worker process containing many
threads. Thus, the problem of a request going to another process with
older code loaded shouldn't be an issue. Even on UNIX that shouldn't
be an issue with MaxRequestsPerChild set to 1 unless specific effort
was put into to preload Django code at process startup using
PythonImport directive.

I did have a think about OP issue, but off the top of my head I
couldn't work out why they would see the behaviour they were seeing
unless Apache is a bit loose with its counting, or it is an oddity of
how a restart of Apache worker process on Windows works.

> Maybe you could trymod_wsgi. It is much more flexible.

On Windows, unlikely that mod_wsgi would make a difference as it only
provides embedded mode on Windows and so behaviour not much different
to mod_python.

> See "Time to deprecate mod_python":
>
> http://groups.google.com/group/modwsgi/browse_thread/thread/95c5de2b9...

Hmmm, I can see the subject line of that post coming back to haunt
me. :-(

I wasn't saying mod_python itself should be deprecated, but that the
hacks in mod_wsgi to get it to work in same process as mod_python
should be dropped. This would've meant that they couldn't be used
together, but would free up mod_wsgi to manage better how Python is
used and eliminate some shortcomings it has with being forced to do
things the mod_python way to cooperate with it.

Graham

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django on Apache (mod_python) administration cookie problem

[Graham Dumpleton]

On Oct 22, 10:52 am, "M.Ganesh" <[EMAIL PROTECTED]> wrote:
> Hi Daniel,
>
> I am also facing the same problem. I really can't understand the
> technicalities of the solution offered in this thread. Since you seemed
> to have solved the problem, can you please give a little more details on
> how to do it

Disabling the PHP mhash module is only a workaround even if it does
work.

The proper fix if it is this issue is to refresh your Python 2.4
installation to get fixed version from Debian repository, or even
perhaps upgrade to Python 2.5 and newer mod_python version which uses
Python 2.5.

Alternatively, disable PHP from Apache completely if you do not need
it.

Which of the three options don't you understand and are wanting more
detail for?

Graham

> Thanks in advance
>
> Regards Ganesh
>
> Daniel bodom_lx Graziotin wrote:
> > Thank you very much for your replies, Alvaro and Graham!
> > Removing php5-mhash solved the problem
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Django 15 Second Refresh

[Graham Dumpleton]

On Oct 23, 3:01 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 22, 2008 at 11:31 AM, GPSGuy <[EMAIL PROTECTED]> wrote:
>
> > Option One: Reloading Wrapper
> > I now that there is caching going on, but I am still not sure why.  I
> > did find a work around, though I would still like for someone to
> > explain what is going on underneath.
>
> Apache does not automatically re-load all of your Python code into memory
> for each request.  Doing so would be an incredible performance hit for a
> production environment where the code generally does not change very often.
> So, once the code is loaded into a process it is re-used for as long as that
> process is used to service requests (dependent on Apache configuration
> parameters).  I am not sure why you are seeing a 15 seconds, exactly, since
> generally it's a number of requests per child process that controls this,
> but I am not an Apache configuration expert so there may be some other
> config option that your server is using to control this.
>
> The reason that you see the date/time change for each request but not a
> variable you have changed in the view is that the code for generating the
> date/time does not change, and it runs for each request, producing the
> current date/time.  Your code runs for each request, but not necessarily the
> most recent code on the disk.  Thus you have to wait for your code to be
> re-loaded in order to see the variable value change reflected in the
> generated response.
>
> There are ways to configure Apache so that you can trigger it to reload your
> code without a restart. For example, if you use mod_wsgi you can configure
> things so that all you need to do is touch your script file to cause all
> your code to be reloaded, see "Reloading Source Code" on this page:
>
> http://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions
>
> Or, you can force the reload yourself by doing the view wrapping with
> explicit reload as you have shown.  But really, it's much easier to just use
> the development server.  I don't really understand why you'd rather use this
> dedicated Apache that isn't really dedicated to you since restarting it
> affects others.

Also see:

http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_Daemon_Processes

The monitoring code in that section can quite happily be used to give
you a measure of automatic process reloading without the need for
touching the WSGI script file. It does this by monitoring changes to
Python code files associated with loaded Python modules. It can also
be told to monitor non Python code files as well if necessary.

The code there should only be used with mod_wsgi daemon mode and for
development, would recommend a single daemon mode process. If that
daemon mode uses a single thread, it wouldn't then be too much
different to using Django development server.

Graham


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Setting up Django on CentOS5 with flup and fastcgi

[Graham Dumpleton]

On Oct 23, 2:00 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> that would be great but i can't allow my users access to http.conf as
> i said i am a shared reseller so i am offering django to my clients.

Apache/mod_wsgi can be used in a similar vein to FASTCGI, with user
code running in separate processes as that user, and with the user
being able to dictate what applications run without them having to
modify the main httpd.conf file.

The only prerequisite to this is that you as admin would need to
preconfigure a WSGIDaemonProcess directive and appropriately delegate
the users applications for their site, to run in that daemon process
group. Once that preconfig is done however, users can add whatever
applications they want using .wsgi files.

The only thing that may be tricky is where users wants to run a Python
web application which isn't safe to run in a Python sub interpreter,
but has to be run in main Python interpreter, eg. Trac. To handle this
a way of allowing them to control which interpreter a specific
application runs in need to be setup. How this would be done depends
on how you have configured Apache and what AllowOverride permissions
you have set up for their .htaccess files.

So, it is possible.

Graham

> the only way i can do it is by writing a fcgi file and pointing to it
> with .htaccess but it seems as if it doesn't want to work.
>
> On Oct 21, 8:34 pm, Adam Nelson <[EMAIL PROTECTED]> wrote:
>
> > I've had great luck with wsgi.
>
> >http://code.djangoproject.com/wiki/django_apache_and_mod_wsgihttp://c...
>
> > This article relates how to reverse proxy that with Nginx if you're
> > interested (for speed, isolation):
>
> >http://vizualbod.com/articles/nginx-fastcgiwsgi-django-deployment
>
> > I haven't put any real load on this stuff yet but it sounds like wsgi
> > is a champ and it's certainly been great for me so far.
>
> > -Adam
>
> > On Oct 21, 1:55 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > > yes i have read that..
>
> > > it seems that the .fcgi file does not read correctly. it just returns
> > > the actual text in the fcgi file. and when i try and run a development
> > > server you just get a timeout.
>
> > > On Oct 21, 5:05 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
>
> > > > On Tue, Oct 21, 2008 at 11:50 AM, [EMAIL PROTECTED] <[EMAIL 
> > > > PROTECTED]>wrote:
>
> > > > > Hello,
>
> > > > > I am a webhosting provider that is trying to set up django on my
> > > > > server so that my clients can utilise it for their own programs.
>
> > > > > Although we do not allow ssh access our only ability to allow them
> > > > > access is to use fastcgi
>
> > > > > Although i am having trouble with doing so. Is there any tutorials
> > > > > that anyone knows of that will aid me to successfully setting up
> > > > > django to allow for shared hosting accounts to use it.
>
> > > > > I run on CentOS 5 and have python 2.4 with django 1.0 stable.
>
> > > > I assume you have read this page:
>
> > > >http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/
>
> > > > ?
>
> > > > Specifics of the trouble you are running into would help people provide
> > > > guidance, without specifics it's hard to say what might be going wrong.
>
> > > > Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Authenticating static files against Django Auth with FastCGI

[Graham Dumpleton]

Look at the Django source code for what the mod_python authentication
handler does and for the bit where it is interacting with Django user
database, do the same. The mod_wsgi documentation also gives an
example in the section dealing with authentication provider.

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

Obviously you need to wrap that in whatever mod_fastcgi requires on
the code side.

Graham

On Oct 23, 6:05 pm, MrJogo <[EMAIL PROTECTED]> wrote:
> I found a useful thread (http://groups.google.com/group/django-users/
> browse_thread/thread/affb11a7692a29ef/
> e1e2d569c1e9104d#016b2fe82fd80f36), so I think I can narrow my
> question down a little: How do I use FastCgiAuthenticator to
> authenticate against Django's auth module?
>
> On Oct 21, 12:40 am, MrJogo <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I am using Django on my university webspace. I set it up by following
> > (and slightly modifying) the instructions on this 
> > page:http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/#runnin...
>
> > Now I would like to protect certain static files by authenticating
> > against my Django user database; basically what's described 
> > here:http://docs.djangoproject.com/en/dev/howto/apache-auth/.
> > Unfortunately, I do not have access to the httpd.conf. I can
> > put .htaccess files into the directories, but that's about it. How can
> > I get the same functionality? Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django on Apache (mod_python) administration cookie problem

[Graham Dumpleton]

On Oct 25, 11:59 am, "M.Ganesh" <[EMAIL PROTECTED]> wrote:
> Graham,
> Option 3: I use other utilities like wordpress and phpMyAdmin, so I cannot 
> afford to disable php completely
> Option 2: I use Linux Mint (Ubuntu variant) for developement and Debian Etch 
> for production. So for option 2, I will require two sets of instructions, 
> which means more trouble for you. So let me skip that.
> Option 1: If this work around works for me, I'll get going and think of 
> better permanent solutions later
> Kindly help me on option one (disabling PHP mhash)

That one I can't help you with as know nothing about PHP. I presume
there is a configuration file for PHP somewhere you need to edit and
comment out load line for PHP mhash module.

Graham

> Thanks in advance
> Regards Ganesh
> Graham Dumpleton wrote:Disabling the PHP mhash module is only a workaround 
> even if it does work. The proper fix if it is this issue is to refresh your 
> Python 2.4 installation to get fixed version from Debian repository, or even 
> perhaps upgrade to Python 2.5 and newer mod_python version which uses Python 
> 2.5. Alternatively, disable PHP from Apache completely if you do not need it. 
> Which of the three options don't you understand and are wanting more detail 
> for? GrahamThanks in advance Regards Ganesh Daniel bodom_lx Graziotin 
> wrote:Thank you very much for your replies, Alvaro and Graham! Removing 
> php5-mhash solved the problem
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: why not django's default server?

[Graham Dumpleton]

On Oct 26, 12:32 pm, "Adam Fast" <[EMAIL PROTECTED]> wrote:
> It's worth mentioning as well that the Django "built-in" dev server is
> single-threaded the last time I heard, and with transferring large
> files / the application itself, I see a lot of your users getting
> "busy signals" so to speak from the server when they request pages. A
> few thousand pageviews a day is really too much to expect from it,
> especially when 30 or so people are all needing reports. As Alex
> mentioned, mod_wsgi requires only the .wsgi file to be touched in
> order to reload code. I think you're going to need Apache with several
> listeners to get an acceptable level of performance.

The touching of the WSGI script file to trigger a reload of the WSGI
application when using mod_wsgi only applies if the application has
been delegated to run in a mod_wsgi daemon mode process. Thus the
feature not available when running mod_wsgi on Windows since it has no
daemon mode, and it also wouldn't work on UNIX systems if the default
of running it in embedded mode applies.

Many people don't seem to understand that this reload feature only
works in daemon mode. Many times have seen on #django irc channel it
suggested to use mod_wsgi for this reason, yet people then can't get
it working because they don't realise daemon mode has to be used. This
is in part because many people who go to #django irc channel don't
bother reading documentation and just want quick answers. So please,
if you are going to suggest mod_wsgi for this reason, please qualify
it by saying that you do need to however be using mod_wsgi daemon mode
on UNIX systems to run the application.

Question now is what you think the problem may be by saying 'I think
you're going to need Apache with several listeners to get an
acceptable level of performance'. If using embedded mode, or even a
single mod_wsgi daemon mode process, the default configurations would
be more than adequate for the load the OP is talking about, as it
would even be for most of your average sites people would run.

Graham

> On Sat, Oct 25, 2008 at 12:27 AM, gniquil <[EMAIL PROTECTED]> wrote:
>
> > I am deploying something for my immediate group in my company, which
> > has about 30 or so people. My app (report) would be viewed at most a
> > few thousand times day (which would already be more than most of the
> > current php apps out there in my group). I would like to know if it's
> > ok to break all the rules such as running the default server and also
> > use it for media (which primarily consists of some ~500k large flash
> > files -- I am using Flex front end).
>
> > By the way, I really like this micro-app architecture about django,
> > unlike pylons. I am primarily using it for generating business reports/
> > dashboards (converting large excel files to simple web apps). And this
> > way of loading small apps really works well.
>
> > The reason I don't want to use apache is primarily due to 1. restarts
> > 2. lacking root access.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Handling Subdomain Requests

[Graham Dumpleton]

On Oct 27, 2:00 pm, killer barney <[EMAIL PROTECTED]> wrote:
> I'm not too familiar with how to handle subdomain requests on django.
> If i have test.example.com, is this somethign I'm supposed to find in
> the urls.py?? Or is this done in the middleware?
>
> I'm really confused about this, so you may have to give me step by
> step instructions =)

More often than not it is done at the web server level. For example,
see VirtualHost configuration in Apache:

  http://httpd.apache.org/docs/2.2/vhosts/

A single instance of the web application would then handle each
virtual host.

Technically, using mod_wsgi or mod_python, you could map multiple
virtual hosts into the same application instance, but individual
request handlers which need to act differently based on the server
name, with need to query which server the request arrived for out of
the request information.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Handling Subdomain Requests

[Graham Dumpleton]

On Oct 27, 6:43 pm, Aljosa Mohorovic <[EMAIL PROTECTED]>
wrote:
> On Oct 27, 5:52 am, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > A single instance of the web application would then handle each
> > virtual host.
>
> is this something that is possible/stable to use in mod_wsgi/django
> combination?

Yes.

> concrete example, i'm building a site with a single admin interface
> and several frontends (different design, same content, different
> context), will be hosted at webfaction (although if necessary can be
> slicehost or something else).
> depending on domain i thought i'll configure several mod_wsgi/django
> projects (apps in webfaction configuration) but i'm very interested in
> option to handle all request from single django project/webfaction
> app.
> obviously i want to use less memory since every frontend will have
> 100-500 hits per month so there is no real need to have ~10x50mb if i
> can use 50-70mb.
> can you provide any suggestions for this situation?
> thanks

The preferred approach would be to use mod_wsgi daemon mode and have a
separate daemon process for each virtual host. Since the sites are so
infrequently used, you would set inactivity-timeout option for daemon
process so when site is idle it will effectively shutdown until
required again, at which point it will be reloaded automatically.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django along with PHP - avoiding Apache crashes

[Graham Dumpleton]

On Oct 28, 4:01 am, Giles Thomas <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> We're implementing some new stuff for our website in Django;
> unfortunately our site currently uses PHP quite heavily (for MediaWiki,
> Wordpress, phpBB and the like), and when we tried deploying the first
> cut of the solution, Apache segfaulted - best guess is that this is a
> result of PHP's problems with a statically linked version of the mysql
> library, which are known to interact badly with mod_python and mysql [1]
>
> Unfortunately, although the problem is with PHP, I have to work around
> it in order to get my Django app working, at least until I can budget
> the time to remove PHP from the site entirely :-)
>
> I guess quite a lot of people out there have had similar problems, so I
> was wondering what the most popular workaround is?  Here are the options
> I've found or been told about so far:
>
>     * Use mod_wsgi so that all of the Django stuff is kept in a separate
>       process.  (A bit ugly.)

Separate processes are provided by daemon mode of mod_wsgi, embedded
mode works the same as mod_python. Either way, it will not help in
this case as PHP preloads everything in the Apache parent process and
thus it infects even the mod_wsgi daemon mode processes as they are
forked from Apache parent process just like Apache child worker
processes.

>     * Run a separate server (Apache, lighthttpd, or whatever) just for
>       Django.  (Even uglier.)

But if the option of recompiling code is not realistic, the easiest to
do.

>     * Recompile PHP with the appropriate flags to make it use a shared
>       mysql library.  (Scary!)

But the preferred option.

Do not though that it isn't an issue with a static MySQL client
library being used, but that the shared library it uses is a different
version, or different variant, ie., not thread safe or reentrant.

This specific issue is talked about in mod_wsgi documentation at:

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

You should perhaps run 'ldd' as shown in example there and work out
what versions/variants of shared libraries are being used by PHP,
Python and Apache as appropriate. Post the details here as then can
tell you better what you may be able to do about it.

BTW, another option which would work is to use Postgresql for Django
instead. Some would argue this is a better database anyway. ;-)

Graham

> Any thoughts would be much appreciated.
>
> Regards,
>
> Giles
>
> [1]http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#if-y...http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
>
> --
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> [EMAIL PROTECTED]
> +44 (0) 20 7253 6372
>
> Try out Resolver One! 
>
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: when deploying a real site django says i dont have access to python eggs cache

[Graham Dumpleton]

On Oct 28, 3:05 pm, geezer <[EMAIL PROTECTED]> wrote:
> hi,
>
> when deploying to a real site, django says i dont have writable access
> to a python eggs cache, when i redirect the python eggs cache, placing
> it into a new writable directory the browser crashes, exactly what are
> the steps to satisfying django requirements for the python eggs cache
> in this situation?

Depends on the hosting mechanism you use, something you don't say. So,
please provide more information about how you are running Django and
how you are configuring that specific hosting mechanism.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How to get site's root path in Django

[Graham Dumpleton]

On Oct 28, 2:24 am, "yuanyun.ken" <[EMAIL PROTECTED]> wrote:
> Hi, all great Django users and developers, I have a little problem.
> To make @login_required work,
> I have to configure those in settings.py:
> root_url = '/root_url/'
> LOGIN_URL = root_url + '/login/'
> LOGOUT_URL =  root_url + '/logout/'
>
> But this is obviously not a good idea, as it couples with project's
> root url.
>
> I tried to use:
> LOGIN_URL = '/login/'
> or
> LOGIN_URL = 'login/'
>
> the first can not work, apache would try to accesshttp://localhost/login/,
> nothttp://localhost/root_url/login/
> the second option would not work, when 
> accesshttp://localhost/root_url/dira/pageb,
> this would lead to accesshttp://localhost/root_url/dira/login
>
> urls.py
> (r'^login/$', 'django.contrib.auth.views.login'),
> (r'^logout/$', 'django.contrib.auth.views.logout')
>
> The following are my configuration in apache's httpd.conf
> Alias /root_url/ D:/ws/django/myproject/
> 
>     SetHandler python-program
>     PythonHandler django.core.handlers.modpython
>     SetEnv DJANGO_SETTINGS_MODULE Regrroot_url.settings
>     PythonOption django.root /root_url
>     PythonDebug On
>     PythonPath "['D:/ws/django/myproject/'] + sys.path"
> Options ExecCGI
> Options +Indexes
> Order allow,deny
> Allow from all
> 
>
> Any help is appreciated, and Thanks in advance.

When mounting at sub URL of a site, you shouldn't be adding the mount
point into anything in settings or in urls.py. For mod_python, the
only point you should need to added it is the PythonOption setting for
django.root. Thus, your settings for LOGIN_URL and LOGOUT_URL were
wrong when you were including root url in them.

Do note though that mounting at a sub URL possibly only works properly
if using Django 1.0, so make sure you aren't using an older version of
Django.

Graham

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django along with PHP - avoiding Apache crashes

[Graham Dumpleton]

On Oct 28, 11:58 pm, Giles Thomas <[EMAIL PROTECTED]>
wrote:
> Graham,
>
> Thank you again for the help - as you might have guessed, my separate
> question that you answered on themod_wsgilist was because I'd decided
> to try out the WSGI solution to the problem first.
>
> What's very strange is that although I did get the same crash when I
> first tried running up Apache + PHP  +mod_wsgias I had with mod_python
> - as you would expect - it now works fine!  I *think* that the change
> that fixed it was when I ran apt-get remove libapache2-mod-python - but
> I'm not quite sure why that worked.

If mod_python or mod_wsgi is compiled against Python static libraries,
then using them together can causes crashes. See:

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

Thus, one you uninstalled mod_python and did a full stop and start of
Apache, problem would go away.

> So I'm now in the uncomfortable position of having a server that works
> perfectly well, when I'm pretty sure that it should not.  One
> possibility: I'm using PHP5, and although the Django page [1] just says
> that there can be problems with PHP, the mod_python description of the
> bug [2] in one place refers to PHP4 - so perhaps the problem wasn't with
> PHP in the first place, but was instead some kind of mod_python version
> incompatibility.
>
> Anyway, for now I'll leave this alone and just keep an eye on it in case
> things start going wrong again.  In case it's of any interest, here's
> what I got when I checked the MySQL library versions in the current
> working setup:
>
> ---
> # ldd /usr/lib/python2.4/site-packages/_mysql.so | grep mysql
>         libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15
> (0x2b8df786)
> # ldd /usr/lib/apache2/modules/mod_*.so | grep mysql
> # ldd /usr/lib/php5/20060613/* | grep mysql
> /usr/lib/php5/20060613/mysqli.so:
>         libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15
> (0x2b8f8bd3f000)
> /usr/lib/php5/20060613/mysql.so:
>         libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15
> (0x2b28d2295000)
> /usr/lib/php5/20060613/pdo_mysql.so:
>         libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15
> (0x2ba328e47000)

There is still the risk of conflicts as Python module is using a
reentrant version of library and PHP isn't.

What this means is that if doing multithreaded stuff in Python, it
could crash in MySQL client library if PHP library taking precedence.
If data structures sizes are different for each library type, it could
crash without multithread use.

Graham

> Cheers,
>
> Giles
>
> [1]http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#if-y...
>
> [2]http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
>
> --
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> [EMAIL PROTECTED]
> +44 (0) 20 7253 6372
>
> Try out Resolver One! 
>
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How to setup django-apache-mod_wsgi without killing existing php site?

[Graham Dumpleton]

On Oct 31, 10:14 am, Håkan Waara <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> I'm in the process of for the first time deploying a django site that  
> (unfortunately) needs to share its Apache with an existing PHP site.
>
> I've been reading a bunch about mod_wsgi and in many places there are  
> mentions that setting up apache with mpm-worker (basically  
> multithreaded mode) will not work if you're also hosting a PHP site on  
> the same Apache; Apache will crash, and the world will collapse...
>
> What I haven't been able to find out is if it's possible/worth it to  
> use mod_wsgi (efficiently) in this situation at all, and if so how to  
> do it?
>
> Does anyone have other suggestions on how to avoid mod_python in this  
> situation? Should I have a look at nginx for example?
>
> Any hints appreciated!

It is not necessary to be running Apache worker MPM to run mod_wsgi,
it will work quite happily in Apache prefork MPM, just like mod_python
can. Also note that if you have problems with mod_wsgi, using
mod_python will not help as it can be impacted by exactly the same
problems.

Now, which MPM you use is not the problem you seem to think it is. The
real problem is generally going to be mismatches in what versions of
shared libraries that PHP uses compared to what various Python modules
require. The main culprit for this is MySQL as PHP generally uses a
non reentrant variant of MySQL client libraries where as Python MySQL
module generally uses a reentrant variant of the library. Result of
this can be Apache crashing.

Other problems can also arise if you are using Debian and the broken
Python 2.4 that Debian released. Specifically, Debian folks fiddled
with the hash module code in Python 2.4 and caused a conflict between
it and a hash module in PHP. This can cause problems with session IDs
being generated incorrectly and causing session mechanisms to fail, or
could also crash Apache.

These issues and others can be found described in:

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

Now, although mod_wsgi can be used with Apache prefork MPM and you can
run your Django application in embedded mode, because prefork means
more Apache child processes, you might not find it desirable that your
fat Django application then causes Apache as a whole to use up so much
memory. In this situation, don't run your Django in mod_wsgi embedded
mode, instead create a mod_wsgi daemon mode process groups and
delegate Django to run in that instead. Use one multithreaded daemon
mode process, or if your Django application isn't thread safe, a small
number of single threaded processes.

For some quick examples of embedded versus daemon mode configuration
see:

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

You should also go through other documentation on the mod_wsgi site
properly as well though. Don't assume that just reading one page, or
some ones blog on how they did it, or relying on answers to questions
you get from irc channels is going to be sufficient. This is why the
documentation exists.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple Copies of Libraries, Apache/mod_wsgi and Performance

[Graham Dumpleton]

On Oct 31, 10:04 am, "Naitik Shah" <[EMAIL PROTECTED]> wrote:
> I'm serving a few sites from a tiny VPS, and I'm quite happy with a
> Apache/mod_wsgi setup. I've managed to reduce the Apache footprint by having
> only a few necessary modules loaded. mod_wsgi is setup to use daemon mode
> and start multiple processes per site.

How many processes in each daemon group and how many threads? A lot of
sites would work quite happily with single daemon process with a dozen
or so threads, which is what WSGIDaemonProcess gives you as default
when you do not define number of processes and threads. Thus, don't
get carried away and create more processes than you really need to.

Can you post the Apache configuration showing relationship between
sites and daemon process groups? Can then possibly comment better.

Also indicate how much traffic each site gets and whether any would
potentially be idle for periods, as can then look at inactivity
timeouts etc.

> Currently, each site has its own python-path and the system python
> installation does not contain anything but stock python modules. Each site
> has its own copy of Django and various other libraries. Is there a
> performance gain to be had by having the sites share these libraries? They
> are different processes, so I think not, but I'm not quite sure. Also,
> another benefit that I can think of is that if the files were the same, the
> OS (Linux 2.6.27) would be able to cache them better, but again I'm not
> quite sure.

The code size is generally not the issue, but runtime application
data, so doubt that having .so in different installations would result
in much being lost.

> This is probably a micro enhancement, but I'm trying hard to keep the memory
> consumption low.
>
> -Naitik
>
> ps: Another enhancement I'm looking into when I have time is the event mpm,
> but that one requires me to give up my distro apache. Thoughts?

Rather than event MPM, would suggest using nginx as a front end, with
nginx serving requests for static files and then proxying other
requests through to Apache/mod_wsgi. This is because nginx is arguably
better at serving static files and maintaining many open connections
with keep alive. The Apache/mod_wsgi instance would then only be
handling dynamic requests and all connections would come from local
nginx. Even if keep alive working there, depending on how optimised
nginx is, it can possibly reuse the connections over time for requests
from different originating clients in a more efficient way, thereby
keeping the memory overhead in Apache which generally arises from
maintaining open connections from lots of different clients.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: appeal for help with #9232

[Graham Dumpleton]

The OP, if they don't need mod_python should also disable it and not
load it into Apache at the same time as mod_wsgi. The mod_python
versions is quite old and buggy and mod_python can interfere with
mod_wsgi especially causing certain configuration options for mod_wsgi
to not work. The mod_wsgi version is also not the latest, should try
with mod_wsgi 2.3. No known issues with uploading with mod_wsgi 2.0,
but still better to use the latest.

Just because binary distributions still only provide old versions
doesn't mean they are the best to use and bug free.

Graham

On Oct 31, 10:56 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 30, 2008 at 11:12 AM, Faheem Mitha <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > Can anyone help with
>
> >http://code.djangoproject.com/ticket/9232
>
> > ? Currently I don't even know if this problem is reproducible. If someone
> > could solve it, or even indicate what was wrong, if anything, I'd be happy
> > to pay for services rendered.
>
> It's not a generally re-creatable problem. Using your project on one of my
> machines (Ubuntu) with Django 1.0, Apache 2.2 & mod_wsgi 2.3 an upload of a
> 700M file takes about a minute and a half (during which time I can see the
> tmp upload file continually growing in size), then gets an error on the
> redirect at the end of the view since "top_folders" is not reversable in the
> testproj config.
>
> Random question that cross my mind:
>
> Are you sure you have a clean install of Django 1.0 -- that is you removed
> any old level before installing 1.0?
>
> Are you trying the upload from a machine with a known good network
> connection to the server (or from the sever machine itself?).
>
> Do you see the same behavior if you run under the development server?
>
> Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple Copies of Libraries, Apache/mod_wsgi and Performance

[Graham Dumpleton]

On Oct 31, 4:09 pm, "Naitik Shah" <[EMAIL PROTECTED]> wrote:
> > Also indicate how much traffic each site gets and whether any would
> > potentially be idle for periods, as can then look at inactivity
> > timeouts etc.
>
> As embarrassing as it sounds, I don't have good numbers available yet. There
> are definite idle periods on certain virtual hosts.

If there are definite idle periods of reasonable size, perhaps look at
'inactivity-timeout' option to WSGIDaemonProcess. This way daemon
process will be restarted when doing nothing, and providing that
preloading not configured using WSGIImportScript, then process size
will be quite small until next needed, at which point it will load
application again.

To counter risk of daemon process growing in size because of memory
creep in application you don't know about, also look at 'maximum-
requests' option to WSGIDaemonProcess.

> > Rather than event MPM, would suggest using nginx as a front end, with
> > nginx serving requests for static files and then proxying other
> > requests through to Apache/mod_wsgi. This is because nginx is arguably
> > better at serving static files and maintaining many open connections
> > with keep alive. The Apache/mod_wsgi instance would then only be
> > handling dynamic requests and all connections would come from local
> > nginx. Even if keep alive working there, depending on how optimised
> > nginx is, it can possibly reuse the connections over time for requests
> > from different originating clients in a more efficient way, thereby
> > keeping the memory overhead in Apache which generally arises from
> > maintaining open connections from lots of different clients.
>
> I considered nginx, but I've been playing with S3 and I think I'm going to
> use that as a poor mans edge system for my static content. But I'll keep
> this in mind. Would using a event mpm help if I didnt have to serve static
> content or need Keep-Alive?

If Apache/mod_wsgi only handling dynamic content, wouldn't see that
event MPM would make any difference. If only handling dynamic content,
turning off keep alive on Apache may help though as unlikely one will
get concurrent requests over same socket for dynamic web page, and so
can give up client connection straight away and not tie up Apache
processes/threads for period that timeout takes to trigger for keep
alive.

In respect of having nginx in front, one of the over benefits of that
was that nginx could have been quite selective about the URLs that it
was proxying. That way if you get a SPAM bot or similar hitting the
site, it could have been blocked at nginx without even going through
to Apache/mod_wsgi, presuming that such a bot was hitting known URLs
for security holes in PHP packages or the like. One may also have been
able to filter SPAM bot traffic at nginx level through user agent or
other things. Thus, nginx could have further been used as a filter
point to limit traffic going through to Apache.

> WSGIPythonOptimize 1

Surprised if this will make much difference. Worth a try but don't
expect it to do much. For a start, as it is a long running process,
any benefit at process start when loading smaller .pyo files is only
for that time and not later when handling actual requests.

> 
>     StartServers          30
>     MinSpareServers       30
>     MaxClients            30
> 

If not using PHP on same Apache, better to use Apache worker MPM as
then cut down on number of Apache child process and still just as
capable at handling load of static files and proxying to mod_wsgi
daemon processes.

>     Alias /media/ /data/daaku/media/
>     
>         SetHandler None

The 'SetHandler None' should not be needed here. This was a mod_python
requirement but mod_wsgi shouldn't need it.

Graham

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: HttpRequest with chunked encoding is not buffered

[Graham Dumpleton]

[EMAIL PROTECTED] wrote:
> Hello,
> I'm trying to receive a possibly large XML message via HttpRequest
> (POST method) with chunked encoding. However, when I send a response,
> I found out (using Wireshark) that the response is being sent before
> the whole POST request body is available. I expected Django to be
> buffering the chunks and that the request would be complete, but
> that's apparently not happening...
>
> I'm reading the body like this:
> request.POST.values()[0]
>
> (Which is probably a wrong way, but I don't know how to do it
> otherwise.)

What hosting mechanism are you using. Anything that uses WSGI (eg,
mod_wsgi, fastcgi/flup) or mod_python will not work as neither WSGI
specification or mod_python support chunked transfer encoding on
request content. Certainly for mod_python and mod_wsgi, it should give
an error back before even gets to Django saying that content length
required to be set.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple Copies of Libraries, Apache/mod_wsgi and Performance

[Graham Dumpleton]

On Nov 1, 8:44 am, "Naitik Shah" <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 31, 2008 at 1:01 PM, Naitik Shah <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 30, 2008 at 10:58 PM, Graham Dumpleton <
> > [EMAIL PROTECTED]> wrote:
>
> >> In respect of having nginx in front, one of the over benefits of that
> >> was that nginx could have been quite selective about the URLs that it
> >> was proxying. That way if you get a SPAM bot or similar hitting the
> >> site, it could have been blocked at nginx without even going through
> >> to Apache/mod_wsgi, presuming that such a bot was hitting known URLs
> >> for security holes in PHP packages or the like. One may also have been
> >> able to filter SPAM bot traffic at nginx level through user agent or
> >> other things. Thus, nginx could have further been used as a filter
> >> point to limit traffic going through to Apache.
>
> > That's interesting. I wonder if Apache could be made to reject such
> > requests. I like the current simple setup - I want to avoid adding Nginx to
> > the mix :)
>
> I looked into this approach a bit, and it seems there's more benefits - the
> one that stood out is that slow clients will first be handled by Nginx, and
> the request will only be handed off to Apache after Nginx is done receiving
> it. Thus, holding the Apache process for less amount of time. I'll look into
> this in more detail once I have the Apache setup working as I like.

Yes, in theory that as well.

This is where one would have thought the Apache event MPM might help,
but from what I remember at look at code, the special event worker
thread only deals with accepting the new connection (before handing it
off to another thread) and later perhaps (can't remember) dealing with
management of keep alive connections.

In other words, don't believe the Apache event MPM uses the event
worker thread to at least read in the HTTP request header before
handing it off to another thread for processing. Thus, request has
already been handed off to its own thread for that part of the request
which may arrive slow, ie., the HTTP request information. I will need
to check again though if what I remember is correct. :-)

This is where nginx is better, as the event model can handle all that
HTTP request header reading in single thread by multiplexing it based
on availability of data. Therefore you don't suffer the Apache
overhead of memory usage for threads sitting there waiting for slow
data to come for HTTP request header.

Anyway, before you quote me on how Apache event MPM works, I better go
check.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple Copies of Libraries, Apache/mod_wsgi and Performance

[Graham Dumpleton]

On Nov 1, 10:06 am, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> On Nov 1, 8:44 am, "Naitik Shah" <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Fri, Oct 31, 2008 at 1:01 PM, Naitik Shah <[EMAIL PROTECTED]> wrote:
> > > On Thu, Oct 30, 2008 at 10:58 PM, Graham Dumpleton <
> > > [EMAIL PROTECTED]> wrote:
>
> > >> In respect of having nginx in front, one of the over benefits of that
> > >> was that nginx could have been quite selective about the URLs that it
> > >> was proxying. That way if you get a SPAM bot or similar hitting the
> > >> site, it could have been blocked at nginx without even going through
> > >> to Apache/mod_wsgi, presuming that such a bot was hitting known URLs
> > >> for security holes in PHP packages or the like. One may also have been
> > >> able to filter SPAM bot traffic at nginx level through user agent or
> > >> other things. Thus, nginx could have further been used as a filter
> > >> point to limit traffic going through to Apache.
>
> > > That's interesting. I wonder if Apache could be made to reject such
> > > requests. I like the current simple setup - I want to avoid adding Nginx 
> > > to
> > > the mix :)
>
> > I looked into this approach a bit, and it seems there's more benefits - the
> > one that stood out is that slow clients will first be handled by Nginx, and
> > the request will only be handed off to Apache after Nginx is done receiving
> > it. Thus, holding the Apache process for less amount of time. I'll look into
> > this in more detail once I have the Apache setup working as I like.
>
> Yes, in theory that as well.
>
> This is where one would have thought the Apache event MPM might help,
> but from what I remember at look at code, the special event worker
> thread only deals with accepting the new connection (before handing it
> off to another thread) and later perhaps (can't remember) dealing with
> management of keep alive connections.
>
> In other words, don't believe the Apache event MPM uses the event
> worker thread to at least read in the HTTP request header before
> handing it off to another thread for processing. Thus, request has
> already been handed off to its own thread for that part of the request
> which may arrive slow, ie., the HTTP request information. I will need
> to check again though if what I remember is correct. :-)
>
> This is where nginx is better, as the event model can handle all that
> HTTP request header reading in single thread by multiplexing it based
> on availability of data. Therefore you don't suffer the Apache
> overhead of memory usage for threads sitting there waiting for slow
> data to come for HTTP request header.
>
> Anyway, before you quote me on how Apache event MPM works, I better go
> check.

I think me memory is okay. Comments in event MPM code say:

 * This MPM tries to fix the 'keep alive problem' in HTTP.
 *
 * After a client completes the first request, the client can keep the
 * connection open to send more requests with the same socket.  This
can save
 * signifigant overhead in creating TCP connections.  However, the
major
 * disadvantage is that Apache traditionally keeps an entire child
 * process/thread waiting for data from the client.  To solve this
problem,
 * this MPM has a dedicated thread for handling both the Listenting
sockets,
 * and all sockets that are in a Keep Alive status.

and looking at code it does indeed seem to send accept socket direct
into worker thread queue for processing before any data actually read.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Response is sent before post body arrives

[Graham Dumpleton]

On Nov 1, 8:22 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm using chunked transfer encoding and i send a post http request to
> my Django application. But when I try to read the post body, it's not
> there (request.POST.keys() returns []). according to Wireshark, I send
> the response and right after that comes the request body.
> Do you know how to wait till the body arrives?
> And why does Django not wait for it automatically?

Hmmm, seems you basically asked the same question twice. See:

 http://groups.google.com/group/django-users/browse_frm/thread/dda2008ccbc8cd65

If you are getting empty input on read, then you are using hosting
mechanism that doesn't properly filter out chunked request content as
not being supported and instead assumes that content length of request
was 0.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Is there a way to host serveral django projects under a single virtual host

[Graham Dumpleton]

On Nov 1, 4:54 am, Håkan Waara <[EMAIL PROTECTED]> wrote:
> 31 okt 2008 kl. 16.43 skrev ilyail3:
>
>
>
>
>
> > hello people, Is there a way to host several django projects under a
> > single virtual host?
> > I know this is possible with mod_php with wildcards as server alias
>
> > and later map urls to dirs using mod_rewrite
>
> > 
> >    DocumentRoot /var/www
> >    ServerNamewww.projects
> >    ServerAlias *.projects
> >    RewriteEngine on
> >    RewriteCond %{HTTP_HOST} !^www.* [NC]
> >    RewriteCond %{HTTP_HOST} ^([^\.]+)\.projects
> >    RewriteCond /var/www/%1 -d
> >    RewriteRule ^(.*) /%1/$1 [L]
> > 
>
> > But is it possible to run django projects from a directory in a
> > similar way.
>
> > Sorry if I'm asking a question someone have asked before , couldn't
> > find anything on this topic
>
> Are you using mod_wsgi, mod_python or what?
>
> If you're using mod_wsgi: From what I gather, running multiple django  
> projects under the same VirtualHost currently has things to deal with  
> to get it working. 
> (Seehttp://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
>   -- search for "Note that Django expects").

Yes, mod_wsgi will by default run different WSGI applications within a
VirtualHost in different sub interpreters of same process. It has the
added benefit though that you could also delegate each application in
same virtual host to different daemon process groups. That or even mix
and match them, having some delegated out to separate process at the
same time as keeping some running in the Apache child processes.

In mod_python, the default is to run all applications within a
VirtualHost (regardless of listener port), in the same sub
interpreter. For Django, because DJANGO_SETTINGS_MODULE global, this
will not work. For mod_python you need to use PythonInterpreter
directive and manually designate that applications should run in
different sub interpreters.

Thus, mod_wsgi is far more flexible than mod_python in this respect.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: HttpRequest with chunked encoding is not buffered

[Graham Dumpleton]

On Nov 1, 10:40 am, "Tomáš Brambora" <[EMAIL PROTECTED]> wrote:
> I have a standard Django installation without any changes in the
> settings (except adding mysql db to the settings.py) and I'm sending
> the message to localhost:8000, so there is no proxy or anything else
> in the way. Still, the request body comes after me sending the
> response...

As I said in the other similar thread you created about this.

If you are getting empty input on read, then you are using hosting
mechanism that doesn't properly filter out chunked request content as
not being supported and instead assumes that content length of
request  was 0.

In other words, chunked request content is not supported. Most hosting
mechanisms will flag it as an error. The internal Django development
server appears just to assume that content length on request is 0
since Content-Length header wouldn't be set. Thus why you are seeing
no input.

Graham

> On Fri, Oct 31, 2008 at 11:50 PM, Graham Dumpleton
>
> <[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] wrote:
> >> Hello,
> >> I'm trying to receive a possibly large XML message via HttpRequest
> >> (POST method) with chunked encoding. However, when I send a response,
> >> I found out (using Wireshark) that the response is being sent before
> >> the whole POST request body is available. I expected Django to be
> >> buffering the chunks and that the request would be complete, but
> >> that's apparently not happening...
>
> >> I'm reading the body like this:
> >> request.POST.values()[0]
>
> >> (Which is probably a wrong way, but I don't know how to do it
> >> otherwise.)
>
> > What hosting mechanism are you using. Anything that uses WSGI (eg,
> > mod_wsgi, fastcgi/flup) or mod_python will not work as neither WSGI
> > specification or mod_python support chunked transfer encoding on
> > request content. Certainly for mod_python and mod_wsgi, it should give
> > an error back before even gets to Django saying that content length
> > required to be set.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Deploying multiple django applications in a single apache server

[Graham Dumpleton]

Just be aware that by default mod_python assigns sub interpreters per
name based virtual host and doesn't take into consideration the
listener port. Therefore, if having two listener ports on the same
host name, the same sub interpreter will be used for both, which means
that Django instances will not be separated and will not work
properly.

In mod_python you will need to use PythonInterpreter directive to
override name of sub interpreter in each VirtualHost for which only
difference is listener port.

Better still, use mod_wsgi instead as it is more sensible and by
default separates the applications by default as it delegates to sub
interpreters on the basis of combination of server name and port. The
only except being that 80/443 are merged into same sub interpreter as
they would generally be the same application.

Graham

On Nov 2, 1:00 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 1, 2008 at 9:03 AM, bluefireredsky <[EMAIL PROTECTED]>wrote:
>
>
>
>
>
> > Hello,
>
> > I have followed the link from django documentation on deploying an
> > application to apache2.
>
> >http://docs.djangoproject.com/en/dev/howto/deployment/modpython/
>
> > I have two applications, which I would like to run on two different
> > ports on the server. Basically one being an administrative website
> > (not the django inbuilt admin website) and the other the user front
> > end.
>
> > Currently I have the following on my ports.conf:
>
> > ===
> > Listen 80
>
> > 
> >    Listen 443
> > 
> > ===
>
> > My httpd.conf is as follows:
>
> > 
> > 
> >    SetHandler python-program
> >    PythonHandler django.core.handlers.modpython
> >    SetEnv DJANGO_SETTINGS_MODULE mysitename.settings
> >    PythonOption django.root /mysitename
> >    PythonDebug On
> >    PythonPath "['/usr/local/'] + sys.path"
> > 
> > 
> >    SetHandler None
> > 
> > 
> >    SetHandler None
> > 
> > 
>
> > What changes should I do on these files to run my second django
> > application on a different port, say 8080, on the same apache server?
>
> This is really more an Apache question than a Django one.  First you'll need
> to add a Listen for the second port in your ports.conf, the doc for that is
> here:
>
> http://httpd.apache.org/docs/2.2/bind.html
>
> At the bottom of that page they point to the VirtualHost directive, which is
> the second thing you'll need to do.  You need to enclose your existing
> directives for the app on port 80 in a VirtualHost block for port 80, and
> create a second VirtualHost with directives for the new app that you want on
> the second port.
>
> Karen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: touching wsgi file

[Graham Dumpleton]

On Nov 3, 7:09 am, belred <[EMAIL PROTECTED]> wrote:
> is touchingt the wsgi file supposed reload every file in the the
> entire django project or just just reload the one wsgi file?

If you are talking about the WSGI script file when using Apache/
mod_wsgi, it depends on how you have Apache/mod_wsgi configured. See:

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

In other words, for whole Django instance to be reloaded you must be
using UNIX and have configured mod_wsgi daemon mode and delegated the
Django instance to run in the daemon mode process group.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: sharing a module level variable

[Graham Dumpleton]

On Nov 3, 2:03 am, belred <[EMAIL PROTECTED]> wrote:
> On Nov 2, 3:29 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>
>
> > belred wrote:
> > > i have an wget event in a cron job.  the view does some processing
> > > which involves calling external websites and databases (takes about 25
> > > seconds) and updates some module level dictionary lookup variables
> > > (about 7 MB of data) which the rest of the program reads.  but
> > > unfortunately, only the one apache child process seems to be updated,
> > > not all the others.  how can i share this module level variable across
> > > processes?  this lookup happens multiple times per  request.  but the
> > > internal data gets updated nightly.
>
> > Aah, so this is the real question! I don't believe Django signals are
> > intended to serve needs like this. How does "the rest of the program"
> > read the module-level dictionary items? The more explicit you are about
> > the exact communication mechanism involved the more likely it is someone
> > (probably not me) will be able to help.
>
> > regards
> >  Steve
>
> thanks steve,
>
> you comments about signals were very clear and should be in the
> documentation.
>
> when i receive the nightly wget request to update the data, it's
> stored in module level dicts which other parts of the program use by
> simply importing the data module.
>
> import data
>
> def view_func(request):
>    foo = data.lookup['foo']
>    ...
>
> def view_update_data(request):
>     data.lookup = retrieve_new_data()
>     ...
>
> this works correctly for the child process that receives the update,
> but the other child process don't seem to be getting the updates.
>
> i thought after i did an update i could os.uptime() thewsgifile
> which would cause all of my django project to restart, but it doesn't
> seem to be updating my data either.

If the module level data you are talking about are just transient
global variables in the module, then other processes can't see them
(or other sub interpreters in same process). For a start read:

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

Written for mod_wsgi, but equally applicable to mod_python for
embedded mode description at least. Take note of very last section
where it summarises data sharing issues.

If it is module level data, only solution would be to use mod_wsgi
daemon mode and delegate Django instance to run in single process.

In respect of triggering a restart, if the data is indeed transient,
ie., in memory only, how does it get read on startup if you are
relying on cron job to trigger its initialisation?

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: touching wsgi file

[Graham Dumpleton]

On Nov 3, 9:55 am, belred <[EMAIL PROTECTED]> wrote:
> i am using linux and i am using mod_wsgi to run django.
>
> i don't understand this sentence.
>
> "This should only be done for daemon processes and not within the
> Apache child processes"...
>
> we have many apache child process.  if i follow this code:
>
> if environ['mod_wsgi.process_group'] != '':
>     import signal, os
>     os.kill(os.getpid(), signal.SIGINT)
>
> will it restart django in the one child process the code executes in
> or all child processes for the given django project?  (i'm trying to
> find a way to restart the entire django project regardless of how many
> child processes are running). also doesn't the mod_wsgi daemon process
> exist within an apache child process?  if so, that above sentence
> doesn't make sense to me.  there must be something i'm missing or
> don't understand because i don't see documentation or people asking
> questions about properly running django on high volume sites under
> apache child processes in linux.  maybe this is not the recommended
> way it's done.

Are you using mod_wsgi daemon mode or not? If you don't know, then
post how you have configured Apache for mapping to WSGI application
running under mod_wsgi.

The term 'Apache child processes' here is referring to the normal
Apache child worker process which handles all types of requests,
including static files, PHP etc etc. It doesn't say 'worker' because
then people get it confused with 'worker' MPM, thinking it perhaps
only applies to 'worker' MPM and not 'prefork' MPM as well.

When using mod_wsgi daemon mode, with requests being correctly
delegated to the daemon process for a specific application, then there
are distinct processes referred to as mod_wsgi daemon mode processes.
Technically these are also a forked child of Apache parent process,
but they only run WSGI requests proxied to it by the normal Apache
child worker processes, they DO NOT do handling of static requests,
PHP etc etc.

The reason you don't want to use the kill() code in normal Apache
child worker processes is two fold.

First is that the normal Apache child worker processes handle requests
for static files, PHP etc etc. Thus, sending a kill signal to itself
could interfere with the operation of other code for another distinct
application executing in the same process. Also, the Apache MPM being
used may interpret signals to mean different things than how a
mod_wsgi daemon mode process does and so you could break the process
is some way rather than shut it down.

The second reason is that on UNIX, Apache is generally multiprocess
and so you would only be shutting down the one process and not all
Apache child worker processes.

Even when doing this in mod_wsgi daemon mode, the daemon process group
should only have one process. This is why the documentation says:

"""To force a daemon process to be restarted, if you are using a
single daemon process with many threads for the application, then you
can embed a page in your application (password protected hopefully),
that sends an appropriate signal to itself."""

In particular, it says 'if you are using a single daemon process'. If
not using a single daemon process, you shouldn't use this technique.

If using daemon mode and have multiple processes in the daemon process
group, touching the WSGI script file will have the effect of causing
daemon mode processes for that application to be restarted the next
time a request arrives for it.

Normally one would manually touch the WSGI script file from outside of
Apache or application, by using 'touch' on the command line. One could
automate it and do it from application if you really want to:

  if environ['mod_wsgi.process_group'] != '':
import os
os.utime(environ["SCRIPT_FILENAME", None)

The 'environ' variable here is the WSGI environment dictionary. The
'SCRIPT_FILENAME' attribute is an Apache specific variable which
indicates the target resource, which in this case just happens to be
the WSGI script file.

If you want code to be portable beyond mod_wsgi, this would need to be
written differently. I'll elaborate on that more later if need to.

The user that mod_wsgi daemon mode process runs as should have
permissions to allow it to update the modification time of the WSGI
script file.

Graham

> On Nov 2, 2:17 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 3, 7:09 am, belred <[EMAIL PROTECTED]> wrote:
>
> > > is touchingt the wsgi file supposed reload every file in the the
> > > entire django project or just just reload the one wsgi file?
>
> > If you are talking about the WSGI s

Re: touching wsgi file

[Graham Dumpleton]

On Nov 3, 12:31 pm, belred <[EMAIL PROTECTED]> wrote:
> thanks for your detailed explanation.  i had to read it 3 times to try
> to absorb everything :) i do not need to have the code be portable
> beyond mod_wsgi.  if i'm following what you and steve have said and
> pages you both pointed me to, it appears if i want to share global
> data i really need to use daemon mode with single process and multiple
> threads.   to restart django under mod_wsgi using daemon mode, i just
> need to touch the wsgi file.  actually, i currently have code that
> uses os.utime, but i didn't know about the SCRIPT_FILE environment
> variable, so that's a really good tip.  i was using a hard-coded path
> in settings.py.  i don't think it worked for me because i don't think
> i'm in daemon mode.  i don't have the script in front of me at this
> time, so i can't share it with you now. i'm a little unclear if you
> said that touching the wsgi file works only in wsgi daemon/multi-
> process  mode or in wsgi daemon regardless of multiprocess/
> multitheaded mode.

Touching WSGI script file works for daemon mode no matter how many
processes/threads you have configured for the daemon process group.

> having the child processes restart on the next
> request is not a problem for me,  just as long at every mod-wsgi
> daemon process eventually gets restarted on it's next request.

All will be restarted before they next handle an actual request.

What tends to happen is that on next request, the daemon process to
which request was proxied says 'sorry, I need to restart'. The Apache
child worker gets this message and so closes connection to daemon
process and attempts to connect to daemon processes again. This time
another in group would pick it up and would do the same thing. In
effect you get a cascade, with all processes in daemon process group
trying to handle it and all realising they need to restart. When one
of the restarted processes finally comes back up and grabs request
again, it will handle the request.

Graham

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: sharing a module level variable

[Graham Dumpleton]

On Nov 3, 11:53 am, belred <[EMAIL PROTECTED]> wrote:
> On Nov 2, 2:58 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > On Nov 3, 2:03 am, belred <[EMAIL PROTECTED]> wrote:
>
> > > On Nov 2, 3:29 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> > > > belred wrote:
> > > > > i have an wget event in a cron job.  the view does some processing
> > > > > which involves calling external websites and databases (takes about 25
> > > > > seconds) and updates some module level dictionary lookup variables
> > > > > (about 7 MB of data) which the rest of the program reads.  but
> > > > > unfortunately, only the one apache child process seems to be updated,
> > > > > not all the others.  how can i share this module level variable across
> > > > > processes?  this lookup happens multiple times per  request.  but the
> > > > > internal data gets updated nightly.
>
> > > > Aah, so this is the real question! I don't believe Django signals are
> > > > intended to serve needs like this. How does "the rest of the program"
> > > > read the module-level dictionary items? The more explicit you are about
> > > > the exact communication mechanism involved the more likely it is someone
> > > > (probably not me) will be able to help.
>
> > > > regards
> > > >  Steve
>
> > > thanks steve,
>
> > > you comments about signals were very clear and should be in the
> > > documentation.
>
> > > when i receive the nightly wget request to update the data, it's
> > > stored in module level dicts which other parts of the program use by
> > > simply importing the data module.
>
> > > import data
>
> > > def view_func(request):
> > >    foo = data.lookup['foo']
> > >    ...
>
> > > def view_update_data(request):
> > >     data.lookup = retrieve_new_data()
> > >     ...
>
> > > this works correctly for the child process that receives the update,
> > > but the other child process don't seem to be getting the updates.
>
> > > i thought after i did an update i could os.uptime() thewsgifile
> > > which would cause all of my django project to restart, but it doesn't
> > > seem to be updating my data either.
>
> > If the module level data you are talking about are just transient
> > global variables in the module, then other processes can't see them
> > (or other sub interpreters in same process). For a start read:
>
> >  http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading
>
> > Written for mod_wsgi, but equally applicable to mod_python for
> > embedded mode description at least. Take note of very last section
> > where it summarises data sharing issues.
>
> > If it is module level data, only solution would be to use mod_wsgi
> > daemon mode and delegate Django instance to run in single process.
>
> > In respect of triggering a restart, if the data is indeed transient,
> > ie., in memory only, how does it get read on startup if you are
> > relying on cron job to trigger its initialisation?
>
> > Graham
>
> in the apps __init__.py it sees if a pickle file exists.  if so, it
> read it in and sets the module level variable.  if it doesn't exist,
> it call on web services to get new data and process it, setting the
> module level variable and saving a pickle.  saving the pickle allows
> the external server to be down as well as my server to restart and
> still use the "last known good data".  it also allows my server to
> start instantly instead of 25 second delay while retrieving new data.
> nightly, cron uses wget to call this routine.

If pickle file doesn't exist and so has to contact web service to get
data, for multiprocess web server case where requests may get handled
by different processes at same time just after startup, you just
except that web service may be asked to do same thing multiple times.

Since this is a degenerate case which wouldn't normally happen,
probably okay, but though I would mention it anyway. You would need to
ensure though that the writing of the pickle files by each process
doesn't interfere with each other and allow incomplete file to be read
by another process. Thus, write to unique temporary file and only
rename to actual file when done.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django on Apache (mod_python) administration cookie problem

[Graham Dumpleton]

On Nov 4, 5:08 pm, Dave  Dash <[EMAIL PROTECTED]> wrote:
> I am witnessing this issue using manage.py runserver.
>
> The only useful information I can give is this was working when I was
> running .97 (or whatever was the trunk a few months back), I recently
> upgraded to the latest trunk (~1.1) and now continually get this
> message.
>
> I suspect something has changed in the last few months and I missed
> whatever it was.  I'm going to attempt to setup a dummy project and
> try this again.
>
> If anybody has some clue, please let me know,

Clear the cookie for the application from your browser cache.

Graham

> Cheers,
>
> Dave Dash
>
> On Sep 30, 5:05 pm, Álvaro Justen <[EMAIL PROTECTED]> wrote:
>
> > Ah, some details:
> > -> Admin interface runs OK with python manage.py runserver - as of it
> > is an Apache error, Django's web server isn't affected by this bug.
> > -> I'm using Debian etch as server: I've installed Apache, PHP and
> > mod_php with Debian packages, but Django installed manually.
> > -> Versions:
> >   * Apache: Server version: Apache/2.2.3
> >     Server built:   Mar 22 2008 09:29:10
> >   * PHP: PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:46:24)
> >     Copyright (c) 1997-2006 The PHP Group
> >     Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
> >   * Django: 1.0-final-SVN-unknown
>
> > --
> >  Cheers,
> >   Álvaro Justen
> >   Debian GNU/Linux user
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: localhost host only webservices/authentication in general

[Graham Dumpleton]

On Nov 6, 11:24 am, craic <[EMAIL PROTECTED]> wrote:
> with django, is it possible to restrict the calling host of particular
> urls to be the localhost?
>
> namely, is there a way to restrict say a set of web services
> implemented in django to be only accepted if they are the same domain
> as the hosted page?
>
> so if i have a php page on foo.com/bar.php, which contains javascript
> with some ajax calls to a web service:http://foo.com/ws/blah, that
> would be allowed.
>
> but if someone on another host/location atttemps to 
> call:http://foo.com/ws/blah
> they will get permission denied.

I'd say it isn't entirely clear what you are asking.

Do you mean you want to block access to anything but a web browser
which is run on a particular host (eg., on the same machine as the web
server), which is what first and last paragraph suggests.

Or, do you mean you want to block access to anything except for case
where web service is accessed from JavaScript running in a web page
hosted by the same web server, as second and third paragraph suggests.

If the first option, as someone else pointed out, if running Django
under Apache, that is relatively simple using something like:

  
  Order deny,allow
  Deny from all
  Allow from localhost
  Allow from 10.0.0.1 # or other IPs as required.
  

The second option is harder to do and not fool proof. It would
generally rely on looking at Referrer HTTP header to ensure that
access came via page hosted from same server, but most likely this
wouldn't be present for request initiated by JavaScript and someone
could fake up the Referrer HTTP header anyway and still gain access.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: FastCGI and Django as a continuously running server

[Graham Dumpleton]

On Nov 6, 4:00 pm, "DULMANDAKH Sukhbaatar" <[EMAIL PROTECTED]>
wrote:
> >  The one thing left that I'd like to do is set up Django to run
> > continuously, even when there are no http requests.  My application
> > runs a bunch of periodic background tasks in addition to serving up
> > web content, and it seems that after a few minutes with no web
> > activity, the app is terminated.  I'm coming from the java world where
> > you typically have one long-running jvm which handles all requests and
> > does not start and stop with new Apache instances.  I'd like to set up
> > something similar with Django.
>
> I think there is no such possibility in Apache. It terminates
> processes or thread after every request.

Sorry, that it is not generally true. It depends on the hosting
mechanism and how it has been configured.

If using mod_python or mod_wsgi, then Apache processes which hold
Django instance will normally persist for many requests. They will not
be terminate after every request.

The problem with mod_python and mod_wsgi (embedded mode) is that they
are multi process on UNIX and so you have to contend with there being
multiple copies in memory and thus multiple instances of that
background task as well. It may be a problem if multiple process try
to run background task at same time.

If using mod_wsgi daemon mode, then you can setup there to be only one
process for the application and so only one instance of background
task. If that task has to be run when idle, just need to be careful
what you are doing with idle timeout restarts and possibly have
preloading of Django setup as well.

If using fastcgi, it also can be configured to have single or multiple
processes and also believe it can be configured to kill off processes
when idle for a period. As to original posters problem, it may be case
the web hosting has configured it to kill off idle processes or simply
recycle them every so often to avoid problems with memory creep.

In other words, it is not as simple as you think. The only instance
where you are guaranteed for process to be killed after every request
is CGI.

Graham

> >  Are there any web pages or documentation people could point me to
> > which explain how to set this up?  Again I'd like my Django app to run
> > continuously and have each web request make a call into an already
> > running python interpreter.
>
> Maybe you can use cron job to run or make request to you application
> periodically. Drupal uses such thing to index web pages and some other
> stuffs.
>
> --
> Regards
> Dulmandakh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

On Nov 7, 2:38 am, huw_at1 <[EMAIL PROTECTED]> wrote:
> Hi all. I am having some real problems with this. I have an LDAP
> authentication backend that I have hooked up to my app. Standalone it
> appears to run fine. However when running it through my apache server
> I am seeing alot of segmentation faults in my error log coupled with
> the redirection page not loading on succesful authentication.
>
> I have googled around a bit and seen a few other threads with LDAP
> authentication and apache segementation faults. However none of them
> seem to be quite the same issue that I am experiencing. The only thing
> I have managed to garner thus far is that there may be a version
> mismatch betweem the openldap libraries used to compile apache with
> and those used to compile the python-ldap module.
>
> If anyone has any ideas about this or, miraculously, has a solution I
> would be most grateful.

The version mismatch on shared library versions is indeed usually what
the problem is.

You need to run 'ldd' on all Apache modules, all PHP modules if using
PHP, and Python LDAP modules and work out which LDAP client libraries
they use.

Normally Apache mod_auth_ldap would use self contained LDAP client
implementation and so it shouldn't be an issue unless symbols not
being namespaced, but may be possible (not sure) to tell it to use
distinct LDAP client library as well.

See:

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

This is about MySQL, but same sort of issue. See how 'ldd' command is
used in that case to check library versions and do similar thing for
LDAP stuff.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django with Apache2 on Ubuntu

[Graham Dumpleton]

On Nov 8, 5:39 am, project2501 <[EMAIL PROTECTED]> wrote:
> Hi,
>   I got Django to work behind Apache2 with mod_python, but had some
> questions for the experts.
>
> 1) Is there an easy way to log stdout without re-writing all my output
> statements? What about python logging?

Anything sent to stdout in mod_python will end up in the Apache error
logs, at least eventually. The problem is that it is buffered and it
requires explicit flushing.

To avoid having to modify code, you may be better off using mod_wsgi.
In mod_wsgi output to stdout will actually generate an error by
default, because portable WSGI applications should not output to
stdout and some WSGI hosting mechanisms use stdin/stdout. One can
disable this restriction in mod_wsgi through a configuration directive
or by reassigning sys.stdout to be sys.stderr.

In general, outputing debug to stdout in web applications is a bad
idea. You should instead output them to stderr instead.

For more information see:

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

> 2) Is there a good way in Django to put startup code when deployed in
> Apache that only gets run once per server restart? I build some
> indexes that are used by my Django apps but it only needs to be done
> at initialize time once.

You can put code in settings file. Do note however that this will be
executed once per process created by Apache. Since Apache is
multiprocess this can therefore happen many times in life of Apache
instance. Apache can also recycle processes within lifetime of Apache
instance.

With mod_wsgi, things are perhaps again more flexible as you can put
startup code in WSGI script file rather than having to put it in
settings file. Also, mod_wsgi allows you using mod_wsgi daemon mode to
delegate application to single daemon process if having initialisation
done more than once is a problem.

More information on mod_wsgi and Django at:

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

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

5.so.2 => /usr/lib64/libgssapi_krb5.so.2
> (0x003b68a0)
>         libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003b68e0)
>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0039ad80)
>         libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3
> (0x003b6860)
>         libz.so.1 => /usr/lib64/libz.so.1 (0x0039a4e0)
>         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>         libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
> (0x003b6920)
>         libkeyutils.so.1 => /lib64/libkeyutils.so.1
> (0x0039af80)
>         libselinux.so.1 => /lib64/libselinux.so.1 (0x0039a340)
>         libsepol.so.1 => /lib64/libsepol.so.1 (0x0039a300)
>
> To me everything matches up. I have had a few other suggestions such
> as using strace. This however has so much detail in it is difficult to
> trace anything in a multi-thread/child environment. I have also had
> suggested mod_backtrace and mod_whatkilledus however these require
> recompiling my apache server which is something I am loathed to do as
> it is something I have never done before and am worried I will lose my
> setup if I do this. So I guess I am open to suggestions as I am trying
> to weigh up my options.
>
> On Nov 6, 10:33 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 7, 2:38 am, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > Hi all. I am having some real problems with this. I have an LDAP
> > > authentication backend that I have hooked up to my app. Standalone it
> > > appears to run fine. However when running it through my apache server
> > > I am seeing alot of segmentation faults in my error log coupled with
> > > the redirection page not loading on succesful authentication.
>
> > > I have googled around a bit and seen a few other threads with LDAP
> > > authentication and apache segementation faults. However none of them
> > > seem to be quite the same issue that I am experiencing. The only thing
> > > I have managed to garner thus far is that there may be a version
> > > mismatch betweem the openldap libraries used to compile apache with
> > > and those used to compile the python-ldap module.
>
> > > If anyone has any ideas about this or, miraculously, has a solution I
> > > would be most grateful.
>
> > The version mismatch on shared library versions is indeed usually what
> > the problem is.
>
> > You need to run 'ldd' on all Apache modules, all PHP modules if using
> > PHP, and Python LDAP modules and work out which LDAP client libraries
> > they use.
>
> > Normally Apache mod_auth_ldap would use self contained LDAP client
> > implementation and so it shouldn't be an issue unless symbols not
> > being namespaced, but may be possible (not sure) to tell it to use
> > distinct LDAP client library as well.
>
> > See:
>
> >  http://code.google.com/p/modwsgi/wiki/ApplicationIssues#MySQL_Shared_...
>
> > This is about MySQL, but same sort of issue. See how 'ldd' command is
> > used in that case to check library versions and do similar thing for
> > LDAP stuff.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: apache and django

[Graham Dumpleton]

On Nov 10, 5:50 pm, "DULMANDAKH Sukhbaatar" <[EMAIL PROTECTED]>
wrote:
> > Ok.  But are the configuration lines any different or will they
> > change.  If anyone has a good tutorial written could you please post
> > it.  Also, What does this line mean ?
> > SetEnv DJANGO_SETTINGS_MODULE mysite.settings
>
> See http://httpd.apache.org/docs/2.2/mod/mod_env.html. I suggest you
> to do some research by yourself.

Note that SetEnv in Apache is traditionally used for CGI scripts and
would dictate what operating system environment variables are set in
the separate process created to run the CGI script. It does not in
itself change operating system environment variables for the Apache
child worker processes where Django runs itself.

When Django is run with mod_python however, Django is taking the
variables set by SetEnv and forcibly updating os.environ and as a side
affect also updating the operating system environment variables as
well. This is actually somewhat bad practice for anything running
directly under an Apache module as it will affect code running under
other Apache modules as well, eg, PHP. Things can get even worse if
running multiple Django instances in a multithreaded server
configuration and setting overlapping sets of variables to different
values as you can end up with race conditions on values of operating
system environment variables as seen by C code or other Apache
modules.

In other words, it isn't that simple and Django in the long term
should target getting rid of reliance on variables in os.environ.

FWIW, with mod_wsgi anything defined using SetEnv only populates the
per request WSGI environment dictionary and not the process level
operating system environment variables. At this stage though, Django
cannot use per request environment that WSGI provides and so manual
step of setting os.environ still required. At least updating
os.environ is only done once when WSGI script loaded and not on every
request like mod_python.

So, it isn't as simple as you may think. :-)

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

On Nov 10, 8:53 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
> Hi Graham and thanks for the response again.
>
> I seem to remember when I originally built this 64-bit mod_python
> module I had a lot of difficulty. I was getting error messages which I
> solved by following the solution in this article:
>
> http://agiletesting.blogspot.com/2007_10_01_archive.html
>
> Although I didn't fully understand what I was doing, the instructions
> fixed the issue I was having. I'm hoping that as a result this is a 64-
> bit issue which I can get around when I move to a 32-bit production
> server.

Solve the static vs shared library issue for mod_python first and then
we can see.

> I have never tried nor heard of mod_wsgi. Is this just a new
> replacement for mod_python which I can run Django and other python web
> apps through? Are there any changes I need to make to them if I
> implement this module?

No changes required to Django user application code. Just how you
configure Apache and how you need to use a WSGI script file as bridge
to Django application is different.

The mod_wsgi module isn't a replacement for mod_python as mod_wsgi
only supports Python web application supporting WSGI interface, as
nearly all do these days. The mod_python module provides its own
framework for developing web applications as well.

Graham

> Many thanks
>
> Huw
>
> On Nov 8, 10:05 am, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 7, 10:29 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > Graham thanks,
>
> > > First of all here is my httpd.conf file modules:
>
> > > # Example:
> > > # LoadModule foo_module modules/mod_foo.so
> > > #
>
> > > LoadModule python_module modules/mod_python.so
> > > #LoadModule dav_svn_module     modules/mod_dav_svn.so
> > > #LoadModule authz_svn_module   modules/mod_authz_svn.so
>
> > > 
> > > 
> > > #
>
> > > So as you can see the only module I am actually using is the
> > > mod_python one. 'httpd -l' reveals:
>
> > >   core.c
> > >   mod_authn_file.c
> > >   mod_authn_default.c
> > >   mod_authz_host.c
> > >   mod_authz_groupfile.c
> > >   mod_authz_user.c
> > >   mod_authz_default.c
> > >   mod_auth_basic.c
> > >   mod_include.c
> > >   mod_filter.c
> > >   mod_log_config.c
> > >   mod_env.c
> > >   mod_setenvif.c
> > >   prefork.c
> > >   http_core.c
> > >   mod_mime.c
> > >   mod_status.c
> > >   mod_autoindex.c
> > >   mod_asis.c
> > >   mod_cgi.c
> > >   mod_negotiation.c
> > >   mod_dir.c
> > >   mod_actions.c
> > >   mod_userdir.c
> > >   mod_alias.c
> > >   mod_so.c
>
> > > Running ldd on mod_python reveals:
>
> > > /usr/local/apache2/modules/mod_python.so:
> > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x2af216d13000)
> > >         libdl.so.2 => /lib64/libdl.so.2 (0x2af216f2d000)
> > >         libutil.so.1 => /lib64/libutil.so.1 (0x2af217131000)
> > >         libm.so.6 => /lib64/libm.so.6 (0x2af217335000)
> > >         libc.so.6 => /lib64/libc.so.6 (0x2af2175b8000)
> > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > The mod_python module isn't linking to shared Python library but has
> > linked it statically. This can cause problems, see below.
>
> > > and on the python ldap module:
>
> > > /usr/local/lib/python2.5/site-packages/python_ldap-2.3.5-py2.5-linux-
> > > x86_64.egg/_ldap.so
> > >         libldap_r-2.3.so.0 => /usr/lib64/libldap_r-2.3.so.0
> > > (0x2aad1567e000)
> > >         liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0
> > > (0x2aad158c7000)
> > >         libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x2aad15ad5000)
> > >         libssl.so.6 => /lib64/libssl.so.6 (0x2aad15cef000)
> > >         libcrypto.so.6 => /lib64/libcrypto.so.6 (0x2aad15f38000)
> > >         libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
> > > (0x2aad1628)
>
> > The ldap module is link Python shared library.
>
> > That mod_python.so has embedded static module and you can shared being
> > linked in here can cause crashes.
>
> > Haven't seen this variation of problem before, but see:
>
> >http://code.google.com/p/modwsgi/wiki/InstallationIssues
>
> > This describes issues with use of static and shared library for Python
> > at same 

Re: apache and django

[Graham Dumpleton]

Are you setting up Apache to serve your Django static media as
instructions indicate you to do?

If you have, have you put in the direct URL to where the static media
should hosted into your browser to see if it works? Have you then
compared that URL to what HTML pages are trying to access for the
same?

Graham

On Nov 11, 3:17 pm, prem1er <[EMAIL PROTECTED]> wrote:
> Hey everyone, thanks for all your help.
>
> I'm currently able to get django running now on apache.  But the style
> sheets aren't working so I'm guessing I have the paths wrong somewhere
> in my apache config.  Anyone see a problem?  I feel like it has to do
> with
>
> PythonOption django.root /
>
> When I have this line in the config the admin site doesn't work.  When
> I don't the admin works, but with no style sheet.
>
> On Nov 10, 7:19 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 10, 5:50 pm, "DULMANDAKH Sukhbaatar" <[EMAIL PROTECTED]>
> > wrote:
>
> > > > Ok.  But are the configuration lines any different or will they
> > > > change.  If anyone has a good tutorial written could you please post
> > > > it.  Also, What does this line mean ?
> > > > SetEnv DJANGO_SETTINGS_MODULE mysite.settings
>
> > > Seehttp://httpd.apache.org/docs/2.2/mod/mod_env.html. I suggest you
> > > to do some research by yourself.
>
> > Note that SetEnv in Apache is traditionally used for CGI scripts and
> > would dictate what operating system environment variables are set in
> > the separate process created to run the CGI script. It does not in
> > itself change operating system environment variables for the Apache
> > child worker processes where Django runs itself.
>
> > When Django is run with mod_python however, Django is taking the
> > variables set by SetEnv and forcibly updating os.environ and as a side
> > affect also updating the operating system environment variables as
> > well. This is actually somewhat bad practice for anything running
> > directly under an Apache module as it will affect code running under
> > other Apache modules as well, eg, PHP. Things can get even worse if
> > running multiple Django instances in a multithreaded server
> > configuration and setting overlapping sets of variables to different
> > values as you can end up with race conditions on values of operating
> > system environment variables as seen by C code or other Apache
> > modules.
>
> > In other words, it isn't that simple and Django in the long term
> > should target getting rid of reliance on variables in os.environ.
>
> > FWIW, with mod_wsgi anything defined using SetEnv only populates the
> > per request WSGI environment dictionary and not the process level
> > operating system environment variables. At this stage though, Django
> > cannot use per request environment that WSGI provides and so manual
> > step of setting os.environ still required. At least updating
> > os.environ is only done once when WSGI script loaded and not on every
> > request like mod_python.
>
> > So, it isn't as simple as you may think. :-)
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: apache mod_wsgi/nginx config: different behaviors if www pre-pended

[Graham Dumpleton]

On Nov 13, 6:48 am, "Serdar T." <[EMAIL PROTECTED]> wrote:
> Can someone offer advice on server deployment headaches involving
> apache/mod_wsgi/nginx? I seem to be having two problems:
>
> 1) Apache/mod_wsgi correctly serves dynamic content from a test app
> (located in a ~/public_html directory) when the url starts with
> "www".  But apache reverts to serving the default index.html (out of /
> var/www) when the "www" is omitted from the url. I tried tweaking the
> ServerAlias configs and even using Rewrite rules, but to no avail.
>
> Ideally, I'd like apache and nginx to rerwite all urls to strip the
> leading "www"
>
> My server config and relevant django app files (settings.py and
> urls.py) are athttp://dpaste.com/90308/
> They are an adaptation of the configs from EricFlo's screencast 13
> (http://thisweekindjango.com/screencasts/episode/21/django-ground-
> episode-13/)

What if you list all host names in single ServerAlias directive and
not multiple.

  http://httpd.apache.org/docs/2.2/mod/core.html#serveralias

> 2) In addition, the admin backend doesn't work on the production
> server (I get a 404 error) regardless of whether or not I pre-pend the
> "www". Apache error logs stated that the sqlite database backend did
> not have write permissions, but the 404 errors persisted even after I
> added the permissions (chmod 755).

You have:

  ADMIN_MEDIA_PREFIX = '/media/'

yet that doesn't appear to be where media files are being served from.

Your configuration is a bit confusing with nginx in front and both
nginx and Apache both attempting to serve static files. Suggest you
get Apache working with static files first and ignore nginx until you
have that working and understand how things are affected by Django
settings for media.

Graham

> Any suggestions would be greatly appreciated!!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

On Nov 12, 11:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
> echo '/usr/local/lib' >> /etc/ld.so.conf
>
> more /etc/ld.so.conf
>
> include ld.so.conf.d/*.conf
> /usr/local/lib
>
> ldd /usr/local/bin/python
>
>         libpython2.5.so.1.0 => not found
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
>         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
>         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
>         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
>         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
>         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)

Where is libpython2.5.so installed? What are the permissions on it?

What do you get for:

  echo $LD_LIBRARY_PATH

just prior to running 'ld'?

Graham

> On Nov 12, 11:57 am, marco ghidinelli <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Nov 12, 2008 at 03:22:02AM -0800, huw_at1 wrote:
>
> > > An update on this.
>
> > > 'which python' returns:
>
> > >         libpython2.5.so.1.0 => not found
> > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
> > >         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
> > >         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
> > >         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
> > >         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
> > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > > This explains why I cannot compile mod_python without first setting
> > > the LD_LIBRARY_PATH to '/usr/local/lib'. I don't know if this is the
> > > reason why the mod_python compilation continuously compiles with the
> > > python library as static. I upgraded my apache to the latest version
> > > however I still am getting segmentation faults on user authentication.
> > > Which potentially suggests that the problem is not apache and is
> > > something else like this issue.
>
> > echo '/usr/local/lib' >> /etc/ld.so.conf
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Permission denied while using apache2

[Graham Dumpleton]

On Nov 12, 11:44 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> laspal wrote:
> > hi,
> > I am trying to create folder.
> > here is the code:
> > if not os.path.isdir(str(_user.username)):
> >          os.mkdir(str(_user.username) )
> > filepathwithname = os.path.join(str(_user.username), file_name)
> >         if not os.path.isfile(filepathwithname):
> >             workbook.save(os.path.join(str(_user.username),
> > file_name))
>
> > The problem is I am getting permission denied error.
> > It works fine when I am using  runserver. but getting error while
> > using apache2
>
> > Can anyone help me out.
>
> What's the current directory when that code runs under Apache? It's
> likely not the same as when you run it under runserver ... so you will
> either need to change its permissions or switch to a directory you *do*
> have permissions on.

For more information see:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_Working_Directory

Still relevant if not using mod_wsgi but instead using mod_python.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

Because you have created the symlink for the .so file so it appears
next to the static library. It is arguably a a failing of standard
Python installer that it doesn't do this. What to do is explained in
document I previously pointed you at:

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

Yes I know this is for mod_wsgi but same applies to mod_python.

Graham

On Nov 13, 8:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
> ls -ltr /usr/local/lib
>
> -r-xr-xr-x     1 root root  4806649 Nov 11 11:22 libpython2.5.a
> -r-xr-xr-x     1 root root  4806649 Nov 12 12:49 libpython2.5.so.1.0
> lrwxrwxrwx  1 root root            19 Nov 12 12:49 libpython2.5.so ->
> libpython2.5.so.1.0
>
> echo $LD_LIBRARY_PATH
>
> /usr/local/lib
>
> ldd /usr/local/bin/python
>
>         libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
> (0x2b6d8efc5000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
>         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
>         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
>         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
>         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
>         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> recompile mod_python and do ldd /usr/local/apache2/modules/
> mod_python.so
>
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x2b74c34f7000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x2b74c3711000)
>         libutil.so.1 => /lib64/libutil.so.1 (0x2b74c3915000)
>         libm.so.6 => /lib64/libm.so.6 (0x2b74c3b19000)
>         libc.so.6 => /lib64/libc.so.6 (0x2b74c3d9c000)
>         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> I still don't get why the library is being compiled in statically.
>
> On Nov 13, 12:11 am, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 12, 11:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > echo '/usr/local/lib' >> /etc/ld.so.conf
>
> > > more /etc/ld.so.conf
>
> > > include ld.so.conf.d/*.conf
> > > /usr/local/lib
>
> > > ldd /usr/local/bin/python
>
> > >         libpython2.5.so.1.0 => not found
> > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
> > >         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
> > >         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
> > >         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
> > >         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
> > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > Where is libpython2.5.so installed? What are the permissions on it?
>
> > What do you get for:
>
> >   echo $LD_LIBRARY_PATH
>
> > just prior to running 'ld'?
>
> > Graham
>
> > > On Nov 12, 11:57 am, marco ghidinelli <[EMAIL PROTECTED]> wrote:
>
> > > > On Wed, Nov 12, 2008 at 03:22:02AM -0800, huw_at1 wrote:
>
> > > > > An update on this.
>
> > > > > 'which python' returns:
>
> > > > >         libpython2.5.so.1.0 => not found
> > > > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
> > > > >         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
> > > > >         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
> > > > >         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
> > > > >         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
> > > > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > > > > This explains why I cannot compile mod_python without first setting
> > > > > the LD_LIBRARY_PATH to '/usr/local/lib'. I don't know if this is the
> > > > > reason why the mod_python compilation continuously compiles with the
> > > > > python library as static. I upgraded my apache to the latest version
> > > > > however I still am getting segmentation faults on user authentication.
> > > > > Which potentially suggests that the problem is not apache and is
> > > > > something else like this issue.
>
> > > > echo '/usr/local/lib' >> /etc/ld.so.conf
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

Did you do a 'ls -L' on the symlink to validate it pointed at
something?

The relative location of where the .so will be is more a hint as for
different systems it may not be in same relative location.

Graham

On Nov 13, 10:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
> My apologies. I forgot to mention that I already tried what was
> suggested in the article you pointed me at. I created a symlink in /
> usr/local/lib/python2.5/config as directed however recompiling
> mod_python still links to the library statically. Unless I missed a
> step in the article I am starting to wonder if mod_python just
> includes this library statically by default. Still, thanks for all the
> help so far. I really appreciate it.
>
> On Nov 13, 9:55 am, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > Because you have created the symlink for the .so file so it appears
> > next to the static library. It is arguably a a failing of standard
> > Python installer that it doesn't do this. What to do is explained in
> > document I previously pointed you at:
>
> >  http://code.google.com/p/modwsgi/wiki/InstallationIssues
>
> > Yes I know this is for mod_wsgi but same applies to mod_python.
>
> > Graham
>
> > On Nov 13, 8:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > ls -ltr /usr/local/lib
>
> > > -r-xr-xr-x     1 root root  4806649 Nov 11 11:22 libpython2.5.a
> > > -r-xr-xr-x     1 root root  4806649 Nov 12 12:49 libpython2.5.so.1.0
> > > lrwxrwxrwx  1 root root            19 Nov 12 12:49 libpython2.5.so ->
> > > libpython2.5.so.1.0
>
> > > echo $LD_LIBRARY_PATH
>
> > > /usr/local/lib
>
> > > ldd /usr/local/bin/python
>
> > >         libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
> > > (0x2b6d8efc5000)
> > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
> > >         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
> > >         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
> > >         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
> > >         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
> > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > > recompile mod_python and do ldd /usr/local/apache2/modules/
> > > mod_python.so
>
> > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x2b74c34f7000)
> > >         libdl.so.2 => /lib64/libdl.so.2 (0x2b74c3711000)
> > >         libutil.so.1 => /lib64/libutil.so.1 (0x2b74c3915000)
> > >         libm.so.6 => /lib64/libm.so.6 (0x2b74c3b19000)
> > >         libc.so.6 => /lib64/libc.so.6 (0x2b74c3d9c000)
> > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > > I still don't get why the library is being compiled in statically.
>
> > > On Nov 13, 12:11 am, Graham Dumpleton <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Nov 12, 11:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > > > echo '/usr/local/lib' >> /etc/ld.so.conf
>
> > > > > more /etc/ld.so.conf
>
> > > > > include ld.so.conf.d/*.conf
> > > > > /usr/local/lib
>
> > > > > ldd /usr/local/bin/python
>
> > > > >         libpython2.5.so.1.0 => not found
> > > > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
> > > > >         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
> > > > >         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
> > > > >         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
> > > > >         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
> > > > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > > > Where is libpython2.5.so installed? What are the permissions on it?
>
> > > > What do you get for:
>
> > > >   echo $LD_LIBRARY_PATH
>
> > > > just prior to running 'ld'?
>
> > > > Graham
>
> > > > > On Nov 12, 11:57 am, marco ghidinelli <[EMAIL PROTECTED]> wrote:
>
> > > > > > On Wed, Nov 12, 2008 at 03:22:02AM -0800, huw_at1 wrote:
>
> > > > > > > An update on this.
>
> > > > > > > 'which python' returns:
>
> > > > > > >         libpython2.5.so.1.0 => not found
> > > > > > >         libpthread.so.0 => /lib64/libpthread.s

Re: mod_python setup on Apache virtual host

[Graham Dumpleton]

On Nov 15, 4:14 pm, "Chris Bai" <[EMAIL PROTECTED]> wrote:
> Can anyone point to me a reference to setup mod_python on Apache virtual
> host for Django? Or write something about it?
>
> I am able to run my app in Django development server. I am also able to set
> up virtual host to display index.html for my website. Now I am ready to move
> my Django app to production but don't know how to setup virtual host for it.
> My environment is Apache 2.2.10, mod_python 3.3.1, and Python 2.5.2.

Which part of the online documentation don't you understand?

  http://docs.djangoproject.com/en/dev/howto/deployment/modpython/

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: mod_python setup on Apache virtual host

[Graham Dumpleton]

Are you setting ErrorDocument directives in Apache configuration?

If you are then disable them and then actual error may not be masked.

Have you looked in Apache error log for more information?

Graham

On Nov 16, 5:53 am, Chuck22 <[EMAIL PROTECTED]> wrote:
> Here is what I tried.
>
> 
>     DocumentRoot "C:/Apache/homedomain"
>     ServerName domain.com
>     ServerAliaswww.domain.com
>
>     SetEnv DJANGO_SETTINGS_MODULE homedomain.settings
>     SetHandler mod_python
>     PythonHandler django.core.handlers.modpython
>     PythonPath "['C:/Apache'] + sys.path"
>     PythonDebug On
>
> 
>
> But I got error:
>
> ***
> MOD_PYTHON ERROR
>
> ProcessId:      1708
> Interpreter:    'domain.com'
>
> ServerName:     'domain.com'
> DocumentRoot:   'C:/Apache/homedomain'
>
> URI:            '/'
> Location:       None
> Directory:      None
> Filename:       'C:/Apache/homedomain/'
> PathInfo:       ''
>
> Phase:          'PythonHandler'
> Handler:        'django.core.handlers.modpython'
>
> Traceback (most recent call last):
>
>   File "C:\Python25\Lib\site-packages\mod_python\importer.py", line
> 1537, in HandlerDispatch
>     default=default_handler, arg=req, silent=hlist.silent)
>
>   File "C:\Python25\Lib\site-packages\mod_python\importer.py", line
> 1229, in _process_target
>     result = _execute_target(config, req, object, arg)
>
>   File "C:\Python25\Lib\site-packages\mod_python\importer.py", line
> 1128, in _execute_target
>     result = object(arg)
>
>   File "C:\Python25\lib\site-packages\django\core\handlers
> \modpython.py", line 222, in handler
>     return ModPythonHandler()(req)
>
>   File "C:\Python25\lib\site-packages\django\core\handlers
> \modpython.py", line 195, in __call__
>     response = self.get_response(request)
>
>   File "C:\Python25\lib\site-packages\django\core\handlers\base.py",
> line 128, in get_response
>     return self.handle_uncaught_exception(request, resolver, exc_info)
>
>   File "C:\Python25\lib\site-packages\django\core\handlers\base.py",
> line 160, in handle_uncaught_exception
>     return callback(request, **param_dict)
>
>   File "C:\Python25\lib\site-packages\django\views\defaults.py", line
> 88, in server_error
>     t = loader.get_template(template_name) # You need to create a
> 500.html template.
>
>   File "C:\Python25\lib\site-packages\django\template\loader.py", line
> 80, in get_template
>     source, origin = find_template_source(template_name)
>
>   File "C:\Python25\lib\site-packages\django\template\loader.py", line
> 73, in find_template_source
>     raise TemplateDoesNotExist, name
>
> TemplateDoesNotExist: 500.html
>
> 
>
> I can not find clear answer in the 
> doc:http://docs.djangoproject.com/en/dev/howto/deployment/modpython/
>
> Any helps are welcome.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multithreaded Dev Server

[Graham Dumpleton]

On Nov 16, 4:40 pm, Chris <[EMAIL PROTECTED]> wrote:
> I understand what you're saying. It's just unfortunate we're throwing
> out the convenience of the dev server.
>
> What's up withhttp://code.djangoproject.com/ticket/3357? Looks like
> this idea isn't new.

Using daemon mode of mod_wsgi can almost give you the convenience you
want. The main issue with Apache is generally the need to restart
Apache on all code changes. With mod_wsgi daemon mode, you only need
touch the modification time of the WSGI script file after a set of
code changes have been made and mod_wsgi will ensure application is
reloaded. If you want, you can add your own monitor thread which looks
for changed files and automatically triggers an application restart.
See:

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

Graham

> Chris
>
> On Nov 16, 12:30 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Sat, 2008-11-15 at 21:17 -0800, Chris wrote:
> > > Do you mean easier in that runserver doesn't support multithreading at
> > > all? Or easier in that it supports multi-threading, but it's difficult
> > > to set up?
>
> > The dev server is single-threaded by design. It wouldn't be impossible
> > to make it multi-threaded with code changes, but it would be fiddly and
> > in the past we've said we really aren't interested, since it adds a lot
> > of maintenance burden. If you want multi-threaded behaviour, use a real
> > web server.
>
> > Regards,
> > Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Segmentation Fault on succesful authentication

[Graham Dumpleton]

Can you try building mod_wsgi instead and see if it picks up the
correct library?

If it doesn't work, post the output from running 'configure' script
and running 'make' for mod_wsgi.

I trust mod_wsgi build process more than I do mod_python.

Graham

On Nov 17, 9:04 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
> ls -ltr /usr/local/lib/python2.5/config/libpython2.5.so
>
> lrwxrwxrwx 1 root root 21 Nov 12 10:48 /usr/local/lib/python2.5/config/
> libpython2.5.so -> ../../libpython2.5.so
>
> ls -ltr /usr/local/lib
>
> -r-xr-xr-x  1 root root  4806649 Nov 11 11:22 libpython2.5.a
> -r-xr-xr-x  1 root root  4806649 Nov 12 12:49 libpython2.5.so.1.0
> lrwxrwxrwx  1 root root       19 Nov 12 12:49 libpython2.5.so ->
> libpython2.5.so.1.0
> drwxr-xr-x 21 root root    20480 Nov 12 12:50 python2.5
>
> ldd /usr/local/apache2/modules/mod_python.so
>
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x2b2d9e698000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x2b2d9e8b2000)
>         libutil.so.1 => /lib64/libutil.so.1 (0x2b2d9eab6000)
>         libm.so.6 => /lib64/libm.so.6 (0x2b2d9ecba000)
>         libc.so.6 => /lib64/libc.so.6 (0x2b2d9ef3d000)
>         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> echo $LD_LIBRARY_PATH
>
> /usr/local/lib
>
> On Nov 14, 5:17 am, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > Did you do a 'ls -L' on the symlink to validate it pointed at
> > something?
>
> > The relative location of where the .so will be is more a hint as for
> > different systems it may not be in same relative location.
>
> > Graham
>
> > On Nov 13, 10:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > My apologies. I forgot to mention that I already tried what was
> > > suggested in the article you pointed me at. I created a symlink in /
> > > usr/local/lib/python2.5/config as directed however recompiling
> > > mod_python still links to the library statically. Unless I missed a
> > > step in the article I am starting to wonder if mod_python just
> > > includes this library statically by default. Still, thanks for all the
> > > help so far. I really appreciate it.
>
> > > On Nov 13, 9:55 am, Graham Dumpleton <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > Because you have created the symlink for the .so file so it appears
> > > > next to the static library. It is arguably a a failing of standard
> > > > Python installer that it doesn't do this. What to do is explained in
> > > > document I previously pointed you at:
>
> > > >  http://code.google.com/p/modwsgi/wiki/InstallationIssues
>
> > > > Yes I know this is for mod_wsgi but same applies to mod_python.
>
> > > > Graham
>
> > > > On Nov 13, 8:44 pm, huw_at1 <[EMAIL PROTECTED]> wrote:
>
> > > > > ls -ltr /usr/local/lib
>
> > > > > -r-xr-xr-x     1 root root  4806649 Nov 11 11:22 libpython2.5.a
> > > > > -r-xr-xr-x     1 root root  4806649 Nov 12 12:49 libpython2.5.so.1.0
> > > > > lrwxrwxrwx  1 root root            19 Nov 12 12:49 libpython2.5.so ->
> > > > > libpython2.5.so.1.0
>
> > > > > echo $LD_LIBRARY_PATH
>
> > > > > /usr/local/lib
>
> > > > > ldd /usr/local/bin/python
>
> > > > >         libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
> > > > > (0x2b6d8efc5000)
> > > > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x0039a4a0)
> > > > >         libdl.so.2 => /lib64/libdl.so.2 (0x0039a460)
> > > > >         libutil.so.1 => /lib64/libutil.so.1 (0x0039b340)
> > > > >         libm.so.6 => /lib64/libm.so.6 (0x0039a420)
> > > > >         libc.so.6 => /lib64/libc.so.6 (0x0039a3e0)
> > > > >         /lib64/ld-linux-x86-64.so.2 (0x0039a2c0)
>
> > > > > recompile mod_python and do ldd /usr/local/apache2/modules/
> > > > > mod_python.so
>
> > > > >         libpthread.so.0 => /lib64/libpthread.so.0 (0x2b74c34f7000)
> > > > >         libdl.so.2 => /lib64/libdl.so.2 (0x2b74c3711000)
> > > > >         libutil.so.1 => /lib64/libutil.so.1 (0x2b74c3915000)
> > > > >         libm.so.6 => /lib64/libm.so.6 (0x2b74c3b19000)
> > > > >         libc.so.6 => /lib64/libc.so.6 (0x2b74c3d9c000)
> > > > >         /lib64/ld-linux-x86-64.so.2 (0x

Re: GeoDjango in Ubuntu 8.10, Segmentation Fault

[Graham Dumpleton]

Based on comments in a separate thread, GeoDango may have issues with
multithreaded configuration. Which Apache MPM was being used for each
Apache version, prefork or worker? The worker MPM uses threads and so
that could be the culprit.

Graham

On Nov 19, 10:43 am, GRoby <[EMAIL PROTECTED]> wrote:
> I replaced packages one at a time with ones from Ubuntu 8.04.  The
> segmentation faults went away when I switched Apache from 2.2.9 to
> 2.2.8, so I can just lock the package with the Hardy version for now.
>
> On Nov 18, 4:34 pm, GRoby <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > I created a GeoDjango application that I have been successfully using
> > with Ubuntu 8.04.
>
> > I would like to have as many packages as possible handled by the OS,
> > so I am testing it with Ubuntu 8.10, with all packages installed
> > through Synaptic (including PostGIS, PostGreSQL, Mod-Python, Psycopg2,
> > Django, etc).
>
> > In a Python Shell, I am able to perform queries on my spatial models
> > successfully.  In a web browser, I get a plain white screen if any
> > code is executed that works with spatially enabled models.  Otherwise
> > everything seems to be working (including an OpenLayers MapServer
> > view, so I know the DB is loaded correctly).
>
> > In the error.log file, I get a single error per attempted page view
> > like:
> > [Tue Nov 18 16:13:43 2008] [notice] child pid 21074 exit signal
> > Segmentation fault (11)
> > [Tue Nov 18 16:16:59 2008] [notice] child pid 21071 exit signal
> > Segmentation fault (11)
> > [Tue Nov 18 16:19:08 2008] [notice] child pid 21328 exit signal
> > Segmentation fault (11)
>
> > If I attempt to run the same code in a Python Shell, the code runs
> > correctly.
>
> > Any ideas, I suspect that it could be a permission or Mod-Python
> > related issue but am not sure where to go from here.
>
> > Thanks!
>
> > BTW, if anyone wants a copy of the application, it is available 
> > fromhttp://www.coopgis.org, it is the start of an Electric Utility GIS.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: configuring production server for static media

[Graham Dumpleton]

If:

  ADMIN_MEDIA_PREFIX = '/media/'

means that static media URLs will all be prefixed with that, then
wouldn't:

  root /home/user/public_html/mysite/public/media;

need to be:

  root /home/user/public_html/mysite/public;

This is because you have location '/' on nginx mapped to this
directory.

Graham

On Nov 20, 10:45 am, "Serdar T." <[EMAIL PROTECTED]> wrote:
> Hello folks,
> Can anyone out there offer advice on glitches in my production
> environment, as well as explain the relevant settings.py in plain
> English for a newbie?
>
> I've been pulling my hair out for weeks trying to get an nginx reverse
> proxy to serve static media while apache mod_wsgi serves up dynamic
> django content. The dynamic content is being served, and I can access
> the index of media files in a browser by visiting the MEDIA_URL.
>
> But for some reason, media does not get served when I access the admin
> backend. I get the login screen without any of the stylesheets,
> javascript, etc. (and a 500 error when I try to login).
>
> I haven't had any luck despite countless tweaks to MEDIA_ROOT,
> MEDIA_URL, and ADMIN_MEDIA_PREFIX  (along with corresponding changes
> to nginx and apache config files).
>
> At the bottom of the post are my various config files. I was hoping
> someone could point out whatever dumb mistake I'm making.
> Additionally, if someone could explain the concepts behind the
> settings.py file and how they relate back to the server config files
> -- that would be enormously helpful (the django docs and countless
> threads I've read on the subject don't connect the dots clearly enough
> -- at least for me).
>
>  I'm hoping a basic explanation might let me penetrate the problem
> conceptually, so I'm not just futzing around with tweaks with no idea
> what's really happening.
>
> Can someone teach a man to fish?
>
> settings.py
> MEDIA_ROOT = '/home/user/public_html/mysite/public/media/'
> MEDIA_URL = 'http://media.mysite.org/'
> ADMIN_MEDIA_PREFIX = '/media/'
>
> **/etc/nginx/nginx.conf*
> user www-data;
> worker_processes  3;
>
> error_log  /var/log/nginx/error.log;
> pid        /var/run/nginx.pid;
>
> events {
>     worker_connections  1024;
>
> }
>
> http {
>     include       /etc/nginx/mime.types;
>     default_type  application/octet-stream;
>
>     access_log  /var/log/nginx/access.log;
>
>     sendfile        on;
>     #tcp_nopush     on;
>
>     #keepalive_timeout  0;
>     keepalive_timeout  10;
>     tcp_nodelay        on;
>
>     gzip  on;
>
>     upstream webcluster {
>         server 127.0.0.1:8080;
>     }
>
>     include /etc/nginx/sites-enabled/*;
>
> }
>
> */etc/nginx/sites-available/mysite.org*
> server {
>         listen 80;
>         server_name media.mysite.org;
>         access_log /var/log/nginx/mysite.media.access.log;
>         location / {
>                 autoindex on;
>                 index index.html;
>                 root /home/user/public_html/mysite/public/media;
>
>         }
>
> }
>
> server {
>         listen 80;
>         server_name mysite.orgwww.mysite.org;
>         access_log /var/log/nginx/mysite.django.access.log;
>         if ($host !~* "^mysite\.org") {
>                 rewrite ^(.*)$http://mysite.org$1permanent;
>                 break;
>         }
>         location / {
>                 proxy_passhttp://webcluster;
>                 include /etc/nginx/proxy.conf;
>         }
>
> }
>
> */etc/apache2/sites-available/mysite.org**
> 
>         ServerAdmin [EMAIL PROTECTED]
>         ServerNamewww.mysite.org
>         ServerAlias mysite.org
>         WSGIScriptAlias / /home/user/public_html/mysite/test_app/
> mysite.wsgi
>
>         
>         Order deny,allow
>         Allow from all
>         
>
>         LogLevel debug
>         ErrorLog /var/log/apache2/mysite/error.log
>         CustomLog /var/log/apache2/mysite/access.log combined
>
> 
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: serving static file via django

[Graham Dumpleton]

On Nov 20, 1:41 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > i know that django is not recommended to serve static content via
> > django and the web server handler should be used for it.
>
> > also, the following method to serve static content in development env,
> > but not recommended in a production env.
>
> > django.views.static.serve
>
> >http://docs.djangoproject.com/en/dev/howto/static-files/?from=olddocs
>
> > my requirement is that I need to serve just one 10x10 gif file via
> > django -- so that i can track what users requested the file. can i use
> > the above view to serve this file ? what are the drawbacks of using
> > this view in a production env ?
>
> It's not like the Django thought-police will beat down your door in the
> middle of the night if you *do* serve a single piece of static content.
> But you should carefully read the warnings in the documentation about
> serving static files before deciding to do so.
>
> The drawbacks are that the Django web servers aren't designed to the
> same rigorous security standards that are applied to production web
> servers like Apache and lighthttpd,

I really scratch my head when I keep seeing this argument about
security. It doesn't really matter whether you use Apache or Django,
it is possible to screw up in configuring either such that you could
expose more of the file system than you intended.

The issue as to whether one is worse than the other has probably more
to do with how easy it is to also inadvertently turn on automatic
directory indexes thereby allowing arbitrary browsing rather than
having to guess what files may be available.

In Django one has to consciously set show_indexes parameter to True
for the particular urlconf rule. In this respect Apache is actually
more dangerous as stuff like DirectoryIndex will be inherited
automatically from an outer scope, so if someone is stupid enough to
have turned it on in main Apache server configuration scope, it will
then apply to all directories and that that is occurring wouldn't be
obvious.

Do acknowledge that with Apache 'Allow from all' also needs to be set
for appropriate scope, but a few too many times I have seen people do
exactly this in main Apache server configuration scope, or for whole
file system. Seems to be more prevalent amongst PC users who open up
their whole drive because they simply don't understand Apache
configuration enough to know to only apply it to certain contexts.
People turning on FollowSymLinks for whole server is also something
that see a bit too often.

So, in the hands of someone who doesn't know what they are doing, I
would almost say that one could cause bigger problems with Apache than
what could be done in the more constrained use case for serving static
files in Django.

I would also say that the bigger problem with people using Django with
Apache is those people who think they need to stick their Django site
instance somewhere under the Apache DocumentRoot for it to work. This
is a much worse situation because if DocumentRoot is still used to
serve static files, they could then be exposing all the Django site
code, including database passwords for download.

> and won't be (quite) as efficient.
> The efficiency probably won't matter for a (one-pixel?) graphics.

Hopefully static file serving in general will be better in Django 1.1.
See View-03 in:

  http://code.djangoproject.com/wiki/Version1.1Features

Graham

> Whether what the Django server *does* provide is sufficiently secure for
> your needs only you can decide. But you can't say you weren't warned if
> everything goes pear-shaped ;-)
>
> regards
>  Steve
> --
> Steve Holden        +1 571 484 6266   +1 800 494 3119
> Holden Web LLC              http://www.holdenweb.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: configuring production server for static media

[Graham Dumpleton]

On Nov 20, 2:10 pm, "Serdar T." <[EMAIL PROTECTED]> wrote:
> hmm...I modified the root as you suggested but still the same results:
> I get the admin page minus any stylesheets, etc.
>
> I'm confused though: what exactly is the ADMIN_MEDIA_PREFIX prefixing?
>
>  It seems that the setting tacks "/media" to the end of root path as a
> way of defining where the server should search for media.
>
> But if the "media" directory is being appended to the end of the path,
> why is it called a prefix?

Please provide a snippet of the HTML pages being served which show the
actual URLs which are generated in the response.

Also indicate whether you have validated that you can access the
static media files from nginx media site and exactly what the URLs you
have managed to successfully access them using are.

A directory list of what is actually in:

  /home/user/public_html/mysite/public
  /home/user/public_html/mysite/public/media

would be useful as well.

Graham

> On Nov 19, 7:43 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > If:
>
> >   ADMIN_MEDIA_PREFIX = '/media/'
>
> > means that static media URLs will all be prefixed with that, then
> > wouldn't:
>
> >   root /home/user/public_html/mysite/public/media;
>
> > need to be:
>
> >   root /home/user/public_html/mysite/public;
>
> > This is because you have location '/' on nginx mapped to this
> > directory.
>
> > Graham
>
> > On Nov 20, 10:45 am, "Serdar T." <[EMAIL PROTECTED]> wrote:
>
> > > Hello folks,
> > > Can anyone out there offer advice on glitches in my production
> > > environment, as well as explain the relevant settings.py in plain
> > > English for a newbie?
>
> > > I've been pulling my hair out for weeks trying to get an nginx reverse
> > > proxy to serve static media while apache mod_wsgi serves up dynamic
> > > django content. The dynamic content is being served, and I can access
> > > the index of media files in a browser by visiting the MEDIA_URL.
>
> > > But for some reason, media does not get served when I access the admin
> > > backend. I get the login screen without any of the stylesheets,
> > > javascript, etc. (and a 500 error when I try to login).
>
> > > I haven't had any luck despite countless tweaks to MEDIA_ROOT,
> > > MEDIA_URL, and ADMIN_MEDIA_PREFIX  (along with corresponding changes
> > > to nginx and apache config files).
>
> > > At the bottom of the post are my various config files. I was hoping
> > > someone could point out whatever dumb mistake I'm making.
> > > Additionally, if someone could explain the concepts behind the
> > > settings.py file and how they relate back to the server config files
> > > -- that would be enormously helpful (the django docs and countless
> > > threads I've read on the subject don't connect the dots clearly enough
> > > -- at least for me).
>
> > >  I'm hoping a basic explanation might let me penetrate the problem
> > > conceptually, so I'm not just futzing around with tweaks with no idea
> > > what's really happening.
>
> > > Can someone teach a man to fish?
>
> > > settings.py
> > > MEDIA_ROOT = '/home/user/public_html/mysite/public/media/'
> > > MEDIA_URL = 'http://media.mysite.org/'
> > > ADMIN_MEDIA_PREFIX = '/media/'
>
> > > **/etc/nginx/nginx.conf*
> > > user www-data;
> > > worker_processes  3;
>
> > > error_log  /var/log/nginx/error.log;
> > > pid        /var/run/nginx.pid;
>
> > > events {
> > >     worker_connections  1024;
>
> > > }
>
> > > http {
> > >     include       /etc/nginx/mime.types;
> > >     default_type  application/octet-stream;
>
> > >     access_log  /var/log/nginx/access.log;
>
> > >     sendfile        on;
> > >     #tcp_nopush     on;
>
> > >     #keepalive_timeout  0;
> > >     keepalive_timeout  10;
> > >     tcp_nodelay        on;
>
> > >     gzip  on;
>
> > >     upstream webcluster {
> > >         server 127.0.0.1:8080;
> > >     }
>
> > >     include /etc/nginx/sites-enabled/*;
>
> > > }
>
> > > */etc/nginx/sites-available/mysite.org*
> > > server {
> > >         listen 80;
> > >         server_name media.mysite.org;
> 

Re: configuring production server for static media

[Graham Dumpleton]

Try:

  ADMIN_MEDIA_PREFIX = 'http://media.mysite.org/media/'

Web site example always show just a path and not a site name, but
source code shows it can be  full URL with site name.

# URL prefix for admin media -- CSS, JavaScript and images. Make sure
to use a
# trailing slash.
# Examples: "http://foo.com/media/";, "/media/".
ADMIN_MEDIA_PREFIX = '/media/'

I guess I'd always assumed that this prefix was added on top of
MEDIA_URL, but apparently not. Thus if on different site, looks like
you need to state host as well.

Graham

On Nov 20, 3:06 pm, "Serdar T." <[EMAIL PROTECTED]> wrote:
> I think my prior response missed the mark in terms of sample html and
> url.
>
> To be precise:
>
> http://mysite.org/admin/
>
> yields the below html:
>
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="en-us" xml:lang="en-
> us" >
> 
> Log in | Django site admin
> 
> 
>
> 
> 
>
> 
>
> 
>
> 
>
>     
>     
>         
>
>         <<<>>>
>
> On Nov 19, 10:58 pm, "Serdar T." <[EMAIL PROTECTED]> wrote:
>
> > On Nov 19, 10:32 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Nov 20, 2:10 pm, "Serdar T." <[EMAIL PROTECTED]> wrote:
>
> > > > hmm...I modified the root as you suggested but still the same results:
> > > > I get the admin page minus any stylesheets, etc.
>
> > > > I'm confused though: what exactly is the ADMIN_MEDIA_PREFIX prefixing?
>
> > > >  It seems that the setting tacks "/media" to the end of root path as a
> > > > way of defining where the server should search for media.
>
> > > > But if the "media" directory is being appended to the end of the path,
> > > > why is it called a prefix?
>
> > > Please provide a snippet of the HTML pages being served which show the
> > > actual URLs which are generated in the response.
>
> >  > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> > 2http://www.w3.org/1999/xhtml"; lang="en-us" xml:lang="en-
> > us" >
> > 3
> > 4Log in | Django site admin
> > 5
> > 6
> > 7
> > 8
> > 9
> > 10
> > 11
> > 12
> > 13
> > 14
> > 15
> > 16
> > 17
> > 18
> > 19
> > 20 
> > 21 
> > 22 
> > 23
> > 24Django administration
> > 25
> > 26 
> > 27
> > 28
> > 29 
> > 30 
> > <<>>
>
> > > Also indicate whether you have validated that you can access the
> > > static media files from nginx media site and exactly what the URLs you
> > > have managed to successfully access them using are.
>
> > Yup, when I turn indexing on in nginx configs, I'm able to view the
> > media files at the following URL subdomain:
>
> >http://media.mysite.org/
>
> > gives acess the following directory heirarchy:
>
> > ../
> > media/
> >           ../
> >           css/                                               10-
> > Nov-2008 14:05                   -
> >           img/                                               10-
> > Nov-2008 14:05                   -
> >           js/
> >          <>
>
> > > A directory list of what is actually in:
>
> > >   /home/user/public_html/mysite/public
>
> > the "/media" directory is the only thing in this directory.
> > It is a symlink to django's admin media file, located in the following
> > directory:
>
> > /home/user/python/django-trunk/django/contrib/admin/media
>
> > >   /home/user/public_html/mysite/public/media
>
> > media, as stated above, is a symlink to django's admin/media directory
>
> > > would be useful as well.
>
> > > Graham
>
> > > > On Nov 19, 7:43 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > If:
>
> > > > >   ADMIN_MEDIA_PREFIX = '/media/'
>
> > > > > means that static media URLs will all be prefixed with that, then
> > > > > wouldn't:
>
> > > > >   root /home/user/public_html/mysite/public/media;
>
> > > > > need to be:
>
> > > > >   root /home/user/public_html/mysite/public;
>
> > > > > This is because you have location '/' on nginx mapped to this
> > > > >

Re: Apache Setup

[Graham Dumpleton]

On Nov 26, 3:32 pm, Django Newbie <[EMAIL PROTECTED]> wrote:
> Hi Everybody,
>
> Django newbie here.  I'm trying to get it to work under apache with
> mod_python on a freebsd server but running into problems.  I searched
> the archives and found similar things, but I tried all the suggestions
> and still no luck.
>
> The error:
>
> MOD_PYTHON ERROR
>
> ProcessId:      11226
> Interpreter:    'dinnertools'
>
> ServerName:     'gidget.cws-web.com'
> DocumentRoot:   '/home/dave/www/gidget.cws-web.com'
>
> URI:            '/dinnertools/'
> Location:       '/dinnertools/'
> Directory:      None
> Filename:       '/home/dave/www/gidget.cws-web.com/dinnertools'
> PathInfo:       '/'
>
> Phase:          'PythonHandler'
> Handler:        'django.core.handlers.modpython'
>
> Traceback (most recent call last):
>
>  File "/usr/local/lib/python2.5/site-packages/mod_python/importer.py",
> line 1537, in HandlerDispatch
>    default=default_handler, arg=req, silent=hlist.silent)
>
>  File "/usr/local/lib/python2.5/site-packages/mod_python/importer.py",
> line 1229, in _process_target
>    result = _execute_target(config, req, object, arg)
>
>  File "/usr/local/lib/python2.5/site-packages/mod_python/importer.py",
> line 1128, in _execute_target
>    result = object(arg)
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/core/handlers/modpython.py",
> line 228, in handler
>    return ModPythonHandler()(req)
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/core/handlers/modpython.py",
> line 201, in __call__
>    response = self.get_response(request)
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/core/handlers/base.py",
> line 67, in get_response
>    response = middleware_method(request)
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/middleware. 
> py",
> line 9, in process_request
>    engine = __import__(settings.SESSION_ENGINE, {}, {}, [''])
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/backends/db 
> .py",
> line 2, in 
>    from django.contrib.sessions.models import Session
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/models.py",
> line 4, in 
>    from django.db import models
>
>  File "/usr/local/lib/python2.5/site-packages/django/db/__init__.py",
> line 16, in 
>    backend = __import__('%s%s.base' % (_import_path,
> settings.DATABASE_ENGINE), {}, {}, [''])
>
>  File
> "/usr/local/lib/python2.5/site-packages/django/db/backends/mysql/base.py",
> line 13, in 
>    raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
>
> My apache setup:
> PythonImport /home/dave/dinnertools/egg.py dinnertools
>
>    
>      SetHandler python-program
>      PythonHandler django.core.handlers.modpython
>      SetEnv DJANGO_SETTINGS_MODULE settings
>      PythonInterpreter dinnertools
>      PythonOption django.root /dinnertools
>      PythonDebug On
>      PythonPath "['/home/dave/dinnertools'] + sys.path"
>    
>
> ImproperlyConfigured: Error loading MySQLdb module: Shared object
> "libmysqlclient_r.so.15" not found, required by "_mysql.so"
>
> The egg.py file:
>
> import os
> os.environ['PYTHON_EGG_CACHE'] = '/www/htdocs/egg_cache'
>
> my project directory:
> # ll
> total 9
> -rw-r--r--  1 dave  dave     0 Nov 21 11:00 __init__.py
> -rw-r--r--  1 dave  dave   145 Nov 21 11:01 __init__.pyc
> -rw-r--r--  1 dave  dave    67 Nov 25 15:03 egg.py
> -rw-r--r--  1 dave  dave   546 Nov 21 11:00 manage.py
> drwxr-xr-x  2 dave  dave   512 Nov 21 11:23 recipes
> -rw-r--r--  1 dave  dave  2862 Nov 25 21:14 settings.py
> -rw-r--r--  1 dave  dave  1817 Nov 25 10:26 settings.pyc
> -rw-r--r--  1 dave  dave   541 Nov 25 10:30 urls.py
> #
>
> DB connections of course work outside of the apache/mod_python
> environment.  Also I would expect some temporary file to be unpacked in
> the /www/htdocs/egg_cache directory, but I don't see any.  The
> permissions on the egg_cache directory are such that apache should be
> able to write to it.
>
> Any ideas?  I assume I need the extra setup related to egg file since
> the MySQLdb module has some egg files related to it.  Please let me know
> what I'm missing.
>
> Thanks,
>
> Yours truly, django newbie.

Your libmysqlclient_r.so.15 file can't be installed in a standard
location. Where is it installed? Do you have anything set in your user
environment so it can be found when you run it as you? Apache runs as
a different user and will not have your environment.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: pythonpath problem

[Graham Dumpleton]

On Nov 26, 5:13 pm, Chris Amico <[EMAIL PROTECTED]> wrote:
> I have a handful of apps in that folder. I can add it to sys.path
> using sys.path.insert(0, path) and they import fine after, but that
> only lasts one session. How do I make it stick?

That is what PythonPath directive is for.

Graham

> On Nov 25, 5:28 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Tue, 2008-11-25 at 14:55 -0800, Chris Amico wrote:
> > > Hi folks,
>
> > > I'm having some trouble getting a directory onto my pythonpath. I'm
> > > sure I'm missing something obvious here.
>
> > > On my server, I have a directory with my django work called redfence.
> > > Inside is my project, along with a folder called 'apps' holding all my
> > > personal and third party apps. It's the apps folder I can't seem to
> > > get python to recognize.
>
> > > Redfence shows up, and the main project folder, redfenceproject,
> > > imports fine. But apps doesn't and I need to be able to put modules
> > > there.
>
> > > Here's what I have in a vhost.conf file:
>
> > > 
> > >     SetHandler python-program
> > >     PythonHandler django.core.handlers.modpython
> > >     SetEnv DJANGO_SETTINGS_MODULE redfenceproject.settings
> > >     PythonOption django.root /
> > >     PythonDebug On
> > >     PythonPath "['/.../redfence/apps', '/.../redfence'] + sys.path"
> > >     SetEnv PYTHON_EGG_CACHE /var/www/vhosts/
> > > redfenceproject.com/.python-eggs
> > > 
>
> > > Any help is much appreciated.
>
> > Nothing look immediately wrong to me.
>
> > So, the first question here is whether you've checked the permissions on
> > apps/? Apache will need execute permissions for the "other" section in
> > order to traverse into that directory. Since you suggest that things
> > inside redfence/ are imported fine, it sounds like the permissions are
> > okay at least down to that level, so I'd have a look at the
> > redfence/apps/ permissions.
>
> > How are you verifying that nothing imports from apps/? For example, I
> > would try putting a really simple file in there that, when imported,
> > prints a message to sys.stderr (and then calls sys.stderr.flush()
> > because modpython buffers stderr) and check the Apache error log for
> > your virtual host. Essentially, take Django out of the equation for the
> > time being. You could even put the little test function from the
> > modpython documentation into that directory and use that as the handler
> > to check the python path is set up correctly.
>
> > (As an aside: I doubt that you need to specify django.root in that
> > config. That option is only need if you SCRIPT_NAME is *not* going to be
> > '/'.)
>
> > Regards,
> > Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: pythonpath problem

[Graham Dumpleton]

On Nov 26, 5:38 pm, Chris Amico <[EMAIL PROTECTED]> wrote:
> Right. And the PythonPath directive ought to do the trick, but it
> clearly isn't. The server belongs to a friend who gave me permission
> to everything under the redfenceproject.com directory (one above
> redfence), and I created the apps folder, so I'm not sure what the
> problem is.

Where else in main Apache configuration files or .htaccess files is
PythonPath directive mentioned?

Can you better describe the directory hierarchy and not say '...'.
Actual directory listings (ls -las) of each of the directories you
have already added to PythonPath would help.

This would be so much more predictable if using mod_wsgi. Python path
stuff in mod_python is a PITA and causes so many problems, although
documentation for mod_python setup doesn't help much. :-(

BTW, what version of mod_python are you using?

Graham

> On Nov 25, 10:29 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 26, 5:13 pm, Chris Amico <[EMAIL PROTECTED]> wrote:
>
> > > I have a handful of apps in that folder. I can add it to sys.path
> > > using sys.path.insert(0, path) and they import fine after, but that
> > > only lasts one session. How do I make it stick?
>
> > That is what PythonPath directive is for.
>
> > Graham
>
> > > On Nov 25, 5:28 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Tue, 2008-11-25 at 14:55 -0800, Chris Amico wrote:
> > > > > Hi folks,
>
> > > > > I'm having some trouble getting a directory onto my pythonpath. I'm
> > > > > sure I'm missing something obvious here.
>
> > > > > On my server, I have a directory with my django work called redfence.
> > > > > Inside is my project, along with a folder called 'apps' holding all my
> > > > > personal and third party apps. It's the apps folder I can't seem to
> > > > > get python to recognize.
>
> > > > > Redfence shows up, and the main project folder, redfenceproject,
> > > > > imports fine. But apps doesn't and I need to be able to put modules
> > > > > there.
>
> > > > > Here's what I have in a vhost.conf file:
>
> > > > > 
> > > > >     SetHandler python-program
> > > > >     PythonHandler django.core.handlers.modpython
> > > > >     SetEnv DJANGO_SETTINGS_MODULE redfenceproject.settings
> > > > >     PythonOption django.root /
> > > > >     PythonDebug On
> > > > >     PythonPath "['/.../redfence/apps', '/.../redfence'] + sys.path"
> > > > >     SetEnv PYTHON_EGG_CACHE /var/www/vhosts/
> > > > > redfenceproject.com/.python-eggs
> > > > > 
>
> > > > > Any help is much appreciated.
>
> > > > Nothing look immediately wrong to me.
>
> > > > So, the first question here is whether you've checked the permissions on
> > > > apps/? Apache will need execute permissions for the "other" section in
> > > > order to traverse into that directory. Since you suggest that things
> > > > inside redfence/ are imported fine, it sounds like the permissions are
> > > > okay at least down to that level, so I'd have a look at the
> > > > redfence/apps/ permissions.
>
> > > > How are you verifying that nothing imports from apps/? For example, I
> > > > would try putting a really simple file in there that, when imported,
> > > > prints a message to sys.stderr (and then calls sys.stderr.flush()
> > > > because modpython buffers stderr) and check the Apache error log for
> > > > your virtual host. Essentially, take Django out of the equation for the
> > > > time being. You could even put the little test function from the
> > > > modpython documentation into that directory and use that as the handler
> > > > to check the python path is set up correctly.
>
> > > > (As an aside: I doubt that you need to specify django.root in that
> > > > config. That option is only need if you SCRIPT_NAME is *not* going to be
> > > > '/'.)
>
> > > > Regards,
> > > > Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: pythonpath problem

[Graham Dumpleton]

On Nov 27, 7:50 am, Chris Amico <[EMAIL PROTECTED]> wrote:
> OK, here's another wrinkle: The modules in that folder import fine on
> the browser end. I put tagging in there, and that shows up in my admin
> list with no errors. So mod_python is picking up the vhost file, but
> I'm not getting it in the shell. Thus when I try python manage.py
> shell with anything from the apps folder installed, I get a "no module
> named tagging" error and can't get into the shell.
>
> Here's what sys.path looks like in the shell:
>
> /var/www/vhosts/redfenceproject.com/redfence/redfenceproject
> /usr/lib64/python2.4/site-packages/setuptools-0.6c5-py2.4.egg
> /usr/lib64/python2.4/site-packages/MySQL_python-1.2.2-py2.4-linux-
> x86_64.egg
> /usr/lib64/python24.zip
> /usr/lib64/python2.4
> /usr/lib64/python2.4/plat-linux2
> /usr/lib64/python2.4/lib-tk
> /usr/lib64/python2.4/lib-dynload
> /usr/lib64/python2.4/site-packages
> /usr/lib64/python2.4/site-packages/Numeric
> /usr/lib64/python2.4/site-packages/gtk-2.0
> /usr/lib/python2.4/site-packages
>
> It looks like I'm not loading either directory here.
>
> I'm using mod_python-3.2.8-3.1

I would strongly suggest you upgrade mod_python. Older versions have
lots of issues with module importing. See:

  http://www.dscpl.com.au/wiki/ModPython/Articles/ModuleImportingIsBroken

Graham

> On Nov 25, 10:53 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 26, 5:38 pm, Chris Amico <[EMAIL PROTECTED]> wrote:
>
> > > Right. And the PythonPath directive ought to do the trick, but it
> > > clearly isn't. The server belongs to a friend who gave me permission
> > > to everything under the redfenceproject.com directory (one above
> > > redfence), and I created the apps folder, so I'm not sure what the
> > > problem is.
>
> > Where else in main Apache configuration files or .htaccess files is
> > PythonPath directive mentioned?
>
> > Can you better describe the directory hierarchy and not say '...'.
> > Actual directory listings (ls -las) of each of the directories you
> > have already added to PythonPath would help.
>
> > This would be so much more predictable if using mod_wsgi. Python path
> > stuff in mod_python is a PITA and causes so many problems, although
> > documentation for mod_python setup doesn't help much. :-(
>
> > BTW, what version of mod_python are you using?
>
> > Graham
>
> > > On Nov 25, 10:29 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Nov 26, 5:13 pm, Chris Amico <[EMAIL PROTECTED]> wrote:
>
> > > > > I have a handful of apps in that folder. I can add it to sys.path
> > > > > using sys.path.insert(0, path) and they import fine after, but that
> > > > > only lasts one session. How do I make it stick?
>
> > > > That is what PythonPath directive is for.
>
> > > > Graham
>
> > > > > On Nov 25, 5:28 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > > > > wrote:
>
> > > > > > On Tue, 2008-11-25 at 14:55 -0800, Chris Amico wrote:
> > > > > > > Hi folks,
>
> > > > > > > I'm having some trouble getting a directory onto my pythonpath. 
> > > > > > > I'm
> > > > > > > sure I'm missing something obvious here.
>
> > > > > > > On my server, I have a directory with my django work called 
> > > > > > > redfence.
> > > > > > > Inside is my project, along with a folder called 'apps' holding 
> > > > > > > all my
> > > > > > > personal and third party apps. It's the apps folder I can't seem 
> > > > > > > to
> > > > > > > get python to recognize.
>
> > > > > > > Redfence shows up, and the main project folder, redfenceproject,
> > > > > > > imports fine. But apps doesn't and I need to be able to put 
> > > > > > > modules
> > > > > > > there.
>
> > > > > > > Here's what I have in a vhost.conf file:
>
> > > > > > > 
> > > > > > >     SetHandler python-program
> > > > > > >     PythonHandler django.core.handlers.modpython
> > > > > > >     SetEnv DJANGO_SETTINGS_MODULE redfenceproject.settings
> > > > > > >     PythonOption django.root /
> > > > > > >     PythonDebug On

Re: Project Setup and PYTHONPATH

[Graham Dumpleton]

On Nov 27, 1:06 am, Flo Ledermann <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> my name is flo, i am relatively new to django but would consider
> myself an experienced web developer. I am sorry if this has been asked
> hundreds of times, but after doing somewhat extensive research i still
> would like to gain some insight into the design decisions involved in
> how manage.py and the project path structure is set up by django. I
> found that django is a very well-designed toolkit in every aspect i
> researched so far, but this is the only area where i still scratch my
> head and miss the clarity and state-of-the-art-ness found in all other
> areas of django.
>
> If i get it right, manage.py adds the parent path of its location in
> the file system to the pythonpath (actually this is done in
> django.core.management.setup_environ() by calling sys.path.append
> (os.path.join(project_directory, os.pardir))). This results in a
> comfortable initial way of experimenting with django. However, i found
> that it does not actuall give me a full pythonpath in the parent
> folder - if i add additional packages there, i have to explicitly set
> the --pythonpath parameter when calling manage.py to the parent dir of
> manage.py.

I analysed this a long time ago and posted it but cant find post to
reference. Although it puts parent in sys.path, it does it only long
enough to import site package root. It then removes parent from
sys.path again. Thus why sibling directories can't be imported
normally.

> Furthermore, another feature that supposedly should help newbies makes
> things even more complicated: the folder that manage.py is in is also
> somehow treated as a part of pythonpath, so that packages can be
> referenced in the source starting from the root package (mysite.myapp)
> or as a relative path (myapp).

Directory manage.py is in is a source for modules because when Python
command line is run it will use current working directory implicitly
for module imports.

> This "helps" local development for a
> kick start, but mayhem breaks loose once you transfer your code to a
> different environment where the project is not launched through
> manage.py. Another strange side effect is that i cannot name my source
> directory (the one above "mysite") "django" (which would be my
> personal preference) because, for some reasons i could not clearly
> resolve, this causes a conflict with the main django namespace,
> although the pythonpath should start *inside* this folder.
>
> It would be great if somebody more experienced (which i guess most of
> you are) could fill me in with the reasons for this design and clarify
> the concepts working under the hood so that i can build a clear mental
> model of how pythonpath et al.

I'd like to hear the explanation as well. I have always found it quite
odd and this odd behaviour always causes issues when people then try
and run same stuff under mod_python/mod_wsgi.

Although the documentation talks about needing to add both directories
explicitly to PythonPath for mod_python, I still personally don't feel
it is explained clearly enough. And yes I have raised the issue of
clarity of the documentation before within discussions of tickets
related to the problem, but it was felt by others to be adequate. Yet
every week there are still questions about how to setup PythonPath
properly which one sees the same old people having to answer again and
again. :-(

Graham

> is set up - on the local development
> machine and on a server environment. In the case that all this is not
> following a concept as clear as the rest of django, i would personally
> vote for refactoring the setup in a way that hints newbies in a more
> deployment-friendly way of setting up their projects from the
> beginning, instead of causing refactoring troubles later on.
>
> All the best and thanks to creators and contributors for a great
> framework!
>
> flo ledermannhttp://www.floledermann.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Apache Setup

[Graham Dumpleton]

On Nov 27, 1:10 am, Django Newbie <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
>
> > On Nov 26, 3:32 pm, Django Newbie <[EMAIL PROTECTED]> wrote:
>
> >> Hi Everybody,
>
> >> Django newbie here.  I'm trying to get it to work under apache with
> >> mod_python on a freebsd server but running into problems.  I searched
> >> the archives and found similar things, but I tried all the suggestions
> >> and still no luck.
>
> >> The error:
>
> >> MOD_PYTHON ERROR
>
> >> ProcessId:      11226
> >> Interpreter:    'dinnertools'
>
> >> ServerName:     'gidget.cws-web.com'
> >> DocumentRoot:   '/home/dave/www/gidget.cws-web.com'
>
> >> URI:            '/dinnertools/'
> >> Location:       '/dinnertools/'
> >> Directory:      None
> >> Filename:       '/home/dave/www/gidget.cws-web.com/dinnertools'
> >> PathInfo:       '/'
>
> >> Phase:          'PythonHandler'
> >> Handler:        'django.core.handlers.modpython'
>
> >> Traceback (most recent call last):
>
> >>  File "/usr/local/lib/python2.5/site-packages/mod_python/importer.py",
> >> line 1537, in HandlerDispatch
> >>    default=default_handler, arg=req, silent=hlist.silent)
>
> >>  File "/usr/local/lib/python2.5/site-packages/mod_python/importer.py",
> >> line 1229, in _process_target
> >>    result = _execute_target(config, req, object, arg)
>
> >>  File "/usr/local/lib/python2.5/site-packages/mod_python/importer.py",
> >> line 1128, in _execute_target
> >>    result = object(arg)
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/core/handlers/modpython.py",
> >> line 228, in handler
> >>    return ModPythonHandler()(req)
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/core/handlers/modpython.py",
> >> line 201, in __call__
> >>    response = self.get_response(request)
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/core/handlers/base.py",
> >> line 67, in get_response
> >>    response = middleware_method(request)
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/middleware.
> >>  py",
> >> line 9, in process_request
> >>    engine = __import__(settings.SESSION_ENGINE, {}, {}, [''])
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/backends/db
> >>  .py",
> >> line 2, in 
> >>    from django.contrib.sessions.models import Session
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/contrib/sessions/models.py",
> >> line 4, in 
> >>    from django.db import models
>
> >>  File "/usr/local/lib/python2.5/site-packages/django/db/__init__.py",
> >> line 16, in 
> >>    backend = __import__('%s%s.base' % (_import_path,
> >> settings.DATABASE_ENGINE), {}, {}, [''])
>
> >>  File
> >> "/usr/local/lib/python2.5/site-packages/django/db/backends/mysql/base.py",
> >> line 13, in 
> >>    raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
>
> >> My apache setup:
> >> PythonImport /home/dave/dinnertools/egg.py dinnertools
>
> >>    
> >>      SetHandler python-program
> >>      PythonHandler django.core.handlers.modpython
> >>      SetEnv DJANGO_SETTINGS_MODULE settings
> >>      PythonInterpreter dinnertools
> >>      PythonOption django.root /dinnertools
> >>      PythonDebug On
> >>      PythonPath "['/home/dave/dinnertools'] + sys.path"
> >>    
>
> >> ImproperlyConfigured: Error loading MySQLdb module: Shared object
> >> "libmysqlclient_r.so.15" not found, required by "_mysql.so"
>
> >> The egg.py file:
>
> >> import os
> >> os.environ['PYTHON_EGG_CACHE'] = '/www/htdocs/egg_cache'
>
> >> my project directory:
> >> # ll
> >> total 9
> >> -rw-r--r--  1 dave  dave     0 Nov 21 11:00 __init__.py
> >> -rw-r--r--  1 dave  dave   145 Nov 21 11:01 __init__.pyc
> >> -rw-r--r--  1 dave  dave    67 Nov 25 15:03 egg.py
> >> -rw-r--r--  1 dave  dave   546 Nov 21 11:00 manage.py
> >

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

On Nov 27, 2:06 pm, Brian <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> Here's a questions I just posted on stackoverflow.com (because I like
> that forum's layout) - but I thought posting it here might lead to
> more / better coverage.  See:http://stackoverflow.com/questions/322694/
>
> Multiple installs of Django - How to configure transparent multiplex
> through the webserver (Lighttpd)?

Are you stuck with using Lighttpd?

Can you explain the background of the situation you have that requires
such a setup? May help in working out what to suggest.

Graham

> Hi Everyone,
>
> This question flows from the answer to: How does one set up multiple
> accounts with separate databases for Django on one server? (http://
> stackoverflow.com/questions/314515)
>
> I haven't seen anything like this on Google or elsewhere (perhaps I
> have the wrong vocabulary), so I think input could be a valuable
> addition to the internet discourse.
>
> How could one configure a server likeso:
>
> * One installation of Lighttpd
> * Multiple Django projects running as FastCGI
> * The Django projects may be added/removed at will, and ought not to
> require restarting the webserver
> * Transparent redirection of all requests/responses to a particular
> Django installation depending on the current user
>
> I.e. Given Django projects (with corresponding FastCGI socket):
>
> * Bob (/tmp/bob.fcgi)
> * Sue (/tmp/sue.fcgi)
> * Joe (/tmp/joe.fcgi)
>
> The Django projects being started with a (oversimplified) script
> likeso:
>
> #!/bin/sh
> NAME=bob
>
> SOCKET=/tmp/$NAME.fcgi
>
> PROTO=fcgi
> DAEMON=true
>
> /django_projects/$NAME/manage.py runfcgi protocol=$PROTO socket=
> $SOCKET
>   daemonize=$DAEMON
> #  end
>
> I want traffic tohttp://www.example.com/to direct the request to the
> correct Django application depending on the user that is logged in.
>
> In other words,http://www.example.comshould come "be" /tmp/bob.fcgi
> if bob is logged in, /tmp/joe.fcgi if joe is logged in, /tmp/sue.fcgi
> if sue is logged in. If no-one is logged in, it should redirect to a
> login page.
>
> I've contemplated a demultiplexing "plexer" FastCGI script with the
> following algorithm:
>
> 1. If the cookie $PLEX is set, pipe request to /tmp/$PLEX.fcgi
>
> 2. Otherwise redirect to login page (which sets the cookie PLEX based
> on a many-to-one mapping of Username => PLEX)
>
> Of course as a matter of security $PLEX should be taint checked, and
> $PLEX shouldn't give rise to any presumption of trust.
>
> A Lighttpd configuration would be likeso (though Apache, Nginx, etc.
> could be used just as easily):
>
> fastcgi.server = ( "plexer.fcgi" =>
>                            ( "localhost" =>
>                              (
>                                "socket" => "/tmp/plexer.fcgi",
>                                "check-local" => "disable"
>                              )
>                            )
>                  )
> #  end
>
> Input and thoughts, helpful links, and to know how to properly
> implement the FastCGI plexer would all be appreciated.
>
> Thank you.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

On Nov 27, 3:17 pm, Brian <[EMAIL PROTECTED]> wrote:
> Hi Graham,
>
> Thanks for the reply. No, I'm not stuck using Lighttpd at all - I just
> like it because it's simple and fast. :)
>
> Here's a link to a description of what I'd like to 
> see:http://stackoverflow.com/questions/314515
>
> The situation is this: I'm creating a web-site with a bunch of
> accounts - each account having its own database. I want people to go
> to the site (i.e.www.example.com/) and when they log in the
> application gets all its requests/responses from their account's
> database. For the moment, all accounts will be using the same Django
> applications, though that is subject to change so I'd prefer not to
> rely on a solution that precludes that possibility.
>
> I suspect (but am happy to be corrected...) that the easiest and
> safest way to do this is to have a Django instance running in FastCGI
> mode with a socket for each account. When a user is logged in, their
> requests/responses are mapped to/from the proper Django socket via the
> multiplexing solution I've suggested in my original post.
>
> As mentioned, accounts may crop up and disappear, and shouldn't
> require restarting the web-server. There could be dozens of accounts
> (which means lots of Django instances).

How often would accounts be changed and if not that often, why would
restarting the web server be a problem?

Graham

> Is there any more information that would be helpful?
>
> Cheers & thank you,
> Brian
>
> On Nov 26, 10:32 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 27, 2:06 pm, Brian <[EMAIL PROTECTED]> wrote:
>
> > > Hi everyone,
>
> > > Here's a questions I just posted on stackoverflow.com (because I like
> > > that forum's layout) - but I thought posting it here might lead to
> > > more / better coverage.  See:http://stackoverflow.com/questions/322694/
>
> > > Multiple installs of Django - How to configure transparent multiplex
> > > through the webserver (Lighttpd)?
>
> > Are you stuck with using Lighttpd?
>
> > Can you explain the background of the situation you have that requires
> > such a setup? May help in working out what to suggest.
>
> > Graham
>
> > > Hi Everyone,
>
> > > This question flows from the answer to: How does one set up multiple
> > > accounts with separate databases for Django on one server? (http://
> > > stackoverflow.com/questions/314515)
>
> > > I haven't seen anything like this on Google or elsewhere (perhaps I
> > > have the wrong vocabulary), so I think input could be a valuable
> > > addition to the internet discourse.
>
> > > How could one configure a server likeso:
>
> > > * One installation of Lighttpd
> > > * Multiple Django projects running as FastCGI
> > > * The Django projects may be added/removed at will, and ought not to
> > > require restarting the webserver
> > > * Transparent redirection of all requests/responses to a particular
> > > Django installation depending on the current user
>
> > > I.e. Given Django projects (with corresponding FastCGI socket):
>
> > > * Bob (/tmp/bob.fcgi)
> > > * Sue (/tmp/sue.fcgi)
> > > * Joe (/tmp/joe.fcgi)
>
> > > The Django projects being started with a (oversimplified) script
> > > likeso:
>
> > > #!/bin/sh
> > > NAME=bob
>
> > > SOCKET=/tmp/$NAME.fcgi
>
> > > PROTO=fcgi
> > > DAEMON=true
>
> > > /django_projects/$NAME/manage.py runfcgi protocol=$PROTO socket=
> > > $SOCKET
> > >   daemonize=$DAEMON
> > > #  end
>
> > > I want traffic tohttp://www.example.com/todirectthe request to the
> > > correct Django application depending on the user that is logged in.
>
> > > In other words,http://www.example.comshouldcome"be"; /tmp/bob.fcgi
> > > if bob is logged in, /tmp/joe.fcgi if joe is logged in, /tmp/sue.fcgi
> > > if sue is logged in. If no-one is logged in, it should redirect to a
> > > login page.
>
> > > I've contemplated a demultiplexing "plexer" FastCGI script with the
> > > following algorithm:
>
> > > 1. If the cookie $PLEX is set, pipe request to /tmp/$PLEX.fcgi
>
> > > 2. Otherwise redirect to login page (which sets the cookie PLEX based
> > > on a many-to-one mapping of Username => PLEX)
>
> > > Of course as a matter of security $PLEX should be taint checked, and
> > > $PLEX shouldn't give rise to 

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

On Nov 27, 3:45 pm, Brian <[EMAIL PROTECTED]> wrote:
> Accounts could be created as often as hourly. I'd be very bad to have
> the webserver go down while people use the system (unless it was for
> less than a second or two... but even then, it's still be very
> bad :) ).

I don't know how lighttpd works, but if one does a graceful restart
(or even a restart) with Apache, in the main it isn't noticeable to
the user as the listener socket is never released and so new
connections just queue up and aren't outright refused, ie., server
isn't actually completely stopped. The issue is more the startup time
of Django instances and whether a restart will cause active login
sessions to be terminated based on how application is written. This is
because on a restart, active instances which are still required are
restarted regardless.

A few more questions.

The actual Django application is something the users themselves are
just a user of? There is no requirement for them to be able to make
changes to a segment of code base and force their own restarts of
their instance to pick up changes.

For each account, through what do they login initially? Are you
expecting to use Django based login mechanisms for that, or do you
front it all with HTTP Basic Authentication. If you are going to
somehow switch based on their identity it presumably needs to be done
outside of the context of the target Django instance else you will not
know which to go to.

Does the account have a distinct UNIX account associated with it, or
would all Django instances run as same user and you are then just
mapping a logical account name to a specific instance attached to a
specific database.

Would there be a calculable cap on the number of accounts you would
have active at any one time. Or would it at least be acceptable that
if there is a preconfigured number of instances you can switch between
and that limit is reached, that restarting web server would then be
seen as okay?

Sorry, if I seem to be asking a lot of questions, but believe might
have a manageable solution for you, but want to be clear on these
things so know if will be or not and what configuration would need to
be.

Graham

> On Nov 26, 11:31 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Nov 27, 3:17 pm, Brian <[EMAIL PROTECTED]> wrote:
>
> > > Hi Graham,
>
> > > Thanks for the reply. No, I'm not stuck using Lighttpd at all - I just
> > > like it because it's simple and fast. :)
>
> > > Here's a link to a description of what I'd like to 
> > > see:http://stackoverflow.com/questions/314515
>
> > > The situation is this: I'm creating a web-site with a bunch of
> > > accounts - each account having its own database. I want people to go
> > > to the site (i.e.www.example.com/) and when they log in the
> > > application gets all its requests/responses from their account's
> > > database. For the moment, all accounts will be using the same Django
> > > applications, though that is subject to change so I'd prefer not to
> > > rely on a solution that precludes that possibility.
>
> > > I suspect (but am happy to be corrected...) that the easiest and
> > > safest way to do this is to have a Django instance running in FastCGI
> > > mode with a socket for each account. When a user is logged in, their
> > > requests/responses are mapped to/from the proper Django socket via the
> > > multiplexing solution I've suggested in my original post.
>
> > > As mentioned, accounts may crop up and disappear, and shouldn't
> > > require restarting the web-server. There could be dozens of accounts
> > > (which means lots of Django instances).
>
> > How often would accounts be changed and if not that often, why would
> > restarting the web server be a problem?
>
> > Graham
>
> > > Is there any more information that would be helpful?
>
> > > Cheers & thank you,
> > > Brian
>
> > > On Nov 26, 10:32 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Nov 27, 2:06 pm, Brian <[EMAIL PROTECTED]> wrote:
>
> > > > > Hi everyone,
>
> > > > > Here's a questions I just posted on stackoverflow.com (because I like
> > > > > that forum's layout) - but I thought posting it here might lead to
> > > > > more / better coverage.  
> > > > > See:http://stackoverflow.com/questions/322694/
>
> > > > > Multiple installs of Django - How to configure transparent multiplex
> > > > > through the webserver (Lighttpd)?
>
> > > > Are you stuck 

Re: Project Setup and PYTHONPATH

[Graham Dumpleton]

On Nov 28, 2:18 am, Flo Ledermann <[EMAIL PROTECTED]> wrote:
> Graham,
>
> thanks for answering! it still feels odd comapred to the otherwise
> wisely designed parts of django... adding a directory AND its parent
> to a source path is something i have never experienced in any
> framework, in any language before. But then there is something new to
> learn every day ;)
>
> i have found a setup for me that only requires a single folder as
> pythonpath which i can live with at the moment, but i would have liked
> to simplify it even more. I guess i have to live with what i have now.
> Do you see any place where this issues could/should be raised or where
> i could vote for a reconsideration of how these things are set up?
> (besides posting in this forum)

I'd say it is unlikely to be changed as too many users code would be
dependent on the current behaviour.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

Since haven't seen a response to my other questions and with Malcolm's
rebuff to your idea, do I take it you aren't interested any more?

Graham

On Nov 27, 5:19 pm, Brian <[EMAIL PROTECTED]> wrote:
> Malcolm:
>
> Thanks for the reply.
>
> > Whilst I'm all in favour of attempting to solve problems given arbitrary
> > constraints as a thought exercise, I think this one isn't really the
> > best practical solution to anything.
>
> I'm sure that's a fault of my explanation, not the design. ;o)
>
>
>
> > You are proposing having a single addressable URL that points to vastly
> > different content based on some other, transparent piece of information
> > (a cookie). Why not use the URL space as it's been designed and give
> > each instance its own URL? We have the domain namespace for that at the
> > topmost level, as well as the full URL namespace for subdivisions at a
> > different layer:  www.example.com/user1/andwww.example.com/user2/,
> > for example. You can do the authentication checks as an addendum to
> > that, for example at the indivdual lighttpd (or other webserver of
> > choice) level.
>
> > I'll go so far as to claim that your proposed setup up breaks the web.
> > Not a single request to that site will be effectively long-term
> > cacheable, since they will all have to vary on cookie. And you're using
> > the same resource name for an arbitrarily large number of difference
> > resources. The web performance and behaviour of people using such a
> > setup is actively harmed when it's so easily avoidable.
>
> You're right in that the clandestine compacting of the url (especially
> with disregard to plausible collisions) in lieu of a cookie to make
> decisions about what the webserver resource location generally flies
> in the face of fundamental principles of web design. However, this
> choice has been carefully contemplated, though it may be reconsidered.
>
> For edification, the project is not a public web-site, but has limited
> authenticated-only access, with all transmissions encrypted. There is
> a one-to-one mapping between authenticated users' account (and,
> notably, a cookie of theirs) and the content they may access on the
> site; i.e. user1 may have example.com/link, and user2 have example.com/
> link. They are mutually exclusive, and neither is ever accessible by
> the public. Thus the userx/ is superfluous. As well, due to the nature
> of the site, it is extraordinarily unlikely that it would be accessed
> by the same web browser for different accounts. It's all rather
> unconventional, I admit, but certainly not arbitrary.
>
> As well, while there will be object caching, page caching is not the
> right answer; the content is highly dynamic and it is a relatively low-
> volume site, so caching is not a major concern.
>
> All to say, I'm cognizant of the concerns expressed, and while I'd
> agree with your concerns for conventional web-sites, I'm quite
> confident in the defensibility of the design choices made, poorly
> though I may have explained them. I'm rather certain it won't break
> the web. In any event URL compaction is not relevant to the crux of
> the real problem, and as you suggest below, URL compaction it's just a
> mod_rewrite. Please disregard any references to URL mapping or
> compaction.
>
> > If you really, really wanted to go down the one name to rule them all
> > path (for example, it wins you a really large bet that you accepted by
> > accident), you could use mod_rewrite to do an internal redirect to the
> > individually named URLs (maybe combined with some other modules).
>
> > I'm not going to participate much more in this, since there isn't really
> > any Django content here (you mention the word Django a few times, but
> > nothing is specific to Django or even uses Django in the solution you've
> > proposed). I think re-evaluating your initial design would be
> > beneficial, though.
>
> Quite alright. The question at hand is where to demultiplex a user
> request to their respective datesets. It can happen either in Django
> or at the web-server. I believe the crux of the problem, if Django is
> the demultiplexer, could be expressed (making some presumptions about
> plausible solutions) as follows:
>
> How could one have a Django installation, where (for example) one may,
> based on the account of the logged-in User:
>
> (a) Add a "prefix_" to each database table; or
>
> (b) Change the database.
>
> I'd be particularly interested in seeing, for example, middleware that
> takes a Request's User and changes the django.conf.SETTINGS
> ['DATABASE_NAME'] to the database for this user's account, or
> alternatively sets a prefix for all subsequent database access.
>
> However, this middleware approach raises red flags (and I don't know
> Django well enough to overcome them), viz.
> * Is changing django.conf.SETTINGS thread-safe?
> * Is there just an inherent danger in changing django.conf.SETTINGS --
> would the DB connection be setup already?
> * Is changing the DB co

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

On Nov 28, 12:06 pm, Brian <[EMAIL PROTECTED]> wrote:
> > For each account, through what do they login initially? Are you
> > expecting to use Django based login mechanisms for that, or do you
> > front it all with HTTP Basic Authentication. If you are going to
> > somehow switch based on their identity it presumably needs to be done
> > outside of the context of the target Django instance else you will not
> > know which to go to.
>
> This is a good question, and I haven't come to a conclusion. Probably
> it'll be the Django built-in application-based authentication,
> particular to each Django instance. There will be a master map of all
> users to their respective Django instance.

That seems a bit like a chicken and egg problem. At the point that you
need to make the decision as to which Django instance to use, you
haven't yet logged in them in. Thus if you are going to try and use
their own instance to log them in, that can't work.

If you use one special Django instance to handle login, then issue is
having any session information in that instance also used by the other
instances such that when you go to actual instance on subsequent
requests, it knows you are allowed to access it.

I'll describe any solution in terms of HTTP Basic authentication first
and then can let you think about authentication when you see how the
multiplexing is achieved.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

Just letting you know off list that I will respond, just need to find
some uninterrupted time to do so. Reply will be back to the list.

Graham

On Nov 28, 2:55 pm, Brian <[EMAIL PROTECTED]> wrote:
> > > This is a good question, and I haven't come to a conclusion. Probably
> > > it'll be the Django built-in application-based authentication,
> > > particular to each Django instance. There will be a master map of all
> > > users to their respective Django instance.
>
> > That seems a bit like a chicken and egg problem. At the point that you
> > need to make the decision as to which Django instance to use, you
> > haven't yet logged in them in. Thus if you are going to try and use
> > their own instance to log them in, that can't work.
>
> If usernames are unique, e.g. email addresses, there can be a map,
> e.g.:
> [EMAIL PROTECTED] => DjangoInstanceA,
> [EMAIL PROTECTED] => DjangoInstanceB,
>
> This User-Instance mapping could happen prior to authentication if,
> when the user submits login-information from a form, a process
> (demultiplexer) decides based upon the username which Django instance
> to direct the login-request to. The Django instance then handles all
> subsequent requests.
>
> I don't know if this will actually work.
>
> > If you use one special Django instance to handle login, then issue is
> > having any session information in that instance also used by the other
> > instances such that when you go to actual instance on subsequent
> > requests, it knows you are allowed to access it.
>
> Perhaps HTTP Basic authentication might be the simplest solution. :)
>
> > I'll describe any solution in terms of HTTP Basic authentication first
> > and then can let you think about authentication when you see how the
> > multiplexing is achieved.
>
> That'd be great!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

On Nov 29, 9:31 am, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> Just letting you know off list that I will respond, just need to find
> some uninterrupted time to do so. Reply will be back to the list.

Hmmm, wrong button. No matter ..

Graham

> Graham
>
> On Nov 28, 2:55 pm, Brian <[EMAIL PROTECTED]> wrote:
>
> > > > This is a good question, and I haven't come to a conclusion. Probably
> > > > it'll be the Django built-in application-based authentication,
> > > > particular to each Django instance. There will be a master map of all
> > > > users to their respective Django instance.
>
> > > That seems a bit like a chicken and egg problem. At the point that you
> > > need to make the decision as to which Django instance to use, you
> > > haven't yet logged in them in. Thus if you are going to try and use
> > > their own instance to log them in, that can't work.
>
> > If usernames are unique, e.g. email addresses, there can be a map,
> > e.g.:
> > [EMAIL PROTECTED] => DjangoInstanceA,
> > [EMAIL PROTECTED] => DjangoInstanceB,
>
> > This User-Instance mapping could happen prior to authentication if,
> > when the user submits login-information from a form, a process
> > (demultiplexer) decides based upon the username which Django instance
> > to direct the login-request to. The Django instance then handles all
> > subsequent requests.
>
> > I don't know if this will actually work.
>
> > > If you use one special Django instance to handle login, then issue is
> > > having any session information in that instance also used by the other
> > > instances such that when you go to actual instance on subsequent
> > > requests, it knows you are allowed to access it.
>
> > Perhaps HTTP Basic authentication might be the simplest solution. :)
>
> > > I'll describe any solution in terms of HTTP Basic authentication first
> > > and then can let you think about authentication when you see how the
> > > multiplexing is achieved.
>
> > That'd be great!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Best practice for shareable web application

[Graham Dumpleton]

On Nov 29, 2:34 pm, "Leon Yeh | New Avenue.net" <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> Usually, when I am working on django project, I have one database per
> web site. So one company has all its database in one single mysql database.
>
> However recently I am working on a site that had requirements similar to
> basecamp web site.
>
> Here are the new requirement:
> 1. Multiple company with multiple users.
> 2. Each company should not be able to see other company data.
> 3. Each company access goes tohttp://companyname.app.com
>
> so my question is that what is the best way doing this ? Should I
> develop the site with:
> a. One database or each company has its own database.
> b. How to handlehttp://companyname.app.comrouting ?
> c. What is the best way of doing the database partitioning if I go with
> one shared database ? Data confidentiality is very important. I am
> afraid that error in database access expose one company data to others.

If data confidentiality is an issue, then keep using separate database
instances for each site. Each web site having their own host name, and
with each application instance in separate processes, is easily
handled with Apache and mod_wsgi (daemon mode), or fastcgi solutions
with web server of your choice that is capable of handling virtual
hosts. Nothing too difficult here.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

On Nov 28, 2:55 pm, Brian <[EMAIL PROTECTED]> wrote:
> > > This is a good question, and I haven't come to a conclusion. Probably
> > > it'll be the Django built-in application-based authentication,
> > > particular to each Django instance. There will be a master map of all
> > > users to their respective Django instance.
>
> > That seems a bit like a chicken and egg problem. At the point that you
> > need to make the decision as to which Django instance to use, you
> > haven't yet logged in them in. Thus if you are going to try and use
> > their own instance to log them in, that can't work.
>
> If usernames are unique, e.g. email addresses, there can be a map,
> e.g.:
> [EMAIL PROTECTED] => DjangoInstanceA,
> [EMAIL PROTECTED] => DjangoInstanceB,
>
> This User-Instance mapping could happen prior to authentication if,
> when the user submits login-information from a form, a process
> (demultiplexer) decides based upon the username which Django instance
> to direct the login-request to. The Django instance then handles all
> subsequent requests.
>
> I don't know if this will actually work.
>
> > If you use one special Django instance to handle login, then issue is
> > having any session information in that instance also used by the other
> > instances such that when you go to actual instance on subsequent
> > requests, it knows you are allowed to access it.
>
> Perhaps HTTP Basic authentication might be the simplest solution. :)
>
> > I'll describe any solution in terms of HTTP Basic authentication first
> > and then can let you think about authentication when you see how the
> > multiplexing is achieved.
>
> That'd be great!

Okay, the solution I am going to describe uses Apache/mod_wsgi. This
is an Apache module specifically designed for hosting Python WSGI
applications within Apache. The mod_wsgi module provides two modes of
operations. The first is embedded mode, which works similar to
mod_python in that applications run within the actual Apache child
worker processes. The second mode is daemon mode, which is similar in
some respects to fastcgi solutions, with applications running in
distinct processes from Apache child worker processes, and with Apache
child worker processes merely acting as a proxy to the WSGI
application daemon processes. We will be using mod_wsgi daemon mode in
this case, as it will allow for each Django instance to run in a
separate process.

How one would normally set up Apache/mod_wsgi for Django is described
at:

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

What we will be doing here goes beyond that, but please ensure you
read that first and perhaps get a single Django instance running that
way before contemplating the multiplexing arrangement described here.

Getting back to what you wanted, you wanted multiple users to see a
Django instance mounted at same URL, but for each to actually get a
distinct instance associated with a distinct database.

For this, as would normally be done, still use WSGIScriptAlias to
mount the WSGI script file at the appropriate URL. Here we assume it
will be root of web server. Thus:

  WSGIScriptAlias / /usr/local/django/mysite/apache/django.wsgi

By default, this will have Django instance running in embedded mode so
we want to override that. This would normally be done by configuring a
daemon process group and delegating application to run in it.

  WSGIDaemonProcess django1 display-name=%{GROUP}

  WSGIProcessGroup django1

The 'display-name' option here means that 'ps' command will show
'(wsgi:django1)' in output rather that 'httpd' process name. This will
be important for later on.

The way WSGIProcessGroup is used here means it is a static mapping, so
although we might be able to create more daemon process groups, you
would have to change the Apache configuration and restart Apache to be
able to delegate application to run in different daemon process group.
Obviously this isn't what we want.

So, instead of a static mapping, we use ability of mod_wsgi for the
process group to which application is delegated to be specified
dynamically. There are actually a number of ways this can be done when
using mod_wsgi, but will use a method which uses mod_rewrite as a
helper.

You indicated that there would be a cap on the number of instances of
Django that need to be running at any one time. Thus, what we will do
is pre define that many daemon process groups.

  WSGIDaemonProcess django1 display-name=%{GROUP}
  WSGIDaemonProcess django2 display-name=%{GROUP}
  WSGIDaemonProcess django3 display-name=%{GROUP}
  ...
  WSGIDaemonProcess djangon display-name=%{GROUP}

We also want which daemon process group is used based on identity of
logged in user. We will use HTTP Basic authentication as
authentication as that is the easiest. As long as you run stuff
through HTTPS using HTTP Basic authentication wouldn't be an issue.

Before we get onto how to use user identity from HTTP Basic
authentication, lets look at the dynamic mapping issue. To 

Re: Best practice for shareable web application

[Graham Dumpleton]

On Nov 30, 6:30 am, "Leon Yeh | New Avenue.net" <[EMAIL PROTECTED]>
wrote:
> Thanks Graham,
>
> The problem is how to automate the database creation at the sign up.
> Also how to keep share one project/ source for all of the instances.
> Multiple settings for each project/ database.
>
> I don't think it is that simple. I have spent couple days look into this
> and have not found any thing that I would considered optimal solution.

What hosting mechanism are you trying to use? I don't regard the
hosting side as that hard. The issue I guess is your expectations as
to whether restarting the web server to add a new virtual host is
acceptable. Also, are you expecting each Django instance to run as a
separate UNIX user, or whether they can all run the same user as long
as each gets their own process.

For database side, if you are just creating multiple instances of same
application. Could you just copy contents of a preconfigured database
to new database name. Worst case is needing to do a few SQL updates to
change virtual host name specific information.

Answer the bit about hosting and how you want to run it, then can
possibly outline a solution.

Graham

> Somebody must have seen this problem before and could have solved it. I
> am going back to see if pinax project has something like this.
>
> Anyhow, back to my research.
>
> Leon Yeh
>
> Graham Dumpleton wrote:
>
> > On Nov 29, 2:34 pm, "Leon Yeh | New Avenue.net" <[EMAIL PROTECTED]>
> > wrote:
> >> Hi All,
>
> >> Usually, when I am working on django project, I have one database per
> >> web site. So one company has all its database in one single mysql database.
>
> >> However recently I am working on a site that had requirements similar to
> >> basecamp web site.
>
> >> Here are the new requirement:
> >> 1. Multiple company with multiple users.
> >> 2. Each company should not be able to see other company data.
> >> 3. Each company access goes tohttp://companyname.app.com
>
> >> so my question is that what is the best way doing this ? Should I
> >> develop the site with:
> >> a. One database or each company has its own database.
> >> b. How to handlehttp://companyname.app.comrouting?
> >> c. What is the best way of doing the database partitioning if I go with
> >> one shared database ? Data confidentiality is very important. I am
> >> afraid that error in database access expose one company data to others.
>
> > If data confidentiality is an issue, then keep using separate database
> > instances for each site. Each web site having their own host name, and
> > with each application instance in separate processes, is easily
> > handled with Apache and mod_wsgi (daemon mode), or fastcgi solutions
> > with web server of your choice that is capable of handling virtual
> > hosts. Nothing too difficult here.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Configuring multiple Django installs transparently via FastCGI mutiplexing

[Graham Dumpleton]

Graham Dumpleton wrote:
> That is basically it and hopefully it makes sense. It may seem a bit
> complex, but what you want to do isn't normal. Also, it all could have
> been done a bit simpler if were using mod_wsgi 3.0 development code
> from subversion trunk as with that have a way of avoiding use of
> WSGIImportScript.

There is actually a more simpler way that it could be done even when
using mod_wsgi 2.X. It does do something that I tend to discourage,
and for which I complain about Django/mod_python integration doing,
but in this case do it for single variable and not many like Django/
mod_python. :-)

What we will do this time is use a second rewrite map file to hold
which Django settings module should be used. This will be passed as
WSGI environment variable, but then forced into process environment
variables.

  WSGIScriptAlias / /usr/local/django/mysite/apache/django.wsgi

  RewriteEngine On

  RewriteMap procmap txt:/usr/local/django/mysite/apache/procmap.txt
  RewriteRule . - [E=PROCESS_GROUP:${procmap:%{REMOTE_USER}|
undefined}]

  RewriteMap configmap txt:/usr/local/django/mysite/apache/
configmap.txt
  RewriteRule . - [E=DJANGO_SETTINGS_MODULE:${configmap:%
{ENV:PROCESS_GROUP}|mysite.settings}]

  WSGIProcessGroup %{ENV:PROCESS_GROUP}

  WSGIDaemonProcess django1 display-name=%{GROUP}
  WSGIDaemonProcess django2 display-name=%{GROUP}
  WSGIDaemonProcess django3 display-name=%{GROUP}
  ...
  WSGIDaemonProcess djangon display-name=%{GROUP}

The WSGI script file would then be:

  import os, sys
  sys.path.append('/usr/local/django')
  sys.path.append('/usr/local/django/mysite')

  import django.core.handlers.wsgi

  _application = django.core.handlers.wsgi.WSGIHandler()

  def application(environ, start_response):
os.environ['DJANGO_SETTINGS_MODULE] = environ
['DJANGO_SETTINGS_MODULE']
return _application(environ, start_response)

The bit I don't like here is that we are setting a process environment
variable on every request. For it to work, we are relying on fact that
Django settings module is actually lazily loaded only when first
required (at least I believe it is). Thus, we use the value of
DJANGO_SETTINGS_MODULE derived from very first request passed in by
Apache. After that request, for that life of the daemon process, even
if value changes, it is ignored.

The 'configmap.txt' file would then contain:

  django1 mysite.settings1
  django2 mysite.settings2
  ...

All this allows us to then get rid of the WSGIImportScript and the
associated preconfig scripts. It does mean having distinct settings
module files for each instance. They would be completely separate, or
would import 'mysite.settings' and then override only what is
required.

  from settings import *

  DATABASE_HOST = ...
  DATABASE_NAME = ...

Adding new site would then be:

1. Add new instance settings file and configure it. Setup database
etc.

2. Edit configmap.txt and map instance to new settings file.

3. Use 'ps' to determine PID of instance and send it SIGINT.

4. Edit procmap.txt and map user to instance.

Give that one a whirl as well and let me know if have questions or
something doesn't quite work as advertised. Only bit I am not sure
about is if %{ENV:PROCESS_GROUP} will be available for use in second
rewrite rule already.

Graham




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Webservers, Django thread-safeness, etc.

[Graham Dumpleton]

On Dec 4, 5:25 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 3, 2008 at 11:45 AM, SteveB <[EMAIL PROTECTED]> wrote:
> > I've had positive experiences with the standalone CherryPy webserver
> > Although I can't prove it, I'm suspicious that the problem may be that
> > Django is not thread safe.  Can anyone state for a fact that it is
> > safe to use Django with a multi-threaded webserver? If not, then multi-
> > threaded webservers like the CherryPy server are not really candidates
> > for use with Django.
>
> No-one can state this for a fact because, even though many people (and
> this is where I remind everyone that it's often a good idea to search
> the archives before posting, especially for frequently-asked questions
> like this one) use Django with thread- as opposed to process-based
> server solutions without reporting thread-safety issues, it's simply
> impossible to state, unequivocally, that "everything you will ever do
> involving Django will be 100% thread safe". This should, incidentally,
> be fairly clear from the fact that Django offers you numerous ways to
> work with, e.g., mutable stateful objects, such that Django itself
> doesn't do anything unsafe with them, but you (and by implication,
> your code) quite easily can if you're not careful.
>
> In other words, the answer is "to the best of anyone's knowledge,
> Django does not have issues running in threaded servers, and if/when
> bugs are found which contradict that we fix them". But there isn't and
> never will be a categorical assurance that Django is provably 100%
> threadsafe or that there won't from time to time be a bug that needs
> to be fixed.

It should also be stated that your best bet is to use Django 1.0 or
later. There were bigger questions marks over older Django versions,
with some changes being made for Django 1.0 to address potential
threading issues.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django And os.path Behavior

[Graham Dumpleton]

What locale settings do you have set in the environment of your user
account? These will not be getting used in context of Apache.

Graham

On Dec 6, 9:21 am, dayvo <[EMAIL PROTECTED]> wrote:
> Thanks for the response Andy.
>
> The code does work fine in the interpreter.  It's when the code is
> called from a web page where it throws an error.  I know it has
> something to do with unicode but I can't understand why os.stat is
> behaving differently.  To test from a view:
>
> --- 
> --
> Relevant URL in urls.py
> --- 
> --
> [EMAIL PROTECTED]:/home/published/www/django/catalog/music# grep demo
> urls.py
>     (r'^demo/$', 'music.views.demo'),
>
> --- 
> --
> Call to checkpath from views.py
> --- 
> --
>
> [EMAIL PROTECTED]:/home/published/www/django/catalog/music# head -16
> views.py
> import django.shortcuts as shortcuts
> from django.template import RequestContext
> from django.http import HttpResponseRedirect
> from django.contrib.contenttypes.models import ContentType
> import models
> import music.demo
>
> def demo(request):
>         music.demo.checkpath()
>         return HttpResponseRedirect('http://google.com')
>
> --- 
> --
> And the error (viahttp://domain.tld/demo)
> --- 
> --
>
> Exception Type:         UnicodeEncodeError
> Exception Value:
>
> 'ascii' codec can't encode character u'\xf3' in position 35: ordinal
> not in range(128)
>
> Exception Location:     /usr/lib/python2.5/posixpath.py in exists, line
> 171
> Python Executable:      /usr/bin/python
> Python Version:         2.5.2
>
> Traceback:
> File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py"
> in get_response
>   86.                 response = callback(request, *callback_args,
> **callback_kwargs)
> File "/home/published/www/django/catalog/music/views.py" in demo
>   14.   music.demo.checkpath()
> File "/usr/lib/python2.5/posixpath.py" in exists
>   171.         st = os.stat(path)
>
> Exception Type: UnicodeEncodeError at /demo/
> Exception Value: 'ascii' codec can't encode character u'\xf3' in
> position 35: ordinal not in range(128)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django And os.path Behavior

[Graham Dumpleton]

On Dec 6, 10:07 am, dayvo <[EMAIL PROTECTED]> wrote:
> Good question.  That could affect the app if I were using relative
> path's or relying on the environment to locate files.  The path's I'm
> using in the app are stored are absolute paths.  They work correctly
> for path's that don't have unicode characters in them.  My Django app
> works correctly with %95+ of the data I'm using.  I'm just trying to
> resolve exceptions.  Those exceptions all have special characters in
> them.
>
> I'm starting to suspect apache and mod_python could have something to
> do with this.  Perhaps it's not a Django issue after all.

Should also be pointed out that even if you try and set locale in
Python application, when using mod_python it can be getting overridden
by another Apache module such as PHP scripts.

For this particular scenario, if you can't get rid of the PHP code,
you may have some success by running mod_wsgi and specifically using
its daemon mode to run your Django application in a separate daemon
process. Similarly, can also use FASTCGI/SCGI/AJP based solutions with
flup WSGI adapter.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Two different django version on the same server?

[Graham Dumpleton]

On Dec 8, 10:15 pm, Pablo Ruiz Múzquiz <[EMAIL PROTECTED]> wrote:
> Hmm. That is exactly what I meant with "No matter what I do with
> Apache's PythonPath".
> I have that same configuration you posted and /admin (and other stuff)
> won't work (most certainly because of the django version mismatch)
>
> The two errrors are "no module named urls" and "Viewdoesnotexist ..
> could not impot login. cannot import name validators"
>
> Thanks anyway, I'll keep trying!

Post your actual configuration then.

There are various subtleties in using mod_python and since you haven't
posted your actual configuration, you could be doing something obvious
wrong, but we cannot tell. Saying you have the same as other poster is
not enough as what they posted doesn't explain everything.

> Pablo
>
> On Dec 7, 8:08 pm, Adi Sieker <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > On 07.12.2008, at 16:56, Pablo Ruiz Múzquiz wrote:
>
> > > Hi all,
>
> > > I'm afraid I googled and googled with no success. Django official docs
> > > or my django book weren't of any help either.
>
> > > I've got a "legacy" django project which was developed using 0.97svn a
> > > year ago and a brand new SVN one, sharing the same server.
>
> > > Django 097 lives at /srv/whatever/django097/django while Django SVN at
> > > the usual site-packages location.
>
> > > No matter what I do with Apache's PythonPath, the virtualhost  
> > > referring
> > > to the old project will load  the SVN version and, thus, /admin and  
> > > some
> > > template handling will fail to load.
>
> > > Any clues? Thanks in advance,
>
> > I'm doing that on one of my domains with mod_python and it's working  
> > just fine.
> > Here is my relevant apache config.
>
> > 
> >          ServerName vhost1
> >      
> >          SetHandler python-program
> >          PythonHandler django.core.handlers.modpython
> >          SetEnv DJANGO_SETTINGS_MODULE project.settings
> >          PythonPath "['', \
> >                       '', \
> >                       ''] + sys.path"
> >      
> > 
>
> > in this VirtualHost  points to a pre newforms admin  
> > version of django and then a duplicate of this VirtualHost where the  
> >  points to a trunk version of django.
> > The _really_ important part is that sys.path comes after the version  
> > you want to use for this host.
> > Since sys.path will include your site.packages it'll find the trunk  
> > version first.
>
> > adi
>
> > --
> > Adi J. Sieker         mobile: +49 - 178 - 88 5 88 13
> > Freelance developer   skype:  adijsieker
> > SAP-Consultant        web:    http://www.sieker.info/profile
> >                        openbc:https://www.openbc.com/hp/
> > AdiJoerg_Sieker/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Development server crash with no error message

[Graham Dumpleton]

On Dec 9, 8:50 am, Andrew Fong <[EMAIL PROTECTED]> wrote:
> When I'm poking around in my Django app, my development server
> (manage.py runserver) will sometimes quit without raising an exception
> or leaving any messages. I am not tinkering around with the code or
> doing anything that would force a reload. It just decides to quit.
>
> I can check the last request I made before it crashed, but without any
> exceptions or errors, it's very hard to debug. Does anyone have any
> tips on getting some more useful output out of a crash?

What database adapter are you using? Is it a current version?

What other third party packages are you using which use a C extension
module to do stuff?

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: dynamic mod wsgi

[Graham Dumpleton]

On Dec 9, 6:53 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi, I'm converting to the excellent mod_wsgi and wondering if it's
> possible to make a single httpd virtual host/wsgi file to manage
> wildcard subdomains.
>
> Basically I have an app where i'm creating a new instance for each
> client and using subdomains. So client1.example.com and
> client2.example.com both point to the same app, but their own
> settings.py/django instance.
>
> So far so fine.  I've been happily converting to mod_wsgi daemons,
> creating virtual hosts and independent .wsgi files for each one. But
> now just wondering whether there is some way i can make this process
> dynamic so one virtual host/.wsgi file will take care of all these
> subdomains.
>
> I see the advice on the wsgi wiki to push domain sub-directories to
> different django instances, but i'd rather keep using the subdomains
> if possible.
>
> It looks possible to be able to parse information about the incoming
> request in the wsgi file and push it to different settings. But i'm
> not sure what this will do in terms of spawning processes etc, it
> looks a little dangerous, or maybe this will work. Any advice
> appreciated thanks!

Start by reading recent discussion:

  http://groups.google.com/group/django-users/browse_frm/thread/dfd352162db59ed7

I'll post more tomorrow if have time, have to do some things tonight
and then out most of the day tomorrow.

In short though, no support for dynamic transient daemon processes
yet, ie.,:

  http://code.google.com/p/modwsgi/issues/detail?id=22

so, can't get away from using WSGIDaemonProcess for each instance at
the moment.

One can use dynamic setting of WSGIApplicationGroup via a variable set
by mod_rewrite to select daemon process as well as set some name
relevant to settings file. WSGI application wrapper can then be used
to override DJANGO_SETTINGS_MODULE.

So, information is in that post, you just need to adapt it to your
situation. That is, use SERVER_NAME rather than REMOTE_USER from
authentication as basis of selecting daemon process group. You could
though skip the rewrite maps that allowed multiple levels of
indirection and made it further dynamic in nature.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: dynamic mod wsgi

[Graham Dumpleton]

On Dec 9, 8:05 pm, Ben Eliott <[EMAIL PROTECTED]> wrote:
> Graham,
> Thank you for coming back personally to such a lowly wsgi question! I  
> started reading your email and thinking the answer was 'no', then  
> ended up thinking 'definitely maybe'. I'll keep an eye out in case you  
> post more, otherwise i'll follow those links and your directions and  
> hope to report back with some progress.

I'll definitely try and say more later when get a chance.

Just do be aware of one thing. By using a single WSGI script file for
multiple sites, you loose the ability with mod_wsgi daemon mode to
touch the WSGI script file and cause a single site to be reloaded. One
would normally use this as a way of reloading a single site without
the need to restart the whole of Apache. When sharing the single WSGI
script file across sites, touching the WSGI script file will restart
all sites using that WSGI script file. If they share the code this may
actually be want you want, so not a problem, but worth mentioning.

In this arrangement, if you did want to reload one site, for example
because you change its settings file, you would need to use 'ps' to
identify process(es) in that daemon process group, based on what
display-name option was set to, and send all those processes in that
daemon process group a SIGINT using the 'kill' command. Alternatively,
you would need to setup a background thread which monitored something
like the distinct settings file for each site and have the process
itself send a SIGINT to itself. This would be a variation on
background reloader described in:

  
http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_Daemon_Processes

More later.

Graham

> Thanks and Regards,
> Ben
>
> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>
>
>
> > On Dec 9, 6:53 pm, "[EMAIL PROTECTED]"
> > <[EMAIL PROTECTED]> wrote:
> >> Hi, I'm converting to the excellent mod_wsgi and wondering if it's
> >> possible to make a single httpd virtual host/wsgi file to manage
> >> wildcard subdomains.
>
> >> Basically I have an app where i'm creating a new instance for each
> >> client and using subdomains. So client1.example.com and
> >> client2.example.com both point to the same app, but their own
> >> settings.py/django instance.
>
> >> So far so fine.  I've been happily converting to mod_wsgi daemons,
> >> creating virtual hosts and independent .wsgi files for each one. But
> >> now just wondering whether there is some way i can make this process
> >> dynamic so one virtual host/.wsgi file will take care of all these
> >> subdomains.
>
> >> I see the advice on the wsgi wiki to push domain sub-directories to
> >> different django instances, but i'd rather keep using the subdomains
> >> if possible.
>
> >> It looks possible to be able to parse information about the incoming
> >> request in the wsgi file and push it to different settings. But i'm
> >> not sure what this will do in terms of spawning processes etc, it
> >> looks a little dangerous, or maybe this will work. Any advice
> >> appreciated thanks!
>
> > Start by reading recent discussion:
>
> >  http://groups.google.com/group/django-users/browse_frm/thread/dfd3521...
>
> > I'll post more tomorrow if have time, have to do some things tonight
> > and then out most of the day tomorrow.
>
> > In short though, no support for dynamic transient daemon processes
> > yet, ie.,:
>
> >  http://code.google.com/p/modwsgi/issues/detail?id=22
>
> > so, can't get away from using WSGIDaemonProcess for each instance at
> > the moment.
>
> > One can use dynamic setting of WSGIApplicationGroup via a variable set
> > by mod_rewrite to select daemon process as well as set some name
> > relevant to settings file. WSGI application wrapper can then be used
> > to override DJANGO_SETTINGS_MODULE.
>
> > So, information is in that post, you just need to adapt it to your
> > situation. That is, use SERVER_NAME rather than REMOTE_USER from
> > authentication as basis of selecting daemon process group. You could
> > though skip the rewrite maps that allowed multiple levels of
> > indirection and made it further dynamic in nature.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Memory Footprint

[Graham Dumpleton]

On Dec 10, 3:10 am, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> Hello,
>
> First, I'm gonna say that I have DEBUG turned off, and it's not Django's
> fault.
>
> My Django sites seem to eat lots of memory. This is fine, and it isn't a
> huge deal except that I am using all of my VPS's memory plus swap. The
> real solution is to upgrade memory on the VPS, but I'm a poor college
> student so I want to reduce the memory footprint any way I can. I'm
> using mod_python and apache.
>
> I've seen discussion about mod_python specifically where it was
> suggested to set large variables to None when you're done with them.
> Django does most of the grunt work, and my views don't seem to load any
> very large variables. It seems like any variables instantiated by my
> views would go out of scope after the view function has returned, and
> the Python garbage collection will show up.
>
> I'm curious to know if anyone has ever tried to optimize their code to
> reduce the overall memory footprint. I haven't found any blog posts
> about it yet. I'm willing to resort to making my Django code as
> non-persistent as possible. My sites are all low traffic, so
> non-persistent processes plus memcached shouldn't be too terrible, even
> if I get slashdotted. I just need to squeeze out as much as I can out of
> the ram I have. Swapping makes the Django requests painfully slow.
>
> I am running memcached, which does seem to help my sites go faster, but
> it isn't helping the memory footprint go down (obviously.) I'm also
> considering switching to lighttpd. I've read it has a smaller footprint
> than apache. I've also read that mod_wsgi performs better than mod_python.
>
> Please let me know if you have any other ideas! I'm also curious to know
> if anyone thinks that one of the things I mention trying would help or
> hurt. Thanks!

Definitely stop using mod_python and use mod_wsgi instead. When using
mod_wsgi ensure you use daemon mode with single multithreaded process.
Set maximum-requests and inactivity-timeout for daemon process to
ensure that process is recycled to reclaim memory every so often or
when idle. Also ensure that Apache uses worker MPM and not prefork
MPM. Limit maximum number of Apache child processes to 2 with about 25
threads each. The default of one mod_wsgi daemon process with 15
threads would be adequate.

If you want to get even more aggressive about it, add nginx in front
of Apache as proxy and have nginx serve static files, also turn keep
alive off in Apache. This will make static file serving better and
ensure that Apache doesn't hold connections and unnecessarily use
memory doing that.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Development server crash with no error message

[Graham Dumpleton]

Forgot to ask, what platform?

On Dec 11, 10:05 am, Andrew Fong <[EMAIL PROTECTED]> wrote:
> I'm using MySQLdb, cmemcache, PIL, and the django.contrib.gis stuff.
>
> On Dec 8, 2:58 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Dec 9, 8:50 am, Andrew Fong <[EMAIL PROTECTED]> wrote:
>
> > > When I'm poking around in my Django app, my development server
> > > (manage.py runserver) will sometimes quit without raising an exception
> > > or leaving any messages. I am not tinkering around with the code or
> > > doing anything that would force a reload. It just decides to quit.
>
> > > I can check the last request I made before it crashed, but without any
> > > exceptions or errors, it's very hard to debug. Does anyone have any
> > > tips on getting some more useful output out of acrash?
>
> > What database adapter are you using? Is it a current version?
>
> > What other third party packages are you using which use a C extension
> > module to do stuff?
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Development server crash with no error message

[Graham Dumpleton]

On Dec 11, 8:06 pm, Tobias Kräntzer
<[EMAIL PROTECTED]> wrote:
> Am Donnerstag, den 11.12.2008, 00:05 +0100 schrieb Andrew Fong:
>
> > I'm using MySQLdb, cmemcache, PIL, and the django.contrib.gis stuff.
>
> Hi, we had a similar problem. It turns out, that in our case it was a
> multithreading issue with geos/gdal. For instance using apache2 with
> wsgi and and allowing only one thread per process was helpful.

The development server is single threaded though, so threading
shouldn't be an issue.

A problem recently highlighted with the geos stuff though is that it
likes to crash if using it on 64 bit Linux architecture.  That was
part of asking what platform, although forgot to ask about whether 32
bit or 64 bit version of Python.

Recent threads about this at:

  http://groups.google.com/group/django-users/browse_frm/thread/e337057e9df9bb9
  http://groups.google.com/group/modwsgi/browse_frm/thread/a488d2551c4c7df0

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: setting the proper file permisions chmod

[Graham Dumpleton]

On Dec 12, 8:32 am, garagefan  wrote:
> I figured out my issue with the "access denied, suspicious operation"
> bull...
>
> apparently the only way the admin side of my site can upload an image
> to a directory is by having "other" set to have full rwx set... ie
> chmod **7 I'm not so sure this is a good thing to keep set as that
> would give everyone, logged in or other, access to overwriting data,
> adding stuff, etc... right?

Who owns the files once uploaded?

Whoever that is should be the owner of the directory. Sounds like you
are running under Apache and don't understand that your code runs as
the Apache user.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: setting the proper file permisions chmod

[Graham Dumpleton]

On Dec 12, 8:52 am, garagefan  wrote:
> this is my first time working this closely to the server for a live
> environment :)
>
> "apache" appears as owner of the file once uploaded. is there a way to
> set the default on this to be another user?

Only by using Apache/mod_wsgi (not mod_python) and specifically using
mod_wsgi daemon mode, with a distinct user defined for the daemon
process and thus your Django application to run as.

Graham

> On Dec 11, 4:45 pm, Graham Dumpleton 
> wrote:
>
> > On Dec 12, 8:32 am, garagefan  wrote:
>
> > > I figured out my issue with the "access denied, suspicious operation"
> > > bull...
>
> > > apparently the only way the admin side of my site can upload an image
> > > to a directory is by having "other" set to have full rwx set... ie
> > > chmod **7 I'm not so sure this is a good thing to keep set as that
> > > would give everyone, logged in or other, access to overwriting data,
> > > adding stuff, etc... right?
>
> > Who owns the files once uploaded?
>
> > Whoever that is should be the owner of the directory. Sounds like you
> > are running under Apache and don't understand that your code runs as
> > the Apache user.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: setting the proper file permisions chmod

[Graham Dumpleton]

On Dec 12, 9:07 am, garagefan  wrote:
> which would actually result in keeping my server more secure... i
> would assume leaving other with rwx would be paramount to keeping my
> front door wide open?

The risk is more from users who have shell accounts on the same
system, or have web applications running as different user. Those
users would be able to modify stuff in that directory even though they
aren't owner.

It doesn't change the risk in respect of other web application code
running under mod_python or PHP which also runs as Apache user. Such
code because runs as Apache user would be able to write to the
directory even if owned by Apache user and not o+rwx.

> I'll look into mod_wsgi... but i can't imagine that every person
> running mod_python and working with file uploads hasn't had to combat
> this little issue.

Based on posts one sees, a lot of people just make it o+rwx and leave
it at that.

> is there really a safety concern?

If you are fully in control of the system and no other users on it, it
is not good, but not disastrous.

> or is there another way around this?

Make the user owned by Apache user instead and don't have o+rwx.

I am biased, but arguable that mod_wsgi is a better overall choice
these days than mod_python anyway and with mod_python fading away to a
degree, better long term choice.

Graham

> On Dec 11, 4:59 pm, Graham Dumpleton 
> wrote:
>
> > On Dec 12, 8:52 am, garagefan  wrote:
>
> > > this is my first time working this closely to the server for a live
> > > environment :)
>
> > > "apache" appears as owner of the file once uploaded. is there a way to
> > > set the default on this to be another user?
>
> > Only by using Apache/mod_wsgi (not mod_python) and specifically using
> > mod_wsgi daemon mode, with a distinct user defined for the daemon
> > process and thus your Django application to run as.
>
> > Graham
>
> > > On Dec 11, 4:45 pm, Graham Dumpleton 
> > > wrote:
>
> > > > On Dec 12, 8:32 am, garagefan  wrote:
>
> > > > > I figured out my issue with the "access denied, suspicious operation"
> > > > > bull...
>
> > > > > apparently the only way the admin side of my site can upload an image
> > > > > to a directory is by having "other" set to have full rwx set... ie
> > > > > chmod **7 I'm not so sure this is a good thing to keep set as that
> > > > > would give everyone, logged in or other, access to overwriting data,
> > > > > adding stuff, etc... right?
>
> > > > Who owns the files once uploaded?
>
> > > > Whoever that is should be the owner of the directory. Sounds like you
> > > > are running under Apache and don't understand that your code runs as
> > > > the Apache user.
>
> > > > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: apache+mod_wsgi+django problem with objects which stay in memory

[Graham Dumpleton]

On Dec 13, 10:18 am, vytautas  wrote:
> [Fri Dec 12 13:27:07 2008] [error] Model read finished. Duration
> 1.2693259716
> [Fri Dec 12 13:27:07 2008] [error] Model validity check skipped
> [Fri Dec 12 13:27:09 2008] [error] Model read finished. Duration
> 1.23547005653
> [Fri Dec 12 13:27:09 2008] [error] Model validity check skipped
> [Fri Dec 12 13:27:18 2008] [error] Model read finished. Duration
> 1.28153181076
> [Fri Dec 12 13:27:18 2008] [error] Model validity check skipped
>
> here we have one object, every time that object is recreated, and here
> is a reason why we lost a data.
> program working with scheme of my program is samething like that:
>
> step1->step2->step3->result
>
> and in every step I update the data, and from this data I get the
> info wich is necassary for  future, but when apache became the request
> from server, then the object, in which I save data, are recreated and
> my data is lost:/
> my object is dictonarie.
>
> my english is broken, sorry =]

Which is why am not 100 percent what you mean.

Anyway, read:

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

Apache on UNIX is a multi process web server. If you are making
modifications to objects cached in memory in a request handler and
then expecting you to see changes for all subsequent requests, it will
not work, as subsequent requests could be against a different process.
Apache and/or mod_wsgi may also recycle processes depending on
configuration and so if you don't have an external persistence
mechanism such that data survives across process lifetime, also will
not work.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How to embed django into a custom web server

[Graham Dumpleton]

On Dec 13, 12:05 pm, Jim  wrote:
> Hi,
>
> I'm experimenting with building a web server with embedded python and
> I'd like to setup and include Django.   The server works by loading a
> main python script into memory at startup and then script registers a
> callback routine to handle incoming messages.  The script looks
> something like this:
>
> import MyWebServer
>
> # Initialization code
>
> def my_callback(connection_name, request, size):
>         MyWebServer.sendReply(connection_name, 'hello world', 11)
>
> MyWebServer.set_callback(my_callback)
>
> First of all, does this seem like a reasonable approach?  Second, what
> do I need to do to setup the Django environment using this
> architecture?

Make your web server support WSGI API standard and then you can just
use Django WSGI interface. The WSGI specification is documented at:

  http://www.python.org/dev/peps/pep-0333/

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How to embed django into a custom web server

[Graham Dumpleton]

Jim wrote:
> Hi Graham,
>
> Thanks for your response.  I've taken a quick look over the WSGI spec
> and it looks good.  I have a couple questions though and I apologize
> if they've already been answered in the forum or in the Django
> documentation 
>
> 1)   Based on your suggestion to use WSGI, I'm assuming Django already
> implements WSGI, right?

Yes. See documentation.

  http://code.djangoproject.com/wiki/ServerArrangements

There are links to various places which describe setting it up to work
with WSGI capable hosting mechanisms.

> 2)   If I implement WSGI, what is the best way to test compliancy?  Is
> there a testing framework?  If not, do you think that using a
> compliant framework like Django would be sufficient?

For a WSGI validator, see:

  http://docs.python.org/library/wsgiref.html#module-wsgiref.validate

Trying it on a large framework is always a good test, but start with
some simple hello world applications first.

Also look at implementation of:

  http://docs.python.org/library/wsgiref.html#module-wsgiref.simple_server

There is also the Paste WSGI server and CherryPy WSGI server you can
look at.

> 3)   My web server has an asynchronous, persistent socket
> architecture.  Do you see any problems between this architecture and
> WSGI?

Yes. WSGI and Python web applications in general are not suitable for
use on an asynchronous web server. This is because when a request is
being handled the server can't be doing anything else. Thus, if you
expect concurrency within a single process, you would need to use
threads. Other option is to run multiple processes to handle requests.

Why are you developing your own web server in the first place when
there are already so many options available?

Graham

> Thanks!
>
>
> On Dec 12, 6:08�pm, Graham Dumpleton 
> wrote:
> > On Dec 13, 12:05�pm, Jim  wrote:
> >
> >
> >
> > > Hi,
> >
> > > I'm experimenting with building a web server with embedded python and
> > > I'd like to setup and include Django. � The server works by loading a
> > > main python script into memory at startup and then script registers a
> > > callback routine to handle incoming messages. �The script looks
> > > something like this:
> >
> > > import MyWebServer
> >
> > > # Initialization code
> >
> > > def my_callback(connection_name, request, size):
> > > � � � � MyWebServer.sendReply(connection_name, 'hello world', 11)
> >
> > > MyWebServer.set_callback(my_callback)
> >
> > > First of all, does this seem like a reasonable approach? �Second, what
> > > do I need to do to setup the Django environment using this
> > > architecture?
> >
> > Make your web server support WSGI API standard and then you can just
> > use Django WSGI interface. The WSGI specification is documented at:
> >
> > �http://www.python.org/dev/peps/pep-0333/
> >
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How to embed django into a custom web server

[Graham Dumpleton]

On Dec 14, 5:29 pm, Jim  wrote:
> Thanks for the good info.  Let me explain why I would want to develop
> my own web server... I've got a real time, asynchronous server that
> uses a proprietary binary protocol to monitor remote systems using a
> push model, and I'd like to expose the incoming data over HTTP using a
> web app, also using a push model.  The existing server is multi-
> threaded and already uses embedded python so I thought I'd look into
> implementing a limited web server and run the web server in the same
> process as the real-time server.  The server is a windows based server
> that is built with WIN32 IO completion ports.
>
> So I'm concerned about the multi-threading issues you've brought up
> here and I'm worried that I don't fully understand all of the pitfalls
> involved in integrating Django using WSGI.  If I use standard
> synchronization methods such as mutexes, critical sections and
> reentrant code, are there any fundamental reasons why I can't make
> this work?

If using Django 1.0, as long as your code uses thread synchronisation
mechanism as necessary, then should be okay. The only example I have
seen illustrating ongoing threading concerns with Django 1.0 relates
to a use case lying outside of the normal in respect of templates.
That is, if you use Django in the standard documented ways then
guidance seems to be that it should have no problems.

Graham

> Also, I *am* looking at using an available web server to accomplish
> this task, but I wanted to look into this first.
>
> On Dec 13, 3:40 pm, Graham Dumpleton 
> wrote:
>
> > Jim wrote:
> > > Hi Graham,
>
> > > Thanks for your response.  I've taken a quick look over the WSGI spec
> > > and it looks good.  I have a couple questions though and I apologize
> > > if they've already been answered in the forum or in the Django
> > > documentation 
>
> > > 1)   Based on your suggestion to use WSGI, I'm assuming Django already
> > > implements WSGI, right?
>
> > Yes. See documentation.
>
> >  http://code.djangoproject.com/wiki/ServerArrangements
>
> > There are links to various places which describe setting it up to work
> > with WSGI capable hosting mechanisms.
>
> > > 2)   If I implement WSGI, what is the best way to test compliancy?  Is
> > > there a testing framework?  If not, do you think that using a
> > > compliant framework like Django would be sufficient?
>
> > For a WSGI validator, see:
>
> >  http://docs.python.org/library/wsgiref.html#module-wsgiref.validate
>
> > Trying it on a large framework is always a good test, but start with
> > some simple hello world applications first.
>
> > Also look at implementation of:
>
> >  http://docs.python.org/library/wsgiref.html#module-wsgiref.simple_server
>
> > There is also the Paste WSGI server and CherryPy WSGI server you can
> > look at.
>
> > > 3)   My web server has an asynchronous, persistent socket
> > > architecture.  Do you see any problems between this architecture and
> > > WSGI?
>
> > Yes. WSGI and Python web applications in general are not suitable for
> > use on an asynchronous web server. This is because when a request is
> > being handled the server can't be doing anything else. Thus, if you
> > expect concurrency within a single process, you would need to use
> > threads. Other option is to run multiple processes to handle requests.
>
> > Why are you developing your own web server in the first place when
> > there are already so many options available?
>
> > Graham
>
> > > Thanks!
>
> > > On Dec 12, 6:08 pm, Graham Dumpleton 
> > > wrote:
> > > > On Dec 13, 12:05 pm, Jim  wrote:
>
> > > > > Hi,
>
> > > > > I'm experimenting with building a web server with embedded python and
> > > > > I'd like to setup and include Django. The server works by loading a
> > > > > main python script into memory at startup and then script registers a
> > > > > callback routine to handle incoming messages. The script looks
> > > > > something like this:
>
> > > > > import MyWebServer
>
> > > > > # Initialization code
>
> > > > > def my_callback(connection_name, request, size):
> > > > > MyWebServer.sendReply(connection_name, 'hello world', 11)
>
> > > > > MyWebServer.set_callback(my_callback)
>
> > > > > First of all, does this seem like a reasonable approach? Second, what
> > > > > do I need to do to setup the Django environment using this
> > > > > architecture?
>
> > > > Make your web server support WSGI API standard and then you can just
> > > > use Django WSGI interface. The WSGI specification is documented at:
>
> > > >http://www.python.org/dev/peps/pep-0333/
>
> > > > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: django and favicon.ico problem

[Graham Dumpleton]

On Dec 16, 9:45 pm, architecture  wrote:
> i was working with php and always i put the favicon.ico in the root of
> the website but now the problem with django occurs
> now i'm working with django and i have a problem now
> i used
> 1. static.serve
> 2. .htaccess
> 3.redirect_to
>
> but none of them works have you any idea for using favicon.ico in the
> website

How are you hosting Django? Are you using mod_python, mod_wsgi or
fastcgi? What you use dictates what you need to do.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: django and favicon.ico problem

[Graham Dumpleton]

On Dec 18, 10:12 am, felix  wrote:
> you can put it directly in your http-vhosts.conf file
>
> 
>              ServerName crucial-systems.com
>              DocumentRoot /home/crucial/crucial-stack/crucialwww
> ... etc...
>
> Alias /favicon.ico "/home/crucial/crucial-stack/crucialwww/favicon.ico"
>
> ...
>
> WSGIScriptAlias / /home/crucial/crucial-stack/crucial/crucial.wsgi
>
> note that even though the document root appears to be mapped to the
> crucialwww directory, in practice the WSGIScriptAlias / means that
> everything is directed to django.
>
> all image and css directories I also use Alias (before the WSGIScriptAlias)
> to map those to the correct directories.
>
> I used to do a lot of symlinks and juggling of my directories.  I'm
> preferring this method now as its much easier to change and move things.

As documented for mod_wsgi in:

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

This is why I asked how Django instance was originally being hosted.

FWIW, if using mod_python you can from memory still use Alias, but
also need to specify a Location directive for that URL path and
SetHandler to None. If you don't have the latter bit the request still
gets sucked into mod_python rather than being served as a static file.
YMMV vary on getting this to work though because mod_python doesn't
interleave properly with file based resource directives such as Alias
where as mod_wsgi does.

Graham

> -fx
>
> On Wed, Dec 17, 2008 at 6:31 PM, 3lancer.eu  wrote:
>
> > HI,
>
> > > I haven't bothered to try fixing it yet, but I wonder if a redirect
> > > from /favicon.ico to /media/images/favicon.ico might solve that issue.
> > >  If I get a chance I'll test it today, see if works.  Has anyone else
> > > experimented with this?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Limiting HTTP request size

[Graham Dumpleton]

On Dec 20, 12:48 am, Andreas Gustafsson  wrote:
> What's the recommended way to protect a Django application against
> denial of service via huge file uploads or  huge POST requests in
> general?  If I set the LimitRequestBody option in the Apache
> configuration file, mod_python throws an ominous-looking exception
> when the limit is exceeded:
>
>   SystemError: ../Objects/stringobject.c:4089: bad argument to
> internal function
>
> I assume that's a symptom of the bug described in   issues.apache.org/jira/browse/MODPYTHON-240>.

Wrong issue, the issue that error relates to is:

  http://issues.apache.org/jira/browse/MODPYTHON-234

which is in turn related to:

  http://issues.apache.org/jira/browse/MODPYTHON-222

It hasn't got anything to do with LimitRequestBody. That this but
exists in current versions of mod_python and can crop up at random
times is a good reason why you don't want to be using mod_python.

Instead of mod_python use mod_wsgi and you will not get this problem.
Also, in mod_wsgi the LimitRequestBody actually works like one would
expect it to work where as in mod_python it doesn't work at all.

The custom file upload handler mentioned by someone else will not help
at all with the mod_python bug and you could still get that error when
using it.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Limiting HTTP request size

[Graham Dumpleton]

On Dec 20, 9:19 pm, Andreas Gustafsson  wrote:
> On Dec 19, 11:45 pm, Graham Dumpleton 
> wrote:
>
> > It hasn't got anything to do with LimitRequestBody. That this but
> > exists in current versions of mod_python and can crop up at random
> > times is a good reason why you don't want to be using mod_python.
>
> I've never seen it happen at random, but it happens consistently every
> time
> the LimitRequestBody limit is exceeded.

It may be possible that LimitRequestBody is a more reliable way of
triggering the problem in some situations. The bad argument error has
been reported on mod_python list a number of times, some not linked to
LimitRequestBody at all. See for example:

  http://www.modpython.org/pipermail/mod_python/2007-June/023795.html

Note that although it was random, it rarely happened.

The way I phrased things was perhaps poor, in that the issue is not
connected with just LimitRequestBody, but is a much deeper problem in
how mod_python code is written as explained in:

  http://issues.apache.org/jira/browse/MODPYTHON-234

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Admin formatting

[Graham Dumpleton]

On Dec 21, 12:54 pm, Jeff Anderson  wrote:
> MS wrote:
> > I am learning Django under Windows Vista.
>
> > I am using Python 2.5 and Wamp5. The document root for Apache is set
> > to c:/wamp/www/
>
> > I have a project under c:/wamp/www/DjangoProjects/mysite
>
> Don't do that. You don't need your python code in the document root, and
> it's a bad idea to make it available to the world.> If I run it using the 
> Django built-in server it works fine. If I run
> > it using Apache and wsgi-python the application works fine but the
> > admin does not look the same, I suspect it does not make use of the
> > admin css files.
>
> Correct. You have to tell apache that the location of the admin media
> should be handled with the default handler, and then make an alias for
> that location to point to the correct location on disk. This is in the
> docs:http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#id1

If when they say 'wsgi-python' they mean Apache/mod_wsgi, then the
information on the mod_python documentation will not be of use.

For mod_wsgi see:

  http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
  
http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Hosting_Of_Static_Files

When using mod_wsgi you do not need to do the Location/SetHandler None
hack that is required in mod_python to have Alias directive honoured.
In mod_wsgi for case of static media at sub URL of Django site, just
use Alias directives and they will correctly take precedence.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: dynamic mod wsgi

[Graham Dumpleton]

On Dec 22, 9:44 pm, Ben Eliott  wrote:
> Hi Graham,
> I've finally managed to get back to the wildcard subdomains & mod_wsgi  
> today. Unfortunately the discussion thread you mentioned has  
> disappeared and after a few hours i still seem to be doing a good job  
> of getting nowhere.

I can still access thread with no problems.

> Although you mentioned using mod_rewrite to get hold of the url  
> variable, it looks like the %{SERVER} variable in mod_wsgi might take  
> care of this already?
>
> My main issue seems to be to accessing the %{SERVER} (or relevant  
> mod_rewrite) variable in the .wsgi script, to specify a particular  
> settings file.
>
> Within a VirtualHost i have:
> WSGIApplicationGroup %{SERVER}
> WSGIDaemonProcess %{SERVER} ...threads etc
> WSGIProcessGroup %{SERVER}

The %{SERVER} value is only magic when used with WSGIApplicationGroup
directive.

> So this is probably hoplessly wrong also, but if you can give some  
> further pointers that would be most kind.

Can you post a more complete example of your Apache configuration
showing what you are trying to achieve.

Sorry I didn't get back to you last time, it was a hectic few weeks.
Things have settled down somewhat now, so I'll go back over your
original post and work out again what it is you were trying to do.

Graham

> Thanks and Regards,
> Ben
>
> On 9 Dec 2008, at 10:18, Graham Dumpleton wrote:
>
>
>
> > On Dec 9, 8:05 pm, Ben Eliott  wrote:
> >> Graham,
> >> Thank you for coming back personally to such a lowly wsgi question! I
> >> started reading your email and thinking the answer was 'no', then
> >> ended up thinking 'definitely maybe'. I'll keep an eye out in case  
> >> you
> >> post more, otherwise i'll follow those links and your directions and
> >> hope to report back with some progress.
>
> > I'll definitely try and say more later when get a chance.
>
> > Just do be aware of one thing. By using a single WSGI script file for
> > multiple sites, you loose the ability with mod_wsgi daemon mode to
> > touch the WSGI script file and cause a single site to be reloaded. One
> > would normally use this as a way of reloading a single site without
> > the need to restart the whole of Apache. When sharing the single WSGI
> > script file across sites, touching the WSGI script file will restart
> > all sites using that WSGI script file. If they share the code this may
> > actually be want you want, so not a problem, but worth mentioning.
>
> > In this arrangement, if you did want to reload one site, for example
> > because you change its settings file, you would need to use 'ps' to
> > identify process(es) in that daemon process group, based on what
> > display-name option was set to, and send all those processes in that
> > daemon process group a SIGINT using the 'kill' command. Alternatively,
> > you would need to setup a background thread which monitored something
> > like the distinct settings file for each site and have the process
> > itself send a SIGINT to itself. This would be a variation on
> > background reloader described in:
>
> >  http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_...
>
> > More later.
>
> > Graham
>
> >> Thanks and Regards,
> >> Ben
>
> >> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>
> >>> On Dec 9, 6:53 pm, "ben.dja...@googlemail.com"
> >>>  wrote:
> >>>> Hi, I'm converting to the excellent mod_wsgi and wondering if it's
> >>>> possible to make a single httpd virtual host/wsgi file to manage
> >>>> wildcard subdomains.
>
> >>>> Basically I have an app where i'm creating a new instance for each
> >>>> client and using subdomains. So client1.example.com and
> >>>> client2.example.com both point to the same app, but their own
> >>>> settings.py/django instance.
>
> >>>> So far so fine.  I've been happily converting to mod_wsgi daemons,
> >>>> creating virtual hosts and independent .wsgi files for each one.  
> >>>> But
> >>>> now just wondering whether there is some way i can make this  
> >>>> process
> >>>> dynamic so one virtual host/.wsgi file will take care of all these
> >>>> subdomains.
>
> >>>> I see the advice on the wsgi wiki to push domain sub-directories to
> >>>> different django instances, but i'd rather keep using the  
> >>>> subdomains
> &g

Re: dynamic mod wsgi

[Graham Dumpleton]

Have some further questions about what you want to do.

Do you want a separate daemon process for each distinct Django site,
or are you happy with one really fat process which contains each
Django site in a separate sub interpreter of that process?

How much memory does each Django site instance take up?

How many different site instances would you have?

Are all the site instances distinguishable by server name alone?

Graham

On Dec 23, 9:00 am, Graham Dumpleton 
wrote:
> On Dec 22, 9:44 pm, Ben Eliott  wrote:
>
> > Hi Graham,
> > I've finally managed to get back to the wildcard subdomains & mod_wsgi  
> > today. Unfortunately the discussion thread you mentioned has  
> > disappeared and after a few hours i still seem to be doing a good job  
> > of getting nowhere.
>
> I can still access thread with no problems.
>
> > Although you mentioned using mod_rewrite to get hold of the url  
> > variable, it looks like the %{SERVER} variable in mod_wsgi might take  
> > care of this already?
>
> > My main issue seems to be to accessing the %{SERVER} (or relevant  
> > mod_rewrite) variable in the .wsgi script, to specify a particular  
> > settings file.
>
> > Within a VirtualHost i have:
> > WSGIApplicationGroup %{SERVER}
> > WSGIDaemonProcess %{SERVER} ...threads etc
> > WSGIProcessGroup %{SERVER}
>
> The %{SERVER} value is only magic when used with WSGIApplicationGroup
> directive.
>
> > So this is probably hoplessly wrong also, but if you can give some  
> > further pointers that would be most kind.
>
> Can you post a more complete example of your Apache configuration
> showing what you are trying to achieve.
>
> Sorry I didn't get back to you last time, it was a hectic few weeks.
> Things have settled down somewhat now, so I'll go back over your
> original post and work out again what it is you were trying to do.
>
> Graham
>
> > Thanks and Regards,
> > Ben
>
> > On 9 Dec 2008, at 10:18, Graham Dumpleton wrote:
>
> > > On Dec 9, 8:05 pm, Ben Eliott  wrote:
> > >> Graham,
> > >> Thank you for coming back personally to such a lowly wsgi question! I
> > >> started reading your email and thinking the answer was 'no', then
> > >> ended up thinking 'definitely maybe'. I'll keep an eye out in case  
> > >> you
> > >> post more, otherwise i'll follow those links and your directions and
> > >> hope to report back with some progress.
>
> > > I'll definitely try and say more later when get a chance.
>
> > > Just do be aware of one thing. By using a single WSGI script file for
> > > multiple sites, you loose the ability with mod_wsgi daemon mode to
> > > touch the WSGI script file and cause a single site to be reloaded. One
> > > would normally use this as a way of reloading a single site without
> > > the need to restart the whole of Apache. When sharing the single WSGI
> > > script file across sites, touching the WSGI script file will restart
> > > all sites using that WSGI script file. If they share the code this may
> > > actually be want you want, so not a problem, but worth mentioning.
>
> > > In this arrangement, if you did want to reload one site, for example
> > > because you change its settings file, you would need to use 'ps' to
> > > identify process(es) in that daemon process group, based on what
> > > display-name option was set to, and send all those processes in that
> > > daemon process group a SIGINT using the 'kill' command. Alternatively,
> > > you would need to setup a background thread which monitored something
> > > like the distinct settings file for each site and have the process
> > > itself send a SIGINT to itself. This would be a variation on
> > > background reloader described in:
>
> > >  http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Restarting_...
>
> > > More later.
>
> > > Graham
>
> > >> Thanks and Regards,
> > >> Ben
>
> > >> On 9 Dec 2008, at 08:23, Graham Dumpleton wrote:
>
> > >>> On Dec 9, 6:53 pm, "ben.dja...@googlemail.com"
> > >>>  wrote:
> > >>>> Hi, I'm converting to the excellent mod_wsgi and wondering if it's
> > >>>> possible to make a single httpd virtual host/wsgi file to manage
> > >>>> wildcard subdomains.
>
> > >>>> Basically I have an app where i'm creating a new instance for each
> > >>>> client and using subdo

Re: Configuring mod_python and Djano on Apache2

[Graham Dumpleton]

On Dec 31, 8:41 am, tosh  wrote:
> it depends on the url structure of your site really
>
> if you don't need your django site to load from the root you could
> just do something like
>
> 
>     SetHandler None
> 

Don't need SetHandler None at root needed if mounting at sub URL. In
fact this may cause other things to stop working.

Graham

> 
>     SetHandler python-program
>     PythonHandler django.core.handlers.modpython
>     SetEnv DJANGO_SETTINGS_MODULE Test.settings
>     PythonPath "['/home/YOUR_USERNAME/django_projects'] + sys.path"
> 
>
> On Dec 29, 2:23 pm, webhopper  wrote:
>
> > Hello,
>
> > I am a new fan of Django. Enjoying the learning process. The tutorial
> > documentation is great. Where I am stuck is on how to move my
> > development project onto my public website which sits on Ubuntu 8.10.
>
> > I was able to configure mod_python and tell it where to find my Django
> > project and templates. Found this 
> > bloghttp://www.jeffbaier.com/2007/07/26/installing-django-on-an-ubuntu-li...
> > useful.
>
> > This is what I had in apache2.conf:
>
> > 
> >     SetHandler python-program
> >     PythonHandler django.core.handlers.modpython
> >     SetEnv DJANGO_SETTINGS_MODULE Test.settings
> >     PythonPath "['/home/YOUR_USERNAME/django_projects'] + sys.path"
> > 
>
> > This works and I can see my Django site working. But here is  the
> > problem. I have other stuff like MovableType running on same web
> > server, which I do not want to disrupt.
>
> > The way Apache gets configured if I follow instructions above seems to
> > be that EVERYTHING is seen by mon_python first and I am being required
> > to list all context roots that should NOT be handled by mod_python.
> > See for example below:
>
> > 
> >     SetHandler None
> > 
>
> > This is painful and does not scake as I consolidate more on same
> > server.
>
> > Is there a way top configure mod_python better?
>
> > Thanks in advance for any advice
>
> > Best
>
> > Sreeram
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Slow application performance...

[Graham Dumpleton]

On Jan 2, 2:17 pm, Jeff Anderson  wrote:
> vernon wrote:
> > Hi everyone,
>
> > When I was first experimenting with Django on my local machine with
> > the bundled webserver, one of the things I was really impressed by was
> > the speed — everything was instantaneous. Listing things in the DB,
> > modifying and saving changes etc...
>
> > I finally decided to deploy the beginnings on my app on my remote
> > server using the Apache/mod_python setup described in the docs.
>
> The mod_python setup is a memory hog. It loads a copy of your code into
> memory for each persistent apache process. I'm guessing you are using
> all your available memory on your slice, and swapping. I had this same
> problem. I posted about it to this group a couple weeks ago. Basically,
> switch to mod_wsgi in daemon mode. It'll reduce your memory usage, and
> increase the speed of the site. Search the archive for more details.

A mod_python setup need not be a memory hog if you are using most up
to date mod_python and it is installed and configured correctly,
especially ensuring it uses the Python shared library and that Python
isn't statically linked into it.

People complaining about slow performance of mod_python and it being a
memory hog quite often also don't understand the process/threading
model of Apache dictated by the specific MPM they choose. In short,
Apache is a multiprocess web server and that has a number of
implications.

The first is that each child process has a full copy of application,
thus if you use prefork MPM, possibly because of needing to also run
PHP, then you can end up with a large number of application instances.
If you were to use worker MPM you will find a lot less child processes
are used and so a lot less memory as each child process will use
multithreading as well to handle parallel requests.

The second, and which can account for slow requests, is the startup
cost of loading and initialising Django for each process. This is not
done when processes are first created but when first request arrives
for application. Thus first group of concurrent requests against a
child process will appear slow.

All these factors also apply when using mod_wsgi. The only differences
with mod_wsgi is that it has a smaller base memory footprint and that
one can use daemon mode to help you around the memory usage issues
from running embedded mode with prefork MPM. So, through incorrect
configuration you can create just as a big a problem with mod_wsgi as
you can with mod_python.

If you can expand on exactly what you believe is causing mod_python to
be a memory hog, that would perhaps be useful in identifying why you
were having the issues you may have been having and suggestions can be
made on how you should have configured your system.

Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: python.conf question, multiple sites on same server?

[Graham Dumpleton]

On Jan 4, 12:17 pm, garagefan  wrote:
> I've read the documentation, and it doesn't seem clear enough, or
> provide a fully working example?
>
> i've copied what i have in my python.conf file, keep in mind that i
> have removed site specific names and have made them generic
>
> NameVirtualHost *:80
>
> 
>     ServerNamewww.website.net
>
>     

Presumably you mean /mysite here and not the root of the web server.
This needs to match what you have set django.root to.

Graham

>         SetHandler python-program
>         PythonHandler django.core.handlers.modpython
>         SetEnv DJANGO_SETTINGS_MODULE mysite.settings
>         PythonOption django.root /mysite
>         PythonDebug On
>         PythonPath "['/home/html'] + sys.path"
>     
>     
>         SetHandler None
>     
>     
>         SetHandler None
>     
> 
>
> i get no python errors, however when i go to the site i receive
> nothing. these locations worked previous to attempting to set up a
> virtual host. i assume *:80 is the port? in which case, i suppose it
> may be possible that the port is incorrect? in which case, i'm unsure
> as to where to check this... i assume under the apache conf file?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: python.conf question, multiple sites on same server?

[Graham Dumpleton]

BTW, with mod_python, if trying to host multiple Django sites inside
of same VirtualHost, you must set PythonInterpreter directive
differently for each.

You really need to provide a more complete example showing all the
sites and how they site with respect to each other and the VirtualHost
in the configuration.

Graham

On Jan 4, 12:47 pm, Graham Dumpleton 
wrote:
> On Jan 4, 12:17 pm, garagefan  wrote:
>
> > I've read the documentation, and it doesn't seem clear enough, or
> > provide a fully working example?
>
> > i've copied what i have in my python.conf file, keep in mind that i
> > have removed site specific names and have made them generic
>
> > NameVirtualHost *:80
>
> > 
> >     ServerNamewww.website.net
>
> >     
>
> Presumably you mean /mysite here and not the root of the web server.
> This needs to match what you have set django.root to.
>
> Graham
>
> >         SetHandler python-program
> >         PythonHandler django.core.handlers.modpython
> >         SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> >         PythonOption django.root /mysite
> >         PythonDebug On
> >         PythonPath "['/home/html'] + sys.path"
> >     
> >     
> >         SetHandler None
> >     
> >     
> >         SetHandler None
> >     
> > 
>
> > i get no python errors, however when i go to the site i receive
> > nothing. these locations worked previous to attempting to set up a
> > virtual host. i assume *:80 is the port? in which case, i suppose it
> > may be possible that the port is incorrect? in which case, i'm unsure
> > as to where to check this... i assume under the apache conf file?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: python.conf question, multiple sites on same server?

[Graham Dumpleton]

On Jan 4, 12:53 pm, garagefan  wrote:
> no, as then i would need to use, for example...www.website.net/mysite/*
> instead ofwww.website.net/*for the various apps.

If you are mounting it at root of web site, you should not be setting
django.root with PythonOption directive for a start. You only need set
django.root when mounted at a sub url. That you had set it gave the
impression you wanted it mounted at a sub url.

> as i said the locations worked perfectly before attempting to create
> the virtual host. right now i need to have this virtual host point to
> the correct website on my server.

As I said, you need to provide more complete configuration which shows
both Django sites and how you have set them up.

If your VirtualHost containers are the same except for ServerName in
each, then show that by providing the configurations for both, or be
clear about that and state it rather than us having to assume what it
all looks like.

> would i change server name to be an ip address? as each website on my
> server has a unique address, while having the same port? since 80 is
> the open port for apache

Show configurations for both VirtualHost's and then we may be able to
answer.

Graham

> On Jan 3, 8:47 pm, Graham Dumpleton 
> wrote:
>
> > On Jan 4, 12:17 pm, garagefan  wrote:
>
> > > I've read the documentation, and it doesn't seem clear enough, or
> > > provide a fully working example?
>
> > > i've copied what i have in my python.conf file, keep in mind that i
> > > have removed site specific names and have made them generic
>
> > > NameVirtualHost *:80
>
> > > 
> > >     ServerNamewww.website.net
>
> > >     
>
> > Presumably you mean /mysite here and not the root of the web server.
> > This needs to match what you have set django.root to.
>
> > Graham
>
> > >         SetHandler python-program
> > >         PythonHandler django.core.handlers.modpython
> > >         SetEnv DJANGO_SETTINGS_MODULE mysite.settings
> > >         PythonOption django.root /mysite
> > >         PythonDebug On
> > >         PythonPath "['/home/html'] + sys.path"
> > >     
> > >     
> > >         SetHandler None
> > >     
> > >     
> > >         SetHandler None
> > >     
> > > 
>
> > > i get no python errors, however when i go to the site i receive
> > > nothing. these locations worked previous to attempting to set up a
> > > virtual host. i assume *:80 is the port? in which case, i suppose it
> > > may be possible that the port is incorrect? in which case, i'm unsure
> > > as to where to check this... i assume under the apache conf file?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---