Как переиспользовать команды из history?

Набрал длинную команду, но забыл sudo и получил отказ. Вместо перепечатывания просто можно повторить её с повышенными правами:

$ apt install nginx
$ sudo !!

Bash подставит предыдущую команду целиком и выполнит её с sudo.

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

$ !-2

Bash возьмёт команду по относительному номеру из history и выполнит её сразу.

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

$ !docker
$ !grep

Bash найдёт последнюю команду, начинающуюся с этого слова, и выполнит её.

Команда выполняется сразу. Для проверки можно добавить :p (например, !grep:p).

🔥 Это ускоряет работу в терминале кратно, особенно когда команды длинные и сложные.

🚪 Linux Ready | #совет

📂 Напоминалка как работает SSH!

Например, при подключении по SSH сначала устанавливается TCP-соединение, затем происходит согласование версий и алгоритмов, после чего выполняется key exchange и аутентификация по ключам.

На картинке — полный процесс: от установления соединения до выполнения команд внутри зашифрованного канала.

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

➡️ DevOps Ready | #ресурс

Пробрасываем локальный порт через SSH — доступ к закрытому сервису за одну команду!

Частый кейс: сервис крутится на удалённой машине, но слушает только localhost (например, база, админка, dev-сервер). Напрямую к нему не подключиться — но можно аккуратно протянуть порт к себе.

Команда:

ssh -L 8080:localhost:3000 user@remote-server

Что происходит: 8080 — локальный порт на твоей машине; localhost:3000 — адрес сервиса на удалённой машине; всё, что ты открываешь на localhost:8080, идёт через SSH на localhost:3000 на удалённой машине.

Теперь просто открываешь в браузере: http://localhost:8080
И видишь сервис с удалённой машины, даже если он не доступен извне.

Чтобы не держать терминал:

ssh -f -N -L 8080:localhost:3000 user@remote-server

Остановить можно, например:

pkill -f "ssh -L 8080"

Практический пример: PostgreSQL на сервере слушает только localhost:

ssh -L 5432:localhost:5432 user@remote-server

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

psql -h localhost -p 5432 -U user dbname

Если локальный порт уже занят — просто меняешь его:

ssh -L 9000:localhost:3000 user@remote-server

Важно: трафик шифруется через SSH, не нужно открывать порты на сервере; работает для любых TCP-сервисов (HTTP, DB, Redis и т.д.).

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

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

😎 krxnotes — информативные шпаргалки по Linux и системам!

Это структурированная коллекция заметок по Linux и смежным темам: процессы, файловые системы, shell и работа с ядром. Материал ориентирован на практическое понимание того, как устроена система на низком уровне. Информация подаётся в компактном формате без избыточной теории, с акцентом на реальные сценарии использования.

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

➡️ DevOps Ready | #репозиторий

Перехватываем вывод процесса через tee — лог и консоль одновременно!

Частый кейс: запускаешь задачу (деплой, миграция, билд) и хочешь одновременно видеть вывод в терминале и сохранять его в файл. Обычный редирект > убирает вывод из консоли. Решается через tee.

Команда:

command 2>&1 | tee output.log

Что происходит: 2>&1 объединяет stderr и stdout; tee дублирует поток — пишет в файл и выводит в терминал.

Добавление в файл (append):

command 2>&1 | tee -a output.log

Без потери кода возврата (важно для скриптов):

set -o pipefail
command 2>&1 | tee output.log
echo $?

Без pipefail код возврата будет от tee, а не от command.
echo $? нужно вызывать сразу после пайплайна, иначе значение перезапишется.

Альтернатива:

command 2>&1 | tee output.log
exit ${PIPESTATUS[0]}

Важно: PIPESTATUS нужно читать сразу после пайплайна, иначе он перезапишется.

Пример: деплой

set -o pipefail
./deploy.sh 2>&1 | tee deploy.log

Лог сохраняется, при этом видно всё в реальном времени.

Пример: долгий билд

make -j4 2>&1 | tee build.log

stderr не теряется, но порядок строк может перемешиваться (из-за параллельности и буферизации).

