Thank you very much for your suggestions about using Celery. I'll
definitely look into this one. Originally I was trying to avoid using
os.fork(), but was unsure what to use. I will also look into the
uWSGI information provided as well. Overall I would prefer to make
the entire system modular, much like how Django works. If you use
Apache, then use this backend, if you use Nginx, then use this one.
Having a similar system to how Django currently works will make it
easy for any current Django developer/deployment administrator to work
with this control panel system. This also opens the door to third-
parties creating their own backends for custom solutions. Also a
backend system for storing data would be nice as well, say store
configuration in a model, or fetch and store it using LDAP. Other
plugins, may include similar ones to what cPanel has, such as DNS
management and such. Database management would be very basic, as the
editing of data is handled nicely by each projects Django admin site.
Database management would have the ability to administer databases,
and perform exports and imports of data. Another ability I would like
to be plugable would be how users transfer their applications to the
server, currently I do plan Subversion support, but say a user prefers
GIT, or even the archaic and insecure FTP? FYI, I use Subversion over
SSH.
My ultimate goal with this project would be to bring a cPanel like
experience to Django administration, to better widen it's support
among "cheap hosts", where PHP currently(and unfortunately)
dominates. Does cPanel even support Django type applications? I
don't want to try re-inventing a wheel here. I will look further into
panels for hosting Django projects and see what comes up.
On Aug 19, 2:24 am, Roberto De Ioris <robe...@unbit.it> wrote:
> 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/Emperorhttp://projects.unbit.it/uwsgi/wiki/FastRouterhttp://projects.unbit.it/uwsgi/wiki/LinuxNamespacehttp://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 Iorishttp://unbit.it
> JID: robe...@jabber.unbit.it
--
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.
