Pluto [1] is one of these interactive notebook thingies that have become
so unreasonably popular with people doing machine learning or data
analysis, but – somewhat surprisingly – it's actually not shit (e.g. no
global mutable state in the notebook, no weird unreadable fileformat
that doesn't play well with version control, etc.)
In particular, it can be used collaboratively (while it doesn't do
real-time collaborative editing like a pad, it /does/ push out global
updates each time someone executes a cell, so it's reasonably close),
and I think it may be useful to have for julia-hacking sessions.
It may also be useful for people running low-end laptops, since code is
executed on the host — and I guess hainich has enough unused ressources
lying around that we can spare a few.
After deploying this, the notebook server should be reachable via:
ssh hainich -L 9999:localhost:9999
and then visiting http://localhost:9999
Caveats: by design, pluto allows a user to execute arbitrary code on the
host. That is its main function, and not something we can prevent. I've
tried to mitigate this as far as possible by:
- only allowing access via ssh port forwarding. In theory pluto does
have basic access control, but that works via a secret link that
it'll spit to stdout on startup (i.e. the journal), which cannot be
set in advance, nor regenerted without restarting the entire process.
Unfortunately, this means we won't be able to use it at e.g.
conference sessions with people who don't have access to our infra
- running it in a nixos-container as its own user, so it should never
get any kind of access to the "main" directory tree apart from a
single directory that we can keep notebooks in (which is currently a
bind mount set to /data/pluto)
- limiting memory and cpu for that container via systemd (less out of
worry for exploits, and more so that a few accidental while-true
loops will never consume enough cpu time to noticebly slow down
anything else). The current limits for both a chosen relatively low;
we'll have to see if they become too limiting should anyone run an
actual weather model on this.
Things we could also do:
- currently, the container does not have its own network (mostly since
that would make it slightly less convenient to use with port
forwarding); in theory, pluto should even be able to run entirely
without internet access of its own, but I'm not sure if this would
break things like loading images / raw data into a notebook
- make the container ephemeral, and only keep the directory containing
the notebooks. I haven't done this since it would require
recompilation of pluto each time the container is wiped, which makes
for a potentially inconvenient startup time (though still < 3-5 mins)
Questions:
- have I missed anything important that should definitely be also
sandboxed / limited in some way?
- in general, are we comfortable running something like this?
- would we (in principle) be comfortable opening this up to other
people for congress sessions (assuming we figure out a reasonable
access control)?
Notes to deployer:
- while I have not tested this on hainich, it works on my own server
- you will probably have to create the /data/pluto directory for the
bind mount, and make it world-writable (or chown it to the pluto user
inside the container)
[1] https://github.com/fonsp/Pluto.jl/
Intended for KontraIAA; requirements were that it should be a simple and
non-confusing as possible.
I tried both KiwiIRC and thelounge, and found both horrible to
package (a fact not helped by the somewhat opaque structure of
nixpkgs.nodePackages, which does contain a version of thelounge but
will apparently ignore overrides of the src attribute).
Instead, this now contains a very hacky version of thelounge, which
merely takes the already-built version from nixpkgs and glues some extra
css to it which hides potentially confusing fields.
Things hidden on the "connect" screen:
- the "name" field (since thelounge offers "nick" "name" and "realname"
by default, which seems too much for something embedded on a website)
- the "I have a password" checkbox
Things hidden on the general view:
- the button to open the side panel (the panel itself is not hidden,
and will appear by itself on wider layouts), so that users will only
see that one channel
- the "channel options" menu (which includes a "leave channel" option
which would effectively break the webchat)
Things not addressed:
- thelounge has autocompletion for /join /leave, etc. Do we want to
disable that as well?
- It would probably useful to suppress all the "x joined the channel"
messages. Thelounge supports this, but apparently doesn't support
setting it as default?
Misc:
- for now, users will be connected to #thelounge on libera.chat, which
appears to be okay with being used as an experimental channel
- I allowed prefetching link previews, but only on the server's side
(i.e. users' browsers won't fetch content from arbitrary sites)
- not yet tested on hainich, but should work (tested in a NixOS
container)
- currently assumes a "webchat.voc.hacc.space" domain (I think we had a
voc domain? but I forgot where it is …)
nixos and its concepts/service management/update mechanism don't play nice with minecraft
In general some things I wanted to do (e.g. a map) are to spikiely resource intensive to run on a server meant to provide other services consistently
A replacement will be provided soon™
this is a workaround to be able to use java 11 with the
minecraft-server module
minecraft calls for jre_headless, which is still java 8
newer java version don't ship jre, which now have to be custom built or
the jdk used
lots of fancy new stuff, but most importantly: we no longer import all
of my user config, just the very base.
none of that fancy stuff is active right now, this should mostly be a
no-op unless we do the same restructure that i have just done in my
nixfiles here as well.
