ServerAdmin.ru
30.7K subscribers
508 photos
45 videos
19 files
2.79K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Регистрация в РКН: https://vk.cc/cG1Urj
Download Telegram
Ещё одна реально полезная мулька в системе Windows, которую имеет смысл запомнить и применять, если у вас рабочая станция под управлением этой системы. Речь пойдёт про команду Powershell – Test-NetConnection. У неё есть простое и удобное сокращение – tnc.

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

1️⃣ Проверка работы интернета. У меня привычка проверять интернет так: ping ya.ru. На автомате это делаю. Пингую Яндекс. Вместо этого можно просто запустить tnc.

> tnc

ComputerName           : internetbeacon.msedge.net                                                                      RemoteAddress          : 13.107.4.52                                                                                    InterfaceAlias         : Беспроводная сеть                                                                              SourceAddress          : 192.168.140.82                                                                                 PingSucceeded          : True                                                                                           PingReplyDetails (RTT) : 73 ms


Запущенный без параметров он пингует домен internetbeacon.msedge.net, показывает его IP, показывает твой локальный IP и тип соединения (проводной/беспроводной), что удобно, если используешь и Ethernet и WiFi. У меня часто бывает, что не знаю, как подключен. Когда дома сажусь за рабочий стол, всегда подключаю провод, иногда забываю отключить WiFi, если сидел с ноутом на кухне или ещё где-то.

Тут и писать меньше, и информации сразу получаешь больше. В общем, удобно.

2️⃣ Проверка доступности порта, как замена telnet.

> tnc ya.ru -p 80

ComputerName     : ya.ru
RemoteAddress : 5.255.255.242
RemotePort : 443
InterfaceAlias : Беспроводная сеть
SourceAddress : 192.168.140.82
TcpTestSucceeded : True


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

Наверное можно было бы чем-то ещё быстро порты смотреть, но лично я привык использовать telnet. Его ещё и ставить сейчас надо отдельно. В базовой системе нет. С tnc получается удобнее. Буду использовать.

Tnc ещё умеет пинговать, трассировать, проверять маршруты. Много всего, но мне не показалось удобным делать это именно там. Не стал запоминать и рассказывать. Если интересно, посмотрите сами.

#windows
Please open Telegram to view this post
VIEW IN TELEGRAM
Открытый практикум DevOps by Rebrain: Разработка модели угроз продукта N

После регистрации мы отправим вам подарок! Вы сможете найти его в ответном письме.

👉 Регистрация

Время проведения:

22 апреля (вторник), 19:00 по МСК

Программа практикума:

▪️ Совместно с участниками вебинара будем анализировать возможные проблемы безопасности
▫️ На основе упрощенной архитектуры продукта выполним построение модели угроз
▪️ Обсудим результаты

Кто ведёт?

Андрей Моисеев — DevSecOps направления Cloud Native Security MTS Web Services. Спикер конференций HighLoad++, DevOps, SafeCode, HeisenBug. Занимался безопасностью с обеих сторон сертификации. Развивает процессы и инструменты DevSecOps.

Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь!

Реклама. ООО "РЕБРЕИН", ИНН: 7727409582, erid: 2W5zFJuUVur
Я периодически использую Rocket.Chat. На текущий момент это хоть и не без недостатков, но тем не менее наиболее функциональное бесплатное решение для сервера чата, установленного на своих серверах. В целом, работает нормально, но утомляет его постоянное обновление. Нет LTS версии, минимум раз в пол года, а обычно и чаще, надо обновлять сервер с ненулевой вероятностью получить проблемы.

Рассказать я хотел не о нём. Чтобы не держать постоянно запущенным клиента Rocket.Chat, решил поднять для него шлюз в Telegram, чтобы пересылал туда сообщения. Нашёл довольно популярный проект Matterbridge, который поддерживает очень много популярных чатов:

