Менеджер паролей для linux

Если не хочешь хранить пароли в .env или светить их в коде, попробуй pass. Это минималистичный менеджер паролей, который хранит каждый пароль в отдельном GPG-файле, зашифрованном твоим GPG-ключом.

Установка:

sudo apt install pass gpg
gpg --gen-key
pass init <имя_ключа>

Команда pass init связывает хранилище с твоим ключом, только им можно будет расшифровать пароли.

Добавление и просмотр:

pass insert github.com
pass show github.com

Пароли лежат в ~/.password-store. Это обычные файлы, но зашифрованные GPG. Структура каталогов повторяет иерархию имён, поэтому всё выглядит логично и читаемо.

Использование в скриптах:

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

#!/bin/bash
DOCKER_PASS=$(pass show dev/docker)
echo "$DOCKER_PASS" | docker login -u myuser --password-stdin

pass легко интегрируется в CI, shell-скрипты и git. Все шифруется твоим ключом, все под твоим контролем.

LinuxCamp | #utils

Запуск Windows-приложений на Linux: Wine

Если ты сидишь на Linux, но время от времени нуждаешься в каких-нибудь программах, которые есть только под винде — используй Wine

Он ничего не эмулирует, он транслирует код из одной среды, в другую - переводит вызовы Windows API в POSIX-вызовы "на лету" — из-за этого программы работают быстрее и потребляют меньше ресурсов.

Отсюда и следует его полное название, которое является акронимом - Wine Is Not an Emulator.

Проект запустили ещё в 1993 году, а стабильный релиз вышел в 2008. Это полностью открытое ПО, которое поддерживают компании вроде CodeWeavers.

Важно что:

— не всё работает идеально, иногда придётся повозиться с настройками
— стабильность зависит от конкретной программы и драйверов

Подробный гайд по установке и использованию wine.

LinuxCamp | #utils

perf: микроскоп для производительности ядра

perf - инструмент, встроенный прямо в ядро Linux. Он показывает, куда утекает производительность: какие функции жрут CPU, сколько контекстных переключений, какие системные вызовы самые медленные. Не требует установки пакетов, а просто:

sudo perf top

и ты видишь, где реально горит процессор.

Замер производительности программы

Хочешь понять, где тормозит твой код запускаешь:

sudo perf record -g ./my_program
sudo perf report

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

Анализ системных вызовов

Чтобы увидеть, что делает процесс на уровне ядра:

sudo perf stat -p $(pidof nginx)

Выведет количество системных вызовов, переключений контекста и кэшей. Это то, что top не покажет.

Вывод

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

LinuxCamp | #utils

Как поделиться терминалом по ссылке и без SSH?

ttyd - утилита, которая превращает твой терминал в веб-страницу. Запускаешь одну команду и можешь открыть консоль прямо в браузере.

Установка

sudo snap install ttyd --classic
ttyd bash

Открываешь http://<ip>:7681 и видишь свой терминал в браузере. По умолчанию он только для чтения, но если добавить флаг -W, можно делать его интерактивным.

Зачем это нужно

С ttyd можно делиться консолью на демо, показывать командам CI, смотреть логи контейнеров или следить за своим ИИ-агентом прямо с телефона через Tailscale - без SSH и без клиента. Например:

ttyd -p 7681 sh -lc 'docker logs -f backend'

Теперь логи бекенда доступны по ссылке

Один терминал для всех

Чтобы все видели одну и ту же сессию (а не каждый свой терминал), можно обернуть в tmux:

tmux new -s demo
ttyd tmux attach -t demo

Теперь все участники смотрят один экран. Добавь -W, если хочешь дать им право писать команды.

Вывод

ttyd превращает обычный shell в веб-интерфейс без SSH. Но нельзя забывать о безопасности! Не давайте права на запись кому попало.

LinuxCamp | #utils

Умный CLI файловый менеджер: nnn

nnn - миниатюрный, но мощный терминальный файловый менеджер, который почти не требует настройки:

— Управляется с клавиатуры: стрелки, / для поиска, Tab для контекстов, q для выхода

— Поддерживает фильтрацию, пакетное переименование, анализ диска, закладки и сессии

— Интегрируется с Vim/Neovim, копирует пути в буфер, умеет работать с архивами и отправлять файлы в корзину

— Работает везде: Linux, macOS, BSD, Windows (WSL), Haiku, Termux (Android)

