Установка Aspia в Docker
Система удаленного доступа Aspia пользуется заслуженной популярностью, но при ее развертывании есть некоторые особенности – пакеты собраны для Ubuntu 20.04 или Debian 11, которые на сегодня являются устаревшими.
Также, по нашим временам, для подобного ПО хочется большей переносимости, чтобы в случае чего можно было быстро мигрировать на новое место.
Для этих целей удобно использовать контейнеры, но официального Docker-образа для Aspia нет, есть неофициальный, созданный одним из участников сообщества, который сам активно использует этот продукт.
Допустим мы разместим проект в /opt/aspia, сразу создадим там две служебные директории для хранения базы данных и конфигов:
Затем создадим docker-compose.yml со следующим содержимым:
Где вам потребуется указать имя хоста узла Aspia и внешний IP-адрес, по которому вы будете принимать внешние подключения.
Если вы переносите уже существующую инсталляцию сразу разместите в папках конфиги и публичный ключ в ./data/config и базу данных в
Сразу после запуска контейнер готов к работе, хотя вы можете произвести более тонкие настройки через конфигурационные файлы.
Наиболее популярный тюнинг – это изменение диапазона ID клиентов, которые по умолчанию начинаются с единицы. Но это не сложно исправить.
Останавливаем службу:
Устанавливаем sqlite:
Подключаемся к базе и правим нужную запись:
В нашем случае мы установили начальное значение 3000. Обратите внимание, что это нужно сделать до того, как вы начали подключать клиентов.
После чего снова запускаем службу, сервер Aspia готов к работе.
Система удаленного доступа Aspia пользуется заслуженной популярностью, но при ее развертывании есть некоторые особенности – пакеты собраны для Ubuntu 20.04 или Debian 11, которые на сегодня являются устаревшими.
Также, по нашим временам, для подобного ПО хочется большей переносимости, чтобы в случае чего можно было быстро мигрировать на новое место.
Для этих целей удобно использовать контейнеры, но официального Docker-образа для Aspia нет, есть неофициальный, созданный одним из участников сообщества, который сам активно использует этот продукт.
Допустим мы разместим проект в /opt/aspia, сразу создадим там две служебные директории для хранения базы данных и конфигов:
mkdir -p /opt/aspia/data/{database,config}Затем создадим docker-compose.yml со следующим содержимым:
services:
aspia-server:
image: paprikkafox/aspia-server:latest
container_name: aspia-server
hostname: aspia.example.com
environment:
- EXTERNAL_IP=203.0.113.6
ports:
- "8070:8070"
- "8060:8060"
volumes:
- ./data/database:/var/lib/aspia:rw
- ./data/config:/etc/aspia:rw
restart: always
Где вам потребуется указать имя хоста узла Aspia и внешний IP-адрес, по которому вы будете принимать внешние подключения.
Если вы переносите уже существующую инсталляцию сразу разместите в папках конфиги и публичный ключ в ./data/config и базу данных в
./data/database, в противном случае они будут автоматически созданы при первом запуске.Сразу после запуска контейнер готов к работе, хотя вы можете произвести более тонкие настройки через конфигурационные файлы.
Наиболее популярный тюнинг – это изменение диапазона ID клиентов, которые по умолчанию начинаются с единицы. Но это не сложно исправить.
Останавливаем службу:
docker compose down
Устанавливаем sqlite:
apt install -y sqlite3
Подключаемся к базе и правим нужную запись:
sudo sqlite3 ./data/database/router.db3 "INSERT INTO hosts (id, key) VALUES (3000, 0x53544152544b4559);"
В нашем случае мы установили начальное значение 3000. Обратите внимание, что это нужно сделать до того, как вы начали подключать клиентов.
После чего снова запускаем службу, сервер Aspia готов к работе.
👍21❤5
Как создать копию драйверов текущего ПК не прибегая к сторонним инструментам
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Кроме PowerShell вы также можете использовать DISM:
Или pnputil, что актуально для старых систем, начиная с Windows 7:
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Export-WindowsDriver —Online —Destination F:\Drivers
Кроме PowerShell вы также можете использовать DISM:
dism /online /export-driver /destination: F:\Drivers
Или pnputil, что актуально для старых систем, начиная с Windows 7:
pnputil.exe /export-driver * F:\Drivers
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
👍61❤9⚡5
Evolution free tier от Cloud.ru существенно похудел
Еще в марте 2024 мы писали про бесплатное предложение от Cloud.ru (https://t.me/interface31/2227) основной ценностью которого была бесплатная виртуальная машина с очень неплохими характеристиками.
Единственный момент – в предложение не входил выделенный IP-адрес и его нужно приобретать отдельно, за 149 руб/мес., что вызвало тогда волну критики. Хотя, будем честны, настоящего Free tier ни у кого практически нет.
Здесь же вы получали неплохой VPS по цене всего 149 руб. без существенных ограничений в параметрах и скрытых подводных камней.
Да, по первым порам платформа Evolution не отличалась стабильностью, а техподдержка оставляла желать лучшего и об этом мы тоже писали. Однако ситуация медленно, но, верно, исправлялась.
И вот теперь там подумали и решили, что с халявой пора завязывать и без лишнего шума и пыли виртуалку из доступных бесплатных ресурсов убрали. Хотя само предложение Free tier осталось, но теперь это интересно разве что как демо версия некоторых сервисов.
Так что кто не успел – тот опоздал, а иметь бесплатный сервер для личных, учебных или тестовых нужд в отечественном облаке по нынешним временам – совсем не лишнее.
Еще в марте 2024 мы писали про бесплатное предложение от Cloud.ru (https://t.me/interface31/2227) основной ценностью которого была бесплатная виртуальная машина с очень неплохими характеристиками.
Единственный момент – в предложение не входил выделенный IP-адрес и его нужно приобретать отдельно, за 149 руб/мес., что вызвало тогда волну критики. Хотя, будем честны, настоящего Free tier ни у кого практически нет.
Здесь же вы получали неплохой VPS по цене всего 149 руб. без существенных ограничений в параметрах и скрытых подводных камней.
Да, по первым порам платформа Evolution не отличалась стабильностью, а техподдержка оставляла желать лучшего и об этом мы тоже писали. Однако ситуация медленно, но, верно, исправлялась.
И вот теперь там подумали и решили, что с халявой пора завязывать и без лишнего шума и пыли виртуалку из доступных бесплатных ресурсов убрали. Хотя само предложение Free tier осталось, но теперь это интересно разве что как демо версия некоторых сервисов.
Так что кто не успел – тот опоздал, а иметь бесплатный сервер для личных, учебных или тестовых нужд в отечественном облаке по нынешним временам – совсем не лишнее.
👍6😢5❤3
Vikunja – менеджер задач с открытым исходным кодом
В современном мире без управления задачами обойтись сложно, особенно если у вас в работе более одного проекта. Поэтому менеджеры задач довольно востребованный тип программного обеспечения.
Если вы не хотите приобретать еще одну подписку или вообще хотите посмотреть, как данный тип ПО впишется в ваш рабочий процесс и что вам вообще от него надо, то можно развернуть на собственных мощностях Vikunja.
Установить его очень просто, на официальной страничке выбираете нужный набор ПО, и он генерирует вам готовые конфигурационные файлы. Например, для использования совместно с PostgreSQL вы можете использовать такой docker-compose.yml:
Перед запуском создайте в папке проекта директории и установите на них права:
Понятно, что выставлять в интернет его в таком виде без обратного прокси нельзя, но для посмотреть можно и так.
Теперь переходим по адресу
При этом одни задачи могут блокировать другие, что важно, так как сразу позволяет видеть ошибки в планировании и грамотно перераспределять нагрузку в случае изменения сроков.
А для этого тут есть то, что редко где встречается в бесплатных версиях коммерческих продуктов – диаграмма Ганта, если вы ведете сложный проект с этапами и зависимостями, то без него никак.
Также есть канбан, если вы предпочитаете работать по этой схеме, хотя никто не мешает вам одновременно применять несколько методов.
На первый взгляд выглядит совсем неплохо, и мы быстро накидали в ней нечто похожее на правду.
Но есть и ряд особенностей и недоработок. Самая существенная из них – нельзя одновременно вывести на один экран несколько проектов, общий список дел вы можете увидеть только на обзорной странице.
И ладно бы это касалось только независимых проектов, но это в полной мере относится и ко вложенным, что сильно затрудняет планирование и распределение рабочих ресурсов.
Командная работа тоже построена своеобразно. Вы можете создать команду и попросить пользователей присоединиться к ней, задав каждому свою роль. Создатель команды является ее администратором.
Но вы не можете просто так назначить произвольную задачу участнику команды пока вы не поделитесь с ним проектом целиком, что неудобно, если участником команды является внешний подрядчик и вы не хотите раскрывать ему всю внутреннюю кухню.
В целом продукт производит приятное впечатление, пользоваться можно, но однозначно рекомендовать его мы не можем, недоработки тоже достаточно серьезные и могут существенно затруднить процесс планирования.
Хотя если вы не пользовались раньше менеджерами задач, то Vikunja будет неплохим вариантов для знакомства, во всяком случае вы сможете быстро понять как данное ПО будет работать с вашими процессами и какие инструменты и функции вам нужны, а какие не очень.
В современном мире без управления задачами обойтись сложно, особенно если у вас в работе более одного проекта. Поэтому менеджеры задач довольно востребованный тип программного обеспечения.
Если вы не хотите приобретать еще одну подписку или вообще хотите посмотреть, как данный тип ПО впишется в ваш рабочий процесс и что вам вообще от него надо, то можно развернуть на собственных мощностях Vikunja.
Установить его очень просто, на официальной страничке выбираете нужный набор ПО, и он генерирует вам готовые конфигурационные файлы. Например, для использования совместно с PostgreSQL вы можете использовать такой docker-compose.yml:
services:
vikunja:
image: vikunja/vikunja:2.3.0
environment:
VIKUNJA_SERVICE_PUBLICURL: http://<your-server-ip>:3456/
VIKUNJA_SERVICE_SECRET: 8ea9b4dd84
VIKUNJA_DATABASE_HOST: db
VIKUNJA_DATABASE_PASSWORD: changeme
VIKUNJA_DATABASE_TYPE: postgres
VIKUNJA_DATABASE_USER: vikunja
VIKUNJA_DATABASE_DATABASE: vikunja
ports:
- 3456:3456
volumes:
- ./files:/app/vikunja/files
depends_on:
db:
condition: service_healthy
restart: unless-stopped
db:
image: postgres:18
environment:
POSTGRES_PASSWORD: changeme
POSTGRES_USER: vikunja
volumes:
- ./db:/var/lib/postgresql
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -h localhost -U $$POSTGRES_USER"]
interval: 2s
start_period: 30s
Перед запуском создайте в папке проекта директории и установите на них права:
mkdir files db
chown 1000 files db
Понятно, что выставлять в интернет его в таком виде без обратного прокси нельзя, но для посмотреть можно и так.
Теперь переходим по адресу
http://<your-server-ip>:3456, регистрируемся и смотрим. Все что нужно для работы тут есть. Вы можете создавать проекты любой степени вложенности и размещать в них задачи, сами задачи могут иметь логические связи друг с другом и зависимости.При этом одни задачи могут блокировать другие, что важно, так как сразу позволяет видеть ошибки в планировании и грамотно перераспределять нагрузку в случае изменения сроков.
А для этого тут есть то, что редко где встречается в бесплатных версиях коммерческих продуктов – диаграмма Ганта, если вы ведете сложный проект с этапами и зависимостями, то без него никак.
Также есть канбан, если вы предпочитаете работать по этой схеме, хотя никто не мешает вам одновременно применять несколько методов.
На первый взгляд выглядит совсем неплохо, и мы быстро накидали в ней нечто похожее на правду.
Но есть и ряд особенностей и недоработок. Самая существенная из них – нельзя одновременно вывести на один экран несколько проектов, общий список дел вы можете увидеть только на обзорной странице.
И ладно бы это касалось только независимых проектов, но это в полной мере относится и ко вложенным, что сильно затрудняет планирование и распределение рабочих ресурсов.
Командная работа тоже построена своеобразно. Вы можете создать команду и попросить пользователей присоединиться к ней, задав каждому свою роль. Создатель команды является ее администратором.
Но вы не можете просто так назначить произвольную задачу участнику команды пока вы не поделитесь с ним проектом целиком, что неудобно, если участником команды является внешний подрядчик и вы не хотите раскрывать ему всю внутреннюю кухню.
В целом продукт производит приятное впечатление, пользоваться можно, но однозначно рекомендовать его мы не можем, недоработки тоже достаточно серьезные и могут существенно затруднить процесс планирования.
Хотя если вы не пользовались раньше менеджерами задач, то Vikunja будет неплохим вариантов для знакомства, во всяком случае вы сможете быстро понять как данное ПО будет работать с вашими процессами и какие инструменты и функции вам нужны, а какие не очень.
👍17🤔4❤1😁1👀1
И больше никогда так не делай! Нам приключения не нужны!
Очередные длинные праздники – это повод отдохнуть, а вовсе не то, о чем многие из вас сейчас подумали. Хотя желание поработать в выходные и праздничные дни возникает часто.
Мотивация тут проста и понятна – большинства сотрудников на рабочем месте нет, никто не мешает. Но это же самое обстоятельство может сыграть и против вас. Потому что на рабочем месте нет ни только ваших сотрудников, но и всех других – партнеров, поддержки и т.д. и т.п.
И если вдруг что-то пошло не так – вы окажетесь у разбитого корыта и помощи оказать вам будет некому.
А сегодня вспомнилась одна история, которая произошла как раз в эти самые дни. Один молодой и резкий товарищ решил обновить 1С в небольшой сети розничных магазинов. 1С доработанная, мы протестировали обновление и передали заказчику для развертывания.
Ну что тут может пойти не так? А вот решительно все. Если обновление не содержит технических ошибок, то это не значит, что ошибок не содержит сама учетная система, которые после применения обновления себя проявят.
В этот раз именно так все и вышло. После обеда нам позвонил их директор и попросил принять участие в веселом квесте: на магазинах лезут какие-то ошибки, продавцы психуют, покупатели нервничают, собираются очереди.
К проблеме, кроме нашего героя уже оказался подключен практически весь коллектив фирмы, включая высшее руководство.
Как оказалось, в некоторых карточках товаров были не заполнены или заполнены неправильно некоторые реквизиты, которые до обновления не проверялись, а теперь, в связи с грядущими изменениями законодательства стали нужны, о чем система и сообщала при каждом добавлении товара в чек, заставляя выбирать нужное значение руками.
В общем разобрались и быстро исправили, но выходной день практически всего коллектива был безнадежно испорчен, многим пришлось даже экстренно возвращаться обратно в город с дач и прочих загородных мест отдыха.
В последствии, на оглашении оргвыводу тому самому молодому именно это и поставили на вид, потому что приключения никому не нужны, а вносить изменения перед или на выходных, даже не очень длинных – это верный способ их получить.
Очередные длинные праздники – это повод отдохнуть, а вовсе не то, о чем многие из вас сейчас подумали. Хотя желание поработать в выходные и праздничные дни возникает часто.
Мотивация тут проста и понятна – большинства сотрудников на рабочем месте нет, никто не мешает. Но это же самое обстоятельство может сыграть и против вас. Потому что на рабочем месте нет ни только ваших сотрудников, но и всех других – партнеров, поддержки и т.д. и т.п.
И если вдруг что-то пошло не так – вы окажетесь у разбитого корыта и помощи оказать вам будет некому.
А сегодня вспомнилась одна история, которая произошла как раз в эти самые дни. Один молодой и резкий товарищ решил обновить 1С в небольшой сети розничных магазинов. 1С доработанная, мы протестировали обновление и передали заказчику для развертывания.
Ну что тут может пойти не так? А вот решительно все. Если обновление не содержит технических ошибок, то это не значит, что ошибок не содержит сама учетная система, которые после применения обновления себя проявят.
В этот раз именно так все и вышло. После обеда нам позвонил их директор и попросил принять участие в веселом квесте: на магазинах лезут какие-то ошибки, продавцы психуют, покупатели нервничают, собираются очереди.
К проблеме, кроме нашего героя уже оказался подключен практически весь коллектив фирмы, включая высшее руководство.
Как оказалось, в некоторых карточках товаров были не заполнены или заполнены неправильно некоторые реквизиты, которые до обновления не проверялись, а теперь, в связи с грядущими изменениями законодательства стали нужны, о чем система и сообщала при каждом добавлении товара в чек, заставляя выбирать нужное значение руками.
В общем разобрались и быстро исправили, но выходной день практически всего коллектива был безнадежно испорчен, многим пришлось даже экстренно возвращаться обратно в город с дач и прочих загородных мест отдыха.
В последствии, на оглашении оргвыводу тому самому молодому именно это и поставили на вид, потому что приключения никому не нужны, а вносить изменения перед или на выходных, даже не очень длинных – это верный способ их получить.
👍15👌4❤2🤮2😁1
Устраиваете ли вы работы на выходные и в праздники?
Anonymous Poll
20%
Да, идеальное время, никто не мешает
17%
Раньше устраивал, теперь перестал
31%
Когда как
1%
Устраивал, пока не нажил проблем, теперь нет
22%
Нет, на выходных надо отдыхать
4%
У нас подобное прямо запрещено
6%
Нет, но иногда думаю поработать
👎2👍1
Настраиваем скачивание обновлений APT через внешний прокси-сервер
История для наших дней типичная – у заказчика перестали нормально обновляться сервера Linux и если с доступом к репозиториям Debian или Ubuntu проблем не было, то вот с репозиториями Proxmox или Zabbix – ну просто беда.
Проблема не глобальная, с других площадок все нормально работало, провайдер на контакт не шел, рассказывая, что он сам ничего не блокирует и мы со своими претензиями пришли не по адресу.
Ну решение такого вопроса сегодня знает даже воспитанник детского сада – известное слово из трех букв. Но самое очевидное решение не всегда самое оптимальное.
Потому что решение проблемы таким путем требует инфраструктурных решений – развертывания сервера, клиента, настройки выборочной маршрутизации, хотя задача стоит предельно простая – качать обновления APT.
Но если подумать, то найдется другой способ, простой и изящный – поднять прокси-сервер, через который APT умеет работать из коробки. К этому добавим, что классический SOCKS5 не является массовым средством ходить туда, не надо куда и массовых блокировок внутри по нему нет.
Плюс все это очень быстро и просто разворачивается в любом месте. На сервере создаем новую папку проекта и размещаем там
И
Где 203.0.113.92 – адрес вашей площадки и только ей разрешено использовать проски-сервер.
Запускам стек и у нас все готово, а дальше на целевом севере выполняем две команды:
После чего сразу запускаем обновление APT и оно пойдет уже через наш прокси сервер. При этом мы настоятельно рекомендуем использовать в этой настройке именно FQDN,а не IP-адрес.
Это дает гибкость и переносимость. Сам прокси не содержит данных и для его переноса достаточно скопировать на новый узел всего два конфигурационных файла.
История для наших дней типичная – у заказчика перестали нормально обновляться сервера Linux и если с доступом к репозиториям Debian или Ubuntu проблем не было, то вот с репозиториями Proxmox или Zabbix – ну просто беда.
Проблема не глобальная, с других площадок все нормально работало, провайдер на контакт не шел, рассказывая, что он сам ничего не блокирует и мы со своими претензиями пришли не по адресу.
Ну решение такого вопроса сегодня знает даже воспитанник детского сада – известное слово из трех букв. Но самое очевидное решение не всегда самое оптимальное.
Потому что решение проблемы таким путем требует инфраструктурных решений – развертывания сервера, клиента, настройки выборочной маршрутизации, хотя задача стоит предельно простая – качать обновления APT.
Но если подумать, то найдется другой способ, простой и изящный – поднять прокси-сервер, через который APT умеет работать из коробки. К этому добавим, что классический SOCKS5 не является массовым средством ходить туда, не надо куда и массовых блокировок внутри по нему нет.
Плюс все это очень быстро и просто разворачивается в любом месте. На сервере создаем новую папку проекта и размещаем там
docker-compose.yml:services:
dante:
image: n00b1k/dante:1.0.3
container_name: dante
restart: unless-stopped
ports:
- "1080:1080"
volumes:
- ./danted.conf:/etc/danted.conf:ro
И
danted.conf:logoutput: stdout
internal: 0.0.0.0 port=1080
external: eth0
user.privileged: root
user.unprivileged: nobody
clientmethod: none
socksmethod: none
client pass {
from: 203.0.113.92/32 to: 0.0.0.0/0
log: connect disconnect error
}
socks pass {
from: 203.0.113.92/32 to: 0.0.0.0/0
command: bind connect udpassociate
log: connect disconnect error
}
Где 203.0.113.92 – адрес вашей площадки и только ей разрешено использовать проски-сервер.
Запускам стек и у нас все готово, а дальше на целевом севере выполняем две команды:
echo 'Acquire::http::Proxy "socks5h://proxy.example.com:1080";' > /etc/apt/apt.conf.d/80proxy
echo 'Acquire::https::Proxy "socks5h://proxy.example.com:1080";' >> /etc/apt/apt.conf.d/80proxy
После чего сразу запускаем обновление APT и оно пойдет уже через наш прокси сервер. При этом мы настоятельно рекомендуем использовать в этой настройке именно FQDN,а не IP-адрес.
Это дает гибкость и переносимость. Сам прокси не содержит данных и для его переноса достаточно скопировать на новый узел всего два конфигурационных файла.
👍22❤4🤮2
Обновляем Proxmox Backup Server с версии 3 до 4
Каждый раз после выхода новой версии Debian обновляется вся линейка Proxmox, которая основана на этом дистрибутиве. Так после выхода Debian 13 была выпущена новая версия Proxmox Backup Server 4. Время обновления каждый сам выбирает самостоятельно, но мы специально подготовили для вас материал на основе официальной документации и собственного опыта как это сделать максимально удобно и безболезненно.
✅ Читать далее: https://interface31.ru/post/obnovlyaem-proxmox-backup-server-s-versii-3-do-4/
Каждый раз после выхода новой версии Debian обновляется вся линейка Proxmox, которая основана на этом дистрибутиве. Так после выхода Debian 13 была выпущена новая версия Proxmox Backup Server 4. Время обновления каждый сам выбирает самостоятельно, но мы специально подготовили для вас материал на основе официальной документации и собственного опыта как это сделать максимально удобно и безболезненно.
✅ Читать далее: https://interface31.ru/post/obnovlyaem-proxmox-backup-server-s-versii-3-do-4/
1👍30
Правильный ответ на вопрос: в чем особенность диапазонов IP 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24
Данные диапазоны отличаются тем, что предназначены для использования в документации и примерах, когда нужно показать белый IP-адрес. Выделение данных диапазонов регламентируется RFC 5735, и они носят наименования TEST-NET-1, TEST-NET-2 и TEST-NET-3.
Как и диапазоны серых сетей данные адреса не маршрутизируются в сети интернет, также их не следует использовать во внутренних сетях.
Раз уж мы коснулись примеров и документации, то будет уместно вспомнить еще и RFC 2606 который регламентирует выделение доменных зон и имен для тех же самых целей.
Так в качестве примеров и использования в документации зарезервированы следующие домены верхнего уровня:
.test
.example
.invalid
.localhost
При этом следует помнить, что домен .localhost традиционно разрешается в IP-адрес петлевого интерфейса 127.0.0.1 и любое иное его использование будет конфликтовать с реально используемым сценарием.
Для документации рекомендуется использовать домен .example, а домен .test для тестирования и лабораторных сред. Основное назначение домена .invalid – это создание имен, которые очевидно являются недействительными, в тех случаях, когда есть такая явная необходимость.
Также для использования в примерах, когда нужно явно указать некоторое доменное имя зарезервированы домены:
example.com
example.net
example.org
Только эти три и никакие иные. Особенно это касается русскоязычной части сети, где для примеров любят использовать иные имена, которые не являются зарезервированными.
Но если сильно хочется русскоязычный домен, то можно использовать для примеров и документации домен верхнего уровня .испытание (xn--80akhbyknj4f).
Никакие иные адреса и доменные имена в примерах и документации использоваться не должны, особенно если они являются действительными и принадлежат иным владельцам, либо же могут быть выданы или зарегистрированы.
Данные диапазоны отличаются тем, что предназначены для использования в документации и примерах, когда нужно показать белый IP-адрес. Выделение данных диапазонов регламентируется RFC 5735, и они носят наименования TEST-NET-1, TEST-NET-2 и TEST-NET-3.
Как и диапазоны серых сетей данные адреса не маршрутизируются в сети интернет, также их не следует использовать во внутренних сетях.
Раз уж мы коснулись примеров и документации, то будет уместно вспомнить еще и RFC 2606 который регламентирует выделение доменных зон и имен для тех же самых целей.
Так в качестве примеров и использования в документации зарезервированы следующие домены верхнего уровня:
.test
.example
.invalid
.localhost
При этом следует помнить, что домен .localhost традиционно разрешается в IP-адрес петлевого интерфейса 127.0.0.1 и любое иное его использование будет конфликтовать с реально используемым сценарием.
Для документации рекомендуется использовать домен .example, а домен .test для тестирования и лабораторных сред. Основное назначение домена .invalid – это создание имен, которые очевидно являются недействительными, в тех случаях, когда есть такая явная необходимость.
Также для использования в примерах, когда нужно явно указать некоторое доменное имя зарезервированы домены:
example.com
example.net
example.org
Только эти три и никакие иные. Особенно это касается русскоязычной части сети, где для примеров любят использовать иные имена, которые не являются зарезервированными.
Но если сильно хочется русскоязычный домен, то можно использовать для примеров и документации домен верхнего уровня .испытание (xn--80akhbyknj4f).
Никакие иные адреса и доменные имена в примерах и документации использоваться не должны, особенно если они являются действительными и принадлежат иным владельцам, либо же могут быть выданы или зарегистрированы.
1👍30🤮4❤2👎1👀1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👎2🤝2👏1👌1
Маразм крепчал, еноты пели. Серия номер следующая
На прошлой неделе, без лишнего шума и пыли наши законодатели приняли законопроект № 1069392-8 о внесении изменений в КоАП РФ. Дополнив его, между прочим, новой статьей:
И санкции от 10 000 и до 700 000 рублей, в зависимости кто, что и когда. А нормы, на которые ссылается статья относятся к Федеральный закон от 27.07.2006 N 149-ФЗ "Об информации, информационных технологиях и о защите информации", который в части п.10 ст.8 требует:
А способов там немного: номер телефона, ЕСИА, ЕСИА + биометрия и:
Мы опустим тот момент, что закон технически неграмотный и путает аутентификацию и авторизацию. А то, что он абсолютно размытый и резиновый. Да, у нас явно отсекаются зарубежные OAuth-провайдеры и прочие зарубежные системы (Телеграм, Discord и т.д.), но и появляется огромное серое поле.
Вот у меня аутентификация через логин и пароль, а для этого я запрашиваю электронную почту. Является ли использованием пользователем зарубежной почты нарушением? С одной стороны, про почту там ничего не сказано, но и владельцем ее не является гражданин РФ или российское юрлицо.
Любой владелец информационного сайта, не завязанный непосредственно на необходимость как-то идентифицировать пользователей, просто уберет или резко сократит возможности аутентификации до безопасных.
А сегодня у нас в РФ остался только один OAuth-провайдер, который позволяет подключить свой ресурс физическим лицам без дополнительной заморочки – это Яндекс.
Все остальные, включая VK, работают только с юридическими лицами и после длительной юридической процедуры регистраций и согласований.
И даже если владелец ресурса имеет такую возможность, он сто раз подумает, а оно ему надо? Сегодня ты там засветился, а завтра утомишься сдавать отчеты и станешь объектом проверок. Проще выключить все нафиг.
Ну так давайте уйдем в зарубежные/международные зоны и пусть попробуют предъявить. Но это плохая политика, если только ваш сайт действительно не международный. Выявив нарушения и не обнаружив владельца РКН просто добавит ваш сайт в выгрузку и заблокирует к нему доступ.
И вы потеряете большую часть трафика, после чего существование подобного ресурса будет лишено смысла.
Поэтому сегодня отечественные ресурсы оказались между молотом и наковальней, особенно это касается ресурсов информационных. Прямой конвертации пользователей в прибыль тут нет, а риски и издержки растут с каждым днем.
И многим будет проще просто взять и прикрыть это, ставшее опасным хобби, нежели пытаться и дальше лавировать между струями дождя.
На прошлой неделе, без лишнего шума и пыли наши законодатели приняли законопроект № 1069392-8 о внесении изменений в КоАП РФ. Дополнив его, между прочим, новой статьей:
«Статья 13.55. Неисполнение обязанности по проведению авторизации пользователей сети «Интернет» при предоставлении доступа к информации
Неисполнение владельцем сайта и (или) страницы сайта в сети «Интернет … прошедшим авторизацию, обязанности проводить ее в отношении пользователей сети «Интернет», находящихся на территории Российской Федерации, одним из способов, предусмотренных Федеральным законом от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации», в случае, если такая обязанность предусмотрена указанным Федеральным законом
И санкции от 10 000 и до 700 000 рублей, в зависимости кто, что и когда. А нормы, на которые ссылается статья относятся к Федеральный закон от 27.07.2006 N 149-ФЗ "Об информации, информационных технологиях и о защите информации", который в части п.10 ст.8 требует:
10. Владелец сайта и (или) страницы сайта в сети «Интернет… в случае, если доступ к информации, размещенной на его сайте и (или) странице сайта в сети «Интернет» … предоставляется пользователям, прошедшим авторизацию, обязан проводить ее в отношении пользователей, находящихся на территории Российской Федерации, одним из следующих способов:
А способов там немного: номер телефона, ЕСИА, ЕСИА + биометрия и:
с использованием иной информационной системы, обеспечивающей авторизацию пользователей … владельцем которой является гражданин Российской Федерации, не имеющий гражданства другого государства, или российское юридическое лицо.
Мы опустим тот момент, что закон технически неграмотный и путает аутентификацию и авторизацию. А то, что он абсолютно размытый и резиновый. Да, у нас явно отсекаются зарубежные OAuth-провайдеры и прочие зарубежные системы (Телеграм, Discord и т.д.), но и появляется огромное серое поле.
Вот у меня аутентификация через логин и пароль, а для этого я запрашиваю электронную почту. Является ли использованием пользователем зарубежной почты нарушением? С одной стороны, про почту там ничего не сказано, но и владельцем ее не является гражданин РФ или российское юрлицо.
Любой владелец информационного сайта, не завязанный непосредственно на необходимость как-то идентифицировать пользователей, просто уберет или резко сократит возможности аутентификации до безопасных.
А сегодня у нас в РФ остался только один OAuth-провайдер, который позволяет подключить свой ресурс физическим лицам без дополнительной заморочки – это Яндекс.
Все остальные, включая VK, работают только с юридическими лицами и после длительной юридической процедуры регистраций и согласований.
И даже если владелец ресурса имеет такую возможность, он сто раз подумает, а оно ему надо? Сегодня ты там засветился, а завтра утомишься сдавать отчеты и станешь объектом проверок. Проще выключить все нафиг.
Ну так давайте уйдем в зарубежные/международные зоны и пусть попробуют предъявить. Но это плохая политика, если только ваш сайт действительно не международный. Выявив нарушения и не обнаружив владельца РКН просто добавит ваш сайт в выгрузку и заблокирует к нему доступ.
И вы потеряете большую часть трафика, после чего существование подобного ресурса будет лишено смысла.
Поэтому сегодня отечественные ресурсы оказались между молотом и наковальней, особенно это касается ресурсов информационных. Прямой конвертации пользователей в прибыль тут нет, а риски и издержки растут с каждым днем.
И многим будет проще просто взять и прикрыть это, ставшее опасным хобби, нежели пытаться и дальше лавировать между струями дождя.
🤷♂18😢10🔥8😁5❤3
Не было печали – апдейтов накачали
В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.
Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.
Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.
Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.
Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.
Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.
Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
🔥24😱17😢4👀1
Почему пакетная система Linux скорее всего доживает последние дни
Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы.
Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива.
Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду.
Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А.
Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать.
Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива.
В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего.
Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки.
Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может.
Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему.
А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы.
И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника.
В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере.
Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах.
При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте.
И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения.
А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы.
Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива.
Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду.
Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А.
Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать.
Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива.
В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего.
Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки.
Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может.
Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему.
А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы.
И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника.
В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере.
Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах.
При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте.
И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения.
А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
🤔22👍13🤡8❤7👀2
Пакетный ад сложных проектов с зависимостями
Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.
Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.
Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.
Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.
Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.
Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.
Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.
Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».
Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.
Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.
Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.
Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.
И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.
А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».
При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.
В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.
Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.
После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.
Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.
Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.
Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.
Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.
Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.
Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.
Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».
Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.
Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.
Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.
Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.
И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.
А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».
При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.
В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.
Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.
После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
👍16❤4👎3🤣2