Introduction from afar

Not long ago I felt nostalgic inside FreeBSD again, everything is wonderful, everything is familiar, everything is convenient.
There is just one point that completely rules it out from desktop use, at least for me.
On almost all my laptops, FreeBSD does not support either sleep or standby modes (s2disk/s2ram).
And I couldn’t do anything with the hardware/drivers/ACPI, but I tried a lot.

Without standby mode, it is completely impossible to use a laptop, since after transportation, you need to load everything again, turn it on, and restore a complex work session.
And I only reboot workstations after applying updates that require it.

One of the many nice little things that Beastie has that Debian lacks is ZFS Boot Environments, this is somewhat more convenient than, say, LVM snapshots.
And the second is GEOM_ELI, which supports not only, like LUKS, the OR password OR key mode, but also supports password WITH key mode.

I thought and thought, and decided to deploy Debian from scratch, taking into account all the tools I use, my experience, and, importantly, my habits.

Debian is still my main system, so the only way to get a hardware (physical) encryption key in addition to the password is to make it from the header and place it on a bootable USB flash drive.

Let’s consider a standard situation where you have a main work computer on which you have three different projects.
One project is on nodejs, the second is a production project on python, and the third is your personal “pet project”, also on python.
You also have personal and work email in the same system, and, say, a browser and home-banking.
And all this under your login.
Well, not under the root login, of course! ¯\_(ツ)_/¯
Everything is quite normal.

Many technically competent developers may have dozens of such projects.
And dozens of keys for SSH or GIT servers.

An example with the popular PyTorch framework

It’s quite ordinary: you write your code, commit it from time to time, and then a torchtriton update arrives in your cozy pet project.
And after that, the following data sets were transferred from your system, in accordance with the binary’s main function:

• Get system information:
  • nameservers from /etc/resolv.conf
  • hostname from gethostname()
  • current username from getlogin()
  • current working directory name from getcwd()
  • environment variables
• Read the following files:
  • /etc/hosts
  • /etc/passwd
  • The first 1,000 files in $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

The update arrived and the confidential data flew away.
It’s not just everything under your account (and possibly the system) has been compromised, but also, down the chain, everything you managed, committed to, and connected to.

Very, very often you have to deal with the need to use a certain version of Python, for example, for torch, or for something specific.
Using conda or Docker with nvidia-container-toolkit and then setting up images like nvidia/cuda:13.0.1-runtime-ubuntu22.04 feels counterintuitive to me, even though I’ve done it many times.
And an additional packages have to be installed in the container.

But easier and more convenient to compile everything on the host system, and at the same time prevent contamination of the entire system with third-party libraries and executable files.

The following is an example of building multiple Python versions for the verpy group only, which is a bit more convenient than installing for just one user.

• ai - an arbitrary user from whom the compilation is performed.
• verpy - the group that will be allowed to use these versions.

1
2
3
4

apt install \
    build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
    wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev \
    liblzma-dev libgdbm-dev libnsl-dev libgdbm-compat-dev

mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai

Without going into detail about how exactly and why everything is organized, access is provided through the following chain:

1

Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance.

The Main Frontend manages the gitlab subdomain, which is closed to external access via auth_basic authorization.