Телеграм канал «Linux Education»

🎂 С Днём рождения, Линус! 56 - это не возраст… это просто новая стабильная версия 💻✨ @linux_education

Linux совет 💡 Если нужно удалить пустые директории, find делает это быстро и аккуратно. Способ через rmdir: $ find . -type d -empty -exec rmdir -v {} + Что здесь происходит: - -type d — ищем только директории - -empty — выбираем пустые - -exec rmdir — удаляем через rmdir - rmdir гарантирует, что директория действительно пустая Альтернативный и более короткий вариант: $ find . -type d -empty -delete Этот способ делает то же самое, но без вызова внешней команды. Полезно для: - очистки build-артефактов - приведения проекта в порядок - автоматизации cleanup-скриптов @linux_education

‍🖥 python-injection - практический сборник уязвимостей в Python python-injection - это репозиторий с наглядными примерами инъекций и небезопасных паттернов в Python-коде, которые регулярно встречаются в реальных проектах. Проект показывает, как «обычный» Python-код превращается в уязвимость, если не понимать, как именно работают интерпретатор, библиотеки и внешние вызовы. Что внутри: - Command Injection через os.system, subprocess, shell=True - SQL Injection при неправильной работе с запросами - Code Injection через eval, exec, pickle - Path Traversal и небезопасная работа с файлами - Template Injection - Примеры небезопасной десериализации - Реальные анти-паттерны из production-кода Главная ценность репозитория — код, а не теория: - есть уязвимый пример - есть объяснение, почему он опасен - понятно, как именно происходит атака Подходит для: - Python-разработчиков - backend-инженеров - security-энтузиастов - code review и обучения безопасному программированию Если ты пишешь Python и думаешь, что «у нас же не веб» - этот репозиторий стоит открыть. pip install python-injection https://github.com/100nm/python-injection @linux_education

‍⚡️ Shannon - автономный AI-хакер для поиска реальных уязвимостей Shannon - это полностью автономный AI-агент, который ищет настоящие эксплойты в веб-приложениях, а не просто флаги или теоретические проблемы. Он работает без подсказок, анализирует исходный код и ведёт себя как реальный атакующий. Главное достижение - 96.15 процента успешных атак на XBOW Benchmark в режиме hint-free и source-aware. Это один из самых сложных бенчмарков для offensive security, где агенту нужно самостоятельно находить цепочки уязвимостей. Как это работает: - анализ исходного кода и поведения приложения - построение гипотез атак - автоматическая проверка эксплойтов - подтверждение реального взлома, а не ложных срабатываний Shannon показывает, куда движется AppSec. Мы переходим от сканеров и правил к автономным AI-агентам, которые думают и атакуют как человек, но делают это быстрее и масштабнее. Для команд безопасности это означает одно - защищаться скоро придётся не от скриптов, а от полноценных AI-атакеров. github.com/KeygraphHQ/shannon @linux_education

Танцевали с роботом, прокачивали ГигаЧат и собирали лучших спецов на AI Journey 🤩 Подписчики Sber AI наблюдали этот год на максимальных скоростях — весь 2025-й мы генерировали настоящее и создавали будущее. В этом видео — наш вайб! А в канале Sber AI: 🤩 инсайды AI-индустрии от разработчиков Сбера 🤩 гайды и лайфхаки по нейросетям 🤩 главные события из мира искусственного интеллекта — AI Journey всё ещё можно посмотреть тут (https://aij.ru/program/2025) ◀️ Запрыгивайте на борт! (https://t.me/SberAIScience) @linux_education

⚡ Простой Linux-совет: Если логи сжаты в .gz, их не нужно распаковывать, чтобы посмотреть содержимое или найти нужную строку. Используй специальные `z`-команды: • zcat - просто показать содержимое файла • zless - читать файл постранично • zgrep - искать текст внутри .gz • zegrep - поиск с расширенными регулярными выражениями • zfgrep - поиск точного текста • zcmp / zdiff - сравнивать сжатые файлы Это экономит время и место на диске и отлично подходит для быстрого анализа логов прямо в проде. @linux_education

🖥 Linux: Как один забытый процесс может убить сервер за ночь Одна из самых частых и коварных проблем в Linux - забытый процесс без лимитов. Это может быть: - cron задача - systemd сервис - Python скрипт - backup или лог-парсер Днем он почти незаметен. А ночью начинает: - бесконечно писать в лог - съедать память - плодить дескрипторы - держать CPU на 100% К утру сервер либо: - перестает отвечать по SSH - начинает дропать сервисы Причина почти всегда одна - нет лимитов и мониторинга. Минимум, что нужно проверять: - сколько памяти потребляет процесс - растет ли число файловых дескрипторов - жив ли он неделями без рестарта - ограничен ли он через systemd Найти самые прожорливые процессы ps aux --sort=-%mem | head # Проверить количество открытых файлов у процесса ls /proc/PID/fd | wc -l # Посмотреть лимиты процесса cat /proc/PID/limits # Если systemd - проверить ограничения сервиса systemctl show your-service.service | grep -E 'LimitNOFILE|MemoryLimit' @linux_education