◽️Discord
◽️IRC
◽️Matrix
◽️Mattermost
◽️Microsoft Teams
◽️Nextcloud Talk
◽️Rocket.chat
◽️Slack
◽️Telegram
◽️Twitch
◽️VK
◽️WhatsApp
◽️XMPP
◽️Zulip

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

Сразу скажу, что у меня не получилось настроить передачу из рокета в телегу. Я не знаю прочему. Бился пару часов, решить не смог, бросил. Получал постоянно ошибку, с которой справиться не смог. Но в целом, судя по описанию, вещь вполне рабочая и настраивается относительно легко. Покажу свой конфиг, который с точки зрения синтаксиса сделан правильно. Можно взять его за основу. Имя файла matterbridge.toml:

[rocketchat]
  [rocketchat.myrocketchat]
  Server="https://serveradmin.rocket.chat:443"
  Login="rocketuser@gmail.com"
  Password="topsecret"
  PrefixMessagesWithNick=false
  RemoteNickFormat="[{PROTOCOL}] <{NICK}> "

[telegram]
  [telegram.mytelegram]
  Token="13992116911:BBHtEAKqxUHYt45PoWwxKfvH5TR6-vdNw"
  RemoteNickFormat="<{NICK}> "
  MessageFormat=""
  QuoteFormat="{MESSAGE} (re @{QUOTENICK}: {QUOTEMESSAGE})"
  QuoteLengthLimit=46
  IgnoreMessages="^/"

[[gateway]]
name="Serveradmin_gateway"
enable=true

  [[gateway.inout]]
  account="telegram.mytelegram"
  channel="-1001331797787"

  [[gateway.inout]]
  account="rocketchat.myrocketchat"
  channel="test-room"


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

Запускаем шлюз через простенький docker-compose.yml:

services:
 matterbridge:
  image: 42wim/matterbridge:stable
  restart: unless-stopped
  volumes:
  - ./matterbridge.toml:/etc/matterbridge/matterbridge.toml:ro


# docker compose up

Если в конфигурации будут ошибки, об этом будет информация и контейнер завершит работу.

Описание настроек для всех поддерживаемых чатов есть в wiki. Можно указывать разные направления пересылок, как в одну, так и в другую сторону, или двустороннюю пересылку. Также можно сообщения пересылать в несколько разных приёмников. Например, из группы Телеграм в несколько разных чатов. Если будете настраивать пересылку в или из Telegram, внимательно прочитайте последовательность действий в wiki. Обязательно отключить боту Privacy mode и после этого вывести его из группы и завести снова. Я пока последнее не сделал, не работало ничего в телеге.

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

🌐 Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#chat
В стандартном репозитории Debian живёт неприметная и не особо популярная программа sosreport. Создана она была, судя по названию, для служб технической поддержки. Тем не менее, полезна может быть не только им. Она создаёт архив со слепком состояния системы. Этот архив включает в себя практически всю информацию о системе:

◽️Настройки Grub
◽️Все конфигурационные файлы из раздела /etc
◽️Информация о ядре, модулях, настройках sysctl
◽️Объекты systemd
◽️Различная информация о системе: версия, точки монтирования, информация о железе, кроны, пользователи, настройки сети, установленные пакеты и т.д.
◽️Информация о пользователях, история логинов, параметры.
◽️Логи из /var/log и journalctl
◽️И многое другое, функциональность расширяется плагинами, которые можно писать самостоятельно

По сути собрана вся доступная подробная информация о системе. Ставится так:

# apt install sosreport

Использовать удобнее всего так:

# sos report --batch --all-logs

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

Архив будет иметь имя вида sosreport-337737-2025-04-15-acgbmpx.tar.xz. Его можно распаковать и смотреть прямо тут, либо передать куда-то в другое место, распаковать и запустить сгенерированную html страничку sos.html, которая лежит в директории sos_reports.

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

Ещё вариант применения - запускать по каким-то событиям мониторинга. Например, сработал триггер на загрузку процессора. Можно запустить скрипт с sosreport, который применит только плагин process и соберёт всю информацию о процессах.

