WebArt!
Немножко древнего
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 | |
Обычно решается перезагрузкой системы, но когда (всегда) открыт миллион окон и запущен миллион скриптов поверх десятков смонтированных разделов, перезагружать систему не очень удобный вариант.
Перезапуск модуля wifi...