Установка основных версий Python на Debian Trixie

22/Декабрь/2025 pythontrixie

Python и Debian 1600x904 debian-python.png
Python и Debian

Очень, очень часто приходится сталкиваться с необходимостью использования определённой версии Питона, например, для torch, или чего-то специфического.
Использовать conda или Docker в связке с nvidia-container-toolkit и потом настраивать образы вроде nvidia/cuda:13.0.1-runtime-ubuntu22.04 мне ощущается противоестесственно, хотя часто так делал.
Да и в контейнере приходится устанавливать дополнительные пакеты.

Проще и удобней собрать всё на хостовой системе, но при этом не допустить контаминации всей системы посторонними библиотеками и исполняемыми файлами.

Далее приводится пример сборки нескольких версий Python только для группы verpy, что несколько удобнее, чем установка только для одного пользователя.

  • ai - произвольный пользователь, от которого осуществляется компиляция.
  • verpy - группа, которой будет разрешено исполнение.
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

Установка основных версий...

Ошибка подключения GitLab Agent: Unauthorized

25/Ноябрь/2025 kubernetesgitlabagentk

Ошибка подключения GitLab Agent 1400x350 kubernetes_gitlab_agent_error.png
Ошибка подключения GitLab Agent

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

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

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

Ошибка подключения GitLab...

Установка Kubernetes на LXC

21/Ноябрь/2025 kubernetesk8slxc

Kubernetes на LXC 1000x1040 kubernetes-on-lxc.png
Kubernetes на LXC

В данном примере показана установка поверх LXC, тогда как для любого более-менее серьезного применения это совершенно неприемлемо и требует использования KVM с дополнительными мерами безопасности.
И, кроме того, установка на KVM будет намного, намного проще.
LXC не обеспечивает адекватной безопасности, поскольку для правильной работы требуется монтирование разделов /sys и /proc с хоста, которые доступны всем экземплярам LXC.
Кроме того, этот пример требует использования ПРИВИЛЕГИРОВАННОГО контейнера LXC.
Однако LXC позволяет относительно легко настроить тестовую инфраструктуру без накладных расходов, связанных с KVM.
Поэтому некоторые аспекты в этом примере будут связаны исключительно с настройкой в ​​LXC.


Хост

Для начала давайте подготовим хост-систему.

nano /etc/modules

1
2
3
4
5
6
7
8
9
10
11
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

1
2
3
4
5
6
7
8
9
10
11
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
Установка Kubernetes на...

Почему стандартные плагины jekyll далеки от идеала

11/Март/2025 jekyllstructured-datanginx

В этой заметке я не буду приводить полный код для всех компонентов, только дам сниппеты и подсказки, на что стоит обратить внимание при сборке сайта на jekyll.

Jekyll Structured Data and sitemap.xml 1535x697 jekyll-structured-data-sitemap-and-nginx.png
Jekyll Structured Data and sitemap.xml

Время модификации файла

Каждая страница имеет как минимум три точки отображения временной отметки в разных файлах, элементах страницы или ответе сервера, и все они должны быть одинаковыми.

  • ld+json "dateModified": "2025-03-07T15:43:42+00:00"
  • sitemap <lastmod>2025-03-07T15:43:42+00:00</lastmod>
  • headres last-modified: Fri, 07 Mar 2025 15:43:42 GMT
Почему стандартные плагины...

Token-based лимитирование количества подключений

22/Июнь/2024 nginx

Nginx - аутентификация на основе токенов 1600x896 nginx_api_token.png
Nginx - аутентификация на основе токенов

Все знают про лимиты количества подключений с одного IP (IP-based), но что делать, если мы хотим ограничить количество подключений к некому API на один токен авторизации?
И не важно, сколько разных IP будет использовано.

Часть конфига nginx:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
map $request_uri $client_token {
    "~*(?i)(token=)([a-f0-9]{32})" $2;      # regex return <32str>
    default                        "";      # Fallback to limit_req_zone:global
}

limit_req_zone  $binary_remote_addr   zone=global:32m       rate=100r/s;    # Rule_1
limit_req_zone  $client_token         zone=tokenlimit:32m   rate=5r/s;      # Rule_2
limit_req       zone=global           burst=25;

server {
        location / {
            index index.html;
            root /var/www/html;
        }
        location = /api {
            index index.html;
            root /var/www/api/html;
            limit_req   zone=tokenlimit   burst=5 nodelay;  # api location
            limit_req   zone=global;                        # Fallback
            limit_req_status              429;              # 503
Token-based лимитирование количества...
Страница 2 из 6