Linux: Системный администратор

Перевод статей из серии «Кунг-фу стиля Linux»: — Удобная работа с файлами по SSH — Мониторинг дисковой подсистемы — Глобальный поиск и замена строк с помощью ripgrep — Упрощение работы с awk — Наблюдение за файловой системой — Наблюдение за файлами — Удобный доступ к справке при работе с bash — Великая сила make — Устранение неполадок в работе incron — Расшаривание терминала в браузере — Синхронизация настроек — Бесплатный VPN по SSH — Превращение веб-приложений в полноценные программы — Утилита marker и меню для командной строки — sudo и поворот двух ключей — Программное управление окнами — Организация работы программ после выхода из системы — Регулярные выражения — Запуск команд — Разбираемся с последовательными портами — Базы данных — это файловые системы нового уровня — О повторении кое-каких событий сетевой истории — PDF для пингвинов — Делаем все и сразу — Файловые системы пользовательского пространства теперь доступны и в Windows — Делиться — это плохо — Автоматическое генерирование заголовочных файлов — Простые конвейеры #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🚨 Иногда сетевой интерфейс «пропадает» после перезагрузки, особенно на серверах с systemd-networkd. Причина - интерфейсы могут переименовываться (например, ens3 → enp0s3). Фиксируем имя интерфейса: 🔧 Решение через systemd-link 1. Узнаём MAC-адрес:

ip link show

2. Создаём правило:

cat >/etc/systemd/network/10-persistent.link <<EOF
[Match]
MACAddress=52:54:00:ab:cd:ef

[Link]
Name=lan0
EOF

3. Перезапускаем:

systemctl restart systemd-udevd
systemctl restart systemd-networkd

Теперь интерфейс всегда будет называться lan0. - Удобнее писать unit-файлы, firewall-правила и netplan-конфиги. - Избежите «сломанных» сетевых настроек после обновления/замены железа. 👉 Можно использовать Driver= или Path= вместо MAC, если карты одинаковые. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

Знакомая картина? Terraform-код превратился в спагетти, где одни и те же ресурсы копируются из проекта в проект, а малейшее изменение требует правок в десятках файлов. Вроде бы Infrastructure as Code должен упрощать жизнь, но на практике часто получается наоборот — код становится неподдерживаемым монстром. 📅 23 сентября в 20:00 Николай Акулов проведёт открытый вебинар «Terraform: паттерны, антипаттерны и модульность» в рамках курса «DevOps Advanced». Это практическое занятие для тех, кто хочет привести свою IaC в порядок и научиться строить масштабируемую инфраструктуру. На вебинаре разберут принципы эффективного DRY на практике → как правильно использовать модульность для повышения зрелости Terraform-проектов, какие антипаттерны встречаются чаще всего и как их избежать. Николай покажет лучшие практики работы с Terraform и даст рекомендации по оптимизации CI/CD пайплайнов. Особенно полезно будет DevOps-инженерам, инфраструктурным разработчикам и всем, кто работает с Infrastructure as Code. Спикер поможет научиться создавать переиспользуемые модули, распознавать ошибки проектирования и внедрять процессы автоматизации. 👉 Вебинар бесплатный, регистрация по ссылке — тема критически важная для эффективной работы с инфраструктурой: https://vk.cc/cPwhWd 🎁 Каждый участник вебинара получит бонус — скидку на полный курс. Главное — успеть записаться. Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

🚀 Быстрый способ отследить «зависшие» TCP-сессии Иногда сервис «висит», но порты открыты и соединения висят в ESTABLISHED. Классика: приложение не отвечает, но сокеты не закрываются. 🔍 Как проверить:

ss -tnao state established 'sport = :22'

-tnao - TCP, numeric, all, с таймерами; state established - только активные соединения; 'sport = :22' - фильтр по SSH (меняй на свой порт). 👉 Обрати внимание на колонку timer: on (keepalive,...) - соединение живое; on (timewait,...) или долго висит без активности → зомби-сессия. 🛠 Что делать: 1. Сбросить проблемные соединения:

ss -K dport = :22 state established

2. Добавить sysctl-тюнинг, чтобы ядро не держало «мертвяков» вечно:

