forked from hacc/haccfiles
stuebinm
a00e28d85a
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/
50 lines
2.5 KiB
Org Mode
50 lines
2.5 KiB
Org Mode
#+TITLE: Pluto standalone
|
|
|
|
This is a nix derivation that wraps a version of julia with the packages
|
|
(and their dependency closure) defined in ~Packages.toml~; currently
|
|
this is just Pluto. It also provides a little julia script that will
|
|
activate this packageset (called a "julia depot"), and then start a
|
|
Pluto notebook server on port 9999. Note that it does so without setting
|
|
up any kind of authenticaton, so don't expose that port!
|
|
|
|
* TODOs
|
|
- [ ] add more packages
|
|
- [ ] more sensible auth
|
|
- [ ] working precompilation; this would probably allow running this
|
|
without a writable julia depot
|
|
|
|
* Steps to reproduce / update the julia-to-nix part of this:
|
|
|
|
In general, it is enough to follow the readme of julia2nix, but since
|
|
that has a bunch of unstated assumptions and weird failure modes, here's a rough outline of how to actually do it:
|
|
- using julia's package managing mode, make changes to ~Packages.toml~
|
|
and ~Manifest.toml~. Be sure to use the same version of julia that
|
|
will run on hainich (currently the ~julia_15~ package of
|
|
nixpkgs-unstable), as otherwise hashes may be different
|
|
- clone https://github.com/thomasjm/julia2nix somewhere
|
|
- run ~julia2nix~ to generate the nix derivations
|
|
+ unfortunately, jula2nix assumes that nixpkgs-unstable is available
|
|
as ~<nixpkgs>~ from within nix; it may fail if you are on another
|
|
channel. In that case, there seems to be no better solution than grepping for occurences of "<nixpkgs>" in jula2nix and replacing
|
|
them with some other path that has the required version
|
|
+ this will re-generate all the ~*.nix~ files in this directory, and
|
|
probably reset all options. The defaults are reasonably sensible,
|
|
but make sure to disable the ~precompile~ option in ~default.nix~
|
|
(see below for why)
|
|
- run ~nix-build --no-out-link~ to check if it worked and nix can
|
|
build the julia depot
|
|
- deploy hainich. Note that the derivation will only contain the
|
|
package sources, not a compiled version. Julia will compile packages
|
|
on startup (and cache them for subsequent runs), so after the deploy
|
|
it may take a minute or two to actually run Pluto
|
|
|
|
* precompilation
|
|
/In theory/, we should be able to precompile all the packages during
|
|
nix-build, and then directly load them into julia and runtime.
|
|
However, this currently fails, and even if precompiled packages are
|
|
present in the depot built via nix, julia will refuse to use them and
|
|
recompile them instead (in a second julia depot that is writable at
|
|
runtime).
|
|
|
|
There's an open issue on this at jula2nix:
|
|
https://github.com/thomasjm/julia2nix/issues/22
|