On 6/27/07, Nils Bruin <[EMAIL PROTECTED]> wrote: > > I'm a little worried about creating new accounts for each user, just because > > that means the Notebook server has to have the ability to create new > > accounts, > > which is probably a pretty serious ability to have. But I suppose sudo > > could > > give them just access to the adduser command and not much else. Actually, > > I sort of like this idea. > > > > William > > I understand that the ideas you are developing here are highly > appropriate for an open notebook and are probably applicable to > VMware'd systems too.
In fact that are *only* about this situation, in which we are thinking about the larger picture, i.e,. the system that is SAGE + a linux distro. > However, the typical potential user doesn't have > admin access themselves. It will be hard enough to convince system True -- nobody is suggesting making the normal user's default notebook install work like we're describing in this thread. We've actually very much kept the usage scenarios below in mind in implementing the new notebook; I think you'll be happy with it when it is released. > administrators to install software that listens on an outside port, > but if that software can ALSO make new user accounts, it will probably > be impossible (and otherwise the sysadmin should be fired) > > Please keep in mind there are other usage scenarios as well: > - sage runs on a private machine, with essentially only one > authorised login (think laptop) With the new version of SAGE I'll release soon (or you can get from /home/was/twisted on sage.math), if you type "notebook()" it: (1) migrates any old notebook to the new format, (2) asks for a new "root password" in case you've never used the command before, (3) opens a server on port 8000 on localhost, (4) accepts https (ssl encrypted) logins from localhost only, and (5) does not by default allow creation of new accounts. This is perfect for a private machine (there is also a notebook(secure=False) option, when you know your machine is truly private, i.e., no other accounts but your own, i.e., a laptop). > - sage runs on a workstation, with one main user but multiple people > authorized to login (standard networked workstation) > - sage runs on a rack server; multiple people are allowed to login > and regularly do > - prof wants to use sage as a teaching tool and for students to do > assignments. Students are not very trusted, but the prof administering > the sage system probably only has limited authority on the machine it > runs on. > > Scenarios 1 through 3 would not necessarily be chrooted, because > people using the notebook would normally have shell access anyway. None of them need to be chroot'd. > The > notebook could just listen on a local port and people can connect via > ssh tunnels. Replace "ssh tunnel", which makes too many demands on the users to be sure to do the right thing, with "ssl encrypted https session". > It might even be desirable that, after authentication, I > can access my own homedir files (makes for easy attaching & editing of > custom programs and allows me to communicate easily with normal - > homedir centric software. On the other hand, sage su-ing to my uid > would make me slightly uncomfortable (sage is too complicated a > program to do such delicate things). > > Scenario 4 does need good lockdown and probably protection against > vandalism. However, the prof may not have enough permissions to set up > what you described before. In this scenario, the notebook would > probably have to listen on an outward port. The only thing that makes > it not quite a "public" notebook is that accounts are not freely given > out. > > Incidentally, if the notebook connects via ssh to the sage sessions, > there is no reason for them to live on the same computer either > anymore! True. I have already tested this out and it is implemented. It is currently necessary for the file system to be shared though, for various reasons. > This opens the road of running a central notebook process, where all > the members of the department can connect. From there, the sage > processes are run on a collection of machines! This setup only needs Yes, definitely. > that the system can trust that the relevant parts of the filesystem > are network shared, or (for the read-only parts) exact copies on all > machines involved. These conditions are normally easy to meet on > departmental research networks. It's not read-only -- there really needs to be a shared filesystem. This is fortunately a pretty standard thing though. Many thanks for your feedback and enthusiasm. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
