Jupyterhub and motd/nologin/alerts?

[Norman Gray]

Greetings.

Is there any jupyterhub equivalent of motd, or nologin, or alerts,
available on Jupyterhuh? I feel sure there must be, but I can't find
anything relevant either in the docs or via searches.

When planning for server downtime, it's useful to be able to warn users
of the forthcoming downtime with some sort of motd-equivalent, then stop
people connecting in the period running up to the shutdown, and to alert
them -- in a 'hey, you!' way -- if they're still connected come shutdown
time.

I can see it's possible in principle to fiddle with the login screen for
the motd, but that seems rather hacky.

What am I missing?

Best wishes,

Norman

[Michael Milligan]

It sounds like you want https://github.com/rcthomas/jupyterhub-announcement

That plugin is developed and used at NERSC to do communication with their users in much the way you describe. We should probably do something about making it more discoverable.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/6E9FB33D-BAF3-48C9-AE5C-8D085CD2F5EE%40gmail.com.

--

Michael Milligan, Ph.D.    | Supercomputing Institute
Assistant Director for     | University of Minnesota
   Application Development | mill...@umn.edu
he/him/his                 | www.msi.umn.edu

[Norman Gray]

Michael, hello.

On 1 Sep 2020, at 15:27, 'Michael Milligan' via Project Jupyter wrote:

> It sounds like you want
> https://github.com/rcthomas/jupyterhub-announcement
>
> That plugin is developed and used at NERSC to do communication with
> their
> users in much the way you describe. We should probably do something
> about
> making it more discoverable.

That's very useful -- thanks -- and seems to do exactly what's required
in terms of announcements.

For the benefit of those users who _will not read_, is there any way of
inhibiting logins, or of either communicating with them (in the sense of
'we're rebooting -- go out for a walk!') or booting them off in a
controlled way?

Best wishes,

Norman

[Michael Milligan]

Hello -

It is straightforward to stop user sessions from the Jupyterhub admin page. I'm not aware of a "nologin" type solution, but it sounds simple enough that someone has probably implemented one.

Unfortunately the weak link here is communicating with users who are already in running sessions. Jupyterhub can't easily help there, as by that time the user experience is under the control of the notebook server, jupyterlab, or whatever frontend they happen to be using. So your solution will depend on what your users are actually doing. I'd also be curious to know if others in this forum have solutions for that.

 

Best wishes,

Norman

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/BBF672DE-A262-4B1E-A167-0D58BB561725%40gmail.com.

[Norman Gray]

Michael, hello.

On 1 Sep 2020, at 18:20, 'Michael Milligan' via Project Jupyter wrote:

> I'm not aware of a "nologin" type solution, but it sounds simple
> enough
> that someone has probably implemented one.

It does sound quite simple. Having created a mildly customised spawner
before, I imagine I could hack up something like this myself, but...
must resist... must resist...

> Unfortunately the weak link here is communicating with users who are
> already in running sessions. Jupyterhub can't easily help there, as by
> that
> time the user experience is under the control of the notebook server,
> jupyterlab, or whatever frontend they happen to be using. So your
> solution
> will depend on what your users are actually doing. I'd also be curious
> to
> know if others in this forum have solutions for that.

Right, I see. I could imagine there being some sort of hook in there
which we could use, but if control is handed over to the notebook
server, I can appreciate that would be hard.

So maybe this is more of a jupyterlab question, than a jupyterhub one.

Best wishes,

Norman

[Jason Grout]

If you wanted to implement a front-end extension for, say, JupyterLab, you could do this. Basically, the extension would have two parts: a server part that creates an api endpoint (i.e., a url that can be polled, like `/motd`) and a frontend part that polls the url asking for a message and displays a message if there is one. Or slightly fancier would be an api endpoint that uses some sort of push method (websocket, or even long polling, or something) - that way a message could be pushed to the server without having to wait for a polling interval.

Jason

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/AB5AF6AB-7205-42FF-A8ED-54CFF747C8F0%40gmail.com.

[Rollin Thomas]

Hi there,

The question of how to get an announcement to users running in JupyterLab has been asked before, and I think what Jason suggests is the answer.  The jupyterhub-announcement service has an API endpoint `/latest` that returns the latest message, when and who posted it.  JupyterLab could just call that periodically.  If the "hey log off" message is something you want sent immediately the more fancy websocket option would be the way to go though we'd have to add that to the service.  There's an issue open on jupyterhub-announcement right now about it but it's a bit stale, maybe we can revive the conversation.  I do think at this point it's more of a JupyterLab implementation/extension question (except for the push part).

What we do for nologin-like stuff at our Center is a bit rough, but it mostly works.  We update the hub configuration to allow only admin logins (via the allow-only list) and then use an admin-managed script or the admin interface to shut down all the servers.  Users don't get any warning about it of course and with a large number of users on it can take a while; our script version is parallelized.  I think it's not perfect but it's good enough for when we really need the notebooks to stop for some reason.  If there's a scheduled maintenance I start shutting down idle servers a little bit ahead of time to keep any maintenance window short.