— Приватный, POSIX-совместимый, без сбора данных и лишних зависимостей

— Расширяется плагинами: превью, миниатюры, монтирование, загрузка в облако и многое другое

Совет:

Если вы сильно привыкли к ls, делаем alias и используем nnn:

alias ls='nnn -de'

Ссылки:

1) GitHub проекта
2) Туториал по использованию тулзы

LinuxCamp | #utils

fio: тестируем скорость дисков

Что делает fio:

fio - утилита для нагрузочного тестирования ввода-вывода (input-output). Она показывает, сколько твой диск реально выдаёт: IOPS, MB/s и latency при разных сценариях чтения и записи.

Установка:

sudo apt install fio -y

Пример проверки скорости:

fio --name=test \
    --ioengine=io_uring \
    --rw=randread \
    --bs=4k \
    --size=1G \
    --numjobs=4 \
    --runtime=30s \
    --group_reporting

fio создаёт четыре параллельных задачи, которые читают случайные блоки по 4 KB из 1 GB файла в течение 30 секунд, используя движок io_uring. Результат: сколько твой диск может обработать случайных операций за секунду.

Зачем это нужно:

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

Вывод:

fio - это конкретные цифры, по который можно делать выводы, основанные не на ощущениях. С ним легко увидеть, насколько быстро твоя система справляется с реальной нагрузкой.

LinuxCamp | #utils

Нет места, а оно есть

du/dh показывает, что место в файловой системе еще есть, а записать ничего не возможно, т.к. нет места.

Места полно, а записать нельзя

Симптом:

df -h показывает, что место есть, а при записи: "No space left on device".

Почему так бывает

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

Как проверить

Посмотреть, кто держит удалённые файлы:

lsof | grep deleted

или покороче:

lsof +L1

В списке найдёшь процессы и пути к призрачным файлам.

Как починить

Заверши процесс, который держит файл:

kill -9 <pid>

или перезапусти службу, если это, например, nginx, postgres или docker. После этого место действительно освободится.

Вывод

Удалённый файл жив, пока его кто-то держит. df/du не всегда дают полную реальную картину происходящего.

LinuxCamp | #storage

Когда процессу не дают дышать

Симптом:

Приложение падает с ошибкой, а ты смотришь вроде ресурсов полно.

Too many open files

Виноват ulimit

Каждый процесс в Linux живёт в рамках ограничений ядра - ulimits. Одно из них nofile, максимум открытых файловых дескрипторов. Файл, сокет, pipe - всё это дескрипторы.

Посмотреть текущие лимиты:

ulimit -n

увидишь, например:

1024

Это значит, что твой процесс не может держать больше 1024 открытых файлов и соединений.

Как увеличить

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

Временно (для текущей сессии):

ulimit -n 65535

Навсегда — в /etc/security/limits.conf или /etc/systemd/system.conf:

* soft nofile 65535
* hard nofile 65535

Если сервис под systemd, добавь в unit-файл:

[Service]
LimitNOFILE=65535

и перезапусти:

systemctl daemon-reexec
systemctl restart <service>

Осторожно с лимитами

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

Вывод

Too many open files - это не баг, а защита ядра. Если приложение задыхается, то можно увеличить лимиты. Главное понимать почему в приложении появляется данная проблема

LinuxCamp | #utils

ИИ добрался и до операционок: SUSE и Red Hat

Enterprise-лидеры встраивают ИИ в основу операционной системы. Новые фичи на примере недавнего анонса SUSE:

— MCP (Model Context Protocol) — реализовали открытый стандарт связи ИИ с системой.

— ИИ может действовать: читать логи, предлагать/выполнять откаты, генерить конфиги — через Cockpit или CLI.

— Поддержка любого LLM-провайдера. Можно использовать свои модели.

Что будет?

Вот так будет выглядеть пример взаимодействия с ОС, к которому мы идем:

$ ai-troubleshoot nginx

— ИИ анализирует "journalctl, nginx -t, ss -tulpn, df -h" и выводит:

«Порт 80 занят apache2... Остановить apache и перезапустить nginx?»

LinuxCamp | #news

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

Из нового: замена в дистрибутиве Ubuntu 25.10 инструментария GNU Coreutils на Rust Coreutils (uutils) привела к нарушению работы скрипта для автоматической проверки наличия обновлений пакетов.

Инициатива наказуема)

