🤔 Young Linux — большой справочник по Linux и Bash!

Здесь можно найти подробные разборы Linux-команд, Bash-скриптов, работы с файлами, процессами, правами доступа, пакетами и системным администрированием. Материалы сопровождаются примерами команд и практическими объяснениями, что делает обучение более понятным.

📌 Оставляю ссылочку: younglinux.info

🚪 Linux Ready | #сайт

Любую уже запущенную команду можно отправить в background, даже если забыли поставить &!

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

Большинство в такой ситуации останавливают процесс и запускают всё заново с &.

На самом деле это не нужно.

Если команда уже работает в foreground:

$ sleep 1000

Нажмите:

Ctrl + Z

Shell отправит процессу сигнал SIGTSTP и временно остановит выполнение.

Теперь достаточно выполнить:

$ bg

Процесс продолжит работу уже в background, а терминал снова станет свободным.

Проверить список фоновых задач можно так:

$ jobs

Если позже нужно вернуть процесс обратно в foreground:

$ fg

🔥 Полезный встроенный механизм job control в Bash. Он особенно выручает при долгих командах, когда перезапуск означает потерю времени или состояния.

🚪 Linux Ready | #совет

Диагностика проблем с DNS в Linux!

Многие сетевые проблемы на Linux-серверах оказываются связаны не с firewall, маршрутизацией или приложением, а именно с DNS. Симптомы обычно такие: curl зависает, пакетный менеджер не работает, API недоступен по домену, но по IP всё открывается.

В таких случаях сначала стоит проверить, как система резолвит DNS. Первое, что нужно посмотреть — какие DNS-серверы используются системой.

cat /etc/resolv.conf

В классических системах этого достаточно. Но в современных дистрибутивах с systemd-resolved файл часто указывает только на локальный stub-resolver.

nameserver 127.0.0.53

Если используется systemd-resolved, реальные DNS лучше смотреть так:

resolvectl status

Команда показывает активные DNS-серверы для интерфейсов и текущее состояние resolver’а.

Дальше стоит проверить, как система реально разрешает имя.

getent hosts google.com

Это полезнее, чем кажется. В отличие от dig и nslookup, getent использует системный механизм разрешения имён и ближе к тому, как работают реальные приложения. Если getent не работает, а dig работает — проблема обычно в локальной конфигурации.

Чтобы исключить сам DNS-сервер, полезно сделать прямой запрос.

dig google.com @8.8.8.8

Или через Cloudflare:

dig google.com @1.1.1.1

Так быстро становится понятно, проблема локальная или внешняя.

Даже если DNS отвечает, стоит посмотреть время ответа.

dig google.com

Смотри на строку:

;; Query time: X msec

Если нужно проверить весь путь разрешения, помогает trace.

dig +trace google.com

Также бывает полезно проверить reverse DNS.

dig -x 8.8.8.8

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

Если используется systemd-resolved, можно очистить локальный кэш.

sudo resolvectl flush-caches

А затем посмотреть статистику.

resolvectl statistics

Если приложение жалуется на DNS, но dig работает корректно, стоит проверить NSS.

cat /etc/nsswitch.conf

Особенно строку hosts, потому что она определяет порядок источников разрешения имён.

Для финальной диагностики полезно посмотреть DNS-трафик в реальном времени.

sudo tcpdump -ni any port 53

🔥 Вывод: хорошая DNS-диагностика обычно начинается с трёх вещей: проверки системного resolver’а, прямых запросов к DNS-серверам и анализа сетевого трафика. Такой подход позволяет найти большинство DNS-проблем намного быстрее, чем полный разбор всей сетевой подсистемы.

🚪 Linux Ready | #практика

Запускаем только один экземпляр скрипта с помощью flock!

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

Представьте простой пример. Ваш скрипт выполняется 90 секунд, а cron запускает его каждую минуту:

* * * * * /opt/scripts/backup.sh

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

Именно для таких случаев в Linux есть flock. Он использует файловые блокировки ядра и позволяет сказать: пока этот скрипт работает, второй запуск не начинай.

Самый простой вариант выглядит так:

flock /tmp/backup.lock /opt/scripts/backup.sh

Первый процесс получит блокировку, а следующий будет ждать, пока она освободится.

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

flock -n /tmp/backup.lock /opt/scripts/backup.sh

Если блокировка уже занята, команда сразу завершится с ненулевым кодом, а новый экземпляр просто не запустится.

Именно поэтому в cron обычно встречается такой вариант:

* * * * * /usr/bin/flock -n /var/lock/backup.lock /opt/scripts/backup.sh

