Хватит шуточек, пора уже и делом заняться. Новогодние праздники утомляют. Не люблю долго бездельничать. Обычно с нетерпением жду, когда закончатся праздники и начнутся трудовые будни.

Давно уже планировал написать небольшую заметку вот по какой важной теме. Я советую в скриптах, особенно тех, что будут запускать в cron указывать полные пути к бинарникам. То есть не просто rsync, а /usr/bin/rsync. Это сэкономит вам уйму времени на отладку и поиск проблем.

Обычное дело написать скрипт без полных путей, засунуть его в крон и долго соображать, почему что-то не работает. А все просто. Вы тестируете скрипт в своем окружении, а cron запускает в своем. И у него может не быть PATH для ваших бинарников.

Еще есть нюанс с тем, как PATH проверяется. У вас могут быть одни и те же имена бинарников, но в разных директориях. Например, для php это может быть актуально. Там надо смотреть, в какой последовательности перебираются пути. Я в свое время записал это, но сейчас уже подзабыл. Столкнулся с тем, что запускался не тот бинарник, который мне был нужен.

Я лично для себя решил, что проще везде писать полные пути, чем следить за тем, чтобы было правильное окружение, в котором все пути те, что вам нужны.

Пульт управления нодой Ethereum. Часа 2 разбирался с синхронизацией ноды. Эфир - вечная головная боль. У нее постоянно что-то ломается.

Я использую клиент openethereum. Прошлая версия 3.0.1 зависла на определенном блоке и несколько дней не могла продолжить синхронизацию. Перепробовал все, что только можно. Пришлось обновляться на 3.1.0, а там новый формат db и обновление - это путь в один конец.

Часто обновление приносит новые проблемы, еще хуже старых, не тороплюсь обновляться. Но делать нечего, пришлось рискнуть. Обновил базу, бинарники, подправил конфиг под новую версию и запустил.

Нода тупо ни на что не отвечает после запуска. В логах тихо. Пару раз ее грохнул OOM Killer. Пришлось добавить swap 32G, как памяти на сервере. Нода активно ела ресурсы - cpu, память, диск. Через 1,5 часа молчаливой работы штатно запустилась и стала отвечать на запросы.

Очередная проблема решена. Если кто-то, как и я, работает с нодами, давайте скооперируемся для обмена опытом. Инфы мало, проблемы решать одному тяжело.

Я прохожу сейчас обучение по CI/CD. По завершении, напишу свой отзыв. В курсе предлагается готовое тестовое окружение, но я использую свое, чтобы получше во всем разобраться. Из-за разницы окружения, столкнулся с небольшой ошибкой.

Суть в том, что gitlab-runner по умолчанию связывается с job через tags. Я столкнулся то ли с багом, то ли с нюансом своей версии Gitlab. Решил оформить решение в статью, чтобы не забыть и с вами поделиться.

https://serveradmin.ru/gitlab-this-job-is-stuck-because-the-project-doesnt-have-any-runners-online-assigned-to-it/

​​Любопытная статья про архитектуру очень большого отказоустойчивого мониторинга на базе Zabbix, который живее всех живых, несмотря на то, что его уже столько лет хоронят.

https://habr.com/ru/post/536194/

К сожалению, в статье нет каких-то интересных подробностей и практических примеров, но просто для понимания, что так можно сделать, сойдет.

Мониторинг высокой доступности настроен с помощью старых и хорошо известных инструментов - Corosync и Pacemaker. Это кластеризация на уровне приложений на базе бесплатного ПО.

Жаль, что в статье совсем не рассмотрели вопрос с кластеризацией БД. Под большой нагрузкой там очень много нюансов по настройкам и реализации, чтобы все это нормально работало.

Как обычно, в комментариях куча людей начали хоронить Zabbix и спрашивать, почему не Prometheus. Если кому-то интересно, то у меня есть отдельная статья со сравнением Zabbix vs Prometheus.

✉ Опубликовал статью с различными вариантами настройки почтового сервера postfix для сопровождения работы сайта. В основе лежит задача по выбору сервера, через который будет отправка в зависимости от домена получателя письма.

Попутно рассказываю, зачем вообще свой почтовый сервер сайту. Какие он дает возможности и чем они отличаются от готовых сервисов. Показываю, как гибко управлять отправкой.

Так же в статье собрал все ссылки на свои похожие публикации по теме управления отправкой почты через postfix. Постарался доступно все объяснить на примерах из своей практики.

https://serveradmin.ru/postfix-vybor-servera-dlya-otpravki-v-zavisimosti-ot-poluchatelya/

📌 Завтра, 12 января, вторник, пройдет вебинар: Обзор системы мониторинга Zabbix.

На нем разберут основные концепции работы с системой мониторинга Zabbix, ее архитектуру, возможности.

