Настраиваем Fail2Ban для совместной работы с брандмауэром Mikrotik
Fail2Ban - давно зарекомендовавшее себя решение для Linux систем, позволяющее эффективно выявлять и блокировать вредоносную активность, такую как подбор паролей или поиск уязвимостей.
Но как быть, если защищаемые узлы находятся внутри сетевого периметра, а на внешнем контуре находится роутер Mikrotik?
Ведь хотелось бы управлять блокировками на уровне всей сети, а не отдельного узла.
Нет ничего сложного, в этой статье мы расскажем как быстро и просто обеспечить совместную работу этих двух популярных продуктов.
https://interface31.ru/tech_it/2024/09/nastraivaem-fail2ban-dlya-sovmestnoy-raboty-s-brandmauerom-mikrotik.html
Fail2Ban - давно зарекомендовавшее себя решение для Linux систем, позволяющее эффективно выявлять и блокировать вредоносную активность, такую как подбор паролей или поиск уязвимостей.
Но как быть, если защищаемые узлы находятся внутри сетевого периметра, а на внешнем контуре находится роутер Mikrotik?
Ведь хотелось бы управлять блокировками на уровне всей сети, а не отдельного узла.
Нет ничего сложного, в этой статье мы расскажем как быстро и просто обеспечить совместную работу этих двух популярных продуктов.
https://interface31.ru/tech_it/2024/09/nastraivaem-fail2ban-dlya-sovmestnoy-raboty-s-brandmauerom-mikrotik.html
👍27❤2
Настраиваем мониторинг Proxmox Virtual Environment при помощи Zabbix
Виртуализация сегодня плотно вошла в нашу жизнь и гипервизор давно стал объектом высокой степени важности, так как от его работы зависит множество различных сервисов.
Поэтому очень важно держать руку на пульсе и своевременно получать данные о состоянии гипервизора и виртуальных машин. В этом нам поможет система мониторинга Zabbix.
В данной статье мы рассмотрим, как настроить интеграцию Proxmox и Zabbix чтобы начать получать все необходимые данные о состоянии гипервизора и виртуальных машин.
https://interface31.ru/tech_it/2024/08/nastraivaem-monitoring-proxmox-virtual-environment-pri-pomoshhi-zabbix.html
Виртуализация сегодня плотно вошла в нашу жизнь и гипервизор давно стал объектом высокой степени важности, так как от его работы зависит множество различных сервисов.
Поэтому очень важно держать руку на пульсе и своевременно получать данные о состоянии гипервизора и виртуальных машин. В этом нам поможет система мониторинга Zabbix.
В данной статье мы рассмотрим, как настроить интеграцию Proxmox и Zabbix чтобы начать получать все необходимые данные о состоянии гипервизора и виртуальных машин.
https://interface31.ru/tech_it/2024/08/nastraivaem-monitoring-proxmox-virtual-environment-pri-pomoshhi-zabbix.html
👍36🤷♂1
Debian 13 еще не вышел и только-только вошел в стадию полной заморозки пакетов (27 июля), релиз назначен на 9 августа. Но Proxmox уже сегодня представил Proxmox VE 9.0.
Стремление быть впереди прогресса конечно же радует, но ровно до тех пор, пока не вспомнишь что на гипервизор зачастую завязаны критические узлы инфраструктуры.
Конечно, хочется надеяться, что Debian 13 учтет ошибки прошлого релиза, когда сами разработчики признали его фактически тестовым и не рекомендовали обновлять производственные среды до выхода Debian 12.1.
Но в любом случае бросать все и переходить на новую версию гипервизора мы не советуем. А вот в лабораторных условиях развернуть и протестировать можно, но не более, примерно до выхода Proxmox VE 9.1.
Стремление быть впереди прогресса конечно же радует, но ровно до тех пор, пока не вспомнишь что на гипервизор зачастую завязаны критические узлы инфраструктуры.
Конечно, хочется надеяться, что Debian 13 учтет ошибки прошлого релиза, когда сами разработчики признали его фактически тестовым и не рекомендовали обновлять производственные среды до выхода Debian 12.1.
Но в любом случае бросать все и переходить на новую версию гипервизора мы не советуем. А вот в лабораторных условиях развернуть и протестировать можно, но не более, примерно до выхода Proxmox VE 9.1.
1👍35👀4👌2❤1
Zabbix - сложная система и у начинающего пользователя часто разбегаются глаза и он теряется среди новых для него терминов и обилия информации.
Поэтому, прежде чем браться за ее освоение, нужно изучить базовые понятия и основы построения системы, чтобы понимать из каких элементов, как из кирпичиков, строится мониторинг.
Данная статься рассчитана на начинающих, но также будет полезна и тем, кто уже работает с Zabbix так как поможет освежить и систематизировать знания, а может быть даже и узнать что-то новое.
https://interface31.ru/tech_it/2024/09/zabbix-osnovy-i-bazovye-ponyatiya.html
Поэтому, прежде чем браться за ее освоение, нужно изучить базовые понятия и основы построения системы, чтобы понимать из каких элементов, как из кирпичиков, строится мониторинг.
Данная статься рассчитана на начинающих, но также будет полезна и тем, кто уже работает с Zabbix так как поможет освежить и систематизировать знания, а может быть даже и узнать что-то новое.
https://interface31.ru/tech_it/2024/09/zabbix-osnovy-i-bazovye-ponyatiya.html
👍34❤2
Их нравы
Читаю тут новости и не перестаю удивляться. Есть одна широко известная компания, которую принято всячески ругать за телеметрию. Но заметка не об этом.
Ну это же просто праздник какой-то! Выделил текст в любом приложении, и он уже по незащищенному HTTP-протоколу потопал на сайт китайских товарищей. А если вы еще используете публичные КВН и тому подобное баловство – то еще и успел осесть по дороге.
Пароли? Банковские данные? Конфиденциальная информация? Ну да, достаточно просто выделить.
Зачем большинству пользователей англо-китайские словари – загадка, но так как сопровождающий – китаец, то он так решил. И вообще, он художник, он так видит.
Кстати, подобное поведение в 2009 году было признано уязвимостью (CVE-2009-2260), но сейчас, видимо, настали совсем другие времена и это стало новой нормальностью.
В общем все идет к тому, что было на заре широкополосного интернета, когда он оплачивался помегабайтно. Тогда каждый первый ставил на ПК персональный брандмауэр, в котором выборочно разрешал приложениям выход во всемирную сеть.
Теперь, похоже, надо снова что-то аналогичное, но только совсем по другой причине.
✅ Источник новости: https://www.opennet.ru/opennews/art.shtml?num=63677
Читаю тут новости и не перестаю удивляться. Есть одна широко известная компания, которую принято всячески ругать за телеметрию. Но заметка не об этом.
В предлагаемом в репозитории Debian Testing (будущий релиз Debian 13) пакете StarDict, реализующем интерфейс для поиска в словарях, выявлена проблема с конфиденциальностью - в конфигурации по умолчанию приложение отправляет автоматически помещаемый в буфер обмена выделенный текст (x11 PRIMARY selection) на внешние серверы. Достаточно в любом приложении выделить отрывок текста, и он сразу отправляется без шифрования по протоколу HTTP на китайские серверы online-словарей dict.youdao.com и dict.cn.
Ну это же просто праздник какой-то! Выделил текст в любом приложении, и он уже по незащищенному HTTP-протоколу потопал на сайт китайских товарищей. А если вы еще используете публичные КВН и тому подобное баловство – то еще и успел осесть по дороге.
Пароли? Банковские данные? Конфиденциальная информация? Ну да, достаточно просто выделить.
Сопровождающий пакет StarDict в Debian ответил, что подобное поведение является штатным. По умолчанию в StarDict включён режим автоматического поиска в словарях выделенного текста и активированы как локальные, так и внешние словари. Серверы dict.youdao.com и dict.cn предоставляют англо-китайские словари, включаемые по умолчанию.
Зачем большинству пользователей англо-китайские словари – загадка, но так как сопровождающий – китаец, то он так решил. И вообще, он художник, он так видит.
Кстати, подобное поведение в 2009 году было признано уязвимостью (CVE-2009-2260), но сейчас, видимо, настали совсем другие времена и это стало новой нормальностью.
В общем все идет к тому, что было на заре широкополосного интернета, когда он оплачивался помегабайтно. Тогда каждый первый ставил на ПК персональный брандмауэр, в котором выборочно разрешал приложениям выход во всемирную сеть.
Теперь, похоже, надо снова что-то аналогичное, но только совсем по другой причине.
✅ Источник новости: https://www.opennet.ru/opennews/art.shtml?num=63677
😱24🔥14👍7❤4👌3
Linux, пакеты, доверие
Каждый раз, говоря об открытом ПО в пример ставится его большая безопасность, проистекающая из открытости. Мол, тысячи глаз следят, тысячи рук исправят…
В целом разумное зерно в этом есть, но не более. Людей, способных читать код на уровне достаточном для нахождения уязвимостей и прочей вредоносной активности – единицы. Еще меньше будет желающих посвятить этому занятию свое время.
Поэтому поиском уязвимостей занимаются в основном энтузиасты, злоумышленники и специалисты по безопасности.
Мы же в свою очередь рассмотрим спектр угроз для простого пользователя Linux, а также возможные варианты противодействия им.
Начнем с самого начала – исходного кода. Код принадлежит автору и обычно расположен в его репозитории. Мы вольны изучать, собирать и изменять его в той мере, в которой это не противоречит лицензии.
Автор также волен вносить в свой код любые изменения, которые сочтет нужным.
Большинство авторов редко занимаются сборкой ПО под конкретные дистрибутивы, либо собирают под ряд наиболее популярных. В этом случае мы можем подключить репозиторий от разработчика и получать бинарные пакеты прямо из первых рук.
Но это не всегда хорошо. Почему? Потому что автор может не знать тонкостей конкретного дистрибутива и просто собрать пакет без оптимизаций и интеграций. Чтобы был.
Сборкой и поддержкой пакетов непосредственно для дистрибутивов занимаются специальные люди – мейнтейнеры (сопровождающие), которые знают все особенности дистрибутива и способны наиболее оптимальным образом собрать пакет и интегрировать его в систему.
При этом они могут менять исходный код пакета, накладывать патчи, изменять параметры сборки и т.д. и т.п. Это все отображается в репозиториях исходного кода дистрибутива.
Сегодня есть еще и третий путь – пакеты Snap, Flatpak и AppImage. Их сборкой могут заниматься как авторы ПО, так и третьи лица. Поэтому всегда нужно понимать кто собирает и поддерживает версию, которую вы хотите установить.
А теперь об угрозах. Основная – это компрометация исходного кода разработчика. Это могут сделать как злоумышленники, так и сам автор, примеров тому в последние годы было достаточно. Также возможна игра вдолгую – с постепенным перехватом управления проектом злоумышленниками.
В этом случае, если вы используете репозиторий или иные пакеты непосредственно от разработчика, то вы сразу получаете скомпрометированный пакет себе в систему после ближайшего обновления, а в случае Snap/Flatpak этого даже не потребуется, они обновятся сами. Но их, как раз, наиболее легко и просто откатить.
Определенным заслоном на этом пути становятся мейнтейнеры, которые способны выявить негативные моменты при сборке и тестировании и заблокировать дальнейшее распространение.
Также политика многих дистрибутивов не предусматривает обновления до самых последних версии и всегда остается временной зазор, который позволяет выявить негативные моменты в вышестоящем источнике.
Но может ли злоумышленником оказаться мейнтейнер? Может. И пример тому был во вчерашней заметке, где сопровождающий собрал пакет так, что он отправлял потенциально чувствительную информацию в открытом виде на китайские сервера.
Также он может собрать пакет немного не так, с отличиями от исходного кода в репозиториях дистрибутива. Это достаточно несложно обнаружить, достаточно просто пересобрать дистрибутив (или пакет) из исходных кодов, но в случае целенаправленной атаки время может быть упущено и скомпрометированный пакет разойдется пользователям.
Может мейнтейнер внезапно начать чудить? Может, кто ему не дает. Но в отличие от разработчика он связан правилами дистрибутива и такое поведение должно быть достаточно быстро пресечено.
В целом, несмотря на все потенциальные угрозы, пакеты из репозитория дистрибутива наиболее безопасны. Так как имеют временной зазор между появлением версии разработчика и ее попадания в дистрибутив, а также промежуточное звено дополнительного контроля – мейнтейнера.
Каждый раз, говоря об открытом ПО в пример ставится его большая безопасность, проистекающая из открытости. Мол, тысячи глаз следят, тысячи рук исправят…
В целом разумное зерно в этом есть, но не более. Людей, способных читать код на уровне достаточном для нахождения уязвимостей и прочей вредоносной активности – единицы. Еще меньше будет желающих посвятить этому занятию свое время.
Поэтому поиском уязвимостей занимаются в основном энтузиасты, злоумышленники и специалисты по безопасности.
Мы же в свою очередь рассмотрим спектр угроз для простого пользователя Linux, а также возможные варианты противодействия им.
Начнем с самого начала – исходного кода. Код принадлежит автору и обычно расположен в его репозитории. Мы вольны изучать, собирать и изменять его в той мере, в которой это не противоречит лицензии.
Автор также волен вносить в свой код любые изменения, которые сочтет нужным.
Большинство авторов редко занимаются сборкой ПО под конкретные дистрибутивы, либо собирают под ряд наиболее популярных. В этом случае мы можем подключить репозиторий от разработчика и получать бинарные пакеты прямо из первых рук.
Но это не всегда хорошо. Почему? Потому что автор может не знать тонкостей конкретного дистрибутива и просто собрать пакет без оптимизаций и интеграций. Чтобы был.
Сборкой и поддержкой пакетов непосредственно для дистрибутивов занимаются специальные люди – мейнтейнеры (сопровождающие), которые знают все особенности дистрибутива и способны наиболее оптимальным образом собрать пакет и интегрировать его в систему.
При этом они могут менять исходный код пакета, накладывать патчи, изменять параметры сборки и т.д. и т.п. Это все отображается в репозиториях исходного кода дистрибутива.
Сегодня есть еще и третий путь – пакеты Snap, Flatpak и AppImage. Их сборкой могут заниматься как авторы ПО, так и третьи лица. Поэтому всегда нужно понимать кто собирает и поддерживает версию, которую вы хотите установить.
А теперь об угрозах. Основная – это компрометация исходного кода разработчика. Это могут сделать как злоумышленники, так и сам автор, примеров тому в последние годы было достаточно. Также возможна игра вдолгую – с постепенным перехватом управления проектом злоумышленниками.
В этом случае, если вы используете репозиторий или иные пакеты непосредственно от разработчика, то вы сразу получаете скомпрометированный пакет себе в систему после ближайшего обновления, а в случае Snap/Flatpak этого даже не потребуется, они обновятся сами. Но их, как раз, наиболее легко и просто откатить.
Определенным заслоном на этом пути становятся мейнтейнеры, которые способны выявить негативные моменты при сборке и тестировании и заблокировать дальнейшее распространение.
Также политика многих дистрибутивов не предусматривает обновления до самых последних версии и всегда остается временной зазор, который позволяет выявить негативные моменты в вышестоящем источнике.
Но может ли злоумышленником оказаться мейнтейнер? Может. И пример тому был во вчерашней заметке, где сопровождающий собрал пакет так, что он отправлял потенциально чувствительную информацию в открытом виде на китайские сервера.
Также он может собрать пакет немного не так, с отличиями от исходного кода в репозиториях дистрибутива. Это достаточно несложно обнаружить, достаточно просто пересобрать дистрибутив (или пакет) из исходных кодов, но в случае целенаправленной атаки время может быть упущено и скомпрометированный пакет разойдется пользователям.
Может мейнтейнер внезапно начать чудить? Может, кто ему не дает. Но в отличие от разработчика он связан правилами дистрибутива и такое поведение должно быть достаточно быстро пресечено.
В целом, несмотря на все потенциальные угрозы, пакеты из репозитория дистрибутива наиболее безопасны. Так как имеют временной зазор между появлением версии разработчика и ее попадания в дистрибутив, а также промежуточное звено дополнительного контроля – мейнтейнера.
👍25🥱3❤1
Как правильно определить количество свободной памяти в Linux
Классика жанра – почему у меня в системе не хватает памяти, если системный монитор или панель говорят, что памяти еще достаточно.
Сегодня снова задали такой вопрос, мол если верить Proxmox, то памяти еще хватает (занято 70%), но Zabbix начал сигналить о катастрофической нехватке памяти (занято свыше 90%). Кто не прав?
Чтобы это понять выполним в консоли команду:
И изучим ее вывод, он содержит несколько столбцов:
▫️ total: Общее количество установленной физической памяти.
▫️ used: Количество памяти, которое в настоящее время используется.
▫️ free: Свободная физической памяти, доступная для немедленного использования.
▫️shared: Память, которая разделяется между процессами, например, библиотеки, которые могут быть использованы несколькими процессами одновременно.
▫️ buffers/cache: Память, которая используется в качестве буферов для операций ввода-вывода и в качестве кэша для операций
▫️ available: Количество памяти, которая доступна для использования, учитывая, что часть памяти, используемая как buffers/cache может быть освобождена при необходимости.
Если сравнить то, что показывает Proxmox, системный монитор и т.д., то он показывает именно available. Так может нечего переживать? Все норм и Zabbiх зря нагоняет панику?
А вот и нет. Во-первых, не все буферы можно сбросить, во-вторых, сброс буферов – дорогая операция, так как в последующем вместо быстрого доступа к нужным данным из памяти мы получим медленное чтение и с диска.
И система, если процесс попросит памяти больше, чем free еще десять раз подумает, а сбрасывать ли буфер?
А помогать ей в этом будет OOM Killer, который ведет строгий учет всех запущенных процессов, оценивая их по множеству критериев и присваивая «очки негодности».
И альтернативой сброса буферов может оказаться убийство «негодного» процесса. И скорее всего так оно и произойдет. Хотя со стороны кажется, что память еще есть и можно развернуться.
На нашей практике примерно в такой же ситуации регулярно выключалась неактивная виртуалка. И администратор долго не мог понять почему, пока не посмотрел на вывод free, а не дашборды Proxmox.
Поэтому не следует верить тому, что показывают графики или индикаторы, все, на что вы можете железобетонно рассчитывать – это free, а available – это то, что могут дать, а могут догнать и еще раз дать. Учитывайте это.
И Zabbix в этом случае не нагоняет жути, а по сути прав, так как учитывает описанные выше особенности.
А на закуску можем посоветовать почитать наши статьи:
🔹 Что такое пространства подкачки и как они работают
🔹 Что такое OOM Killer и как он работает
Классика жанра – почему у меня в системе не хватает памяти, если системный монитор или панель говорят, что памяти еще достаточно.
Сегодня снова задали такой вопрос, мол если верить Proxmox, то памяти еще хватает (занято 70%), но Zabbix начал сигналить о катастрофической нехватке памяти (занято свыше 90%). Кто не прав?
Чтобы это понять выполним в консоли команду:
free – h И изучим ее вывод, он содержит несколько столбцов:
▫️ total: Общее количество установленной физической памяти.
▫️ used: Количество памяти, которое в настоящее время используется.
▫️ free: Свободная физической памяти, доступная для немедленного использования.
▫️shared: Память, которая разделяется между процессами, например, библиотеки, которые могут быть использованы несколькими процессами одновременно.
▫️ buffers/cache: Память, которая используется в качестве буферов для операций ввода-вывода и в качестве кэша для операций
▫️ available: Количество памяти, которая доступна для использования, учитывая, что часть памяти, используемая как buffers/cache может быть освобождена при необходимости.
Если сравнить то, что показывает Proxmox, системный монитор и т.д., то он показывает именно available. Так может нечего переживать? Все норм и Zabbiх зря нагоняет панику?
А вот и нет. Во-первых, не все буферы можно сбросить, во-вторых, сброс буферов – дорогая операция, так как в последующем вместо быстрого доступа к нужным данным из памяти мы получим медленное чтение и с диска.
И система, если процесс попросит памяти больше, чем free еще десять раз подумает, а сбрасывать ли буфер?
А помогать ей в этом будет OOM Killer, который ведет строгий учет всех запущенных процессов, оценивая их по множеству критериев и присваивая «очки негодности».
И альтернативой сброса буферов может оказаться убийство «негодного» процесса. И скорее всего так оно и произойдет. Хотя со стороны кажется, что память еще есть и можно развернуться.
На нашей практике примерно в такой же ситуации регулярно выключалась неактивная виртуалка. И администратор долго не мог понять почему, пока не посмотрел на вывод free, а не дашборды Proxmox.
Поэтому не следует верить тому, что показывают графики или индикаторы, все, на что вы можете железобетонно рассчитывать – это free, а available – это то, что могут дать, а могут догнать и еще раз дать. Учитывайте это.
И Zabbix в этом случае не нагоняет жути, а по сути прав, так как учитывает описанные выше особенности.
А на закуску можем посоветовать почитать наши статьи:
🔹 Что такое пространства подкачки и как они работают
🔹 Что такое OOM Killer и как он работает
1👍39❤5
Эскалации в Zabbix
От проблем не убежать, они были, есть и будут возникать с определенной периодичностью, какие бы превентивные меры мы не принимали. Но важно не факт отсутствия проблем, а факт своевременного на них реагирования.
И очень часто в дело вступает человеческий фактор, который превращает небольшое происшествие в проблему масштаба предприятия.
Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?
А на помощь нам снова придет система мониторинга Zabbix, которая умеет эскалировать проблемы. Именно она поможет отследить, что что-то пошло не так и вовремя подключить вышестоящих специалистов или руководство. А также не даст замолчать проблему или замести ее под ковер.
Все мы знаем, что в основе Zabbix лежит контроль собираемых показателей относительно заранее заданных условий при помощи триггеров. Сработавший триггер может являться основанием для действия.
Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?
Все очень просто, каждое действие состоит из некоторых операций, которых может быть несколько, и они будут выполняться по очереди.
Допустим мы создали некоторое действие, привязали к нему нужные триггеры и думаем как мы будем обрабатывать сложившуюся ситуацию.
А обрабатывать мы ее будем пошагово, с каждым шагом поднимая проблему на более высокий уровень.
Сначала выбираем длительность шага, это тот промежуток времени, за который проблема должна быть решена ответственным лицом. Не следует ставить сильно маленькое время, чтобы не получить шквал сообщений и не перебудоражить всех, кого нужно и кого не нужно.
Но и выставлять слишком большой период тоже не стоит, иначе может оказаться что мы начали «бить в колокола» слишком поздно.
Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.
Первый шаг – уведомить ответственное лицо, кстати, каждую операцию можно растянуть на несколько шагов. И тогда ответственное лицо будет уведомляться несколько раз.
Если никаких действий за 15 минут не последовало, то начинаем эскалировать проблему. Добавляем следующий шаг, которым уведомляем руководство ответственного лица о наличии проблемы.
Ждем еще 15 минут, если нет реакции, то мы можем не только продолжать уведомлять все более вышестоящие лица, но и выполнять некоторые действия для решения проблемы. Например, снять отчеты по нагрузке на CPU, память, диски и отправить их кому надо.
Снова нет реакции? Ну тогда в дело вступают роботы, можем прибить самый ресурсоемкий процесс. Не помогло? Кстати, для этого можно и не ждать следующие 15 минут, а задать произвольное время шага, допустим 5 минут.
Через 5 минут после того, как мы прибили процесс снова высокая нагрузка? Ну давайте последний раз всех предупредим. Не помогло? Ну тогда идем на крайние меры и перезагружаем узел.
Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.
Причем параллельно мы можем добавлять шаги для контроля и отчетности. Скажем, после получаса существования проблемы мы можем собирать логи, показатели, историю команд и отсылать ее вышестоящему руководству для разбора полетов.
Проблема решена? Отлично, но не следует расслабляться. Настроим действия восстановления. Сюда можно добавить сбор основных метрик по решенной проблеме и отправка их ответственному сотруднику в течении следующих условных двух часов, чтобы он мог проконтролировать, что ситуация снова не ухудшается.
В общем, эскалация в Zabbix это крайне гибкий и удобный инструмент, позволяющий контролировать не только возникновение проблем, но и процесс их решения.
От проблем не убежать, они были, есть и будут возникать с определенной периодичностью, какие бы превентивные меры мы не принимали. Но важно не факт отсутствия проблем, а факт своевременного на них реагирования.
И очень часто в дело вступает человеческий фактор, который превращает небольшое происшествие в проблему масштаба предприятия.
Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?
А на помощь нам снова придет система мониторинга Zabbix, которая умеет эскалировать проблемы. Именно она поможет отследить, что что-то пошло не так и вовремя подключить вышестоящих специалистов или руководство. А также не даст замолчать проблему или замести ее под ковер.
Все мы знаем, что в основе Zabbix лежит контроль собираемых показателей относительно заранее заданных условий при помощи триггеров. Сработавший триггер может являться основанием для действия.
Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?
Все очень просто, каждое действие состоит из некоторых операций, которых может быть несколько, и они будут выполняться по очереди.
Допустим мы создали некоторое действие, привязали к нему нужные триггеры и думаем как мы будем обрабатывать сложившуюся ситуацию.
А обрабатывать мы ее будем пошагово, с каждым шагом поднимая проблему на более высокий уровень.
Сначала выбираем длительность шага, это тот промежуток времени, за который проблема должна быть решена ответственным лицом. Не следует ставить сильно маленькое время, чтобы не получить шквал сообщений и не перебудоражить всех, кого нужно и кого не нужно.
Но и выставлять слишком большой период тоже не стоит, иначе может оказаться что мы начали «бить в колокола» слишком поздно.
Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.
Первый шаг – уведомить ответственное лицо, кстати, каждую операцию можно растянуть на несколько шагов. И тогда ответственное лицо будет уведомляться несколько раз.
Если никаких действий за 15 минут не последовало, то начинаем эскалировать проблему. Добавляем следующий шаг, которым уведомляем руководство ответственного лица о наличии проблемы.
Ждем еще 15 минут, если нет реакции, то мы можем не только продолжать уведомлять все более вышестоящие лица, но и выполнять некоторые действия для решения проблемы. Например, снять отчеты по нагрузке на CPU, память, диски и отправить их кому надо.
Снова нет реакции? Ну тогда в дело вступают роботы, можем прибить самый ресурсоемкий процесс. Не помогло? Кстати, для этого можно и не ждать следующие 15 минут, а задать произвольное время шага, допустим 5 минут.
Через 5 минут после того, как мы прибили процесс снова высокая нагрузка? Ну давайте последний раз всех предупредим. Не помогло? Ну тогда идем на крайние меры и перезагружаем узел.
Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.
Причем параллельно мы можем добавлять шаги для контроля и отчетности. Скажем, после получаса существования проблемы мы можем собирать логи, показатели, историю команд и отсылать ее вышестоящему руководству для разбора полетов.
Проблема решена? Отлично, но не следует расслабляться. Настроим действия восстановления. Сюда можно добавить сбор основных метрик по решенной проблеме и отправка их ответственному сотруднику в течении следующих условных двух часов, чтобы он мог проконтролировать, что ситуация снова не ухудшается.
В общем, эскалация в Zabbix это крайне гибкий и удобный инструмент, позволяющий контролировать не только возникновение проблем, но и процесс их решения.
👍20❤1
Что означают метрики Pressure Stall Information (PSI) в Linux
В последнем релизе Proxmox VE разработчики добавили на панель новые метрики класса Pressure Stall Information, что, ожидаемо, вызвало волну интереса.
На самом деле метрики эти давно не новые и появились еще в ядре 4.20, в любой системе Linux вы можете получить их значение командой:
Где вместо <metric> следует подставить интересующий вас параметр: cpu, memory или io.
Данные метрики показывают время, в течении которого процессы ожидают освобождения указанных ресурсов.
👉 У данных метрик есть две основные категории:
🔹 some — показывает время, когда хотя бы один процесс ожидает освобождения ресурсов
🔹 full — показывает время, когда все активные процессы ожидают освобождения ресурсов
Для каждой категории доступны следующие показатели:
🔹 avg10 — среднее значение за последние 10 секунд
🔹 avg60 — среднее значение за последнюю минуту
🔹 avg300 — среднее значение за последние 5 минут
❓ Как интерпретировать полученные значения? Существуют следующие рекомендации:
🔹 CPU pressure:
🔸 avg10:
▫️0-10% — нормальное состояние
▫️10-25% — умеренная нагрузка
▫️25% — критическое состояние
🔸 avg60:
▫️0-5% — нормальное состояние
▫️5-15% — умеренная нагрузка
▫️15% — критическое состояние
🔸 avg300:
▫️0-3% — нормальное состояние
▫️3-10% — умеренная нагрузка
▫️10% — критическое состояние
🔹Memory pressure:
🔸avg10:
▫️0-5% — нормальное состояние
▫️5-20% — умеренная нагрузка
▫️20% — критическое состояние
🔸 avg60:
▫️0-3% — нормальное состояние
▫️3-15% — умеренная нагрузка
▫️15% — критическое состояние
🔸 avg300:
▫️0-2% — нормальное состояние
▫️2-10% — умеренная нагрузка
▫️10% — критическое состояние
🔹 IO pressure:
🔸 avg10:
▫️0-15% — нормальное состояние
▫️15-40% — умеренная нагрузка
▫️40% — критическое состояние
🔸 avg60:
▫️0-10% — нормальное состояние
▫️10-30% — умеренная нагрузка
▫️30% — критическое состояние
🔸 avg300:
▫️0-5% — нормальное состояние
▫️5-20% — умеренная нагрузка
▫️20% — критическое состояние
Данные метрики будут полезны при анализе использования ресурсов и их распределении между виртуальными машинами, а также быстро помогут понять почему вдруг все начало тормозить.
В последнем релизе Proxmox VE разработчики добавили на панель новые метрики класса Pressure Stall Information, что, ожидаемо, вызвало волну интереса.
На самом деле метрики эти давно не новые и появились еще в ядре 4.20, в любой системе Linux вы можете получить их значение командой:
/proc/pressure/<metric>
Где вместо <metric> следует подставить интересующий вас параметр: cpu, memory или io.
Данные метрики показывают время, в течении которого процессы ожидают освобождения указанных ресурсов.
👉 У данных метрик есть две основные категории:
🔹 some — показывает время, когда хотя бы один процесс ожидает освобождения ресурсов
🔹 full — показывает время, когда все активные процессы ожидают освобождения ресурсов
Для каждой категории доступны следующие показатели:
🔹 avg10 — среднее значение за последние 10 секунд
🔹 avg60 — среднее значение за последнюю минуту
🔹 avg300 — среднее значение за последние 5 минут
❓ Как интерпретировать полученные значения? Существуют следующие рекомендации:
🔹 CPU pressure:
🔸 avg10:
▫️0-10% — нормальное состояние
▫️10-25% — умеренная нагрузка
▫️25% — критическое состояние
🔸 avg60:
▫️0-5% — нормальное состояние
▫️5-15% — умеренная нагрузка
▫️15% — критическое состояние
🔸 avg300:
▫️0-3% — нормальное состояние
▫️3-10% — умеренная нагрузка
▫️10% — критическое состояние
🔹Memory pressure:
🔸avg10:
▫️0-5% — нормальное состояние
▫️5-20% — умеренная нагрузка
▫️20% — критическое состояние
🔸 avg60:
▫️0-3% — нормальное состояние
▫️3-15% — умеренная нагрузка
▫️15% — критическое состояние
🔸 avg300:
▫️0-2% — нормальное состояние
▫️2-10% — умеренная нагрузка
▫️10% — критическое состояние
🔹 IO pressure:
🔸 avg10:
▫️0-15% — нормальное состояние
▫️15-40% — умеренная нагрузка
▫️40% — критическое состояние
🔸 avg60:
▫️0-10% — нормальное состояние
▫️10-30% — умеренная нагрузка
▫️30% — критическое состояние
🔸 avg300:
▫️0-5% — нормальное состояние
▫️5-20% — умеренная нагрузка
▫️20% — критическое состояние
Данные метрики будут полезны при анализе использования ресурсов и их распределении между виртуальными машинами, а также быстро помогут понять почему вдруг все начало тормозить.
👍19🔥6❤1
А что именно мы мониторим?
Очень часто внедрения системы мониторинга заканчивается тем, что она начинает тихо пылиться где-то на забытой всеми виртуалке, пока не будет отключена совсем.
На вопрос почему такие пользователи обычно отвечают, что все равно от нее нет особого толка.
И это действительно так, если вы не уделили системе мониторинга особого внимания и не настроили какие именно параметры вы хотите контролировать, а также не задали подходящие именно вам пороговые значения – толку от нее действительно не будет.
Любая система мониторинга имеет некоторые настроенные из коробки метрики и триггеры, где-то больше, где-то меньше, но все они рассчитаны на некий сферический сервер в вакууме и использовать без адаптации можно разве что триггеры, срабатывающие на предельных значениях.
Но сообщение о выходе параметров за эти значения равносильны звонку в экстренные службы, если раньше вам об этом не сообщат пользователи или руководство в три часа ночи.
А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.
Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.
А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.
Поэтому что в том, что в другом случае параметры срабатывания триггеров надо откорректировать согласно фактическому положению дел. Иначе такие предупреждения скоро замылят глаз и перестанут восприниматься как серьезные, что может сыграть злую шутку при реальном недостатке места в системе.
Но сам по себе сервер не представляет такой ценности, как запущенные на нем приложения и часто можно столкнуться с ситуацией, когда сервер сам по себе не выходит за рамки контрольных показателей, а приложение работает из рук вон плохо.
Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?
Стандартный шаблон он тоже для сферического приложения в вакууме и без адаптации будет практически негоден.
Скажем, если у вас веб-сервер на дешевом-дешевом VPS, то вы можете никогда не дождаться срабатывания триггера на большое число запросов, так как сервер ляжет гораздо раньше.
Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.
И это касается очень и очень многого. При том, что никаких общих рекомендаций, мол поставь сюда такую цифру, а сюда такую дать нельзя, все достаточно индивидуально. Поэтому для корректной работы любого шаблона вам придется изучить что отражают все собираемые им метрики и как рассчитать их нормальные и предельные значения для каждого конкретного случая.
Сложно? Ну как сказать, если вы понимаете принцип работы приложения – то не очень, а иначе – придется углубиться в теорию. Но без этого никак, даже не касаясь систем мониторинга без данных знаний вы не сможете нормально эксплуатировать систему.
Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.
При этом нам известны и иные случаи, когда внедрив мониторинг и углубившись в изучение метрик и их влияния на общий результат коллеги серьезно подтягивали производительность которая начинала быть видимой буквально невооруженным глазом.
Поэтому, собираясь внедрять систему мониторинга приготовьтесь углубиться в подробности эксплуатации используемых программных продуктов и показателей, влияющих на их производительность.
Очень часто внедрения системы мониторинга заканчивается тем, что она начинает тихо пылиться где-то на забытой всеми виртуалке, пока не будет отключена совсем.
На вопрос почему такие пользователи обычно отвечают, что все равно от нее нет особого толка.
И это действительно так, если вы не уделили системе мониторинга особого внимания и не настроили какие именно параметры вы хотите контролировать, а также не задали подходящие именно вам пороговые значения – толку от нее действительно не будет.
Любая система мониторинга имеет некоторые настроенные из коробки метрики и триггеры, где-то больше, где-то меньше, но все они рассчитаны на некий сферический сервер в вакууме и использовать без адаптации можно разве что триггеры, срабатывающие на предельных значениях.
Но сообщение о выходе параметров за эти значения равносильны звонку в экстренные службы, если раньше вам об этом не сообщат пользователи или руководство в три часа ночи.
А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.
Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.
А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.
Поэтому что в том, что в другом случае параметры срабатывания триггеров надо откорректировать согласно фактическому положению дел. Иначе такие предупреждения скоро замылят глаз и перестанут восприниматься как серьезные, что может сыграть злую шутку при реальном недостатке места в системе.
Но сам по себе сервер не представляет такой ценности, как запущенные на нем приложения и часто можно столкнуться с ситуацией, когда сервер сам по себе не выходит за рамки контрольных показателей, а приложение работает из рук вон плохо.
Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?
Стандартный шаблон он тоже для сферического приложения в вакууме и без адаптации будет практически негоден.
Скажем, если у вас веб-сервер на дешевом-дешевом VPS, то вы можете никогда не дождаться срабатывания триггера на большое число запросов, так как сервер ляжет гораздо раньше.
Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.
И это касается очень и очень многого. При том, что никаких общих рекомендаций, мол поставь сюда такую цифру, а сюда такую дать нельзя, все достаточно индивидуально. Поэтому для корректной работы любого шаблона вам придется изучить что отражают все собираемые им метрики и как рассчитать их нормальные и предельные значения для каждого конкретного случая.
Сложно? Ну как сказать, если вы понимаете принцип работы приложения – то не очень, а иначе – придется углубиться в теорию. Но без этого никак, даже не касаясь систем мониторинга без данных знаний вы не сможете нормально эксплуатировать систему.
Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.
При этом нам известны и иные случаи, когда внедрив мониторинг и углубившись в изучение метрик и их влияния на общий результат коллеги серьезно подтягивали производительность которая начинала быть видимой буквально невооруженным глазом.
Поэтому, собираясь внедрять систему мониторинга приготовьтесь углубиться в подробности эксплуатации используемых программных продуктов и показателей, влияющих на их производительность.
👍17❤2⚡2
Что такое Magic SysRq и чем он может быть полезен
Каждый из нас не раз сталкивался с ситуацией, когда Linux-система впадала в состояние близкое к коме и переставала реагировать на все ваши команды, включая reboot.
Неприятно, да. Что делать? Обувать ботинки и спешить в место физического расположения сервера? Не спешите, попробуйте Magic SysRq – это специальные низкоуровневые команды, которые позволяют взаимодействовать даже с наглухо повисшей системой, работало бы ядро.
Чтобы перейти в этот режим отправьте:
А затем обычно следует команда жесткой перезагрузки системы:
Это эффективно и позволяет перезагрузить даже безнадежный сервер, но и достаточно жестко, так как эквивалентно нажатию кнопки Reset на корпусе.
Но ведь мы же висим? Висим, но ядро то работает. Поэтому давайте не будем рубить с плеча, а попробуем обойтись с системой более гуманно.
Прежде всего, если у вас система с графической оболочкой, то следует отключить от нее консоль ввода-вывода чтобы быть уверенным, что никто его не перехватит:
Затем пробуем отправить SIGTERM всем процессам (попросим завершиться их по-хорошему). Некоторое время ждем, так как не все могут это сделать мгновенно.
А дальше: кто не спрятался – я не виноват, приступаем к принудительному завершению всех активных процессов (посылаем SIGKILL):
Чтобы не потерять данные в буферах и кешах принудительно пишем их на диск (посылаем fsync):
После чего отмонтируем все файловые системы:
А теперь можно и Reset нажать:
Как видим – режим тот же, а действия разные. Поэтому не спешите жестко ребутить систему, попробуйте завершить работу по более мягкому варианту. И если ядро живое, то у вас с очень большой вероятностью все получится.
Каждый из нас не раз сталкивался с ситуацией, когда Linux-система впадала в состояние близкое к коме и переставала реагировать на все ваши команды, включая reboot.
Неприятно, да. Что делать? Обувать ботинки и спешить в место физического расположения сервера? Не спешите, попробуйте Magic SysRq – это специальные низкоуровневые команды, которые позволяют взаимодействовать даже с наглухо повисшей системой, работало бы ядро.
Чтобы перейти в этот режим отправьте:
echo 1 > /proc/sys/kernel/sysrq
А затем обычно следует команда жесткой перезагрузки системы:
echo b > /proc/sysrq-trigger
Это эффективно и позволяет перезагрузить даже безнадежный сервер, но и достаточно жестко, так как эквивалентно нажатию кнопки Reset на корпусе.
Но ведь мы же висим? Висим, но ядро то работает. Поэтому давайте не будем рубить с плеча, а попробуем обойтись с системой более гуманно.
Прежде всего, если у вас система с графической оболочкой, то следует отключить от нее консоль ввода-вывода чтобы быть уверенным, что никто его не перехватит:
echo r > /proc/sysrq-trigger
Затем пробуем отправить SIGTERM всем процессам (попросим завершиться их по-хорошему). Некоторое время ждем, так как не все могут это сделать мгновенно.
echo e > /proc/sysrq-trigger
А дальше: кто не спрятался – я не виноват, приступаем к принудительному завершению всех активных процессов (посылаем SIGKILL):
echo i > /proc/sysrq-trigger
Чтобы не потерять данные в буферах и кешах принудительно пишем их на диск (посылаем fsync):
echo s > /proc/sysrq-trigger
После чего отмонтируем все файловые системы:
echo u > /proc/sysrq-trigger
А теперь можно и Reset нажать:
echo b > /proc/sysrq-trigger
Как видим – режим тот же, а действия разные. Поэтому не спешите жестко ребутить систему, попробуйте завершить работу по более мягкому варианту. И если ядро живое, то у вас с очень большой вероятностью все получится.
👍45🔥8❤3
Знали ли вы про Magic SysRq?
Anonymous Poll
8%
Знаю, использую
9%
Знаю, не использую
47%
Не знал, буду использовать
7%
Не знал, но использовать не буду
4%
Не знал и не хочу знать
1%
У меня есть аналог этих команд на двух ногах
8%
Это какие-то шаманские заклинания
16%
Ничего не понято, но очень интересно
☝️ 512 МБ хватит всем!
Все течет, все меняется. Особенно интересно смотреть на старые системы, которые тогда были вполне себе "ничего", а сейчас годятся только в музей.
Перед вами "малинка" образца 2013 года. Тогда нам этих плат по рублю за мешок отдали из одного банка. Им было дешевле продать недорого, чем списывать и утилизировать. На них были тонкие клиенты на основе Windows XP Embedded и да, 512 МБ хватало.
Мы же ставили на них Linux и использовали под то, под что сегодня обычно ставят "малинки". В те годы вполне актуальные системы получались.
Сейчас же если только поностальгировать. Ну или RouterOS x86 попробовать поставить. 😉
Все течет, все меняется. Особенно интересно смотреть на старые системы, которые тогда были вполне себе "ничего", а сейчас годятся только в музей.
Перед вами "малинка" образца 2013 года. Тогда нам этих плат по рублю за мешок отдали из одного банка. Им было дешевле продать недорого, чем списывать и утилизировать. На них были тонкие клиенты на основе Windows XP Embedded и да, 512 МБ хватало.
Мы же ставили на них Linux и использовали под то, под что сегодня обычно ставят "малинки". В те годы вполне актуальные системы получались.
Сейчас же если только поностальгировать. Ну или RouterOS x86 попробовать поставить. 😉
❤3👍1
Почта России – бессмысленная и беспощадная
Про Почту России в принципе все всё знают и удивить очередным пробитым дном со стороны этой конторы трудно. Тем более что снизу каждый раз начинают достаточно громко и настойчиво стучать.
Но некоторые моменты кроме недоумения, граничащего с крайней стадией изумления (скажем так) не вызывают.
Эта история случилась на днях, как это бывает продавец с Озона прислал не то. Ну бывает, дело житейское. Получал я в постамате, поэтому для возврата выбрал один из ближайших пунктов выдачи, точнее новый пункт, который открылся буквально недавно.
Меня даже не смутил адрес, который совпадал с местным отделением этого недоумения. Там рядом пустует достаточно много помещений, и я решил, что где-то там новый пункт и открыли.
Когда я не нашел там никакого Озона, но обнаружил его наклейку на двери почтового отделения – меня начали одолевать сомнения. Я еще робко надеялся, что может как-нибудь обойдется… Не обошлось…
Как оказалось пункт выдачи Озон открыла сама Почта России, равно как и пункт выдачи Wildberries, добавив вывесок и наклеек к пустующим ранее окошкам.
Но я на всякий случай уточнил, мол здесь Озон? Сотрудница почты подтвердила, что здесь, только сказала приходить завтра, лучше всего в первой половине, потому что сегодня у них что-то не работает.
На этом можно было бы и закончить, переделать возврат на нормальный пункт и не испытывать судьбу, но я решил дать Почте России шанс и не ошибся (в самых негативных прогнозах).
Утро встретило меня небольшой очередью в почтовом отделении, человека в четыре. Сотрудник один. Отдельного сотрудника для выдачи нет. Уже успех! Но ладно, постоим, раз пришли.
Подходит моя очередь – поясняю, что надо вернуть Озон. ОК, пройдите вон на то окно. Открываю в телефоне штрих-код, но тут с меня требуют паспорт!
Паспорт??? На Озоне??? Зачем???
А пофиг, у них так положено. Ну, на крайний случай, можно показать QR-код из приложения Почта России. Хорошо, код показал.
А теперь с вас 70 рублей за пакет. Какой такой пакет? Ну в чем-то же его назад отправлять надо. Что за ерунда? Ну вот так или никак. Ладно, не обеднею.
Снова протягиваю телефон, но тетенька его игнорирует и пикает штрих-код на упаковке товара, которую я принес и заявляет, что это не их товар и возврату он не подлежит.
Спрашиваю, не прикалываются ли они? Нет, они серьезны как никогда, они его не выдавали, они его принимать не будут. Показываю штрих-код в телефоне с адресом их пункта, но им все равно, это не их код и вообще я походу двери перепутал.
Ладно, отхожу, открываю в телефоне описание пункта и читаю как пройти. Там русским языком написано, что Озон в помещении почтового отделения. Возвращаюсь к тетеньке с этим текстом на телефоне. В ответ слышу, чего я вообще сюда пришел, других пунктов Озона что ли нет нигде.
После чего она зовет другую сотрудницу и выясняется, что тут у них есть еще один Озон, но они пароля не помнят, как включить не знают и вообще, чего я до них докопался.
Ну как чего, написано Озон – значит Озон, мне как клиенту должны быть пофиг. На что мне рекомендуют по этому вопросу обращаться в центральное отделение, а не к ним. Зову начальника отделения. Его, как всегда, в таких ситуациях, нет. Зову того, кто вместо него. Тоже никого нет. Все сироты казанские… Бейджики с одежды сотрудников также быстро и незаметно исчезают…
В общем – классика. Мне только непонятно одно – зачем??? Зачем нужен весь этот дешевый балаган? Если работать это с таким подходом заведомо не будет. Ну ни один нормальный человек больше одного раза туда не придет.
Чего хочет добиться руководство открывая подобные «пункты выдачи»? Красиво отчитаться на очередные мудрые инициативы? Но оно бы и пес с ним, если бы не одно но. Такие инициативы сильно поганят нормальному бизнесу, который, может быть, и хотел бы открыть тут нормальный пункт – но не сможет, потому что территория уже занята Почтой.
А еще непонятно то, почему бы не сделать так, чтобы это работало. Семи пядей во лбу там не надо – бизнес элементарный, тем более сотрудникам почты близкий.
Про Почту России в принципе все всё знают и удивить очередным пробитым дном со стороны этой конторы трудно. Тем более что снизу каждый раз начинают достаточно громко и настойчиво стучать.
Но некоторые моменты кроме недоумения, граничащего с крайней стадией изумления (скажем так) не вызывают.
Эта история случилась на днях, как это бывает продавец с Озона прислал не то. Ну бывает, дело житейское. Получал я в постамате, поэтому для возврата выбрал один из ближайших пунктов выдачи, точнее новый пункт, который открылся буквально недавно.
Меня даже не смутил адрес, который совпадал с местным отделением этого недоумения. Там рядом пустует достаточно много помещений, и я решил, что где-то там новый пункт и открыли.
Когда я не нашел там никакого Озона, но обнаружил его наклейку на двери почтового отделения – меня начали одолевать сомнения. Я еще робко надеялся, что может как-нибудь обойдется… Не обошлось…
Как оказалось пункт выдачи Озон открыла сама Почта России, равно как и пункт выдачи Wildberries, добавив вывесок и наклеек к пустующим ранее окошкам.
Но я на всякий случай уточнил, мол здесь Озон? Сотрудница почты подтвердила, что здесь, только сказала приходить завтра, лучше всего в первой половине, потому что сегодня у них что-то не работает.
На этом можно было бы и закончить, переделать возврат на нормальный пункт и не испытывать судьбу, но я решил дать Почте России шанс и не ошибся (в самых негативных прогнозах).
Утро встретило меня небольшой очередью в почтовом отделении, человека в четыре. Сотрудник один. Отдельного сотрудника для выдачи нет. Уже успех! Но ладно, постоим, раз пришли.
Подходит моя очередь – поясняю, что надо вернуть Озон. ОК, пройдите вон на то окно. Открываю в телефоне штрих-код, но тут с меня требуют паспорт!
Паспорт??? На Озоне??? Зачем???
А пофиг, у них так положено. Ну, на крайний случай, можно показать QR-код из приложения Почта России. Хорошо, код показал.
А теперь с вас 70 рублей за пакет. Какой такой пакет? Ну в чем-то же его назад отправлять надо. Что за ерунда? Ну вот так или никак. Ладно, не обеднею.
Снова протягиваю телефон, но тетенька его игнорирует и пикает штрих-код на упаковке товара, которую я принес и заявляет, что это не их товар и возврату он не подлежит.
Спрашиваю, не прикалываются ли они? Нет, они серьезны как никогда, они его не выдавали, они его принимать не будут. Показываю штрих-код в телефоне с адресом их пункта, но им все равно, это не их код и вообще я походу двери перепутал.
Ладно, отхожу, открываю в телефоне описание пункта и читаю как пройти. Там русским языком написано, что Озон в помещении почтового отделения. Возвращаюсь к тетеньке с этим текстом на телефоне. В ответ слышу, чего я вообще сюда пришел, других пунктов Озона что ли нет нигде.
После чего она зовет другую сотрудницу и выясняется, что тут у них есть еще один Озон, но они пароля не помнят, как включить не знают и вообще, чего я до них докопался.
Ну как чего, написано Озон – значит Озон, мне как клиенту должны быть пофиг. На что мне рекомендуют по этому вопросу обращаться в центральное отделение, а не к ним. Зову начальника отделения. Его, как всегда, в таких ситуациях, нет. Зову того, кто вместо него. Тоже никого нет. Все сироты казанские… Бейджики с одежды сотрудников также быстро и незаметно исчезают…
В общем – классика. Мне только непонятно одно – зачем??? Зачем нужен весь этот дешевый балаган? Если работать это с таким подходом заведомо не будет. Ну ни один нормальный человек больше одного раза туда не придет.
Чего хочет добиться руководство открывая подобные «пункты выдачи»? Красиво отчитаться на очередные мудрые инициативы? Но оно бы и пес с ним, если бы не одно но. Такие инициативы сильно поганят нормальному бизнесу, который, может быть, и хотел бы открыть тут нормальный пункт – но не сможет, потому что территория уже занята Почтой.
А еще непонятно то, почему бы не сделать так, чтобы это работало. Семи пядей во лбу там не надо – бизнес элементарный, тем более сотрудникам почты близкий.
👍31😁13🥱7❤6🤔4
Раз уж мы подняли тему DNS, то разберем основные ресурсные записи:
SOA - Start of authority - начальная запись зоны
NS - Authoritative name server - сервера имен отвечающих за зону
A - Address - Адресная запись, соответствие между именем и IP-адресом
AAAA - Address v6 - Адресная запись в формате IPv6
CNAME - Canonical name - Каноническое имя для псевдонима (одноуровневая переадресация)
MX - Mail Exchanger - Адрес почтового шлюза для домена. Состоит из двух частей — приоритета (чем число больше, тем ниже приоритет), и адреса узла
SRV - Server selection - Указание на местоположение серверов для сервисов
TXT - Text string - Запись произвольных данных, до 255 байт в размере
PTR - Pointer - Соответствие адреса имени — обратное соответствие для A и AAAА
Теперь об особенностях их применения и характерных ошибках.
Начнем с того, кто управляет зонами. Прямой зоной управляет владелец доменного имени, а обратной - владелец диапазона IP. Поэтому если вы купили доменное имя, то прямой зоной будете управлять вы, а обратной зоной будет управлять хостер или провайдер. В этом случае за внесением PTR-записи нужно обратиться к нему, самому создавать зону бесполезно и бессмысленно.
Второе. Во всех ресурсных записях, кроме A и AAAA следует указывать доменные имена, если есть A запись и CNAME для одного узла, то указываем имя из CNAME.
🛑 Неправильно:
@ IN MX 10 192.168.100.25
🛑 Неправильно:
@ IN MX 10 mail
mail IN CNAME srv-mx-01
srv-mx-01 IN A 192.168.100.25
✅ Правильно:
@ IN MX 10 srv-mx-01
mail IN CNAME srv-mx-01
srv-mx-01 IN A 192.168.100.25
Символ @ обозначает текущий домен, допустим example.com
Все записи могут быть абсолютными и относительными.
Абсолютные записи заканчиваются точкой ☝️ (корневой домен), например, example.com.
Относительные записи (без точки на конце) дополняются текущим доменом. Например srv-mx-01 - srv-mx-01.example.com.
👉 Распространенная ошибка - написать в файле зоны абсолютную запись без точки, тогда получим следующий сюрприз: example.com - example.com.example.com. Эта ситуация очень часто вызывает много затруднений у начинающих.
В обратную зону всегда пишем только абсолютные записи, с точкой на конце.
SOA - Start of authority - начальная запись зоны
NS - Authoritative name server - сервера имен отвечающих за зону
A - Address - Адресная запись, соответствие между именем и IP-адресом
AAAA - Address v6 - Адресная запись в формате IPv6
CNAME - Canonical name - Каноническое имя для псевдонима (одноуровневая переадресация)
MX - Mail Exchanger - Адрес почтового шлюза для домена. Состоит из двух частей — приоритета (чем число больше, тем ниже приоритет), и адреса узла
SRV - Server selection - Указание на местоположение серверов для сервисов
TXT - Text string - Запись произвольных данных, до 255 байт в размере
PTR - Pointer - Соответствие адреса имени — обратное соответствие для A и AAAА
Теперь об особенностях их применения и характерных ошибках.
Начнем с того, кто управляет зонами. Прямой зоной управляет владелец доменного имени, а обратной - владелец диапазона IP. Поэтому если вы купили доменное имя, то прямой зоной будете управлять вы, а обратной зоной будет управлять хостер или провайдер. В этом случае за внесением PTR-записи нужно обратиться к нему, самому создавать зону бесполезно и бессмысленно.
Второе. Во всех ресурсных записях, кроме A и AAAA следует указывать доменные имена, если есть A запись и CNAME для одного узла, то указываем имя из CNAME.
🛑 Неправильно:
@ IN MX 10 192.168.100.25
🛑 Неправильно:
@ IN MX 10 mail
mail IN CNAME srv-mx-01
srv-mx-01 IN A 192.168.100.25
✅ Правильно:
@ IN MX 10 srv-mx-01
mail IN CNAME srv-mx-01
srv-mx-01 IN A 192.168.100.25
Символ @ обозначает текущий домен, допустим example.com
Все записи могут быть абсолютными и относительными.
Абсолютные записи заканчиваются точкой ☝️ (корневой домен), например, example.com.
Относительные записи (без точки на конце) дополняются текущим доменом. Например srv-mx-01 - srv-mx-01.example.com.
👉 Распространенная ошибка - написать в файле зоны абсолютную запись без точки, тогда получим следующий сюрприз: example.com - example.com.example.com. Эта ситуация очень часто вызывает много затруднений у начинающих.
В обратную зону всегда пишем только абсолютные записи, с точкой на конце.
👍25🥱4❤1
Что не так с Cat 7?
Один мой хороший знакомый, третьего дня решил проапгрейдить домашнюю сеть до 2,5 Гбит/с. Зачем? Не спрашивайте. Ну и каждый волен сходить с ума по-своему.
В общем выбрали мы с ним коммутатор, сетевые карты и дело дошло до патч-кордов. И вот он присылает мне пару артикулов и спрашивает, что я об этом думаю.
А артикулы были примерно такие: Патч-корд NAME [круглый, SF/FTP, RJ-45, Cat. 7, длина - N м]
Пытаюсь выяснить причину столь странного выбора, а в ответ слышу – ну это же седьмая категория, это же круто и вообще, они красивые.
Согласиться здесь могу лишь с последним. А вот что такое седьмая категория и чем она отличается от других давайте разбираться.
Что такое категория кабеля? Это стандарт, описывающий его технические характеристики, максимальную частоту передаваемого сигнала и скорости передачи данных на определенные расстояния.
Наиболее распространены и привычны кабели категории Cat 5e, они предусматривают физический размер (диаметр) 24AWG (0,51 мм) и разъем 8P8C RJ-45. Максимальная передаваемая частота – 100 МГц, это обеспечивает связь на скоростях до 1 Гбит/с на расстоянии до 100 м.
Но гигабита скоро стало мало и был разработан новый стандарт – Cat 6, который предполагал несколько более крупный кабель - 23AWG (0,585 мм) и все тот же разъем 8P8C RJ-45. Кабель поддерживал частоту передачи до 250 МГц и поддерживал скорость до 10 Гбит/с на расстоянии до 35-50 м.
Одновременно с ним, а это было в 2002 году, был представлен стандарт Cat 7, который при тех же физических размерах кабеля обеспечивал рабочие частоты до 600 МГц и передачу на скорости 10 Гбит/с на расстояние до 100 метров.
Вот он долгожданный прорыв… или нет? Скорее всего второе. Стандарт Cat 7 предусматривал применение проприетарных разъемов GG45 или TERA. При этом первый из них обратно совместим с RJ-45.
Но все кроется в мелочах. Разъем GG45 предусматривает 4 дополнительных контакта для заземления, а сам кабель седьмой категории обязательно должен быть типа STP (S/UTP), т.е. иметь экран на каждой паре и общий экран для всего кабеля.
Все это серьезно отражается на стоимости и кабель Cat 7 стоит ощутимо дороже своих аналогов.
Так может есть за что переплатить? Увы. Все преимущества данного кабеля раскрываются только с проприетарными разъемами. В режиме совместимости с RJ-45 рабочая частота кабеля падает до 200-250 МГц, т.е. на уровень куда более дешевого Cat 6.
А немного позже вышел Cat 6a, который на обычной витухе позволял достичь рабочих частот до 500 МГц и передавать 10 Гбит/с на расстояние до 100 метров, правда при строгом соблюдении всех правил монтажа.
А что касается бытовых сетей и скоростей 2,5 Гбит/с, то кабели Cat 6a полностью соответствуют всем требованиям и при этом доступны и недороги.
Хотя Cat 7 красивее и дороже (хотя по реальным параметрам хуже), но это уже что-то из области аудиофилии и прочих антинаучных забав.
Один мой хороший знакомый, третьего дня решил проапгрейдить домашнюю сеть до 2,5 Гбит/с. Зачем? Не спрашивайте. Ну и каждый волен сходить с ума по-своему.
В общем выбрали мы с ним коммутатор, сетевые карты и дело дошло до патч-кордов. И вот он присылает мне пару артикулов и спрашивает, что я об этом думаю.
А артикулы были примерно такие: Патч-корд NAME [круглый, SF/FTP, RJ-45, Cat. 7, длина - N м]
Пытаюсь выяснить причину столь странного выбора, а в ответ слышу – ну это же седьмая категория, это же круто и вообще, они красивые.
Согласиться здесь могу лишь с последним. А вот что такое седьмая категория и чем она отличается от других давайте разбираться.
Что такое категория кабеля? Это стандарт, описывающий его технические характеристики, максимальную частоту передаваемого сигнала и скорости передачи данных на определенные расстояния.
Наиболее распространены и привычны кабели категории Cat 5e, они предусматривают физический размер (диаметр) 24AWG (0,51 мм) и разъем 8P8C RJ-45. Максимальная передаваемая частота – 100 МГц, это обеспечивает связь на скоростях до 1 Гбит/с на расстоянии до 100 м.
Но гигабита скоро стало мало и был разработан новый стандарт – Cat 6, который предполагал несколько более крупный кабель - 23AWG (0,585 мм) и все тот же разъем 8P8C RJ-45. Кабель поддерживал частоту передачи до 250 МГц и поддерживал скорость до 10 Гбит/с на расстоянии до 35-50 м.
Одновременно с ним, а это было в 2002 году, был представлен стандарт Cat 7, который при тех же физических размерах кабеля обеспечивал рабочие частоты до 600 МГц и передачу на скорости 10 Гбит/с на расстояние до 100 метров.
Вот он долгожданный прорыв… или нет? Скорее всего второе. Стандарт Cat 7 предусматривал применение проприетарных разъемов GG45 или TERA. При этом первый из них обратно совместим с RJ-45.
Но все кроется в мелочах. Разъем GG45 предусматривает 4 дополнительных контакта для заземления, а сам кабель седьмой категории обязательно должен быть типа STP (S/UTP), т.е. иметь экран на каждой паре и общий экран для всего кабеля.
Все это серьезно отражается на стоимости и кабель Cat 7 стоит ощутимо дороже своих аналогов.
Так может есть за что переплатить? Увы. Все преимущества данного кабеля раскрываются только с проприетарными разъемами. В режиме совместимости с RJ-45 рабочая частота кабеля падает до 200-250 МГц, т.е. на уровень куда более дешевого Cat 6.
А немного позже вышел Cat 6a, который на обычной витухе позволял достичь рабочих частот до 500 МГц и передавать 10 Гбит/с на расстояние до 100 метров, правда при строгом соблюдении всех правил монтажа.
А что касается бытовых сетей и скоростей 2,5 Гбит/с, то кабели Cat 6a полностью соответствуют всем требованиям и при этом доступны и недороги.
Хотя Cat 7 красивее и дороже (хотя по реальным параметрам хуже), но это уже что-то из области аудиофилии и прочих антинаучных забав.
👍6