ServerAdmin.ru

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

⇨ 100% способ взломать найм / Паровозик собеседований

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

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

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

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

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

Такая вот необычная идея. Видео короткое, на 11 минут, можно глянуть.

#найм

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

⇨ Файловый сервер Linux с доступом для всех
⇨ Файловый сервер Linux с простым ограничением прав к ресурсу
⇨ Файловый сервер Linux. ACL и наследование прав
Серия содержательных и полезных уроков по настройке Samba. Если не ошибаюсь, автор - один из активных комментаторов в чате. Вроде по его ссылке на канал попал.

⇨ Linux - Как Писать Скрипты - Пишем Конфигурируемый Скрипт | Linux Scripting with Config file
Пример написания bash скрипта с парсингом конфигурации из json файла. Хороший пример, который можно взять себе за образец.

🔥Checkmk, self-hosted IT monitoring for just EVERYTHING!
Очень подробный обзор мониторинга Checkmk. Мне самому эта система понравилась. Два раза с интервалом в 2 года её разворачивал и тестировал. Обратите внимание, кому нравится Nagios подобный мониторинг. Checkmk его далёкий форк, уже сильно переработанный, но концепция осталась похожей. Автор тоже впечатлился, нахваливает мониторинг. Он open source, так что можно свободно пользоваться.

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

🔥Обзор NanoKVM Full маленький да удаленький
Обзор очень прикольной миниатюрной KVM для сервера или компьютера.

⇨ Битва ИИ-кодеров: Claude 3.7 vs Deepseek v3 0324 vs OpenAi o1. Кто пишет лучший Python код?
Сравнение популярных ИИ в написании кода. Это продолжение предыдущего ролика с более масштабным тестом. Тут уже победители того теста пишут развитие приложения. Все ИИ допустили ошибки. Автор их с помощью этих же ИИ исправил и получил рабочий код. То есть в целом все выдали результат. В лоб сравнить трудно, кто лучше. Сам автор чаще всего использует Claude 3.7. Было интересно и полезно посмотреть, как автор работает с ИИ для написания кода. Они очень упрощают и ускоряют разработку.

⇨ Протокол UDP | Компьютерные сети 2025 - 26
⇨ Протокол UDP в Wireshark | Компьютерные сети 2025 - 27
Очередные обновлённые уроки хорошего бесплатного курса по сетям.

⇨ Home Lab Automation with Terraform, Ansible, and CI/CD pipelines!
Мысли автора по поводу современной автоматизации и несколько конкретных практических примеров: использование Terraform с Proxmox, Ansible для обновления Ubuntu и несколько примеров настройки CI/CD.

⇨ GitLab CI CD automation (Docker, Kubernetes, Terraform, and more…)
Подробный разбор настройки CI/CD с помощью Gitlab и его раннеров. Видео для тех, кто не знаком с темой. Даётся база.

🔥LocalSend - Airdrop for us All!
Обзор отличной программы LocalSend, которую я сам регулярно использую для передачи файлов между компьютерами и смартфонами. Отличное решение для дома и всех домашних пользователей.

⇨ New Docker Hub pull rate limits? What you have to do…
С 1-го апреля Docker Hub ввёл лимиты на использование сервиса. Я только из этого видео о них узнал. Для неаутентифицированного пользователя будет доступно только 10 pulls в час. Не скажу, что мне этого мало, но иногда, когда что-то тестируешь и разворачиваешь разные версии, запросто упрёшься в это ограничение. Как вариант, использовать аутентификацию. Тогда лимит уже 100 pulls в час. Автор рассказал, как зарегистрировать и использовать аутентификацию на практике.

#видео

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

Обратил внимание, что многие отмечают низкий уровень владения базой у соискателей. То есть человек, к примеру, разработчик, может не первый год писать код, но при этом не понимать, как работает служба DNS. Какой-нибудь новичок devops, по крайней мере так себя позиционирующий, может не знать, как работает маршрутизация или TLS шифрование. Сертификаты добавлять научился, а как всё это функционирует, не понимает.

