LinuxCamp | DevOps

📘 На Stepik вышел курс — «DevOps» Хотите разобраться, что такое DevOps и как он применяется в реальных проектах? В этом курсе — полный набор базовых инструментов и практик, чтобы уверенно стартовать. • От Linux и Bash до Git, Docker и Kubernetes • Автоматизация инфраструктуры с Terraform и Ansible • CI/CD пайплайны: настройка тестирования и деплоя • Мониторинг и логирование: Prometheus, Grafana, алертинг • Практика на реальных кейсах и задания прямо в браузере 🎓 Сертификат — добавьте в резюме или LinkedIn 🚀 Освойте DevOps на практике без сложного входа и дорогих программ. Начните уже сегодня со скидкой 25% в течение 48 часов 👉 Пройти курс на Stepik

atime, relatime, noatime: зачем это вообще нужно Что такое atime atime - это время последнего доступа к файлу. Каждое чтение файла обновляет метаданные. Даже обычный cat, grep или ls может вызвать запись на диск. Проверить режим монтирования можно так:

mount | grep atime

Почему atime это проблема Обновление atime - дополнительная запись. Исторически atime был включён всегда, и это реально било по производительности. Компромисс - relatime relatime обновляет atime не всегда, а только если atime старше mtime или ctime, или прошло больше 24 часов Это дефолт почти во всех современных дистрибутивах. Пример:

UUID=... / ext4 defaults,relatime 0 1

В большинстве случаев это лучший баланс между корректностью и производительностью. noatime - максимум производительности noatime полностью отключает обновление atime. Используется для: /var, /data, базы данных, кэшей, логов

UUID=... /data ext4 defaults,noatime 0 2

Когда atime все-таки нужен Некоторые утилиты и сценарии зависят от atime: почтовые системы, старые бэкапы, системы очистки неиспользуемых файлов. С noatime такая логика ломается. Вывод atime - это не архаизм, а механизм, который нужно контролировать. relatime подходит почти всегда. noatime - осознанная оптимизация для data-разделов. Менять режим стоит только понимая, что именно ты ускоряешь и чем жертвуешь. LinuxCamp | #utils

📱 Топ 6 каналов по AI и Программированию! Подборка для прокачки в сфере ИИ, Python, InfoSec, нейросетей и свежих IT-новостей — всё в одном месте. Советую вам подписаться: 📱 AI-ресурсы — t.me/ai_prompt Полезные нейросети, сервисы и фишки для работы. 👩‍💻 Python — t.me/python_prompt Гайды, задачи и шпаргалки по Python. 🤖 Нейросети — t.me/neuro_prompt Промпты, разборы и практическое применение AI. 🤔 InfoSec & Хакинг — t.me/infosec_prompt Обучение по ИБ, уязвимости и мышление хакера. 📱 IT Новости — t.me/it_news Главные события из мира технологий без воды. 📱 IT Мемы — t.me/it_memes Чтобы было не только полезно, но и смешно.

fsck и счётчик монтирований: как управлять лимитом проверок Что за лимит монтирований В ext4 есть счётчик монтирований. Когда он достигает Maximum mount count, при следующей загрузке запускается fsck. Проверка текущих значений:

sudo tune2fs -l /dev/sda1 | grep -E "Mount count|Maximum mount count"

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

sudo tune2fs -c 500 /dev/sda1

Это значит, что fsck сработает только после 500 монтирований. При необходимости можно сбросить текущий счётчик:

sudo tune2fs -C 0 /dev/sda1

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

Айтишники, это вам — в телеграм есть комьюнити по каждому направлению в IT Там есть буквально всё: чаты для общения, тонны материала(книги, курсы, ресурсы и гайды), свежие новости и конечно же мемы Выбирайте своё направление: 💩 Frontend 🐍 Python 🐧 Linux 👩‍💻 С/С++ 👩‍💻 C# 🤔 Хакинг & ИБ 📱 GitHub 🖥 SQL 👩‍💻 Сисадмин 🤟 DevOps ⚙️ Backend 🖥 Data Science 🧑‍💻 Java 🐞 Тестирование 🖥 PM / PdM 👩‍💻 GameDev 🧑‍💻 Golang 🤵‍♂️ IT-Митапы 🧑‍💻 PHP 💻 WebDev 🖥 Моб. Dev 🖥Анали.(SA&BA) 👩‍💻 Дизайн 🖥 Нейросети 💛 1C 🤓 Книги IT ➡️ Сохраняйте в закладки

