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

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

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

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

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

#mailserver

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

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

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

#postgresql

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

На входе стоит 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.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, готовлю детей ко сну. А когда ложусь спать, оставляю аппарат на кухне.

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

Несколько дней назад у меня была публикация по быстрой подготовке конфига postgresql с помощью готового web сервиса. В комментариях были вопросы про то же самое, только для mysql.

Лично я основные параметры конфигурации mysql сервера выставляю на глазок сам, так как чаще с ним работаю и уже привык. А потом в процессе эксплуатации использую вот этот скрипт - https://github.com/major/MySQLTuner-perl

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

Более подробно вопрос тюнинга mysql с помощью этого скрипта я рассматривал в разделе статьи - https://serveradmin.ru/bitrixenv-optimizacziya-nastroek-servera-pod-sajt-na-bitrix/#_Mysql

#mysql

Для нагрузочного тестирования сайта я обычно использую yandex.tank. Это эффективный, функциональный, но при этом простой в использовании и бесплатный инструмент. Хотел сначала про него заметку написать, но, как это часто бывает, получилась статья.

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

https://serveradmin.ru/primer-nagruzochnogo-testirovaniya-sajta-s-yandex-tank/

#нагрузочное_тестирование

​​А вы знали, как работает проверка интернета в Windows? Я думаю, всем знакома надпись рядом с сетевым соединением: "Подключение к интернету отсутствует" или "No Internet" в английской версии. Называется эта штука - Индикатор состояния подключения к сети или Network Connectivity Status Indicator (NCSI).

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

1️⃣ Выполняется DNS lookup адреса www.msftconnecttest.com и отправляется HTTP GET запрос по адресу https://www.msftncsi.com/ncsi.txt. Скачивается текстовый файл. Его можно и вручную проверить, если интересно посмотреть, что там. Если оба действия выполнены корректно, значит все ОК, интернет работает.

2️⃣ Выполняется DNS lookup адреса dns.msftncsi.com и проверяется ответ. Он должен быть 131.107.255.255.

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

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

Компания Mikrotik регулярно проводит мероприятия под названием MUM (MikroTik User Meeting). Из названия понятно, что это встречи пользователей микротиков. Подобные мероприятия проводятся по всему миру, в том числе и в России.

Предыдущая встреча в Москве была в сентябре 2019 года. Доклады и записи выступлений можно посмотреть по ссылке - https://mum.mikrotik.com/2019/RUM/agenda/ru. Информация там обычно очень интересная и актуальная. Можете оценить даже по заголовкам выступлений.

Я иногда просматриваю презентации всех выступлений. Они на английском языке в основном, поэтому все понятно. К примеру, информацию по NCSI из предыдущей заметки я случайно узнал из одной презентации, продемонстрированной в последнем MUM в Индонезии. Там, кстати, приведен интересный пример проверки интернета на микротиках с помощью скрипта, который реализует схожую логику с NCSI.

В комментариях к одной из заметок со мной поделились ссылкой на подборку с инструментами по нагрузочному тестированию по HTTP - https://github.com/denji/awesome-http-benchmark. Мне показался полезным список, поэтому делюсь с вами. К каждому инструменту есть ссылка на описание.

Из предложенного списка лично мне знакомы 2 инструмента - всем известный ab и siege. Последний я даже использовал когда-то давно для написания статьи со сравнением производительности php 5.4, 5.6 и 7.0. Статья уже давно не актуальна, но может кому-то будет интересно почитать, как я это делал - https://serveradmin.ru/ustanovka-i-obnovlenie-php-7-na-centos-7/ В сравнении в итоге победил с огромным отрывом статичный кэш :)

📆 Завтра, 10-го декабря в 10:00 будет очередной вебинар Zabbix, тема которого меня заинтересовала - Работа с Zabbix посредством API: ваша первая интеграция.

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

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

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

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

Ошибка при отправке была следующая:

550 5.7.0 Sender or From header address rejected: not owned by authorized user

При этом отправитель точно соответствовал пользователю, под которым авторизовывались. Написали запрос в тех. поддержку Яндекса. Ответ несколько удивил:

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

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

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

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

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

​​Мне тут посоветовали программу EssentialPIM в качестве органайзера со встроенным календарем, задачами, заметками и вот этим вот всем. Сами разработчики называют его менеджером персональной информации. Он даже пароли умеет хранить.

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

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

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