LinuxCamp | #news

Сборка дистра по исходникам: Linux From Scratch

Что такое LFS?

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

Зачем это нужно?

— Глубокое понимание структуры Linux: /bin, /sbin, /etc, init, systemd, libc, toolchain…

— Полный контроль: только то, что ты выбрал — никаких лишних пакетов и зависимостей.

— Основа для своих embedded-проектов, роутеров, серверов или учебных систем.

После LFS можно пойти дальше: Beyond Linux From Scratch (BLFS) — добавляй графику, браузеры, DE и даже Docker

Это не про эффективность, а про понимание - как варить кофе в турке, когда все вокруг используют кофемашины)

LinuxCamp | #resources

Одна ошибка и ты ошибся: Suicide Linux

Suicide Linux – это не полноценный дистрибутив, а Debian пакет, который наказывает пользователя за любые опечатки в командах удалением данных с диска:

sudo rm -rf /

"Это уже шестой раз, когда я переустанавливаю систему... Прощай, suicide linux!"

sudo atp remove suicide-linux
"О нет, опять"

LinuxCamp | #resources

Когда память закончилась, но сервер ещё живёт

Сценарий:

На голом сервере запущен сервис с утечкой памяти. Что произойдёт, когда память закончится?

Если включён swap

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

Посмотреть, включён ли swap:

swapon --show

или просто:

free -h

Если swap выключен

Когда физическая память закончится, ядро запустит OOM Killer (Out Of Memory Killer) - это специальный механизм, который выбирает и убивает процессы, чтобы высвободить память. Умрёт не обязательно твой сервис, система решает сама, кого "пожертвовать", ориентируясь на приоритет oom_score.

Посмотреть, как она видит твоё приложение:

cat /proc/<pid>/oom_score

Как OOM выбирает жертву

Он не смотрит на виртуальную память, а только на реально используемую (resident set size, RSS). Именно физическая память решает, кому жить, а кому нет.

Вывод

Если память утекает Linux не спасёт, он просто решит, кого первым застрелить. Swap продлит агонию, OOM поставит точку.

LinuxCamp | #storage #ram

101-я причина отсутствия памяти: коротко про inode

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

Что такое inode

Файл в Linux состоит из данных и его описания. Данные лежат в блоках, а описание в inode. В inode хранятся права, владелец и номера блоков с данными.

Посмотреть inode файла:

ls -li

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

Свободное место и количество inode это разные вещи. Ext2/3/4 создают inode один раз при форматировании. Один файл -> один inode.

Проверка:

df -h   # место
df -i   # inode

Типичная ситуация:

df -h  → свободно 20G
df -i  → 0 свободных inode

Свободные блоки есть, а inode закончились, получается новый файл создать нельзя.

Что делать

Понять, что именно упёрлось: место или inode. Если упёрлось в inode, вариантов немного. На ext увеличить их нельзя. Только удалить мелкие файлы или переделать файловую систему.

Резервные блоки ext

Ext по умолчанию скрывает около 5% места под root. Иногда это десятки гигабайт.

Посмотреть:

tune2fs -l /dev/sdX1 | grep 'Reserved block'

Временно отключить:

sudo tune2fs -m 0 /dev/sdX1

Вывод

Если прод внезапно перестал писать, а df -h показывает свободное место — сразу смотри df -i. Чаще всего именно inode закончились первыми. В xfs и btrfs такая ситуация почти не встречается, потому что inode там создаются динамически, а не заранее.

LinuxCamp | #storage

Это не линукс боится вирусов, а вирусы боятся линукса

Скачал вирус для Linux. Распаковал. Запустил от root - не сработало.

Оказалось, что вместо /usr/local/bin вирус распаковался в /usr/bin, куда у malware нет прав на запись, поэтому вирус не смог создать файл процесса.

Нашел пропатченный configure и makе - не хватало библиотеки, которой в Ubuntu нет. Собрал вручную. Запустился и упал с core dump.

Разобрал логи - вирус предполагал, что работает на ext4, и обращался к API шифрования диска. Под btrfs этот API уже давно депрекейтнут и ядро просто перевело раздел в read-only.

Открыл исходники, нашёл Bitcoin-кошелёк и скинул туда $5 из жалости.

LinuxCamp | #memes

Когда тебе разрешили удаленку, но вместо ноута выдали вот это и просят ну... иногда ходить в офис)