Когда кто-то говорит:

да кому вообще нужен ваш линукс

Чтобы не было вопросов, нужно на каждой системе, где он юзается писать "Powered by linux" LinuxCamp | #memes

Мне кажется, нужно для всех топ компаний вводить новый стандарт - шифровать методом стеганографии и прятать под PNG все логи и бэкапы инфраструктуры 🤔 LinuxCamp | #memes

⚡️ ВАЙБ-КОДИНГ теперь в Telegram! Ребята сделали крутейший канал, где на наглядных примерах и понятном языке рассказывают как войти в новую эру разработки с ИИ, делятся полезными фишками и инструментами Подписывайтесь, нас уже 10 тысяч: @vibecoding_tg

tune2fs: куда пропало место и почему это нормально Что показывает Reserved block count Reserved block count - это блоки ext4, зарезервированные под root. По умолчанию около 5% диска. На больших RAID это десятки гигабайт, и это ожидаемо. Посмотреть сколько зарезервировано:

sudo tune2fs -l /dev/md2 | grep "Reserved block count"

Зачем нужен резерв Резерв позволяет системе работать, даже если диск заполнен: писать логи, логиниться под root, корректно завершать сервисы. Убирая его полностью, ты сознательно снижаешь устойчивость системы к авариям. Когда можно уменьшать На разделах с данными (/var, /data, /srv) резерв обычно не критичен. На системном разделе (/) его лучше оставить хотя бы минимальным. Уменьшение до 1%:

sudo tune2fs -m 1 /dev/md2

Важно: изменения затрагивают файловую систему напрямую. При ошибке выбора устройства можно повредить данные, поэтому всегда проверяй, с каким разделом работаешь. К чему может привести неправильная настройка Нулевой резерв на системном диске может привести к ситуации, когда система не сможет писать логи или корректно стартовать сервисы при заполнении диска. Это не поломка сразу, а потеря запаса прочности. Вывод tune2fs безопасен при осознанном использовании. Менять параметры ext4 можно и нужно, но только понимая, что ты жертвуешь отказоустойчивостью ради дополнительного места. LinuxCamp | #utils

Изоляция рунета ближе, чем ты думаешь

Loading … ██████████████] 99%

Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.

Сетевые неймспейсы: изолируем сетевой стек в три команды Что такое netns Сетевой namespace - это отдельный сетевой стек: свои интерфейсы, маршруты, iptables, локальные порты. Создаём изолированный сетевой стек Создаём namespace:

sudo ip netns add testns

Проверяем:

ip netns list

Пустой стек без интерфейсов, кроме lo. Добавляем виртуальный линк Соединяем основной namespace и testns:

sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth1 netns testns

Назначаем адреса:

sudo ip addr add 10.10.0.1/24 dev veth0
sudo ip netns exec testns ip addr add 10.10.0.2/24 dev veth1

Включаем интерфейсы:

sudo ip link set veth0 up
sudo ip netns exec testns ip link set veth1 up
sudo ip netns exec testns ip link set lo up

Проверяем связь Из основного пространства:

ping -c 3 10.10.0.2

Из изолированного:

sudo ip netns exec testns ping -c 3 10.10.0.1

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

sudo ip netns exec testns curl http://10.10.0.1:8080

И не трогаешь основной стек. Вывод Сетевые неймспейсы дают чистую сетевую песочницу. Три команды и у вас отдельная "мини-сеть" для экспериментов, тестов и отладки, без виртуалок и контейнеров. LinuxCamp | #utils

GitHub теперь в Telegram! Самый прогерский канал, где за 10 минут ты научишься: / Пробив по фото и номеру в ТГ // Как взломать вебку подруги /// Мануал по OSINT разведке Подписывайся, нас уже сотни тысяч: >@GitHub

Сетевые неймспейсы: изолируем сетевой стек в три команды Что такое netns Сетевой namespace - это отдельный сетевой стек: свои интерфейсы, маршруты, iptables, локальные порты. Создаём изолированный сетевой стек Создаём namespace:

sudo ip netns add testns

Проверяем:

ip netns list

Пустой стек без интерфейсов, кроме lo. Добавляем виртуальный линк Соединяем основной namespace и testns:

sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth1 netns testns

Назначаем адреса:

sudo ip addr add 10.10.0.1/24 dev veth0
sudo ip netns exec testns ip addr add 10.10.0.2/24 dev veth1

Включаем интерфейсы:

sudo ip link set veth0 up
sudo ip netns exec testns ip link set veth1 up
sudo ip netns exec testns ip link set lo up