sysctl -w net.ipv4.tcp_keepalive_time=300
sysctl -w net.ipv4.tcp_keepalive_probes=5
sysctl -w net.ipv4.tcp_keepalive_intvl=60

💡 Это помогает, если юзеры «обрываются» без выхода или при нестабильных VPN. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🔒 Автоблокировка SSH-брутфорса через nftables Даже если у тебя стоит fail2ban - иногда проще и быстрее решить задачу силами самого nftables. Минимум зависимостей, максимум контроля. Пример: бан по 5 неудачным попыткам за 1 минуту

table inet sshguard {
    set ssh_blacklist {
        type ipv4_addr
        flags timeout
        timeout 1h
    }

    map ssh_counter {
        type ipv4_addr : counter
    }

    chain input {
        type filter hook input priority 0;

        # Разрешаем локалку и уже забаненных
        ip saddr @ssh_blacklist drop

        tcp dport 22 ct state new add @ssh_counter { ip saddr } counter
        tcp dport 22 ct state new ip saddr @ssh_counter { ip saddr } >= 5 add @ssh_blacklist { ip saddr } drop

        # Разрешаем SSH по умолчанию (после фильтра)
        tcp dport 22 accept
    }
}

Как это работает - ssh_counter считает подключения по IP. - Если за минуту ≥5 попыток — IP летит в ssh_blacklist на 1 час. - Всё внутри одного ruleset’а, без демонов. 👉 Подходит для серверов, где хочется минимализма и нет нужды в сложных паттернах от fail2ban. 👉 Но осторожно: банится любой IP, даже если это сканер мониторинга или кривой клиент. Сохрани, пригодится 😉 #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🇷🇺 100% российская разработка INFRAX — платформа all-in-one для управления ИТ-инфраструктурой: ✅ Мониторинг инфраструктуры (ITOM) ✅ Удаленный доступ для сотрудников и привилегированных пользователей ✅ Обработка заявок пользователей (ServiceDesk) ✅ База знаний с разграничением доступа к категориям (публичные и закрытые) ✅ Автоматизация (скрипты и планировщик) ✅ Контроль привилегированных пользователей. Видеозапись сессий RDP/SSH/VNC. (PAM) ✅ Управление доступами. Доступ ко всем корпоративным сервисам через одну учетку (IAM) БЕСПЛАТНО до 100 пользователей! 🎁 👉 Попробовать INFRAX Реклама. ООО «АУДИТ-ТЕЛЕКОМ», ОГРН 1167746696776, erid: 2Vtzqv8Ag74

nftables: автобан SSH без fail2ban (динамические set’ы + rate-limit) Коротко: кладём “шумные” источники в чёрный список прямо из datapath - с авто-истечением и без внешних демонов. Подходит для брутфорса SSH и не только. Основано на limit rate over и динамических set с timeout. Шаги 1. Таблица/цепь (если ещё нет):

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

2. Два уровня списков: кратковременный “flood” и часовой “blackhole” (v4/v6):

# IPv4
nft add set inet filter ssh_flood4      '{ type ipv4_addr; flags dynamic; timeout 10s; size 131072; }'
nft add set inet filter ssh_blackhole4  '{ type ipv4_addr; flags dynamic; timeout 1h;  size 65536; }'

# IPv6
nft add set inet filter ssh_flood6      '{ type ipv6_addr; flags dynamic; timeout 10s; size 131072; }'
nft add set inet filter ssh_blackhole6  '{ type ipv6_addr; flags dynamic; timeout 1h;  size 65536; }'

flags dynamic + timeout обязательны для пополнения set’ов из правил; size - защита от OOM. Пример такой схемы есть в man nft.

3. Сначала рубим тех, кто уже в бане:

nft add rule inet filter input ip  saddr @ssh_blackhole4 drop
nft add rule inet filter input ip6 saddr @ssh_blackhole6 drop

4. Автобан SSH: >10 новых соединений/сек с одного источника ⇒ бан на 1 час: (используем добавление в set прямо из правила; limit rate over матчится на превышение порога)

# IPv4
nft add rule inet filter input tcp dport 22 ct state new \
    add @ssh_flood4     { ip  saddr limit rate over 10/second } \
    add @ssh_blackhole4 { ip  saddr timeout 1h } drop

