LinuxSkill - Сводки с прода и Шпаргалки
Следим за новостями Linux, DevOps и ИБ, чтобы быть готовым к любым факапам. Бонусом — плотные шпаргалки и чеклисты для ежедневной работы в терминале. 📩 По всем вопросам: @chorapov Зеркало в MAX: https://max.ru/LinuxSkill РКН https://vk.cc/cMUwm4
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام 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) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
top: скрипт для моментальной диагностики Linux
Привет, системный траблшутер!
Если у тебя что-то "легло" или тормозит, нужно моментально получить срез состояния системы. Ты не хочешь запускать 10 разных команд.
Объедини ключевые команды (uptime, free, ps) в одну функцию, которая быстро покажет тебе, где узкое место.
🐧 Скрипт check_status.sh
#!/bin/bash
# Используем hostname для получения имени сервера
SERVER_NAME=$(hostname)
# Создание функции, чтобы избежать повторов кода
function get_quick_status() {
echo "--- СТАТУС СЕРВЕРА: ${SERVER_NAME} ---"
# 1. Аптайм и Load Average
echo "Load Average (1, 5, 15 мин) и Uptime:"
uptime
# Load Average > 1.0 часто указывает на проблемы
# 2. Использование памяти (в удобном формате)
echo "Использование RAM и SWAP (free -h):"
free -h
# free -h выводит информацию о памяти и swap
# 3. Использование корневого раздела
echo "Использование диска (df -h /):"
df -h / | tail -n 1 | awk '{print "Used: " $3 ", Avail: " $4 }'
# df показывает использование файловой системы
# 4. Топ-5 активных процессов по CPU
echo "Топ-5 активных процессов (PID, %CPU, COMMAND):"
ps -e --no-header -o pid,%cpu,comm | sort -nr -k 2 | head -5
# ps -e отображает информацию о текущих запущенных процессах
}
# Запускаем функцию
get_quick_status
Вывод: Ты можешь использовать эту заготовку как основу, чтобы быстро диагностировать проблемы с CPU, памятью или диском, а затем добавить vmstat или iostat для глубокого анализа, если это требуется.
#Мониторинг #Bash #CLI #Скрипт #uptime #freeroot. Атакующий может получить права root на хосте.
# В Dockerfile создаем группу и непривилегированного пользователя 'app'
RUN groupadd -r app_grp && useradd -r -g app_grp app
USER app # Всегда переключаемся на непривилегированного пользователя
2. Ограничение возможностей ядра (Capabilities)
Docker по умолчанию включает много возможностей, но лучше их отключить и добавить только необходимые.
# Сбрасываем все Capabilities (CAP_DROP ALL)
docker run -ti --cap-drop ALL debian /bin/bash
# Добавляем только возможность привязки к низким портам (<1024)
docker run --cap-drop all --cap-add CAP_NET_BIND_SERVICE alpine:latest sh
# Запрет на повышение привилегий (hardening)
docker run --security-opt=no-new-privileges ubuntu bash
3. Оптимизация Dockerfile: Слияние RUN
Каждая инструкция RUN создает новый уровень (layer), увеличивая размер образа. Объединяйте команды с && для минимизации слоев.
# Плохо: 3 отдельных слоя
RUN apk update
RUN apk add nodejs nodejs-npm
RUN mkdir -p /app/public
# Хорошо: одна инструкция, один слой
RUN apk update && \
apk add nodejs nodejs-npm && \
mkdir -p /app/public /app/server
4. Управление томами (Volumes)
Для сохранения постоянных данных используй тома (VOLUME).
# Создание тома на хосте (local driver по умолчанию)
docker volume create my_data_vol
# Просмотр информации о томе (включая путь на хосте)
docker volume inspect my_data_vol
# Удаление всех неиспользуемых томов (используй с осторожностью!)
docker volume prune
5. Очистка системы
Для избежания беспорядочного роста образов и контейнеров (image sprawl).
# Удаление остановленных контейнеров
docker rm $(docker ps -aq -f status=exited)
# Удаление неиспользуемых (висячих) образов
docker rmi $(docker images -q -f dangling=true)
# Полная очистка: контейнеры, образы, сети, тома
docker system prune -a
6. Режимы работы с сетью
Docker по умолчанию использует режим bridge (мост), который изолирует контейнеры в частной сети.
# Просмотр активных сетевых режимов (по умолчанию: bridge, none, host)
docker network ls
# Запуск контейнера в режиме хоста (убирает изоляцию, но дает скорость)
docker run --net=host -d my_app
# Создание изолированной сети, чтобы контейнеры видели друг друга по имени
docker network create my_custom_net
docker run --network my_custom_net --name redis_db redis
7. Работа с образами и тегами
Для контроля версий всегда используй конкретные теги, а не latest.
# Получение образа с конкретным тегом
docker pull debian:jessie
# Построение образа с явным указанием тега
docker build -t my_app:v1.2 .
# Использование дайджеста для абсолютной гарантии версии
FROM redis@sha256:3479bbcab384fa343b52743b933661335448f8166203688006...
8. Использование docker exec вместо SSH-демонов
Не запускай SSH-демон внутри контейнера. Для отладки используй docker exec.
# Запуск bash внутри активного контейнера (интерактивно)
docker exec -it <CONTAINER_ID> /bin/bash
# Запуск команды внутри контейнера без входа в оболочку
docker exec -it my_web_container ls -l /var/log
9. Настройка ресурсов (cgroups)
Ограничивай ресурсы (CPU, Memory), чтобы избежать DoS-атак или утечек памяти.
# Ограничение памяти (128 Мб)
docker run -it --rm -m 128m my_app
# Ограничение использования CPU (только ядра 0 и 1)
docker run -it --rm --cpuset=0,1 -c 2 my_app
10. Постоянный контроль состояния
Для избежания проблем, связанных с перезапуском и изменяемостью.
# Просмотр запущенных контейнеров
docker ps
# Просмотр всех контейнеров (включая остановленные)
docker ps -a
# Просмотр подробной конфигурации контейнера (JSON)
docker inspect <CONTAINER_ID>
# Получение журналов (STDOUT/STDERR)
docker logs <CONTAINER_ID>
#Docker #DevOps #Security #CLI #HardeningDROP, затем разреши необходимое.
# 1. Запрещаем весь входящий трафик по умолчанию
iptables -P INPUT DROP
# 2. Разрешаем внутренний трафик (loopback)
iptables -A INPUT -i lo -j ACCEPT
# 3. Разрешаем ответы на наши запросы (stateful firewall)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 4. Открываем SSH для управления (TCP порт 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Теперь сохраняем правила, чтобы они пережили перезагрузку
service iptables save
Вывод: Эти четыре команды — основа для любого безопасного сервера.
#Безопасность #iptables #CLI #Hardening--privileged в Docker — это прямая угроза безопасности. Он даёт контейнеру доступ ко всем устройствам хоста и может обеспечить злоумышленнику права root.
Используйте принцип минимальных привилегий (least privilege), отключая ненужные возможности ядра (capabilities).
1. Почему --privileged — это опасно?
Запуск контейнера в привилегированном режиме позволяет ему смонтировать корневую файловую систему хоста или получить уровень контроля, аналогичный процессам хоста.
# Опасная команда: получает полный доступ к хост-системе
docker run --rm -v /:/host -t -i debian bash
root@e51ae86c5f7b:/# cd /host
root@e51ae86c5f7b:/host# ls bin dev home
# Атакующий видит корневую ФС хоста, включая /bin, /dev, /etc, /root.
2. Принцип минимальных привилегий (Least Privilege)
Если контейнеру не нужны все возможности root (которые являются комбинацией 40 отдельных CAP_ возможностей Linux), их следует отключить. Docker по умолчанию и так удаляет многие возможности.
# Сброс всех возможностей и добавление только необходимых
# CAP_NET_BIND_SERVICE нужна для привязки к портам ниже 1024
docker run --cap-drop all --cap-add NET_BIND_SERVICE alpine:latest sh
# Пример удаления опасных возможностей SUID/SGID
docker run -it --rm --cap-drop SETUID --cap-drop SETGID ...
# Дополнительное ограничение: запрет на получение новых привилегий
docker run --security-opt=no-new-privileges ubuntu bash
3. Запуск от имени непривилегированного пользователя
Если приложение не требует привилегий root, оно не должно от него запускаться. Это предотвращает повышение привилегий (privilege escalation) в случае взлома.
# В Dockerfile: переключаем пользователя
RUN groupadd -r app_grp && useradd -r -g app_grp app
USER app
💡 Вывод:
Флаг --privileged следует избегать. Используй --cap-drop и USER в Dockerfile, чтобы контейнер не получил прав root на хосте, даже если его взломают.
#DevOps #Docker #Безопасность #root #CLI #Privilegesroot требует максимальной осторожности. Вот главные "самострелы", которые могут привести к краху системы:
1. rm -rf /: Безоговорочное уничтожение всей файловой системы.
2. Fork Bomb (:(){ :|:& };:): Бесконечное порождение процессов, исчерпывающее системные ресурсы.
3. dd: Неправильное указание if и of (вход/выход) уничтожит диск.
4. rm $VAR: Неэкранированная переменная может привести к стиранию лишнего.
5. .:$PATH: Добавление текущего каталога (.) создает лазейку для троянских программ.
#Linux #CLI #Безопасность #Ошибки #Сисадминping или traceroute для базовой диагностики. Но что, если тебе нужно не просто *найти* проблему, а активно симулировать её для проверки отказоустойчивости приложения или сетевого оборудования?
Смотри видео и сохраняй основные команды для своей тестовой лаборатории.
🌐 Источник: Новая образовательная система
#Linux #Netem #DevOps #CLI #Сеть #qdisc/etc/passwd. Разберём, что это за файл и почему он так важен.
📂 Что такое /etc/passwd?
Проблема: Системе нужно знать, какие пользователи существуют, какие у них UID, домашние директории и оболочки.
Решение: Файл /etc/passwd содержит базовую информацию о каждой локальной учетной записи в системе.
Структура записи:
username:x:UID:GID:comment:home_directory:shell
Пример:
root:x:0:0:root:/root:/bin/bash
user1:x:1000:1000:User One:/home/user1:/bin/bash
nginx:x:33:33:nginx:/var/www:/usr/sbin/nologin
Разбор полей:
1. username — имя пользователя
2. x — раньше здесь хранился хеш пароля, теперь он в /etc/shadow
3. UID — уникальный идентификатор пользователя (0 = root)
4. GID — идентификатор основной группы
5. comment — комментарий (обычно полное имя)
6. home_directory — путь к домашней директории
7. shell — оболочка для входа (например, /bin/bash или /usr/sbin/nologin для системных пользователей)
🔎 Как посмотреть содержимое?
# Полный список пользователей
cat /etc/passwd
# Только имена пользователей
cut -d: -f1 /etc/passwd
# Информация о конкретном пользователе
grep "^user1:" /etc/passwd
# Пользователи с оболочкой bash
grep "/bin/bash$" /etc/passwd
🛡️ Почему пароли больше не в /etc/passwd?
Раньше хеши паролей хранились прямо в /etc/passwd, но этот файл доступен всем пользователям для чтения. Это создавало угрозу безопасности.
Решение: Хеши паролей перенесли в /etc/shadow, который доступен только root.
💡 Полезные команды для работы с пользователями
# Добавить пользователя
useradd newuser
# Изменить оболочку пользователя
usermod -s /bin/zsh user1
# Удалить пользователя
userdel user1
# Посмотреть информацию о текущем пользователе
id
# Посмотреть всех пользователей с UID >= 1000 (обычные пользователи)
awk -F: '$3 >= 1000 {print $1}' /etc/passwd
⚡ Быстрая шпаргалка
✅ /etc/passwd — основной файл учетных записей
✅ /etc/shadow — хранит хеши паролей (только root)
✅ /etc/group — информация о группах
✅ UID 0 = root, UID 1-999 = системные пользователи, UID >= 1000 = обычные пользователи
🔗 Полезные ссылки:
Документация: https://man7.org/linux/man-pages/man5/passwd.5.html
#linux #sysadmin #passwd #безопасность #Linux_err24SSH Agent для подключения по защищенному каналу. Аутентификация может происходить по паролю или по ключу [User Query]. Аутентификацию по ключу, как более безопасную, можно предварительно настроить с помощью ssh-keygen.
Для удобства логин и пароль лучше вынести в скрытые макросы шаблона [User Query].
# -----------------------------------------------
# ШАГ 1: Создание Item в шаблоне
# -----------------------------------------------
# Тип: SSH агент (Zabbix Item Type)
Type: SSH agent
# Ключ элемента данных (Key)
# Формат: ssh.run[description,<IP>,<Port>,<User>,<Password>]
Key: ssh.run[mikrotik_backup,10.20.1.20,22,,]
# Тип информации (для хранения конфигурации)
Type of information: Text
# Выполняемый скрипт (команда на удаленном хосте)
Executed script: /export
2. Вкладка "Предобработка" (Preprocessing)
Это критически важный шаг. Мы используем встроенную возможность Zabbix для отбрасывания не изменившихся значений. Это позволяет хранить только различия в конфигурации и оповещать об изменениях [User Query].
# -----------------------------------------------
# ШАГ 2: Настройка дедупликации
# -----------------------------------------------
# Добавляем шаг Предобработки
Preprocessing step:
# Правило: Отбрасывать не изменившееся
Discard unchanged: True (or use specific preprocessing rule)
3. Настройка триггера на изменение конфигурации
Триггер сработает, если последняя полученная конфигурация отличается от предыдущей [User Query].
# -----------------------------------------------
# ШАГ 3: Добавление триггера
# -----------------------------------------------
# Имя: Configuration changed on {HOST.NAME}
# Серьезность: Warning/Average
# Выражение триггера (Trigger Expression):
# last() сравнивает последнее значение с предыдущим (#2)
# Если они отличаются, то триггер сработает
{<Имя шаблона>:ssh.run[mikrotik_backup,10.20.1.20,22,,].last(#1)}<>
{<Имя шаблона>:ssh.run[mikrotik_backup,10.20.1.20,22,,].last(#2)}
4. Дополнительные команды SSH
Ты можешь использовать SSH для выполнения команд и сценариев. Например, для проверки целостности файлов или сбора данных о системе:
# Использование SSH для удаленного выполнения команды
# (Zabbix SSH Agent использует подобный механизм)
# Получение времени в 12-часовом формате с удаленного хоста:
ssh user@host.example.com 'date +%r'
# Использование именованного канала (pipe) для передачи данных между процессами
# (сложный пример, показывающий возможности туннелирования SSH)
su xyz -c "ssh $THERE \"cat > /home/xyz/backup/${HERE}-daily.tar.gz\" < /pipe"& \
cd / && tar -czf - bin boot dev etc home info lib man root sbin share usr var > /pipe
💡 Вывод
Использование SSH Агента в Zabbix позволяет тебе настроить продвинутый аудит конфигураций [User Query] и автоматизацию бэкапов без сложного внешнего скриптования. Главное, что ты получаешь, — немедленное оповещение о любых изменениях в ключевых настройках.
Помни: создавать такие настройки лучше сразу в шаблонах, а не на хостах, чтобы обеспечить удобство и переносимость [User Query].
#Zabbix #SSH #Monitoring #Mikrotik #АвтоматизацияРеклама. ООО «Отус онлайн-образование», ОГРН 1177746618576