LinuxSkill - Сводки с прода и Шпаргалки
Следим за новостями Linux, DevOps и ИБ, чтобы быть готовым к любым факапам. Бонусом — плотные шпаргалки и чеклисты для ежедневной работы в терминале. 📩 По всем вопросам: @chorapov Зеркало в MAX: https://max.ru/LinuxSkill РКН https://vk.cc/cMUwm4
Mostrar más📈 Análisis del canal de Telegram LinuxSkill - Сводки с прода и Шпаргалки
El canal LinuxSkill - Сводки с прода и Шпаргалки (@linuxskill) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 10 676 suscriptores, ocupando la posición 11 405 en la categoría Tecnologías y Aplicaciones y el puesto 59 577 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 676 suscriptores.
Según los últimos datos del 18 octubre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -48, y en las últimas 24 horas de -1, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 10.84%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 4.67% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 1 157 visualizaciones. En el primer día suele acumular 499 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 9.
- Intereses temáticos: El contenido se centra en temas clave como docker, linux, bash, devops, скрипт.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Следим за новостями Linux, DevOps и ИБ, чтобы быть готовым к любым факапам.
Бонусом — плотные шпаргалки и чеклисты для ежедневной работы в терминале.
📩 По всем вопросам: @chorapov
Зеркало в MAX: https://max.ru/LinuxSkill
РКН https://vk.cc/cMUwm4”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 19 octubre, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
php-fpm начал зависать в любой момент и перестал отвечать на запросы? Это происходит из-за исчерпания ресурсов или процессов, ушедших в непрерываемое ожидание.
Вместо ручного поиска и убийства PID, давай настроим автоматический скрипт, который решит эту проблему за тебя.
📌 Авто-чистка зависших FPM
Этот скрипт ищет дочерние процессы php-fpm в состоянии D и принудительно завершает их, чтобы твой пул восстановился, используя базовые принципы Bash-сценариев.
# Ищем процессы FPM, застрявшие в D-состоянии
STUCK_PIDS=$(ps -o pid=,state= -C php-fpm | grep D | awk '{print $1}')
if [ -n "$STUCK_PIDS" ]; then
# Найдено: принудительно убиваем зависшие процессы (SIGKILL)
# Используй kill -9 только в крайних случаях!
echo "$STUCK_PIDS" | xargs kill -9
# Перезапускаем сервис для гарантированного восстановления
systemctl restart php-fpm
fi
💡 Фишка: Ты можешь запускать этот скрипт через cron или systemd.timer, чтобы автоматизировать траблшутинг. Это гарантирует стабильность твоего сервиса.
#Linux #Bash #DevOps #автоматизация #мониторингsystemd-analyze blame покажет точное время, которое каждый юнит потратил на запуск, сортируя их по убыванию.
# Выводит список юнитов, отсортированный по времени запуска
systemd-analyze blame
Назначение: Быстрый поиск юнитов, которые стартуют медленнее всего.
2. ⛓️ Поиск узкого места: Критическая цепочка
Если юнит стартует быстро, но при этом висит в топе, значит, он кого-то ждет. Нам нужно увидеть цепочку зависимостей, которая создает задержку.
# Анализ цепочки зависимостей, которая замедляет запуск системы
systemd-analyze critical-chain
Назначение: Показывает, какой именно юнит или зависимость блокирует загрузку критических служб.
Частый пример: docker.service ждет поднятия сети (systemd-networkd-wait-online.service). Это бессмысленно, если у Docker нет жесткой зависимости от сети на старте.
3. 🛠️ Устраняем задержку через override
Чтобы «отвязать» Docker от медленной сети, используем правильный подход systemd — не трогаем оригинальный файл юнита, а создаем прокладку override.conf:
# Открыть редактор для создания override.conf
sudo systemctl edit docker.service
# В открывшийся файл вставьте:
[Unit]
After=network.target
Wants=network.target
Назначение: Переопределяем параметры After и Wants, чтобы Docker не ждал некритичные сетевые службы.
После этого не забудьте применить изменения:
# Применить изменения
sudo systemctl daemon-reload
sudo systemctl restart docker
Важно: Использование systemctl edit создает отдельный файл, который не будет перезаписан при обновлении пакета Docker.
💡 Вывод: Регулярное использование systemd-analyze позволяет держать под контролем стартовую производительность сервера и избегать фантомный задержек, которые съедают рабочее время.
#Linux #systemd #CLI #DevOps #OptimizationTESTCHARS=2
SHABANG='#!'
FILE="$1" # Берем имя файла из аргумента
# Проверяем первые 2 символа
if [[ $(head -c$TESTCHARS "$FILE") = "$SHABANG" ]]; then
echo "✅ Файл $FILE — сценарий."
fi# Скачать и запустить проверку доступности зарубежных сервисов (YouTube, TikTok, ChatGPT и др.)
curl -sL https://check.foreign.services.sh | bash
Как это работает:
1. curl -sL скачивает скрипт (содержит набор пингов и DNS-запросов к актуальным зарубежным IP).
2. | bash передает его сразу на выполнение в Bash. Результат выводится мгновенно.
💡 Вывод
Теперь ты за секунду знаешь, можно ли использовать эту VPS для работы с гео-зависимыми сервисами. Если проверка пройдена, можешь смело приступать к настройке.
#Linux #Bash #DevOps #VPS #CLI #Securitysudo su -
Привет, цифровой архитектор!
Ты, вероятно, сталкивался с советом, как избавиться от постоянного ввода sudo при работе с Docker. Решение простое: добавить своего пользователя в группу docker. Удобно? Да. Но это одна из самых критических ошибок безопасности в Linux!
В этом посте разберем, почему добавлять пользователя в группу docker равносильно вручению ему полных прав root на хост-машине.
📌 Ошибка: Запуск Docker без sudo
Для удобства многие инженеры выполняют всего одну команду:
# Не делай так, если не понимаешь рисков!
sudo usermod -aG docker $(whoami)
С этого момента любой член группы docker может выполнять команды Docker. Но проблема в том, что Docker-демон по умолчанию работает от имени root.
🚨 Почему это критическая уязвимость?
Если пользователь может управлять Docker-демоном без ограничений, он может запустить контейнер, который способен:
1. Смонтировать корневую файловую систему хост-машины (например, /) в контейнер.
2. Получить полный доступ к /etc/shadow (теневой файл паролей) и другим критическим системным файлам.
3. Выполнить любую команду от имени root на хосте.
В результате, член группы docker может легко повысить свои привилегии до суперпользователя, полностью обходя систему sudo.
💡 Вывод: Практика, которая ломает всё
Использование группы docker ломает фундаментальный принцип изоляции привилегий в Linux. Удобство не стоит безопасности.
Если ты используешь это решение, ты должен понимать, что любой злоумышленник, получивший доступ к этой учетной записи, получит безусловный доступ к хост-системе.
#Docker #Security #Linux #SysAdmin #DevOps