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

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

В общем, история неприятная. Немного понервничал, так как до конца не было понятно, что процесс закончится удачно и не будет проблем. Из бэкапов все восстанавливать очень долго, так как данных много.

Подробное описание и разбор оформил в статью.

https://serveradmin.ru/a-start-job-is-running-for-file-system-check/

▶️ Посмотрел недавно видео про то, как делают бэкапы в Badoo. Не могу сказать, что вынес оттуда что-то новое для себя в организационном плане, но в целом видео считаю полезным. Подача материала понравилась. Не просто презентация, про то, как мы делаем, а немного художественная история получилась. Из того, что не понравилось - шапка в помещении на выступающем.

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

Понравилось определение: «Бэкап - это неизменяемые данные на определенный момент времени». Это сразу отсекает всякие рейды и реплики из списка вариантов бэкапа.

Основные свойства бэкапа:

1️⃣ должен быть в стороне, не подвержен изменению;

2️⃣ должен восстанавливаться;

3️⃣ нужно всегда знать, за какое время ты сможешь
восстановить данные.

Также обратил внимание на софт, который использует Badoo для бэкапов - Bareos. Я знаком с его первоисточником - Bacula, bereos - форк бакулы. Саму бакулу я когда-то давно настраивал и использовал. Впечатления были не очень, поэтому от продукта отказался. Слишком сложный, неинтуитивный, лапша конфигов. Плюс, его еще самого надо бэкапить, потому что если Bacula грохнется, ничего из бэкапов не достать.

Возможно, имеет смысл попробовать Bareos. У кого есть опыт его использования, поделитесь в комментариях.

https://www.youtube.com/watch?v=cQsSALJt80E

#видео #backup

Ударно потрудился в этом году. Регулярно писал посты, получилось более одного в день. Для меня телеграм прям открытие этого года. Давно им пользуюсь, но вести активно канал начал фактически пол года назад.

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

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

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

​​На днях подбивал дела уходящего года. Нужен был дедик. Заказал, как обычно, в Selectel. Я беру бюджетные сервера линейки chipcore с двумя ssd дисками. Для серверов общего назначения под web, почту, мониторинг нормально подходят.

Недавно у них появился новый шаблон системы - Proxmox 6. Очень удобно, быстро получаешь готовый гипервизор. Все автоматически ставится на mdadm raid1, сверху lvm. После установки все проверил, массив на месте. Грузится система с /boot, который тоже на mdadm.

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

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

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

1. Как мне заменили в Selectel не тот диск - https://serveradmin.ru/vosstanovlenie-raid-1/

2. Получил новый сервер с убитыми ssd - https://t.iss.one/srv_admin/190

Хочу поделиться занимательной историей про популярные расширения для браузера - https://habr.com/ru/company/yandex/blog/534586/ с теми, кто ее не слышал.

Обращаю ваше внимание на нее, потому что сам пострадавший. Мне одно время нравился Яндекс.Браузер и я его активно использовал. В какой-то момент стал замечать, что слышу рекламу, когда использую наушники. В рекламе рассказывали про Сбербанк. Слышал ее, только когда использовал Яндекс.Браузер.

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

В то время не знал, что виновато было расширение SaveFrom.net. Но сам для себя решил, что буду пользоваться голым браузером вообще без расширений. Так и поступил и с тех пор мой основной браузер Chrome без расширений.

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

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

🤪 Немного юмора в праздники. У меня есть небольшая подборка вакансий сисадминов, которые я в свое время собрал на авито. Статья старая, думаю, многие не видели ее, так что решил еще раз поделиться.

Пару примеров оттуда:

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

С 14 лет ставил винду и восстанавливал систему знакомым, поэтому опыт есть. Знаю очень хорошо php/css/html5/js/Apache/Linux. Как дополнение разбираюсь в интернет-маркетинге SEO/CPC. На среднем уровне умею работать на 1С. Касательно изменений конфигурации, подключении касс и т.д.

https://serveradmin.ru/lyubopytnye-vakansii-sistemnyh-administratorov/

#юмор

Хороший юмор на тему сисадминов. Смотреть с субтитрами, если не разбираете, о чем говорят. Но там и так все понятно, если что. Понравилось больше всего:

"Сегодня мы с сожалением прощаемся с нашим лучшим сотрудником Майклом. Он забыл свой пароль (испуганный вскрик в зале) и больше не может продолжать свою работу. Я бы хотела с этим что-то поделать, но как вы все знаете, если пароль забыт, то это конец. Он исчезает навсегда (слезы провожающих)."

Еще круто подметили тему с проводами у блондиночки в кабинете 😂

https://www.youtube.com/watch?v=53H3KJ3oAIs

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

Мне кажется, это будет интересно и полезно не меньше основной тематики сайта и канала. У меня есть большой практический опыт в том деле, который наработать не проще, чем изучить те же IT технологии. Скорее даже сложнее, так как нет систематизированных знаний или курсов, где тебя всему научат.

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

https://serveradmin.ru/skolko-ya-zarabotal-na-sajte-i-gruppe-telegram-v-dekabre/

Картинка вроде бы бредовая. Юмор высосан из пальца. Но на практике, когда я работал в офисе, меня на полном серьёзе и не раз просили починить стул, стол (клавиатура падала с подставки), ящик стола, розетку, удлинитель, лампочку, стартер, открыть замок без ключа и т.д...

Было такое?

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

Давно уже планировал написать небольшую заметку вот по какой важной теме. Я советую в скриптах, особенно тех, что будут запускать в 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