Вебинар для тех, кто хочет познакомиться с этой системой и узнать ее возможности. Если уже плотно работаете с Zabbix, вряд ли услышите что-то новое и интересное для себя.

https://us02web.zoom.us/webinar/register/WN_-ipzBm3bQ7yVzsluom6B5w

​​Один из читателей моего сайта заморочился и написал руководство по бэкапу гипервизора - https://serveradmin.ru/forum/postid/2259/. За то, что он не поленился это сделать, я его искренне благодарю, так как знаю, что оформить полезную заметку - осмысленный труд, занимающий время.

Сам я по сути темы уже написал свое мнение там же в обсуждении на форуме. Бэкапить гипервизорвы нет смысла. И если вам вдруг понадобилось это сделать, значит вы что-то делаете не так. Виртуализация как раз и избавила нас от необходимости бэкапить таким сложным способом железные сервера. Я примерно так же бэкапил сервера под управлением Freebsd, когда начинал свою карьеру.

Но сейчас нет необходимости это делать. Виртуальные машины переезжают на гипервизоры одного и того же вендора без проблем практически на любое железо. Если у вас выходит из строя гипервизор, вы просто восстанавливаете виртуальные машины на любой другой и продолжаете работу.

При этом бэкап виртуальных машин значительно проще, чем железных серверов. Это одно из весомых преимуществ виртуализации, которое явно упрощает управление инфраструктурой. Надо обязательно этим пользоваться и забыть о бэкапе железных систем.

Отсюда возникает важный вывод, о котором некоторые забывают. На сам гипервизор не стоит навешивать какой-то функционал, помимо самого гипервизора. Исключение я делаю только в одном случае, когда использую KVM.

Иногда гипервизор выполняет роль простейшего шлюза для виртуальных машин. На нем настроен firewall и nat. Если нужен более сложный функционал, шлюз переезжает в отдельную виртуальную машину. То есть даже dns и dhcp я не ставлю на гипервизор, чтобы как раз не пришлось его бэкапить. Если виртуальной сети нужны эти службы, поднимается отдельная виртуалка со шлюзом.

🔥 Хочу поделиться с вами полезной ссылкой, которая недавно попала в поле зрения моего внимания. Сам я ознакомился с ней еще в момент публикации поста. Тематика заметки очень актуальна в последние 5 лет - работа шифровальщиков - вымогателей.

Не всегда то, что зашифровано, потеряно навсегда без ключа, который хранится у вымогателей. В статье как раз приводится такой пример. Все файлы были "зашифрованы" с помощью XOR и специалист смог их восстановить без обращения к злоумышленникам.

Так что если вам зашифровали данные, попытайте сначала удачу обращением в тех поддержку антивирусов, если у вас есть лицензия. Если вирус какой-то простой, есть шанс, что тех. поддержка вам поможет.

Тут можно было бы еще добавить, что обращайтесь к специалистам, но так как сам не знаю таких специалистов, к которым можно обратиться, поэтому и не пишу. Автор статьи на хабре живет в Беларуси (не знаю как тут правильно писать название страны).

https://habr.com/ru/post/327618/

В свете последних изменений с поддержкой Centos, команда Ubuntu подсуетилась и решила заманить разочарованных пользователей к себе. Они опубликовали заметку с набором из 6 фактов, на основании которых вам следует сделать свой выбор в пользу Ubuntu LTS. Я решил перевести основные моменты предложенных фактов и прокомментировать.

1️⃣ Разработчики предпочитают Ubuntu. В целом, замечал такое сам. Но тут речь скорее про рабочие станции и ноутбуки. А Centos это ниша в основном серверов, так что в контексте обсуждаемой проблемы этот факт малозначителен.

2️⃣ Ubuntu LTS предсказуем, стабилен и безопасен. Это просто рекламный слоган. Подтвердить или опровергнуть трудно. Чем тот же Oracle Linux непредсказуем, нестабилен и небезопасен? Ubuntu указывает на 5 лет поддержки релиза, но нас то, любителей Centos, разве это может удивить? А каждые 2 года обновления дистрибутива вряд ли можно назвать предсказуемыми. Изменения подчас радикальные.

3️⃣ В Ubuntu нет обязательных подписок. Тоже так себе факт. Подписок в linux много где нет.

4️⃣ Ubuntu LTS предлагает enterprise уровень поддержки с простым ценообразованием. Оплата рассчитывается за каждый сервер, без скрытых платежей и дополнительных условий. Тут мне трудно что-то прокомментировать, так как за linux и поддержку никогда не платил. В целом, для бизнеса прозрачное ценообразование это однозначно плюс.

5️⃣ Ubuntu поддерживают все облачные провайдеры. Это так и на самом деле это весомый аргумент. Убунта реально есть везде и это удобно.