Разделение потоков с сохранением, stdout в файл, stderr отдельно:

command > >(tee out.log) 2> >(tee err.log >&2)

Используется process substitution (bash). stdout/stderr остаются в консоли, но порядок между потоками не гарантируется.

Пример: отладка пайплайна

tee raw.log < data.txt | grep error | tee filtered.log

Сохраняешь и исходные данные, и результат фильтрации.

Что это даёт: полный контроль над логами без потери интерактивности; удобно для CI, деплоя, отладки; прозрачная диагностика.

🔥 Ограничения и нюансы: pipe меняет код возврата (решается pipefail или PIPESTATUS); pipefail не POSIX (bash/zsh/ksh); некоторые программы буферизуют вывод; при больших потоках — нагрузка на диск.

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

📂 Напоминалка по сетевым протоколам и портам!

Например, HTTP (80) используется для обычного веб-трафика, SSH (22) — для удалённого доступа к серверу, а DNS (53) — для преобразования доменных имён в IP.

На картинке — базовые и наиболее часто используемые сетевые протоколы с портами и типами транспорта (TCP/UDP).

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

➡️ DevOps Ready | #ресурс

Как передавать файлы между машинами без scp, rsync и настройки SSH?

Когда нет доступа по SSH, сломан scp или нужно быстро скинуть файл между контейнерами, серверами или в изолированной сети — выручает netcat.

На принимающей стороне открываешь порт и пишешь всё в файл:

$ nc -l 9000 > output.bin
$ ls -lh output.bin

На отправляющей стороне отправляешь данные напрямую в сокет:

$ nc -N <host> 9000 < input.bin
$ echo done

Если нужен прогресс передачи:

$ pv input.bin | nc -N <host> 9000
или на приёме:
$ nc -l 9000 | pv > output.bin

Важно: без шифрования и аутентификации (использовать в доверенной сети), синтаксис может отличаться (например, BusyBox: nc -l -p 9000).

🔥 Работает даже в минимальных окружениях, контейнерах и rescue-системах, где кроме nc почти ничего нет.

🚪 Linux Ready | #совет

📂 Разбор DNS Record Types!

Это наглядная шпаргалка по основным DNS-записям. Таблица охватывает A и AAAA для IPv4/IPv6, CNAME для алиасов, MX для почты, PTR для reverse DNS, NS для name servers и TXT для произвольной информации.

Идеально для быстрого понимания, как DNS связывает домены, IP-адреса и почтовую инфраструктуру.

➡️ DevOps Ready | #ресурс

❤️ Ravesli — курс по Linux с разбором системы и практикой!

От базовых понятий и структуры системы до понимания дистрибутивов и принципов работы ОС. Материал построен последовательно и помогает сформировать целостное представление о Linux. Уроки ориентированы на системное понимание: объясняется не только работа команд, но и логика самой системы.

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

➡️ DevOps Ready | #сайт

Перехватываем вывод процесса через tee — лог и консоль одновременно!

Частый кейс: запускаешь задачу (деплой, миграция, билд) и хочешь одновременно видеть вывод в терминале и сохранять его в файл. Обычный редирект > убирает вывод из консоли. Решается через tee.

Команда:

command 2>&1 | tee output.log

Что происходит: 2>&1 объединяет stderr и stdout; tee дублирует поток — пишет в файл и выводит в терминал.

Добавление в файл (append):

command 2>&1 | tee -a output.log

Без потери кода возврата (важно для скриптов):

set -o pipefail
command 2>&1 | tee output.log
echo $?

Без pipefail код возврата будет от tee, а не от command.
echo $? нужно вызывать сразу после пайплайна, иначе значение перезапишется.

Альтернатива:

command 2>&1 | tee output.log
exit ${PIPESTATUS[0]}

Важно: PIPESTATUS нужно читать сразу после пайплайна, иначе он перезапишется.

Пример: деплой

set -o pipefail
./deploy.sh 2>&1 | tee deploy.log

Лог сохраняется, при этом видно всё в реальном времени.

Пример: долгий билд

make -j4 2>&1 | tee build.log

