On Sun, Feb 11, 2018 at 1:10 AM, Dima Pasechnik <dimp...@gmail.com> wrote: > > > On Sunday, February 11, 2018 at 1:20:59 AM UTC, Kwankyu wrote: >> >> >> >> On Sunday, February 11, 2018 at 8:00:46 AM UTC+9, kcrisman wrote: >>> >>> That is a great question. Sagenb (what you have found) does not serve up >>> Jupyter. It would be really interesting to hear from someone who knows >>> about Jupyterhub and whether that is a stable solution at this point. >> >> >> I don't have an experience of deploying Jupyterhub, but for experiments >> have installed a Jupyterhub server on a ubuntu machine. >> >> Jupyterhub is really just a hub for Jupyter notebooks. A user, after login >> in the login webpage, have a Jupyter notebook runnng with his(her) own >> account of the machine. So it is like the user login to a machine and run a >> Jupyter notebook in the shell and use the notebook on a web browser. >> >> For me, a big concern of running Jupyterhub on my machine is security. If >> you give an id and passwd to a user (say a student), then (s)he can whatever >> you can do on a linux machine with internet connection. > > > This is not really true. There are many ways to restrict what a user can do. > E.g. cocalc does more or less the same thing: a cocalc project is associated > with a unique linux user account (and yes, for non-paying users there is no > full-blown internet access).
The CoCalc docker image I linked to automatically creates new accounts for each user, all inside a single Docker image... so that's some isolation from the rest of the system. The main CoCalc.com website does NOT do that. Instead all projects appear to themselves to be running as the same Linux user, but each is isolated inside its own separate Docker container, scheduled using Kubernetes across a cluster of small VM's. There was a talk at the last Kubecon about a way to run JupyterHub that similarly schedules users on a cluster using Kubernetes -- https://www.youtube.com/watch?v=g5rl7T18n-s&feature=youtu.be This is the same thing that Volker mentioned. > And you are right, if you restrict a user within a lightweight virtual > machine it's more secure. > E.g. FreeBSD has something called jails for such a purpose: > https://www.freebsd.org/doc/handbook/jails.html > Not sure what's Linux equivalent for this. Containers. Docker is by far the most mature at this point. There's also rkt, which is far less mature (according to my tests). Volker mentioned LXC, but it's also less mature than Docker. Containers are typically paired with use of cgroups (which initially Google pushed into Linux, based on their internal needs) to isolate groups of processes, and impose limits (e.g., on memory, cpu, processes, etc.). In CoCalc.com we use Calico to program the Linux routing table, which makes it easy to restrict connections between parts of the system, not allow outgoing connections by default, etc. Volker: > [...] whereas SageNB runs everyone under the same unix account. More precisely, it used a rotating pool of pre-created unix accounts... -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