Только не забудьте, что пользователь, от имени которого работает cron, должен иметь доступ к файлу блокировки.

Если же вы хотите защитить скрипт независимо от того, как его запускают — через cron, вручную или из другого скрипта, — блокировку можно поставить прямо внутри него:

#!/usr/bin/env bash

exec 200>/var/lock/backup.lock
flock -n 200 || exit 1

echo "Работает только один экземпляр"

Здесь exec открывает файл блокировки и связывает его с файловым дескриптором 200, а flock устанавливает блокировку именно на этот дескриптор. Пока дескриптор открыт, блокировка остаётся активной. Даже если процесс аварийно завершится, ядро автоматически её снимет, поэтому вечных блокировок здесь не бывает.

🔥 flock использует рекомендательные (advisory) блокировки. Это значит, что они работают только между процессами, которые сами используют flock для одного и того же файла блокировки. Если какая-то программа полностью игнорирует механизм блокировок, flock физически её не остановит.

🚪 Linux Ready | #практика

📂 Напоминалка для работы с curl!

Например, curl -I позволяет проверить HTTP-заголовки сервера, curl -H добавить необходимые заголовки или токены авторизации, а curl -X POST отправить запрос к API из терминала.

На картинке — основные команды curl, которые пригодятся при разработке, тестировании API, диагностике сетевых проблем и работе с Linux-серверами.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

❤️‍🔥"Это разъ*бный сетап, бро!" 😤

Так сказал мой друг из Африки, когда увидел этот стол)
Не знаю уж че за сетап, меня зовут Саша и качественную необычную мебель из натурального дерева я делаю уже больше 12-ти лет, столько же занимаюсь и темой здоровья.

Когда я услышал, что до 10% смертности связано с сидячим образом жизни, меня это поразило и я задался целью делать максимально функциональные и полезные рабочие пространства, ибо геморрой в 30 это конечно довольно нишево, но все же сомнительно 😂

Ну а собрать такой комплект под свои задачи и при этом сразу прикинуть цены вы можете в удобном Mini App конструкторе ➕

Знали, почему большинство пользователи Linux почти всегда используют find вместе с -print0?

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

Чтобы исключить эту проблему, find умеет разделять имена файлов нулевым байтом:

$ find . -type f -print0

Теперь этот поток можно безопасно передать в xargs:

$ find . -type f -print0 | xargs -0 sha256sum

Так будут корректно обработаны любые допустимые имена файлов, независимо от пробелов, табуляции и других символов.

Тот же приём подходит для удаления файлов:

$ find . -type f -print0 | xargs -0 rm

И для передачи файлов любой другой программе:

$ find . -type f -print0 | xargs -0 grep "TODO"

Именно связка -print0 и -0 считается стандартным способом безопасной обработки имён файлов в Unix-подобных системах.

🔥 Если пишете shell-сценарии или автоматизацию, этот приём избавляет от целого класса трудноуловимых ошибок.

🚪 Linux Ready | #совет

🐱 Большая Linux-шпаргалка для разработчиков!

Здесь собрано огромное количество полезных команд и практических заметок по Linux: работа с терминалом, файловой системой, процессами, сетью, сервисами, Docker, Git, PostgreSQL, Nginx и не только. Особенно ценно, что это не просто сухой список команд, а именно шпаргалка с примерами, пояснениями и полезными сценариями из практики.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Контроль целостности системных утилит Linux через проверку хэш-сумм.

При компрометации сервера злоумышленники часто подменяют базовые системные бинарники (например, ss, ps или login) на модифицированные версии с бэкдорами. Мы напишем лаконичный bash-скрипт, который создаст эталонные слепки контрольных сумм SHA-256 для критически важных утилит и проверит их на предмет несанкционированных изменений. Этот базовый механизм Host IDS (интрузивного детектирования) позволяет оперативно обнаружить факт присутствия атакующего в системе.

Сформируем базу данных эталонных хэш-сумм для выбранных системных утилит и сохраним её в защищенный файл:

# Создание эталонных хэшей для проверки
sha256sum /bin/ps /bin/ss /usr/bin/whoami > /root/sys_integrity.db

Файл базы данных успешно создан и содержит уникальные криптографические отпечатки чистых бинарников.

Напишем автоматический скрипт валидации, который сверяет текущее состояние файлов с ранее сохраненным эталоном:

# Скрипт проверки и вывода измененных файлов
sha256sum -c /root/sys_integrity.db 2>&1 | grep -v 'OK' || echo "Integrity check: SUCCESS"

Команда выполнит сверку всех строк и выведет предупреждение только в случае несовпадения хэшей.