6️⃣ Ubuntu готова для работы в огромной инфраструктуре. На ее основе можно строить кластера OpenStack, Kubernetes, High Performance Computing и т.д. Это тоже важный аргумент, так как Убунту чаще всего поддерживают все популярные вендоры ПО и железа. Но с клонами RHEL она тут на равных. Последние даже я бы сказал, что опережают.

В общем и целом, меня не убедили. Чисто маркетинговая заметка, типа какие мы хорошие, обратите на нас внимание. Думаю все и так держат во внимании Ubuntu, кто думает, куда мигрировать с Centos.

Лично я кое-где установил Centos Stream. Начинаю присматриваться к нему. Возможно для моих нужд это будет удобной системой с непрерывными обновлениями и без необходимости мигрировать с релиза на релиз. Посмотрим.

В прод ставлю пока Centos 8. Думаю, что не будет проблем, если что, в будущем переключиться на какой-то форк Centos, которых наверняка будет не мало в ближайшем будущем. В голове держу Oracle Linux и Rocky Linux.

https://ubuntu.com/blog/migrating-to-ubuntu-lts-six-facts-for-centos-users

​​На днях переносил один сервер на другое железо и решил поделиться заметкой по данной теме. Чаще всего если у сервера требуется замена комплектующих, я заказываю новый сервер и переношу все данные на него, а потом просто сдаю проблемный сервер.

Подобный подход продиктован негативным опытом, с которым я сталкивался при замене комплектующих, когда время остановки сервера было непрогнозируемым. Если надо выключать сервер и что-то менять из железа (обычно диск или память), то мне такая замена не подходит. Есть шанс, что криворукая поддержка хостера что-то сделает не так и все сломает.

Я сейчас не буду подробно останавливаться на примерах, так как неоднократно их упоминал ранее. Даже в отдельную статью пару лет назад собрал подобные случаи.

Если мне надо что-то заменить на сервере, то описываю ситуацию в тех. поддержку и прошу на сутки дать новый сервер, чтобы я перенес данные со старого и сдал его. Где-то идут на встречу и позволяют сделать такой обмен, где-то нет. Тогда просто дожидаюсь конца оплаченного периода, не продлеваю. За пару дней до конца оплаты заказываю новый сервер и переезжаю на него.

В таком случае простой прогнозируем, а чаще всего его вообще нет, так как получается бесшовно перенести сервисы, либо остановить их на минимальное время. Если же вы выключаете сервер и начинаете зависеть от тех. поддержки, время простоя вами уже не контролируется.

#железо

​​Хочу посоветовать всем системным администраторам, кто это еще не сделал, обратить пристальное внимание на git. Сам я давно пользуюсь этой системой контроля версий, но только недавно дошел до того, что стал там хранить практически все текстовые данные.

Чистил свою тестовую лабу и удалил несколько виртуалок. И только потом вспомнил, что на одной из них были нужные скрипты, на написание которых ушло прилично времени. Все репозитории проверил, нигде не нашел копий. Их просто не было. Пришлось потратить несколько часов на восстановление.

Теперь всегда, прежде чем начать писать какой-то скрипт или более ли менее большой конфиг, создаю репозиторий под это дело и все пушу туда. Я обычно использую облачный gitlab и свой локальный для приватных данных. Gitlab - мое личное предпочтение. Вы можете использовать любой бесплатный сервис. Их сейчас полно развелось.

Мало того, что это удобный контроль изменений, так еще и мгновенный бэкап всей информации по одной команде. Плюс, можно быстро что-то отредактировать через веб интерфейс. В общем, удобно, рекомендую. Еще и к разработчикам приблизитесь, будете лучше разбираться в их кухне.

#git

Один из читателей скинул мне несколько песен про админов. Мне они понравились. Я решил развить тему, поискал еще песни и делюсь с вами.

Вот, например, неплохая переделка песни сектора газа. Хоть и про программистов, но для админов тема близка 😪

Отпусти меня товарищ лейтенант,
Я не эмо, и не гот я, и не панк,
Программировал сегодня целый день,
Оттого мозги и рожа набекрень.

Тут же классика админской песни:

Где без питься и хлеба, забытые в веках,
Админы сервер держат в слабеющих руках.
........................................
Их трудная работа важней иных работ,
Из них ослабнет кто-то и сервер упадет.

Про Чистый DOS и писать не буду. Кто еще не слышал эту песню из переделки ДДТ? Хорошая переделка Высоцкого получилась. Прям наслаждение получил от прослушивания. Я все файлы переименовал, тэги добавил, чтобы было удобно слушать. Добавь в закладки, чтобы не потерять подборку.

В целом, подборка вся бодрая. Что-то лучше, что-то хуже, но понравились все песни. Если у вас есть еще на примете хорошие песни в тему, добавляйте в комментариях.