LinuxCamp | DevOps

Временный секрет в Linux без следов Иногда нужно сохранить пароль или токен на пару минут. Передать в скрипт, использовать в деплое, проверить подключение и не оставить его в history, tmp-файлах или с правами. Сделаем временный файл, который доступен только владельцу и сам удалится. Создаём безопасный файл Сразу задаем строгие права и создаём уникальный файл:

umask 077
SECRET_FILE=$(mktemp /tmp/secret.XXXXXX)

umask 077 гарантирует, что файл будет доступен только владельцу. mktemp создаёт файл атомарно и защищает от подмены в /tmp. Права выставляются в момент создания. Вводим секрет без history Читаем данные напрямую из TTY и записываем в файл:

read -s SECRET
printf "%s\n" "$SECRET" > "$SECRET_FILE"

read -s не показывает ввод. Переменная живет только в текущем shell. В history ничего не попадет. Автоудаление Настроим удаление через 5 минут:

(sleep 300; shred -u "$SECRET_FILE") &

sleep задает задержку. shred -u перезаписывает и удаляет файл. Процесс уходит в фон, можно продолжать работу. Даже если выйдешь из shell, удаление все равно произойдет. Итог Получаем временный файл с жесткими правами, без утечек в history и без мусора на диске. LinuxCamp | #utils

Я настроил свое рабочее пространство в терминале сервера Люблю работать прямо на сервере: деплой, логи, конфиги, контейнеры. Раньше для этого я открывал несколько вкладок и подключался по SSH по два-три раза. Когда проектов и логов становится много это превращается в хаос. Закрыл вкладку - процесс умер. Переподключился - всё заново. Решение: Пересобрать это через tmux. tmux создает отдельную сессию внутри SSH. Даже если соединение оборвалось, процессы продолжают жить. Ты возвращаешься на сервер, открываешь сессию, а там все на месте. Создать сессию:

tmux new -s backend

Окна и панели Но самое полезное - это окна и панели. Окна в tmux как вкладки, а панели разделяют экран внутри одного окна. Теперь у меня в одной сессии может быть окно с логами, второе с деплоем, третье с htop. Разделить экран можно так:

Ctrl + b, %  # вертикальный split
Ctrl + b, "  # горизонтальный split

Создавать и переключаться между окнами:

Ctrl + b, c  # создание окна
Ctrl + b, n  # переключение между окнами

Если нужно уйти и оставить все работать:

Ctrl + b, d

Вернуться:

tmux attach -t backend

Вывод: В итоге у меня один SSH, по одной сессии на проект, и внутри нее уже готовое рабочее окружение под меня. Также можно разделять по стендам: дев, прод, стейдж. Заходишь и продолжаешь с того же места. LinuxCamp | #utils

Когда стандартное облако не работает. Типовая ситуация: — нужно масштабирование без переноса всей инфраструктуры; — база должна остаться на выделенном железе; — фронт — в публичном облаке; — SLA высокий, но бюджет не бесконечный. Стандартные решения в таких случаях не помогают. Нужна архитектура под задачу, а не «коробочное решение» для всех. В канале DataSpace мы разбираем: — как онлайн-ритейлер выдержал рост нагрузки в 10 раз без деградации сервисов — где гибридная модель действительно оправдана — как быстро сравнить разные варианты конфигурации стоимости — какие ошибки чаще всего допускают при выборе провайдера Если отвечаете за инфраструктуру или эксплуатацию, будет полезно подписаться — @dataspace_ru

Notepad++ полгода распространял китайский вирус через обновления из-за взлома хостинга Китайские хакеры более полугода имели возможность запускать бинарники на компьютерах пользователей Notepad++ Детали компрометации Notepad++: - В июне 2025 года был взломан сервер обновлений Notepad++. Это позволило вредоносным бинарникам выполняться через механизм обновления утилиты. - По словам исследователя в области кибербезопасности Кевина Бомонта, взлом был осуществлён группировкой «Funky Stamen». - Автор Notepad++ также заявил, что, по всей вероятности, атака была проведена «китайской группой, спонсируемой государством». - 18 ноября 2025 года разработчик Notepad++ выпустил обновление версии 8.8.8, в которое был включён патч для апдейтера в связи с «потенциальной проблемой перехвата». - Окончательно выгнать хакеров удалось только 2 декабря. Это тот редкий кейс, когда open-source проект пострадал не из-за собственного кода, а из-за слабого звена в цепочке поставки — хостинга. Полгода атака оставалась почти незаметной. LinuxCamp | #news

В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда? Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России 📆 в канале размещаются как онлайн, так и оффлайн мероприятия; 👩‍💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие; 🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах: 🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!

