Thought about this some more, and I wonder if there isn’t a simpler solution:
* create a worker pool of userid’s that represents the maximum number of simultaneous users you are willing to support. This could be very large, if you want * when a worker id becomes available, pull the next email from the inbox, assign it to that worker id, and submit that job to the scheduler for execution * when the job completes, package the results/output and email them back to the original sender. Then mark the worker id as available. You’ll still have security issues around the use of Docker, which is why I’d recommend considering Singularity since it doesn’t require nor allow privileged operations - and it doesn’t require integration with the resource manager like Docker does. Singularity knows how to fully package OMPI apps, so it is rather simple to automate the procedure for “containerizing” the user’s app prior to submitting to the scheduler. HTH Ralph > On Jun 6, 2016, at 2:07 AM, John Hearns <hear...@googlemail.com> wrote: > > Rob, I am not familair with wakari.io <http://wakari.io/> > > However what you say about the Unix userid problem is very relevant to many > 'shared infrastructure' projects and is a topic which comes up in discussions > about them. > Teh concern there is, as you say, if the managers of the system have a global > filesystem, with shared datasets, then if virtual clusters are created on the > shared infrastructure, or if containers are used, then if the user have root > access they can have privileges over the global filesystem. > > You are making some very relevant points here. > > > > > > On 5 June 2016 at 01:51, Rob Nagler <openmpi-wo...@q33.us > <mailto:openmpi-wo...@q33.us>> wrote: > Thanks! SLURM Elastic Computing seems like it might do the trick. I need to > try it out. > > xCAT is interesting, too. It seems to be the HPC version of Salt'ed Cobbler. > :) I don't know that it's so important for our problem. We have a small > cluster for testing against the cloud, primarily. I could see xCAT being > quite powerful for large clusters. > > I'm not sure how to explain the Unix user id problem other than a gmail > account does not have a corresponding Unix user id. Nor do you have one for > your representation on this mailing list. That decoupling is important. The > actual execution of unix processes on behalf of users of gmail, this mailing > list, etc. run as a Unix single user. That's how JupyterHub containers run. > When you click "Start Server" in JupyterHub, it starts a docker container as > some system user (uid=1000 in our case), and the container is given access to > the user's files via a Docker volume. The container cannot see any other > user's files. > > In a typical HPC context, the files are all in /home/<unix-user>. The > "containment" is done by normal Unix file permissions. It's very easy, but it > doesn't work for web apps as described above. Even being able to list all the > other users on a system (via "ls /home") is a privacy breach in a web app. > > Rob > > > _______________________________________________ > users mailing list > us...@open-mpi.org <mailto:us...@open-mpi.org> > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users > <https://www.open-mpi.org/mailman/listinfo.cgi/users> > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/06/29369.php > <http://www.open-mpi.org/community/lists/users/2016/06/29369.php> > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/06/29377.php