Проверяем связь Из основного пространства:

ping -c 3 10.10.0.2

Из изолированного:

sudo ip netns exec testns ping -c 3 10.10.0.1

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

sudo ip netns exec testns curl http://10.10.0.1:8080

И не трогаешь основной стек. Вывод Сетевые неймспейсы дают чистую сетевую песочницу. Три команды и у вас отдельная "мини-сеть" для экспериментов, тестов и отладки, без виртуалок и контейнеров. LinuxCamp | #utils

Opensource в каждый офис Германская земля Шлезвиг-Гольштейн приняла решение отказаться от Microsoft Office 365 в пользу LibreOffice и другого открытого ПО, что приведёт к значительной экономии бюджета и повышению суверенитета данных. Такой переход позволит экономить более 15 млн евро ежегодно. Сейчас выполнена миграция 80% рабочих мест. Кроме того, запланирован инвестиционный вклад в размере 9 млн евро, который направлен на завершение миграции и развитие открытых решений. LinuxCamp | #news

iperf3: как понять, тормозит канал или сервер Что делает iperf3 iperf3 даёт реальную пропускную способность сети между двумя машинами. Измеряет не "скорость интернета", а скорость между конкретными хостами. Это лучший способ понять, где bottleneck: у провайдера, в маршруте или в самом сервере. Быстрый старт На сервере поднимаем слушатель:

iperf3 -s

На клиенте запускаем тест:

iperf3 -c <SERVER_IP>

Вывод покажет фактический throughput, передачу по секундам и retransmits. TCP или UDP TCP-тест:

iperf3 -c <IP> -t 10

Показывает реальную пропускную способность как для обычных приложений: учитывает RTO, congestion control и потери. UDP-тест:

iperf3 -c <IP> -u -b 1G

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

UDP Jitter: 1.23 ms
Loss: 2%

Высокий jitter и потери → проблемы маршрута или перегруз канала. Пример реальной диагностики Пользователь жалуется, что сервис долго отвечает. На сервере всё нормально, CPU не загружен. Проверяем TCP:

iperf3 -c <SERVER_IP>

Видим:

[  5]   0.00-10.00  sec   42.0 MBytes  35.2 Mbits/sec  120 retransmits

120 повторных отправок это много. Проблема не в приложении, а в канале: пакетная потеря, слабый Wi-Fi, либо провайдер режет TCP-окна. Проверяем UDP:

iperf3 -c <SERVER_IP> -u -b 300M

Loss: 15%   Jitter: 5 ms

Подтверждение: канал нестабилен. Вывод iperf3 - это честная проверка сети. TCP-тест показывает реальное поведение приложений, UDP-тест раскрывает проблемы: jitter, потери, нестабильность. Когда непонятно, сервер тормозит или канал начинаем именно с iperf3. LinuxCamp | #utils

fdisk: базовый инструмент разметки дисков в Linux Зачем нужен fdisk fdisk управляет таблицей разделов на диске: показывает структуру, создаёт и удаляет разделы, меняет типы и метки. Работает с MBR и GPT-таблицами. Это утилита низкого уровня без файловых систем и монтирования. Просмотр структуры диска Показать все устройства:

fdisk -l

Информация по конкретному диску:

sudo fdisk -l /dev/sda

Вывод покажет размер, таблицу разделов, типы, смещения и флаги. Работа в интерактивном режиме Для изменения разметки диска:

sudo fdisk /dev/sdb

(важно: быть аккуратным и убедиться, что выбран правильный диск) Команды внутри fdisk:

p  — показать текущие разделы
n  — создать новый раздел
d  — удалить раздел
t  — изменить тип
w  — записать изменения и выйти
q  — выйти без сохранения

Пример использования Создаём новый раздел на дополнительном диске /dev/sdb:

sudo fdisk /dev/sdb
# внутри:
n        # новый раздел
p        # primary
1        # номер
<enter>  # старт по умолчанию
<enter>  # конец по умолчанию
w        # записать (осторожно!)

Форматируем:

sudo mkfs.ext4 /dev/sdb1

Монтируем:

sudo mount /dev/sdb1 /var/log2

Вывод fdisk - это точный и простой инструмент для управления таблицей разделов. Работает надёжно, но требует аккуратности: изменения сразу затрагивают структуру диска, поэтому перед записью (w) всегда проверяй, что работаешь именно с нужным устройством. LinuxCamp | #utils

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

dmesg | tail -n 30