stderr не теряется, но порядок строк может перемешиваться (из-за параллельности и буферизации).

Разделение потоков с сохранением, stdout в файл, stderr отдельно:

command > >(tee out.log) 2> >(tee err.log >&2)

Используется process substitution (bash). stdout/stderr остаются в консоли, но порядок между потоками не гарантируется.

Пример: отладка пайплайна

tee raw.log < data.txt | grep error | tee filtered.log

Сохраняешь и исходные данные, и результат фильтрации.

Что это даёт: полный контроль над логами без потери интерактивности; удобно для CI, деплоя, отладки; прозрачная диагностика.

🔥 Ограничения и нюансы: pipe меняет код возврата (решается pipefail или PIPESTATUS); pipefail не POSIX (bash/zsh/ksh); некоторые программы буферизуют вывод; при больших потоках — нагрузка на диск.

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

❤️ Linux Cheatsheet — шпаргалка по Linux, которую стоит держать под рукой!

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

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

➡️ DevOps Ready | #репозиторий

Смотрим, какие capability выданы бинарнику!

Иногда программа запускается без root, но всё равно умеет открывать raw sockets, bind low ports или менять network stack. Обычно причина заключается в Linux capabilities.

Посмотреть capability бинарника:

getcap /usr/bin/ping

Часто увидишь что-то вроде:

cap_net_raw=ep

Это значит, что бинарник может работать с raw sockets без полного root-доступа.

Проверить capabilities всех бинарников в системе:

sudo getcap -r / 2>/dev/null

Так можно быстро найти потенциально опасные или нестандартные разрешения.

Выдать capability бинарнику:

sudo setcap cap_net_bind_service=+ep ./app

Теперь приложение сможет слушать порты ниже 1024 без root.

Например, запускать HTTP сервер сразу на 80:

./app

Удалить capability:

sudo setcap -r ./app

Посмотреть capabilities процесса:

grep Cap /proc/1234/status

🔥 Linux capabilities позволяют выдавать процессам точечные привилегии без полного root-доступа.

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

📂 Напоминалка по работе traceroute!

Например, traceroute показывает маршрут пакетов от компьютера до сервера, а за счёт TTL позволяет определить каждый промежуточный узел (hop) и задержку до него.

На картинке — наглядно разобран принцип работы traceroute: как увеличивается TTL, как роутеры отвечают через ICMP и как по шагам строится маршрут до конечного сервера.

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

➡️ DevOps Ready | #ресурс

📂 Напоминалка по прокси-серверам!

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

На картинке — наглядное сравнение Forward Proxy и Reverse Proxy: где они располагаются, как работают и для каких задач используются.

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

➡️ DevOps Ready | #ресурс

Знали, что можно корректно записывать в привилегированные файлы без запуска редактора от root?

Частая ошибка заключается в использовании sudo echo ... > file, что не работает ожидаемым образом, поскольку перенаправление выполняется текущим shell без привилегий.

tee решает эту проблему, так как сама утилита запускается с правами sudo и выполняет запись:

$ echo "option=1" | sudo tee /etc/app.conf
$ echo "option=2" | sudo tee -a /etc/app.conf

Флаг -a обеспечивает корректное добавление в файл без его перезаписи.

Можно применять шаблоны или генерируемые конфигурации напрямую:

$ generate_config | sudo tee /etc/app.conf
$ sudo tee /etc/app.conf < config.new

При этом сохраняется корректная модель прав доступа, отсутствуют временные файлы и исключаются ошибки, связанные с перенаправлением в shell.

🔥 Этот подход широко используется при автоматизации, конфигурации систем и в CI/CD сценариях.

🚪 Linux Ready | #совет

🐱 Awesome Sysadmin — огромная база инструментов для Linux и DevOps!

В этом репозитории собраны open-source инструменты для системного администрирования: мониторинг, логирование, backup, docker, kubernetes, безопасность, networking, автоматизация и всё, что нужно для работы с серверами и инфраструктурой. По сути это готовая база полезного софта для сисадминов, DevOps и backend-разработчиков.

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

➡️ DevOps Ready | #репозиторий