Мій ВебАрт!
Трохи старовинного
web2.0 стилю
Не багато коду, думок,
фотографій та чарівності. Історія сайту
Приклади
готові до застосування. Перейти до категорії
Електроніка
мікроелектроніка
та всіляка електротехніка. Перейти до категорії
Фотографії
З різних категорій. Переглянути категорію
Дуже, дуже часто доводиться стикатися з необхідністю використання певної версії Пітона, наприклад, для torch, або чогось специфічного.
Використовувати conda або Docker у зв’язці з nvidia-container-toolkit і потім налаштовувати образи наприклад nvidia/cuda:13.0.1-runtime-ubuntu22.04 мені відчувається протиприродно, хоча часто так робив.
Та й у контейнері доводиться встановлювати додаткові пакети.
Простіше і зручніше зібрати все на хостовій системі, але при цьому не допустити контамінації всієї системи сторонніми бібліотеками та файлами.
Далі наводиться приклад компіляції кількох версій Python тільки для групи verpy, що дещо зручніше, ніж встановлення лише для одного користувача.
ai - довільний користувач, від якого здійснюється компіляція.verpy - група, якою буде дозволено використання.mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai
21/Листопад/2025 kubernetesk8slxc
У цьому прикладі показана установка поверх LXC, тоді як для будь-якого більш-менш серйозного застосування це абсолютно неприйнятно і вимагає використання KVM з додатковими заходами безпеки.
І, крім того, встановлення на KVM буде набагато, набагато простіше.
LXC не забезпечує адекватної безпеки, оскільки для правильної роботи потрібне монтування розділів /sys та /proc з хоста, які доступні всім примірникам LXC.
Крім того, цей приклад потребує використання привілейованого контейнера LXC.
Однак LXC дозволяє легко налаштувати тестову інфраструктуру без накладних витрат, пов’язаних з KVM.
Тому деякі аспекти в цьому прикладі будуть пов’язані виключно з налаштуванням в LXC.
Спочатку давайте підготуємо хост-систему.
nano /etc/modules
nano /etc/sysctl.d/35-lxc-kubernetes.conf
1 2 3 4 5 6 7 8 9 10 11 | |
Усі знають про ліміти кількості підключень з одного 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 | |
12/Січень/2024 gdm3xorgkvmsecurity
Абстрактно.
Є якийсь софт, якому потрібні ікси.
Здавалося б, завантажив, встановив, запустив – користуйся.
Але ось, проблема, подібний софт (для мене подібний - абсолютно весь, який не входить у штатний репозиторій Debian) я не хочу запускати:
Крім того, той же браузер для “полазити” по сайтах і браузер для клієнт-банку, це не той же самий браузер, користувач і, іноді, система.
Пункти 1, 2, 4, зараз не розглядаємо, мова йтиме про X.
У Debian при стандартних налаштуваннях системи як display-manager використовується LightDM.
У ньому можна увімкнути listen tcp, але процеси Xorg він запускає від root.
У gdm3 навпаки, за умовчанням, він запускає Xorg від користувача, який логіниться в оточення, але в ньому зламали можливість увімкнути listen tcp.
Точніше залишили можливість вимкнути nolisten tcp,
але не увімкнути listen tcp.
Для цього потрібно відредагувати обгортку над X.
На ноутбуці або через перегрівання, або через тривалу роботу, або через перевантаження каналу кількістю пакетів за секунду pps, виникає помилка.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | |
Зазвичай вирішується перезавантаження системи, але коли (завжди) відкрито мільйон вікон та запущено мільйон скриптів поверх десятків змотованих розділів, перезавантажувати систему не дуже зручний варіант.
Перезапуск модуля wifi...