I’m a little confused by the Jupyter ecosystem, so I was hoping someone more knowledgeable could give me some advice.
I have a server that I’d like to serve Jupyter Notebooks from to small groups of people. Users need to be able to access the notebooks without a login (like with Binder) or with a login that doesn’t correspond to an OS login.
I tried setting up JupyterHub, but it didn’t allow logins for non-OS users. I also tried setting up BinderHub, but it turns out it’s for cloud servers only.
It’s okay if the notebooks have to be stored on GitHub, but if possible I’d also like to be able to store them locally to the server.
The Littlest JupyterHub sounds like what you need. Here are two resources adapting it along the lines you discuss. One sets up users with passwords you coulld give out.
If you are looking for something more along the Binder lines, @yuvipanda made a littlest binderhub demo. I don’t know if it has progressed to being a plug-in for the littlest JupyterHub but that was one direction. See here.
Looking over the first one, it refers to “valid linux usernames”, and I don’t see anything that loosens that requirement later on. The second link doesn’t mention authentication at all. I don’t think this is what I’m looking for.
I’ll keep an eye on the Littlest Binder, but it doesn’t seem ready for production yet. Are there any other options for serving Jupyter Notebooks without OS accounts?
I recall setting up my own littlest JupyterHub that I could just make up names of users and associated passwords in the admin panel. So I think “valid linux usernames” there in Jason’s Setup directions means that the names just have be allowed as linux names. In other words, not have weird characters. They don’t have to correspond to users of a real linux machine prior. No account set up is required beyond that. So you could fabricate users and associated passwords and hand those out to your small group of people.
Otherwise, you could just take your own server out of the equation and use Github to share the notebooks via Binder.
Since you asked in your last email, another option for serving Jupyter Notebooks without accounts is to set up separate servers for each user. Then you set up it up so the user just needs the address of the server and a previously set password. (However, you just mentioned the one server in your first post.) You can set up an Amazon Machine Image ahead of time with the dependencies, data, and notebooks you want and then spawn multiple versions of that. Then I provide the users which the address of a specific temporary machine and the password (shared among all the spawned instances) that all have been set up. I have done this in the past for training when I didn’t know about the littlest JupyterHub.
The users for your TLJH are technically linux user accounts but you create them via the UI.
Okay, this is what I’m asking. I’m not allowed to create OS user accounts on the server, whether it’s through a UI or not. I need an authentication system where logins are completely, 100% independent of logins to the OS itself, and it sounds like you’re confirming that the Littlest JupyterHub does not meet that criteria.
I’ve looked through the documentation for the native authenticator that you linked, but I can’t find a clear indication of whether its logins are related to OS logins. Do you know how it stores username/password info?
How much power and resources do you need? If you don’t already have an Amazon Web Services account, the first year offers a minimal machine level for free and you can run a TLJH via that instance. I don’t know about the deals on the other providers listed here.
TLJH with NativeAuthenticator does need to create system users. If you can’t create user accounts, then you probably want to use DockerSpawner to put users in containers. For this, you don’t need to create any system accounts, and the username requirements are a little more lax (though using safe linux usernames is still a good idea for simplicity).
If you install dockerspawner:
pip install dockerspawner
c.JupyterHub.spawner_class = 'docker'
then DockerSpawner will be used, and you can pick the image, mounts, etc. in DockerSpawner.