# /usr/bin/sosreport --batch -o process

Sosreport выполнит и сохранит вывод следующих команд:

# ps auxwww
# lsof -b +M -n -l -c ''
# ps auxwwwm
# ps alxwww
# ps -elfL
# ps axo pid,ppid,user,group,lwp,nlwp,start_time,comm,cgroup
# ps axo flags,state,uid,pid,ppid,pgid,sid,cls,pri,addr,sz,wchan:20,lstart,tty,time,cmd

Можно и самому всё это выполнить и вывести куда-то, но через sosreport удобнее. Он к тому же может сразу положить архив куда-то по ftp или sftp с помощью ключей --upload, --upload-url, --upload-user, --upload-pass.

Я нечто подобное делала вручную и до сих пор использую. Описывал в своей статье:

Мониторинг списка запущенных процессов в Zabbix

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #мониторинг
Почтовые сервера, как правило, добавляют в заголовки писем всю цепочку адресов, которые оно прошло. Это стандартное поведение. Например, клиент с IP адресом 192.168.115.5 отправил письмо через почтовый сервер 95.185.15.218. В заголовках письма Received: будет отражена вся эта цепочка.

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

Received: from [10.8.2.2] (unknown [176.119.158.81])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by mail.rocky-linux.ru (MailServer) with ESMTPSA id 59C4811B337


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

Добавляем в основной конфиг сервера /etc/postfix/main.cf новый параметр:

header_checks = regexp:/etc/postfix/header_checks

Создаём этот файл /etc/postfix/header_checks и добавляем в моём случае такое содержимое:

/^Received:.*\[10\.8\.2\.[0-9]/   IGNORE

Создаём db файл и перечитываем конфигурацию:

# postmap header_checks
# postfix reload

Больше в Received: заголовках писем, отправленных через мой почтовый сервер не будет информации о клиентах из подсети 10.8.2.0/24.

Другие полезные материалы по Postfix:

◽️Ограничение на отправку писем в единицу времени
◽️Перенос почтового сервера
▪️ Мониторинг postfix в zabbix
▪️ Настройка маршрута отправки в зависимости от домена
▪️ Как изменить тему письма и адрес отправителя через postfix
▪️ Выбор сервера для отправки в зависимости от получателя

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#postfix
Расскажу старую историю про взлом Микротика, который я лично наблюдал. Публиковал её давно, когда на канале было в разы меньше читателей, так что большинство из тех, кто читает канал сейчас, её не видели. А история показательная и поучительная.

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

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

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

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

Это все подробности, что стали известны мне. Как произошел взлом Микротика, точно не известно. Его сразу же перенастроили и закрыли все доступы извне. Там либо пароль был простой, либо обновлений не стояло. Думаю, сломали стандартно, через уязвимость и доступ через Winbox. Он был доступен. А там время от времени всплывают уязвимости. Может и сейчас есть, но мы их пока не знаем.

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

1️⃣ Доступ к пограничным роутерам запрещать максимально сильно. Лучше снаружи вообще всё закрыть. Если всё же нужно оставить доступ, то настройте хотя бы Port knocking или доступ по спискам IP. Касательно Микротик, надо дополнительно отключить все способы удалённого подключения, которые вы не используете (FTP, SSH и т.д.).
2️⃣ Сервера изолировать от всего остального. Я не всегда следую этому правилу 😔.
3️⃣ На выходные компьютеры в офисе выключать.
4️⃣ Использовать дневной лимит на звонки через VOIP телефонию, если оператор поддерживает. Меня, кстати, не раз выручала эта история. Были инциденты. Вроде даже писал об этом. Надо будет поискать эти старые публикации и повторить. Уже и сам подзабыл подробности.
5️⃣ Всегда и везде своевременно ставить обновления.

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

#mikrotik
Please open Telegram to view this post
VIEW IN TELEGRAM
🔍 Хотите освоить регулярные выражения для системного администрирования? Погрузитесь в мир grep, sed и awk!

📅 На вебинаре вы узнаете, как читать, писать и применять регулярные выражения для реальных задач в Linux. Изучите различия между основными типами регулярных выражений (Basic, Extended, PCRE) и научитесь использовать их в системных утилитах.

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

Все участники вебинара получат скидку на курс "Administrator Linux. Professional".

👉 Для участия зарегистрируйтесь https://clck.ru/3LVkpY

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились.

Мониторинг и Логи ПРОДАКШЕН уровня — Grafana + Loki + Prometheus + Promtail
Подробное видео про настройку указанного стека от Python разработчика. Качественное видео. Даётся база, так что если вы всё это настраивать уже умеете, вряд ли узнаете что-то новое. Отдельно отмечу, что автор показывает пример простого приложения и интеграцию его логов и метрик в указанный стек.

Moodle - an incredibly powerful online training platform
Обзор open source платформы, на базе которой можно организовать обучающие онлайн курсы. Видео обзорное, будет полезно только тем, кто подбирает себе подобный инструмент. Продукт вполне стабилен и функционален.

🔥CURSOR AI - Установка, Настройка и Использование для DEVOPS
Руководство от Астахова Дениса, автора канала ADV-IT. У него почти всегда интересные видео, если они не про AWS. Всегда с удовольствием смотрю, даже если он там кулеры от своего ноута чистит. Тут он показал пример работы в редакторе с участием AI.

Установка и настройка Proxmox в 2025 году от А до Я (установка и подготовка к работе с нуля)
Простое обзорное видео. Интересно будет только тем, кто Proxmox либо вообще не ставил, либо новичок в нём и хочет что-то узнать о практике настройки других специалистов.

ОСОБЕННОСТИ УСТАНОВКИ ПРОГРАММ В СБОРКЕ САМОХОСТИНГ. 3/3 Ролик в серии PVE Samohosting Edition
Автор устанавливает различный софт на Proxmox, который считает для себя полезным. Я последнее время проматываю его ролики, потому что они очень длинные и конкретно для меня не очень актуальные. Я в основном всё, что он рассказывает, и так знаю. Но тем не менее, видео качественные, с хорошим монтажом и содержанием. Рекомендую, если вам интересна тема домашнего сервера, Proxmox и различного прикладного софта на нём для личных и семейных нужд.

DNS Failover designs for Home Lab: Pi-Hole, Unbound, Windows Server, Nebula Sync and more!
Хорошее обзорное видео про DNS Failover с примерами реализации.

Протокол TCP | Компьютерные сети 2025 - 28
Очередной обновлённый урок бесплатного курса по сетям от Созыкина Андрея.

I Rebuilt My Home Server — Quieter, Faster, and Ready for 2025
Интересное видео про сборку домашнего сервера. Хорошая картинка, монтаж и в целом интересно посмотреть на домашнюю лабораторию этого блогера.

What hardware runs in my HomeLab in 2025?
Интересный обзор домашней лабы блогера Christian Lempa. Его лабу я ещё не видел и здесь не публиковал. У него там акцент не на железо и картинки серверной, а на схемы сети и описание. Интересно посмотреть. Сама серверная выглядит более-менее приземлённо, а не как у некоторых, шик и блеск.

#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
Посмотрел небольшой ролик про удобное рабочее место человека с сидячей работой, который захотел обсудить, прокомментировать и дополнить своим опытом. Думаю, это будет полезно с учётом того, что у меня большой личный опыт по этой части.

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

▶️ Рабочее место программиста БЕЗ БОЛЕЙ В СПИНЕ // Девайсы для здоровья и продуктивности работы из дома
Пройдусь по пунктам из видео и прокомментирую их.

1️⃣ Рабочий стол со сменой положения сидя и стоя. Я за таким работал несколько лет. В целом, мне нравилось. Важно понимать одну простую вещь и дальше вы уже сами сможете выработать правильные привычки и приобрести подходящие предметы. К болям в спине, шее и других отделах чаще всего приводит перегрузка мышц. Причём она может быть как от казалось бы небольшой, но постоянной статической нагрузки (сидение в неестественной позе), так и разовой динамической (поднял что-то очень тяжёлое). Поэтому от болей в спине страдают одинаково как физически развитые и сильные люди, так и задохлики, которые тяжести вообще не поднимают.

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

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

2️⃣ Фитбол или различные стулья без спинок, чтобы держать спину ровно. Лично я эту рекомендацию не разделяю и вообще удивился, когда увидел фитбол у автора. Ранее он справедливо заметил, что к проблемам спины приводит постоянная перегрузка мышц. Но фитбол как раз и вызывает постоянную перегрузку, так как нужно без дополнительной поддержки держать спину. Мой опыт показывает, что это провальная тактика. Когда я пытался следовать рекомендации держать спину ровно, чтобы мышцы не расслаблялись и работали, неизменно получал боли в спине. Сидеть весь день с напряжённой спиной вредно. Побалансировать 15-20 минут на фитболе возможно и будет полезно, но долго сидеть на нём не рекомендую. Надо подбирать удобное кресло с поддержкой поясницы и головы, в котором ты сидишь максимально расслабленно. Посидел, поработал и пошёл размялся.

3️⃣ Источник света сбоку от рабочего места со сменой яркости в зависимости от деятельности. Я привык работать с верхним светом от люстр и светильников. Дополнительно рабочее место не подсвечиваю.

4️⃣ Автоматический корректор осанки. Небольшая электронная приблуда, которая запоминает заданное положение тела и сигнализирует, когда оно меняется. Не уверен, что это имеет смысл. Обычно человек стремится оказаться в расслабленной позе, чтобы не напрягать мышцы. Другое дело, что часто эта поза оказывается нефизиологичной, расслабляет одни мышцы (например, спину), но перегружает другие (шею), что приводит к проблемам. Лучше подобрать кресло или положение стоя где ты и расслаблен, и находишься в удобной позе.

5️⃣ Смартфон вне зоны внимания, уведомления отключены. Тоже так делаю.

6️⃣ Наушники с шумоподавлением. Постоянно использую уже много лет, рекомендую.

7️⃣ Техника Pomodoro с интервальной работой циклами по 25 минут и отдыхом. Я не пробовал так работать, не знаю, насколько удобно и эффективно.

Надеюсь, вам будет полезна эта информация. В целом в видео всё поделу рассказано. Мне понравилось.

#спина
Please open Telegram to view this post
VIEW IN TELEGRAM
23 апреля встречаемся на ну ооочень техническом митапе «Метрокластер на отечественном»

Что в программе?
▪️Разбор архитектуры и нюансов технологии метрокластера, особенностей проектирования и реализации
▪️Live-demo работы решения на отечественном оборудовании и ПО

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

В составе стенда два набора оборудования:
▪️СХД Аэродиск
▪️Сервер виртуализации Aquarius под управлением zVirt
▪️Коммутатор Qtech

и один набор ПО:
▪️СУБД Postgres Pro под синтетической нагрузкой
▪️Платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных

Между двумя площадками эмулируется расстояние 60 км. Отслеживать состояние комплекса будет система мониторинга «Пульт».

🗓 Когда?

23 апреля, 16:00

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

1️⃣ System ⇨ Users, отключаю или удаляю админа, добавляю нового пользователя с полными правами.

2️⃣ IP ⇨ Services, отключаю всё, кроме ssh и winbox. Ограничение доступа через параметр Aviable From в этом разделе не настраиваю. Предпочитаю все настройки по ограничению доступа делать в Firewall.

3️⃣ System ⇨ Logging, настраиваю отправку логов куда-то вовне, если инфраструктура предполагает такой сервис. Обычно это Syslog или ELK.

4️⃣ IP ⇨ Firewall, тут зависит от функциональности роутера, но что касается доступа извне, то закрываю либо статическим списком IP адресов, либо настраиваю Port knocking. Даже если настроен VPN, всегда страхую доступ извне каким-то ещё входом, не только по VPN.

5️⃣ Настраиваю мониторинг стандартным шаблоном Zabbix. Но сразу скажу, что не очень его люблю. Не потому, что он сделан плохо, а просто там много информации и триггеров, которые мне не нужны. Потом много спама прилетает, приходится править или отключать какие-то триггеры.

6️⃣ Знаю, что некоторые ещё отключают прямой доступ по MAC адресу в Tools ⇨ MAC Server ⇨ MAC WinBox Server, но я обычно оставляю.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#mikrotik
Достаем листочки, сейчас будет контрольная!
Задача: подобрать подходящий сервер для компании. И на этот раз без “долго и мучительно”. А просто и с комфортом благодаря нашей шпаргалке. Собрали важные рекомендации в одном доке — забирайте!

Реклама. ООО "ИТЕЛОН". ИНН 7701527528. erid: 2W5zFJDJ6wA
@itelon_servers
Как вы относитесь к работе с ночными дежурствами? Я – крайне отрицательно. Причём речь идёт не о постоянном дежурстве, когда ты сидишь в свои заранее оговорённые рабочие часы, а о ситуациях, когда ты уже отработал своё время, но тебе могут позвонить во внерабочее в случае аварии и попросить что-то сделать.

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

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

Смотрел разные видео одного блогера (Антон Павленко) по поводу работы. Он рассказывал, что тоже работал с ночными дежурствами по похожей схеме и подорвал здоровье. И теперь при поиске работы отсутствие ночных дежурств – одно из основных требований. Я полностью поддерживаю такой подход.

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

Но по факту практически всегда находятся люди, готовые работать за доплату (а некоторые и без неё) с дежурствами помимо основного графика, пока у них так же не начнутся проблемы со здоровьем. Берегите себя, своё здоровье и не соглашайтесь работать на таких условиях. Здоровье практически всегда обходится дороже заработанных денег за его счёт.

#мысли #совет
Пару лет назад у VictoriaMetrics вышел продукт, который является частью именного стека, – VictoriaLogs. Руки не доходили раньше на него посмотреть и вот дошли. Сразу скажу, что всё очень понравилось за простоту, функциональность и удобство. Покажу сразу с примерами.

Отдельно перечислю особенности VictoriaLogs:

▪️По своей сути это одиночный бинарник, который можно сконфигурировать ключами запуска, не нужен даже конфигурационный файл.
▪️В бинарнике есть всё, что надо для сбора и просмотра логов: веб интерфейс, метрики для мониторинга за системой, все типы приёмников логов.
▪️Для бэкапа достаточно скопировать директорию с данными, например, с помощью rsync. То есть вообще никаких проблем и заморочек с бэкапом.
▪️Есть плагин для datasource в Grafana, чтобы делать оттуда запросы к логам, а также готовый дашборд для визуализации метрик хранилища.
▪️Простая, короткая документация, где есть всё необходимое для запуска и настройки.

Покажу примеры сбора логов в VictoriaLogs от Journald, Syslog и Vector. Для этого подготовил небольшой docker-compose.yml с некоторыми параметрами:

services:
victoria-logs:
image: victoriametrics/victoria-logs:latest
volumes:
- ./victoria-logs-data:/victoria-logs-data
command:
- --storageDataPath=/victoria-logs-data
- --retentionPeriod=90d
- --syslog.listenAddr.tcp=:514
ports:
- 9428:9428
- 514:514
restart: always


Запускаем проект, переходим на порт 9428, чтобы убедиться в том, что всё запустилось. По умолчанию открывается страница с некоторыми ссылками на Web UI, Метрики и ключи запуска.

Отправим в VictoriaLogs логи от systemd от любого сервера, локального или внешнего. Для этого понадобится служба systemd-journal-remote. Ставим её:

# apt install systemd-journal-remote

Редактируем конфиг /etc/systemd/journal-upload.conf, добавляя один параметр:

[Upload]
URL=http://localhost:9428/insert/journald

URL, соответственно, измените, если у вас сбор логов не с локального сервера, а удалённого. Запускаем службу и проверяем, что она успешно начала отправку логов:

# systemctl start systemd-journal-upload
# systemctl status systemd-journal-upload

Идём в веб интерфейс VictoriaLogs - http://212.193.59.87:9428/select/vmui и смотрим там логи.

Переходим к Syslog. Я уже добавил параметр syslog.listenAddr.tcp=:514. Убедитесь, что указанный порт прослушивается:

# ss -tulnp | grep 514

Если у вас этот порт уже занят syslog сервером, то измените порт для VictoriaLogs. В общем-то настраивать больше ничего не надо. Теперь в любом софте, который умеет отправлять данные в формате syslog, укажите в качестве сервера IP вашего VictoriaLogs. Например, в том же Микротике: System ⇨ Logging ⇨ Actions ⇨ Add Type Remote.

Для сбора логов от всех популярных агентов, типа Filebeat, Fluentd, Vector и т.д. тоже ничего специально настраивать не надо. Делаете всё точно так же, как для отправки логов в Elasticsearch, только в качестве endpoint указываете URL от вашего сервера VictoriaLogs. Вот пример для Vector:

sinks:
vlogs:
inputs:
- nginx_access_logs
type: elasticsearch
endpoints:
- http://212.193.59.87:9428/insert/elasticsearch/
api_version: v8
compression: gzip


Решение очень понравилось своей простотой, универсальностью и скоростью настройки. Буквально за час со всем разобрался и настроил. Никаких затруднений. Отдельно нужно решать вопрос доступа к приёмнику логов и веб интерфейсу. С уровня приложения никаких решений нет. Нужно либо firewall, либо proxy использовать.

Отдельно отмечу, что те же логи syslog и journald сразу парсятся по основным полям, типа hostname, time, cmdline и т.д. Ничего для этого настраивать не надо. Сразу в веб интерфейсе можно поиск и группировку по ним делать. Получается очень функциональное решение по простоте и скорости настройки на уровне обычного syslog сервера, но с гораздо большими возможностями.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#logs #devops
Открытый практикум Linux by Rebrain: Установка Linux на свой домашний сервер

После регистрации мы отправим вам подарок! Вы сможете найти его в ответном письме.

👉 Регистрация

Время проведения:


30 апреля (среда), 20:00 по МСК

Программа практикума:

▪️Формулируем задачу
▫️Планируем способ аллокации дискового пространства
▪️А если на загрузочном диске будет только загрузчик?

Кто ведёт?

Андрей Буранов — специалист по UNIX-системам в компании VK, входит в топ 3 лучших преподавателей образовательных порталов. 10+ лет опыта работы с ОС Linux и 8+ лет опыта преподавания.

Бесплатные практикумы по DevOps, Linux, Networks и Golang от REBRAIN каждую неделю. Подключайтесь!

Реклама. ООО "РЕБРЕИН", ИНН: 7727409582, erid: 2W5zFGRpmjN
Я очень много лет использовал в Linux утилиту screen для того, чтобы в случае обрыва связи при подключении по SSH не завершалось выполнение запущенных интерактивных операций. Особенно это касается обновлений системы через apt или dnf. Типичная проблема, не считая банального обрыва связи, - подключился по VPN к серверу, запустил обновление, обновился софт для VPN, тебя отключило, обновление завершилось на середине процесса. Это может привести к проблемам (система не загрузилась из-за прерванного обновления).

В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.

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

Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.

Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.

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

Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?

#linux #terminal