Admin Guides | Сисадмин

Когда IT дает сбой, бизнес не должен останавливаться Не работает 1С, недоступны документы, сотрудники не могут выполнять свои задачи. Даже несколько часов простоя могут обернуться потерями для компании. Причины могут быть разными, но для руководителя главное — как быстро компания сможет вернуться к нормальной работе. Itentis Cloud — безопасная облачная среда для стабильной работы бизнеса. Мы предлагаем аренду облачных ресурсов на базе компактной инфраструктуры с контролируемой нагрузкой. Здесь можно разместить 1С, CRM и другие корпоративные системы без покупки собственного оборудования. А если вы не хотите погружаться в технические вопросы, команда Itentis возьмет вашу IT-инфраструктуру на комплексное обслуживание. Ищете надежную площадку для корпоративных систем? Обращайтесь в Itentis Cloud — подберем решение под ваши задачи. ☁️ Зарабатывайте вместе с Itentis Cloud! Один из наших партнеров, системный администратор, начал с переноса нескольких клиентов в облако, а теперь получает 70–100 тыс. руб. ежемесячно на партнерской комиссии. Подключайте и своих клиентов к Itentis Cloud, получайте процент от их расходов на инфраструктуру и увеличивайте доход. Первые 14 дней использования облака бесплатно. Подробнее — в партнерской программе

bio splitting: почему Linux дробит запросы к диску Приложение отправляет большой запрос на чтение, но до накопителя он может дойти несколькими отдельными операциями. И дело не обязательно в файловой системе. Сам block layer умеет разбивать I/O, если исходный запрос не укладывается в ограничения устройства. ⏺Откуда берутся ограничения В Linux операции чтения и записи описываются структурами bio. Внутри находятся адреса данных, размер и информация о том, с какими секторами нужно работать. Но устройство не обязано принимать запрос любого размера. Посмотреть его ограничения можно через sysfs:

cat /sys/block/nvme0n1/queue/max_sectors_kb
cat /sys/block/nvme0n1/queue/max_segments
cat /sys/block/nvme0n1/queue/max_segment_size

Первый параметр ограничивает объём данных в запросе, второй - количество сегментов, третий - размер отдельного сегмента. Например, если допустимый размер запроса составляет 128 КБ, один bio на 512 КБ нельзя просто передать устройству целиком. ⏺Что происходит при splitting Block layer может разделить исходный bio на несколько частей:

Исходный bio: 512 KB
        |
        v
   Block layer
        |
        +-- bio 128 KB
        +-- bio 128 KB
        +-- bio 128 KB
        +-- bio 128 KB

Каждая часть получает свой диапазон секторов и ссылки на соответствующие участки памяти. При этом данные не обязательно копируются. Разделение касается прежде всего описания I/O и его границ. ⏺Почему размер - не единственная причина Даже небольшой запрос может не пройти ограничения устройства. Например, если данные представлены слишком большим количеством сегментов памяти или запрос пересекает границу, которую контроллер не умеет обрабатывать за одну операцию. Дополнительные ограничения могут появляться и в стеке Device Mapper или RAID. Поэтому один запрос приложения, один bio и одна команда накопителю - далеко не всегда одно и то же.

⚡️ В сети начали массово сливать IT-курсы и книги известных онлайн школ Вот отсортированная база с тонной материала (постепенно пополняется): (363 видео, 87 книги) — Python (117 видео, 53 книги) — ВАЙБКОД (174 видео, 91 книги) — DevOps (415 видео, 68 книги) — Frontend (137 видео, 93 книги) — DS/ML (143 видео, 33 книги) — ИБ/Хакинг (352 видео, 89 книги) — С/С++/C (343 видео, 87 книги) — Java/QA (176 видео, 32 книги) — Git/Linux (167 видео, 53 книги) — PHP/1С (227 видео, 83 книги) — SQL/БД 114 видео, 77 книги) — Сисадмин (107 видео, 43 книги) — BA/SA (181 видео, 32 книги) — Go/Rust (167 видео, 43 книги) — Kotlin/Swift (112 видео, 24 книги) — Flutter (113 видео, 82 книги) — GameDev (183 видео, 37 книги) — Дизайн (136 видео, 33 книги) — PM/HR Скачивать ничего не нужно — все выложили в Telegram