Типичный линуксоид, он такой)) 1. Хейтим винду и хвалим творение "О Великого Торвальдса" 2. Не тянем тяжелый люкс и 10 часов восстанавливаем систему)) LinuxCamp | #memes

В России заблокировали Linux! на время Российские пользователи и разработчики потеряли доступ к git.kernel.org и другим связанным ресурсам. Проблемы, вероятно, возникли из-за работы технических средств противодействия угрозам (ТСПУ) на фоне замедления работы Telegram. Роскомнадзор заявил, что не блокировал сервисы Linux в России, так что пока выдыхаем 😮‍💨 LinuxCamp | #news

Как не потерять логи Самая обидная история: сервис упал, контейнер пересоздался, ты полез разбираться, а логов нет. Потому что они жили рядом с процессом, а процесс умер. Решение простое: пусть логи живут в системе, а не в контейнере На большинстве серверов уже есть journald. Он умеет хранить, ротировать, искать по времени и не превращать диск в свалку. Туда можно складывать логи и от systemd-сервисов, и от Docker. Сохранение логов Docker в journald

x-logging: &journald
  driver: "journald"
  options:
    tag: "{{.Name}}"

services:
  app:
    logging: *journald

Теперь смотришь логи не через docker logs, а как нормальные системные:

journalctl -t app -f
journalctl -t app --since "1 hour ago"
journalctl -t app --since "2026-02-09 00:00:00"

Чтобы логи переживали ребут По умолчанию journald может хранить часть логов в памяти. Включаем хранение на диск:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

Проверка сколько места заняли логи:

journalctl --disk-usage

Ротация логов journald, чтобы диск не умер Если ты кидаешь логи в journald, он не хранит их бесконечно. Ротация и лимиты настраиваются в /etc/systemd/journald.conf или правильнее в отдельных файлах:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/10-rotation.conf

Вывод Хочешь не терять логи, не привязывай их к жизни контейнера. Сложи их в journald и получи единый поиск, ротацию и историю, которая переживает перезапуски. LinuxCamp | #utils

Иногда просто хочется быть счастливым🙂 LinuxCamp | #memes

Хватит копипастить ssh: наводим порядок в ~/.ssh/config Ключ у тебя уже есть, пароль ты уже ненавидишь, но всё равно каждый раз пишешь ssh user@ip, потом ещё раз на бастион, потом снова, потом ждёшь. SSH умеет делать это нормально, если один раз настроить конфиг. ~/.ssh/config вместо копипасты Создай конфиг и закрой на него права:

nano ~/.ssh/config
chmod 600 ~/.ssh/config

Минимальный пример: алиас, юзер, ключ, нормальные keepalive

Host prod
  HostName 95.215.56.62
  User maga
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

Теперь подключение становится человеческим:

ssh prod

JumpHost: когда есть bastion Если внутренняя машина доступна только через bastion, добавляешь ProxyJump.

Host bastion
  HostName 1.2.3.4
  User maga
  IdentityFile ~/.ssh/id_ed25519

Host internal
  HostName 10.95.0.10
  User maga
  IdentityFile ~/.ssh/id_ed25519
  ProxyJump bastion

И заходишь одной командой, без матрёшки из ssh:

ssh internal

Ускоряем повторные ssh: ControlMaster Когда ты делаешь 10 коннектов подряд, каждый новый handshake это боль, особенно через bastion. Мультиплексирование решает.

Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

После этого повторные ssh internal ощущаются как телепорт. Вывод Ключи дают безопасность, а ~/.ssh/config даёт скорость и порядок. ProxyJump убирает матрёшку, ControlMaster убирает тормоза. Один раз настроил и дальше просто работаешь. LinuxCamp | #utils

Быстрый анализ загрузки через systemd-analyze На сервере все ок: железо норм, диски норм, но после ребута он думает о смысле жизни секунд 40. Обычно лезешь сразу в сервисы, логи и смотришь что запустилось, а что еще нет. Но иногда юнит не падает, а просто висит в starting и ждёт сеть, DNS, диск или маунт. Что делает systemd-analyze systemd-analyze вскрывает сколько заняло ядро, сколько занял userspace, и какие юниты съели время. Кто тормозит

systemd-analyze blame

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

systemd-analyze critical-chain

Эта штука показывает цепочку, что блокировало путь до default.target. Видно кто кого ждал и где пробка. График загрузки для красивого разбора Если хочется визуально показать коллеге почему оно долго стартует, есть SVG-таймлайн.

systemd-analyze plot > boot.svg

Открываешь boot.svg в браузере и видишь полосочки, кто и когда стартовал. Вывод systemd-analyze это твой способ увидеть кто, где и почему тормозит загрузку и кто кого ожидает. LinuxCamp | #utils

