Вступ здалеку

Нещодавно знову ностальгував у FreeBSD, все чудово, все звично, все зручно.
Лише один момент повністю виключає її з використання, принаймні в мене.
Майже на всіх моїх ноутбуках FreeBSD не підтримує ні режим сну, ні режим очікування (s2ram/s2disk).
І зробити я з цим нічого не зміг, а перепробував багато чого.

Без режиму очікування абсолютно неможливо користуватися ноутбуком, так як після транспортування необхідно по новому все завантажувати, включати, відкривати.
Та й перезавантажую робочі станції лише після оновлень, які цього вимагають.

З багатьох приємних дрібниць, які є у Фряхі, і які відсутні в Debian це ZFS Boot Environments, що зручніше, ніж, скажімо, снапшоти LVM.
А друге це GEOM_ELI, який підтримує не лише, як LUKS, режим АБО пароль, АБО ключ, але також підтримує режим І пароль, І ключ.

Подумав, подумав, та й вирішив розгорнути Debian з нуля з урахуванням усіх інструментів, які використовую, досвіду, і, що важливо, звичок.

Debian поки що залишається основною моєю системою, тому єдиний спосіб отримання хардварного (фізичного) ключа шифрування на додаток до паролю - це зробити його з хедера і розмістити на USB-флешці.

Стандартна ситуація, у вас є основний робочий комп’ютер, на якому у вас є три різних проекта.
Один проект на nodejs, другий продакшн на python, а третій ваш власний “pet project”, теж на python.
А ще у вас у цій же системі особиста та робоча пошта, та й, скажімо, браузер і клієнт-банк.
І це все під вашим юзером.
Звичайно ж, головне, щоб не під рутом!
Решта не має значення. ¯\_(ツ)_/¯
Все цілком звичайне.

У багатьох технічно грамотних розробників таких проектів можуть бути десятки і десятки ключів для ssh або git серверів.

Приклад із популярним фреймворком PyTorch

Цілком повсякденно Ви пишете свій код, іноді комітіте, і тут у ваш затишний pet-project з AI прилітає оновлення torchtriton.
А після цього з вашої системи відлітають наступні набори даних, відповідно до основної функції бінарника, яка робить наступне:

• Збір системної інформації:
  • nameservers з /etc/resolv.conf
  • hostname з gethostname()
  • поточний логін з getlogin()
  • поточна робоча директорія з getcwd()
  • змінні оточення
• Читання наступних файлів:
  • /etc/hosts
  • /etc/passwd
  • Перші 1,000 файлів з $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

Оновлення прилетіло, конфедиційні дані – відлетіли.
Скомпрометовано не тільки все під вашим юзером (і, можливо, системою), але й по ланцюжку все, чим ви керували, куди комітили, куди підключалися.

Дуже, дуже часто доводиться стикатися з необхідністю використання певної версії Пітона, наприклад, для torch, або чогось специфічного.
Використовувати conda або Docker у зв’язці з nvidia-container-toolkit і потім налаштовувати образи наприклад nvidia/cuda:13.0.1-runtime-ubuntu22.04 мені відчувається протиприродно, хоча часто так робив.
Та й у контейнері доводиться встановлювати додаткові пакети.

Простіше і зручніше зібрати все на хостовій системі, але при цьому не допустити контамінації всієї системи сторонніми бібліотеками та файлами.

Далі наводиться приклад компіляції кількох версій Python тільки для групи verpy, що дещо зручніше, ніж встановлення лише для одного користувача.

• ai - довільний користувач, від якого здійснюється компіляція.
• verpy - група, якою буде дозволено використання.

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

Не вдаючись до подробиць, як саме і чому все організовано, доступ здійснюється по наступному ланцюжку:

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

Основний фронтенд управляє піддоменом gitlab, який закритий для зовнішнього доступу за допомогою авторизації auth_basic.

У цьому прикладі показана установка поверх LXC, тоді як для будь-якого більш-менш серйозного застосування це абсолютно неприйнятно і вимагає використання KVM з додатковими заходами безпеки.
І, крім того, встановлення на KVM буде набагато, набагато простіше.
LXC не забезпечує адекватної безпеки, оскільки для правильної роботи потрібне монтування розділів /sys та /proc з хоста, які доступні всім примірникам LXC.
Крім того, цей приклад потребує використання привілейованого контейнера LXC.
Однак LXC дозволяє легко налаштувати тестову інфраструктуру без накладних витрат, пов’язаних з KVM.
Тому деякі аспекти в цьому прикладі будуть пов’язані виключно з налаштуванням в LXC.

Хост

Спочатку давайте підготуємо хост-систему.

nano /etc/modules

overlay
nf_nat
br_netfilter
xt_conntrack
rbd
fuse
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
iptable_nat

nano /etc/sysctl.d/35-lxc-kubernetes.conf

kernel.dmesg_restrict = 0
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.bridge.bridge-nf-call-iptables = 1
# --conntrack-max-per-core Default: 32768 * N
net.netfilter.nf_conntrack_max=131072
# net.bridge.bridge-nf-call-arptables
# kernel.pid_max=100000
# user.max_user_namespaces=15000
vm.compact_memory = 1
vm.overcommit_memory = 1