С фильтром по ошибкам:

dmesg -T | grep -i error

Живой вывод, как tail -f:

dmesg -w

Пример реальной проблемы Сервер начал подвисать и рандомно отключать сетевой интерфейс. Система молчит, journalctl не даёт понятных подсказок. Смотрим dmesg:

dmesg -T | grep -i eth0

И видим:

[Mon Dec  1 10:15:12 2025] e1000e 0000:00:19.0 eth0: EEPROM corrupted
[Mon Dec  1 10:15:13 2025] eth0: link down
[Mon Dec  1 10:15:14 2025] eth0: link up

Причина - умирающий сетевой адаптер или битый firmware/EEPROM. Без dmesg найти такое почти невозможно: приложение думает, что сеть просто пропадает. Ещё один пример: проблемы с диском

dmesg -T | grep -i "read error"

Вывод:

blk_update_request: I/O error, dev sda, sector 1587840

Ядро сообщает, что диск не может прочитать сектор,это верный признак начала деградации. Вывод dmesg - это прямой канал общения с ядром. Если проблема связана с железом, драйверами, памятью, сетевыми интерфейсами или файловой системой, то почти всегда подсказка лежит именно здесь. LinuxCamp | #utils

ROI в DevOps ↗️ Эффективны ли ваши инвестиции в DevOps? Как посчитать возврат от вложений? Команда юнита «Экспресс 42» (Флант) приглашает вас на вебинар, где:

– Поделится инструментами оценки ROI сверху вниз (верхнеуровневая оценка трансформации) и снизу вверх (детальная оценка отдельных изменений). – Проанализирует выгоды и ROI на примере компании среднего размера. – Объяснит, как DevOps помогает сократить трудозатраты и получить дополнительную доходность.

Вебинар пройдёт 5 декабря (пт) в 12:00 Зарегистрироваться Если ищете способы увеличить прибыль или сократить издержки, а также усовершенствовать качество поставки цифровых продуктов, ждём вас на эфире 🧑🏼‍💻

Почему показатели нагрузки кажутся странными и чем помогает htop CPU% и несколько ядер Показатель %CPU у процесса это доля одного логического ядра, а не всей системы. На машине с 8 ядрами суммарный %CPU может быть больше 100%, это нормально. Сначала смотрим, сколько вообще ядер:

nproc
lscpu | grep '^CPU(s):'

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

htop

load average не процент загрузки load average показывает среднее количество процессов, которые либо выполняются, либо ждут CPU или I/O. Это не процент и не "нагрузка процессора". Значение 4.0 на 4 ядрах означает, что в среднем одновременно 4 задачи хотят работать.

uptime
cat /proc/loadavg

Если load примерно равен числу ядер система работает в нормальном режиме. Если намного выше, значит есть очередь на CPU или на диск. Steal time и работа в виртуалках В htop есть поле st в строке CPU. Это время, когда ваша виртуальная машина хотела получить CPU, но гипервизор отдал его другим. Если st заметно выше нуля, а сама нагрузка небольшая, узкое место не в вашем приложении, а в окружении. IOWait и зависания из-за диска Поле wa (iowait) показывает, сколько времени CPU простаивает в ожидании диска или сети. Высокий wa при невысоком %CPU и большом load average означает, что проблема в I/O. Для проверки дисков удобно использовать iostat:

iostat -x 1

Как смотреть нагрузку Корректный минимум: понять число ядер и текущий load, затем посмотреть разбиение CPU по user/system/iowait/steal и проверить диск.

nproc
uptime
htop
iostat -x 1

Если эти команды анализировать вместе, показания htop перестают выглядеть странными и становится ясно, где именно упирается система: в CPU, диск, память или виртуализацию. LinuxCamp | #utils

Как обеспечить безопасность в Kubernetes? 5 декабря в 11:00 разработчики Luntry, решения для защиты контейнерной инфраструктуры, и платформы контейнеризации «Штурвал» проведут совместный вебинар. В программе: ◾предоставление доступов и анализ прав RBAC; ◾погружение в сетевую безопасность и организацию Zero Trust; ◾мультитенантность и ее связь с контролем Kubernetes-ресурсов. Luntry и «Штурвал» вместе создают сквозной контур безопасности для Kubernetes, который не только обнаруживает уязвимости, но и предоставляет инструменты для их оперативного устранения и даже предотвращения. Будет полезно инженерам безопасности, SRE, DevOps-инженерам, тимлидам. 📌 Зарегистрироваться