Ранее я упоминал про утилиту Lynis, а также то, как я её использую в связке с Zabbix для предупреждения о каких-то проблемах на хостах. С момента написания статьи я немного поменял подход к сбору данных. Расскажу кратко, как это у меня сейчас работает. Я с тех пор постоянно использую эту связку. Мне нравится, как она работает.
Кратко поясню суть того, что делаю и для чего. Утилита Lynis есть в стандартных репах. Она делает некоторый набор проверок системы и пишет отчёт в лог. Конкретно меня от неё интересуют две вещи:
◽️Вывод предупреждений. Например, о том, что систему надо перезагрузить после обновления ядра, либо о том, что есть уязвимые пакеты.
◽️Список пакетов с уязвимостями, для которых доступны обновления.
С помощью Zabbix я анализирую лог Lynis и прямо на почту отправляю текст замечаний и уязвимых пакетов, если они есть. Реализую это следующим образом:
1️⃣ Делаю простой скрипт, который запускает Lynis и анализирует код завершения работы. У этой программы он ненулевой, если есть какие-то замечания. Завожу эти замечания в переменную и отправляю данные с помощью zabbix_sender на Zabbix Server. Если код выхода 0, то отправляю строку All is OK.
Сам скрипт очень простой:
Ставлю скрипт в cron или timers на выполнение раз в 2-3 часа. Чаще большого смысла нет.
2️⃣ В Zabbix Server делаю простой шаблон с одним элементом данных типа Zabbix траппер. Его настройки есть на скриншоте снизу. К айтему делаю два триггера. Один на поиск строки All is OK. Если в последнем полученном значении её нет, то срабатывает триггер. И второй - проверка, что данные приходят. Если в течении дня ничего не приходило, то он срабатывает. Настройки триггера тоже ниже.
3️⃣ В итоге если Lynis что-то находит, отправляет информацию в Zabbix Server. Срабатывает триггер, в описании которого будет текст из айтема со всеми замечаниями и списками уязвимых пакетов, которые надо обновить. Пример письма с информацией тоже есть ниже на картинке.
Всё это настраивается относительно просто. Не нужны никакие отдельные системы и сторонние пакеты. Всё ставится из базовых репозиториев, а система мониторинга скорее всего уже есть. Мне для базовых проверок такой информации достаточно.
Сам шаблон не прикрепляю, так как там всего один айтем и два триггера, содержимое которых и так есть на скринах. Воспроизвести нетрудно. Работать будет на любых версиях Zabbix сервера. Если не устанавливали на хосты zabbix_sender, то поставьте его. Он идёт в отдельном пакете:
Такая вот простая и функциональная система с предупреждениями об обновлениях и некоторых других вещах. Lynis делает много проверок, можно почитать о нём отдельно. В рамках этой заметки не стал на этом делать акцент.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #security
Кратко поясню суть того, что делаю и для чего. Утилита Lynis есть в стандартных репах. Она делает некоторый набор проверок системы и пишет отчёт в лог. Конкретно меня от неё интересуют две вещи:
◽️Вывод предупреждений. Например, о том, что систему надо перезагрузить после обновления ядра, либо о том, что есть уязвимые пакеты.
◽️Список пакетов с уязвимостями, для которых доступны обновления.
С помощью Zabbix я анализирую лог Lynis и прямо на почту отправляю текст замечаний и уязвимых пакетов, если они есть. Реализую это следующим образом:
Сам скрипт очень простой:
#!/bin/bash/usr/sbin/lynis audit system -qexitcode=$?result="0"if [ $exitcode != 0 ]; then result=$(/usr/bin/grep "Warning:\|Found vulnerable package" /var/log/lynis.log)else result="All is OK"fizabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k "lynis.check" -o "$result"Ставлю скрипт в cron или timers на выполнение раз в 2-3 часа. Чаще большого смысла нет.
Всё это настраивается относительно просто. Не нужны никакие отдельные системы и сторонние пакеты. Всё ставится из базовых репозиториев, а система мониторинга скорее всего уже есть. Мне для базовых проверок такой информации достаточно.
Сам шаблон не прикрепляю, так как там всего один айтем и два триггера, содержимое которых и так есть на скринах. Воспроизвести нетрудно. Работать будет на любых версиях Zabbix сервера. Если не устанавливали на хосты zabbix_sender, то поставьте его. Он идёт в отдельном пакете:
# apt install zabbix-senderТакая вот простая и функциональная система с предупреждениями об обновлениях и некоторых других вещах. Lynis делает много проверок, можно почитать о нём отдельно. В рамках этой заметки не стал на этом делать акцент.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍120👎3
Дискуссионная пятничная тема. Недавно общался с человеком, который просил помощи с Windows Server и Hyper-V. И приводил свои ошибки из логов на русском языке. Те, кто много работал с Windows серверами, наверное уже поняли, о чём пойдёт речь.
Если искать в поиске в интернете ошибки на русском языке, то что-то дельное найти будет проблематично. Их придётся переводить на английский язык и пытаться найти на английском. Чтобы избежать этой проблемы и упростить себе жизнь в обслуживании и диагностике – ставьте везде, где это допустимо, английские версии продуктов. Частично этот вопрос закрывают ИИ, но всё равно не полностью.
Не так давно столкнулся с тем, что если в консоли Linux стоит русская локаль, то Mariadb начинает в лог писать ошибки на русском языке. По ним ничего дельного потом не найти. Это очень неудобно. То же самое с PostgreSQL. Если СУБД стоит на одном сервере с сервером 1С, который требует русскую локаль, то тоже все логи PostgreSQL будут на русском языке. Хотя конкретно в PostgreSQL перевод очень качественный, но так бывает не везде.
Язык современной техносферы – английский и с этим приходится считаться. Если у вас возникает какая-то ошибка, то в англоязычном интернете, пока он ещё доступен, вы найдете в разы больше материала по ней.
Русский язык обычно нужен пользователям, которые работают с системой. Некоторые начинающие инженеры тоже ставят русский язык в надежде, что это упростит им настройку и эксплуатацию. Но на деле он только осложнит, если начнутся какие-то проблемы и ошибки. Так что рекомендую везде использовать английский.
#разное
Если искать в поиске в интернете ошибки на русском языке, то что-то дельное найти будет проблематично. Их придётся переводить на английский язык и пытаться найти на английском. Чтобы избежать этой проблемы и упростить себе жизнь в обслуживании и диагностике – ставьте везде, где это допустимо, английские версии продуктов. Частично этот вопрос закрывают ИИ, но всё равно не полностью.
Не так давно столкнулся с тем, что если в консоли Linux стоит русская локаль, то Mariadb начинает в лог писать ошибки на русском языке. По ним ничего дельного потом не найти. Это очень неудобно. То же самое с PostgreSQL. Если СУБД стоит на одном сервере с сервером 1С, который требует русскую локаль, то тоже все логи PostgreSQL будут на русском языке. Хотя конкретно в PostgreSQL перевод очень качественный, но так бывает не везде.
Язык современной техносферы – английский и с этим приходится считаться. Если у вас возникает какая-то ошибка, то в англоязычном интернете, пока он ещё доступен, вы найдете в разы больше материала по ней.
Русский язык обычно нужен пользователям, которые работают с системой. Некоторые начинающие инженеры тоже ставят русский язык в надежде, что это упростит им настройку и эксплуатацию. Но на деле он только осложнит, если начнутся какие-то проблемы и ошибки. Так что рекомендую везде использовать английский.
#разное
5👍205👎17
This media is not supported in your browser
VIEW IN TELEGRAM
Часто слушал эту прикольную песенку НТР. Такой подход к делу и материшну в целом не одобряю, но песня забавная. И при этом особо не обращал внимание на вступление.
Плиз коммит ченджес иммидиатли, асап.
Тут вроде понятно, о чём идёт речь, хотя что такое асап тоже не знал. А дальше думал, идёт какой-то набор слов просто для красного словца.
Сума сандаран cамалан бабан.
И только недавно я понял, что тут речь идёт об имени и фамилии какого-то индусаСумасандаран Самаланбабан . Увидел где-то обсуждение индусских имён и вспомнил, что в песне был не набор бессмысленных слов, а индусское имя 😀
То есть полностью вступление звучит так:
Please, commit changes immediately asap (As Soon As Possible),
Sumasandaran Samalanbaban.
Что означает в вольном переводе: "Пожалуйста, внесите исправления немедленно, Сумасандаран Самаланбабан."
#юмор #музыка
Плиз коммит ченджес иммидиатли, асап.
Тут вроде понятно, о чём идёт речь, хотя что такое асап тоже не знал. А дальше думал, идёт какой-то набор слов просто для красного словца.
Сума сандаран cамалан бабан.
И только недавно я понял, что тут речь идёт об имени и фамилии какого-то индуса
То есть полностью вступление звучит так:
Please, commit changes immediately asap (As Soon As Possible),
Sumasandaran Samalanbaban.
Что означает в вольном переводе: "Пожалуйста, внесите исправления немедленно, Сумасандаран Самаланбабан."
#юмор #музыка
👍90👎7
Небольшая зарисовка-совет из моего недавнего опыта по настройке шаблона в Zabbix Server. В настройках айтема можно использовать предобработку, которая называется Отбрасывать не изменившееся. По названию уже понятно, что она делает – не записывает новое значение, если оно не отличается от прошлого. Я везде, где можно, использую эту предобработку, потому что она существенно экономит место в базе данных, особенно если речь идёт про какие-то длинные строки в логах или другие редко изменяемые данные.
В то же время в функциях триггеров есть функция nodata, которая проверяет время последнего поступления данных. И если данные не поступали дольше заданного периода, она активирует триггер. Эта функция проверяет поступление данных на основе последней записи айтема в базе, а не самого факта поступления данных от агента. И если предобработка отбрасывает не изменившееся значение, функция nodata считает, что его не было.
Выглядит это как баг, но на деле просто особенность работы указанной пары функциональности, которую нужно знать. У предобработки есть расширенная версия – Отбрасывать не изменившееся с периодическим контролем, а у функции есть в качестве одного из параметров интервал в прошлое, на котором мы проверяем наличие новых значений.
Эта два значения надо правильно подобрать, чтобы проверка работала корректно. У предобработки время периодического контроля, когда значение в любом случае будет записано, даже если не изменилось, должно быть меньше, чем интервал в прошлое у функции nodata. Тогда всё это будет корректно работать.
Я какое-то время потратил на то, чтобы разобраться, почему один из триггеров работает некорректно. Забыл про указанную предобработку и долго не мог понять, что не так. Данные корректно уходят на сервер, в отладке это видно, но в базу данных не попадают. Думал со связью проблемы. Потом уже принудительно начал в айтем записывать разные данные, убедился, что они приходят и записываются в базу. И только после этого понял, что стоит предобработка, которая отбрасывает неизменившиеся значения.
Если не знаете и не используете описанную функциональность в мониторинге, советую обратить внимание. Предобработка существенно экономит место в базе, а функция nodata страхует вас от ситуации, когда новые данные просто не приходят, а вы думаете, что у вас всё в порядке, потому что на основе старых данных триггер не видит проблем. А на деле, к примеру, бэкапы просто не выполняются.
#zabbix
В то же время в функциях триггеров есть функция nodata, которая проверяет время последнего поступления данных. И если данные не поступали дольше заданного периода, она активирует триггер. Эта функция проверяет поступление данных на основе последней записи айтема в базе, а не самого факта поступления данных от агента. И если предобработка отбрасывает не изменившееся значение, функция nodata считает, что его не было.
Выглядит это как баг, но на деле просто особенность работы указанной пары функциональности, которую нужно знать. У предобработки есть расширенная версия – Отбрасывать не изменившееся с периодическим контролем, а у функции есть в качестве одного из параметров интервал в прошлое, на котором мы проверяем наличие новых значений.
Эта два значения надо правильно подобрать, чтобы проверка работала корректно. У предобработки время периодического контроля, когда значение в любом случае будет записано, даже если не изменилось, должно быть меньше, чем интервал в прошлое у функции nodata. Тогда всё это будет корректно работать.
Я какое-то время потратил на то, чтобы разобраться, почему один из триггеров работает некорректно. Забыл про указанную предобработку и долго не мог понять, что не так. Данные корректно уходят на сервер, в отладке это видно, но в базу данных не попадают. Думал со связью проблемы. Потом уже принудительно начал в айтем записывать разные данные, убедился, что они приходят и записываются в базу. И только после этого понял, что стоит предобработка, которая отбрасывает неизменившиеся значения.
Если не знаете и не используете описанную функциональность в мониторинге, советую обратить внимание. Предобработка существенно экономит место в базе, а функция nodata страхует вас от ситуации, когда новые данные просто не приходят, а вы думаете, что у вас всё в порядке, потому что на основе старых данных триггер не видит проблем. А на деле, к примеру, бэкапы просто не выполняются.
#zabbix
1👍89👎3
Какое-то дёрганное лето получается. Новые проблемы сыпятся, как из рога изобилия. Жара что ли на сервера так влияет? Расскажу историю очередной проблемы, с которой столкнулся. Там есть несколько поучительных моментов.
На одном проекте ночью упал Redis, сайт начал 500-ю ошибку отдавать. Нечасто такое случается. Редис если и упадёт, то обычно быстро поднимается, потому что используют его в основном под кэш в оперативной памяти, данные можно не сохранять.
Redis словил ошибку Segmentation fault. Эта такая мутная тема, потому что нельзя однозначно сказать, из-за чего она возникает. Это могут быть как проблемы с железом, так и с самим софтом. Либо банально оперативной памяти на сервере не хватило.
У меня скорее всего последний вариант, так как в момент падения сервер реально сильно нагрузили, причём разносторонней нагрузкой. Рядом работающая СУБД в этот же момент скинула на диск свой пул и буферный кэш. Это осталось в её логе. Они это делают, чтобы освободить оперативную память, если её не хватает.
В настройках systemd юнита Redis указан параметр
Redis всю ночь поднимался и падал, постоянно записывая что-то на диск. Это видно по мониторингу. Забил весь ресурс дисков своей записью. Он писал свои трейсы в лог, но помимо них ещё какую-то информацию. Судя по всему своё состояние пытался скинуть, но не получалось. Я трейсы бегло посмотрел, но особо не вникал, так как там без должного понимания ничего особо не увидишь.
В общем случае с параметром
Но как я уже сказал, у меня что-то пошло не так. В данном случае было бы лучше, если бы он тихо помер и не мучал больше сервер. Помогло в итоге то, что я туром проснулся, вручную остановил его и запустил заново:
Так что сильно рассчитывать на systemd в таких вопросах не стоит. Очень желательно настраивать для критичных сервисов внешний мониторинг службы, чтобы она отвечала по настроенному TCP порту или Unix сокету. Отдавала какие-то данные или своё состояние передавала. И если не отвечает, то каким-то образом гарантированно перезапускать её, в зависимости от того, где она запущена, как служба на сервере или в отдельном контейнере.
Если бы это была СУБД, типа MySQL или Postgres, которая всю ночь пыталась подняться и падала, то даже не знаю, что бы стало с данными. Для этих баз данных такое поведение может быть фатальным, особенно если они упали из-за проблем с диском, а при старте запускали восстановление данных. Постоянные перезапуски их добьют. Так что аккуратнее с параметром
Я в итоге снизил потребление памяти у некоторых служб, чтобы избежать ситуаций, когда память вся закончится. Буду наблюдать. Надеюсь, что проблема не повторится.
#linux #systemd #ошибка
На одном проекте ночью упал Redis, сайт начал 500-ю ошибку отдавать. Нечасто такое случается. Редис если и упадёт, то обычно быстро поднимается, потому что используют его в основном под кэш в оперативной памяти, данные можно не сохранять.
Redis словил ошибку Segmentation fault. Эта такая мутная тема, потому что нельзя однозначно сказать, из-за чего она возникает. Это могут быть как проблемы с железом, так и с самим софтом. Либо банально оперативной памяти на сервере не хватило.
У меня скорее всего последний вариант, так как в момент падения сервер реально сильно нагрузили, причём разносторонней нагрузкой. Рядом работающая СУБД в этот же момент скинула на диск свой пул и буферный кэш. Это осталось в её логе. Они это делают, чтобы освободить оперативную память, если её не хватает.
В настройках systemd юнита Redis указан параметр
Restart=always. Подробно на эту тему я делал отдельную заметку. Рекомендую ознакомиться, если не знаете. Данный параметр означает, что при любой причине завершения работы службы будет попытка поднять её. Я упоминал в той заметке, что не всегда это бывает полезно. И это как раз мой случай.Redis всю ночь поднимался и падал, постоянно записывая что-то на диск. Это видно по мониторингу. Забил весь ресурс дисков своей записью. Он писал свои трейсы в лог, но помимо них ещё какую-то информацию. Судя по всему своё состояние пытался скинуть, но не получалось. Я трейсы бегло посмотрел, но особо не вникал, так как там без должного понимания ничего особо не увидишь.
В общем случае с параметром
Restart=always служба должна подняться автоматически. Я потестировал немного на отдельной виртуалке. Если Редису дать команду SIGSEGV, то он так же, как у меня вышло, скидывает свой трейс в лог, завершает работу и запускается заново. Проверить можно так:# kill -SIGSEGV $(pidof redis-server)Но как я уже сказал, у меня что-то пошло не так. В данном случае было бы лучше, если бы он тихо помер и не мучал больше сервер. Помогло в итоге то, что я туром проснулся, вручную остановил его и запустил заново:
# systemctl stop redis-server# systemctl start redis-serverТак что сильно рассчитывать на systemd в таких вопросах не стоит. Очень желательно настраивать для критичных сервисов внешний мониторинг службы, чтобы она отвечала по настроенному TCP порту или Unix сокету. Отдавала какие-то данные или своё состояние передавала. И если не отвечает, то каким-то образом гарантированно перезапускать её, в зависимости от того, где она запущена, как служба на сервере или в отдельном контейнере.
Если бы это была СУБД, типа MySQL или Postgres, которая всю ночь пыталась подняться и падала, то даже не знаю, что бы стало с данными. Для этих баз данных такое поведение может быть фатальным, особенно если они упали из-за проблем с диском, а при старте запускали восстановление данных. Постоянные перезапуски их добьют. Так что аккуратнее с параметром
Restart.Я в итоге снизил потребление памяти у некоторых служб, чтобы избежать ситуаций, когда память вся закончится. Буду наблюдать. Надеюсь, что проблема не повторится.
#linux #systemd #ошибка
👍98👎3
Вопрос управлением памятью в Linux непростой. У меня уже были в разное время заметки по этой теме. Причём он не только технический, но и организационный. Как раскидать сервисы по виртуалкам и контейнерам? Всегда придётся искать баланс, потому что максимально всё подробить не обязательно будет удобно и эффективно. Но при любом раскладе нужно будет настраивать сами приложения. Покажу на нескольких примерах, как это выглядит на практике у меня.
1️⃣ Начну с MySQL. В качестве калькулятора при подборе настроек я использую MySQLTuner. Он много всего может проверить и посоветовать, но без глубокого понимания работы СУБД, лучше лишний раз не трогать настройки.
Мне главное понять, сколько памяти съест СУБД, если её максимально нагрузить при текущих параметрах. Это MySQLTuner как раз наглядно покажет. Подробно все настройки, на которые стоит обратить внимание в этом контексте, я разбирал в отдельной заметке. Не буду повторяться. Надо настроить так, чтобы MySQL не запросила памяти больше, чем есть на сервере, либо можно позволить выделить с учётом других сервисов, если они там есть. Параметры подбираются по ситуации.
Для PostgreSQL есть много конфигураторов, которые по заявленным характеристикам сервера сами посоветуют параметры, в том числе относящиеся к потреблению памяти. Мне больше всего нравится pgconfigurator.cybertec.at (хостится за CF, нужен VPN).
Есть софт попроще в плане настроек потребления памяти. Например, в Elasticsearch, Redis, Memcached можно одним параметром ограничить память, которую приложение будет использовать.
2️⃣ Дальше у нас идут приложения, которые в зависимости от нагрузки запускают разное количество экземпляров. Наглядным примером тут выступает php-fpm. Его нужно ограничить по количеству процессов, которые он может запустить в пределах отведённой ему памяти. Для этого надо понять, а сколько памяти в текущих условиях занимает один процесс?
Вопрос этот нетривиальный, так как у нас есть общая память, виртуальная память, реальная память. Форки одного процесса частично используют общую память и поэтому в лоб посмотреть в top или htop, сколько один процесс использует реальной памяти, не получится. Хотя для грубого подсчёта может и сойти. Более точно это можно определить с помощью
3️⃣ Отдельно идут приложения, которые не имеют своих настроек потребления памяти. Плюс, они не форкаются под выросшей нагрузкой. Наглядные примеры таких приложений - Nginx, Postfix, Dovecot. Сюда же можно отнести какие-то самописные скрипты, или тот же Fail2Ban. Последнего надо обязательно ограничивать, так как он легко может повесить сервер под нагрузкой.
Если мы хотим для таких приложений настроить ограничения, то можем воспользоваться настройками systemd. Их там несколько, можно очень гибко всё настроить. При определённом лимите можно ограничивать выделение памяти, а если не поможет, то перезапустить сервис или прибить. Тоже подробно это описывал ранее.
☝️ Может показаться, что контейнеры как раз и придумали в том числе для того, чтобы изолировать приложения друг от друга и ограничивать в ресурсах, и не тратить время на тонкую настройку. Частично да, в том числе для этого и придумали. Третий тип приложений отлично ограничивается на уровне выделенных ресурсов, но первые два, особенно СУБД, всё равно для стабильной работы нужно предварительно настроить под выделенные ресурсы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#perfomance
Мне главное понять, сколько памяти съест СУБД, если её максимально нагрузить при текущих параметрах. Это MySQLTuner как раз наглядно покажет. Подробно все настройки, на которые стоит обратить внимание в этом контексте, я разбирал в отдельной заметке. Не буду повторяться. Надо настроить так, чтобы MySQL не запросила памяти больше, чем есть на сервере, либо можно позволить выделить с учётом других сервисов, если они там есть. Параметры подбираются по ситуации.
Для PostgreSQL есть много конфигураторов, которые по заявленным характеристикам сервера сами посоветуют параметры, в том числе относящиеся к потреблению памяти. Мне больше всего нравится pgconfigurator.cybertec.at (хостится за CF, нужен VPN).
Есть софт попроще в плане настроек потребления памяти. Например, в Elasticsearch, Redis, Memcached можно одним параметром ограничить память, которую приложение будет использовать.
Вопрос этот нетривиальный, так как у нас есть общая память, виртуальная память, реальная память. Форки одного процесса частично используют общую память и поэтому в лоб посмотреть в top или htop, сколько один процесс использует реальной памяти, не получится. Хотя для грубого подсчёта может и сойти. Более точно это можно определить с помощью
pmap. У меня была подробная заметка, где я на конкретном примере показал, как это сделать. Это руководство подойдёт для всех подобных приложений.Если мы хотим для таких приложений настроить ограничения, то можем воспользоваться настройками systemd. Их там несколько, можно очень гибко всё настроить. При определённом лимите можно ограничивать выделение памяти, а если не поможет, то перезапустить сервис или прибить. Тоже подробно это описывал ранее.
☝️ Может показаться, что контейнеры как раз и придумали в том числе для того, чтобы изолировать приложения друг от друга и ограничивать в ресурсах, и не тратить время на тонкую настройку. Частично да, в том числе для этого и придумали. Третий тип приложений отлично ограничивается на уровне выделенных ресурсов, но первые два, особенно СУБД, всё равно для стабильной работы нужно предварительно настроить под выделенные ресурсы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#perfomance
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍88👎2
На днях почувствовал себя пользователем vi или vim, который не знает, как из него выйти. Установил на винду консольный редактор MSEdit:
Подсказали в прошлой заметке про sudo в Windows. Честно говоря вообще впервые про него услышал. Это что-то из далёкого прошлого. Редактор из системы MS-DOS. Я её не застал. Сознательный возраст встретил с Windows 95.
Запускается в командной строке:
Зашёл, а выйти не могу. Понятно, что в Windows всё намного проще. Можно просто окно закрыть. Тем не менее, стал перебирать различные комбинации. Ничего из привычного не подошло. Я не понял ни как выйти, ни как открыть верхнее меню. Комбинации клавиш не совпадают с теми, к которым привык в Linux.
В верхнее меню можно попасть через Alt и любую из указанных клавиш. А можно просто мышкой туда тыкнуть. Как оказалась, в этот консольный редактор добавили поддержку мышки.
Для винды выглядит максимально непривычно. Не знаю, будет ли это кому-то удобно. Мне кажется, оживили проект больше по приколу, нежели для развития какой-то функциональности, в отличии от sudo. Я пользоваться точно не буду, потому что горячие клавиши непривычны. Автоматом жму Ctrl + X или F10, чтобы выйти. А первая комбинация в edit вырезает строку.
#windows
> winget install Microsoft.EditПодсказали в прошлой заметке про sudo в Windows. Честно говоря вообще впервые про него услышал. Это что-то из далёкого прошлого. Редактор из системы MS-DOS. Я её не застал. Сознательный возраст встретил с Windows 95.
Запускается в командной строке:
> edit readme.txtЗашёл, а выйти не могу. Понятно, что в Windows всё намного проще. Можно просто окно закрыть. Тем не менее, стал перебирать различные комбинации. Ничего из привычного не подошло. Я не понял ни как выйти, ни как открыть верхнее меню. Комбинации клавиш не совпадают с теми, к которым привык в Linux.
В верхнее меню можно попасть через Alt и любую из указанных клавиш. А можно просто мышкой туда тыкнуть. Как оказалась, в этот консольный редактор добавили поддержку мышки.
Для винды выглядит максимально непривычно. Не знаю, будет ли это кому-то удобно. Мне кажется, оживили проект больше по приколу, нежели для развития какой-то функциональности, в отличии от sudo. Я пользоваться точно не буду, потому что горячие клавиши непривычны. Автоматом жму Ctrl + X или F10, чтобы выйти. А первая комбинация в edit вырезает строку.
#windows
👍43👎6
📊 2 недели назад проводил опрос на тему использования операционных систем на рабочих машинах и серверах. Было интересно сравнить с такими же опросами в прошлом году.
На удивление, за год существенных изменений нет. Результаты очень близкие с учётом погрешности. Единственный момент – я ошибся в TG с опросом ОС на серверах. В прошлом году разрешил выбрать несколько вариантов, а в этом только один. Из-за этого в лоб сравнить 2 года не получится, но по общей картине видно, что изменений там особо нет.
Ожидал, что доля Linux на рабочих машинах подрастёт, а MacOS снизится, но этого не произошло. Также думал, что заметно снизится доля Windows серверов. В результатах TG это заметно, но очень незначительно, что на такой выборке выглядит как погрешность. А в VK вообще без изменений.
Среди российских дистрибутивов неожиданно было увидеть высокую долю Red OS, очень близкую к Alt. Честно говоря, думал, что в лидерах будет именно он, а не Astra. На деле Астра – безоговорочный лидер.
Свёл результаты обоих лет на картинках снизу с разбивкой на Telegram и VK.
#опрос
На удивление, за год существенных изменений нет. Результаты очень близкие с учётом погрешности. Единственный момент – я ошибся в TG с опросом ОС на серверах. В прошлом году разрешил выбрать несколько вариантов, а в этом только один. Из-за этого в лоб сравнить 2 года не получится, но по общей картине видно, что изменений там особо нет.
Ожидал, что доля Linux на рабочих машинах подрастёт, а MacOS снизится, но этого не произошло. Также думал, что заметно снизится доля Windows серверов. В результатах TG это заметно, но очень незначительно, что на такой выборке выглядит как погрешность. А в VK вообще без изменений.
Среди российских дистрибутивов неожиданно было увидеть высокую долю Red OS, очень близкую к Alt. Честно говоря, думал, что в лидерах будет именно он, а не Astra. На деле Астра – безоговорочный лидер.
Свёл результаты обоих лет на картинках снизу с разбивкой на Telegram и VK.
#опрос
👍79👎5
Казалось бы, ну кто не знает в наше время, что нужно делать и проверять бэкапы? Куча инструментов есть, в том числе бесплатных. Но это всё слабо помогает. Через меня проходит много всевозможных историй, поэтому решил в очередной раз рассказать о них и напомнить про бэкапы.
1️⃣ Читал статью на хабре, как разработчик случайным запросом очистил базу пользователей и похоронил коммерческий проект, так как бэкап был месячной давности.
2️⃣ Мне в личные сообщения написал человек и попросил помочь. У него умер рейд массив на контроллере домена. Он бэкапился встроенным резервным копированием винды. При восстановлении оказалось, что ничего не восстанавливается, система пишет, что не видит бэкапа в указанном месте.
В обоих случаях бэкапы вроде бы и делались, но не проверялись. По факту оказалось, что их нет.
3️⃣ Эта история более насыщенная, так как я в ней лично поучаствовал. Обратился старый заказчик, которому я несколько лет назад настраивал инфраструктуру. Но не поддерживал её. Если кому-то что-то настраиваю, то сразу предупреждаю, что поддерживать не буду. У меня нет такой возможности. Всё аккуратно передаю и объясняю, чтобы дальше без моего участия можно было вести дела.
Но тут сделал исключение. Был поздний вечер, уже собирался спать, всё выключил. Ну и как обычно проверил Telegram. А там умер виндовый сервер с кучей баз 1С. Утром придут люди и «прибьют меня».
Базы были как файловые, так и в MSSQL. Бэкапы файловых баз были, скульных – свежих нет. Но бэкап это пол дела. Системы то самой нет. Надо всё с нуля поднимать и настраивать, восстанавливать лицензии, делать публикации. На дворе ночь, подменного сервера нет.
Сервер вёл себя странно. Он нормально загружался до своей заставки с часами. А дальше ни на что не реагировал. Если раз 10 нажать CTRL+ALT+Delete, падает в чёрный экран и больше ни на что не отвечает. Но при этом курсор двигается, активен порт RDP, но удалённые соединения не устанавливаются. Залогиниться не получалось даже локально.
Загрузился в режиме восстановления, успешно зашёл в систему. Весь системный лог в ошибках. Службы не запускаются, какие-то файлы недоступны, на диске ошибки. Но при этом
Запускаю
Я не верил, что эту систему можно оживить. Слишком много каких-то неведомых проблем. Заказчик предложил удалить программу Обновлятор-1С, так как впервые система зависла и начались проблемы во время её работы. Я знаю эту программу. Она довольно старая и известная. Cам не раз пользовался. Каких-то глобальных проблем с ней не видел. Стояла купленная лицензионная версия.
Не думал, что удаление программы на что-то повлияет. Загрузился в безопасном режиме, удалил программу, перезагрузился. Система запустилась как ни в чём ни бывало. Никаких ошибок ни с диском, ни с файлами, ни со службами. Я не знаю, что она там делала и как ломала систему. Но факт есть факт. Дело реально было в ней.
☝️ Мораль тут какая? Бэкапить надо не только данные, но и системы. Иначе в час ИКС ты просто не будешь знать, что тебе делать. Надо искать и железо, и систему восстанавливать. А потом на неё данные накатывать. Это очень долго. Наверняка окажется, что и версий подходящих нет. Я практически всегда делаю бэкап и виртуальной машины и отдельно данных. Ну и по возможности всё это проверяю. Если не проверять, то очень велика вероятность, что в час ИКС ничего восстановить и не получится. Бэкапы могут месяцами не создаваться или создаваться битыми. Для баз данных это очень актуальная тема.
Кстати, описанная инфраструктура была построена примерно вот так. Уже не первый раз убеждаюсь, что это работает просто и надёжно. И почти не требует обслуживания. Главное, бэкапы данных и виртуальных машин делать.
#backup
В обоих случаях бэкапы вроде бы и делались, но не проверялись. По факту оказалось, что их нет.
Но тут сделал исключение. Был поздний вечер, уже собирался спать, всё выключил. Ну и как обычно проверил Telegram. А там умер виндовый сервер с кучей баз 1С. Утром придут люди и «прибьют меня».
Базы были как файловые, так и в MSSQL. Бэкапы файловых баз были, скульных – свежих нет. Но бэкап это пол дела. Системы то самой нет. Надо всё с нуля поднимать и настраивать, восстанавливать лицензии, делать публикации. На дворе ночь, подменного сервера нет.
Сервер вёл себя странно. Он нормально загружался до своей заставки с часами. А дальше ни на что не реагировал. Если раз 10 нажать CTRL+ALT+Delete, падает в чёрный экран и больше ни на что не отвечает. Но при этом курсор двигается, активен порт RDP, но удалённые соединения не устанавливаются. Залогиниться не получалось даже локально.
Загрузился в режиме восстановления, успешно зашёл в систему. Весь системный лог в ошибках. Службы не запускаются, какие-то файлы недоступны, на диске ошибки. Но при этом
sfc /scannow и DISM /Online /Cleanup-Image /RestoreHealth ошибок не показывают.Запускаю
chkdsk C: /f /r и перезагружаю. Во время проверки долго висит на 15%, по графикам VM видно, что очень активно шерстит NVME дисками. В итоге проверка до конца не доходит, аварийно вырубается и система заново загружается с теми же проблемами.Я не верил, что эту систему можно оживить. Слишком много каких-то неведомых проблем. Заказчик предложил удалить программу Обновлятор-1С, так как впервые система зависла и начались проблемы во время её работы. Я знаю эту программу. Она довольно старая и известная. Cам не раз пользовался. Каких-то глобальных проблем с ней не видел. Стояла купленная лицензионная версия.
Не думал, что удаление программы на что-то повлияет. Загрузился в безопасном режиме, удалил программу, перезагрузился. Система запустилась как ни в чём ни бывало. Никаких ошибок ни с диском, ни с файлами, ни со службами. Я не знаю, что она там делала и как ломала систему. Но факт есть факт. Дело реально было в ней.
☝️ Мораль тут какая? Бэкапить надо не только данные, но и системы. Иначе в час ИКС ты просто не будешь знать, что тебе делать. Надо искать и железо, и систему восстанавливать. А потом на неё данные накатывать. Это очень долго. Наверняка окажется, что и версий подходящих нет. Я практически всегда делаю бэкап и виртуальной машины и отдельно данных. Ну и по возможности всё это проверяю. Если не проверять, то очень велика вероятность, что в час ИКС ничего восстановить и не получится. Бэкапы могут месяцами не создаваться или создаваться битыми. Для баз данных это очень актуальная тема.
Кстати, описанная инфраструктура была построена примерно вот так. Уже не первый раз убеждаюсь, что это работает просто и надёжно. И почти не требует обслуживания. Главное, бэкапы данных и виртуальных машин делать.
#backup
Please open Telegram to view this post
VIEW IN TELEGRAM
👍132👎3
У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
Это пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
Можно просто в Docker запустить:
Если запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
# trufflehog git https://github.com/trufflesecurity/test_keysЭто пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
# curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/binМожно просто в Docker запустить:
# docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keysЕсли запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
# trufflehog filesystem --config=$PWD/generic.yml /var/logTrufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
1👍74👎3
⇨ Postgresus - удобный домашний бекап баз данных
Коротенький обзор веб панели программы для бэкапа PostgreSQL серверов. Выглядит удобно и полезно. Скорее всего тоже попробую и сделаю отдельный обзор. Бэкапы она делает только полные, так что подойдёт только для небольших баз. У меня есть сервера, где как раз куча небольших баз 1С. Возможно, с этой панелькой будет удобно их бэкапить и быстро восстанавливать.
⇨ Self-Host Your Own Automation Platform with n8n + Docker
Очередной обзор и примеры использования платформы для автоматизации n8n. Это очень популярная и функциональная штука. Я пару раз за неё садился и пытался к чему-нибудь приспособить, но ничего дельного не получалось. Её на самом деле с наскока трудно освоить, хоть она и позиционируется как простое no-code решение. Кто не знаком с ней, рекомендую посмотреть. Может приспособите её куда-то к себе.
⇨ Сжатие текста в Angie: статика, динамика, производительность
Обзор и тесты различных режимов сжатия в веб сервере. Я всё это неплохо знаю и в своё время тестировал и использовал различные алгоритмы: gzip, brotli, zstd. Про последний делал отдельную заметку с описанием настройки. Я лично почти везде включаю zstd на веб серверах.
⇨ Zabbix 7.4 Host Wizard Overview
Видео актуально, если вы не собираетесь обновляться до 7.4, но хотите посмотреть, как выглядит новый интерфейс добавления хостов в Zabbix Server.
⇨ OAuth 2.0 — Простым языком на понятном примере
Автор подробно и с примерами показал, как работает OAuth и OpenID Connect. Часто упоминаю эти технологии, когда рассказываю про тот или иной софт. Если не знаете, что это такое, то посмотрите видео.
⇨ Grafana Alloy, NEW log + metric collector replaces everything!
Обзор инструмента Grafana Alloy. Думал это что-то новое, но не особо то и новое. Год уже точно существует. Честно говоря, впервые услышал про этот продукт. Никогда не видел и не слышал. Он собирает логи и метрики. По сути это аналог promtail, opentelemetry collector и т.д.
⇨ ALT Linux 10 установка КриптоПРО 5 с поддержкой ключей от 4-й версии
Настройка работы КриптоПРО на рабочей станции ALT.
⇨ Устанавливаем Fedora Server 42 — Идеальный дистрибутив для self-hosting?
Практической пользы нет, но мне было любопытно посмотреть. Вообще не знал, что у Fedora есть сервер. После видео так и не понял, зачем он нужен.
⇨ Прямое подключение NAS к ПК по 10GbE
Видео простенькое, для обычных пользователей. Но мне было интересно посмотреть, что за адаптеры с подключением по usb-c используются для этого (цена ~6 т.р.), какие провода и т.д. На практике я вообще никогда не настраивал такие интерфейсы. Были кое-где на арендных серверах, но там настраивать ничего не надо. Сразу выдают настроенные.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Postgresus - удобный домашний бекап баз данных
из рубрики "полезное и интересное" рассмотрел сегодня удобный UI-интерфейс для бекапа\рестора БД Psql.
умеет работать по расписанию, отправлять нотификации, сохранять в s3\google-drive, обладает удобным и очень приветливым интерфейсом.
где-то на проде конечно…
умеет работать по расписанию, отправлять нотификации, сохранять в s3\google-drive, обладает удобным и очень приветливым интерфейсом.
где-то на проде конечно…
👍53👎2
Регулярные выражения или по-простому регулярки способны освоить не только лишь все. Это база, которая сделала конструкции из консольных команд в Unix нечитаемыми не только для обычных людей, но и it-специалистов, которые не понимают регулярок. Кто знает, может быть из-за них юниксоидов, а потом и линуксоидов прозвали задротами и красноглазиками. А как ещё назвать человека, который способен расшифровать подобное:
Конечно, сейчас можно сказать, что зачем всё это знать, если можно просто спросить ChatGPT и он всё объяснит и сам напишет. А зачем вообще в школу ходить и делать домашки, если их может тот же ИИ сделать? Уже есть исследования, которые показывают, что через 2-3 месяца активного использования ИИ для решения задач у человека заметно снижаются когнитивные способности. Если по-простому, то он тупеть начинает, не хочет и не может лишний раз подумать и решить задачу.
Я, кстати, из-за этого всегда без исключений все тексты пишу сам, даже если очень не хочется. Велик соблазн попросить ИИ, а потом за ним подредактировать. Это проще, чем писать самому с нуля. Но я знаю, что начну терять навык. Даже структуру статей, заметок не прошу делать. Делаю сам от и до.
То же самое касается конфигураций и bash скриптов. Никогда не прошу полностью решить задачу. Если что-то и спрашиваю, то про какие-то конкретные вещи. То есть использую его как справочник, а не как инструмент для решения всей задачи. Тупеть не хочется. Возраст и так своё дело рано или поздно сделает, не хочется ему помогать.
Длинное вступление получилось. Написать не об этом хотел. Есть очень качественный интерактивный тренажёр для изучения регулярных выражений. Он переведён на многие языки, в том числе русский. Перевод качественный.
⇨ https://regexlearn.com/ru
В нём сначала идёт блок теории, а потом она закрепляется практикой. Ничего сложного, но нужно будет немного поднапрячь мозги. Даётся база, каких-то сложных выражений не разбирают. Если будете реально проходить, то рекомендую открыть с этого же сайта шпаргалку. Я без неё проходил, потому что в целом всё это и так знаю. Конкретно эту базу невольно пришлось освоить, когда самостоятельно изучал Asterisk и писал план набора в
📌 Дополнительные ссылки по теме:
▪️ autoregex.xyz — построение регулярок с помощью ИИ
▪️ regex101.com — проверка регулярных выражений
▪️ grex — автоматическое составление регулярок на основе набора данных
▪️ regexper.com — схематическое изображение регулярок
▪️ ihateregex.io — готовые примеры регулярных выражений
▪️SLASH\ESCAPE — интерактивная атмосферная обучающая игра
Ссылки все живые. Какие-то блокируются из-за CF, какие-то из-за блока на той стороне 🤷♂️
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#regex #обучение
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*#?&])[A-Za-z\d@$!#%*?&]{8,}$Конечно, сейчас можно сказать, что зачем всё это знать, если можно просто спросить ChatGPT и он всё объяснит и сам напишет. А зачем вообще в школу ходить и делать домашки, если их может тот же ИИ сделать? Уже есть исследования, которые показывают, что через 2-3 месяца активного использования ИИ для решения задач у человека заметно снижаются когнитивные способности. Если по-простому, то он тупеть начинает, не хочет и не может лишний раз подумать и решить задачу.
Я, кстати, из-за этого всегда без исключений все тексты пишу сам, даже если очень не хочется. Велик соблазн попросить ИИ, а потом за ним подредактировать. Это проще, чем писать самому с нуля. Но я знаю, что начну терять навык. Даже структуру статей, заметок не прошу делать. Делаю сам от и до.
То же самое касается конфигураций и bash скриптов. Никогда не прошу полностью решить задачу. Если что-то и спрашиваю, то про какие-то конкретные вещи. То есть использую его как справочник, а не как инструмент для решения всей задачи. Тупеть не хочется. Возраст и так своё дело рано или поздно сделает, не хочется ему помогать.
Длинное вступление получилось. Написать не об этом хотел. Есть очень качественный интерактивный тренажёр для изучения регулярных выражений. Он переведён на многие языки, в том числе русский. Перевод качественный.
⇨ https://regexlearn.com/ru
В нём сначала идёт блок теории, а потом она закрепляется практикой. Ничего сложного, но нужно будет немного поднапрячь мозги. Даётся база, каких-то сложных выражений не разбирают. Если будете реально проходить, то рекомендую открыть с этого же сайта шпаргалку. Я без неё проходил, потому что в целом всё это и так знаю. Конкретно эту базу невольно пришлось освоить, когда самостоятельно изучал Asterisk и писал план набора в
extensions.conf. Там без регулярок никуда. Вся настройка на них основывается.📌 Дополнительные ссылки по теме:
▪️ autoregex.xyz — построение регулярок с помощью ИИ
▪️ regex101.com — проверка регулярных выражений
▪️ grex — автоматическое составление регулярок на основе набора данных
▪️ regexper.com — схематическое изображение регулярок
▪️ ihateregex.io — готовые примеры регулярных выражений
▪️SLASH\ESCAPE — интерактивная атмосферная обучающая игра
Ссылки все живые. Какие-то блокируются из-за CF, какие-то из-за блока на той стороне 🤷♂️
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#regex #обучение
2👍177👎4
На прошлой неделе смотрел видео и читал статью про веб панель управления бэкапами PostgreSQL. А если точнее, то только бэкапами в виде дампов. Сразу понятно, что это инструмент для небольших баз данных. Большие базы дампами бэкапить неудобно, так как это, во-первых, может длиться непрогнозируемо долго, во-вторых, это всегда только полные бэкапы, а для больших баз хочется инкрементных копий.
Речь пойдёт о Postgresus. Основные возможности:
◽️Веб интерфейс для управления заданиями и отчётами
◽️Расписание бэкапов
◽️Сжатие, автоочистка старых бэкапов
◽️Хранение локально или в S3, Google Drive
◽️Уведомления по Email, Telegram
◽️Запускается в Docker Compose
По сути это замена самописным bash скриптам в кроне. Именно их я и использую для таких задач 🤖 Решил упростить себе задачу. Забегая вперёд, скажу, что эта панель реально заменяет эти скрипты, не более.
Postgresus состоит из двух Docker контейнеров: непосредственно сама панель и локальный экземпляр postgresql сервера для хранения собственных настроек. Запустить можно вручную из предложенного в репозитории файла
Скрипт ставит докер и стартует с этим же docker-compose.yml. Я вручную запустил. После запуска можно сразу идти в веб интерфейс на порт сервера 4005 и там всё настраивать. Не рекомендую запускать подобные вещи непосредственно на сервере с СУБД. Я сделал отдельную небольшую виртуалку и открыл для неё доступ к базам.
Дальнейшее управление осуществляется через веб интерфейс. Там всё максимально просто и наглядно:
1️⃣ Настраиваем хранилище для бэкапов. Я использовал локальную директорию. После тестов примонтирую туда отдельно большой диск.
2️⃣ Добавляем приёмник для уведомлений. Telegram сразу заработал, нужно указать токен своего бота и ID чата. С почтой не получилось, так как отправка по умолчанию настраивается по TLS, а у меня там локальный сервер стоял без него. Перенастраивать не захотелось. Жаль, что автор не оставил такой возможности.
3️⃣ Добавляем подключение к базе данных и настраиваем параметры её бэкапа.
Бэкап выполняется не особо быстро. Скриптами локально я базу на 5ГБ бэкаплю секунд 30. Из соседней виртуалки с помощью Postgresus бэкапится 12 минут. В целом мне некритично, так как для этого сервера бэкапы выполняются раз в сутки по ночам. Времени достаточно, хотя с такой скоростью это растянется часа на полтора.
Архивы хранятся локально в виде дампов со случайными именами вида
Восстановление возможно тут же через веб интерфейс, причём на любой сервер, а не только исходный. Это удобно для ручного тестирования бэкапов. Можно создать тестовый сервер и там периодически проверять дампы или выгружать их для каких-то других задач, не нагружая основной сервер.
В общем и целом панель нормальная. Для небольших серверов будет удобным решением в качестве замены самописных скриптов. Плюс, тут дополнительно работает мониторинг доступности баз данных и уведомления и для бэкапов, и для этого мониторинга. Сделано всё аккуратно и красиво. Посмотрим, как покажет себя в реальной эксплуатации. Мне возможно не будет удобным это решение, так как на скриптах я обычно сразу и на другие сервера передаю бэкапы, и формирую дневные, недельные, месячные наборы для долгосрочного хранения. На базе этой панели это делать неудобно. Возможно, останется как дополнительный инструмент, в котором можно быстро сделать бэкап и восстановить где-то в другом месте.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postgresql #backup
Речь пойдёт о Postgresus. Основные возможности:
◽️Веб интерфейс для управления заданиями и отчётами
◽️Расписание бэкапов
◽️Сжатие, автоочистка старых бэкапов
◽️Хранение локально или в S3, Google Drive
◽️Уведомления по Email, Telegram
◽️Запускается в Docker Compose
По сути это замена самописным bash скриптам в кроне. Именно их я и использую для таких задач 🤖 Решил упростить себе задачу. Забегая вперёд, скажу, что эта панель реально заменяет эти скрипты, не более.
Postgresus состоит из двух Docker контейнеров: непосредственно сама панель и локальный экземпляр postgresql сервера для хранения собственных настроек. Запустить можно вручную из предложенного в репозитории файла
docker-compose.yml, либо воспользоваться скриптом от разработчика:# curl -sSL https://raw.githubusercontent.com/RostislavDugin/postgresus/refs/heads/main/install-postgresus.sh | bashСкрипт ставит докер и стартует с этим же docker-compose.yml. Я вручную запустил. После запуска можно сразу идти в веб интерфейс на порт сервера 4005 и там всё настраивать. Не рекомендую запускать подобные вещи непосредственно на сервере с СУБД. Я сделал отдельную небольшую виртуалку и открыл для неё доступ к базам.
Дальнейшее управление осуществляется через веб интерфейс. Там всё максимально просто и наглядно:
Бэкап выполняется не особо быстро. Скриптами локально я базу на 5ГБ бэкаплю секунд 30. Из соседней виртуалки с помощью Postgresus бэкапится 12 минут. В целом мне некритично, так как для этого сервера бэкапы выполняются раз в сутки по ночам. Времени достаточно, хотя с такой скоростью это растянется часа на полтора.
Архивы хранятся локально в виде дампов со случайными именами вида
a8bc8814-c548-4f9a-ba0c-97d3b1e107fc. Не очень удобно, если захочется куда-то дублировать их. Скачать дамп можно через веб интерфейс и вручную восстановить с помощью pg_restore. Я заглянул внутрь дампа. Он отличается от того, что делаю я с помощью pg_dump. Скорее всего используются какие-то дополнительные ключи. Я обычно делаю чистый дамп только данных.Восстановление возможно тут же через веб интерфейс, причём на любой сервер, а не только исходный. Это удобно для ручного тестирования бэкапов. Можно создать тестовый сервер и там периодически проверять дампы или выгружать их для каких-то других задач, не нагружая основной сервер.
В общем и целом панель нормальная. Для небольших серверов будет удобным решением в качестве замены самописных скриптов. Плюс, тут дополнительно работает мониторинг доступности баз данных и уведомления и для бэкапов, и для этого мониторинга. Сделано всё аккуратно и красиво. Посмотрим, как покажет себя в реальной эксплуатации. Мне возможно не будет удобным это решение, так как на скриптах я обычно сразу и на другие сервера передаю бэкапы, и формирую дневные, недельные, месячные наборы для долгосрочного хранения. На базе этой панели это делать неудобно. Возможно, останется как дополнительный инструмент, в котором можно быстро сделать бэкап и восстановить где-то в другом месте.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postgresql #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍80👎7
Вчера рассмотрел Postgresus - веб панель для бэкапов баз Postgresql. У неё есть очень близкий и более старый аналог – PG Back Web. Панели похожи по функциональности и архитектуре. Автор Postgresus наверняка знаком с ней, потому что многие вещи реализованы схожим образом. Но есть и отличия. Каждый, судя по всему, реализовал настройки и управление так, как ему казалось более удобным. Расскажу по порядку.
1️⃣ Установка выполняется так же, как и у Postgresus – готовый
2️⃣ В Pgbackweb сущности в виде баз данных и заданий для бэкапа разделены. Отдельно добавляется база, отдельно для неё создаётся задание для бэкапа. Соответственно, для одной и той же базы могут быть созданы разные задачи с бэкапом и параметрами хранения. В Postgresus настройки базы и бэкапа для неё объединены в одну сущность.
3️⃣ Создаваемый в Pgbackweb дамп тут же на лету жмётся в zip. А в самом архиве лежит чистый дамп в текстовом формате, который можно открыть, посмотреть, изменить. Создание дампа в Pgbackweb примерно в 2-2,5 раза дольше, чем у Postgresus. Последний жмёт средствами самого pg_dump, если я правильно понял из исходников, то есть использует ключи
К сожалению, обе панели не дают возможность самому задавать эти параметры. А иногда бывает нужно либо так, либо эдак. Например, если тебе важна скорость, то лучше жать встроенными средствами. Но из такого дампа потом неудобно извлекать отдельную таблицу, если она понадобится. А из текстового дампа это сделать очень просто. Лично я, когда создаю дампы баз данных, выгружаю их в обычном текстовом формате и жму сам с помощью pigz в многопоточном режиме. Получается и быстро, и удобно. Потом распаковал и делай с ним, что хочешь.
4️⃣ Pgbackweb предлагает сохранять бэкапы либо локально, либо в S3. Больше у неё ничего нет для хранения. Формат путей вида
5️⃣ Сохранённый дамп можно самому скачать и восстановить вручную, либо воспользоваться веб интерфейсом. Базу можно восстановить как в исходную, так и в другую, в том числе на другом сервере. Здесь возможности обеих панелей совпадают.
6️⃣ В качестве уведомлений Pgbackweb предлагает только вебхуки, что слабовато по сравнению с готовой интеграцией с Telegram, Email, Slack, Discord в Postgresus.
В общем и целом панели сильно похожи и выполняют одни и те же задачи. Разница в некоторых мелочах, которые кому-то могут быть критичны, кому-то нет. Мне лично больше понравилась Postgresus за её внешний вид и внутреннюю логику. Сжатые дампы делает намного быстрее, что уже на базах в 5-10 ГБ становится критично. Так как, к примеру, 15 минут против 35 для 10 ГБ – это существенная разница.
⇨🌐 Исходники / ▶️ Видеобзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postgresql #backup
docker-compose.yaml в репозитории для запуска двух контейнеров: сама веб панель и локальная Postgresql для сохранения настроек и состояния. Достаточно запустить docker compose и можно идти на порт 8085 сервера и пользоваться панелью. В консоли больше делать нечего.-Fc (custom-format) -Z 6 (compression level). К сожалению, обе панели не дают возможность самому задавать эти параметры. А иногда бывает нужно либо так, либо эдак. Например, если тебе важна скорость, то лучше жать встроенными средствами. Но из такого дампа потом неудобно извлекать отдельную таблицу, если она понадобится. А из текстового дампа это сделать очень просто. Лично я, когда создаю дампы баз данных, выгружаю их в обычном текстовом формате и жму сам с помощью pigz в многопоточном режиме. Получается и быстро, и удобно. Потом распаковал и делай с ним, что хочешь.
/backups/dbase01/2025/07/21. Это удобно, если захочется забирать готовые дампы куда-то ещё и складывать их в архивы по каким-то датам. В Postgresus такой возможности нет. Там ни в пути, ни в имени файла нет никаких временных меток и упоминания имени базы.В общем и целом панели сильно похожи и выполняют одни и те же задачи. Разница в некоторых мелочах, которые кому-то могут быть критичны, кому-то нет. Мне лично больше понравилась Postgresus за её внешний вид и внутреннюю логику. Сжатые дампы делает намного быстрее, что уже на базах в 5-10 ГБ становится критично. Так как, к примеру, 15 минут против 35 для 10 ГБ – это существенная разница.
⇨
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postgresql #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍61👎3