# IPv6
nft add rule inet filter input tcp dport 22 ct state new \
    add @ssh_flood6     { ip6 saddr limit rate over 10/second } \
    add @ssh_blackhole6 { ip6 saddr timeout 1h } drop

Зачем и когда - Нативная альтернатива fail2ban на L3/L4: реакция в ядре, без лог-парсинга. - Хорошо для SSH/SMTP/HTTP-auth, анти-скан/скрэпинг, временное “blackhole”. - Порог/timeout легко подкручивать под трафик. Полезные трюки / предупреждения 🔎 Диагностика: nft list set inet filter ssh_blackhole4 и nft monitor ruleset - видно пополнение set’ов. 🎚️ Тюнинг детектора: добавьте burst 3 к limit, чтобы сгладить джиттер (по умолчанию 5 пакетов). 🧹 Снятие бана: nft delete element inet filter ssh_blackhole4 { 1.2.3.4 } или nft flush set inet filter ssh_blackhole4. 📐 Порядок правил: держите drop по @ssh_blackhole вверху input, раньше любых accept. 🧪 Если хочется “не более N коннектов одновременно”, используйте ct count over N (connlimit). Сохрани, пригодится. А ты так настраиваешь? #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

nftables без fail2ban: динамический бан брутфорса SSH (IPv4/IPv6) Задача: быстро отстреливать источники, ломающие ssh, без демонов и лог-парсеров. Решение - динамический set с таймаутом + правило, которое само добавляет нарушителя. Шаги 1. Создаём таблицу, набор и цепочку:

sudo nft -f - <<'EOF'
table inet fw {
  set ssh_bad {
    type inet_addr
    flags timeout
    timeout 1h      # дефолт для элементов
  }

  chain input {
    type filter hook input priority 0; policy accept;

    iif lo accept
    ct state established,related accept

    # уже занесённых — вон:
    ip saddr @ssh_bad drop

    # детект частых новых соединений на 22/tcp и бан + дроп:
    tcp dport 22 ct state new limit rate over 10/minute \
      add @ssh_bad { ip saddr timeout 2h } counter drop
  }
}
EOF

2. Ручное управление бан-листом (админ-бан/разбан):

sudo nft add element inet fw ssh_bad { 203.0.113.5 timeout 24h comment "manual" }
sudo nft delete element inet fw ssh_bad { 203.0.113.5 }

3. Наблюдение за изменениями сета (для отладки):

sudo nft monitor set

4. Персистентность (Debian/Ubuntu/RHEL/Alma):

# Проверь синтаксис и атомарно загрузись
sudo nft -c -f /etc/nftables.conf && sudo nft -f /etc/nftables.conf
sudo systemctl enable --now nftables

совет: вынеси блок в /etc/nftables.d/ssh-ban.nft и подключи include в /etc/nftables.conf.

Зачем и когда - Базовая защита от брутфорса без сторонних сервисов. - Подходит для edge/VM/контейнер-хостов, где не нужен полный fail2ban. - Работает в family inet → одна логика и для IPv4, и для IPv6. Трюки / best practices - limit rate over срабатывает только при превышении порога - нормальные пользователи не пострадают. - Не делай flush table inet fw в бою: обнулятся текущие баны (timeouts). Обновляй правила точечно (nft -a list ruleset, затем delete rule handle … / add rule …) или проверяй конфиг -c перед загрузкой. - Для нестандартных портов поменяй tcp dport 22 на свой. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

Сколько раз вы слышали истории о том, как злоумышленники получали доступ к Kubernetes-кластерам через неправильно настроенные права доступа или незащищённые секреты? В эпоху, когда контейнеризация стала стандартом, безопасность K8s — это уже не опция, а жизненная необходимость для любой серьёзной инфраструктуры. 📅 9 сентября в 20:00 Денис Шишикин проведёт открытый вебинар «Обеспечение безопасности в Kubernetes» в рамках курса «DevOps Advanced». Это практическое занятие для тех, кто хочет защитить свои кластеры от типовых угроз и научиться применять проверенные практики безопасности. На вебинаре разберут конкретные инструменты и подходы — механизмы контроля доступа через RBAC, ограничение привилегий подов с помощью Pod Security Admission, безопасную работу с секретами через Sealed Secrets. Денис покажет, как сканировать манифесты и кластеры с помощью Trivy и kube-bench. Особенно полезно будет DevOps-инженерам, системным администраторам и всем, кто работает с Kubernetes в продакшне. Спикер объяснит, какие угрозы характерны для K8s-кластеров и как проводить базовый аудит безопасности ресурсов и конфигураций. 👉 Вебинар бесплатный, но регистрация обязательна — места ограничены: https://vk.cc/cP9DCw 🎁 Каждый участник вебинара получит бонус — скидку на полный курс. Главное — успеть записаться. Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

