Есть общая рекомендация по использованию дисков в Linux - сначала создать раздел на диске, а потом использовать его по назначению. Даже если у вас будет один раздел на весь диск, сделайте его.

Если честно, я никогда не разбирался в чем суть этой рекомендации. Более того, иногда использовал диск целиком без создания раздела. С проблемами не сталкивался.

Но недавно один подписчик написал в комментарии к статье, что у него разваливается mdamd рейд после перезагрузки. Как оказалось, он не разбил диски на разделы, а добавил их как есть, целиком, в массив.

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

После того, как он это сделал, проблема ушла. Я не проверял данную информацию и не знаю, что за версии bios, которые затирают метаданные. Но факт в том, что проблема такая есть, поэтому я поделился с вами. Сам буду всегда создавать разделы.

​​🔥 Я тут в очередной раз просматривал на hh вакансии и решил сделать заметку по этому поводу. Ниже на картинке зарплатные вилки для Системных администраторов и Devops. Разница в предлагаемой оплате более чем значительная.

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

Чтобы не прослыть шарлатаном, достаточно немного освоить ci/cd, docker и уметь писать скрипты на bash / python, ко всему тому, что у вас есть за плечами. Если не умеете ни то, ни другое, займитесь обучением по этим темам в первую очередь. За пол года неспешного обучения сможете претендовать на увеличение зп 50+ т.р.

Я не хочу обсуждать смысл слова devops, что это не должность а методология, т.д. и т.п.🤷‍♂️ Говорю по факту, что сейчас есть на рынке вакансий и как можно оперативно увеличить свой доход небольшими усилиями.

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

Но ничего не поделать, придется переходить на подтвержденные сертификаты. В общем, в статье рассказываю, как использовать бесплатные сертификаты от Let's Encrypt в почтовых серверах. В частности, в postfix и dovecot.

https://serveradmin.ru/nastrojka-ssl-tls-sertifikatov-lets-encrypt-v-postfix-i-dovecot/

📆 Завтра будет вебинар Zabbix на тему - Больше готовых возможностей мониторинга с Zabbix агентом 2. Планирую посмотреть. Надеюсь получится не как в прошлый раз. Вебинар просто не состоялся и не было никакого уведомления о том, что его не будет.

Кто-то в итоге видел вебинар по прошлой теме, который я анонсировал - Мониторинг Docker с помощью Zabbix, используя Kubernetes. Дайте обратную связь по нему.

Регистрация на этот - https://us02web.zoom.us/webinar/register/WN_S6EaA2cgQPKyEUZUb8v_kw

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

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

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

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

#zabbix

Немного развил тему wordpress и docker, начатую некоторое время назад. В этот раз полностью автоматизировал установку и запуск сайта сразу с https. Сертификат выдает let's encrypt в отдельном контейнере с nginx proxy.

Что на выходе получается. У вас есть несколько конфигов (nginx, .htacces и преднастройка worpdress с помощью wp-cli) и файл docker-compose. С его помощью вы без лишних телодвижений запускаете сайт. Он автоматом получает сертификаты, настраивает https, устанавливает чистый wordpress с указанными вами плагинами и темами.

Помимо самой статьи в конце есть видео, где я демонстрирую все описанное.

https://serveradmin.ru/install-wordpress-docker-https/

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

Я основные моменты по agent2 законспектировал и делюсь с вами:

1️⃣ В agent2 есть буфер для хранения информации. Если нет связи с сервером, то данные накапливаются на агенте и потом отправляются. Это полезная штука, только ради которой можно переходить на этого агента.
2️⃣ Поддержка плагинов на Go. Уже есть для mysql, postgres, redis, memcached, docker. Постараюсь посмотреть на них в ближайшее время и написать статью.
3️⃣ Статус агента можно проверить через браузер. Любопытная вещь, впервые об этом услышал. Пока не придумал, зачем это может быть нужно.
4️⃣ Старый агент будет по прежнему развиваться и поддерживаться. Нет планов по его закрытию. 
5️⃣ На одном и том же узле могут работать оба агента одновременно.

Немного погуглил после вебинара на тему второго агента. Вроде ничего нового и полезного не нашел. Делюсь вот этой ссылкой - https://temofeev.ru/info/articles/razrabotka-plaginov-dlya-zabbix-agent-2/ Там очень подробно описан механизм работы нового агента, так же рассказано, как для него писать плагины. Приведены конкретные примеры кода.

❗️ Плавно подходим к тому, что чтобы настраивать хороший мониторинг, нужно быть программистом. Эту мысль я уже озвучивал раньше в заметках. Так что господа админы: "Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!"

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