Запомнился один вопрос, на котором по словам интервьюера, уже даже не помню, кого именно, заваливается чуть ли не половина кандидатов на должность devops инженера.

❓ Какой самый минимальный Dockerfile может быть?

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

FROM scratch

или

FROM alpine

То есть просто использование какого-то базового образа. В таком виде это уже контейнер с минимальным объёмом Dockerfile.

# echo 'from alpine' > Dockerfile
# docker build -t docker-minimal
# docker run docker-minimal

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

FROM alpine
CMD ["sh", "-c", "echo 'Hello from Container!'"]

Контейнер после запуска напишет в консоль фразу и завершится.

Написал я это всё к тому, что на рынке очень много соискателей, которые не обладают базовыми знаниями. Чтобы выделиться среди них, изучайте базу – Linux, сети, Ansible, Docker. А потом уже всё остальное. Причём вся эта база представлена очень обширно на базе бесплатных материалов.

Я некоторые базовые вещи изучал уже имея несколько лет рабочего стажа. Просто некогда было системно учиться. Уже не помню, был ли у меня Linux в институте. Администрирования вроде не было. Я вышел из института Windows администратором, а дальше всему обучился сам. Учился неправильно и несистемно, хотя пока семьи не было, было время для этого. Рекомендую его использовать с пользой. Когда появятся дети, свободного времени будет намного меньше. Лучше сразу на курсы пойти, желательно очные, и максимально сжато и ёмко изучить какую-то тему.

#совет

Утром писал о том, что нравятся текстовые логи в том числе потому, что привык их грепать. А в journalctl искать не так удобно. После этого задумался, как удобнее всего погрепать логи systemd.

Пошёл по самому простому пути и посмотрел man:

# man journalctl

Оказывается, есть ключ -g или --grep, который делает примерно то же самое, что и утилита grep. Из всего журнала выводит строки с нужным тебе выражением. Поддерживает в том числе регулярки.

Причём этот параметр там был не всегда. Я точно знаю, что раньше не было. Зашёл на сервер с Centos 7 и проверил:

# journalctl --grep ovpn
journalctl: unrecognized option '--grep'

Ключ появился в каком-то обновлении.

На самом деле очень удобно. Я решил сделать об этом заметку и не кидать сюда другие команды journalctl, чтобы не размывать тему. Просто запомните, если не знали, что с помощью journalctl можно грепать логи. А так как он ищет по всему системному логу, который может быть очень большим, это удобнее, чем смотреть по разным файлам syslog или как-то их объединять, чтобы охватить бОльший период.

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

#systemd #logs

Каждый практикующий линуксоид хотя бы раз в жизни сталкивался с OOM Killer, который просто приходит и грохает какое-нибудь приложение. Чаще всего от этого страдают СУБД, так как они обычно самые жирные по потреблению памяти.

Небольшая инструкция на тему того, что делать, если на сервере кончается память и к вам приходит OOM Killer.

1️⃣ Первым делом я бы проверил системные логи на тему работы OOM Killer. Если у вас включены текстовые логи syslog, то сделать это проще всего так:

# grep -i Killed /var/log/syslog

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

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

2️⃣ Запускаем батю-скрипт на bash, который построит красивую табличку по приоритетным целям для OOM Killer:



printf 'PID\tOOM Score\tOOM Adj\tCommand\n'
while read -r pid comm; do [ -f /proc/$pid/oom_score ] && [ $(cat /proc/$pid/oom_score) != 0 ] && printf '%d\t%d\t\t%d\t%s\n' "$pid" "$(cat /proc/$pid/oom_score)" "$(cat /proc/$pid/oom_score_adj)" "$comm"; done < <(ps -e -o pid= -o comm=) | sort -k 2nr

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