💬 Вопрос на собеседовании для сисадмина Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Почему Docker-контейнер может занимать намного больше места, чем размер его образа? ✅Ответ: Причина может быть в механизме OverlayFS, который Docker использует для организации файловой системы контейнера. Образ состоит из слоёв, доступных только для чтения. При запуске контейнера поверх них создаётся отдельный записываемый слой. Когда приложение пытается изменить файл из образа, срабатывает механизм copy-up: файл копируется в записываемый слой, и изменения происходят уже там. Посмотреть использование диска Docker можно командой:

docker system df -v

А размер записываемого слоя конкретного контейнера:

docker inspect --size <container_id>

🔴В 2025 году Россияне заработали 5,3 млрд рублей на арбитраже криптовалют По данным Минфин 32% граждан покинули своё место работы поскольку уже в первый месяц смогли заработать 250 000 рублей, а через 2-3 месяца с легкостью вышли на семизначные числа. Самое смешное, что лишь 8% россиян что-то слышали об этой профессии хотя все инструкции бесплатно лежат на канале Арбитраж Криптовалют Там объясняют, как имея телефон и доступ в интернет заработать свои первые $3000. Причём разжёвывают так доступно, что поймёт даже ребенок. Кстати, на канале сегодня вышла новая рабочая связка! Ссылка для входа — https://t.me/+vI7iluNHD9YwMmRi

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ Проект «Terminal» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков: • Практические курсы и задания • Книги и статьи известных авторов • Полезные инструменты и ресурсы • IT-новости и инсайды Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, Git, Linux, QA, Java, Vibe-coding, InfoSec и др. ⌨️ подписаться

kmalloc_obj: зачем Linux типизированное выделение памяти В коде ядра легко допустить неприятную ошибку: выделить память под структуру, но случайно указать неправильный размер. Компилятор может ничего не заметить, а проблема проявится уже во время работы. Например, когда код начнёт записывать данные за пределы выделенного участка. ⏺Как это работает с kmalloc Обычно память под структуру выделяют так:

struct my_device *dev;

dev = kmalloc(sizeof(*dev), GFP_KERNEL);

Здесь всё правильно. Но kmalloc() получает только размер в байтах. Какой именно объект будет храниться в памяти, allocator не знает. Если разработчик ошибётся в sizeof(), можно получить слишком маленький буфер. ⏺Что меняет kmalloc_obj Идея типизированного выделения - связать размер памяти непосредственно с типом объекта. Вместо ручного указания размера используется выражение, по которому компилятор определяет нужный тип:

dev = kmalloc_obj(*dev, GFP_KERNEL);

Для массива предусмотрен аналогичный подход:

dev = kmalloc_objs(*dev, 16, GFP_KERNEL);

Так меньше шансов перепутать размер структуры или неправильно рассчитать память под несколько элементов. ⏺А что с защитой памяти Важно понимать: типизированное выделение не превращает C в безопасный язык и не устраняет все ошибки работы с указателями. Но оно убирает один источник проблем - несоответствие размера выделяемой памяти объекту, для которого она предназначена. Особенно это полезно в kernel-коде, где подобная ошибка может закончиться повреждением памяти, а не просто падением одного приложения.

Переход с VMware: как не начать с нуля и получить больше возможностей Смена платформы виртуализации поднимает практические вопросы: как изменятся существующие процессы, будет ли возможна автоматизация, останутся ли Terraform и Ansible в рабочем контуре и можно ли использовать декларативное управление наравне с управлением через веб-интерфейс. 16 октября на вебинаре узнаете о типовых сценариях и задачах эксплуатации классической виртуализации и увидите, как их можно автоматизировать в Deckhouse Platform.

В программе: — сценарии классической виртуализации и сочетание веб-интерфейса с декларативным управлением; — подготовка «золотых образов» и первичная настройка ВМ; — развёртывание через Terraform, манифесты, шаблонизатор и GitOps; — управление конфигурацией ВМ с помощью Ansible.

🎁 Бонусы: розыгрыш мерча и обучения.

Зарегистрироваться

16 октября, 12:00

Два антивируса в Windows могут начать бороться друг с другом Инженер Microsoft Рэймонд Чен рассказал о сбое, причину которого корпоративная поддержка долго не могла найти. Виновниками оказались два антивируса в одной системе.

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

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