Как читать файлы Эпштейна на Linux Интернет на днях поймал лютый сюжетный твист: в опубликованных файлах по делу Эпштейна люди нашли… Bash Reference Manual. 😵 Да, 158-страничный туториал по bash, тот самый, который открывали наши деды, когда забывали очередную команду с 100500 флагами. Это значит, что пришло время написать шпаргалку про то как смотреть pdf-файлы на linux xdg-open (пакет xdg-utils) Открыть PDF дефолтной программой.

xdg-open file.pdf

evince (пакет evince) Нормальный GUI просмотрщик, если у тебя есть окружение.

evince file.pdf

pdfinfo и pdftotext (пакет poppler-utils) Посмотреть метаданные и быстро вытащить текст.

pdfinfo file.pdf | head
pdftotext file.pdf - | less

pdftoppm (пакет poppler-utils) Если PDF это скан и текста нет, рендерим страницы в PNG.

pdftoppm -png -f 1 -l 3 file.pdf page

mupdf (пакет mupdf) Лёгкий просмотрщик, часто быстрее тяжёлых.

mupdf file.pdf

zathura (пакет zathura) Минималистичный просмотрщик, любимый вариант для клавиатурных ниндзя.

zathura file.pdf

Вывод Для PDF тебе обычно хватает poppler-utils и одного просмотрщика. Остальное уже по вкусу. А если вдруг в очередной слив опять попадет документация по bash, ты хотя бы будешь готов открыть ее красиво. LinuxCamp | #utils

Освойте UserGate и повысьте уровень защиты своей ИТ-инфраструктуры! Бесплатный онлайн-курс поможет вам шаг за шагом освоить внедрение и настройку UserGate — без лишней теории, с упором на практику. В программе курса: ✅ Настройка сетевых зон, NAT, VPN, кластеров, фильтрации на уровне приложений и правил межсетевого экрана ✅ Интеграция с LDAP и Active Directory, фильтрация контента, системы обнаружения вторжений и обратный прокси ✅ Пошаговые видеоуроки, практические упражнения и итоговое тестирование По завершении курса Вы получите: ⭐ именной сертификат 📕 PDF-инструкции 📋 чек-листы и готовые конфигурации, которые помогут в дальнейшей работе Пройдите курс в удобное время — запись уже доступна. Реклама. ООО "ИНФРАТЕХ". ИНН 5024197250.

Вышел новый Linux 6.19, следующий уже 7.0! Linus выпустил Linux kernel 6.19, и сразу подтвердил, что следующая ветка будет называться 7.0. Причина максимально невпечатляющая: нумерация стала неудобной, а не потому что там грядёт большой перелом 😒 Что полезного собсна вышло: Вкратце 6.19 это обычный релиз с пачкой драйверов, фиксов и улучшений железа. Если сидишь на свежих дистрибутивах или катишь ядро руками, можно в целом планировать апдейт Шо по Rust? К циклу Linux 7.0 в ядро ушел патч, который символически закрывает формулировку "Rust experiment". Раст остается, выдыхаем (ну или напрягаемся) Вывод: 7.0 это ребрендинг цифры. Смысла обновляться ради числа и ждать серьезных положительных изменений нет. Поделитесь если есть фиксы, из-за которых хотели бы перейти на новую версию🔥 LinuxCamp | #news

👩‍💻 Хватит учить только синтаксис, начинай делать реальные проекты! Python Ready — авторский канал, где Python перестаёт быть только теорией и становится рабочим инструментом. Мини-проекты, боты, советы, разборы задач, гайды и шпаргалки для каждого программиста. 🔥 Советую подписаться: @python_ready

👩‍💻 Хватит учить только синтаксис, начинай делать реальные проекты! Python Ready — авторский канал, где Python перестаёт быть только теорией и становится рабочим инструментом. Мини-проекты, боты, советы, разборы задач, гайды и шпаргалки для каждого программиста. 🔥 Советую подписаться: @python_ready

flock: чтобы cron не запускал одно и то же дважды У cron есть суперсила: он запускает задачи по расписанию. И есть скрытая пассивка: ему всё равно, что прошлый запуск ещё не закончился. Так рождаются классические баги: двойная чистка, двойная рассылка, два бэкапа в один файл, гонки за локи в БД. Мастхев-решение Запускать только один экземпляр, остальные попытки пропускать:

* * * * * flock -n /tmp/myjob.lock -c '/usr/local/bin/myjob.sh'

-n значит не ждать, если занято, сразу выйти. Если важно не пропустить, а выполнить по очереди Ждать пока освободится лок:

flock /tmp/myjob.lock -c '/usr/local/bin/myjob.sh'

Или ждать максимум 30 секунд:

flock -w 30 /tmp/myjob.lock -c '/usr/local/bin/myjob.sh'

Чтобы было видно пропуск

flock -n /tmp/cleanup.lock -c '/usr/local/bin/cleanup.sh' || logger -t cleanup "skip: lock busy"