3️⃣ Теперь мы знаем, кого прибивает наш киллер, и видим в табличке OOM Score и OOM Adjustment. Чем выше первое значение, тем больше шансов, что процесс будет прибит. Если стоит 0, то не будет прибит никогда. Кто-то может подумать, что хорошо бы сделать нужному процессу Score 0, но это плохая идея. Если процесс течёт по памяти, то тупо виртуалка зависнет. Обычно так не делают. Второе значение - поправочный коэффициент для управления Score. Чем ниже этот коэффициент, в том числе с минусовыми значениями, тем меньше шансов, что OOM Killer убьёт нужный процесс.

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

4️⃣ Прежде чем менять коэффициенты, идём в свои приложения и настраиваем в них потребление памяти, чтобы она на сервере не кончалась. Настраиваем мониторинг, если его нет. Чаще всего этого будет достаточно и трогать параметры OOM Killer не придётся.

5️⃣ Если используемые вами приложения не имеют своих настроек по потреблению памяти, то настроить их и поведение OOM Killer можно с помощью Systemd. У меня была отдельная заметка по этой теме. Там ничего сложного.

6️⃣ Когда всё настроили и хотите посмотреть, как себя поведёт система, если вдруг памяти не останется, то займите её всю чем-нибудь. Например, утилитой stress. Или просто в консоли запустите:

# python3 -c 'a="a"*1073741824; input()'

Заняли 1GB памяти. Подберите своё значение, чтобы памяти не осталось (2147483648 - 2GB, 3221225472 - 3GB и т.д.). После этого можно воспользоваться магической командой, про одну из которых я недавно писал:

# echo f > /proc/sysrq-trigger

Она принудительно вызывает OOM Killer. Пример, конечно, так себе, потому что OOM Killer скорее всего грохнет запущенную команду (хотя в моих тестах первым умер systemd). Чтобы этого избежать, надо дать ей низкий Score:

# echo -16 > /proc/$(pgrep python3)/oom_adj

Ещё раз вызываем киллера и смотрим, кого он прибьёт:

# echo f > /proc/sysrq-trigger
# grep -i Killed /var/log/syslog

У меня systemd умер первым.

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

#terminal #linux

На прошлой неделе был на конференции Deckhouse Conf. Это не рекламная публикация, у меня её никто не заказывал. Моё посещение было самостоятельным. Публиковал рекламу о событии на канале и сам записался. Ничего о себе особо не указывал, оставил обычную заявку. Мне её подтвердили, так что съездил. Событие было интересное, поэтому решил поделиться с вами некоторыми новыми для себя вещами.

🟢 Конференция в первую очередь была посвящена программному продукту Deckhouse. А точнее экосистеме, которая состоит из множества компонентов. Основные - Kubernetes Platform и Virtualization Platform. Конференция в основном была посвящена Kubernetes и всему, что с ним связано.

Deckhouse Platform представлена в том числе в бесплатной редакции Community Edition с открытым исходным кодом. Развернуть и использовать можно без ограничений в рамках возможностей этой версии. Не знаю, насколько эта версия в реальности функциональна. Не нашёл табличку со сравнением Enterprise и Community. По картинкам и техническому описанию всё выглядит очень красиво. Много своих разработок, о которых технический директор продукта больше часа рассказывал.

🔥 В рамках построения своей платформы Флант полностью переписали мониторинг Prometheus на C++, чтобы снизить нагрузку, которую он создаёт. По словами разработчиков он потребляет до 10 раз меньше памяти, чем обычный Prometheus и до 3 раз эффективней, чем VictoriaMetrics. Что значит эффективней, не знаю. Проект назвали Prom++, он open source, попробовать может каждый. У него полная совместимость с оригинальным Prometheus, так что можно просто заменить один на другой и попробовать. Очень интересный продукт. Если он реально полностью совместим и в 10 раз легче, то не вижу причин его не использовать.