​​Вы хорошо понимаете значение метрики в Linux под названием Load Average? Традиционно считается, что она показывает загрузку системы. Кто-то думает, что это загрузка процессора. На самом деле ни то, и ни другое. Вообще, это такая таинственная метрика, что иногда мне кажется, я сам толком не понимаю, что она значит и как считается.

Например, можно зайти на сервер, увидеть LA под 100 и при этом заметить, что процессор не нагружен вообще. Более того, вообще не понятно, кто или что нагружает систему. А это у вас просто дисковая подсистема не справляется с нагрузкой.

Или еще пример. У вас на сервере LA в районе 20. Кажется, что много и надо разбираться, в чем дело. Но есть еще один факт - на сервере 36 ядер. И вроде как все в порядке, рабочая нагрузка, хоть и выше средней.

То есть метрика неоднозначная, которая сама по себе не дает понять, с чем конкретно проблема. Ко всему прочему, она еще и изменяется не линейно, а экспоненциально. То есть не верно считать, что load average за минуту включает активность только за последнюю минуту, но в основном, конечно, её.

Для однопроцессорной системы понять логику измерения load average можно с помощью картинки во вложении. Для простоты восприятия la сравнивают с транспортным потоком. Значение более 1.00 означает наличие очереди на въезде на магистраль. Размер этой очереди будет равен превышению единицы. Например, значение 1.70 показывает, что в очереди стоит 70% от числа машин, находящихся на магистрали.

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

А теперь добавьте сюда многоядерность, многопроцессорность, HyperThreading и попробуйте интерпретировать значения load average. Это нетривиальная задача. Так что надо аккуратно относиться к этой метрике.

Чтобы получше разобраться, как все это работает и что считает, рекомендую статью - https://habr.com/ru/post/260335/ Автор залез в исходники ядра, чтобы точно понять, что конкретно показывает load average.

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

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

# wget -q -O install-snoopy.sh https://github.com/a2o/snoopy/raw/install/install/install-snoopy.sh
# chmod 755 install-snoopy.sh
# ./install-snoopy.sh stable

По умолчанию, он логирует кучу всевозможных команд от системных процессов. Если вам все это не нужно, то можете оставить во такой конфиг /etc/snoopy.ini

[snoopy]
filter_chain = "only_tty"
output = file:/var/log/snoopy.log

Snoopy будет логировать только команды консоли. На всякий случай не забудьте потом настроить ротацию этого файла.

Остается только активировать snoopy и перезагрузить сервер.

# snoopy-enable
# reboot

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

#ssh

Я тут прикольный канал нашел с айтишным юмором. Он местами специфичен и не очень смешной, но в целом все равно забавно. Вот этот ролик про удаленную работу дома зашел, рекомендую :)

https://www.youtube.com/watch?v=_F-_2s6SJPU

Там еще про devops неплохие ролики.

​​Тут на дня прилег хостер TimeWeb на несколько часов. Причем так крупно прилег. Не работал ни телефон, ни NS сервера, ни сам сайт хостера. Вообще все отрубило. Он потом написал пояснения, что лег корневой маршрутизатор, а когда включили запасной, оказалось, что с ним ничего не работает 🤷🏻‍♂️

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

Пошел на hh и посмотрел вакансии Timeweb. Из технических вакансий там было только две - программист python и специалист технической поддержки Linux. Я не поленился, зашел в описание вакансии и посмотрел требования. Он должен знать linux, писать скрипты, работать в консоли, разбираться в ошибках и т.д. То есть нормальный такой линукс админ средней руки.

Как думаете, какая для него объявлена зарплата? 80-100 т.р.? Увы, нет - от 35 000 до 50 000 руб. Я, конечно, понимаю, что это не те люди, которые проектируют и поддерживают инфраструктуру. Но тем не менее. Это же очень мало. За эти деньги даже нормального эникея на винду найти затруднительно.

Зато в других вакансиях на зп не экономят:
▪ Product Manager от 180 000 руб.
▪ Product Marketing Manager до 250 000 руб.
▪ Продуктовый маркетолог от 130 000 руб.
▪ IT Sales manager/менеджер по продажам до 200 000 руб.

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

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