Another benifit: If your physical machine is somehow seized by an unwanted thirdparty, Once your server is powered off or restarted, your running instance of everything would be gone, and Intellectual Property would be safe.
In this model we could establish reliable licensed service to Intranets and corporates. The service could be charged either by hour or by number of running instances. The Intranet only need to load the latest version of a service from the Internet, and go LAN-only or whatever afterwards. You don't have to worry that your source code is leaked or modified without permission. I am intend to build a system like this. Does anyone have any technical experience of how difficult and reliable this could be? Thank you guys! On Wed, Aug 21, 2013 at 5:01 PM, est <[email protected]> wrote: > > say, downloading an image of your application’s data off the central > node and mounting it read-only? > > Yes, but the big difference here is that, file reading via NFS or Docker > image *can't be audited*. You never knew what happened on each operating > side. e.g. whether it's been read/write by uWSGI process or some unintended > malicious process. > > IF uWSGI take over the source code loading mechanism, you can't inject > arbitary code easily, like the php just append one-liner backdoor easy. > Modify memory without corrupting or reload requires some serious skills and > triggered unscheduled reload or crach the SysOp would immediately know. > > > You suggest it would improve runtime security and guarantee code > integrity > > Another benifit is deadly easy scaling. If you run short of uWSGI Web > workers during peak time, just install uWSGI in a new node, run it by > subscribing to the central provision node, every config, source files will > be loaded & balanced automatically. The only thing you need to take care of > is how to collect user uploaded files into one place. > > > > > > > On Wed, Aug 21, 2013 at 4:40 PM, Mel Boyce <[email protected]> wrote: > >> >> On 21/08/2013, at 5:39 PM, est <[email protected]> wrote: >> >> > Hello, >> > >> > So this crazy idea came to my mind. Since Django (or any other WSGI >> project) is running with all modules loaded into memory, after the initial >> loading the local .py and .pyc source files are, in theory, no longer >> necessary, assume that we don't ever need to reload/restart the system >> > >> > So, >> > >> > 1. Is it totally safe to delete .py and .pyc files after the WSIG >> project finished loading in current version of uWSGI? (Assume workers >> don't have to harakiri or reload) >> > 2. Suppose we need to build a cluster that we only store & distribute >> source file from a central node (e.g. a subscription server) and slave >> nodes loads python source files via uwsgi protocol or something, How >> difficult is could this be? >> > >> > This idea could help strengthen runtime security at clustered nodes and >> gurantee code integraty. Is my idea bad? >> > >> > Just some crazy speculations, all kinds of criticism is welcome :) >> > _______________________________________________ >> > uWSGI mailing list >> > [email protected] >> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> >> While I don't think this is a bad idea, I do wonder if it's something >> needed. You suggest it would improve runtime security and guarantee code >> integrity; surely those responsibilities lie with the system administrator >> via existing mechanisms (solid code deployment routines, robust permission >> sets, etc). >> _______________________________________________ >> uWSGI mailing list >> [email protected] >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> > >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