Одно из преимуществ профессиональных рабочих станций — их надежность. К примеру, системы Dell Precision оснащены памятью, поддерживающей функцию коррекции ошибок. По результатам исследования, проведенного Google и Университетом Торонто, ошибки памяти возникают в трети компьютеров минимум раз в год. В 70—80% случаев непоправимой ошибке предшествует поправимая, которая появилась в течение 1—2 месяцев. Вот почему так важно, чтобы система умела их вовремя распознавать.

В рабочих станциях Dell применяется технология Dell Reliable Memory Technology (RMT) Pro. Она навсегда блокирует доступ к поврежденным секторам памяти, что исключает появление «синего экрана смерти». При этом можно продолжать пользоваться тем же модулем и не тратиться на замену.

Хотите узнать и о других плюсах рабочих станций? Загружайте бесплатно нашу брошюру.

#реклама

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

Когда мне приходилось участвовать в закупках системных блоков, я никогда не рассматривал вариант самостоятельного сбора или заказа сбора из моих комплектующих в магазине. Считаю это пережитком прошлого, пустой и вредной тратой времени, если вы работаете на потоке. Речь не идет о системном блоке домой, который вы обновляете раз в 5-10 лет.

Я не буду развивать эту тему здесь, так как все очень подробно и с примерами рассказал в статье. Сейчас мне любопытно посмотреть на мнение других по этой теме, поэтому предлагаю такой опрос. При работе наемным сотрудником в организации, вы прежде всего рассматриваете покупку брендового компьютера или самосбор?

https://serveradmin.ru/korporativnyj-kompyuter-dlya-raboty-v-ofise-brend-ili-samosbor/

​​Всем привет. Я завел себе еще один канал и назвал @srv_admin_live. Объясню, зачем это сделал. Ведение основного канала превратилось в упорядоченную и структурированную деятельность. Я составляю контент план на неделю, чаще всего заранее пишут посты. Выверяю текст, форматирую, готовлю изображения, ссылки и т.д.

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

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

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

Ниже пример того, как я планирую публикации на основной канал.

На днях один заказчик предоставил доступ к свежеустановленному серверу на Centos 8. Сказал, что выполнил минимальную установку. Я с удивление обнаружил, что на сервере не установлен rsyslog.

Понял это, когда не обнаружил на привычном месте в /var/log логов maillog и messages. Я не проверял еще, действительно ли из базового образа убрали rsyslog. Когда разворачиваю из шаблонов хостеров, он там присутствует.

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

Предлагаемый в качестве замены Journald пишет логи в бинарном формате. Как по мне, это менее удобно обычного текстового. Если хотите вернуть традиционные текстовые логи, просто установите и запустите rsyslog:

# dnf install rsyslog
# systemctl enable --now rsyslog

Вам где больше нравится смотреть логи?

У меня достаточно много статей про настройку почтовых серверов. Это не случайно, так как меня часто просят их настраивать. Казалось бы, эта услуга сейчас очень развита как сервис. Достаточно подключить домен к какой-нибудь почте mail.ru или Яндекс и пользоваться бесплатно или за небольшие деньги.

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

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

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

https://serveradmin.ru/izmenenie-pochtovogo-parolya-polzovatelem-cherez-roundcube/

​​Простой и удобный конфигуратор PostgreSQL для того, чтобы быстро подогнать конфиг к реалиям сервера - https://www.pgconfig.org/

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

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

⚡️ На днях ко мне обратился знакомый с просьбой помочь разгрести последствия взлома локалки. Я у него админю сервера в ЦОД, а к локальной сети не имею никакого отношения. Расскажу кратко то, что узнал сам. Ситуация типовая и показательная.

На входе стоит Mikrotik, в который воткнут usb модем провайдера сотовой сети. Интернет заходит через него. На микротике был обнаружен vpn канал злоумышленника. С его помощью он закрепился в локальной сети и изучал ее.

Проблемы заметили со стороны ip телефонии. Позвонил провайдер и предупредил, что звонки заблокированы, так как израсходован дневной лимит. Это позволило сразу обнаружить взлом, который был осуществлен в выходной день. При этом было настроено ограничение по ip на подключения к облачной АТС. Считается, что это самая надежная защита, так как физически невозможно осуществить звонок извне, даже если утекут учетные данные номеров. По факту это не спасло, так как через vpn канал это ограничение обошли. Повезло, что был дневной лимит.

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

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

Отсюда можно сделать несколько закономерных выводов:

1. Доступ к пограничным роутерам запрещать максимально сильно. Лучше снаружи вообще всё закрыть. Если все же нужно оставить доступ, то настройте хотя бы Port knocking.
2. Сервера изолировать от всего остального.
3. На выходные компьютеры в офисе выключать.
4. Дневной лимит на звонки через ip телефонию, если оператор поддерживает, использовать.
5. Всегда и везде своевременно ставить обновления.

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

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

А оправдано его использование может быть в следующих ситуациях:
1️⃣ К серверу подключаются разные администраторы. Нужно логировать их действия и разграничивать права доступа.
2️⃣ Linux ваша рабочая системы, с помощью sudo вы запускаете редкие команды с полными правами.
3️⃣ Sudo используется в скриптах для ограничения доступа. Абсолютно оправданное использование, сам так поступаю.

А что вы думаете по поводу sudo? Используете или нет и в каких случаях?

https://serveradmin.ru/sudo-ne-nuzhen-pri-rabote-v-konsoli-servera-tak-li-eto/

Ко мне на обзор попал очень интересный сервис для дистанционного управления компьютерами - Getscreen.meGetscreen.me. И хотя сервисов для удаленного подключения к компьютерам очень много, уверен, этот вас заинтересует. Основные моменты, за которые лично мне он сразу понравился - работа через браузер, интеграция с telegram (есть крутые фишки) и удобный личный кабинет, через который все управляется.

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

https://serveradmin.ru/otzyv-na-getscreen-me/

​​📆 Завтра пройдет вебинар Zabbix - Как правильно обнаруживать проблемы: используем все возможности триггеров. Я уже смотрел его и в целом могу порекомендовать. Там дается обзор основного функционала триггеров с примерами.

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

https://us02web.zoom.us/webinar/register/WN_XB2165P8Rz6CJsFMGlqohQ

#zabbix #вебинар

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

Команда Инфратех сделала этот труд за вас. 👌🏼

Представляем книгу «Всё о FortiGate от А до Я» — полное руководство по одному из лучших NGFW по Гартнеру, тестам NSS Labs и ФСТЭК.

На 75 страницах вы:

💠 узнаете фишки FortiGate которых нет у других вендоров
💠 в одном месте просмотрите все линейки моделей от десктоп-исполнения до модульных FortiGate на 8 слотов в серверном шкафу
💠 на примере рассчитаете вместе с автором стоимость устройства и лицензий
💠 получите схемы создания отказоустойчивых кластеров на VDOMs и нескольких устройствах

Книга бесплатная, придет на почту в течении 15 минут после регистрации по ссылке 👉🏻 https://clck.ru/SEMfy

#реклама

Недавно обновил свою очень старую статью (писал 5 лет назад) про бэкап сайтов на Яндекс.Диск. Тогда он еще нормально работал по webdav. Я сам уже не пользуюсь этим диском для бэкапов с линукс серверов, но одно время использовал очень активно.

Основное преимущество - цена. С помощью консольного клиента linux я синхронизировал каталоги файлов на несколько терабайт с десятками тысяч файлов. И стоило это фактически копейки, если сравнивать с нормальными хранилищами для бэкапов.

Работало все это на таких объемах не очень стабильно, клиент периодически вис. Но при наличии мониторинга бэкапов это было терпимо. В какой-то момент просто перестали влезать в технологическое окно и бэкапы не успевали синхронизироваться. После этого пришлось перейти на другие инструменты (арендовали сервер с большими дисками).

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

https://serveradmin.ru/bekap-sayta-wordpress-na-yandeks-disk/

​​Регулярно вижу в некоторых вакансиях требование быть на связи 24/7. На вид обычная вакансия, все как у всех, но маленькая такая приписочка в конце. Вроде и ничего особенного, но по факту вас хотят разбудить ночью в 3 часа и вынудить что-то сделать.

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

Не делайте так и даже не позволяйте работодателям думать, что работая по стандартному графику 8/5 вы готовы будете еще и ночью что-то чинить. Если сервис не терпит простоя, то должны выделяться деньги на дежурную смену, которая будет способна решать проблемы.

Я даже не представляю, на каких условиях можно соглашаться с таким дополнением. Наверное, только если зарплата будет x2. Несмотря на то, что у меня свободный график, я всегда и всем, когда договариваюсь о сотрудничестве, говорю, что мой рабочий день в интервале с 9 до 19 и в выходные я не работаю. Ночью на звонки не отвечаю. Я всегда выключаю звук на смартфоне после 20:30, готовлю детей ко сну. А когда ложусь спать, оставляю аппарат на кухне.

А вы готовы работать с таким условием, даже если гипотетический шанс быть разбуженным ночью не очень большой? Сколько по-вашему, за это нужно доплачивать и нужно ли?