LinuxCamp | #memes

EXT4 vs XFS vs Btrfs

Ext4: стабильная классика

Работает предсказуемо, стоит по умолчанию почти везде. Но нет CoW (Copy-on-Write), снапшотов, сжатия, дедупликации и менеджера томов. На больших дисках тратит много места на служебные структуры.

Проверка раздела:

fsck.ext4 /dev/sdX
tune2fs -l /dev/sdX

Хорошо подходит если нужен простой, надёжный вариант без излишков - рабочие станции, обычные сервера, любые дефолтные сценарии.

XFS: скорость и параллелизм

Максимальная производительность на больших файлах и высокой параллельности. Не умеет уменьшать размер раздела и не имеет современного функционала вроде снапшотов или сжатия.

Инфа о разделе:

xfs_info /dev/sdX

Подойдет, когда важны большие объёмы и скорость - базы данных, file storage, сервисы с тяжёлыми нагрузками.

Btrfs: современный функционал

Система нового поколения: CoW, снапшоты, субтомы, встроенный RAID, сжатие, дедупликация, контрольные суммы. Гибкая и функциональная, но более требовательная к настройкам и дисциплине работы. Нужно быть аккуратней с данными, потому что есть мнение, что она все еще нестабильна.

Статистика по разделу:

btrfs filesystem df /mnt

Лучше использовать, если нужны снапшоты, откаты, экономия места, встроенный RAID и контроль целостности - dev-сервера, домашние машины, контейнерные среды, CI/CD.

LinuxCamp | #file_system

Что такое Docker context

Docker context определяет, куда отправляются команды docker и docker compose. Контекст может быть локальным или удалённым. Удалённый контекст использует подключение по SSH.

Создание и переключение контекстов

Создать удалённый контекст:

docker context create prod --docker "host=ssh://user@server"

Посмотреть доступные контексты:

docker context ls

Переключиться на нужный:

docker context use prod

Где выполняются команды

После переключения любая команда:

docker ps
docker compose up -d
docker compose down

выполняется на удалённом сервере, но файлы из текущей локальной директории не копируются на сервер.

Docker Engine на сервере получает только API-команды, но не получает ваши файлы.

Ограничения при работе с compose

Если в compose-файле есть:

build: .
volumes:
  - .:/app

удалённый Docker Engine не сможет найти эти пути, потому что это ваш локальный каталог, который не существует на сервере. Чтобы запуск через context работал, нужно использовать образы:

image: myapp:latest

или заранее скопировать проект на сервер и запускать compose через SSH:

ssh user@server
cd /project
docker compose up -d

Важное про docker compose up --build

Команда, выполненная локально:

docker compose up --build

не передаёт ваш проект на сервер и не пересобирает его там. Для удалённого Docker Engine ваш каталог недоступен.

Вывод

Docker context только указывает, какой Docker Engine обслуживает ваши команды. Он не синхронизирует директории, не копирует файлы, не выбирает проект по имени папки на вашей машине.

LinuxCamp | #docker #devops

ZFS: файловая система, которая работает иначе

Что делает ZFS особенной

ZFS - это не просто файловая система, а целый стек: менеджер томов + RAID + CoW + проверки целостности + снапшоты. Она не похожа на ext4, XFS или Btrfs по внутреннему устройству.

Dnode вместо inode

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

Посмотреть пул:

zpool status

Посмотреть ФС:

zfs list

Copy-on-Write

ZFS не перезаписывает данные. Любое изменение → новая копия блока → обновление ссылок. Это защищает от порчи данных и позволяет делать быстрые снапшоты.

Снапшот:

zfs snapshot tank/home@today

Контрольные суммы

Каждый блок данных хранится с checksum. Если блок повреждён, ZFS его обнаружит и попробует восстановить (если есть зеркало/RAID).

Проверка целостности:

zpool scrub tank

Сжатие и дедупликация

ZFS умеет прозрачное сжатие:

zfs set compression=zstd tank/data

Дедупликация есть, но дорого стоит по памяти.

RAID в коробке

RAID - это способ объединить несколько дисков в одну систему так, чтобы увеличить скорость, защитить данные от выхода диска из строя или и то и другое сразу. В ZFS RAID встроен прямо в файловую систему. RAID1/5/6/10/50 доступны "из коробки". Не нужен LVM, mdadm, dm-crypt.

Вывод

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

LinuxCamp | #file_system