🔴 На замену Ingress в Kubernetes разработали новый инструмент Gateway API. Самый популярный бесплатный Ingress Controller, или один из самых популярных, Ingress Nginx не будет его поддерживать. Планов по развитию бесплатной версии нет. Вроде как там что-то новое появилось, но я не уточнял. Так что сейчас использовать бесплатный Ingress Nginx большого смысла нет.

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

Вроде всё, что можно в формате короткой заметки написать. Было интересно. Я с Kubernetes вообще не работаю, хотя и знаю его. Могу развернуть и использовать. Знаю основные сущности и принцип работы. Тут за один день получил все обновлённые знания по разным темам: какой CNI-плагин что умеет и что лучше выбрать, как cilium доставляет пакеты в обход стандартной маршрутизации linux с использованием iptables (они всё ещё актуальны в кубере), как решаются вопросы с размещением statefull приложений, из чего состоит типовой кластер Kubernetes, какие актуальны ingress контроллеры и что они умеют, и т.д.

#devops #kuber

Иногда перед запуском контейнеров в Docker Compose хочется выполнить какой-нибудь скрипт или просто набор команд. У данной задачи может быть много различных решений. Предлагаю одно из них, когда перед запуском основных контейнеров запускается какой-то малюсенький c оболочкой, например, sh.

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

Удобно для этого взять busybox, потому что там много всего есть и он маленький. Но можно обойтись и голым alpine.

services:
 init-nginx:
  image: alpine
  command: ["/bin/sh", "-c", "echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf && echo 'Compose Exec' > /html/index.html"]
  volumes:
   - nginx_config:/config
   - nginx_html:/html

 nginx:
  image: nginx:latest
  volumes:
   - nginx_config:/etc/nginx/conf.d
   - nginx_html:/usr/share/nginx/html
  ports:
   - "8080:80"
  depends_on:
   init-nginx:
    condition: service_completed_successfully

volumes:
 nginx_config:
 nginx_html:

Прямо в compose файле создали конфигурацию Nginx и добавили статическую страничку. Вместо длинной строки command можно записать более наглядно:

  entrypoint: /bin/sh
  command:
   - "-c"
   - |
    echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf
    echo 'Compose Exec' > /html/index.html

Если что-то пойдёт не так и команда не будет выполнена успешно, то второй контейнер не запустится из-за condition: service_completed_successfully.

Если надо что-то сделать на самом хосте перед запуском контейнеров, то просто через volumes подключаем директорию хоста и делаем там всё, что нам надо.

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

#docker #devops

🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024.

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin.

📌 Больше всего пересылок:
◽️Записи лекций института ИТМО (513)
◽️Сервис newreleases.io для отслеживания обновлений ПО (399)
◽️Подборка бесплатных почтовых серверов (399)

📌 Больше всего комментариев:
◽️Выбор рабочего ноутбука (1095 😱)
◽️Мысли на тему своего почтового сервера (240)
◽️Рассуждения на тему Docker (173)

📌 Больше всего реакций:
◽️Работа со службами в systemd (219)
◽️Настройка протокола HTTPv3 в веб сервере (173)
◽️Подборка бесплатных почтовых серверов (172)

📌 Больше всего просмотров:
◽️Управление WireGuard в консоли через wg-cmd (10532)
◽️Сервис newreleases.io для отслеживания обновлений ПО (9804)
◽️Очередная подборка авторских IT роликов (9314)

#топ

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

Правительство России готовится утвердить проект реформирования интернет-отрасли. В обозримом будущем будет создано государственное полукоммерческое учреждение «МУП Интернет», в которое войдут все провайдеры сети Интернет, дата-центры, хостинги, регистраторы доменов, мессенджеры, серверы электронной почты, производители телекоммуникационного оборудования, системные администраторы а также частные предприниматели, оказывающие услуги по ремонту компьютеров.
.........................................................
Новая организация будет контролировать все TCP и UDP пакеты в стране, отвечать за их целостность, а также их соответствие критериям, установленным госбезопасностью. Ей поручат организовать досмотр всех исходящих и входящих пакетов как автоматизированными средствами, так и операторами ЭВМ вручную. Системных администраторов и прочих технических специалистов смежных специальностей внесут в соответствующий реестр для привлечения к анализу внештатных всплесков сетевого трафика на магистральных каналах связи. Выезд заграницу таким специалистам будет ограничен.

