LinuxSkill - Сводки с прода и Шпаргалки
Следим за новостями Linux, DevOps и ИБ, чтобы быть готовым к любым факапам. Бонусом — плотные шпаргалки и чеклисты для ежедневной работы в терминале. 📩 По всем вопросам: @chorapov Зеркало в MAX: https://max.ru/LinuxSkill РКН https://vk.cc/cMUwm4
Больше📈 Аналитический обзор Telegram-канала LinuxSkill - Сводки с прода и Шпаргалки
Канал LinuxSkill - Сводки с прода и Шпаргалки (@linuxskill) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 10 740 подписчиков, занимая 11 158 место в категории Технологии и приложения и 59 600 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 10 740 подписчиков.
Согласно последним данным от 01 сентября, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -51, а за последние 24 часа — 0, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 11.69%. В первые 24 часа после публикации контент обычно набирает 4.80% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 1 256 просмотров. В течение первых суток публикация набирает 516 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 3.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как docker, linux, bash, devops, скрипт.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Следим за новостями Linux, DevOps и ИБ, чтобы быть готовым к любым факапам.
Бонусом — плотные шпаргалки и чеклисты для ежедневной работы в терминале.
📩 По всем вопросам: @chorapov
Зеркало в MAX: https://max.ru/LinuxSkill
РКН https://vk.cc/cMUwm4”
Благодаря высокой частоте обновлений (последние данные получены 02 сентября, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
sshd), который обеспечивает безопасное удаленное подключение к твоему серверу по протоколу SSH, — это то, с чего начинается любая административная работа. Конфигурация OpenSSH-сервера обычно хранится в файле /etc/ssh/sshd\_config.
Доступ к TCP-порту 22 (порт SSH по умолчанию) желательно ограничивать от публичного доступа. Вот замечания по ключевым директивам, которые помогут тебе повысить безопасность:
1️⃣ Аутентификация по паролю
Ты можешь оставить аутентификацию по паролю (PasswordAuthentication yes) на всякий случай, потому что при использовании несловарного пароля подобрать его злоумышленнику практически нереально.
PasswordAuthentication yes
- Закрываем ботов: Если ты решишь полностью отключить аутентификацию по паролю (PasswordAuthentication no), это немедленно отсечет большинство ботов, которые пытаются подобрать пароли, и твой журнал будет менее замусорен.
- Защита от перебора: По умолчанию разрешено 6 попыток аутентификации (MaxAuthTries 6). Ты можешь ограничить это число, например, до четырех (MaxAuthTries 4).
- Пустые пароли: Директива PermitEmptyPasswords no должна быть включена всегда, чтобы запрещать вход с пустым паролем.
2️⃣ Аутентификация с использованием публичных ключей
Это более надежный метод, чем аутентификация по паролю. По умолчанию он включен (PubkeyAuthentication yes). OpenSSH поддерживает несколько типов ключей, включая RSA, ECDSA и Ed25519.
- Преимущества Ed25519: Ключи Ed25519 основаны на эллиптических кривых и многими считаются обеспечивающими превосходную безопасность по сравнению с RSA. На практике они также намного короче.
- Файл ключей: Твой открытый ключ, который ты используешь для аутентификации, должен быть скопирован в файл ~/.ssh/authorized_keys на удаленном хосте.
💡 Вывод:
Помни, что SSH предназначен для обеспечения безопасного входа в оболочку и шифрует все данные сеанса. Если ты используешь OpenSSH, то настройки сервера хранятся в файле /etc/ssh/sshd\_config.
#Linux #DevOps #Security #SSHD #Ed25519👉 На вебинаре вы узнаете: -Что такое Patroni и как он обеспечивает высокую доступность PostgreSQL. -Как etcd используется для хранения конфигурации и координации работы узлов. -Как настроить репликацию, failover и проверку состояния кластера. -Как мониторить и тестировать отказоустойчивость PostgreSQL-кластера на практике. 💪 В результате вебинара вы: -Научитесь разворачивать кластер PostgreSQL с Patroni и etcd. -Поймёте архитектуру высокой доступности и роль каждого компонента. -Сможете настроить автоматическое переключение master/replica при сбоях. -Получите практическое понимание принципов отказоустойчивости баз данных🎁 Все участники вебинара получат специальные условия на полное обучение курса "Инфраструктура высоконагруженных систем" 👉 Для участия зарегистрируйтесь https://otus.pw/7Gef/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
👉 На вебинаре вы узнаете: - Как организовать автоматизированный процесс деплоя с помощью GitLab CI и Ansible. - Как использовать Ansible Playbooks и Roles для управления инфраструктурой. - Лучшие практики по обновлению сервисов без даунтайма и обработке ошибок. 💪 В результате вебинара вы: - Вы освоите автоматизацию CD-процессов с Ansible и GitLab CI. - Сможете разрабатывать гибкие и безопасные пайплайны для деплоя в разных окружениях. - Поймёте, как уменьшить риск ошибок при развертывании и минимизировать время простоя сервисов. - Научитесь управлять конфигурациями инфраструктуры без лишней ручной работы.🎁 Все участники вебинара получат специальные условия на полное обучение курса "DevOps практики и инструменты" 👉 Для участия зарегистрируйтесь: https://otus.pw/N22M/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
# Установка пакетов на Debian 13
apt install incus incus-base qemu-system
# Инициализация административного пользователя
incus admin init
# Список доступных образов Debian
incus image list images:debian
# Запуск контейнера Debian 13
incus launch images:debian/13 debian-ct --storage default
# Подключение к контейнеру
incus exec debian-ct -- bash
# Запуск виртуалки Ubuntu
incus launch images:ubuntu/noble ubuntu-vm --vm --storage default
# Вход в Ubuntu VM
incus exec ubuntu-vm -- bash
# Основные команды для обзора
incus ls
incus info ubuntu-vm
incus storage list
incus network list
💡 Теперь ты знаешь, что Incus — это легкое и гибкое решение для виртуализации без ограничений Proxmox. Попробуй и сам убедись!
🔗 Официальный сайт и документация: linuxcontainers.org
🔗 GitHub репозиторий Incus: https://github.com/lxc/incus
#Linux #DevOps #Виртуализация #Incus #LXC #KVM #Linux_err24stream (Layer 4) для RDP/SSH/VPN, где ручная перезагрузка Nginx из-за нового конфига — это недопустимый downtime.
Статический конфиг нам не подходит. Решение — динамическая маршрутизация на основе SNI (Server Name Indication) с использованием модуля njs, где список арендаторов хранится во внешней БД (Redis или etcd).
📌 Динамический Upstream по SNI с njs
На L4 Nginx (или Angie) может прочитать имя сервера (SNI) во время TLS-рукопожатия и на основе этого имени принять решение о маршрутизации. Модуль njs позволяет сделать этот процесс динамическим.
Шаг 1. Настраиваем njs для чтения SNI
Нам нужен скрипт на njs, который возьмёт имя хоста из SNI и, используя внешний модуль, найдёт соответствующий upstream в Redis или etcd (имитация логики):
// sni_router.js
function route(s) {
// Получаем имя хоста из SNI
var hostname = s.ssl_server_name;
// Здесь должна быть логика поиска в Redis/etcd
// Для примера, ищем в предопределенном словаре:
var tenantMap = {
'client_a.example.com': 'backend_pool_a',
'client_b.example.com': 'backend_pool_b'
};
if (tenantMap[hostname]) {
return tenantMap[hostname];
}
// Если арендатор не найден, используем upstream по умолчанию
return 'default_pool';
}
Шаг 2. Конфигурируем stream и njs
В конфигурации Nginx (Angie) в блоке stream мы загружаем скрипт и используем его результат в директиве upstream.
# Загрузка njs модуля и скрипта
js_include sni_router.js;
js_set $backend_name sni_router.route;
stream {
upstream backend_pool_a {
server 10.0.0.1:443;
}
upstream backend_pool_b {
server 10.0.0.2:443;
}
upstream default_pool {
server 10.0.0.10:443;
}
server {
listen 443 ssl;
ssl_preread on; # Важно: позволяет Nginx читать SNI
# Динамически определяем upstream на основе результата njs-скрипта
proxy_pass $backend_name;
}
}
💡 Вывод
Такой подход позволяет полностью разделить список арендаторов (который может храниться в Redis/etcd и обновляться мгновенно) от статического конфига Nginx. Nginx (Angie) перечитывает njs-переменную $backend_name для каждого нового соединения, обеспечивая высокую доступность и нулевой downtime при добавлении новых клиентов. Это критически важно для масштабируемой и отказоустойчивой архитектуры.
#Nginx #DevOps #Stream #SNI #MultiTenancy #njsphp-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 #Optimization