Скрипт для просмотра внешних сетевых соединений по процессам
Иногда полезно знать, какие программы на вашем компьютере выходят в интернет.
1.
•
•
•
•
•
2. Фильтрация внешних соединений
•
• Исключает все локальные соединения, оставляя только внешние IP.
3. Извлечение PID и имени процесса
•
•
4. Вывод в удобной форме
Иногда полезно знать, какие программы на вашем компьютере выходят в интернет.
#!/usr/bin/env bash
# Вывод заголовка
echo "Активные сетевые соединения (внешние)"
echo
# Получаем список соединений (TCP/UDP) с PID и именами процессов
ss -tunpH | awk '
# Фильтруем только внешние соединения (не localhost)
$5 !~ /(127\.0\.0\.1|::1)/ {
# Извлекаем PID процесса
match($0, /pid=([0-9]+)/, p)
# Извлекаем имя процесса
match($0, /"([^"]+)"/, c)
# Выводим красиво: PID, имя процесса и удалённый адрес
printf "PID: %-6s ПРОГРАММА: %-15s -> %s\n", p[1], c[1], $5
}'
1.
ss -tunpH•
-t — TCP соединения•
-u — UDP соединения•
-n — показывать IP и порты без преобразования в имена•
-p — показать PID и имя процесса•
-H — без заголовка2. Фильтрация внешних соединений
•
$5 !~ /(127\.0\.0\.1|::1)/• Исключает все локальные соединения, оставляя только внешние IP.
3. Извлечение PID и имени процесса
•
match($0, /pid=([0-9]+)/, p) → PID•
match($0, /"([^"]+)"/, c) → имя программы4. Вывод в удобной форме
PID: 1234 ПРОГРАММА: firefox -> 172.217.16.142:443
PID: 982 ПРОГРАММА: ssh -> 18.197.45.22:22Классическая форк-бомба :(){ :|:& };: в современных версиях Ubuntu (начиная примерно с 18.04–20.04 и точно в 22.04/24.04) не крашит систему, как это было в старых дистрибутивах.
Почему она "не работает"
Ubuntu использует
Когда форк-бомба доходит до этого лимита:
• Дальнейшие fork() начинают падать с ошибкой (bash выдаёт кучу "fork: retry: Resource temporarily unavailable").
• Процессор нагружается на короткое время (несколько секунд–минут).
• Затем всё успокаивается: лишние процессы умирают или просто висят, система остаётся отзывчивой.
Дополнительно может сработать OOM Killer (если памяти не хватит), но в большинстве случаев даже до этого не доходит.
Почему она "не работает"
Ubuntu использует
systemd, который автоматически создаёт для каждого пользователя отдельный cgroup (контроллер ресурсов). По умолчанию в systemd установлен лимит на максимальное количество задач (processes + threads) для одного пользователя — обычно около 33% от системного максимума (kernel.threads-max), что даёт примерно 10–15 тысяч процессов (зависит от конфигурации машины).Когда форк-бомба доходит до этого лимита:
• Дальнейшие fork() начинают падать с ошибкой (bash выдаёт кучу "fork: retry: Resource temporarily unavailable").
• Процессор нагружается на короткое время (несколько секунд–минут).
• Затем всё успокаивается: лишние процессы умирают или просто висят, система остаётся отзывчивой.
Дополнительно может сработать OOM Killer (если памяти не хватит), но в большинстве случаев даже до этого не доходит.
Скачали ISO-образ Ubuntu или программу — проверить, что файл не повреждён и не подменён.
Или сразу проверить:
#На сайте обычно дают SHA256 хеш, например:
# 1a2b3c4d...
sha256sum ubuntu-24.04.iso
# Сравнить вывод с тем, что на сайте
Или сразу проверить:
Bashecho "1a2b3c4d... ubuntu-24.04.iso" | sha256sum --check
# Выведет OK или FAILED
Автоматическая смена обоев из папки
Каждый час ставить новый фон рабочего стола из папки с картинками.
Cкрипт
В cron:
Каждый час ставить новый фон рабочего стола из папки с картинками.
Cкрипт
change_wallpaper.sh — для GNOME:Bash#!/bin/bash
wallpapers=~/pictures/wallpapers/*
random_wall=$(shuf -n1 -e $wallpapers)
gsettings set org.gnome.desktop.background picture-uri "file://$random_wall"
gsettings set org.gnome.desktop.background picture-uri-dark "file://$random_wall"
В cron:
cron0 * * * * /path/change_wallpaper.shАвтоматически выключаем компьютер в определённое время
Выключать ПК каждый день в 23:00 (например, для детского ПК).
Простое решение (в cron):
Или с предупреждением за 10 минут:
Выключать ПК каждый день в 23:00 (например, для детского ПК).
Простое решение (в cron):
cron0 23 * * * shutdown -h nowИли с предупреждением за 10 минут:
cron50 22 * * * wall "Компьютер выключится через 10 минут!"
0 23 * * * shutdown -h now«Xargs: как обрабатывать вывод команд пачками (параллельно!)»
Pipe в Bash крут, но xargs делает его мощнее: берёт ввод и передаёт аргументами другой команде.
Полезно для больших списков (файлы, PID).
Пример: убить процессы по grep
Пояснение:
Практика: с find —
Pipe в Bash крут, но xargs делает его мощнее: берёт ввод и передаёт аргументами другой команде.
Полезно для больших списков (файлы, PID).
-P для параллели.Пример: убить процессы по grep
ps aux | grep "myapp" | awk '{print $2}' | xargs -P 4 killПояснение:
grep находит, awk берёт PID ($2), xargs kill'ит параллельно 4 штуки (-P4).Практика: с find —
find . -name "*.tmp" | xargs rm (без -exec). Экономит время на серверах.Бывает, сервер или рабочая машина начинает «думать» дольше обычного: команды висят, интерфейс лагает, SSH отвечает с задержкой. Не паникуем — 90% случаев решаются системной диагностикой.
Полный чек-лист, когда что-то тормозит:
Шаг 1: Общая картина — что жрёт ресурсы прямо сейчас
Сразу запускаем
Что смотреть:
• CPU: если все ядра на 100% — ищем процесс вверху списка (сортировка по %CPU — нажми F6 → %CPU).
• RAM/Swap: если Swap активно используется (жёлтая полоска) — нехватка памяти, процесс убивает OOM-killer.
• Load Average (вверху): три числа — 1/5/15 мин. Если на 4-ядерной машине >8-12 — перегрузка.
Альтернатива без htop:
Шаг 2: Память — free и vmstat
Ключевые колонки в vmstat:
• r — процессы в очереди на CPU (если > числа ядер — CPU bottleneck)
• b — процессы в uninterruptible sleep (обычно I/O wait)
• si/so — swap in/out (если не нули — памяти не хватает)
• wa — % CPU в I/O wait (высокий — диски тормозят)
Шаг 3: Диски — iostat и iotop
В iostat смотрим:
• %util близко к 100% — диск загружен полностью
• await > 20-30 ms — медленный отклик (SSD должно быть <1 ms)
• svctm устарело, но если высокое — проблемы
Если NVMe/SSD, а util 100% — часто виноваты большие логи или бэкапы.
Шаг 4: CPU детально — mpstat и pidstat
Поможет понять: один поток жрёт одно ядро или нагрузка равномерная.
Шаг 5: Исторические данные — sar (sysstat)
Если проблема не постоянная:
Sysstat по умолчанию собирает данные каждые 10 мин — золотой источник для ночных тормозов.
Шаг 6: Конкретный процесс — strace и perf
Если виновник известен (например, mysqld или java):
Шаг 7: Ядро и аппаратные проблемы
Частые виновники: ошибки диска, перегрев, сетевые драйверы.
Шаг 8: Сеть — если тормозит только удалённо
Полный чек-лист, когда что-то тормозит:
Шаг 1: Общая картина — что жрёт ресурсы прямо сейчас
Сразу запускаем
htop (если нет — sudo apt install htop или dnf install htop).Что смотреть:
• CPU: если все ядра на 100% — ищем процесс вверху списка (сортировка по %CPU — нажми F6 → %CPU).
• RAM/Swap: если Swap активно используется (жёлтая полоска) — нехватка памяти, процесс убивает OOM-killer.
• Load Average (вверху): три числа — 1/5/15 мин. Если на 4-ядерной машине >8-12 — перегрузка.
Альтернатива без htop:
top (Shift+P — сортировка по CPU, Shift+M — по MEM).Шаг 2: Память — free и vmstat
free -h # сколько реально свободно
vmstat -w 1 10 # каждую секунду 10 разКлючевые колонки в vmstat:
• r — процессы в очереди на CPU (если > числа ядер — CPU bottleneck)
• b — процессы в uninterruptible sleep (обычно I/O wait)
• si/so — swap in/out (если не нули — памяти не хватает)
• wa — % CPU в I/O wait (высокий — диски тормозят)
Шаг 3: Диски — iostat и iotop
iostat -xz 1 10 # расширенная стат-а каждую сек.
iotop # как htop, но для I/O (нужен root)В iostat смотрим:
• %util близко к 100% — диск загружен полностью
• await > 20-30 ms — медленный отклик (SSD должно быть <1 ms)
• svctm устарело, но если высокое — проблемы
Если NVMe/SSD, а util 100% — часто виноваты большие логи или бэкапы.
Шаг 4: CPU детально — mpstat и pidstat
mpstat -P ALL 1 10 # нагрузка по каждому ядру
pidstat -u 1 10 # CPU по процессам со временемПоможет понять: один поток жрёт одно ядро или нагрузка равномерная.
Шаг 5: Исторические данные — sar (sysstat)
Если проблема не постоянная:
sar -u 10 5 # CPU сейчас
sar -r # память за день
sar -d # диски за день
sar -n DEV # сетьSysstat по умолчанию собирает данные каждые 10 мин — золотой источник для ночных тормозов.
Шаг 6: Конкретный процесс — strace и perf
Если виновник известен (например, mysqld или java):
strace -p PID -c
# системные вызовы и сколько времени на них
perf top -p PID
# что именно в CPU жрёт (нужен kernel-headers)
perf record -p PID -g sleep 10; perf report
# профилированиеШаг 7: Ядро и аппаратные проблемы
dmesg -T --follow
# последние сообщения ядра с читаемыми датами
cat /proc/interrupts
# если один IRQ очень высокий — драйвер/устройствоЧастые виновники: ошибки диска, перегрев, сетевые драйверы.
Шаг 8: Сеть — если тормозит только удалённо
iftop # кто сколько трафика жрёт
nethogs # по процессам
ping -c 4 google.com
mtr google.com # трассировка + пингVDI нужен там, где важно быстро выдавать рабочие места, держать доступ под контролем и не превращать поддержку пользователей в бесконечный хаос. Если удалёнка, филиалы или много однотипных рабочих мест, VDI экономит недели администрирования.
На открытом уроке разберёте архитектуру VDI на базе Microsoft RDS, полный цикл развертывания и настройку удалённого доступа. Без абстракций, с понятной схемой, что и зачем поднимается.
→ Записаться на открытый урок курса «Администратор Windows»: https://otus.pw/JbKh/
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
На открытом уроке разберёте архитектуру VDI на базе Microsoft RDS, полный цикл развертывания и настройку удалённого доступа. Без абстракций, с понятной схемой, что и зачем поднимается.
→ Записаться на открытый урок курса «Администратор Windows»: https://otus.pw/JbKh/
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
Очищаем дисковый кэш в Linux
Linux кэширует файлы в свободной RAM — это ускоряет всё. Но иногда нужно сбросить кэш. Полезно. когда нужен честный бенчмарк скорости диска диагностика памяти либо тесты в VM/контейнерах
Не делай это регулярно — кэш заполнится заново, а производительность упадёт.
Главная команда:
Цифры:
• 1 — только данные файлов
• 2 — метаданные
• 3 — всё
Проверка:
buff/cache резко упадёт → больше free.
Альтернатива:
Готовый one-liner для теста диска:
Мини-скрипт:
Не ставь в cron — хуже будет. Linux сам управляет кэшем лучше нас.
Linux кэширует файлы в свободной RAM — это ускоряет всё. Но иногда нужно сбросить кэш. Полезно. когда нужен честный бенчмарк скорости диска диагностика памяти либо тесты в VM/контейнерах
Не делай это регулярно — кэш заполнится заново, а производительность упадёт.
Главная команда:
sudo sync
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'Цифры:
• 1 — только данные файлов
• 2 — метаданные
• 3 — всё
Проверка:
free -h | grep Membuff/cache резко упадёт → больше free.
Альтернатива:
sudo sysctl -w vm.drop_caches=3Готовый one-liner для теста диска:
sudo sync; echo 3 > /proc/sys/vm/drop_caches; dd if=/bigfile of=/dev/null bs=1M status=progressМини-скрипт:
#!/bin/bash
free -h | grep Mem
sudo sync; echo 3 > /proc/sys/vm/drop_caches
free -h | grep Mem
echo "Кэш сброшен"
Не ставь в cron — хуже будет. Linux сам управляет кэшем лучше нас.
GNU Autotools - классический набор инструментов для автоматизации сборки ПО под Unix-подобные системы. Появился в 1990-х и до сих пор используется в тысячах open-source проектов.
Главная цель Autotools — сделать исходный код портативным: один и тот же тарбол должен собираться на разных дистрибутивах, архитектурах, с разными версиями компилятора и библиотек, без ручной правки Makefile под каждую систему.
Основные компоненты Autotools:
Autoconf
Генерирует скрипт
configure — это shell-скрипт, который при запуске проверяет систему:
• есть ли нужные заголовки, библиотеки, функции
• какой компилятор, какие флаги
• где лежат зависимости (например, pkg-config)
На выходе — настроенный Makefile и config.h.
Automake
Из файла
Позволяет писать простые декларативные правила вместо огромных ручных Makefile.
Libtool
Упрощает сборку и использование shared-библиотек на разных платформах (особенно где
M4
Макро-процессор, на котором построены Autoconf и Automake. В
Дополнительно: gettext (для интернационализации), aclocal и т.д.
Как это работает на практике:
Разработчик проекта:
1. Пишет
2. Запускает
3. Коммитит только эти файлы + вспомогательные (NEWS, README, AUTHORS).
Пользователь (или дистрибутив):
Пример простого
Главная цель Autotools — сделать исходный код портативным: один и тот же тарбол должен собираться на разных дистрибутивах, архитектурах, с разными версиями компилятора и библиотек, без ручной правки Makefile под каждую систему.
Основные компоненты Autotools:
Autoconf
Генерирует скрипт
configure из файла configure.ac (или configure.in).configure — это shell-скрипт, который при запуске проверяет систему:
• есть ли нужные заголовки, библиотеки, функции
• какой компилятор, какие флаги
• где лежат зависимости (например, pkg-config)
На выходе — настроенный Makefile и config.h.
Automake
Из файла
Makefile.am генерирует Makefile.in - шаблон Makefile, который потом подставляется в Autoconf.Позволяет писать простые декларативные правила вместо огромных ручных Makefile.
Libtool
Упрощает сборку и использование shared-библиотек на разных платформах (особенно где
.so, .dylib, .dll отличаются).M4
Макро-процессор, на котором построены Autoconf и Automake. В
configure.ac вы пишете макросы M4.Дополнительно: gettext (для интернационализации), aclocal и т.д.
Как это работает на практике:
Разработчик проекта:
1. Пишет
configure.ac и Makefile.am.2. Запускает
autoreconf -i (или старый autotools набор команд: aclocal → autoconf → automake).3. Коммитит только эти файлы + вспомогательные (NEWS, README, AUTHORS).
Пользователь (или дистрибутив):
./configure # проверяет систему, генерирует Makefile
make # сборка
sudo make install # установкаПример простого
configure.ac:mAC_INIT([myprog], [1.0], [[email protected]])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUTHyper-V часто стоит рядом, но у многих остаётся туманом. В итоге виртуалки создаются наугад, сети работают странно, диски растут как попало, а тестовый контур превращается в лотерею.
На открытом уроке вы разберёте базу Hyper-V. Установка и первичная настройка роли, создание виртуальной машины, работа с виртуальными дисками и виртуальными сетями, типовые сценарии применения в инфраструктуре.
→ Записаться на открытый урок курса «Администратор Windows»: https://otus.pw/ayQZ/
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
На открытом уроке вы разберёте базу Hyper-V. Установка и первичная настройка роли, создание виртуальной машины, работа с виртуальными дисками и виртуальными сетями, типовые сценарии применения в инфраструктуре.
→ Записаться на открытый урок курса «Администратор Windows»: https://otus.pw/ayQZ/
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
iconv: превращаем «????????» обратно в нормальный русский текст
В старых файлах, при копировании с Windows, в логах или при парсинге данных из разных источников часто появляется классика: вместо «
Проблема кодировки. И лучший инструмент для её решения в Linux — утилита
Установка (если вдруг нет):
Основные опции:
•
•
•
•
Примеры:
1. Конвертация файла на месте
Файл text.txt в CP1251, нужно в UTF-8:
Потом можно перезаписать оригинал:
2. Через stdin/stdout (в пайплайне)
Или с curl:
3. Автоопределение кодировки + конвертация
iconv не угадывает сам, но комбинируем с file или uchardet:
4. Массовое конвертирование всех файлов в директории
____________________
если iconv ругается «
В старых файлах, при копировании с Windows, в логах или при парсинге данных из разных источников часто появляется классика: вместо «
Привет, мир» вы видите «ÐŸÑ€Ð¸Ð²ÐµÑ‚, мир» или полные кракозябры.Проблема кодировки. И лучший инструмент для её решения в Linux — утилита
iconv.iconv — часть GNU libc, конвертирует текст из одной кодировки в другую. Поддерживает сотни encoding’ов: UTF-8, CP1251, KOI8-R, ISO-8859-1, CP866 и т.д.Установка (если вдруг нет):
sudo apt install iconv
# на Debian/Ubuntu уже есть в libc6
# или просто проверьте: iconv --versionОсновные опции:
•
-f — from (исходная кодировка)•
-t — to (целевая кодировка)•
-o — файл вывода•
--list — показать все поддерживаемые кодировки (их > 1000!)Примеры:
1. Конвертация файла на месте
Файл text.txt в CP1251, нужно в UTF-8:
iconv -f CP1251 -t UTF-8 text.txt -o text_utf8.txt
Потом можно перезаписать оригинал:
iconv -f CP1251 -t UTF-8 text.txt > text.txt.tmp && mv text.txt.tmp text.txt
2. Через stdin/stdout (в пайплайне)
cat old_file.txt | iconv -f KOI8-R -t UTF-8
Или с curl:
curl -s https://old-site.ru/page | iconv -f CP1251 -t UTF-8
3. Автоопределение кодировки + конвертация
iconv не угадывает сам, но комбинируем с file или uchardet:
# Сначала узнаём кодировку
file -i old_file.txt
# или
uchardet old_file.txt
# Потом конвертируем
iconv -f $(uchardet old_file.txt) -t UTF-8 old_file.txt -o new_file.txt
4. Массовое конвертирование всех файлов в директории
for file in *.txt; do
iconv -f CP1251 -t UTF-8 "$$ file" -o " $${file%.txt}_utf8.txt"
done
____________________
если iconv ругается «
illegal input sequence» — добавьте //IGNORE или //TRANSLIT:iconv -f CP1251 -t UTF-8//TRANSLIT//IGNORE bad_file.txt
TRANSLIT — заменит неизвестные символы на похожие, IGNORE — просто пропустит.Preload — это фоновая служба, которая анализирует, какие программы вы чаще всего запускаете, и предзагружает их библиотеки (
При следующем запуске система берёт всё из RAM, а не читает с диска.
После установки (
Настройка (по желанию):
Конфиг в
После правки:
Проверяем, что работает:
.so), бинарники и зависимости в кэш страниц памяти.При следующем запуске система берёт всё из RAM, а не читает с диска.
После установки (
sudo apt install preload ) автоматически стартует как systemd-сервис.Настройка (по желанию):
Конфиг в
/etc/preload.conf. Основные параметры:
# Количество процессов для отслеживания (по умолчанию 150–200)
model.cachesize = 200
# Какие директории сканировать (добавьте свои)
map.minimum = /usr/bin:/usr/local/bin:/usr/games:/bin:/sbin:/usr/sbin
# Исключить ненужное (например, редко используемые)
exclude = /usr/bin/rare_app /usr/lib/firefox/firefox-bin
# Частота обновления модели (в секундах)
cycle = 3600После правки:
sudo systemctl restart preloadПроверяем, что работает:
# статус службы sudo systemctl status preload
# лог предзагрузок
cat /var/log/preload.log
# вручную обновить модель
sudo preload-predictОбработка артефактов сканирований. Сканирование запустили — а что дальше
Запустить security-сканер — лишь половина дела. Гораздо сложнее превратить результаты сканирования в рабочий процесс, который действительно приводит к исправлению уязвимостей, а не к накоплению отчётов «на складе».
На открытом уроке разберём, как выстраивать работу с артефактами сканирований в GitLab CI/CD. Поговорим о хранении результатов, передаче их разработчикам и настройке security gates, которые автоматически влияют на сборку и релиз. Обсудим, как встроить безопасность в пайплайн так, чтобы она работала системно и не превращалась в формальность.
Урок будет полезен DevSecOps и AppSec-специалистам, DevOps/SRE-инженерам и тимлидам, которые хотят наладить управляемый поток обработки результатов security-сканирований.
→ Вебинар проходит в формате открытого урока курса «Внедрение и работа в DevSecOps»: https://otus.pw/vk3e/
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
Запустить security-сканер — лишь половина дела. Гораздо сложнее превратить результаты сканирования в рабочий процесс, который действительно приводит к исправлению уязвимостей, а не к накоплению отчётов «на складе».
На открытом уроке разберём, как выстраивать работу с артефактами сканирований в GitLab CI/CD. Поговорим о хранении результатов, передаче их разработчикам и настройке security gates, которые автоматически влияют на сборку и релиз. Обсудим, как встроить безопасность в пайплайн так, чтобы она работала системно и не превращалась в формальность.
Урок будет полезен DevSecOps и AppSec-специалистам, DevOps/SRE-инженерам и тимлидам, которые хотят наладить управляемый поток обработки результатов security-сканирований.
→ Вебинар проходит в формате открытого урока курса «Внедрение и работа в DevSecOps»: https://otus.pw/vk3e/
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576