Il giorno 19/ago/2011, alle ore 08:46, Kevin ha scritto:
> Hello everyone,
>
>
> Here's the code I will be needing to run in a os.fork():
> from django.core.management import setup_environ, call_command
> import settings
> setup_environ(settings)
> call_command('<management command>', **kwargs)
>
> So this would be in a separate function and called from a view which
> uses os.fork(), or should I place os.fork() in the same function as
> this code. Of course the sys.path will be re-written before any
> imports are done. I plan on integrating Virtualenv with this. The
> model in the management Django project will contain the directories
> and such that point to the Virtualenv.
>
> If anybody is interesting in helping with such a project, I am very
> much open to any help. I hope that this project may open Django to a
> wider world of users, if the command-line Django admin stuff can be
> done through a nifty web interface. I have a server which it can be
> developed and tested on as well.
>
IMHO, this is the wrong approach from a security/sysadmin point of view.
All of your django instances will run under the same uid. bad: all of your
users will be able
to destroy other instances.
If you want to call a setuid after each fork() you have to run the django panel
as root. even badder.
As a rule, do not allow users generating fork(). You will need to implement a
throttling system (and this could be a pita).
Even if modern os are stronger against fork bombing, you can destroy a whole
server easily.
The most secure approach would be enqueing the tasks (you can use celery, uWSGI
spooler, or a dedicated daemon or whatever you want)
and execute one by one (this solves fork bombing problem). You will lose
real-time, but you will gain security.
Each task should run as a specific uid, so for each customer run another daemon
waiting for event (it will really run manage.py and runfcgi for you).
Lot of work to do, you should take in account that the uWSGI project is built
with this target in mind (ISPs), and has systems to easily administering
multi-uid environments:
http://projects.unbit.it/uwsgi/wiki/Emperor
http://projects.unbit.it/uwsgi/wiki/FastRouter
http://projects.unbit.it/uwsgi/wiki/LinuxNamespace
http://projects.unbit.it/uwsgi/wiki/UseCgroups
the main idea (already used by more than 20 ISPs worldwide) is having the
"panel" generating config files (they can be even taken via http dynamically)
After you have a user instance running, you could add an embedded app on it to
launch tasks (so it will be the user app itself executing processes)
Another (rawer, but funny, used by rosti.cz) approach is this one:
https://github.com/creckx/uWSGI-Manager
You can even start from the ground and re-implement all of this concepts in
pure-python (in this case i suggest you to try gunicorn as it is more simple to
integrate [being in python]).
Or you could follow the old-raw-way of dinamically generating apache
virtualhosts file for each customer and let mod_wsgi+daemon_mode do the hard
work.
Well, returning to the os.fork() problem, if you really need it, be sure that
it will be the user slice/area/instance calling it (so you can limit with the
various jailing technics) and not your main control panel.
--
Roberto De Ioris
http://unbit.it
JID: [email protected]
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
