И больше никогда так не делай! Нам приключения не нужны!
Очередные длинные праздники – это повод отдохнуть, а вовсе не то, о чем многие из вас сейчас подумали. Хотя желание поработать в выходные и праздничные дни возникает часто.
Мотивация тут проста и понятна – большинства сотрудников на рабочем месте нет, никто не мешает. Но это же самое обстоятельство может сыграть и против вас. Потому что на рабочем месте нет ни только ваших сотрудников, но и всех других – партнеров, поддержки и т.д. и т.п.
И если вдруг что-то пошло не так – вы окажетесь у разбитого корыта и помощи оказать вам будет некому.
А сегодня вспомнилась одна история, которая произошла как раз в эти самые дни. Один молодой и резкий товарищ решил обновить 1С в небольшой сети розничных магазинов. 1С доработанная, мы протестировали обновление и передали заказчику для развертывания.
Ну что тут может пойти не так? А вот решительно все. Если обновление не содержит технических ошибок, то это не значит, что ошибок не содержит сама учетная система, которые после применения обновления себя проявят.
В этот раз именно так все и вышло. После обеда нам позвонил их директор и попросил принять участие в веселом квесте: на магазинах лезут какие-то ошибки, продавцы психуют, покупатели нервничают, собираются очереди.
К проблеме, кроме нашего героя уже оказался подключен практически весь коллектив фирмы, включая высшее руководство.
Как оказалось, в некоторых карточках товаров были не заполнены или заполнены неправильно некоторые реквизиты, которые до обновления не проверялись, а теперь, в связи с грядущими изменениями законодательства стали нужны, о чем система и сообщала при каждом добавлении товара в чек, заставляя выбирать нужное значение руками.
В общем разобрались и быстро исправили, но выходной день практически всего коллектива был безнадежно испорчен, многим пришлось даже экстренно возвращаться обратно в город с дач и прочих загородных мест отдыха.
В последствии, на оглашении оргвыводу тому самому молодому именно это и поставили на вид, потому что приключения никому не нужны, а вносить изменения перед или на выходных, даже не очень длинных – это верный способ их получить.
Очередные длинные праздники – это повод отдохнуть, а вовсе не то, о чем многие из вас сейчас подумали. Хотя желание поработать в выходные и праздничные дни возникает часто.
Мотивация тут проста и понятна – большинства сотрудников на рабочем месте нет, никто не мешает. Но это же самое обстоятельство может сыграть и против вас. Потому что на рабочем месте нет ни только ваших сотрудников, но и всех других – партнеров, поддержки и т.д. и т.п.
И если вдруг что-то пошло не так – вы окажетесь у разбитого корыта и помощи оказать вам будет некому.
А сегодня вспомнилась одна история, которая произошла как раз в эти самые дни. Один молодой и резкий товарищ решил обновить 1С в небольшой сети розничных магазинов. 1С доработанная, мы протестировали обновление и передали заказчику для развертывания.
Ну что тут может пойти не так? А вот решительно все. Если обновление не содержит технических ошибок, то это не значит, что ошибок не содержит сама учетная система, которые после применения обновления себя проявят.
В этот раз именно так все и вышло. После обеда нам позвонил их директор и попросил принять участие в веселом квесте: на магазинах лезут какие-то ошибки, продавцы психуют, покупатели нервничают, собираются очереди.
К проблеме, кроме нашего героя уже оказался подключен практически весь коллектив фирмы, включая высшее руководство.
Как оказалось, в некоторых карточках товаров были не заполнены или заполнены неправильно некоторые реквизиты, которые до обновления не проверялись, а теперь, в связи с грядущими изменениями законодательства стали нужны, о чем система и сообщала при каждом добавлении товара в чек, заставляя выбирать нужное значение руками.
В общем разобрались и быстро исправили, но выходной день практически всего коллектива был безнадежно испорчен, многим пришлось даже экстренно возвращаться обратно в город с дач и прочих загородных мест отдыха.
В последствии, на оглашении оргвыводу тому самому молодому именно это и поставили на вид, потому что приключения никому не нужны, а вносить изменения перед или на выходных, даже не очень длинных – это верный способ их получить.
👍12👌4❤2🤮2😁1
Устраиваете ли вы работы на выходные и в праздники?
Anonymous Poll
18%
Да, идеальное время, никто не мешает
16%
Раньше устраивал, теперь перестал
31%
Когда как
1%
Устраивал, пока не нажил проблем, теперь нет
23%
Нет, на выходных надо отдыхать
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-адрес.
Это дает гибкость и переносимость. Сам прокси не содержит данных и для его переноса достаточно скопировать на новый узел всего два конфигурационных файла.
👍18❤3🤮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👍29
Правильный ответ на вопрос: в чем особенность диапазонов 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👍26🤮4❤2👎1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👎2👏1👌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, работают только с юридическими лицами и после длительной юридической процедуры регистраций и согласований.
И даже если владелец ресурса имеет такую возможность, он сто раз подумает, а оно ему надо? Сегодня ты там засветился, а завтра утомишься сдавать отчеты и станешь объектом проверок. Проще выключить все нафиг.
Ну так давайте уйдем в зарубежные/международные зоны и пусть попробуют предъявить. Но это плохая политика, если только ваш сайт действительно не международный. Выявив нарушения и не обнаружив владельца РКН просто добавит ваш сайт в выгрузку и заблокирует к нему доступ.
И вы потеряете большую часть трафика, после чего существование подобного ресурса будет лишено смысла.
Поэтому сегодня отечественные ресурсы оказались между молотом и наковальней, особенно это касается ресурсов информационных. Прямой конвертации пользователей в прибыль тут нет, а риски и издержки растут с каждым днем.
И многим будет проще просто взять и прикрыть это, ставшее опасным хобби, нежели пытаться и дальше лавировать между струями дождя.
🤷♂17😢10🔥8😁5❤2
Не было печали – апдейтов накачали
В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.
Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.
Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.
Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.
Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.
Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.
Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
🔥23😱14😢4
Почему пакетная система 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), многие вообще не подразумевают других путей распространения.
А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
🤔21👍11🤡8❤7👀1
Пакетный ад сложных проектов с зависимостями
Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.
Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.
Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.
Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.
Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.
Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.
Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.
Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».
Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.
Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.
Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.
Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.
И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.
А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».
При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.
В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.
Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.
После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.
Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.
Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.
Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.
Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.
Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.
Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.
Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».
Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.
Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.
Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.
Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.
И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.
А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».
При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.
В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.
Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.
После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
👍15❤3👎2🤣2
Атомарность – будущее Linux
Этот вопрос волнует многих, и пользователей и, тем более, администраторов. Давайте попробуем разобраться в чем преимущество атомарности.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
Этот вопрос волнует многих, и пользователей и, тем более, администраторов. Давайте попробуем разобраться в чем преимущество атомарности.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
👍22🤔6👎3❤1🤮1
Не прошло и полгода…
Совсем не неожиданно, а очень даже наоборот, второй ведущий почтовый Mail.ru прекратил поддержку сторонних почтовых клиентов на бесплатных тарифах. В веб-интерфейсе с почтой можно по-прежнему работать без ограничений.
При этом совсем недавно на аналогичный шаг пошел Яндекс, о чем мы совсем недавно писали: https://t.me/interface31/6266
Какие варианты? Да никаких, достаем кошелек и оплачиваем. Ну или начинаем увлекательный квест под названием «сам себе почтовый хостер», что тоже не самый лучший вариант.
Совсем не неожиданно, а очень даже наоборот, второй ведущий почтовый Mail.ru прекратил поддержку сторонних почтовых клиентов на бесплатных тарифах. В веб-интерфейсе с почтой можно по-прежнему работать без ограничений.
При этом совсем недавно на аналогичный шаг пошел Яндекс, о чем мы совсем недавно писали: https://t.me/interface31/6266
Какие варианты? Да никаких, достаем кошелек и оплачиваем. Ну или начинаем увлекательный квест под названием «сам себе почтовый хостер», что тоже не самый лучший вариант.
🤣15😁3🤬3
Как правильно работать с резервным копированием в облаке?
25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.
⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.
⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.
⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.
Зарегистрируйтесь, чтобы не пропустить!
⏰ 25 июня в 14:00 (мск)
✅ Зарегистрироваться
Реклама. ООО "МВС ОБЛАЧНЫЕ РЕШЕНИЯ". ИНН 7841468537. erid: 2W5zFH1pTJh
25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.
⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.
⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.
⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.
Зарегистрируйтесь, чтобы не пропустить!
⏰ 25 июня в 14:00 (мск)
✅ Зарегистрироваться
Реклама. ООО "МВС ОБЛАЧНЫЕ РЕШЕНИЯ". ИНН 7841468537. erid: 2W5zFH1pTJh
❤1👍1🔥1🤮1🍌1
Про желания и возможности
В обсуждениях снова и снова возникают вопросы про покупку ресурсов.
Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.
Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.
Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.
Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.
Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.
Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.
Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.
Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.
Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.
Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.
Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.
Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.
А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.
Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.
Очень часто можно услышать: да что-там своя почта, делов то…
А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.
Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.
Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.
Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.
И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.
Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.
Вы именно такой специалист? А что вы до сих пор здесь сидите? Вас ждут великие дела.
В обсуждениях снова и снова возникают вопросы про покупку ресурсов.
Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.
Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.
Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.
Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.
Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.
Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.
Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.
Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.
Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.
Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.
Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.
Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.
А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.
Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.
Очень часто можно услышать: да что-там своя почта, делов то…
А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.
Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.
Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.
Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.
И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.
Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.
Вы именно такой специалист? А что вы до сих пор здесь сидите? Вас ждут великие дела.
👍28👎8💯2❤1🥱1
Скот, а не питомцы
В комментариях снова задали вопрос использования десктопного железа в IT-инфраструктуре взамен брендового. Админы, особенно старой школы, обычно вздыхают и сетуя на санкции, курс доллара и отсутствие у бизнеса нужного количества денег говорят, что мол приходится и с десктопным…
Но на самом деле это однобокий и устаревший взгляд на проблему. Сегодня уже практически никто не гоняет продуктивную нагрузку на голом железе – это дурной тон и признак ретроградства. Сегодня на железе стоит исключительно гипервизор/оркестратор и больше ничего. Широко в ходу концепция «чистого хоста».
Нагрузка в 2026 вся виртуализированна и это даже не виртуальные машины, а контейнеры, чаще всего легковесные (OCI). Но даже при использовании более тяжелых LXC или даже полноценных виртуалок такая инфраструктура прекрасно масштабируется горизонтально.
Дорогое серверное железо горизонтально столь же легко не масштабируется, по вполне понятным финансовым причинам и представляет собой единую точку отказа. Выход из строя такого устройства – ситуация аварийная и крайне болезненная для бизнеса.
По сути, перед нами питомец, который имеет свой характер, свои особенности, свои настройки, которого мы холим, лечим, лечим и т.д. Болезнь питомца – горе в семье. Питомцы дороги в содержании, на них не сэкономишь.
Но с переходом нагрузки от монолитов к микросервисам или гибридам мы можем заменить два дорогих брендовых сервера на штук пять хороших, мощных настольных ПК и собрать на них HA-кластер. Сегодня это доступно даже самым маленьким, тот же Proxmox VE в последней версии научился динамически распределять нагрузку на ноды.
И что мы получаем? А получаем не только удешевление владения, но и смену парадигмы. У нас скот, а не питомцы. Да, скот тоже нужно кормить и поить, но коту не покупают корм в пакетиках, а просто кормят сеном или силосом.
И скот безлик. Вам уже тоже все равно на какие-то особенности систем, все они безлики, это типичный хост с Proxmox (условно). Там нет индивидуальных настроек, там все типовое и унифицированное. Вы можете спокойно раскатывать новые конфигурации через Ansible или Terraform.
Ваша инфраструктура больше не завязана на железо и его особенности. Она перешла в декларативную форму – инфраструктура как код (IaC). Вы описываете не настройки, а конечное состояние, которое требуется получить.
Сервер перестает быть сервером, теперь это просто нода, одна из многих. Нет никакого смысла наделять ее индивидуальностью, заниматься персональными настройками и т.д. и т.п.
Сломалась, упала? Да и пес с ней, пусть лежит, утром разберемся, полезная нагрузка все равно уже распределилась по другим узлам и никакой спешки нет.
А утром мы просто достанем со склада (или купим в ближайшем ДНС или Ситилинк) простой ПК с нужными характеристиками и заменим им выбывший. И даже настраивать его персонально не придется, нужное состояние у нас уже описано, нужно только применить.
Заметьте, мы не пытаемся лечить, восстанавливать или что-то еще делать с «заболевшим», мы просто меняем его на «здоровый», разбираться будем потом. Если будем. А попробуйте провернуть такой фокус с брендовым сервером?
Причем мы сейчас не придумали ничего нового, он давно применяется гигантами, в частности Google и Facebook, последние вообще стали основателями Open Compute Project (OCP) – смысл которого – это замена дорогих и закрытых систем на простые, недорогие, унифицированные.
Вместе с этим меняется и отношение к проектированию инфраструктуры, с переходом к концепции Design for Failure (проектирование для отказов), мы больше не исходим из того, что наша техника надежна, наоборот, мы точно знаем, что она сломается и делаем так, чтобы мы могли спокойно заменить один кирпичик другим.
Мы не собираемся никому ничего навязывать, каждый волен поступать как вздумается, но, возможно, пора оглянуться, мир меняется и вместе с ним меняются подходы. И то, что вчера было мейнстримом, сегодня уже устарело, а вчерашние смелые проекты становятся новыми нормами.
В комментариях снова задали вопрос использования десктопного железа в IT-инфраструктуре взамен брендового. Админы, особенно старой школы, обычно вздыхают и сетуя на санкции, курс доллара и отсутствие у бизнеса нужного количества денег говорят, что мол приходится и с десктопным…
Но на самом деле это однобокий и устаревший взгляд на проблему. Сегодня уже практически никто не гоняет продуктивную нагрузку на голом железе – это дурной тон и признак ретроградства. Сегодня на железе стоит исключительно гипервизор/оркестратор и больше ничего. Широко в ходу концепция «чистого хоста».
Нагрузка в 2026 вся виртуализированна и это даже не виртуальные машины, а контейнеры, чаще всего легковесные (OCI). Но даже при использовании более тяжелых LXC или даже полноценных виртуалок такая инфраструктура прекрасно масштабируется горизонтально.
Дорогое серверное железо горизонтально столь же легко не масштабируется, по вполне понятным финансовым причинам и представляет собой единую точку отказа. Выход из строя такого устройства – ситуация аварийная и крайне болезненная для бизнеса.
По сути, перед нами питомец, который имеет свой характер, свои особенности, свои настройки, которого мы холим, лечим, лечим и т.д. Болезнь питомца – горе в семье. Питомцы дороги в содержании, на них не сэкономишь.
Но с переходом нагрузки от монолитов к микросервисам или гибридам мы можем заменить два дорогих брендовых сервера на штук пять хороших, мощных настольных ПК и собрать на них HA-кластер. Сегодня это доступно даже самым маленьким, тот же Proxmox VE в последней версии научился динамически распределять нагрузку на ноды.
И что мы получаем? А получаем не только удешевление владения, но и смену парадигмы. У нас скот, а не питомцы. Да, скот тоже нужно кормить и поить, но коту не покупают корм в пакетиках, а просто кормят сеном или силосом.
И скот безлик. Вам уже тоже все равно на какие-то особенности систем, все они безлики, это типичный хост с Proxmox (условно). Там нет индивидуальных настроек, там все типовое и унифицированное. Вы можете спокойно раскатывать новые конфигурации через Ansible или Terraform.
Ваша инфраструктура больше не завязана на железо и его особенности. Она перешла в декларативную форму – инфраструктура как код (IaC). Вы описываете не настройки, а конечное состояние, которое требуется получить.
Сервер перестает быть сервером, теперь это просто нода, одна из многих. Нет никакого смысла наделять ее индивидуальностью, заниматься персональными настройками и т.д. и т.п.
Сломалась, упала? Да и пес с ней, пусть лежит, утром разберемся, полезная нагрузка все равно уже распределилась по другим узлам и никакой спешки нет.
А утром мы просто достанем со склада (или купим в ближайшем ДНС или Ситилинк) простой ПК с нужными характеристиками и заменим им выбывший. И даже настраивать его персонально не придется, нужное состояние у нас уже описано, нужно только применить.
Заметьте, мы не пытаемся лечить, восстанавливать или что-то еще делать с «заболевшим», мы просто меняем его на «здоровый», разбираться будем потом. Если будем. А попробуйте провернуть такой фокус с брендовым сервером?
Причем мы сейчас не придумали ничего нового, он давно применяется гигантами, в частности Google и Facebook, последние вообще стали основателями Open Compute Project (OCP) – смысл которого – это замена дорогих и закрытых систем на простые, недорогие, унифицированные.
Вместе с этим меняется и отношение к проектированию инфраструктуры, с переходом к концепции Design for Failure (проектирование для отказов), мы больше не исходим из того, что наша техника надежна, наоборот, мы точно знаем, что она сломается и делаем так, чтобы мы могли спокойно заменить один кирпичик другим.
Мы не собираемся никому ничего навязывать, каждый волен поступать как вздумается, но, возможно, пора оглянуться, мир меняется и вместе с ним меняются подходы. И то, что вчера было мейнстримом, сегодня уже устарело, а вчерашние смелые проекты становятся новыми нормами.
1👍37👎4💯2❤1
Атомарность на серверах Linux. Да или нет?
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
👍19❤4👎3👌2👀1
Можно вечно смотреть на горящий огонь, бегущую воду, как работают люди и как инициализируется ЛМ ЧЗ.
И, твою дивизию, ведь все это уже когда-то проходили. Первые версии ЛМ ЧЗ инициализировались долго и не с первого раза. Потом проблему пофиксили и все стало хорошо.
Но теперь на смену ветке 1.х пришла ветка 2.х и ее, что, писали новые пионеры? Которые были не в курсе проблем старых?
В общем - готовьтесь снова развлекаться с ЛМ ЧЗ, как будто новых развлечений с ПИоТ нам мало.
И, твою дивизию, ведь все это уже когда-то проходили. Первые версии ЛМ ЧЗ инициализировались долго и не с первого раза. Потом проблему пофиксили и все стало хорошо.
Но теперь на смену ветке 1.х пришла ветка 2.х и ее, что, писали новые пионеры? Которые были не в курсе проблем старых?
В общем - готовьтесь снова развлекаться с ЛМ ЧЗ, как будто новых развлечений с ПИоТ нам мало.
🤣9👍7❤2🤮2
Не было печали, купила баба порося
Тестовую эксплуатацию ПИоТ можно охарактеризовать именно этой народной поговоркой, разве что «порося» купить заставили добровольно-принудительно.
Какие-то серьезные выводы делать пока рано, но забот у поддержки явно прибавится, причем тех, которых раньше не было, а все старые проблемы Честного знака останутся.
Ну и не перестает покидать ощущение, что ПИоТ – это в первую очередь за деньги, потому что маниакально проверяет свою лицензию чуть ли не в реальном времени и чуть что перестает работать, ссылаясь на ее отсутствие.
При этом четкой ясности по дате 1 июля нет, но до сих пор остаются кассы, которые не готовы к ПИоТ (РР, которые бывший Штрих) и технически отозвать с 1 июля розничный токен не получится, значит и у остальных появится возможность работать по-старому.
Другое дело, что с этим можно будет легко бороться административными методами. В общем, поживем увидим. А пока надо быть готовым к любому раскладу.
Тестовую эксплуатацию ПИоТ можно охарактеризовать именно этой народной поговоркой, разве что «порося» купить заставили добровольно-принудительно.
Какие-то серьезные выводы делать пока рано, но забот у поддержки явно прибавится, причем тех, которых раньше не было, а все старые проблемы Честного знака останутся.
Ну и не перестает покидать ощущение, что ПИоТ – это в первую очередь за деньги, потому что маниакально проверяет свою лицензию чуть ли не в реальном времени и чуть что перестает работать, ссылаясь на ее отсутствие.
При этом четкой ясности по дате 1 июля нет, но до сих пор остаются кассы, которые не готовы к ПИоТ (РР, которые бывший Штрих) и технически отозвать с 1 июля розничный токен не получится, значит и у остальных появится возможность работать по-старому.
Другое дело, что с этим можно будет легко бороться административными методами. В общем, поживем увидим. А пока надо быть готовым к любому раскладу.
👍10🤣3👌1
Спрашивают – отвечаем. Надо ли заземлять экран витой пары?
Очень часто задают вопрос – надо ли заземлять экран витой пары ScTP, FTP, SFTP и как именно это делать. Кто-то говорит, что это необязательно, кто-то предлагает заземлять только с одного конца. Так кого же слушать?
А слушать надо то, что говорят стандарты. И сегодня нам на помощь придёт ГОСТ Р 53246-2008 СИСТЕМЫ КАБЕЛЬНЫЕ СТРУКТУРИРОВАННЫЕ Проектирование основных узлов системы. Общие требования.
Итак, что нам говорит стандарт про экранированную витую пару:
Итак. Экран нужен нам для защиты как от внешних, так и внутренних помех, но его эффективность завит от многих факторов, в т.ч. и от тщательности монтажа.
Но одним экранированным кабелем дело не обходится, снова читаем стандарт:
Поэтому кроме экранированного кабеля нам еще понадобится экранированное оборудование, способное терминировать экранированные кабели и обеспечивать непрерывность экрана.
Т.е. вам понадобятся еще экранированные коннекторы, патч-панели, розетки и активное сетевое оборудование, поддерживающее работу с экранированными кабелями.
При этом стандарт прямо запрещает создание патч-кордов и коммутационных перемычек на основе экранированной витой пары в полевых условиях.
Таким образом вывод можно сделать однозначный: применение экранированной витой пары требует ее сочетания с экранированным сетевым оборудованием и требует обязательного обеспечения непрерывности экрана.
☝️ Т.е. оставить экран кабеля не подключенным к экрану коннектора или патч-панели нельзя!
Неподключенный экран в некоторых ситуациях способен работать в качестве большой антенны и дополнительно собирать на себя наводки.
С экраном разобрались, но пока ни слова не было сказано о заземлении. Вообще, для работы экрана заземление как таковое не нужно, достаточно того, чтобы он был подключен в точку с постоянным потенциалом. Поэтому в стандарте говорится о системах заземления и уравнивания потенциалов.
А вот здесь мы вступаем на скользкую тропу электротехники и вторгаемся в отрасль весьма далекую от администрирования. Поэтому попробуем по-простому.
Именно заземление является самым простым и надежным способом обеспечить точку с постоянным потенциалом, которая нужна для работы экрана. В идеале – это иметь отдельную шину заземления для коммуникационного оборудования, т.н. информационную землю.
На практике же бывает разное, очень разное. Это и отдельные шины заземления в разных частях здания или предприятия, и зануление вместо заземления, да и просто не соответствующие стандарту заземление.
К чему это может привести? А к тому, что между двумя точками земли может оказаться разность потенциалов и по экрану потечет ток, со всеми вытекающими. Именно поэтому существует совет заземлять кабель только с одной стороны. Либо подключать экран к земле через емкость.
Но повторюсь еще раз – здесь мы выходим за рамки администрирования и данный вопрос следует решать с ответственными за это сотрудниками.
Очень часто задают вопрос – надо ли заземлять экран витой пары ScTP, FTP, SFTP и как именно это делать. Кто-то говорит, что это необязательно, кто-то предлагает заземлять только с одного конца. Так кого же слушать?
А слушать надо то, что говорят стандарты. И сегодня нам на помощь придёт ГОСТ Р 53246-2008 СИСТЕМЫ КАБЕЛЬНЫЕ СТРУКТУРИРОВАННЫЕ Проектирование основных узлов системы. Общие требования.
Итак, что нам говорит стандарт про экранированную витую пару:
Экранирование проводников кабеля помогает улучшить защиту от электромагнитного излучения, создаваемого носителями сигналов, и невосприимчивость к воздействию электромагнитных помех от внешних источников.
Способность экрана создавать определенные преимущества для кабельной системы зависит от множества факторов. К этим факторам можно отнести рабочие характеристики компонентов кабельной системы, специфические методы и тщательность монтажа, а также конструктивные особенности и способы подключения активного оборудования.
Итак. Экран нужен нам для защиты как от внешних, так и внутренних помех, но его эффективность завит от многих факторов, в т.ч. и от тщательности монтажа.
Но одним экранированным кабелем дело не обходится, снова читаем стандарт:
Экранированное коммутационное оборудование предназначено для терминирования экранированных кабелей типов ScTP/FTP и S/FTP на основе витой пары проводников с волновым сопротивлением 100 Ом.
Для обеспечения эффективности экранирования системы требуется сохранение непрерывности экрана во всех компонентах кабельных подсистем в моделях линий и каналов, а также подключение экранов к телекоммуникационной системе заземления и уравнивание потенциалов в соответствии с требованиями нормативных документов.
Поэтому кроме экранированного кабеля нам еще понадобится экранированное оборудование, способное терминировать экранированные кабели и обеспечивать непрерывность экрана.
Т.е. вам понадобятся еще экранированные коннекторы, патч-панели, розетки и активное сетевое оборудование, поддерживающее работу с экранированными кабелями.
При этом стандарт прямо запрещает создание патч-кордов и коммутационных перемычек на основе экранированной витой пары в полевых условиях.
Таким образом вывод можно сделать однозначный: применение экранированной витой пары требует ее сочетания с экранированным сетевым оборудованием и требует обязательного обеспечения непрерывности экрана.
☝️ Т.е. оставить экран кабеля не подключенным к экрану коннектора или патч-панели нельзя!
Неподключенный экран в некоторых ситуациях способен работать в качестве большой антенны и дополнительно собирать на себя наводки.
С экраном разобрались, но пока ни слова не было сказано о заземлении. Вообще, для работы экрана заземление как таковое не нужно, достаточно того, чтобы он был подключен в точку с постоянным потенциалом. Поэтому в стандарте говорится о системах заземления и уравнивания потенциалов.
А вот здесь мы вступаем на скользкую тропу электротехники и вторгаемся в отрасль весьма далекую от администрирования. Поэтому попробуем по-простому.
Именно заземление является самым простым и надежным способом обеспечить точку с постоянным потенциалом, которая нужна для работы экрана. В идеале – это иметь отдельную шину заземления для коммуникационного оборудования, т.н. информационную землю.
На практике же бывает разное, очень разное. Это и отдельные шины заземления в разных частях здания или предприятия, и зануление вместо заземления, да и просто не соответствующие стандарту заземление.
К чему это может привести? А к тому, что между двумя точками земли может оказаться разность потенциалов и по экрану потечет ток, со всеми вытекающими. Именно поэтому существует совет заземлять кабель только с одной стороны. Либо подключать экран к земле через емкость.
Но повторюсь еще раз – здесь мы выходим за рамки администрирования и данный вопрос следует решать с ответственными за это сотрудниками.
⚡11💯10👍9❤6