Вывод: flock это ремень безопасности для cron. Одной строкой ты убираешь параллельные запуски, гонки и случайную порчу данных. LinuxCamp | #utils

Безопасность сервера на котором уже крутится твой мега-стартап Иногда безопасность ломается не из-за супер-0day, модной вирусни, user/password от бд: postgres/postgres (все совпадения случайны), а из-за банального: у тебя на VPS торчит порт, который временно открыл и забыл. А интернет не забывает, его постоянно сканируют. Что реально происходит в сети У твоего сервера есть публичный IP. Для внешнего мира он как витрина, туда стучатся все кому не попадя. И по этой витрине ходят роботы. Очень типичная цепочка выглядит так:

Скан → найден порт → баннер/версия → подбор пароля/эксплойт → закрепление

Сканируют все, всегда, без личных причин. Просто потому что это дёшево и масштабируется. Кто ты воин? Если хочешь быстро почувствовать как оно, посмотри на свой сервер глазами атакующего (с другого хоста):

nmap -sS -sV -Pn -p- <твой ip>

Тебя интересует только открыт ли 22 (ssh), а любые неожиданные вещи: 2375 (Docker API), 9200 (Elasticsearch), 5432 (PostgreSQL), 6379 (Redis), 8080/8000 (админки), 9090 (метрики/Prometheus) и т.д. Главная мысль: "Если сервис слушает 0.0.0.0, он уже считается публичным!", даже если там есть пароль. Почему пароль слабая защита Пароль - это последняя линия. Первая линия - это, чтобы до сервиса вообще не дошли. Потому что есть брутфорс и словари, есть утечки паролей, есть баги в сервисах, есть неверные настройки, есть админки без rate-limit. И даже без взлома, открытый порт = лишний шум в логах + лишняя нагрузка. База: закрыть все, кроме нужного Самый спокойный подход: default deny, и дальше открываешь только то, что реально нужно. Пример минимального nftables: разрешаем установленные соединения, loopback, SSH и HTTP/HTTPS, остальное в drop.

nft add table inet filter

nft 'add chain inet filter input { type filter hook input priority 0; policy drop; }'

nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept

nft add rule inet filter input tcp dport 22 accept
nft add rule inet filter input tcp dport { 80, 443 } accept

Если хочешь сделать ещё правильнее, ограничь SSH по IP (например, только твой офис/VPN):

nft add rule inet filter input ip saddr <YOUR_IP>/32 tcp dport 22 accept

И сразу становится заметно: даже если на сервере случайно поднялся Redis на 0.0.0.0, то извне его не видно. Важный вывод Если порт открыт, то им кто-то уже интересуется. Сделай так, чтобы интересоваться было нечем. LinuxCamp | #security

Для тех, кто уже выкупил прикол ИИ, я создал блог, куда пишу более глубокие посты на тему использования ИИ в разработке. Для справки - последний год я с головой погрузился в нейронки и начал применять их на работе (да, я пока работаю C++ фултайм на линукс) и для собственных проектов. На канале показываю чит коды, которые помогают мне быть эффективным в найме и за пару дней с ИИ закрывать спринты. Также делюсь успехами и неудачами в создании своих IT продуктов с помощью вайбкодинга. Помимо прочего, говорим про то, как свои продукты развивать, демонстрирвать их народу и делать так, чтобы народ за решения платил. Я сам еще на пути к мастерству в перечисленных направлениях, но уже есть о чем рассказать) Короче, если разделяешь мои интересы, жду тебя в блоге: https://t.me/+h7e67vXacQM3NDUy

Деннис Ритчи — создатель языка C и ОС Unix

1941 — Родился в пригороде Нью-Йорка, вырос в семье учёного из Bell Labs. 1968 — Получил образование в Гарварде, но не осилил степень PhD из-за бюрократических формальностей. 1969 — начал работать в Bell Labs, где и создал свои главные проекты. 1972 — создал язык программирования C. Язык создавался для эффективности и переносимости. (1969–1973) — разрабатывал ОС Unix, которая изначально писалась на ассемблере, но к 1973 году была почти полностью переписана на C. 1978 — с Брайаном Керниганом выпустил книгу «Язык программирования C». Также свою руку Деннис приложил и к другим проектам: ОС Plan 9 и Inferno, язык Limbo, взлом шифровальной машины M-209, редактор QED, макропроцессор М4.

Влияние языка C на индустрию — C позволил легко переносить Unix на разные аппаратные платформы. — C давал низкоуровневый контроль, как ассемблер, но с высокоуровневой структурой, что сделало его идеальным для системного программирования — Синтаксис и идеи C легли в основу C++, Java, C#, Go, Python. Если было полезно, ставим 🔥 ITCamp | AI & Code