🔐 Защищаем SSH с помощью Fail2Ban Всем привет! 👋 Сегодня поговорим о базовой, но крайне важной утилите для защиты вашего сервера - Fail2Ban. Если у вас есть сервер с доступом по SSH, этот пост для вас. Что такое Fail2Ban? Fail2Ban — это утилита, которая анализирует логи служб (например, SSH, Apache, Nginx) на предмет подозрительной активности, такой как многократные неудачные попытки входа. При обнаружении нарушителя (бота или злоумышленника), Fail2Ban автоматически блокирует его IP-адрес на определённое время с помощью файрвола. Как это защищает SSH? Основная угроза для SSH - это брутфорс-атаки (атаки перебором), когда боты пытаются подобрать ваш пароль, пробуя тысячи комбинаций. Fail2Ban эффективно противостоит этому: 1. Мониторинг логов: Он постоянно следит за файлом /var/log/auth.log (или аналогом в вашей системе). 2. Обнаружение аномалий: Если с одного IP-адреса поступает, скажем, 5 неудачных попыток входа подряд, Fail2Ban это замечает. 3. Блокировка: Утилита мгновенно добавляет правило в файрвол (например, iptables или ufw), которое блокирует этот IP-адрес. 4. Снятие блокировки: Через заданное время (например, 10 минут или час) IP-адрес автоматически разблокируется. Быстрая настройка для SSH (на примере Debian/Ubuntu) Настроить базовую защиту очень просто: 1. Установка:

    sudo apt update
    sudo apt install fail2ban
    

2. Создание локального конфигурационного файла: Никогда не редактируйте jail.conf! Создайте его копию jail.local, чтобы ваши настройки не перезаписались при обновлении.

    sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
    

3. Настройка jail.local: Откройте файл sudo nano /etc/fail2ban/jail.local и найдите секцию [sshd]. Убедитесь, что она включена:

    [sshd]
    enabled = true
    

Вы можете изменить стандартные параметры, например: - maxretry = 5 - количество неудачных попыток до бана. - bantime = 10m - время блокировки (10 минут). - findtime = 10m - временное окно, в течение которого считаются попытки. 4. Перезапуск службы:

    sudo systemctl restart fail2ban
    

5. Проверка статуса: Чтобы увидеть, заблокировал ли Fail2Ban кого-нибудь, используйте команду:

    sudo fail2ban-client status sshd
    

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

⚡ Когда iptables ≠ nftables: почему правила "не работают" Частая ошибка при настройке firewall на дистрибутивах (Ubuntu 22.04, Debian 12, RHEL 9): 🔹 админ вносит правила в iptables, но трафик не фильтруется. 👉 Причина - современные системы используют nf_tables backend, и старый iptables лишь транслируется в nftables. В итоге: часть правил "теряется" или конфликтует. Как проверить:

# какой бэкенд используется
iptables -V
# если увидите "nf_tables" — значит это не классический iptables

Что делать правильно: 1. Если нужен привычный iptables:

update-alternatives --config iptables

→ выбрать iptables-legacy (и для ip6tables тоже). 2. Лучше сразу перейти на nftables:

nft list ruleset
nft add rule inet filter input tcp dport 22 accept

Когда применять: - Если правила не применяются, хотя "вбиты" в iptables. - При миграции старых скриптов/ansible-ролей. - Для единообразия конфигураций в новых ОС. 💡 Новые проекты сразу вести на nftables. Старые - либо переводить, либо жёстко фиксировать iptables-legacy. #Linux@linux_odmin #Шпаргалка@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🔥 Быстро проверить, что слушает порт в Linux Иногда нужно понять, какой процесс занял порт (например, 80 или 443) и почему сервис не стартует. 🔎 Проверка через ss:

ss -ltnp | grep ':80'

-l — только listening сокеты -t — TCP -n — не резолвить имена -p — показывать PID/имя процесса Пример вывода:

LISTEN 0 128 *:80 *:* users:(("nginx",pid=1234,fd=6))

Альтернативы: lsof -i :80 — если привычнее через lsof fuser 80/tcp — быстрый вариант, сразу PID ⚡️ Когда полезно: при конфликте сервисов (Apache vs Nginx) при отладке firewall (порт слушает, но снаружи не доступен) при проверке автозапуска демонов 👉 Лайфхак: если процесс «убегает» после запуска, можно использовать ss -ltunp в цикле:

watch -n1 "ss -ltunp | grep ':80'"

Так поймаете короткоживущие процессы. #Linux@linux_odmin #Шпаргалка@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🔥 net.ipv4.conf.all.rp_filter - твой тихий телохранитель от IP spoofing Многие админы забывают, что rp_filter в Linux может спасти от подмены IP пакетов, но при кривой настройке ломает сложные маршруты. Проверка:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

Значения: - 0 - фильтр выключен - 1 - строгий режим (пакет отбрасывается, если обратный маршрут не совпадает с интерфейсом входа) - 2 - «loose mode» (разрешает асимметричную маршрутизацию, но всё ещё фильтрует spoof) Безопасная настройка для большинства серверов:

sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1

Для сложных схем с несколькими WAN:

sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.default.rp_filter=2

Применить навсегда:

cat >> /etc/sysctl.conf <<EOF
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
EOF
sysctl -p

💡 Когда включать strict (1) - одиночный WAN, простая маршрутизация. 💡 Когда loose (2) - мульти-WAN, policy routing, сложные VPN-топологии. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🚀 Быстрый контроль за соединениями через ss Когда нужно понять, кто держит соединение, какой порт занят или где «течёт» трафик — ss быстрее и информативнее, чем устаревший netstat. Пример: найти все процессы, слушающие порты TCP

ss -ltnp

-l — только прослушивающие сокеты -t — TCP -n — не пытаться резолвить имена -p — показать PID/имя процесса Активные установленные соединения:

ss -tn state established

Отфильтровать по порту:

ss -tn sport = :443

💡 ss может фильтровать по состояниям, адресам и портам прямо в команде — это экономит время при отладке сетевых проблем и поиске подозрительных подключений. Когда применять: - диагностика зависших сервисов - поиск «висящих» соединений - аудит входящих/исходящих подключений Сохрани, пригодится. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🔥 iptables: быстрое логирование и дроп подозрительных пакетов Иногда нужно понять, что именно ломится в сервер, но без спама в dmesg. Минимальный рабочий набор:

# 1. Создаём цепочку для логирования
sudo iptables -N LOG_DROP

# 2. Логируем с ограничением частоты (1 сообщение/сек)
sudo iptables -A LOG_DROP -m limit --limit 1/second -j LOG \
  --log-prefix "[FW DROP] " --log-level 4

# 3. Дропаем пакет
sudo iptables -A LOG_DROP -j DROP

# 4. Применяем к подозрительному трафику (пример: TCP 23)
sudo iptables -A INPUT -p tcp --dport 23 -j LOG_DROP

Где смотреть логи: - journalctl -k -f - или /var/log/kern.log (Debian/Ubuntu) 💡 Best practice: - Используйте -m limit, чтобы не утопить систему в логах - Для массового анализа можно отправлять в rsyslog с отдельным тегом Сохрани — пригодится, если нужно быстро вычислить мусорный трафик и отрезать его 🚫 #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🚀 Быстрый способ ограничить скорость на интерфейсе с tc Иногда нужно временно урезать пропускную способность - тест, симуляция плохого канала, защита от перегрузки. Делается это без лишних пакетов - встроенным Traffic Control. Пример: ограничим eth0 до 10 Мбит/с

# Очистить старые правила
tc qdisc del dev eth0 root 2>/dev/null

# Добавить qdisc с ограничением
tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms

🔹 rate - целевая скорость. 🔹 burst - размер «рывка» (буфер), лучше 2–3× MTU. 🔹 latency - допустимая задержка очереди. 📌 Проверка:

tc -s qdisc show dev eth0

📌 Сброс:

tc qdisc del dev eth0 root

💡 Когда полезно: - тестирование поведения приложений при низкой скорости; - эмуляция 3G/4G-сетей; - временное сдерживание исходящего трафика при ddos/backup. Сохрани, пригодится. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

ss вместо netstat: быстрое выявление зависших соединений netstat устарел, а вот ss работает быстрее и даёт больше деталей. Полезно, когда сервер "подвис" на куче TCP-сессий. Базовые приёмы: 1. Все активные TCP-соединения:

ss -tuna

(-t TCP, -u UDP, -n без DNS, -a все сокеты) 2. Сортировка по количеству соединений с IP:

ss -tan | awk '{print $6}' | sort | uniq -c | sort -nr | head

→ Быстро видим топ-источники трафика. 3. Состояния TCP (например, зависшие TIME-WAIT):

ss -tan state time-wait

4. Отбор по порту:

ss -tan sport = :443

Зачем? – Диагностика DDoS / "залипших" коннектов. – Поиск проблемных клиентов. – Быстрая альтернатива netstat без лишних зависимостей. 👉 ss -p — сразу показывает PID процесса, владеющего сокетом. Проверь свой сервер — удивишься количеству "мертвых" коннектов. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🚀 Netplan: быстрая настройка второго IP на интерфейсе Нужно добавить второй адрес без простоя? Netplan справится за пару секунд. 1. Редактируем конфиг:

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    ens33:
      addresses:
        - 192.168.1.10/24
        - 192.168.1.20/24   # ← второй IP
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

2. Применяем изменения без перезагрузки:

netplan apply

3. Проверяем:

ip a show ens33

Зачем так? – Удобно для быстрого тестирования сервисов. – Применяется атомарно (не рвёт соединения). – Работает одинаково в Ubuntu/Debian с Netplan. ⚠️ Трюк: можно применить временно:

netplan try

- изменения откатятся, если не подтвердить за 120 сек. Сохрани себе — выручит, когда надо быстро поднять доп. IP без рестарта сети. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

💡 Как я ускоряю поиск по логам в Linux Сегодня покажу вам приём, который не раз спасал мне нервы при анализе логов. Представим, что нужно найти ошибки в большом лог-файле, например /var/log/nginx/access.log. Обычно все начинают с:

cat access.log | grep "500"

Но это медленно. Лучше так:

grep "500" access.log

Ещё лучше — использовать less и внутри него grep-подобный поиск:

less +F access.log

А затем нажать /500 — и перейти по найденным совпадениям. Работает быстро, особенно на больших логах. А если хочется реального профита, то вот мой любимый трюк:

grep -E "500|502|503" access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

Что делает эта команда: - Ищет ошибки 500/502/503 - Извлекает IP-адреса (предположим, это первое поле) - Считает, сколько раз каждый IP дал ошибку - Показывает топ атакующих/плохих клиентов Эта команда — мини-аналитика в одну строку. Часто помогает сразу понять, где проблема. #Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin 👉 @linux_odmin

🔥 Bash-скрипт: Поиск больших файлов в системе Когда место на сервере внезапно заканчивается, найти "пожирателей" места бывает непросто. Вот простой скрипт, который покажет топ-20 самых больших файлов:

#!/bin/bash

# Где искать (по умолчанию — весь /)
SEARCH_DIR="/"

# Сколько файлов показывать
TOP=20

echo "=== Топ-$TOP самых больших файлов в $SEARCH_DIR ==="
find "$SEARCH_DIR" -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -n $TOP | awk '{printf "%10d MB  %s\n", $1/1024/1024, $2}'

Как использовать: 1. Сохраните в /usr/local/bin/bigfiles.sh. 2. Сделайте исполняемым:

   chmod +x /usr/local/bin/bigfiles.sh
   

3. Запускайте, например:

   /usr/local/bin/bigfiles.sh
   

#Linux@linux_odmin #Github@linux_odmin 👉 @linux_odmin