• 6 Posts
  • 180 Comments
Joined 3 years ago
cake
Cake day: August 10th, 2023

help-circle
  • Yes, although there have been a few CVE’s related to escalating privileges or breaking out of the sandbox. You’re going to want to keep those updating and keep on top of those.

    There is one concern, in that the nix store (/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.

    With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.

    My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day’s. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.

    Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.

    And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn’t have enough value (assuming of course, your research isn’t too valuable and worth targeting), and you mostly don’t have to worry about it.

    Sure, people will root it. But then they’ll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.

    However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux’s user based isolation.

    The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.

    In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host’s performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU’s usually support it though.


  • the physical display output is claimed by something else totally separate.

    Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It’s possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being “headless”, and not shown.

    I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I’m running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.




  • If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run dbus-run-session startplasma-wayland, does that work?

    Sometimes just startplasma-wayland works, which used to work for me but didn’t work for me this time.

    Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.

    Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.

    EDIT: I only am somewhat confident that this setup will work, I haven’t tested it personally.







  • Containers are commonly used to distribute programs that depend on different library versions, including different libc versions.

    And yes, you could compile software for specific hardware and then deploy it via containers.

    What is the advantage in using a container to say run gromacs, rather than pointing the user to the path of the compiled binary

    Different libc versions. There are also some sandboxing and security restrictions that are applied.

    I definitely want to have some persistent services running: databases, a couple web applications and maybe a Jupiter webpage to visualize results.

    Maybe docker swarm mode, with the nvidia container runtime is easier? It lets you spin up services on multiple nodes, which you could then load balance with a conventional reverse proxy. Although if you are trying to do a single instance of Jupyter, then I don’t know about it’s ability to serve multiple users, or the security of that setup. Usually, people go for things like JupyterHub + the Dockerspawner. Jupyterhub handles authentication or

    There is also a Kubernetes spawner, or you can use an alternative web application that can dynamically spin up jupyterlab/notebooks, like Kubeflow, or coder, but I don’t think any of that is what you want in regards to that specific usecase for Jupyter.

    If you just want to present rendered stuff, check out: https://quarto.org/ , which is a static site generator capable of executing jupyter notebooks, and rendering them to websites. It can also render I use it for my blog, which is ironic because I don’t actually use any of the data science features quarto has. I really like quarto because it’s the only static site generator which I found has fulltext search built in/easily enabled. It runs some javascript over a generated index, and you can search the website without any form of backend needed.


  • Two years later, and I have an answer, after reading this: https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/SysadminGuide.html#Subvolumes

    which was linked from the Arch Wiki, but it is the old wiki, which is obsolete and no longer updated. Basically, in a nested subvolume layout, the nested subvolumes inherit mounting options of their parent subvolume. This might be changeable, but it’s the default.

    On the other hand, separate subvolumes have their own mount options. Although not really important for a swap file, since the file itself can have copy on write features removed, you might want this if you want a subvolume containing folders of data where you want copy on write disabled for performance purposes. This matters for things like postgres, which has it’s own alternatives to journaling/CoW:

    Because WAL restores database file contents after a crash, journaled file systems are not necessary for reliable storage of the data files or WAL files. In fact, journaling overhead can reduce performance, especially if journaling causes file system data to be flushed to disk. Fortunately, data flushing during journaling can often be disabled with a file system mount option, e.g., data=writeback on a Linux ext3 file system. Journaled file systems do improve boot speed after a crash.

    From here: https://www.postgresql.org/docs/18/wal-intro.html

    And then the other benefit of a top level subvolume is management. You can mount it anywhere you want. You can mount it independently of other btrfs subvolumes, meaning you could share a swap file between two installed distros to save space, although this breaks hibernation, so you probably wouldn’t want that. It’s just that top level subvolumes give you flexibility nested subvolumes don’t.


  • Firstly, you should check out what the organization you are building for uses. If they use Red Hat, or Ubuntu, then you should probably just build your solution on top of those operating systems (or a Red Hat clone like Rocky or Alma). Both of those are popular in many organizations, and it would probably be better to use what people are familiar with and know how to troubleshoot or work their way around. Potentially, they even have support contracts, giving them the option of calling the parent company for help.

    Ansible is good. The learning curve is definitely less steep than Nixos, and it’s easier to teach people. One benefit is that you can reuse existing public roles and playbooks. For example this one: https://github.com/galaxyproject/ansible-slurm , which installs slurm.

    You would probably have to write additional playbooks or roles to install nvidia drivers or configure the system, but then they can stick.

    openhpc

    Firstly, is there anything specific from here you need? Secondly, is there anything in here that’s not available in existing distro repositories, like Ubuntu or Red Hat’s?

    It certainly looks like an interesting project, but a 3 node cluster is pretty small, and I find it hard to justify things like OpenMP/MPI, which is basically a special compiler that compiles programs to run across multiple machines at once. For that runtime to work, you do actually have to compile the programs, which are written for it, using it, which can require work on the side of the people who want to run applications or simulations.

    The more likely setup, to me, is that Slurm is going to to run docker containers via Apptainer. Slurm would handle assigning containers to nodes based on free resources, but they wouldn’t actually share resources like memory or CPU. This setup is still plenty useful, and very common.

    Original comment, from before I read that you already selected slurm below. This comment isn’t relevant, as I realized I was targeting the wrong things but I’ll just leave it here regardless.

    For the platform itself, you should use either Kubernetes or Slurm. Slurm is popular in academia, and Kubernetes is popular in corporate, but they are used interchangably depending on specific needs.

    Slurm is better for scheduled tasks. Like let’s say you want researchers at a school to be able to run a long running simulation. They can sign up, reserve time for that slurm cluster, and then send out a “job”, for that slurm cluster. The job will automatically be allocated to the node of the cluster with free resources, and then ran, and then stopped, and the researcher will receive the results back.

    Kubernetes is better for persistent deployed services, like web services or the like. For example, AI inference. Kubernetes can also do batch jobs, but it doesn’t have the advanced time tracking or scheduling systems that slurm has (although sometimes people build that on top of Kubernetes in order to only deploy one clustered system).

    Nixos is nice for configuration as code, but it lacks clustering or application/cluster orchestration features. You can use Nixos to deploy Kubernetes or Slurm, but I wouldn’t use it as the HPC platform itself. Nixos should work with Cuda in addition to that.





  • The point of mit is to get the licensed thing used as widely as possible. It breaks down any barriers to use

    There are no barriers to use, except that you have to share the source code back, and give users the option to modify it. If you use it without modifyiing it, you can just point users to the existing public code.

    The only barrier to use is that Apple disallows (A)GPL related libraries in any of their code, published through their main distribution channels to their platforms (mainly talking about apple app store here).

    https://www.zdnet.com/article/how-to-avoid-public-gpl-floggings-on-apples-app-store/

    But this is ultimately on Apple for not giving users the needed amount of control over their devices to comply with the license. This annoyingly common rhetoric that the GPL itself is a “barrier” or “restrictive” is just blaming the wrong party.

    Now, even though I’m more in favor of copyleft, I can understand with the decision to license software or libraries permissively in order to be able to distribute them through the App Store.

    gpl licensed is a game engine you want people to be able to freely use and modify but never make secret changes to sell

    This is tricky because the GPL is fairly aggressive, and may require the entire game to be open sourced if it’s distributed as one bundle. LGPL doesn’t fight as hard for users freedoms, but also has some similar issues. Most game developers don’t want to open source their games, so I think a permissive license is probably the easiest choice for a game engine.