# проверка (контрольная эмуляция подмены для проверки реакции парсера)
echo "test" >> /root/sys_integrity.db && sha256sum -c /root/sys_integrity.db 2>&1 | grep 'FAILED'

Ожидаемый вывод: /root/sys_integrity.db: FAILED

# cleanup (удаление тестовой базы данных из системы)
rm -f /root/sys_integrity.db

Регулярный запуск такого скрипта через cron помогает вовремя заметить активность руткитов и троянов. Чтобы атакующий не смог подделать саму базу хэшей, обязательно храните эталонный файл sys_integrity.db на удаленном сервере логирования или на флешке в режиме "только чтение".

🚪 Linux Ready | #практика

📂 Напоминалка по стилям API-архитектуры!

Например, REST подходит для классических CRUD-операций, WebSocket — для приложений с обменом данными в реальном времени, GraphQL позволяет получать только нужные данные, а gRPC обеспечивает быстрый обмен между сервисами.

На картинке — 6 популярных архитектурных стилей и протоколов API, которые стоит знать каждому разработчику.

Сохрани, чтобы не забыть!

🚪 Linux Ready | #ресурс

📂 Напоминалка по работе с Load Balancer!

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

На картинке — 7 основных задач Load Balancer: распределение нагрузки, SSL termination, сохранение сессий, отказоустойчивость, масштабирование, защита от DDoS и мониторинг серверов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

1000+ свежих IT-вакансий каждый месяц в одном месте 🤘

Пока другие листают hh — мы ищем вакансии по всему рынку: каналы, сайты компаний, стартапы и закрытые источники.

IT Россия
IT СНГ
Стажировки
Digital
Международка
Удалёнка
Python
Бигтех
Дизайн
QA
Джунам
Frontend
Аналитика
Стартапы за рубежом
DevOps
Не с HH
Автоотклики

Слышали, что в Linux можно изменить конфигурацию systemd-сервиса без изменения оригинального unit-файла?

Многие редактируют файлы внутри /usr/lib/systemd/system или /lib/systemd/system, но после обновления пакета такие изменения могут быть потеряны.

Systemd поддерживает drop-in конфигурации:

$ sudo systemctl edit nginx

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

Например, можно изменить параметры запуска:

[Service]
Restart=always
RestartSec=5

После сохранения systemd автоматически создаст отдельное переопределение.

Проверить итоговую конфигурацию, которую реально использует systemd:

$ systemctl cat nginx

Можно увидеть оригинальный unit и все применённые изменения.

Если нужно полностью удалить свои изменения:

$ sudo systemctl revert nginx

Systemd удалит файл переопределения конфигурации и вернёт сервис к исходному состоянию.

🔥 Drop-in конфигурации — способ менять поведение сервисов в Linux. Они сохраняют обновляемость пакетов и делают изменения прозрачными.

🚪 Linux Ready | #совет

❤️ Отличная статья на Habr для тех, кто хочет глубже понять реальные уязвимости в ядре Linux и влияние kernel-багов на безопасность системы!

В этой статье:
• Разбирается, как одна ошибка в коде может привести к повышению привилегий до root;
• Показано, почему даже маленький символ в ядре способен создать критичную уязвимость;
• Разобран практический кейс, который полезно знать всем, кто интересуется hacking и infosec.

🔊 Продолжай читать на Habr!

➡️ Hacking Ready | #статья

Linux-сервисы можно запускать только в момент первого обращения к ним!

Systemd умеет не только постоянно держать сервисы запущенными, но и активировать их по событию через socket activation.

Вместо постоянного запуска процесса создаётся socket:

[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target

Теперь systemd слушает порт самостоятельно и запускает сервис только когда приходит первый запрос.

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

Проверить такие сокеты можно командой:

$ systemctl list-sockets

Так работает множество системных компонентов Linux, включая некоторые службы systemd и Docker:

$ systemctl status docker.socket

Процесс не обязан постоянно работать в фоне. Его можно запускать только тогда, когда реально появился клиент.

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

🚪 Linux Ready | #совет

📂 Шпаргалка по Linux-администрированию!

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

На картинке собраны основные направления работы Linux-администратора: командная строка, безопасность, SSH-доступ, firewall, резервное копирование и др.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Перехватываем сетевые проблемы в Linux через tcpdump!

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

В такой ситуации важно посмотреть, что реально происходит с пакетами. Например:

curl https://api.example.com

Получаем:

Connection timed out

Проверяем, что firewall не является причиной:

systemctl status firewalld

Всё выглядит нормально, но соединения всё равно нет. Здесь помогает tcpdump. Это один из главных инструментов Linux для сетевой диагностики. Он показывает реальные пакеты: что ушло с сервера, что вернулось обратно и на каком этапе возникла проблема.

В такие моменты tcpdump часто экономит часы поиска. Смотрим TCP-трафик к HTTPS-порту:

sudo tcpdump -nn -i any port 443

Параметры:
-nn — не выполнять DNS-resolve и не заменять номера портов именами;
-i — выбрать интерфейс; any — слушать все интерфейсы.

Например:

IP 10.0.0.15.42310 > 142.250.184.14.443: Flags [S]

Видим SYN-пакеты, но не видим SYN-ACK в ответ. Это означает, что клиент пытается установить TCP-соединение, но ответ обратно не приходит.

Дальше стоит искать проблему в: фильтрации трафика; security group; ACL; маршрутизации; удалённом сервисе. Если видим:

IP 142.250.184.14.443 > 10.0.0.15.42310: Flags [S.]

значит TCP handshake проходит.

Сеть, скорее всего, работает, и проблему уже стоит искать выше сетевого уровня: TLS ;сертификаты; настройки приложения; протокол взаимодействия. Для конкретного хоста лучше ограничивать фильтр:

sudo tcpdump -nn -i any host 10.0.0.5

Например, проверяем соединение приложения с PostgreSQL:

sudo tcpdump -nn -i eth0 host 10.0.0.5 and port 5432

На production это намного удобнее, когда через сервер проходят тысячи соединений. Иногда нужно посмотреть содержимое HTTP-запросов:

sudo tcpdump -A -s0 -i eth0 host 10.0.0.5 and port 80

Можно увидеть:

GET /health HTTP/1.1
Host: backend.local

Для обычного HTTP это работает. Для HTTPS посмотреть содержимое запросов не получится — данные будут зашифрованы TLS. Можно увидеть сам факт соединения и TLS handshake, но не содержимое HTTP-запроса. Если нужно сохранить трафик:

sudo tcpdump -nn -i any port 443 -w capture.pcap

Открыть файл можно в Wireshark или повторно через:

tcpdump -r capture.pcap

На нагруженных серверах удобно ограничивать количество пакетов:

sudo tcpdump -nn -i any port 443 -c 100

Ещё полезный фильтр — только новые TCP-соединения:

sudo tcpdump -nn -i any 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

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

ss -tnp

🔥 Главная сила tcpdump в том, что он помогает быстро определить, где именно проблема: пакет не вышел с сервера; пакет ушёл, но ответ не пришёл; TCP установился, а ошибка уже внутри приложения.

🚪 Linux Ready | #практика

👍 Bash One-Liner — крутая шпаргалка по Bash-командам!

Этот репозиторий настоящая находка для тех, кто работает с Linux, терминалом и автоматизацией. Здесь собрана большая коллекция полезных Bash команд для работы с файлами, логами, процессами, сетью, текстом и системным администрированием.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Запускаем команды от имени другого пользователя через sudo -u — без входа в его интерактивную сессию через su!

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

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

sudo -u www-data id

Команда выполнится с UID и GID пользователя www-data, но текущий терминал останется вашим.

Например, можно проверить, имеет ли веб-приложение доступ к нужной директории:

sudo -u www-data ls -la /var/www/app

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

Также можно открыть shell от имени сервисного пользователя:

sudo -u postgres bash

Все команды внутри этого shell будут выполняться от имени postgres. Однако это не полноценный login shell: текущая директория и часть окружения могут сохраниться от исходного пользователя.

Если нужен shell с окружением, близким к обычному входу пользователя, используйте:

sudo -iu postgres

При отладке важно учитывать, что sudo -u не всегда воспроизводит реальное окружение работающего сервиса.

Например:

sudo -u node env

Эта команда покажет окружение, сформированное sudo, но оно может отличаться от окружения процесса, запущенного через systemd, Docker, Kubernetes, PM2 или другой менеджер процессов.

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

sudo -u www-data env APP_ENV=testing ./deploy.sh

Переменная APP_ENV будет доступна только этому процессу и его дочерним процессам. Глобальные настройки системы при этом не изменятся. Также важно: возможности sudo -u зависят от правил в sudoers. Разрешение на запуск shell, интерпретатора или произвольного скрипта может дать пользователю широкий доступ от имени целевой учётной записи.

🔥 sudo -u — удобный инструмент для проверки прав, отладки сервисов и запуска отдельных команд от имени системных пользователей без полноценного переключения сессии.

🚪 Linux Ready | #практика