⇨ Подробности по ссылке

#сатира

Когда-то давно писал про одну полезную консольную команду, которой иногда пользуюсь. Она принудительно и моментально отправляет сервер с Linux в перезагрузку. Эффект аналогичен нажатию на кнопку reset:

# echo b > /proc/sysrq-trigger

Разница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.

# type reboot
reboot is /usr/sbin/reboot

# type shutdown
shutdown is /usr/sbin/shutdown

Хотя на самом деле это уже давно не бинарники, а только ссылки на /bin/systemctl, но это не отменяет того, что последний тем не менее исполняемый файл. Он должен существовать, а во время выполнения пошуршать диском. У него куча ссылок на таргеты и службы systemd.

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

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

Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.

Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.

Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:

# cat /proc/sys/kernel/sysrq

◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции

На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.

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

Если всё же интересно, то весь список команд можно запросить у ядра:

# echo h > /proc/sysrq-trigger | less /var/log/kern.log

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

#linux #terminal

На прошлой неделе делал подборку инструментов для логирования действий пользователя в консоли. В комментариях справедливо заметили, что всё это умеет делать практически штатный инструмент - auditd. Его всегда рекомендуют включать и настраивать в контексте вопросов безопасности. Например, в руководствах CIS (#cis) о нём всегда упоминают.

Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.

Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.

Устанавливаем auditd:

# apt install auditd

Создаём правило, добавив в файл /etc/audit/rules.d/audit.rules несколько новых строк:

-a always,exit -F arch=b64 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b32 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution

-a always,exit -F arch=b64 -F auid!=-1 -S execve -S execveat -k generic_command_execution                                             
-a always,exit -F arch=b32 -F auid!=-1 -S execve -S execveat -k generic_command_execution

По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.

Применяем правила:

# auditctl -R /etc/audit/rules.d/audit.rules

Теперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:

# ausearch -k root_auth_command_execution

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

◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.

Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.

Может помочь команда, которая выведет список всех выполненных исполняемых файлов:

# aureport -x -i

Также неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.

По умолчанию auditd хранит логи в /var/log/audit/audit.log. Читать их или грепать напрямую неудобно. Там всё сплошным потоком, без дат. Можно через ausearch или aureport выгружать их в файлы:

# aureport -x -i > /var/log/audit_exec_summary.log

Либо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле /etc/audit/plugins.d/syslog.conf. С локального можно на внешний пересылать.

Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.

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

#auditd #ssh #security

🎓 Известный титулованный питерский институт ИТМО, который готовит ИТ специалистов, выкладывает в сеть много обучающего материала. Точнее не он, а его лекторы на неофициальных каналах. Я как минимум 2 нашёл, где выложены полноценные академические лекции для студентов. К некоторым даже конспекты есть.

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

Я нашёл как минимум 2 насыщенных лекциями преподавателей ИТМО youtube канала. Сразу дам ссылки на конкретные курсы лекций:

Записи курса компьютерных сетей, который читается для студентов третьего года обучения программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в шестом семестре.
Лектор: Сергей Мельников
▶️ [s6 | 2023] Компьютерные сети
✍️ Конспект лекций

Лекции Артема Береснева по курсу Компьютерные сети в университете ИТМО
▶️ Лекции по курсу Компьютерные сети

Живая, аудиторная запись. Звук не очень, но атмосферу передает.
▶️ Администрирование Windows Server

Полный курс из 15-ти лекций по администрированию GNU/Linux
▶️ Администрирование в ОС GNU/Linux

Записи лекций по курсу «Разработка на Go», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в качестве курса по выбору.
Лектор: Панасюк И.А.
▶️ [SC | 2024] Разработка на Go

Записи лекций по курсу «Операционные системы», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Маятин
▶️ [s3 | 2024] Операционные системы (light)

Записи лекций по курсу «Операционные системы (hard)», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Романовский
▶️ [s3 | 2024] Операционные системы (hard) - лекции

Записи лекций по курсу «Операционные системы (hard) — практики», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: Никита Сычев
▶️ Операционные системы (hard) - практики

Стало интересно, что это вообще за институт. Посмотрел образовательные программы и программы обучения. Всё самое современное, типа DevOps в разработке и управлении информационными системами. Вспоминаю, как я учился в начале 2000-х и что тогда проходили в вузах. По IT вообще ничего актуального не было. Все в основном учились где и как попало, а потом сами всё изучали на работе. Я учился в МИРЭА на бюджете и потом в РосНОУ платно. Как хорошо, что я ушёл из МИРЭА. Там вообще ничего востребованного не преподавали в то время. В РосНОУ хоть что-то похожее на актуальные знания были: программирование, в том числе C++, Java, системное администрирование, операционные системы. Институт был новый, более-менее современный на тот момент.

Другое дело, что в том же ИТМО всё в основном платное. В среднем 450-550 т.р. за год. Дорого, конечно, но не запредельно, если у тебя мало детей. А если как у меня 4-ро, то денег для всех на такое обучение скорее всего не будет. Пока не знаю, как буду выкручиваться.

Мне интересно, есть примеры людей, которые не получили высшее образование, но учились по подобным лекциям в интернете? Они вообще хоть кем-нибудь изучаются или выкладываются в основном чтобы были?

#обучение

▶️ ИНЖЕНЕР "ПРО РУТИНУ"

Специфичный юмор, заточенный под позднесоветскую ностальгию для тех, кому 40+, а может и все 50+. Сразу скажу, что у этого автора больше ничего не нравится. А этот ролик как-то запал. Не знаю почему. Мне он показался очень близким к современному крупному корпоративному IT с его удалёнкой, зачастую бессмысленной рутиной и кластерами Кубернетис, которые всё внедряют и внедряют.

"Везде все одинаковые. Всё вокруг одно и то же. Одно и то же по кругу, как на стадионе."
"Я уже неделю на работу хожу и ни разу туда не пришёл!"
"Мы изобрели какой-то провод странный, зачем он нужен? 5 лет работали над ним."

К сожалению, не обладаю хорошими навыками монтажа видео. В конце так и просится переделка в стиле:
"Мы внедрили кластер Kubernetes. Зачем он нужен? 5 лет работали над ним, монолит пилили."
И потом вот это видео в продолжении: ❓ А у вас есть Кубернетис?

#юмор

Продолжу вчерашнюю тему со снепшотами LVM, так как в публикации не хватило лимита по объёму. Работать со снепшотами можно как с обычными разделами. Его можно монтировать, сохранять в образ и передавать куда-то по сети. Либо без сохранения сразу по сети передать напрямую.

Допустим, вы сделали снепшот /dev/vgroup/root_snap. Можете его сразу передать на другой сервер:

# dd if=/dev/vgroup/root_snap | ssh root@10.20.1.36 "dd of=vgroup-root.img"

Получили живой бэкап. Его можно, к примеру, подмонтировать и посмотреть данные:

# mount vgroup-root.img /mnt

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

# dd if=/dev/vgroup/root_snap of=/mnt/backup/vgroup-root.img

Из этого снимка можно восстановить систему полностью. Для этого нужен будет какой-то загрузочный диск c Linux. Нужно будет восстановить данные из образа на какой-то диск и отдельно установить на него загрузчик grub. То есть это простой и гарантированный способ получить целостную копию работающей системы и спокойно передать её куда-то по сети.

☝️ Отмечу ещё раз отдельно, что снепшоты LVM – вполне стабильная и рабочая функциональность. Это не какой-то хак, трюк, костыль, который работает на свой страх и риск. Можно без особых опасений её использовать, главное понимать нюансы работы снепшотов. Они немного снижают производительность, их нельзя оставлять надолго, так как они начинают занимать место в VG, которое может кончиться. Могут возникнуть проблемы.

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

Вот ещё одно коротенькое руководство, как можно с помощью снепшотов безопасно обновить систему, которая установлена в VG vgroup на LV root.

Переименовываем текущий LV и создаём вместо него snapshot с таким же названием:

# lvrename vgroup root root-old
# lvcreate -n root -s /dev/vgroup/root-old -L 9G
# reboot

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

 # lvrename vgroup root root-new
 # lvrename vgroup root-old root

Если изменения вам подошли и вы готовы их принять, то сливаем снепшот нового состояния с текущем корнем:

# lvconvert --merge /dev/vgroup/root-new
# reboot

После перезагрузки по lvs смотрим, когда слияние закончится и перезагружаемся ещё раз:

# lvs
# reboot

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

Если же вам изменения не нужны, то просто удаляем снепшот:

# lvremove /dev/vgroup/root-new
# reboot

Инструкция 100% рабочая. Проверял несколько раз и на прошлой заметке, и на этой. Снепшоты, когда вся система вместе с /boot разделом на LVM работают без проблем.

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

#lvm

Я уже ранее делал заметку насчёт LVM, где пояснил, что чаще всего виртуалки делаю с LVM. Это добавляет некоторые удобства, которые по сути ничего не стоят. То есть не вижу смысла их не использовать. Хоть и не часто, но LVM может сильно выручить.

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

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

Снепшоты могут выручить, если у вас хранилище гипервизора без их поддержки, что не так уж редко бывает. Например, хранилище в Proxmox типа LVM, не LVMThin, снепшоты не поддерживает. Также актуально, если вы арендуете VPS без доступа к гипервизору. Обычно там можно только расширить диск, что достаточно для использования снепшотов.

Для того, чтобы использовать снепшоты LVM никаких настроек делать не надо. Главное условие – в VG должно быть свободное место. Если его нет, то надо его где-то найти. Покажу на конкретном примере.

Беру виртуалку, которая полностью установлена на LVM, что я чаще всего и делаю. На VG свободного места нет. Проверяем это:

# pvs

Добавляем в виртуальную машину ещё один диск, либо расширяем существующий. Принципиальной разницы нет. У вас либо появится новый диск, либо новый раздел на текущем диске. Их и используем для расширения VG. Я добавил диск sdb размером 10G. Расширяю им VG:

# vgextend vgroup /dev/sdb

По хорошему лучше сначала сделать раздел sdb1, и расширить уже им, но для краткости опускаю этот момент.

# pvs
PV      VG   Fmt Attr PSize   PFree  
/dev/sda1 vgroup lvm2 a-- <20.00g   0 
/dev/sdb  vgroup lvm2 a-- <10.00g <10.00g

Теперь могу создать снепшот корня. Делаю ему размер 9G:

# lvcreate -L 9G -s -n root_snap /dev/vgroup/root

Смотрю, что получилось:

# lvs

По сути появился ещё один LV. С ним можно работать, как с обычным разделом. Например, подмонтировать его:

# mount /dev/vgroup/root_snap /mnt

Увидим в /mnt состояние системы на момент создания снепшота.

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

# apt update && apt upgrade -y && reboot

После перезагрузки посмотрим на статус LV и на версию загруженного ядра:

# lvs
root    vgroup owi-aos--- <20.00g                           
root_snap vgroup swi-a-s---  9.00g   root  15.85   

# uname -a

Допустим, что-то пошло не так и нам надо откатиться на состояние до обновления. Восстанавливаем снепшот:

# lvconvert --merge /dev/vgroup/root_snap

Видим ошибку:

Delaying merge since origin is open.
Merging of snapshot vgroup/root_snap will occur on next activation of vgroup/root.

Это нормально, так как для восстановления нужно размонтировать LV. Наживую восстановить снепшот нельзя. Восстановление будет запущено после перезагрузки, во время активации LV. Текущий корневой LV будет помечен как (O)rigin with merging snapshot, это видно в lvs:

# lvs
root vgroup Owi-aos--- <20.00g

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

# uname -a

Для несистемного раздела всё выполняется без перезагрузок. В случае, если всё ОК и снепшот не пригодился, удаляем его:

# lvremove /dev/vgroup/root_snap

💥 Обязательно удалите снепшот после того, как убедитесь, что он не нужен.

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

#lvm

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

◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.

◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.

◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду history 1, которая показывает последнюю введённую команду и куда-то записываем её: в файл или syslog. Решение максимально простое и понятное, но со своими нюансами. Надо промты менять и следить, чтобы обратно не менялись.

◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.

◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.

◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.

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

#ssh #logs #подборка

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

Стандартный promt чаще всего user@host-name:current-directory# . С помощью сайта bash-prompt-generator.org можете легко его изменить, просто собрав как в конструкторе те элементы, что вам нужны. И тут же на сайте видно, как будет выглядеть приглашение командной строки.

Из того, что обычно добавляют, отмечу следующие вещи:

- отображение IP адреса сервера
- подсветка промта разными цветами на разных серверах
- подсветка промта красным цветом при работе от root
- вывод времени

Немного поигрался в конструкторе и собрал следующий промт:

[username@hostname.com|192.168.1.100] 20:32:03 (~/bin)$ █

PROMPT_COMMAND='PS1_CMD1=$(ip route get 1.1.1.1 | awk -F"src " '"'"'NR == 1{ split($2, a," ");print a[1]}'"'"')'; PS1='[\[\e[38;5;196m\]\u\[\e[0m\]@\H|${PS1_CMD1}] \t (\[\e[4m\]\w\[\e[0m\])\$ '

Теперь эту команду надо добавить в ~/.bashrc и применить изменения:

# source ~/.bashrc

В данном случае мы настроили promt у конкретного пользователя. Я цвет имени пользователя сделал красным, потому что это root. Для остальных пользователей promt можно вообще не менять, либо задать индивидуальный. Общие же настройки для всех пользователей живут в системном файле /etc/bash.bashrc.

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

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

#terminal #bash

Для просмотра дерева запущенных процессов в системе Linux можно использовать разные способы. Я давно знаю 2 из них и постоянно применяю:

1️⃣ В утилите htop, которую я всегда ставлю на сервера под своим управлением, есть режим древовидного отображения процессов. Для этого надо нажать клавишу t (tree view). Это удобно, когда в моменте надо что-то быстро посмотреть. Если процессов много и надо вдумчиво изучить список, то в htop не очень удобно из-за того, что интерфейс интерактивный.

2️⃣ Консольная команда ps axf, а если список большой то она же, но направленная в текстовый файл ps axf > ~/ptree.txt. Там уже можно более спокойно и осмысленно всё посмотреть.

На днях просматривал репозиторий the-art-of-command-line. Там в основном информация для новичков. Большую часть я и так знаю, но нашёл для себя кое-что новое.

3️⃣ Есть программа pstree в составе пакета psmisc. Он во многих системах есть в базовом наборе системных утилит, либо ставится из стандартных репозиториев. С помощью pstree можно вывести древовидный список процессов в наглядном виде. Нагляднее, чем у ps.

# pstree -p

Есть ещё пара полезных ключей:

-t – показывает полные имена подпроцессов. Для некоторых служб показывает чуть больше информации.
-n – сортировка по pid, а не имени.
-С age – раскраска имён процессов по возрасту. Процессы новее 60 секунд выводятся зелёными, новее часа – жёлтыми, а остальные красными.

Посмотрел все остальные ключи, полезными их не нашёл.

Берите на вооружение, если как и я не знали о существовании этой утилиты.

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

#linux #terminal