Просматривал список необычных утилит Linux, и зацепился взгляд за броское название — fakeroot. Сразу стало интересно, что это за фейковый рут. Впервые услышал это название. Причём утилита старая, есть в базовых репах. Немного почитал про неё, но не сразу въехал, что это в итоге такое и зачем надо.
Покажу сразу на примере. После установки:
Можно запустить:
И вы как будто сделали sudo su. Появилось приветствие в консоли root:
Создаём новый файл и проверяем его права:
Как будто мы работаем под root, создавая файлы с соответствующими правами. При этом, если выйти из fakeroot и проверить права этого файла, окажется, что они как у обычного пользователя, под которым мы подключены:
Fakeroot перехватывает системные вызовы и возвращает их программе, как будто они выполняются под root. Это может быть полезно только в одном случае. Программа из-за нехватки прав завершает работу с ошибкой. Но при этом нам бы хотелось, чтобы она продолжила свою работу, так как отсутствие некоторых прав для нас некритично.
Поясню на простом примере. Вы делаете бэкап каких-то каталогов и там попадаются файлы, к которым у вас вообще нет прав, даже на чтение. Программа, которая делает бэкап, может остановиться с ошибкой, ругнувшись на отсутствие прав. В таком случае её можно запустить в fakeroot. Она будет считать, что имеет доступ ко всему, что ей надо, хотя реально она не прочитает те файлы, к которым у неё нет доступа, но не узнает об этом.
Я, кстати, с этой ситуацией неоднократно сталкивался. Только мне не нужно было пропускать эти файлы, а наоборот — дать права на чтение, чтобы в архив они в итоге попали. Я специально отслеживал такие моменты. Ну а кому-то нужно было их пропускать. В итоге появилась утилита fakeroot.
⇨ Описание FakeRoot на сайте Debian
#linux #terminal
Покажу сразу на примере. После установки:
# apt install fakeroot
Можно запустить:
# fakeroot
И вы как будто сделали sudo su. Появилось приветствие в консоли root:
root@T480:~#
Создаём новый файл и проверяем его права:
# touch file.txt
# ls -la file.txt
-rw-r--r-- 1 root root 0 Jul 26 00:55 file.txt
Как будто мы работаем под root, создавая файлы с соответствующими правами. При этом, если выйти из fakeroot и проверить права этого файла, окажется, что они как у обычного пользователя, под которым мы подключены:
# exit
# ls -la file.txt
-rw-r--r-- 1 zerox zerox 0 Jul 26 00:55 file.txt
Fakeroot перехватывает системные вызовы и возвращает их программе, как будто они выполняются под root. Это может быть полезно только в одном случае. Программа из-за нехватки прав завершает работу с ошибкой. Но при этом нам бы хотелось, чтобы она продолжила свою работу, так как отсутствие некоторых прав для нас некритично.
Поясню на простом примере. Вы делаете бэкап каких-то каталогов и там попадаются файлы, к которым у вас вообще нет прав, даже на чтение. Программа, которая делает бэкап, может остановиться с ошибкой, ругнувшись на отсутствие прав. В таком случае её можно запустить в fakeroot. Она будет считать, что имеет доступ ко всему, что ей надо, хотя реально она не прочитает те файлы, к которым у неё нет доступа, но не узнает об этом.
Я, кстати, с этой ситуацией неоднократно сталкивался. Только мне не нужно было пропускать эти файлы, а наоборот — дать права на чтение, чтобы в архив они в итоге попали. Я специально отслеживал такие моменты. Ну а кому-то нужно было их пропускать. В итоге появилась утилита fakeroot.
⇨ Описание FakeRoot на сайте Debian
#linux #terminal
Необычный бесплатный сервис для обеспечения дополнительной безопасности какого-то периметра — canarytokens.org. С его помощью можно создавать "ловушки", которые сработают, когда кто-то выполнит то или иное действие. Покажу сразу на самом наглядном примере.
Вы можете с помощью сервиса создать документ Word или Exсel, указав свой email адрес. Сервис сгенерирует вам документ, открыв который пользователь увидит пустой лист. При этом о факте открытия вам придёт уведомление на почту с IP адресом того человека, который открыл этот файл.
Конкретно эта проверка с файлом Word работает следующим образом. Документ подписывается сертификатом. Он проверяется при открытии. В сертификате указан список отозванных сертификатов (CRL) на внешнем урле. Офис идёт туда за списком и это обращение отслеживается. Вам тут же приходит уведомление на почту с информацией о том, кто обращался к урлу с CRL списком из вашего документа.
И таких проверок у этого сервиса много. Например, можете сгенерировать URL и получать уведомления, когда кто-то по нему пройдёт. А можете отслеживать даже не переходы, а DNS резолвы поддомена этого урла. Вы увидите информацию о конечном DNS сервере, который обратился за резолвом этого домена. Я проверил эту тему, реально работает проверка с DNS. Можете делать ловушки для подключений Wireguard, для выполнения SQL запросов на MSSQL сервере, для сканирования QR кода и т.д.
Для чего всё это нужно? А тут уже каждый сам может придумать, где и как ему пользоваться. Можете куда-то в свои важные документы положить word файл с именем passwords.docx и следить за ним. Если кто-то откроет этот файл, значит у вас проблемы с безопасностью ваших файлов.
Можете в почту зашить url к какой-нибудь картинке и отследить, когда кто-то откроет это письмо. Или в виндовый файл desktop.ini, в котором хранятся настройки каталога, можно зашить путь к адресу иконки где-то на внешнем сервере. Когда кто-то будет проводником открывать вашу директорию, будете получать уведомления.
В общем, вариантов использования этого сервиса очень много. Посмотрите сами его возможности. Можно использовать как готовый сервис по указанному в начале публикации адресу, так и поднять его у себя. Он open source.
⇨ Сайт / Исходники
#security #сервис
Вы можете с помощью сервиса создать документ Word или Exсel, указав свой email адрес. Сервис сгенерирует вам документ, открыв который пользователь увидит пустой лист. При этом о факте открытия вам придёт уведомление на почту с IP адресом того человека, который открыл этот файл.
Конкретно эта проверка с файлом Word работает следующим образом. Документ подписывается сертификатом. Он проверяется при открытии. В сертификате указан список отозванных сертификатов (CRL) на внешнем урле. Офис идёт туда за списком и это обращение отслеживается. Вам тут же приходит уведомление на почту с информацией о том, кто обращался к урлу с CRL списком из вашего документа.
И таких проверок у этого сервиса много. Например, можете сгенерировать URL и получать уведомления, когда кто-то по нему пройдёт. А можете отслеживать даже не переходы, а DNS резолвы поддомена этого урла. Вы увидите информацию о конечном DNS сервере, который обратился за резолвом этого домена. Я проверил эту тему, реально работает проверка с DNS. Можете делать ловушки для подключений Wireguard, для выполнения SQL запросов на MSSQL сервере, для сканирования QR кода и т.д.
Для чего всё это нужно? А тут уже каждый сам может придумать, где и как ему пользоваться. Можете куда-то в свои важные документы положить word файл с именем passwords.docx и следить за ним. Если кто-то откроет этот файл, значит у вас проблемы с безопасностью ваших файлов.
Можете в почту зашить url к какой-нибудь картинке и отследить, когда кто-то откроет это письмо. Или в виндовый файл desktop.ini, в котором хранятся настройки каталога, можно зашить путь к адресу иконки где-то на внешнем сервере. Когда кто-то будет проводником открывать вашу директорию, будете получать уведомления.
В общем, вариантов использования этого сервиса очень много. Посмотрите сами его возможности. Можно использовать как готовый сервис по указанному в начале публикации адресу, так и поднять его у себя. Он open source.
⇨ Сайт / Исходники
#security #сервис
Если вам нужно заблокировать какую-то страну, чтобы ограничить доступ к вашим сервисам, например, с помощью iptables или nginx, потребуется список IP адресов по странам.
Я сам всегда использую вот эти списки:
⇨ https://www.ipdeny.com/ipblocks
Конкретно в скриптах забираю их по урлам. Например, для России:
⇨ https://www.ipdeny.com/ipblocks/data/countries/ru.zone
Это удобно, потому что списки уже готовы к использованию — одна строка, одно значение. Можно удобно интегрировать в скрипты. Например, вот так:
Тут я создаю список IP адресов для ipset, а потом использую его в iptables:
Если в списке адресов более 1-2 тысяч значений, использовать ipset обязательно. Iptables начнёт отжирать очень много памяти, если загружать огромные списки в него напрямую.
Есть ещё вот такой сервис:
⇨ https://www.ip2location.com/free/visitor-blocker
Там можно сразу конфиг получить для конкретного сервиса: Apache, Nginx, правил Iptables и других. Даже правила в формате Mikrotik есть.
☝ Ссылки рекомендую в закладки забрать.
#iptables #nginx #security #script
Я сам всегда использую вот эти списки:
⇨ https://www.ipdeny.com/ipblocks
Конкретно в скриптах забираю их по урлам. Например, для России:
⇨ https://www.ipdeny.com/ipblocks/data/countries/ru.zone
Это удобно, потому что списки уже готовы к использованию — одна строка, одно значение. Можно удобно интегрировать в скрипты. Например, вот так:
#!/bin/bash
# Удаляем список, если он уже есть
ipset -X whitelist
# Создаем новый список
ipset -N whitelist nethash
# Скачиваем файлы тех стран, что нас интересуют и сразу объединяем в единый список
wget -O netwhite http://www.ipdeny.com/ipblocks/data/countries/{ru,ua,kz,by,uz,md,kg,de,am,az,ge,ee,tj,lv}.zone
echo -n "Загружаем белый список в IPSET..."
# Читаем список сетей и построчно добавляем в ipset
list=$(cat netwhite)
for ipnet in $list
do
ipset -A whitelist $ipnet
done
echo "Завершено"
# Выгружаем созданный список в файл для проверки состава
ipset -L whitelist > w-export
Тут я создаю список IP адресов для ipset, а потом использую его в iptables:
iptables -A INPUT -i $WAN -m set --match-set whitenet src -p tcp --dport 80 -j ACCEPT
Если в списке адресов более 1-2 тысяч значений, использовать ipset обязательно. Iptables начнёт отжирать очень много памяти, если загружать огромные списки в него напрямую.
Есть ещё вот такой сервис:
⇨ https://www.ip2location.com/free/visitor-blocker
Там можно сразу конфиг получить для конкретного сервиса: Apache, Nginx, правил Iptables и других. Даже правила в формате Mikrotik есть.
☝ Ссылки рекомендую в закладки забрать.
#iptables #nginx #security #script
У Zabbix вчера была рассылка с новостями. Давно ничего не писал про него, потому что новостей особо не было. Буднично проходили новости об очередных обновлениях и конференциях в разных странах. А в этот раз они немного подробностей дали по поводу новой версии 7.0, у которой уже 3-я альфа вышла. Так что работа идёт и релиз всё ближе.
Команда Zabbix показала новые виджеты дашборда, которые будут в новой версии. Можете оценить на прикреплённой картинке. Впечатления двоякие. Вроде бы прикольно, но выглядит как-то колхозно всё это. Не получается им к какому-то единому стилю прийти из-за того, что обновления сильно растянуты. Сначала интерфейс обновили, потом частично графики в виджетах, потом новые виджеты стали добавлять, при этом часть графиков так и осталась в старом дизайне, которому уже около 10-ти лет. Мне кажется, им стоило один раз собраться и в каком-то релизе выкатить полное обновление интерфейса и графиков. А то это так и будет вечно продолжаться.
Помимо новых визуализаций, появится виджет с топом триггеров. Я так понял, что это виджет из отчёта 100 наиболее активных триггеров (в русском интерфейсе). Он показывает триггеры, которые чаще всего меняли своё состояние (срабатывали) за указанный период времени. Кстати, удобный отчёт, который позволяет подредактировать триггеры, которые слишком часто срабатывают.
Из тех обновлений, что точно будут в 7.0, отмечу:
◽увеличится поддержка версий до MySQL 8.1 MariaDB 11
◽появится шаблон для мониторинга за PostgreSQL через ODBC
◽появится шаблон для Cisco SD-WAN
◽появится возможность выполнения удалённых команд при активных проверках
◽некоторые настройки переедут в модальные окна (способы оповещений, скрипты и т.д.)
◽увеличат возможности обработки в aggregation functions
Вот и всё наиболее значимое, что было объявлено в последних трех релизах альфы. Пока как-то негусто изменений. По обещанному обновлению модуля инвентаризации, поддержке сторонних TSDB, асинхронному сбору данных не сделано ничего в тех версиях, что опубликованы.
#zabbix
Команда Zabbix показала новые виджеты дашборда, которые будут в новой версии. Можете оценить на прикреплённой картинке. Впечатления двоякие. Вроде бы прикольно, но выглядит как-то колхозно всё это. Не получается им к какому-то единому стилю прийти из-за того, что обновления сильно растянуты. Сначала интерфейс обновили, потом частично графики в виджетах, потом новые виджеты стали добавлять, при этом часть графиков так и осталась в старом дизайне, которому уже около 10-ти лет. Мне кажется, им стоило один раз собраться и в каком-то релизе выкатить полное обновление интерфейса и графиков. А то это так и будет вечно продолжаться.
Помимо новых визуализаций, появится виджет с топом триггеров. Я так понял, что это виджет из отчёта 100 наиболее активных триггеров (в русском интерфейсе). Он показывает триггеры, которые чаще всего меняли своё состояние (срабатывали) за указанный период времени. Кстати, удобный отчёт, который позволяет подредактировать триггеры, которые слишком часто срабатывают.
Из тех обновлений, что точно будут в 7.0, отмечу:
◽увеличится поддержка версий до MySQL 8.1 MariaDB 11
◽появится шаблон для мониторинга за PostgreSQL через ODBC
◽появится шаблон для Cisco SD-WAN
◽появится возможность выполнения удалённых команд при активных проверках
◽некоторые настройки переедут в модальные окна (способы оповещений, скрипты и т.д.)
◽увеличат возможности обработки в aggregation functions
Вот и всё наиболее значимое, что было объявлено в последних трех релизах альфы. Пока как-то негусто изменений. По обещанному обновлению модуля инвентаризации, поддержке сторонних TSDB, асинхронному сбору данных не сделано ничего в тех версиях, что опубликованы.
#zabbix
🎉 Сегодня оказывается день системного администратора. Я и не знал. Не слежу за этим праздником и никогда его не отмечал. Если бы тут в чате не написали, я бы и не вспомнил. Вот шуфутинов день я почему-то никогда не забываю.
Тем не менее, всех сисадминов любителей праздников поздравляю 😁. Вот пример того, как его можно провести (смотреть до конца)
⇨ https://www.youtube.com/watch?v=IhMYtA7ZPLM
По этому поводу предлагаю посмотреть немного развлекательного видео. В разное время мне попадались ролики на тему дня сисадмина. Один из любимых вот этот. Почему-то сразу его вспомнил. Он вроде и не праздничный, но снят хорошо и темы прикольные:
SysAdmin Day 2016
⇨ https://www.youtube.com/watch?v=3XliP_OTjuk
И вот ещё прикольное видео от них же:
This AI can do ANYTHING (SysAdmin Day 2022)
⇨ https://www.youtube.com/watch?v=KuvOwbtSeHk
История про друга айтишника, готового всегда прийти на помощь:
⇨ https://www.youtube.com/watch?v=VFHHbBV9nlo
Переозвучка на тему IT. Там все, и программисты, и сисадмины:
⇨ https://www.youtube.com/watch?v=NuKREeAnm1s
Ещё про программистов вспомнилось прикольное видео. Как на самом деле пишется и проверяется код в больших технологичных компаниях?
⇨ https://www.youtube.com/watch?v=rR4n-0KYeKQ
Помимо дня сисадмина, стоит помнить и про день электрика. А то может случиться вот что:
⇨ https://www.youtube.com/watch?v=9xYrJKYen8Y
Прикольный плейлист с сериями мини сериала на тему A Day in the Life of a SysAdmin. Я все серии смотрел в своё время. Не помню, делал ли заметки об этом. Вроде нет.
⇨ https://www.youtube.com/watch?v=Bo-6lBocYSU&list=PLjRDUUDcXg2GwKQIgNkAe45nkq9tBIXUZ
Не забывайте про сайт https://geekprank.com, когда захотите кого-нибудь разыграть по айтишной теме. Сделано классно.
📌 Ну и для настроения в завершении анекдот:
Умер системный администратор, и попал на небо к Богу. Бог посмотрел на него и говорит, мол ты себя при жизни вел хорошо, грехов немного и поэтому сам выберешь, куда тебе отправляться, в рай или ад. Админ выбирает рай.
Заводит Бог сисадмина в одно помещение, а там стоят крутые сервера, навороченные рабочие станции, быстрая сетка, и говорит: "Это рай, здесь ты будешь жить и развлекаться в свое довольствие, и будешь ты простым пользователем".
У админа глаза заблестели, но из любопытства он все равно просит Бога показать и ад. Бог отвечает: "Ад - это тоже здесь, только тогда ты будешь системным администраторoм".
#юмор
Тем не менее, всех сисадминов любителей праздников поздравляю 😁. Вот пример того, как его можно провести (смотреть до конца)
⇨ https://www.youtube.com/watch?v=IhMYtA7ZPLM
По этому поводу предлагаю посмотреть немного развлекательного видео. В разное время мне попадались ролики на тему дня сисадмина. Один из любимых вот этот. Почему-то сразу его вспомнил. Он вроде и не праздничный, но снят хорошо и темы прикольные:
SysAdmin Day 2016
⇨ https://www.youtube.com/watch?v=3XliP_OTjuk
И вот ещё прикольное видео от них же:
This AI can do ANYTHING (SysAdmin Day 2022)
⇨ https://www.youtube.com/watch?v=KuvOwbtSeHk
История про друга айтишника, готового всегда прийти на помощь:
⇨ https://www.youtube.com/watch?v=VFHHbBV9nlo
Переозвучка на тему IT. Там все, и программисты, и сисадмины:
⇨ https://www.youtube.com/watch?v=NuKREeAnm1s
Ещё про программистов вспомнилось прикольное видео. Как на самом деле пишется и проверяется код в больших технологичных компаниях?
⇨ https://www.youtube.com/watch?v=rR4n-0KYeKQ
Помимо дня сисадмина, стоит помнить и про день электрика. А то может случиться вот что:
⇨ https://www.youtube.com/watch?v=9xYrJKYen8Y
Прикольный плейлист с сериями мини сериала на тему A Day in the Life of a SysAdmin. Я все серии смотрел в своё время. Не помню, делал ли заметки об этом. Вроде нет.
⇨ https://www.youtube.com/watch?v=Bo-6lBocYSU&list=PLjRDUUDcXg2GwKQIgNkAe45nkq9tBIXUZ
Не забывайте про сайт https://geekprank.com, когда захотите кого-нибудь разыграть по айтишной теме. Сделано классно.
📌 Ну и для настроения в завершении анекдот:
Умер системный администратор, и попал на небо к Богу. Бог посмотрел на него и говорит, мол ты себя при жизни вел хорошо, грехов немного и поэтому сам выберешь, куда тебе отправляться, в рай или ад. Админ выбирает рай.
Заводит Бог сисадмина в одно помещение, а там стоят крутые сервера, навороченные рабочие станции, быстрая сетка, и говорит: "Это рай, здесь ты будешь жить и развлекаться в свое довольствие, и будешь ты простым пользователем".
У админа глаза заблестели, но из любопытства он все равно просит Бога показать и ад. Бог отвечает: "Ад - это тоже здесь, только тогда ты будешь системным администраторoм".
#юмор
🎓 Сделал серию заметок про бесплатные курсы на платформе stepik.org и как-то забыл про неё. Там много хороших и полезных курсов, так что продолжу. Если у вас тоже есть на примете хорошие бесплатные курсы, поделитесь информацией.
Регулярные выражения в Python
⇨ https://stepik.org/course/107335/
Здесь вы научитесь составлять и использовать регулярные выражения для решения повседневных задач. В курсе пройдёмся по всем функциям модуля re, разберём работу с группами, изучим флаги, и поймём для чего нужны регулярные выражения.
Рекомендацию на этот курс я получал неоднократно в заметках про регулярки. Перебирал свои записи и вспомнил про него.
Интерактивный тренажер по SQL
⇨ https://stepik.org/course/63054/
В курсе большинство шагов — это практические задания на создание SQL-запросов. Каждый шаг включает минимальные теоретические аспекты по базам данных или языку SQL, примеры похожих запросов и пояснение к реализации.
Админам и девопсам с SQL приходится взаимодействовать постоянно. Базовый синтаксис очень желательно знать. Я немного знаю, но всё равно по шпаргалкам всё делаю, когда надо таблицу создать или запрос выполнить.
Go (Golang) - первое знакомство
⇨ https://stepik.org/course/100208/
Это курс по языку программирования Go (Golang) для самых маленьких. Почему? Потому что показаны будут прежде всего азы (хотя и не только), при этом в достаточно краткой форме.
Go, как и Python, активно используется для создания вспомогательных утилит и сервисов в обслуживании и эксплуатации систем. Знать его хоть чуть-чуть в современном IT будет полезно всем. Я, к сожалению, совсем не знаю.
А может вам просто надоело обслуживание и вы хотите перейти в разработку? Вот пример человека, который из тех поддержки стал программистом на Go.
#обучение #бесплатно
Регулярные выражения в Python
⇨ https://stepik.org/course/107335/
Здесь вы научитесь составлять и использовать регулярные выражения для решения повседневных задач. В курсе пройдёмся по всем функциям модуля re, разберём работу с группами, изучим флаги, и поймём для чего нужны регулярные выражения.
Рекомендацию на этот курс я получал неоднократно в заметках про регулярки. Перебирал свои записи и вспомнил про него.
Интерактивный тренажер по SQL
⇨ https://stepik.org/course/63054/
В курсе большинство шагов — это практические задания на создание SQL-запросов. Каждый шаг включает минимальные теоретические аспекты по базам данных или языку SQL, примеры похожих запросов и пояснение к реализации.
Админам и девопсам с SQL приходится взаимодействовать постоянно. Базовый синтаксис очень желательно знать. Я немного знаю, но всё равно по шпаргалкам всё делаю, когда надо таблицу создать или запрос выполнить.
Go (Golang) - первое знакомство
⇨ https://stepik.org/course/100208/
Это курс по языку программирования Go (Golang) для самых маленьких. Почему? Потому что показаны будут прежде всего азы (хотя и не только), при этом в достаточно краткой форме.
Go, как и Python, активно используется для создания вспомогательных утилит и сервисов в обслуживании и эксплуатации систем. Знать его хоть чуть-чуть в современном IT будет полезно всем. Я, к сожалению, совсем не знаю.
А может вам просто надоело обслуживание и вы хотите перейти в разработку? Вот пример человека, который из тех поддержки стал программистом на Go.
#обучение #бесплатно
Stepik: online education
Регулярные выражения в Python
Здесь вы научитесь научитесь составлять и использовать регулярные выражения для решения повседневных задач. В курсе пройдёмся по всем функциям модуля re, разберём работу с группами, изучим флаги, и поймём для чего нужны регулярные выражения ❤️
Меня часто спрашивают, каким образом можно объединить несколько интернет каналов в один общий. То есть настроить не резервирование, не переключение, не балансировку, а именно одновременное использование нескольких каналов для увеличения суммарной пропускной способности. При этом сами каналы чаще всего разного типа. То есть это не то же самое, что объединить порты на свитчах.
У меня никогда не было опыта подобной настройки. Я понимаю, что технически это сложная задача, как логически, так и архитектурно. Честное суммирование каналов будет приводить к явным проблемам. Например, у клиента канал 1000 мегабит, а у сервиса 3 канала по 100 мегабит. Клиент на полной скорости пытается забрать контент с сервера, который вынужден будет для максимальной скорости утилизировать все 3 канала одновременно. Получается один клиент будет забирать контент с трёх разных маршрутов с разными метриками, откликами, source ip шлюзов и т.д.
Ну и в обратную сторону те же самые проблемы, когда у клиента 3 канала, а у сервиса один. Всё это нужно как-то собирать в единую последовательность, чтобы данные не превращались в кашу. А есть ещё привязки аутентификаций и кук к IP. Что с ними будет?
К чему я всё это? Если у вас возникнет подобная задача (постарайтесь от неё отмахнуться), то дам вам подсказку в виде бесплатного OpenMPTCProuter. Это open source проект программного роутера, который умеет честно суммировать интернет каналы. Для этого он состоит из двух частей. Одна клиентская, которую вы ставите там, где суммируете каналы. А вторая часть располагается где-то в интернете для объединения подключений со всех интернет каналов. Только такая схема может обеспечить реальное объединение каналов и возможность приложениям нормально работать при такой схеме без потери пакетов и разрыва соединений.
Клиентская часть, где будут подключены интернет каналы, может быть установлена на обычный x86, x86_64 Linux, Raspberry PI 2B/3B/3B+/4B, Linksys WRT3200ACM/WRT32X, Teltonika RUTX12, Banana PI BPI-R2. Она построена на базе OpenWRT. Суммирующий сервер может быть развёрнут в интернете на обычном VPS на базе Debian или Ubuntu.
Настройка, на удивление для такого продукта, не сложная. Я сам не пробовал, но есть руководство на сайте и инструкции в интернете. Настраивается суммирующий сервер с помощью готового скрипта. Потом поднимаем из образа клиентскую часть. Через веб интерфейс настраиваем интернет каналы и указываем настройки подключения к суммирующему серверу. Этого минимума будет достаточно, чтобы всё заработало.
Это единственное бесплатное решение, которое мне знакомо по данной задаче. Все другие входят в состав дорогих коммерческих продуктов. Из не очень дорогого я когда-то видел коробочку с несколькими USB модемами, но не уверен, что там было честное объединение, а не резервирование и переключение. Да и то название забыл.
Если кто-то пользовался подобными или конкретно этой системой, то дайте обратную связь. Как на практике работает объединение каналов? Тут же куча сопутствующих проблем возникает от банальной настройки файрвола до проброса портов. Не понятно, как это должно работать в таких схемах.
#network
У меня никогда не было опыта подобной настройки. Я понимаю, что технически это сложная задача, как логически, так и архитектурно. Честное суммирование каналов будет приводить к явным проблемам. Например, у клиента канал 1000 мегабит, а у сервиса 3 канала по 100 мегабит. Клиент на полной скорости пытается забрать контент с сервера, который вынужден будет для максимальной скорости утилизировать все 3 канала одновременно. Получается один клиент будет забирать контент с трёх разных маршрутов с разными метриками, откликами, source ip шлюзов и т.д.
Ну и в обратную сторону те же самые проблемы, когда у клиента 3 канала, а у сервиса один. Всё это нужно как-то собирать в единую последовательность, чтобы данные не превращались в кашу. А есть ещё привязки аутентификаций и кук к IP. Что с ними будет?
К чему я всё это? Если у вас возникнет подобная задача (постарайтесь от неё отмахнуться), то дам вам подсказку в виде бесплатного OpenMPTCProuter. Это open source проект программного роутера, который умеет честно суммировать интернет каналы. Для этого он состоит из двух частей. Одна клиентская, которую вы ставите там, где суммируете каналы. А вторая часть располагается где-то в интернете для объединения подключений со всех интернет каналов. Только такая схема может обеспечить реальное объединение каналов и возможность приложениям нормально работать при такой схеме без потери пакетов и разрыва соединений.
Клиентская часть, где будут подключены интернет каналы, может быть установлена на обычный x86, x86_64 Linux, Raspberry PI 2B/3B/3B+/4B, Linksys WRT3200ACM/WRT32X, Teltonika RUTX12, Banana PI BPI-R2. Она построена на базе OpenWRT. Суммирующий сервер может быть развёрнут в интернете на обычном VPS на базе Debian или Ubuntu.
Настройка, на удивление для такого продукта, не сложная. Я сам не пробовал, но есть руководство на сайте и инструкции в интернете. Настраивается суммирующий сервер с помощью готового скрипта. Потом поднимаем из образа клиентскую часть. Через веб интерфейс настраиваем интернет каналы и указываем настройки подключения к суммирующему серверу. Этого минимума будет достаточно, чтобы всё заработало.
Это единственное бесплатное решение, которое мне знакомо по данной задаче. Все другие входят в состав дорогих коммерческих продуктов. Из не очень дорогого я когда-то видел коробочку с несколькими USB модемами, но не уверен, что там было честное объединение, а не резервирование и переключение. Да и то название забыл.
Если кто-то пользовался подобными или конкретно этой системой, то дайте обратную связь. Как на практике работает объединение каналов? Тут же куча сопутствующих проблем возникает от банальной настройки файрвола до проброса портов. Не понятно, как это должно работать в таких схемах.
#network
Минцифры давно уже запустило маркетплейс российского ПО. Выглядит он удобно и содержательно:
⇨ https://russoft.ru
Только сразу прошу, не надо обсуждать политику, чиновников, импортозамещение и прочее. Это не имеет смысла. Я просто делюсь информацией о хорошо организованном каталоге. Даже и не знал, что существует столько отечественного ПО.
Например, идём в Системное ПО ⇨ Управление IT-инфраструктурой. Видим 17 продуктов, про большую часть которых я даже не слышал. Тут сразу указана примерная стоимость и есть ссылка на сайт продукта. Немного изучил список. Привлекло внимание название Управление IT-отделом 8. Посмотрел, а это help desk и инвентаризация на базе платформы 1С. Причём там и веб интерфейс есть, и интеграция с Telegram ботами. 1С, как ни крути, мощная платформа. На её базе всё, что угодно можно делать.
К каждому ПО указан список иностранных аналогов. Так что если вы ищите замену чему-либо, можно сразу по этому продукту искать. Для примера забил Zabbix и увидел список ПО для мониторинга. Вообще ни один продукт из этого списка не знаком.
Почитал новости о релизе этого каталога. Обещали в будущем сделать рейтинг и отзывы, но пока ничего этого нет. А последние новости на сайте от марта этого года. Такое ощущение, что портал сделали, бюджет кончился и его заморозили. Надеюсь, что разморозят и продолжат развивать. Идея хорошая.
#отечественное
⇨ https://russoft.ru
Только сразу прошу, не надо обсуждать политику, чиновников, импортозамещение и прочее. Это не имеет смысла. Я просто делюсь информацией о хорошо организованном каталоге. Даже и не знал, что существует столько отечественного ПО.
Например, идём в Системное ПО ⇨ Управление IT-инфраструктурой. Видим 17 продуктов, про большую часть которых я даже не слышал. Тут сразу указана примерная стоимость и есть ссылка на сайт продукта. Немного изучил список. Привлекло внимание название Управление IT-отделом 8. Посмотрел, а это help desk и инвентаризация на базе платформы 1С. Причём там и веб интерфейс есть, и интеграция с Telegram ботами. 1С, как ни крути, мощная платформа. На её базе всё, что угодно можно делать.
К каждому ПО указан список иностранных аналогов. Так что если вы ищите замену чему-либо, можно сразу по этому продукту искать. Для примера забил Zabbix и увидел список ПО для мониторинга. Вообще ни один продукт из этого списка не знаком.
Почитал новости о релизе этого каталога. Обещали в будущем сделать рейтинг и отзывы, но пока ничего этого нет. А последние новости на сайте от марта этого года. Такое ощущение, что портал сделали, бюджет кончился и его заморозили. Надеюсь, что разморозят и продолжат развивать. Идея хорошая.
#отечественное
Я активно использую как в работе, так и в личных целях, Яндекс.Диск. У него очень низкая стоимость хранения данных. В Linux использую либо API для загрузки данных, либо rclone.
Для Windows использовал либо родной клиент, что не очень удобно, либо монтировал сетевой диск в Linux и там с ним работал. Не знал, что полнофункциональный rclone нормально работает в Windows, причём абсолютно так же, как в Linux. Настройка 1 в 1.
Установить можно как вручную, так и с помощью winget:
Через winget не сразу понял, куда он был установлен. Оказалось, что в директорию C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\Rclone.Rclone_Microsoft.Winget.Source_8wekyb3d8bbwe\rclone-v1.63.1-windows-amd64.
Для настройки работы rclone с Яндекс диском нужно получить токен. Как это сделать, я описывал в заметке по работе с API. Единственное отличие — нужно предоставить побольше прав:
▪ Доступ к папке приложения на Диске
▪ Доступ к информации о Диске
▪ Запись в любом месте на Диске
▪ Доступ к Яндекс.Диску для приложений
А в качестве Redirect URI использовать ссылку: http://127.0.0.1:53682/
После этого запускаете в консоли команду:
Выбираете New remote ⇨ указываете название, например yandex ⇨ номер 48, соответствующий хранилищу Яндекс диск ⇨ client_id и client_secret оставляете пустыми ⇨ выполняете запрос токена ⇨ сохраняете конфиг.
У вас появится файл в C:\Users\User\AppData\Roaming\rclone\rclone.conf примерно следующего содержания:
[yandex]
type = yandex
client_id =
client_secret =
token = {"access_token":"y0_AgAAAABvmXfPAALEtgAAAAKpIA8y2bb-M0IiRFu068gJJKvzSOGoBBs","token_type":"OAuth","refresh_token":"1:p0NRuhts1VI1N7Sq:NWEoGv963fVVGSpE_k8Mftn6Pd8AKsFcte2WGqv77mKgWaoer36TX4irbubWTfCgk9_Gxh5NLBzkWA:b_dCjrHMIEMkKeH-oOFrFQ","expiry":"2024-07-30T20:45:05.4991551+03:00"}
Теперь можно через консоль загружать туда файлы:
Положили в корень диска файл test.txt
Помимо загрузки файлов, rclone умеет монтировать внешние хранилища как локальные или сетевые диски. Для этого ему нужна программа winfsp. Поставить можно тоже через winget:
Монтируем яндекс диск в режиме чтения:
Или в режиме записи:
Яндекс диск смонтирован в виде локального диска X. Подробнее о монтировании в Windows, о правах доступа и прочих нюансах можно прочитать в документации.
Если для вас всё это слишком замороченно и хочется попроще, то вот набор программ, которые реализуют то же самое. Это платные программы, с ограниченными бесплатными версиями. Они удобны и популярны, так что при желании, вы найдёте репаки платных версий, но аккуратнее с ними. Я лично давно уже опасаюсь использовать ломаный софт.
🔹Air Explorer — двухпанельный файловый менеджер, который позволяет работать с облачными сервисами как с локальными директориями. Поддерживает и Яндекс.Диск, и диск от Mail ru.
🔹Air Live Drive — программа от того же производителя, которая позволят монтировать облачные диски как локальные.
🔹RaiDrive — писал об этой программе ранее. Позволяет подключать различные облачные сервисы как локальные диски.
#windows #rclone #backup
Для Windows использовал либо родной клиент, что не очень удобно, либо монтировал сетевой диск в Linux и там с ним работал. Не знал, что полнофункциональный rclone нормально работает в Windows, причём абсолютно так же, как в Linux. Настройка 1 в 1.
Установить можно как вручную, так и с помощью winget:
> winget install rclone
Через winget не сразу понял, куда он был установлен. Оказалось, что в директорию C:\Users\User\AppData\Local\Microsoft\WinGet\Packages\Rclone.Rclone_Microsoft.Winget.Source_8wekyb3d8bbwe\rclone-v1.63.1-windows-amd64.
Для настройки работы rclone с Яндекс диском нужно получить токен. Как это сделать, я описывал в заметке по работе с API. Единственное отличие — нужно предоставить побольше прав:
▪ Доступ к папке приложения на Диске
▪ Доступ к информации о Диске
▪ Запись в любом месте на Диске
▪ Доступ к Яндекс.Диску для приложений
А в качестве Redirect URI использовать ссылку: http://127.0.0.1:53682/
После этого запускаете в консоли команду:
> rclone config
Выбираете New remote ⇨ указываете название, например yandex ⇨ номер 48, соответствующий хранилищу Яндекс диск ⇨ client_id и client_secret оставляете пустыми ⇨ выполняете запрос токена ⇨ сохраняете конфиг.
У вас появится файл в C:\Users\User\AppData\Roaming\rclone\rclone.conf примерно следующего содержания:
[yandex]
type = yandex
client_id =
client_secret =
token = {"access_token":"y0_AgAAAABvmXfPAALEtgAAAAKpIA8y2bb-M0IiRFu068gJJKvzSOGoBBs","token_type":"OAuth","refresh_token":"1:p0NRuhts1VI1N7Sq:NWEoGv963fVVGSpE_k8Mftn6Pd8AKsFcte2WGqv77mKgWaoer36TX4irbubWTfCgk9_Gxh5NLBzkWA:b_dCjrHMIEMkKeH-oOFrFQ","expiry":"2024-07-30T20:45:05.4991551+03:00"}
Теперь можно через консоль загружать туда файлы:
> rclone copy C:\Users\User\Downloads\test.txt yandex:/
Положили в корень диска файл test.txt
Помимо загрузки файлов, rclone умеет монтировать внешние хранилища как локальные или сетевые диски. Для этого ему нужна программа winfsp. Поставить можно тоже через winget:
> winget install winfsp
Монтируем яндекс диск в режиме чтения:
> rclone mount yandex:/ X:
Или в режиме записи:
> rclone mount yandex:/ X: --vfs-cache-mode writes
Яндекс диск смонтирован в виде локального диска X. Подробнее о монтировании в Windows, о правах доступа и прочих нюансах можно прочитать в документации.
Если для вас всё это слишком замороченно и хочется попроще, то вот набор программ, которые реализуют то же самое. Это платные программы, с ограниченными бесплатными версиями. Они удобны и популярны, так что при желании, вы найдёте репаки платных версий, но аккуратнее с ними. Я лично давно уже опасаюсь использовать ломаный софт.
🔹Air Explorer — двухпанельный файловый менеджер, который позволяет работать с облачными сервисами как с локальными директориями. Поддерживает и Яндекс.Диск, и диск от Mail ru.
🔹Air Live Drive — программа от того же производителя, которая позволят монтировать облачные диски как локальные.
🔹RaiDrive — писал об этой программе ранее. Позволяет подключать различные облачные сервисы как локальные диски.
#windows #rclone #backup
В Linux можно на ходу уменьшать или увеличивать количество используемой оперативной памяти. Единственное условие - если уменьшаете активную оперативную память, она должна быть свободна. Покажу на примерах.
Для начала воспользуемся командой lsmem для просмотра информации об использовании оперативной памяти. Команда, кстати, полезная. Рекомендую запомнить и использовать. С её помощью можно быстро посмотреть полную информацию об оперативе сервера:
Команда показывает в том числе блоки оперативной памяти, на которые её разбивает ядро. Вот с этими блоками и можно работать. Видим, что у нас 32 блока по 128M, а всего 4G памяти и вся она активна. Отключим 1G c помощью chmem.
или отключим 8 произвольных блоков:
Утилита пройдётся по всем блокам памяти. Те, что могут быть освобождены, она отключит. Процесс может занимать много времени, так как утилита будет пытаться перемещать информацию по памяти, чтобы высвободить заданный объём.
Проверяем, что получилось:
Возвращаем всё как было:
Вряд ли вам часто может быть нужна эта возможность. Но иногда может пригодиться, так что стоит знать о ней. Например, в некоторых системах виртуализации, добавленная на ходу память добавляется как offline и её нужно вручную активировать.
Ещё вариант, если вы точно знаете диапазон битой памяти. Вы можете отключить содержащий её блок с помощью chmem и какое-то время сервер ещё поработает.
#linux #terminal
Для начала воспользуемся командой lsmem для просмотра информации об использовании оперативной памяти. Команда, кстати, полезная. Рекомендую запомнить и использовать. С её помощью можно быстро посмотреть полную информацию об оперативе сервера:
# lsmem
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x00000000f7ffffff 3.9G online yes 0-30
0x0000000100000000-0x0000000107ffffff 128M online yes 32
Memory block size: 128M
Total online memory: 4G
Total offline memory: 0B
Команда показывает в том числе блоки оперативной памяти, на которые её разбивает ядро. Вот с этими блоками и можно работать. Видим, что у нас 32 блока по 128M, а всего 4G памяти и вся она активна. Отключим 1G c помощью chmem.
# chmem -d 1G
или отключим 8 произвольных блоков:
# chmem -d -b 22-29
Утилита пройдётся по всем блокам памяти. Те, что могут быть освобождены, она отключит. Процесс может занимать много времени, так как утилита будет пытаться перемещать информацию по памяти, чтобы высвободить заданный объём.
Проверяем, что получилось:
# lsmem
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x00000000afffffff 2.8G online yes 0-21
0x00000000b0000000-0x00000000efffffff 1G offline 22-29
0x00000000f0000000-0x00000000f7ffffff 128M online yes 30
0x0000000100000000-0x0000000107ffffff 128M online yes 32
Memory block size: 128M
Total online memory: 3G
Total offline memory: 1G
Возвращаем всё как было:
# chmem -e 1G
Вряд ли вам часто может быть нужна эта возможность. Но иногда может пригодиться, так что стоит знать о ней. Например, в некоторых системах виртуализации, добавленная на ходу память добавляется как offline и её нужно вручную активировать.
Ещё вариант, если вы точно знаете диапазон битой памяти. Вы можете отключить содержащий её блок с помощью chmem и какое-то время сервер ещё поработает.
#linux #terminal
Объясню простыми словами отличия современных систем контейнеризации. Для тех, кто с ними постоянно не работает, не очевидно, что они могут различаться принципиально по областям применения. Акцент сделаю на наиболее популярных Docker и LXC, а в конце немного по остальным пройдусь.
Все контейнеры используют одно и то же ядро операционной системы Linux и работают в его рамках. Это принципиальное отличие от виртуальных машин. А принципиальное отличие Docker от LXC в том, что Docker ориентируется на запуск приложений, а LXC на запуск системы.
Поясню на конкретном примере. Допустим, вам надо запустить в работу веб сервер. Если вы будете делать это с помощью Docker, то на хостовой машине запустите контейнер с Nginx, контейнер с Php-fpm, создадите на хосте локальные директории с файлами сайта и конфигурациями сервисов и пробросите их внутрь контейнеров, чтобы у них был доступ к ним. В самих контейнерах кроме непосредственно сервисов Nginx и Php-fpm практически ничего не будет.
Если ту же задачу решать с помощью LXC, то вы просто запустите контейнер с нужной базовой системой внутри. Зайдёте внутрь контейнера и настроите там всё, как обычно это делаете на отдельной виртуальной машине. То есть LXC максимально повторяет работу полноценной системы, только работает на базе ядра хоста.
☝ Docker - это один контейнер, одна служба, LXC - набор служб для решения конкретной задачи. При этом в образ Docker тоже можно поместить практически полноценную систему, но так обычно никто не делает, хотя и есть исключения.
Исходя из этих пояснений, становятся понятны плюсы и минусы каждого подхода. Плюсы Docker:
◽минимальный объём образов, соответственно, максимальная скорость запуска нужных сервисов;
◽для бэкапа достаточно сохранить непосредственно данные, образы можно опустить, так как они типовые.
Минусы:
◽более сложная настройка по сравнению с обычной виртуальной машиной, особенно что касается сети и диагностики в целом.
Плюсы LXC:
◽настройка практически такая же, как на обычной VM, заходишь внутрь контейнера по SSH и настраиваешь.
Минусы LXC:
◽итоговые образы бОльшего объёма, так как содержат всё окружение стандартных систем.
◽сложнее автоматизировать и стандартизировать разворачивание масштабных сервисов.
LXC отлично подходит как замена полноценной VM. Его удобно настроить, забэкапить в единый образ и развернуть в том же виде в другом месте. Docker идеален для максимальной плотности сервисов на одном сервере. Думаю именно за это он стал так популярен. На больших масштабах это заметная экономия средств, поэтому крупные компании его активно используют и продвигают.
Аналогом Docker в плане подхода в виде запуска отдельных служб в контейнерах является Podman. Там есть незначительные отличия в реализации, но в целом они очень похожи. Это продукт компании RedHat, и они его всячески продвигают.
Ещё упомяну про LXD, который иногда сравнивают с LXC, хотя это разные вещи. По сути, LXD - надстройка над LXC, предоставляющая REST API для работы с контейнерами LXC. Она упрощает работу с ними, стандартизирует и даёт удобные инструменты управления. При этом LXD может работать не только с контейнерами LXC, но и с виртуальными машинами QEMU.
Надеюсь ничего нигде не напутал. Писал своими словами по памяти, так как с Docker и LXC практически постоянно работаю и примерно представляю, как они устроены.
#docker #lxc
Все контейнеры используют одно и то же ядро операционной системы Linux и работают в его рамках. Это принципиальное отличие от виртуальных машин. А принципиальное отличие Docker от LXC в том, что Docker ориентируется на запуск приложений, а LXC на запуск системы.
Поясню на конкретном примере. Допустим, вам надо запустить в работу веб сервер. Если вы будете делать это с помощью Docker, то на хостовой машине запустите контейнер с Nginx, контейнер с Php-fpm, создадите на хосте локальные директории с файлами сайта и конфигурациями сервисов и пробросите их внутрь контейнеров, чтобы у них был доступ к ним. В самих контейнерах кроме непосредственно сервисов Nginx и Php-fpm практически ничего не будет.
Если ту же задачу решать с помощью LXC, то вы просто запустите контейнер с нужной базовой системой внутри. Зайдёте внутрь контейнера и настроите там всё, как обычно это делаете на отдельной виртуальной машине. То есть LXC максимально повторяет работу полноценной системы, только работает на базе ядра хоста.
☝ Docker - это один контейнер, одна служба, LXC - набор служб для решения конкретной задачи. При этом в образ Docker тоже можно поместить практически полноценную систему, но так обычно никто не делает, хотя и есть исключения.
Исходя из этих пояснений, становятся понятны плюсы и минусы каждого подхода. Плюсы Docker:
◽минимальный объём образов, соответственно, максимальная скорость запуска нужных сервисов;
◽для бэкапа достаточно сохранить непосредственно данные, образы можно опустить, так как они типовые.
Минусы:
◽более сложная настройка по сравнению с обычной виртуальной машиной, особенно что касается сети и диагностики в целом.
Плюсы LXC:
◽настройка практически такая же, как на обычной VM, заходишь внутрь контейнера по SSH и настраиваешь.
Минусы LXC:
◽итоговые образы бОльшего объёма, так как содержат всё окружение стандартных систем.
◽сложнее автоматизировать и стандартизировать разворачивание масштабных сервисов.
LXC отлично подходит как замена полноценной VM. Его удобно настроить, забэкапить в единый образ и развернуть в том же виде в другом месте. Docker идеален для максимальной плотности сервисов на одном сервере. Думаю именно за это он стал так популярен. На больших масштабах это заметная экономия средств, поэтому крупные компании его активно используют и продвигают.
Аналогом Docker в плане подхода в виде запуска отдельных служб в контейнерах является Podman. Там есть незначительные отличия в реализации, но в целом они очень похожи. Это продукт компании RedHat, и они его всячески продвигают.
Ещё упомяну про LXD, который иногда сравнивают с LXC, хотя это разные вещи. По сути, LXD - надстройка над LXC, предоставляющая REST API для работы с контейнерами LXC. Она упрощает работу с ними, стандартизирует и даёт удобные инструменты управления. При этом LXD может работать не только с контейнерами LXC, но и с виртуальными машинами QEMU.
Надеюсь ничего нигде не напутал. Писал своими словами по памяти, так как с Docker и LXC практически постоянно работаю и примерно представляю, как они устроены.
#docker #lxc
🔝Чуть не забыл про очередной топ постов за прошедший месяц. Надо будет попробовать собрать похожую информацию за прошедшее полугодие. И в целом сформировать какой-то список наиболее интересных и полезных заметок. Пока думаю, как это всё оформить. Написано уже море всего и какую-то часть я сам забываю. Приходится использовать поиск по каналу, чтобы не писать об одном и том же. Как же быстро летит время. Вроде недавно начал вести канал, а на самом деле прошло уже много лет и написаны тысячи заметок.
📌 Больше всего просмотров:
◽️Видео "Веселенький денек у сисадмина" (7381)
◽️Облачный сервис Grafana Cloud (7320)
◽️Списки IP адресов Google и Yandex (7301)
📌 Больше всего комментариев:
◽️Мифы про Astra Linux (154)
◽️Обновление Proxmox 7 до 8 (121)
◽️Заметка про бумажные копии электронных документов (69)
📌 Больше всего пересылок:
◽️Списки IP адресов по странам (489)
◽️Сервис уведомлений ntfy.sh (392)
◽️Создание ловушек с помощью canarytokens.org (372)
📌 Больше всего реакций:
◽️Мифы про Astra Linux (205)
◽️Заметка про бумажные копии электронных документов (180)
◽️Маркетплейс российского ПО от Минцифры (162)
◽️Расследование внезапной перезагрузки сервера (148)
#топ
📌 Больше всего просмотров:
◽️Видео "Веселенький денек у сисадмина" (7381)
◽️Облачный сервис Grafana Cloud (7320)
◽️Списки IP адресов Google и Yandex (7301)
📌 Больше всего комментариев:
◽️Мифы про Astra Linux (154)
◽️Обновление Proxmox 7 до 8 (121)
◽️Заметка про бумажные копии электронных документов (69)
📌 Больше всего пересылок:
◽️Списки IP адресов по странам (489)
◽️Сервис уведомлений ntfy.sh (392)
◽️Создание ловушек с помощью canarytokens.org (372)
📌 Больше всего реакций:
◽️Мифы про Astra Linux (205)
◽️Заметка про бумажные копии электронных документов (180)
◽️Маркетплейс российского ПО от Минцифры (162)
◽️Расследование внезапной перезагрузки сервера (148)
#топ
У меня на днях будет задача по переносу баз 1С с MSSQL на PostgreSQL. Переезжаем полностью с Windows Server на Debian. По этому поводу у меня есть относительно свежая ссылка (2022 год):
⇨ Частые вопросы по миграции базы данных 1С с MS SQL на PostgreSQL
Пришло время с ней поработать. Делаю для вас краткую выжимку, чтобы можно было использовать как шпаргалку. А когда сделаю перенос, напишу, как всё организовал. У меня есть свой подход к организации сервера для 1С.
1️⃣ Тюним PostgreSQL под ресурсы системы. Особое внимание на параметры shared_buffers, work_mem, temp_buffers, huge_pages. Если будете использовать сборку от PostgreSQL Pro, то там все важные параметры настраиваются автоматически после установки пакета.
Отдельно обратите внимание на autovacuum_max_workers. Параметр вычисляют так: кол-во vCPU / 2. И так же по этой теме настраиваем autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor, autovacuum_vacuum_cost_limit.
2️⃣ Тюним систему под максимальную производительность СУБД:
3️⃣ Сам перенос проще всего выполнить через выгрузку в dt и последующую загрузку. Если база очень большая и недопустим простой, то перенос можно выполнять с помощью планов обмена.
4️⃣ Выгружать и загружать dt файлы быстрее и удобнее через автономный сервер ibcmd. В этот момент базу лучше отключить от сервера приложений, либо просто остановить его на время, если есть возможность.
Подробно всё это описано в статье по ссылке. Там же есть и сравнение производительности. В среднем по всем тестам MSSQL немного быстрее PostgreSQL, но не критично. Есть тесты, где одна база быстрее другой и наоборот. Среднее, как я уже сказал, выходит немного в пользу MSSQL.
#1С
⇨ Частые вопросы по миграции базы данных 1С с MS SQL на PostgreSQL
Пришло время с ней поработать. Делаю для вас краткую выжимку, чтобы можно было использовать как шпаргалку. А когда сделаю перенос, напишу, как всё организовал. У меня есть свой подход к организации сервера для 1С.
1️⃣ Тюним PostgreSQL под ресурсы системы. Особое внимание на параметры shared_buffers, work_mem, temp_buffers, huge_pages. Если будете использовать сборку от PostgreSQL Pro, то там все важные параметры настраиваются автоматически после установки пакета.
Отдельно обратите внимание на autovacuum_max_workers. Параметр вычисляют так: кол-во vCPU / 2. И так же по этой теме настраиваем autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor, autovacuum_vacuum_cost_limit.
2️⃣ Тюним систему под максимальную производительность СУБД:
sysctl -w vm.swappines=2
sysctl -w vm.overcommit_memory=2
3️⃣ Сам перенос проще всего выполнить через выгрузку в dt и последующую загрузку. Если база очень большая и недопустим простой, то перенос можно выполнять с помощью планов обмена.
4️⃣ Выгружать и загружать dt файлы быстрее и удобнее через автономный сервер ibcmd. В этот момент базу лучше отключить от сервера приложений, либо просто остановить его на время, если есть возможность.
Подробно всё это описано в статье по ссылке. Там же есть и сравнение производительности. В среднем по всем тестам MSSQL немного быстрее PostgreSQL, но не критично. Есть тесты, где одна база быстрее другой и наоборот. Среднее, как я уже сказал, выходит немного в пользу MSSQL.
#1С
Пока занимался с PostgreSQL, вспомнил про простой и быстрый способ посмотреть статистику по запросам, который я использовал очень давно. Ещё во времена, когда не пользовался централизованными системами по сбору и анализу логов. Проверил методику, на удивление всё работает до сих пор, так что расскажу вам.
Речь пойдёт про анализатор запросов pgFouine. Продукт старый, последняя версия от 2010-го года. Обновление есть только для совместимости с версией php 7. Сам анализатор - это одиночный скрипт на php, который на входе берёт лог с запросами, а на выходе формирует одну html страницу со статистикой, которая включает в себя:
◽общую статистику по запросам, в том числе по их типам
◽запросы, которые занимают больше всего времени СУБД
◽топ медленных запросов
◽счётчик повторяющихся запросов
Для того, чтобы включить сбор логов, в конфигурационный файл PostgreSQL нужно добавить следующие параметры:
Это мы собираем только медленные запросы, дольше трех секунд. Если указать
Имеет смысл также отключить запись этих логов в общий лог, добавив
Перезапускаем сервисы:
Ждём, когда заполнится лог и отправляем его в pgFouine. Для этого достаточно скопировать себе файл pgfouine.php или весь репозиторий:
Теперь файл report.html можно открыть в браузере и посмотреть статистику. Предварительно нужно установить php, либо передать лог с запросами на машину, где php установлен. У меня нормально отработал на версии php 7.4.
Такой вот олдскул. Сейчас не знаю, кто так статистику смотрит. Есть парсеры логов для ELK или Graylog. Но для этого у вас должны быть эти системы. Надо туда отправить логи, распарсить, собрать дашборды. Это пуд соли съесть. А подобный разовый анализ можно сделать за 10 минут.
#postgresql
Речь пойдёт про анализатор запросов pgFouine. Продукт старый, последняя версия от 2010-го года. Обновление есть только для совместимости с версией php 7. Сам анализатор - это одиночный скрипт на php, который на входе берёт лог с запросами, а на выходе формирует одну html страницу со статистикой, которая включает в себя:
◽общую статистику по запросам, в том числе по их типам
◽запросы, которые занимают больше всего времени СУБД
◽топ медленных запросов
◽счётчик повторяющихся запросов
Для того, чтобы включить сбор логов, в конфигурационный файл PostgreSQL нужно добавить следующие параметры:
log_destination = 'syslog'
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
log_min_duration_statement = 3000 # 3000 мс = 3 секунды
log_duration = off
log_statement = 'none'
Это мы собираем только медленные запросы, дольше трех секунд. Если указать
log_min_duration_statement = 0
, будут логироваться все запросы. Логи будут писаться в syslog. Имеет смысл поместить их в отдельный файл. Для этого добавляем в конфигурационный файл rsyslog:LOCAL0.* -/var/log/postgresql/sql.log
Имеет смысл также отключить запись этих логов в общий лог, добавив
LOCAL0.none
:*.*;auth,authpriv.none;LOCAL0.none -/var/log/syslog
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none;\
LOCAL0.none -/var/log/messages
Перезапускаем сервисы:
# systemctl restart postgresql
# systemctl restart rsyslog
Ждём, когда заполнится лог и отправляем его в pgFouine. Для этого достаточно скопировать себе файл pgfouine.php или весь репозиторий:
# git clone https://github.com/milo/pgFouine
# cd pgFouine
# php pgfouine.php -file /var/log/postgresql/sql.log > report.html
Теперь файл report.html можно открыть в браузере и посмотреть статистику. Предварительно нужно установить php, либо передать лог с запросами на машину, где php установлен. У меня нормально отработал на версии php 7.4.
Такой вот олдскул. Сейчас не знаю, кто так статистику смотрит. Есть парсеры логов для ELK или Graylog. Но для этого у вас должны быть эти системы. Надо туда отправить логи, распарсить, собрать дашборды. Это пуд соли съесть. А подобный разовый анализ можно сделать за 10 минут.
#postgresql
Дошли руки обработать ещё одно руководство от CIS на тему настройки Ubuntu Linux 22.04 LTS (нужна регистрация). Это огромный документ на 865 страниц. Я его весь просмотрел и постарался уместить в одну заметку то, что посчитал наиболее полезным и уместным для сервера общего назначения (рекомендации Level 1 - Server). Все детали упоминаемых настроек в подробностях описаны в исходном файле.
🔹Отключите поддержку неиспользуемых файловых систем (cramfs, squashfs, udf и т.д.). Достаточно отключить соответствующие модули ядра. Пример:
🔹/tmp и /var/tmp лучше вынести в отдельный раздел со своими параметрами. Например, noexec, nosuid, nodev и т.д. В идеале, отдельный раздел и настройки должны быть ещё и у /var/log, /home, /dev/shm. Пример параметров в fstab:
🔹Отслеживайте изменения в системных файлах, например с помощью AIDE (Advanced Intrusion Detection Environment):
🔹Убедитесь, что загрузка в single user mode требует аутентификации. Для этого обязательно установите пароль root:
🔹Отключите Apport Error Reporting Service, которая автоматически отправляет информацию о сбоях (по умолчанию включена):
🔹По возможности включайте, настраивайте AppArmor.
🔹Настройте синхронизацию времени какой-то одной службой (chrony, ntp или systemd-timesyncd).
🔹Проверьте все открытые порты и отключите всё ненужное:
🔹Отключите неиспользуемые сетевые протоколы. Например, ipv6. В документе представлена подробная инструкция, как это сделать. Но при этом сделана пометка, что в общем случае рекомендуется оставить ipv6, но корректно настроить всё, что с ним связано. Другие протоколы, которые в общем случае не нужны, но активны: dccp, sctp, rds, tipc. Только убедитесь, что они реально не используются. Какие-то из них могут быть нужны для работы некоторых кластеров.
🔹Настройте Firewall (UFW). Запретите все соединения, кроме разрешённых явно (нормально закрытый файрвол). Не забудьте про все используемые протоколы, в том числе ipv6.
🔹Настройте аудит доступа, изменения, удаления системных файлов с помощью auditctl.
Убедитесь, что доступ к логам сервиса ограничен.
🔹По возможности настройте отправку системных логов куда-то вовне. Используйте systemd-journal-remote или rsyslog.
🔹Настройте логирование действий через sudo. Добавьте через
Ограничьте использование
Документ огромный, но на самом деле там не так много информации. Очень много подробностей по аудиту, логам, файрволу. Если вам реально нужно разобраться, как всё это настраивается, то там есть все примеры вплоть до каждой команды и скрипта.
#cis #security #linux
🔹Отключите поддержку неиспользуемых файловых систем (cramfs, squashfs, udf и т.д.). Достаточно отключить соответствующие модули ядра. Пример:
# modprobe -f udf
🔹/tmp и /var/tmp лучше вынести в отдельный раздел со своими параметрами. Например, noexec, nosuid, nodev и т.д. В идеале, отдельный раздел и настройки должны быть ещё и у /var/log, /home, /dev/shm. Пример параметров в fstab:
/tmp tmpfs tmpfs rw,nosuid,nodev,noexec,inode6
🔹Отслеживайте изменения в системных файлах, например с помощью AIDE (Advanced Intrusion Detection Environment):
# apt install aide aide-common
🔹Убедитесь, что загрузка в single user mode требует аутентификации. Для этого обязательно установите пароль root:
# passwd root
🔹Отключите Apport Error Reporting Service, которая автоматически отправляет информацию о сбоях (по умолчанию включена):
# systemctl stop apport.service
# systemctl --now disable apport.service
# apt purge apport
🔹По возможности включайте, настраивайте AppArmor.
# apt install apparmor
🔹Настройте синхронизацию времени какой-то одной службой (chrony, ntp или systemd-timesyncd).
🔹Проверьте все открытые порты и отключите всё ненужное:
# ss -tulnp
🔹Отключите неиспользуемые сетевые протоколы. Например, ipv6. В документе представлена подробная инструкция, как это сделать. Но при этом сделана пометка, что в общем случае рекомендуется оставить ipv6, но корректно настроить всё, что с ним связано. Другие протоколы, которые в общем случае не нужны, но активны: dccp, sctp, rds, tipc. Только убедитесь, что они реально не используются. Какие-то из них могут быть нужны для работы некоторых кластеров.
🔹Настройте Firewall (UFW). Запретите все соединения, кроме разрешённых явно (нормально закрытый файрвол). Не забудьте про все используемые протоколы, в том числе ipv6.
# apt install ufw
🔹Настройте аудит доступа, изменения, удаления системных файлов с помощью auditctl.
# apt install auditctl audispd-plugins
Убедитесь, что доступ к логам сервиса ограничен.
🔹По возможности настройте отправку системных логов куда-то вовне. Используйте systemd-journal-remote или rsyslog.
🔹Настройте логирование действий через sudo. Добавьте через
visudo
параметр:Defaults logfile="/var/log/sudo.log"
Ограничьте использование
su
.Документ огромный, но на самом деле там не так много информации. Очень много подробностей по аудиту, логам, файрволу. Если вам реально нужно разобраться, как всё это настраивается, то там есть все примеры вплоть до каждой команды и скрипта.
#cis #security #linux
Недавно рассказывал, как я гипервизор случайно перезагрузил и не заметил. Тогда сразу в голове родился мем, но не было повода опубликовать.
У вас бывает небольшой мандраж, когда перезагружаете важный сервер? Особенно если это происходит редко. И особенно, если он железный, стоит где-то на удалённой площадке или в ЦОД, и при старте он очень долго поднимается, потому что там куча проверок железа.
Я обычно запускаю бесконечный пинг и жду 3-4 минуты. Если сервер не начинает отвечать за это время, открываю консоль сервера. Она есть не всегда.
Сейчас призадумался и вспомнил историю, когда сервер не поднялся. Из него вынули штатно одиночный диск, предварительно отмонтировав. Но забыли поправить fstab, он там остался. Проработал где-то пол года так, потом случился reboot. Сервер не поднялся, загрузился в single mode. Пришлось ехать, разбираться. Благо сразу понял в чём дело, как ошибку увидел. Отлегло, когда так быстро починил. Помню, что это был гипервизор XEN. Там под капотом Centos 5 стояла.
#мем
У вас бывает небольшой мандраж, когда перезагружаете важный сервер? Особенно если это происходит редко. И особенно, если он железный, стоит где-то на удалённой площадке или в ЦОД, и при старте он очень долго поднимается, потому что там куча проверок железа.
Я обычно запускаю бесконечный пинг и жду 3-4 минуты. Если сервер не начинает отвечать за это время, открываю консоль сервера. Она есть не всегда.
Сейчас призадумался и вспомнил историю, когда сервер не поднялся. Из него вынули штатно одиночный диск, предварительно отмонтировав. Но забыли поправить fstab, он там остался. Проработал где-то пол года так, потом случился reboot. Сервер не поднялся, загрузился в single mode. Пришлось ехать, разбираться. Благо сразу понял в чём дело, как ошибку увидел. Отлегло, когда так быстро починил. Помню, что это был гипервизор XEN. Там под капотом Centos 5 стояла.
#мем
Хочу продолжить вчерашнюю тему с удалёнными перезагрузками и отрубанием серверов. Немного повспоминал и решил сразу написать, пока не забыл, ещё несколько своих историй по этой теме.
1️⃣ Эту историю я тут описывал и даже статью написал. После обновления сделал штатную перезагрузку виртуалки, а она не поднялась. Немного подождал и пошёл смотреть консоль. Там принудительно началась проверка fsck диска на 3Тб. Длилась она несколько часов. Пришлось понервничать, так как не был уверен, что всё завершится благополучно. С тех пор на больших дисках слежу за этими проверками.
2️⃣ Этот случай был недавно. Достался в наследство сервер с MSSQL, где базы вынесены на отдельный дисковый массив, который представляет из себя внешнюю коробку, подключенную по SCSI разъёму (если не ошибаюсь, точно не помню уже). Проблема в том, что коробочка недорогая. Качество уровня desktop, больше для домашних пользователей. Решили сэкономить. После штатного отключения питания, коробочка не включилась. У неё было своё отдельное питание. Сервер загрузился, базы все лежат. Подключаюсь к серверу, массива нет, соответственно, ничего не работает. Попросил человека на месте проверить, в чём дело. Сказал, что коробка выключена и не включается.
Бэкапы все были, начал разворачивать. Проблема в том, что сервер железный. То есть пришлось поднимать новый сервер уже в VM. Пока это делал, инициативный человек на месте отключил коробку, разобрал, продул, собрал и она заработала. Пока работает, но на подхвате уже готов новый сервер, за бэкапами слежу. Переезд уже запланирован.
3️⃣ С подобной ситуацией сталкивался не раз и уже сильно учёный на этот счёт. Все серваки, подключенные к УПСу должны штатно завершать свою работу, когда заряд кончается. Обычно к этому приходят не сразу, а после того, как в один прекрасный день электричество вырубят не на 5 минут, а на пол дня.
И второй важный момент. Они не должны подниматься автоматически. К этому тоже приходят не сразу, а после того, как хапнут проблем. Я всё это проходил. Вырубается электричество, серваки штатно завершают работу, когда батареи пусты. Потом подаётся электричество, серваки включаются, а через 5 минут электричество опять отключают. И всё моментально аварийно падает в момент загрузки. На этом этапе я лично терял VM. С тех пор автоматически запускаются только гипервизоры. А виртуальные машины я или кто-то ещё включает вручную через некоторое время, когда точно понятно, что отключения прекратились и батареи немного зарядились.
❗️ Это просто совет. Когда меняете сетевые настройки, существенные параметры файрвола, либо что-то по железу (добавляете какое-то хранилище, сетевую карту с загрузкой драйвера), либо в системе то, что потенциально может приводить к проблемам загрузки или внешнего доступа. Не откладывайте перезагрузку, а сделайте её по возможности как можно раньше. Иначе может случиться так, что вы через пол года перезагрузите сервер и начнутся проблемы, которые вызваны этими изменениями, а вы про них забыли. Таких примеров у меня была масса.
Например, подключил хранилище, добавил запись в fstab или с ошибкой, или вообще забыл это сделать. А через несколько месяцев перезагрузил сервер. Включаешь его, а данных нет, служба не работает. Начинаешь в панике разбираться, в чём дело.
Либо настраиваешь firewall, применяешь правила, всё в порядке, доступ на месте. И забываешь включить автозапуск файрвола. Через несколько месяцев перезагружаешься и не замечаешь, что правил нет и у тебя всё в открытом доступе. Потом это долго можно не замечать, если не ставил на мониторинг.
Ещё пример. Меняешь сложный dialplan в asterisk. Перезагрузку откладываешь на потом, чтобы не прерывать текущую работу. И забываешь. А при очередной перезагрузке не можешь понять, почему что-то работает неправильно. Трудно быстро вникнуть и вспомнить, что ты менял несколько месяцев назад.
После существенных изменений лучше сразу же перезагрузиться и убедиться, что всё в порядке и работает так, как вы только что настроили.
#железо
1️⃣ Эту историю я тут описывал и даже статью написал. После обновления сделал штатную перезагрузку виртуалки, а она не поднялась. Немного подождал и пошёл смотреть консоль. Там принудительно началась проверка fsck диска на 3Тб. Длилась она несколько часов. Пришлось понервничать, так как не был уверен, что всё завершится благополучно. С тех пор на больших дисках слежу за этими проверками.
2️⃣ Этот случай был недавно. Достался в наследство сервер с MSSQL, где базы вынесены на отдельный дисковый массив, который представляет из себя внешнюю коробку, подключенную по SCSI разъёму (если не ошибаюсь, точно не помню уже). Проблема в том, что коробочка недорогая. Качество уровня desktop, больше для домашних пользователей. Решили сэкономить. После штатного отключения питания, коробочка не включилась. У неё было своё отдельное питание. Сервер загрузился, базы все лежат. Подключаюсь к серверу, массива нет, соответственно, ничего не работает. Попросил человека на месте проверить, в чём дело. Сказал, что коробка выключена и не включается.
Бэкапы все были, начал разворачивать. Проблема в том, что сервер железный. То есть пришлось поднимать новый сервер уже в VM. Пока это делал, инициативный человек на месте отключил коробку, разобрал, продул, собрал и она заработала. Пока работает, но на подхвате уже готов новый сервер, за бэкапами слежу. Переезд уже запланирован.
3️⃣ С подобной ситуацией сталкивался не раз и уже сильно учёный на этот счёт. Все серваки, подключенные к УПСу должны штатно завершать свою работу, когда заряд кончается. Обычно к этому приходят не сразу, а после того, как в один прекрасный день электричество вырубят не на 5 минут, а на пол дня.
И второй важный момент. Они не должны подниматься автоматически. К этому тоже приходят не сразу, а после того, как хапнут проблем. Я всё это проходил. Вырубается электричество, серваки штатно завершают работу, когда батареи пусты. Потом подаётся электричество, серваки включаются, а через 5 минут электричество опять отключают. И всё моментально аварийно падает в момент загрузки. На этом этапе я лично терял VM. С тех пор автоматически запускаются только гипервизоры. А виртуальные машины я или кто-то ещё включает вручную через некоторое время, когда точно понятно, что отключения прекратились и батареи немного зарядились.
❗️ Это просто совет. Когда меняете сетевые настройки, существенные параметры файрвола, либо что-то по железу (добавляете какое-то хранилище, сетевую карту с загрузкой драйвера), либо в системе то, что потенциально может приводить к проблемам загрузки или внешнего доступа. Не откладывайте перезагрузку, а сделайте её по возможности как можно раньше. Иначе может случиться так, что вы через пол года перезагрузите сервер и начнутся проблемы, которые вызваны этими изменениями, а вы про них забыли. Таких примеров у меня была масса.
Например, подключил хранилище, добавил запись в fstab или с ошибкой, или вообще забыл это сделать. А через несколько месяцев перезагрузил сервер. Включаешь его, а данных нет, служба не работает. Начинаешь в панике разбираться, в чём дело.
Либо настраиваешь firewall, применяешь правила, всё в порядке, доступ на месте. И забываешь включить автозапуск файрвола. Через несколько месяцев перезагружаешься и не замечаешь, что правил нет и у тебя всё в открытом доступе. Потом это долго можно не замечать, если не ставил на мониторинг.
Ещё пример. Меняешь сложный dialplan в asterisk. Перезагрузку откладываешь на потом, чтобы не прерывать текущую работу. И забываешь. А при очередной перезагрузке не можешь понять, почему что-то работает неправильно. Трудно быстро вникнуть и вспомнить, что ты менял несколько месяцев назад.
После существенных изменений лучше сразу же перезагрузиться и убедиться, что всё в порядке и работает так, как вы только что настроили.
#железо
▶️ В декабре 2022 года компания Google выпустила небольшой сериал из 6-ти серий на тему того, как она защищает себя и интернет от хакеров - HACKING GOOGLE Series. Получилось интересно и необычно. На русском языке нашёл только трейлер:
⇨ https://www.youtube.com/watch?v=ubLLES_iDtQ
Остальные серии на английском языке можно посмотреть на официальном канале Google в youtube:
⇨ https://www.youtube.com/playlist?list=PL590L5WQmH8dsxxz7ooJAgmijwOz0lh2H
Если на слух не понимаете английский, то нормально смотрится в Яндекс.Браузере с встроенным синхронным переводом. Любителям подобного рода информации крайне рекомендую. Чего то похожего я даже и не видел.
❗️Сразу предупреждаю, что смотреть это надо как развлекательное видео. Повесточки там везде, что можете заметить уже по трейлеру. Например, авторами вируса WannaCry назначили северокорейцев.
#видео #развлечение
⇨ https://www.youtube.com/watch?v=ubLLES_iDtQ
Остальные серии на английском языке можно посмотреть на официальном канале Google в youtube:
⇨ https://www.youtube.com/playlist?list=PL590L5WQmH8dsxxz7ooJAgmijwOz0lh2H
Если на слух не понимаете английский, то нормально смотрится в Яндекс.Браузере с встроенным синхронным переводом. Любителям подобного рода информации крайне рекомендую. Чего то похожего я даже и не видел.
❗️Сразу предупреждаю, что смотреть это надо как развлекательное видео. Повесточки там везде, что можете заметить уже по трейлеру. Например, авторами вируса WannaCry назначили северокорейцев.
#видео #развлечение
YouTube
ВЗЛОМАТЬ ГУГЛ | Сериал Тизер (RU)
Пять элитных команд безопасности. Шесть нерассказанных историй. Загляните за кулисы вместе с хакерскими командами Google, которые обеспечивают безопасность в Интернете большего числа людей, чем кто-либо другой в мире.
Если вы хотите продолжения - пишите…
Если вы хотите продолжения - пишите…
Свежая информация на тему настройки сервера 1С + PostgreSQL 15 на Debian. Я буквально на днях её выполнял. Моя статья по этой теме на текущий день полностью актуальна:
⇨ Установка и настройка 1С на Debian с PostgreSQL
Уточню только, что если будете настраивать выгрузку баз в dt, используйте сразу автономный сервер, если у вас нет желания и необходимости иметь полноценный клиент на сервере без установки графического окружения. Я этой теме много внимания уделил в статье, но необходимость в этом возникает редко и почти никому не нужно. А времени можно потратить много, так как настройка работы графических приложений через xvfb без установки полноценного рабочего стола нетривиальна и замороченна.
❗️ Важное дополнение, которое возможно сэкономит кому-то время. Сборка PostgreSQL 15 с патчами для 1С от Postgres Professional не поддерживает установку на Debian 12. Нету репозитория для этой системы. Мне хотелось всё развернуть на 12-й версии. Обманул установщик, подключил репы на Debian 12, но всё равно СУБД не установилась. Возникают проблемы с зависимостями.
Для получения этой версии PostgreSQL, необходимо сделать запрос на сайте https://1c.postgres.ru/ и вам придёт инструкция на почту. Кому не хочется этим заниматься, сразу даю ссылку на скрипт подключения репозиториев для всех поддерживаемых систем:
Или вот готовый репозиторий под Debian 11:
Соответственно, если у вас 1С сервера на Debian 11, не торопитесь обновлять систему. А я уже кое-где собирался обновляться. Надо подождать, пока не появятся репозитории Postgres Professional под 12-ю версию.
#1С
⇨ Установка и настройка 1С на Debian с PostgreSQL
Уточню только, что если будете настраивать выгрузку баз в dt, используйте сразу автономный сервер, если у вас нет желания и необходимости иметь полноценный клиент на сервере без установки графического окружения. Я этой теме много внимания уделил в статье, но необходимость в этом возникает редко и почти никому не нужно. А времени можно потратить много, так как настройка работы графических приложений через xvfb без установки полноценного рабочего стола нетривиальна и замороченна.
❗️ Важное дополнение, которое возможно сэкономит кому-то время. Сборка PostgreSQL 15 с патчами для 1С от Postgres Professional не поддерживает установку на Debian 12. Нету репозитория для этой системы. Мне хотелось всё развернуть на 12-й версии. Обманул установщик, подключил репы на Debian 12, но всё равно СУБД не установилась. Возникают проблемы с зависимостями.
Для получения этой версии PostgreSQL, необходимо сделать запрос на сайте https://1c.postgres.ru/ и вам придёт инструкция на почту. Кому не хочется этим заниматься, сразу даю ссылку на скрипт подключения репозиториев для всех поддерживаемых систем:
# wget https://repo.postgrespro.ru/1c-15/keys/pgpro-repo-add.sh
# sh pgpro-repo-add.sh
Или вот готовый репозиторий под Debian 11:
deb http://repo.postgrespro.ru/1c-15/debian bullseye main
Соответственно, если у вас 1С сервера на Debian 11, не торопитесь обновлять систему. А я уже кое-где собирался обновляться. Надо подождать, пока не появятся репозитории Postgres Professional под 12-ю версию.
#1С
Server Admin
Установка 1С на Linux (Debian) + PostgreSQL
Пошаговое руководство по настройке Сервера 1С на Debian + PostgreSQL с примерами эксплуатации: мониторинг, бэкапы и т.д.
В логировании современных систем и программ в основном используют два подхода к распределению логов и событий по важности. Один из них поддерживает 8 уровней важности, или значимости. Не знаю, как правильно перевести severity levels, передав их смысл. Эти уровни пришли из формата логов syslog, появившемся в 80-х годах. Вот эти уровни:
▪ Emergency
▪ Alert
▪ Critical
▪ Error
▪ Warning
▪ Notice
▪ Informational
▪ Debug
Чем ниже идти по приведённому списку, тем больше информации будет в логах. Соответственно, если настраиваете систему логирования, то внимательно смотрите, какой уровень логов будете собирать.
Debug чаще всего не предназначен для долговременного хранения, а включается только во время отладки приложения. Если забудете отключить этот уровень, потом с удивлением обнаружите, что ваши логи разрослись до огромных размеров и работать с ними неудобно. Надо чистить. Постоянно информация уровня Debug обычно не нужна.
Например, такой формат логов поддерживает Nginx или Apache. В них явно можно указать, какого уровня события будут логироваться.
В современной разработке прижилась немного упрощённая и более конкретная схема важности логирования или ошибок:
▪ Fatal
▪ Error
▪ Warn
▪ Info
▪ Debug
▪ Trace
Уровни Trace и Debug нужны чаще всего для разработчиков, которые занимаются отладкой. Иногда они объединены в один уровень Debug. С остальными четырьмя уровнями приходится работать уже сопровождению или поддержке.
Уровень Info это обычно информация о работе сервиса: запуск, остановка, перезагрузка и т.д. Реакция на это не нужна. А вот на уровень Warn и выше уже может потребоваться реакция, хотя и не всегда. К примеру, если у вас почтовый сервер Postfix смотрит в интернет, то все неудачные попытки аутентификации будут уровня Warn. И реагировать на это не обязательно. А вот если у вас система в закрытом контуре и неудачных аутентификаций там быть не должно, то на подобное событие нужна реакция.
Уровни Error и Fatal самые критичные. Очевидно, что на них реакция требуется всегда. В соответствии с уровнями событий, настраиваются разные реакции. К примеру, я события типа Info в Zabbix собираю, но никаких реакций и оповещений на них не делаю. С дашбордов обычно тоже их убираю, либо делаю отдельные информационные панели. Например, со списком действий пользователей VPN, подключения и отключения. Реакция на это не нужна, но иногда бывает нужно быстро посмотреть, кто сейчас подключен. Отлично подойдёт виджет с такой информацией.
Так что рекомендую осмысленно подходить к классификации событий. Это помогает и упрощает настройку систем мониторинга и оповещений.
#linux #logs
▪ Emergency
▪ Alert
▪ Critical
▪ Error
▪ Warning
▪ Notice
▪ Informational
▪ Debug
Чем ниже идти по приведённому списку, тем больше информации будет в логах. Соответственно, если настраиваете систему логирования, то внимательно смотрите, какой уровень логов будете собирать.
Debug чаще всего не предназначен для долговременного хранения, а включается только во время отладки приложения. Если забудете отключить этот уровень, потом с удивлением обнаружите, что ваши логи разрослись до огромных размеров и работать с ними неудобно. Надо чистить. Постоянно информация уровня Debug обычно не нужна.
Например, такой формат логов поддерживает Nginx или Apache. В них явно можно указать, какого уровня события будут логироваться.
В современной разработке прижилась немного упрощённая и более конкретная схема важности логирования или ошибок:
▪ Fatal
▪ Error
▪ Warn
▪ Info
▪ Debug
▪ Trace
Уровни Trace и Debug нужны чаще всего для разработчиков, которые занимаются отладкой. Иногда они объединены в один уровень Debug. С остальными четырьмя уровнями приходится работать уже сопровождению или поддержке.
Уровень Info это обычно информация о работе сервиса: запуск, остановка, перезагрузка и т.д. Реакция на это не нужна. А вот на уровень Warn и выше уже может потребоваться реакция, хотя и не всегда. К примеру, если у вас почтовый сервер Postfix смотрит в интернет, то все неудачные попытки аутентификации будут уровня Warn. И реагировать на это не обязательно. А вот если у вас система в закрытом контуре и неудачных аутентификаций там быть не должно, то на подобное событие нужна реакция.
Уровни Error и Fatal самые критичные. Очевидно, что на них реакция требуется всегда. В соответствии с уровнями событий, настраиваются разные реакции. К примеру, я события типа Info в Zabbix собираю, но никаких реакций и оповещений на них не делаю. С дашбордов обычно тоже их убираю, либо делаю отдельные информационные панели. Например, со списком действий пользователей VPN, подключения и отключения. Реакция на это не нужна, но иногда бывает нужно быстро посмотреть, кто сейчас подключен. Отлично подойдёт виджет с такой информацией.
Так что рекомендую осмысленно подходить к классификации событий. Это помогает и упрощает настройку систем мониторинга и оповещений.
#linux #logs
Очень простой и быстрый способ настроить уведомления об успешном SSH подключении к серверу в Telegram. Для этого понадобится свой bot, простенький bash скрипт и изменение конфига PAM для SSH. Будем через него уведомления делать.
Рассказывать про создание бота не буду. Надо создать нового бота, получить его токен. Также понадобится ваш ID. Узнать можно разными способами, например через бота @my_id_bot.
Далее берём простой скрипт:
Тут мы проверяем переменную PAM_TYPE. Если это что-то отличное от закрытия сессии, то нам подходит. Проверить работу скрипта можно примерно так:
От бота вам должно прийти уведомление в указанном выше формате. Только имени пользователя не будет, потому что переменную PAM_USER не задали.
Копируем этот скрипт в директорию /etc/ssh/ и выставляем минимальные права:
Далее открываем конфиг
На этом всё. Теперь при успешном SSH подключении вы будете получать уведомление в Telegram.
По аналогии с этим скриптом, вы можете сделать уведомления и на другие события. Например, на закрытие сессии, или на неудачную аутентификацию.
Единственное, что мне хотелось бы сделать, но не получилось - вывести в уведомление IP адрес подключившегося пользователя. Я не нашёл в переменных PAM этой информации. А парсить лог ssh подключений не захотелось. Это делает решение неуниверсальным. В представленном виде сообщения будут такие:
2023-08-07, Monday 15:10
SSH Login: root@debian11
Подробная дата (date +"%Y-%m-%d, %A %R"), имя пользователя ($PAM_USER) и имя сервера (hostname). Можете добавить какую-то ещё информацию по своему усмотрению. Если кто-то знает переменную PAM с информацией об адресе подключившегося, подскажите. Я не нашёл такой информации.
#linux #bash #ssh #security
Рассказывать про создание бота не буду. Надо создать нового бота, получить его токен. Также понадобится ваш ID. Узнать можно разными способами, например через бота @my_id_bot.
Далее берём простой скрипт:
#!/bin/bash
if [ "$PAM_TYPE" != "close_session" ]; then
ID=1307682341
BOT_TOKEN=6327355747:AAEDcFIlhKSIOKS-t2I9ARTdT1usbq2a9W4
message="$(date +"%Y-%m-%d, %A %R")"$'\n'"SSH Login: $PAM_USER@$(hostname)"
curl -s --data "text=$message" --data "chat_id=$ID" 'https://api.telegram.org/bot'$BOT_TOKEN'/sendMessage' > /dev/null
fi
Тут мы проверяем переменную PAM_TYPE. Если это что-то отличное от закрытия сессии, то нам подходит. Проверить работу скрипта можно примерно так:
# PAM_TYPE=open_session ./ssh-success.sh
От бота вам должно прийти уведомление в указанном выше формате. Только имени пользователя не будет, потому что переменную PAM_USER не задали.
Копируем этот скрипт в директорию /etc/ssh/ и выставляем минимальные права:
# chown root /etc/ssh/ssh-success.sh
# chmod 100 /etc/ssh/ssh-success.sh
Далее открываем конфиг
/etc/pam.d/sshd
и добавляем туда:# Send a login notification to Telegram via ssh-success.sh
session optional pam_exec.so seteuid /etc/ssh/ssh-success.sh
На этом всё. Теперь при успешном SSH подключении вы будете получать уведомление в Telegram.
По аналогии с этим скриптом, вы можете сделать уведомления и на другие события. Например, на закрытие сессии, или на неудачную аутентификацию.
Единственное, что мне хотелось бы сделать, но не получилось - вывести в уведомление IP адрес подключившегося пользователя. Я не нашёл в переменных PAM этой информации. А парсить лог ssh подключений не захотелось. Это делает решение неуниверсальным. В представленном виде сообщения будут такие:
2023-08-07, Monday 15:10
SSH Login: root@debian11
Подробная дата (date +"%Y-%m-%d, %A %R"), имя пользователя ($PAM_USER) и имя сервера (hostname). Можете добавить какую-то ещё информацию по своему усмотрению. Если кто-то знает переменную PAM с информацией об адресе подключившегося, подскажите. Я не нашёл такой информации.
#linux #bash #ssh #security