⚡️️️️️️ Не работает корпоративная связь? Труконф поможет восстановить коммуникации Если из-за сбоев облачной инфраструктуры ваша компания потеряла доступ к корпоративному мессенджеру, звонкам или онлайн-встречам, Труконф готов безвозмездно помочь с запуском децентрализованной системы коммуникаций. TrueConf Server можно развернуть в сети вашей организации, чтобы не зависеть от внешних облачных сервисов. Система быстро обеспечит ваших сотрудников мессенджером, аудио- и видеозвонками, онлайн-встречами и другими инструментами — просто обратитесь к нам любым удобным способом. Вы также можете самостоятельно установить бесплатную версию мессенджера на 300 пользователей на своем ПК или сервере без обращения к нам (или более — по запросу). ➡️ Нужна помощь

dm-dust: как устроить диску bad sectors без поломки Представьте: диск исправен, SMART ничего подозрительного не показывает, но чтение определённого сектора внезапно возвращает Input/output error. В Linux такое можно воспроизвести специально. Для этого есть dm-dust - target Device Mapper, который имитирует повреждённые блоки и позволяет проверить, как файловая система или приложение переживёт ошибку чтения. 1️⃣Создаём тестовый диск Чтобы не рисковать настоящим накопителем, используем файл и loop-устройство:

truncate -s 64M /tmp/dust.img
LOOP=$(sudo losetup --find --show /tmp/dust.img)
SECTORS=$(sudo blockdev --getsz "$LOOP")

echo "0 $SECTORS dust $LOOP 0 512" |
  sudo dmsetup create dusttest

Теперь /dev/mapper/dusttest выглядит как обычное блочное устройство. Пока все операции проходят без искусственных ошибок. 2️⃣ Ломаем конкретный блок Допустим, хотим сделать нечитаемым блок №64:

sudo dmsetup message dusttest 0 addbadblock 64
sudo dmsetup message dusttest 0 enable

Пробуем прочитать его напрямую:

sudo dd if=/dev/mapper/dusttest \
  of=/dev/null bs=512 count=1 skip=64 \
  iflag=direct

Вместо данных получим:

dd: error reading '/dev/mapper/dusttest':
Input/output error

Причём ошибка возникает в Device Mapper. Сам backing storage остаётся исправным. 3️⃣ Проверяем восстановление У dm-dust есть интересная особенность: запись в повреждённый блок проходит успешно и удаляет его из списка bad blocks. Так имитируется поведение диска, который переназначил проблемный сектор. Для проверки файловой системы можно сначала создать её на /dev/mapper/dusttest, записать тестовые файлы, а затем включить ошибки на выбранных блоках данных или метаданных. Дальше смотрим:

sudo dmesg -w
sudo dmsetup status dusttest

Интересно, вернёт ли приложение EIO, продолжит ли файловая система работать и не перейдёт ли она в read-only режим. Конкретная реакция зависит от файловой системы и того, какой блок оказался недоступен. После эксперимента:

sudo dmsetup message dusttest 0 disable
sudo dmsetup message dusttest 0 clearbadblocks
sudo dmsetup remove dusttest
sudo losetup -d "$LOOP"

erid: 2W5zFG6b481 Пока одни облака лежат, другие работают. Бизнесу нужен сайт без простоев и быстрые серверы без перерывов на обед. Клиенты должны пользоваться продуктом даже ночью. В DLine Media ставка на доступность и стабильность: — VPS/VDS от 210 ₽ в месяц; — выделенные серверы от 3 930 ₽ в месяц; — colocation для вашего оборудования; — скидки до 30%; — собственный ЦОД. DLine Media — инфраструктура без переплаты. 👉 Забронировать ресурсы

Как настроить ротацию паролей для системных пользователей Ротация паролей на Linux управляется через PAM и утилиту chage. Политика задаётся либо глобально через /etc/login.defs, либо точечно для каждого пользователя. Глобальная политика /etc/login.defs применяется ко всем новым пользователям при создании:

# /etc/login.defs
PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   14

PASS_MAX_DAYS: через сколько дней пароль истекает. PASS_MIN_DAYS: минимум дней до смены, защищает от немедленной смены обратно на старый. PASS_WARN_AGE: за сколько дней предупреждать пользователя. Для существующих пользователей login.defs не применяется задним числом, только chage:

chage -M 90 -m 1 -W 14 username

Смотрим текущую политику пользователя

chage -l username
passwd -S username

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

for user in $(awk -F: '$3 >= 1000 && $3 != 65534 {print $1}' /etc/passwd); do
  chage -M 90 -W 14 $user
  echo "$user: $(chage -l $user | grep 'Password expires')"
done

Фильтруем по UID >= 1000 чтобы не трогать системных пользователей. Принудительная смена при следующем входе Если нужно сбросить пароль конкретному пользователю:

chage -d 0 username

При следующем SSH-входе система потребует сменить пароль до того как пустит в систему.

Диагностика сетей Docker за пару минут Контейнеры перестали «видеть» друг друга или интернет? Обычно виноваты bridge, IP или iptables. Быстрая проверка помогает локализовать проблему. 1️⃣Что у нас вообще есть?

docker network ls

Смотрим все сети и их типы. Первая проверка - сеть существует и активна ли она. 2️⃣Разбираемся с конкретной сетью

docker network inspect <name>

Проверяем настройки bridge, IP-адреса и какие контейнеры к ней подключены. Часто именно здесь всплывает конфликт IP. 3️⃣Какой IP у контейнера?

docker exec -it <container> ip addr

Быстрая проверка: назначен ли контейнеру правильный IP и подключен ли к нужной сети. 4️⃣Контейнеры видят друг друга?

docker exec -it <container> ping <ip>

Если пинги не проходят - смотрим bridge и firewall. 5️⃣Правила iptables для Docker

iptables -L -n -v | grep DOCKER

Иногда проблема не в Docker, а в том, что iptables заблокировал трафик.

💬 Вопрос на собеседовании для DevOps-инженера Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Что такое CFS bandwidth control и как оно управляет CPU-ресурсами в Linux? ✅Ответ: CFS bandwidth control — это механизм планировщика Completely Fair Scheduler (CFS) для ограничения доли процессорного времени, доступного группе задач (cgroup). Он позволяет задавать квоты CPU для контейнеров и процессов, предотвращая «захват» CPU одним нагрузочным процессом. Как это работает: • Задаётся период (cpu.cfs_period_us) и квота (cpu.cfs_quota_us). • Планировщик распределяет CPU среди процессов так, чтобы группа не превышала выделенную квоту за период. • Если квота исчерпана, процессы группы ждут до следующего периода, а остальные задачи продолжают выполняться.

💻Практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ» 📹 15 октября в 11:00 Мск за 90 минут на практике построим реальную стратегию и разберём: 🔹 как определить RPO и RTO для критичных сервисов; 🔹 как защитить бэкапы от шифровальщика; 🔹 как учесть зависимости систем и ресурсы для восстановления; 🔹 как каналы связи влияют на скорость бэкапа и восстановления; 🔹 когда достаточно обычных бэкапов, а когда нужны репликация, Hardened Repository и DRaaS; 🔹 как подготовить план аварийного восстановления и протестировать его. 🧑‍💻 Каждый участник выберет свой критичный сервис и проработает его 🎁 Всем прошедшим практикум передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления: — Матрица систем и зависимостей — Таблица определения и согласования RPO / RTO — Технический runbook аварийного восстановления — Отчёт о тестовом восстановлении ИТ-сервиса — Карта готовности одного критичного сервиса к восстановлению — Рабочая тетрадь «Стратегия восстановления данных и ИТ-сервисов» 👉 Приходите, будет полезно. Регистрация тут

dm-delay: как Linux специально замедляет диск Device Mapper умеет не только объединять и шифровать устройства. У него есть target dm-delay, который специально добавляет задержку к I/O. Это удобно для тестов: можно проверить, как система, файловая система или приложение ведут себя с медленным storage, не меняя реальный диск. ⏺Создаём задержку Например, добавим 100 мс к чтению и 200 мс к записи:

echo "0 $(blockdev --getsz /dev/nvme0n1) delay /dev/nvme0n1 0 100 /dev/nvme0n1 0 200" \
  | dmsetup create slowdisk

Проверяем:

dmsetup table slowdisk
lsblk

Теперь /dev/mapper/slowdisk обращается к тому же storage, но I/O проходит через dm-delay. ⏺Где возникает задержка Схематично путь выглядит так:

application
    ↓
filesystem
    ↓
block layer
    ↓
dm-delay
    ↓
NVMe / SSD

dm-delay получает bio, удерживает его заданное время и только потом отправляет дальше. Важно: физический диск при этом ничего не «замедляет». Дополнительная latency появляется именно в Device Mapper. ⏺Зачем это нужно Например, можно воспроизвести ситуацию:

обычный SSD
   ↓
latency ~ сотни μs

dm-delay
   ↓
latency ~ сотни ms

И посмотреть, что произойдёт с timeout’ами, очередями I/O, fsync, RAID или приложением. После теста mapping удаляется:

dmsetup remove slowdisk