База знаний (кластер NBICS)

Ручная проверка, содержит ли переменная PATH каталог /sbin Вот актуальные на 2025 год самые быстрые и надёжные способы проверить и исправить отсутствие /sbin, /usr/sbin, /usr/local/sbin в $PATH — именно эти три каталога почти всегда отсутствуют у обычных пользователей в Ubuntu/Debian/Mint/Pop!_OS и производных. 1. Проверка одной командой (2025 стандарт) echo "$PATH" | tr ':' '\n' | grep -E '^(/(usr/)?s?bin)$' # или ещё короче и красивее: (echo "$PATH"; echo) | tr ':' '\n' | nl | grep -E '/s?bin' Если ничего не вывелось — /sbin и /usr/sbin действительно отсутствуют. 2. Самые удобные однострочники # Есть ли вообще хоть один *bin? [[ :$PATH: == *:/sbin:* || :$PATH: == *:/usr/sbin:* ]] && echo "OK" || echo "Отсутствует" # Точная проверка всех трёх нужных каталогов missing=() for dir in /sbin /usr/sbin /usr/local/sbin; do [[ ":$PATH:" != *":$dir:"* ]] && missing+=("$dir") done ((${#missing[@]} == 0)) && echo "Всё в порядке" || echo "Отсутствуют: ${missing[*]}" 3. Правильное исправление навсегда (2025) # Добавь эту строку в конец ~/.bashrc или ~/.zshrc echo 'export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:$PATH"' >> ~/.bashrc # Или одной командой (если файла ещё нет) cat <<'EOF' >> ~/.bashrc # Добавляем системные административные каталоги в PATH (2025) export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:$PATH" EOF После этого: source ~/.bashrc # или перезайди в терминал Теперь reboot, ifconfig, iptables, fdisk, systemctl и т.д. будут работать без /sbin/ и без sudo в командах типа sudo reboot. 4. Мой личный «идеальный» вариант (ставлю на всех серверах и рабочих машинах) # В ~/.bashrc или ~/.profile if [[ $UID -ne 0 && ":$PATH:" != *":/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:"* ]]; then export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:$PATH" fi Защищает от дублирования при повторном source и не трогает root. 5. Проверка после исправления which reboot && echo "reboot теперь доступен без пути!" which iptables && echo "iptables тоже!" Итог: запомни всего две команды на всю жизнь # Проверить [[ ":$PATH:" == *":/sbin:"* ]] && echo "OK" || echo "Нет /sbin" # Исправить навсегда echo 'export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:$PATH"' >> ~/.bashrc && source ~/.bashrc Больше никогда не будешь писать /sbin/ip, /sbin/reboot или получать ошибку command not found на только что установленной Ubuntu/Mint.

Многострочные комментарии Вот полная и актуальная на 2025 год шпаргалка по многострочным комментариям в Bash-скриптах — от классики до самых красивых и удобных способов. Топ-6 способов писать многострочные комментарии в Bash # 1. Классика — HereDoc (самый надёжный и правильный) : <<'COMMENT' Это многострочный комментарий. Можно писать всё что угодно: • пояснения • TODO • авторство • лицензию Даже кавычки " ' и $ переменные не интерполируются! COMMENT # 2. С произвольным маркером (мой личный фаворит) : <<'EOF' #!/bin/bash Скрипт делает резервную копию всех сайтов Автор: Alex Дата: 2025 Требует: rsync, tar, notify-send EOF # 3. Если нужны переменные внутри комментария — без кавычек : <<COMMENT Сегодня $(date) Пользователь: $USER Домашняя папка: $HOME COMMENT # → переменные подставятся! # 4. Самый короткий и читаемый (2025 стиль) <<'#' Это тоже комментарий! Работает потому что <<# — это встроенный маркер Bash # # 5. Многострочный комментарий с отступами (очень красиво) cat <<'EOF' >/dev/null ┌───────────────────────────────────────────────────── │ Скрипт: backup.sh │ Назначение: Ежедневный бэкап /var/www и баз MySQL │ Автор: admin@company.ru │ Версия: 3.1 (2025-11-29) │ Требует права root Логи пишутся в /var/log/backup.log ┌───────────────────────────────────────────────────── EOF # 6. Комментарий-блок в одну строку (для ленивых) : <<{1..10} # закомментирует следующие 10 строк (нестандартно, но работает) Рекомендуемые шаблоны для реальных скриптов (2025) #!/usr/bin/env bash set -euo pipefail : <<'INFO' Имя скрипта : deploy.sh Описание: Деплой приложения через Docker Compose Автор : Иван Иванов <ivan@company.ru> Дата создания : 2025-03-15 Версия : 2.4 Требования : docker, docker-compose, jq Использование : ./deploy.sh [staging|production] INFO # код скрипта... Итог: запомни всего один идеальный вариант : <<'EOF' Твой многострочный комментарий здесь Можно хоть 100 строк Всё игнорируется, переменные не подставляются EOF Это самый чистый, переносимый и читаемый способ в 2025 году. Работает в любом Bash ≥ 3.0, не ломается от кавычек, доллара и тире.

Timeshift (Точки восстановления Linux) Вот актуальная на конец 2025 года шпаргалка по Timeshift — всё, что реально работает в Ubuntu 22.04/24.04, Mint 21/22, Debian 12/13, Pop!_OS и т.д. 1. Установка Timeshift в 2025 году (самые рабочие способы) # Способ 1 — официальный PPA (самый стабильный) sudo add-apt-repository -y ppa:teejee2008/timeshift sudo apt update sudo apt install timeshift # Способ 2 — если PPA уже не работает (2025+ часто так) # Установка из официального .deb (рекомендую) wget -O timeshift-latest.deb https://github.com/linuxmint/timeshift/releases/latest/download/timeshift_24.06.4_amd64.deb sudo apt install ./timeshift-latest.deb # Способ 3 — через Snap (не рекомендую — тормозит и не видит BTRFS) sudo snap install timeshift --classic 2. Основные команды CLI (2025) Задача Команда Создать снапшот вручную sudo timeshift --create --comments "После установки OpenVIDU" Создать снапшот на конкретный диск sudo timeshift --create --snapshot-device /dev/nvme0n1p2 --comments "Чистая система" Посмотреть все снапшоты sudo timeshift --list Восстановить последний снапшот sudo timeshift --restore Восстановить конкретный снапшот sudo timeshift --restore --snapshot '2025-11-29_14-30-00' Удалить снапшот sudo timeshift --delete --snapshot '2025-11-01_10-00-00' Удалить все снапшоты старше 30 дней sudo timeshift --delete --keep 3 # оставить только 3 последних Проверить целостность всех снапшотов sudo timeshift --check Посмотреть, сколько места занимают sudo timeshift --list | grep -E "Size|Used" 3. Самые полезные однострочники (мой личный набор) # Создать снапшот перед опасными действиями sudo timeshift --create --comments "Перед обновлением до Ubuntu 25.04" # Быстрое восстановление (если система упала) sudo timeshift --restore --skip-grub # Удалить всё, кроме 5 последних снапшотов sudo timeshift --delete-all --keep-last 5 # Создать снапшот и сразу вывести его ID sudo timeshift --create --comments "После установки Docker" | grep "Created snapshot" # Автоматический бэкап по расписанию (добавь в crontab) 0 3 * * * /usr/bin/timeshift --create --comments "Еженощный бэкап" --quiet >/dev/null 2>&1 4. Важные особенности 2025 года Что нужно знать Комментарий RSYNC vs BTRFS RSYNC — работает везде, BTRFS — быстрее и экономит место (но только на BTRFS!) Timeshift НЕ бэкапит /home по умолчанию Включи в настройках → «Include hidden items in user home directories» Для восстановления вне системы нужен Live-USB Загружайся с Ubuntu Live → устанавливай timeshift → восстанавливай После клонирования системы на другой диск Запусти sudo timeshift --target /dev/sdX1 для переноса точек восстановления 5. Мой личный скрипт «снапшот перед экспериментами» #!/bin/bash COMMENT=${1:-"Ручной снапшот $(date +%Y-%m-%d_%H-%M)"} sudo timeshift --create --comments "$COMMENT" && \ echo "Снапшот создан: $COMMENT" Сохрани как ~/bin/ts → chmod +x ~/bin/ts → используй просто: ts "Перед установкой Wine и Windows-программ" Запомни всего 3 команды — и ты никогда не потеряешь систему: sudo timeshift --create --comments "..." # перед любыми экспериментами sudo timeshift --list # посмотреть, что есть sudo timeshift --restore # если всё сломалось

Установка и удаление Snap Вот самый чистый, актуальный и проверенный на 2025 год способ установки и полного удаления Snap в Ubuntu/Debian/Mint/Pop!_OS и производных. Установка Snap (2025) sudo apt update sudo apt install snapd # это всё, что нужно sudo systemctl enable --now snapd.socket # на всякий случай После этого просто: snap install hello-world # проверка Полное удаление Snap (ничего не останется) # 1. Список установленных snap-пакетов snap list # 2. Удалить ВСЕ snap-пакеты одной командой (2025 способ) sudo snap remove --purge $(snap list | awk '!/^Name|^snapd$/ {print $1}') # 3. Удалить сам snapd и всё, что с ним связано sudo apt purge -y snapd gnome-software-plugin-snap 2>/dev/null || true sudo apt autoremove -y # 4. Удалить остатки (это важно!) sudo rm -rf /snap /var/snap /var/lib/snapd /var/cache/snapd rm -rf ~/snap # 5. (Опционально) Убить запущенные процессы snap, если висели sudo killall snapd || true # 6. Перезагрузить (рекомендуется) sudo reboot Однострочник полного удаления (мой личный, копируй-вставляй) sudo snap remove --purge $(snap list | awk '!/^Name|^snapd$/ {print $1}') 2>/dev/null; \ sudo apt purge -y snapd gnome-software-plugin-snap; sudo apt autoremove -y; \ sudo rm -rf /snap /var/snap /var/lib/snapd /var/cache/snapd ~/snap; \ echo "Snap полностью уничтожен. Перезагрузись!" Как проверить, что Snap действительно мёртв which snap && echo "Ещё жив!" || echo "Snap мёртв. Празднуем!" ls /snap /var/snap 2>/dev/null && echo "Остатки есть" || echo "Чисто" Альтернативы Snap (куда люди уходят в 2025) Что ставить вместо Snap Команда установки Flatpak sudo apt install flatpak AppImage просто скачиваем и запускаем Обычные .deb sudo apt install ... Distrobox / Toolbox для запуска приложений в контейнерах

Поиск файлов через терминал Вот актуальный на 2025 год набор команд для поиска файлов в Linux — от самых быстрых до самых мощных. Работает везде: Ubuntu, Debian, Fedora, Arch, Alpine, macOS. Топ-10 команд, которые реально используют в 2025 # 1. Самая быстрая и красивая (2025 стандарт) fd .drawio$ # или просто fd drawio # 2. Классика find (всегда работает) find /путь -type f -name "*.drawio" 2>/dev/null # 3. Только в текущей папке (без рекурсии) find . -maxdepth 1 -type f -name "*.drawio" # 4. Поиск по имени без учёта регистра find . -type f -iname "*.DrAwIo" # 5. Найти и сразу открыть в draw.io / diagrams.net find . -type f -name "*.drawio" -exec xdg-open {} \; # 6. Найти все drawio-файлы и показать их размер + дату find . -type f -name "*.drawio" -printf '%s %p %TY-%Tm-%Td\n' | sort -nr | head -20 # 7. Искать только в домашних папках (быстро) find ~ -type f -name "*.drawio" 2>/dev/null # 8. Поиск по содержимому файла (внутри .drawio — это XML/JSON) rg -g '*.drawio' "Customer Database" # 9. Самый быстрый аналог find (на Rust) fd -e drawio # ищет только файлы с расширением .drawio fd -e drawio -x xdg-open {} # открыть все найденные # 10. Через locate (если база обновлена — мгновенно) updatedb && locate "*.drawio" Установка лучших инструментов 2025 # Ubuntu/Debian/Mint/Pop!_OS sudo apt install fd-find ripgrep # fd и rg # Fedora sudo dnf install fd-find ripgrep # Arch/Manjaro sudo pacman -S fd ripgrep # macOS brew install fd ripgrep Мои личные алиасы (добавь в ~/.bashrc или ~/.zshrc) alias fdraw="fd -e drawio" # найти все .drawio alias odraw="fd -e drawio -x xdg-open {}" # открыть все alias findbig="find . -type f -size +100M -exec ls -lh {} \;" alias fr="fd" # коротко вместо find Однострочники для самых частых задач # Найти все .drawio за последние 7 дней find . -type f -name "*.drawio" -mtime -7 # Найти и удалить все .drawio (осторожно!) find . -type f -name "*.drawio" -delete # Найти .drawio-файлы больше 10 МБ find . -type f -name "*.drawio" -size +10M # Найти по содержимому (например, слово "API") rg -g '*.drawio' "REST API" Итог: запомни всего три команды на всю жизнь fd drawio # 2025 — самый быстрый и удобный find . -name "*.drawio" # классика, работает везде rg "слово" -g '*.drawio' # поиск внутри файлов Больше никогда не используй find без fd — в 2025 году fd и rg — это то, чем пользуются все профи.

Информация о видеокарте Вот самый полный и актуальный на конец 2025 года набор команд, чтобы узнать всё о видеокарте (или видеокартах) в Linux — работает на ноутбуках, десктопах, серверах, WSL2, даже если драйверы не установлены. Топ-8 команд (копируй-вставляй в порядке очереди) # 1. Самая быстрая и красивая (2025 стандарт) inxi -Gxxxz # 2. Если inxi нет — универсальный минимум lspci -nnk | grep -EA3 "VGA|3D|Display" # 3. Подробно про каждую карту (включая встроенную) sudo lshw -C display # 4. Что реально рендерит OpenGL/Vulkan сейчас glxinfo | grep "OpenGL renderer" || echo "mesa не установлена" vulkaninfo | grep deviceName | head -1 # 5. NVIDIA — полная инфа + температура + драйвер nvidia-smi -L && nvidia-smi # 6. AMD (новые карты с ROCm или старые) rocm-smi || radeontop # 7. Intel iGPU intel_gpu_top # 8. Самая короткая и всегда работает даже без драйверов lspci | grep -Ei "vga|3d|display" Что выведут эти команды в 2025 году (примеры Команда Пример вывода (NVIDIA) Пример вывода (AMD + Intel) inxi -Gxxxz Graphics: Device-1: NVIDIA RTX 4070 driver: nvidia v: 560.35.03 Device-1: AMD RX 7900 XTX driver: amdgpu │ Device-2: Intel Arc A770 lspci \| grep VGA 01:00.0 VGA compatible controller: NVIDIA GA104 [RTX 3070] 03:00.0 VGA: AMD Navi 31 [RX 7900 XT] │ 00:02.0 VGA: Intel Raptor Lake-S GT1 glxinfo \| grep renderer OpenGL renderer string: NVIDIA GeForce RTX 4070/PCIe/SSE2 OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi) nvidia-smi GeForce RTX 4070 │ 72°C │ Driver 560.35.03 — Установка всех нужных утилит одной строкой (Ubuntu/Debian/Mint) sudo apt update && sudo apt install -y inxi mesa-utils vulkan-tools pciutils lshw # Для NVIDIA драйверов (если ещё не стоят) # sudo ubuntu-drivers install Fedora: sudo dnf install inxi vulkan-tools mesa-vulkan-drivers pciutils lshw Мой личный алиас (добавь в ~/.bashrc) alias gpu='echo "=== GPU ==="; inxi -Gxxxz 2>/dev/null || lspci | grep -Ei "vga|3d"; echo "=== Рендерер ==="; glxinfo | grep "OpenGL renderer" 2>/dev/null || echo "Нет OpenGL"; nvidia-smi -L 2>/dev/null | head -1 || echo "Нет NVIDIA"' Вывод будет такой: === GPU === Graphics: Device-1: NVIDIA RTX 4070 Ti driver: nvidia v: 560.35.03 === Рендерер === OpenGL renderer string: NVIDIA GeForce RTX 4070 Ti/PCIe/SSE2 GPU 0: NVIDIA GeForce RTX 4070 Ti Итог — запомни всего две команды на всю жизнь inxi -Gxxxz # красиво и всё сразу lspci | grep -Ei "vga|3d|display" # работает всегда и везде

Проверка поддержки аппаратной виртуализации Вот самый полный и актуальный на 2025 год набор команд для проверки поддержки и состояния аппаратной виртуализации в Linux (Intel VT-x / AMD-V / SVM). 1. Самые точные и быстрые (работают везде) # Количество ядер с поддержкой виртуализации (Intel = vmx, AMD = svm) egrep -c '(vmx|svm)' /proc/cpuinfo # Если результат > 0 → железо поддерживает # Если 0 → либо процессор старый, либо виртуализация выключена в BIOS/UEFI # Более человекочитаемо lscpu | grep -i virtualization # или lscpu | grep -E "Flags|Virtualization" Пример нормального вывода: Flags: ... vmx ... ← Intel Flags: ... svm ... ← AMD Virtualization: VT-x ← Intel (новые ядра) Virtualization: AMD-V ← AMD 2. Полная проверка: поддержка есть + включена ли в BIOS # Универсальная команда 2025 года (самая надёжная) kvm-ok Установка (Debian/Ubuntu/Mint/Fedora): sudo apt install cpu-checker # Ubuntu/Debian/Mint # или sudo dnf install libvirt-clients cpu-checker # Fedora Вывод kvm-ok: INFO: /dev/kvm exists KVM acceleration can be used ← всё отлично Если выключено в BIOS: INFO: Your CPU supports KVM extensions INFO: KVM is disabled by your BIOS/UEFI HINT: Enter your BIOS/UEFI setup and enable Virtualization Technology 3. Проверка через специальные утилиты # Intel cat /proc/cpuinfo | grep -E "vmx|VT-x" # AMD cat /proc/cpuinfo | grep -E "svm|AMD-V" # Подробно с названиями флагов grep --color -E "vmx|svm" /proc/cpuinfo 4. Если используешь VirtualBox VBoxManage list vms | grep -i running # косвенно # или прямо: egrep -q "vmx|svm" /proc/cpuinfo && echo "VirtualBox будет работать с ускорением" 5. Проверка из-под Windows перед установкой Linux (если dual-boot) PowerShell (как админ): Get-VMProcessor | Select VMName, ExposeVirtualizationExtensions # или systeminfo | findstr "Виртуализация" 6. Однострочник, который я вставляю в свои скрипты установки if [ $(egrep -c '(vmx|svm)' /proc/cpuinfo) -gt 0 ]; then if [ -e /dev/kvm ] && kvm-ok 2>/dev/null | grep -q "can be used"; then echo "Виртуализация полностью работает (KVM + VT-x/AMD-V)" else echo "Виртуализация поддерживается железом, но выключена в BIOS/UEFI!" fi else echo "Процессор НЕ поддерживает аппаратную виртуализацию" fi Что делать, если показывает 0 или «disabled by BIOS» Перезагружаемся → входим в BIOS/UEFI (обычно Del, F2, F10, F12) Ищем и включаем: Intel → Intel Virtualization Technology или VT-x, VT-d AMD → AMD-V, SVM Mode, Virtualization Сохраняем (F10 → Yes) и перезагружаемся После этого kvm-ok покажет зелёный свет, а VirtualBox/QEMU/KVM будут летать в 10–20 раз быстрее. Запомни всего две команды — и всегда будешь знать статус виртуализации: egrep -c '(vmx|svm)' /proc/cpuinfo # поддерживает ли процессор kvm-ok # включено ли в BIOS + работает ли KVM

Узнать общий размер текущего каталога Вот актуальный на 2025 год набор команд для быстрого и точного определения размера текущего (или любого) каталога. Всё работает везде: Ubuntu, Debian, Fedora, Arch, Alpine и т.д. Топ-7 команд (копируй-вставляй) # 1. Самая популярная и правильная (2025 стандарт) du -sh . # размер текущей папки # 2. Ещё быстрее и красивее (мой ежедневный выбор) du -sh --apparent-size . # реальный размер файлов (а не блоков на диске) # 3. Размер без учёта скрытых папок (полезно в /home) du -sh -- * # только видимые папки и файлы # 4. Размер с учётом только реальных файлов (игнорирует sparse-файлы, Docker-образы и т.п.) du -sh --apparent-size --exclude="*.img" --exclude="*.qcow2" . # 5. Самый быстрый способ (не сканирует содержимое, только метаданные) dust -r . # после установки: cargo install dust или sudo apt install dust # 6. Интерактивный и самый красивый (рекомендую всем) ncdu . # покажет всё дерево + можно удалять прямо из интерфейса # 7. Размер в байтах (удобно для скриптов) du -sb . # точное количество байт Полезные вариации # Размер нескольких папок сразу du -sh ~/{Downloads,Documents,Desktop,.cache,.local} 2>/dev/null | sort -hr # Размер только папок первого уровня (с сортировкой) du -sh ./* | sort -hr # Размер с исключениями (например, без node_modules и .git) du -sh --exclude="./node_modules" --exclude="./.git" . # Самые жирные папки внутри текущей (топ-20) du -h --max-depth=2 . 2>/dev/null | sort -hr | head -20 Установка самых удобных утилит (2025) # Ubuntu/Debian/Mint sudo apt install ncdu dust # dust — это как du, но в 10 раз быстрее и красивее # Fedora sudo dnf install ncdu dust # Arch/Manjaro sudo pacman -S ncdu dust Мои алиасы (добавь в ~/.bashrc или ~/.zshrc) alias size="du -sh ." alias sizeof="du -sh" # sizeof Downloads alias big="du -h --max-depth=1 . | sort -hr" alias fat="dust -r" alias clean="ncdu ~" Итог: запомни всего три команды на всю жизнь du -sh . # классика, всегда работает dust . # самый быстрый и красивый (2025) ncdu . # когда нужно покопаться и почистить Больше ничего придумывать не надо. dust и ncdu — это то, чем пользуются все продвинутые линуксоиды в 2025 году.

Одинарные и двойные кавычки в YAML В YAML строки можно заключать в одинарные ('...') или двойные ("...") кавычки. Оба варианта корректны, но ведут себя по-разному, особенно при работе с особыми символами, переменными окружения и многострочными значениями. Ниже — полное объяснение, обновлённое для всех современных применений YAML. 1. Одинарные кавычки ('...') Что делают Одинарные кавычки всегда сохраняют строку буквально. Никакие спецсимволы, такие как: \n \t $VARIABLE \${VAR} не интерпретируются, а остаются как есть. Используйте одинарные кавычки, если: нужно передать буквально то, что написано; вы используете строки с $, \, ", JSON внутри YAML; конфигурация чувствительна к экранированию (например, regex); в Docker Compose значение не должно интерполироваться. Пример: server_name: 'element3.nbics.net' password: 'pa$$word' regex: '^\d{3}-\d{2}-\d{4}$' path: 'C:\Program Files\App' Особенность YAML: Единственный символ, который нельзя использовать напрямую внутри '...', — это '. Для него используется удвоение: text: 'Bob''s server' 2. Двойные кавычки ("...") Что делают Двойные кавычки разрешают интерполяцию переменных и управляющие последовательности: \n превращается в перенос строки \t — табуляция \" — экранирование А также: переменные окружения в Docker Compose (${VAR}) escape-последовательности YAML (формат JSON) Используйте двойные кавычки, если: нужны спецсимволы; требуется интерполяция ${VARIABLE}; конфиг используется в CI/CD, Docker Compose, K8s; значение включает переносы строк с escape. Пример: server_name: "${SERVER_NAME}" welcome: "Hello,\nworld!" path: "C:\\Users\\Admin" json: "{\"key\": \"value\"}" 3. Отличия по поведению (в таблице) Особенность 'одинарные' "двойные" Интерполяция переменных нет да Обработка \n, \t, \" нет да Выполняет escape-последовательности нет да Буквальная строка да нет Работает в Docker Compose безопаснее для переменных Вложенные кавычки только '' для ' можно \" 4. YAML без кавычек: когда можно Чаще всего YAML допускает строки без кавычек, если они не содержат спецсимволов: domain: example.com env: production Но кавычки требуются, если есть: двоеточие : (кроме конца строки) # {}, [] *, & $ (в Docker Compose!) \ 5. YAML в Docker Compose (важно для 2025) В Docker Compose "..." интерполирует переменные окружения: environment: DOMAIN: "${DOMAIN}" Если нужно отключить интерполяцию: environment: PASSWORD: '$ecure$Tr!ng' или даже: PASSWORD: '${NOT_A_VARIABLE}' 6. YAML в Ansible В Ansible двойные кавычки требуются для Jinja2: msg: "Server is {{ inventory_hostname }}" А если Jinja не нужен — безопаснее одинарные: msg: 'Literal text: {{ not_interpreted }}' 7. YAML и многострочный текст YAML использует блоковые литералы: Буквальный текст: script: | echo "Hello" echo "No interpolation" Сжатый вариант: multiline: > This is a long line that becomes a single line Кавычки тут обычно не используются. Итог: как правильно выбирать кавычки Одинарные ('...'), если: нужен буквальный текст нет интерполяции есть спецсимволы $, \, {}, которые должны остаться как есть Двойные ("..."), если: нужны переменные ${...} нужны спецсимволы \n, \t, Unicode, JSON сложные значения в CI/CD или Docker Compose

Взаимодействие Nginx и Certbot для получения и управления SSL-сертификатами Certbot — это официальный клиент Let's Encrypt, который автоматизирует получение и установку SSL/TLS-сертификатов. Nginx — популярный веб-сервер, который может работать как реверс-прокси. Их интеграция позволяет легко перейти на HTTPS без ручной настройки. 1. Введение: Зачем нужен SSL и как Certbot взаимодействует с Nginx SSL/TLS-сертификаты обеспечивают шифрование трафика между клиентом (браузером) и сервером, предотвращая перехват данных. Без HTTPS сайт считается небезопасным в браузерах, и поисковики (как Google) понижают его в выдаче. Роль Certbot: Certbot автоматизирует процесс: проверяет владение доменом, запрашивает сертификат у Let's Encrypt и настраивает Nginx. Плагин --nginx специально интегрируется с конфигурацией Nginx, временно модифицируя её для проверки. Преимущества интеграции: Бесплатно и автоматически (сертификаты на 90 дней с автопродлением). Минимальные изменения в конфиге. Поддержка редиректа HTTP → HTTPS. Аналогия: Certbot — как мастер-установщик, который проверяет, что домен ваш (через " challenge" — вызов), а затем "вклеивает" замки (сертификаты) в дверь вашего сервера (Nginx). Предварительные требования: Установленный Nginx (sudo apt install nginx на Ubuntu). Установленный Certbot (sudo apt install certbot python3-certbot-nginx). Домен с A-записью,指向 на IP сервера. Открытый порт 80 в фаерволе (для проверки). 2. Минимальная настройка Nginx для Certbot Для успешного получения сертификата Nginx должен слушать порт 80 и иметь блок server с правильным server_name. Certbot использует HTTP-01 challenge: он создаёт временный файл на сервере, и Let's Encrypt проверяет его доступность по HTTP. Минималистичный конфиг для выпуска сертификата Если ваш бэкенд (приложение) ещё не готов, используйте простой конфиг, независимый от прокси. Создайте файл в /etc/nginx/sites-available/my_domain.conf и активируйте симлинк в sites-enabled. server { listen 80; server_name my_domain.tld; # Замените на ваш домен location / { root /var/www/html; # Пустая директория для статических файлов } } Почему это работает? Certbot ищет блок с server_name, совпадающим с доменом (-d my_domain.tld). Он временно добавит location /.well-known/acme-challenge/ для проверки, не трогая ваш location /. Проверка конфига: sudo nginx -t (проверить синтаксис). sudo systemctl reload nginx (применить изменения). Если у вас уже есть прокси-настройки (для приложения на порту 9090), они тоже подойдут, но убедитесь, что бэкенд запущен, иначе Nginx может не перезагрузиться. Пример с прокси (если бэкенд готов): server { listen 80; server_name my_domain.tld; keepalive_timeout 60; location / { proxy_pass http://localhost:9090; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_cache off; proxy_buffering off; proxy_read_timeout 100s; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } Нюанс: Если бэкенд не работает, Certbot может выдать ошибку при reload. В этом случае используйте минималистичный вариант выше. 3. Процесс получения сертификата с Certbot --nginx Запустите команду: sudo certbot --nginx -d my_domain.tld Что происходит шаг за шагом Проверка владения (HTTP-01 Challenge): Certbot создаёт секретный файл в /.well-known/acme-challenge/ на вашем сервере. Временно модифицирует конфиг Nginx, добавляя правило для этой локации (выше вашего location /). Сервер Let's Encrypt запрашивает http://my_domain.tld/.well-known/acme-challenge/XYZ. Nginx отдаёт файл, подтверждая владение. Выпуск сертификата: Если проверка успешна, Certbot получает сертификат и ключи (/etc/letsencrypt/live/my_domain.tld/). Автоматически добавляет в конфиг: listen 443 ssl; Пути к сертификатам: ssl_certificate ...; ssl_certificate_key ...; Опции: include /etc/letsencrypt/options-ssl-nginx.conf; и ssl_dhparam ...; Предлагает настроить редирект с 80 на 443 (рекомендуется для безопасности). Автоматическое продление: Certbot создаёт таймер (systemd) или crontab для ежедневной проверки. Продление запускается, если осталось <30 дней. После успеха Certbot выдаст "Congratulations!". Теперь сайт доступен по HTTPS. Возможные проблемы: DNS не пропагировался: Проверьте A-запись. Порт 80 заблокирован: Откройте в UFW (sudo ufw allow 80). Конфликт с бэкендом: Используйте минимальный конфиг. 4. Редактирование конфига после получения сертификата После Certbot вы можете заменить временные настройки на реальные. Сохраните строки, помеченные # managed by Certbot — они нужны для продления. Пример итогового конфига с прокси и SSL: server { listen 80; server_name my_domain.tld; # Редирект на HTTPS (добавит Certbot, если выбрать) return 301 https://$server_name$request_uri; } server { listen 443 ssl; # managed by Certbot server_name my_domain.tld; keepalive_timeout 60; ssl_certificate /etc/letsencrypt/live/my_domain.tld/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/my_domain.tld/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot location / { proxy_pass http://localhost:9090; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_cache off; proxy_buffering off; proxy_read_timeout 100s; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } Проверьте: sudo nginx -t и sudo systemctl reload nginx. Совет: Разделите HTTP (редирект) и HTTPS в отдельные блоки для ясности. 5. Продление сертификата: Как Certbot работает с кастомным конфигом Certbot не повредит ваш конфиг при продлении (через 90 дней). Он: Временно добавляет правило для challenge. Проверяет синтаксис (nginx -t). Обновляет сертификаты и reload Nginx. Убирает временные изменения. Ваши прокси-настройки остаются нетронутыми, если нет ошибок синтаксиса. Тестирование продления Запустите симуляцию: sudo certbot renew --dry-run Если "all simulated renewals succeeded" — всё в порядке. Автоматизация: Certbot сам настраивает таймер. Проверьте: sudo systemctl list-timers. 6. Лучшие практики и распространённые ошибки Структура конфига: Держите SSL-строки от Certbot нетронутыми. Используйте отдельные файлы для сайтов (/etc/nginx/sites-available/). Безопасность: Включите HSTS (add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;) после настройки. Мониторинг: Установите уведомления о продлении (опция Certbot --post-hook для скриптов). Ошибки: "No matching server block": Убедитесь в правильном server_name. Ошибка reload: Запустите бэкенд или используйте статический root. Многодоменные сертификаты: Добавьте -d домен2.tld. Альтернативы: Для продвинутых — Certbot в standalone режиме (без Nginx), но --nginx удобнее.

Основы DNS (Domain Name System) 1. Что такое DNS и зачем она нужна? DNS — это Domain Name System, или система доменных имён. Представьте интернет как огромный город, где каждый сервер или сайт — это дом с уникальным адресом. Эти адреса — IP-адреса (например, 192.0.2.1 для IPv4 или 2001:db8::1 для IPv6). Но запоминать цифры неудобно, поэтому DNS работает как телефонная книга интернета: она переводит удобные для людей имена (домены, как example.com) в IP-адреса, которые понимают компьютеры. Ключевые компоненты DNS: Доменное имя: example.com — это иерархическая структура. "com" — топ-уровень (TLD), "example" — второй уровень. DNS-записи: Типы записей, такие как: A-запись: Связывает домен с IPv4-адресом. AAAA-запись: Для IPv6. NS-запись: Указывает на авторитативные DNS-серверы (о них ниже). MX-запись: Для почты. CNAME-запись: Псевдоним для другого домена. Регистратор домена: Компания, где вы покупаете домен (например, GoDaddy или Reg.ru). Здесь вы настраиваете NS-записи. Без DNS вы бы набирали IP-адреса в браузере вместо доменов — это было бы неудобно и хаотично. 2. Как работает DNS: Процесс разрешения имён Когда вы вводите домен в браузер (например, google.com), происходит разрешение DNS — поиск IP-адреса. Это многоступенчатый процесс, похожий на цепочку вопросов: Локальный кэш: Ваш компьютер (ОС или браузер) проверяет, нет ли уже сохранённого IP для этого домена. Рекурсивный DNS-сервер: Если нет, запрос идёт к серверу вашего провайдера (ISP) или публичному (как 8.8.8.8 от Google). Этот сервер "рекурсивно" ищет ответ, спрашивая другие серверы. Корневые серверы: Их 13 по миру (управляются организациями вроде ICANN). Они знают TLD (например, .com) и направляют к серверу TLD. Сервер TLD: Знает, где находятся NS-серверы для вашего домена (например, ns1.example.com). Авторитативные DNS-серверы: Эти серверы (указанные в NS-записях) дают окончательный ответ: "Домен example.com имеет IP 93.184.216.34". Весь процесс занимает миллисекунды благодаря кэшированию (см. ниже). Если серверы недоступны, запрос может завершиться ошибкой (например, "DNS_PROBE_FINISHED_NXDOMAIN"). Аналогия: Вы ищете адрес друга. Сначала смотрите в свою записную книжку (локальный кэш). Если нет — звоните в справочную (рекурсивный сервер), которая спрашивает районную справочную (TLD), а та — домоуправление (авторитативный сервер). 3. Кэширование DNS: Оптимизация и её нюансы Чтобы не запрашивать IP каждый раз заново, DNS использует кэширование — временное хранение данных. Кэши есть везде: Уровни кэширования: Браузер: Современные браузеры (Chrome, Firefox) имеют свой кэш DNS для ускорения. Он может работать поверх ОС и даже использовать технологии вроде DNS-over-HTTPS (DoH) для шифрования. Операционная система: Windows, macOS или Linux хранят кэш в памяти (очистка: ipconfig /flushdns в Windows). Роутер: Домашний роутер кэширует DNS для всей сети. ISP (провайдер): Крупные провайдеры (Ростелеком, МТС) имеют мощные кэши для миллионов пользователей. Глобальные серверы: Публичные DNS (Google, Cloudflare) тоже кэшируют, но обновляются быстрее. TTL (Time To Live): Это "срок жизни" записи в секундах (например, 3600 = 1 час). TTL говорит кэшу: "Храни эту информацию столько времени, потом проверь заново". Длинный TTL (24–72 часа) экономит трафик, но замедляет обновления. Короткий TTL (5–10 минут) ускоряет изменения, но нагружает серверы. Кэширование делает DNS быстрым, но может привести к задержкам при изменениях (см. раздел о пропагации). 4. Пропагация DNS: Как распространяются изменения Когда вы меняете DNS-запись (например, переносите сайт на новый сервер с новым IP), изменения не происходят мгновенно. Это называется пропагацией DNS — распространением обновлений по глобальной сети. Почему это занимает время? Изменение вносится на авторитативных серверах (у хостинга или регистратора). Кэши по миру обновляются только по истечении TTL старой записи. Разные серверы (в разных странах, у разных ISP) обновляются асинхронно — от минут до 72 часов (максимум, рекомендованный ICANN). Факторы влияния: Длинный TTL старой записи: Кэши держат её дольше. География: Серверы в Европе обновятся быстрее, чем в Азии. Неконсистентность: Если NS-записи указывают на разные серверы, данные могут расходиться. Пропагация — это нормальный процесс, но для ускорения устанавливайте короткий TTL перед изменениями (за 24–48 часов). 5. Диагностика и инструменты для работы с DNS Чтобы проверить DNS, используйте инструменты: Команды в терминале: nslookup your-domain.com: Показывает IP. nslookup -type=ns your-domain.com: Список NS-серверов. nslookup your-domain.com ns1.example.com: Запрос к конкретному NS. Онлайн-сервисы: dnschecker.org: Проверяет пропагацию по миру (введите домен, тип A — увидите IP из разных стран). toolbox.googleapps.com/apps/dig/: Аналог dig-команды для детального анализа. dnsviz.net: Визуализирует цепочку делегирования, выявляет несоответствия. Очистка кэша: В Windows: ipconfig /flushdns. Перезагрузка роутера/ПК. Смена DNS на публичные: Google (8.8.8.8), Cloudflare (1.1.1.1). Эти инструменты помогут диагностировать, где именно "застряли" данные. 6. Частный случай: Проблемы со сбоем доменов после изменений Как частный случай, иногда после переноса домена на новый сервер (например, с Yunohost на Nextcloud) в разных местах видны разные IP: на одном ПК — старый сервер, на другом — новый; даже в браузерах на одном устройстве. Это вызвано неполной пропагацией и кэшированием (разные TTL, ISP-кэши). Проблема обычно решается ожиданием (до 72 часов), очисткой кэша или корректировкой NS-записей. Для детальной диагностики используйте dnschecker.org и nslookup. 7. Лучшие практики по работе с DNS Планируйте изменения: Установите короткий TTL заранее. Используйте надёжные DNS: Публичные для стабильности, авторитативные от хостинга. Мониторьте: Регулярно проверяйте записи через сервисы. Безопасность: Включайте DNSSEC для защиты от подмены. Избегайте ошибок: Убедитесь, что все NS-серверы синхронизированы и отдают одинаковые данные.

Информация о версии PeerTube Вариант 1. cd /var/www/peertube/peertube-latest && node dist/server --version Вариант 2. cd /var/www/peertube/peertube-latest && yarn --cwd . peertube --version Информация о версии PostgreSQL psql --version

Информация о версии PostgreSQL psql --version

Изменение порта После этого желательно поменять порты на какие-то редко используемые. По умолчанию для Webmin порт 10000, но этот порт может использоваться другими сервисами. Например, Jitsi. Чтобы поменять порт открываем файл /etc/webmin/miniserv.conf и меняем там порт в строке port=10000 (меняем, например, на port=55555) listen=10000 (это устаревшая строка для совместимости. Удаляем, оставляем как есть, или можно поставить тоже порт как в настройке port) Перезагружаем Webmin командой sudo systemctl restart webmin Заходим по адресу https://<ip_сервера>:55555

Изменения в конфигах Cockpit В каждом LXC-контейнере (/etc/cockpit/cockpit.conf): Для первого: [WebService] Origins = https://my_domain.tld wss://my_domain.tld # меняем на нужный домен ProtocolHeader = X-Forwarded-Proto AllowUnencrypted = true UrlRoot = /vm1 # Добавляем эту строку для первого сервера Для второго: [WebService] Origins = https://my_domain.tld wss://my_domain.tld # меняем на нужный домен ProtocolHeader = X-Forwarded-Proto AllowUnencrypted = true UrlRoot = /vm2 # Добавляем эту строку для второго сервера Далее - для каждой системы с Cockpit systemctl restart cockpit

Заходим по адресу https://my_domain.tld Вводим имя и пароль системного пользователя в окне авторизации

Для полного удаления RustDesk с Debian 13 (Trixie) необходимо не только деинсталлировать сам пакет, но и очистить конфигурационные файлы, которые программа сохраняет в системных и пользовательских директориях. Выполните следующие шаги в терминале: ###1. Удаление пакета и системных настроекИспользуйте команду purge, чтобы удалить бинарные файлы и общесистемные конфиги: sudo apt purge rustdesk После этого удалите оставшиеся зависимости, которые больше не нужны: sudo apt autoremove ###2. Очистка пользовательских данных (ID и настройки)RustDesk сохраняет ваш уникальный ID и настройки подключения в домашних папках пользователей (включая пользователя root, если вы запускали программу от его имени). Для текущего пользователя: rm -rf ~/.config/rustdesk Для пользователя root (если применимо): sudo rm -rf /root/.config/rustdesk ###3. Удаление сервисных и лог-файловИногда RustDesk оставляет следы в системных папках для работы службы в фоновом режиме. Чтобы очистить их полностью: Проверьте и удалите логи: sudo rm -rf /var/log/rustdesk Удалите остатки в /etc и /var/lib: sudo rm -rf /etc/rustdesk sudo rm -rf /var/lib/rustdesk ###4. Очистка репозитория (если добавляли вручную)Если вы устанавливали RustDesk через официальный репозиторий (а не просто скачивали .deb пакет), удалите файл списка источников и ключ: sudo rm /etc/apt/sources.list.d/rustdesk.list sudo rm /usr/share/keyrings/rustdesk.gpg (Названия файлов могут отличаться, проверьте их в папке /etc/apt/sources.list.d/). ###Как проверить результат?Чтобы убедиться, что в системе не осталось «хвостов», выполните поиск: find / -name "*rustdesk*" 2>/dev/null Если команда ничего не выводит — удаление прошло успешно. Если вы удаляли RustDesk из-за технических проблем или планируете искать замену, могу ли я помочь вам с настройкой другого инструмента удаленного доступа?

Для полного удаления AnyDesk в Debian (и других дистрибутивах на базе DEB, таких как Ubuntu или Mint) недостаточно просто удалить пакет. Программа оставляет конфигурационные файлы, ключи репозитория и пользовательские настройки. Вот пошаговый процесс полной очистки: ###1. Удаление пакета и системных файловИспользуйте команду purge, чтобы удалить саму программу вместе с системными конфигурационными файлами: sudo apt purge anydesk После этого удалите неиспользуемые зависимости: sudo apt autoremove ###2. Удаление пользовательских данныхAnyDesk хранит ваш ID, пароли и настройки в домашней директории пользователя. Эти файлы не удаляются через apt. Удалите скрытую папку настроек: rm -rf ~/.anydesk ###3. Очистка системных остатков (для полной чистоты)Иногда после удаления остаются файлы в системных директориях. Проверьте и удалите их: Глобальные настройки: sudo rm -rf /etc/anydesk Служебные файлы (лог-файлы и кэш): sudo rm -rf /var/lib/anydesk ###4. Удаление репозитория AnyDeskЕсли вы добавляли официальный репозиторий AnyDesk, чтобы получать обновления, его тоже стоит убрать, чтобы apt не опрашивал его в будущем: Удаление списка источников: sudo rm /etc/apt/sources.list.d/anydesk-stable.list Удаление ключа GPG: Найдите ключ AnyDesk в системе (обычно он называется anydesk.gpg или находится в общем списке) и удалите его: sudo rm /usr/share/keyrings/anydesk.gpg (Если путь отличается, проверьте содержимое /usr/share/keyrings/ или /etc/apt/trusted.gpg.d/). ###Как проверить, что всё удалено?Вы можете выполнить поиск по системе на наличие любых упоминаний AnyDesk: whereis anydesk find / -name "*anydesk*" 2>/dev/null Если команды ничего не вывели — система полностью чиста.

Webmin оставляет после себя довольно много файлов и каталогов в разных местах. Полная процедура удаления (чтобы повторная установка была чистой) Выполните по порядку: # 1. Остановите Webmin (на всякий случай) sudo /etc/webmin/stop # 2. Удалите пакет sudo apt remove webmin # просто удаляет пакет sudo apt purge webmin # удаляет пакет + конфиги из /etc/webmin # 3. Удалите оставшиеся зависимости (опционально, если они больше не нужны) sudo apt autoremove # 4. Вручную удалите то, что purge не трогает (это важно для чистой переустановки) sudo rm -rf /etc/webmin # основной конфиг (purge обычно удаляет, но на всякий) sudo rm -rf /var/webmin # сессии, логи, кэш, модули, temporary files sudo rm -rf /tmp/.webmin # временные файлы (часто остаются) sudo rm -rf /usr/share/webmin # основные файлы Webmin (если остались после purge) # 5. Удалите пользователя и группу webmin (если создавались) sudo userdel webmin 2>/dev/null || true sudo groupdel webmin 2>/dev/null || true # 6. Если вы добавляли репозиторий Webmin в sources.list # Удалите строку с http://www.webmin.com/download/webmin в /etc/apt/sources.list или /etc/apt/sources.list.d/webmin.list sudo rm -f /etc/apt/sources.list.d/webmin.list sudo apt update Почему это важно /etc/webmin — purge обычно удаляет, но иногда остаются файлы. /var/webmin — здесь хранятся сессии, логи miniserv.log, модули, обновления, кэш тем (authentic-theme и т.д.). При переустановке без удаления этого каталога старые настройки (тема, пользователи, модули) могут подтянуться обратно. /tmp/.webmin — временные файлы терминала, websocket-серверов и т.д. /usr/share/webmin — основные скрипты и модули. После apt purge обычно удаляется, но иногда остаётся при неполном удалении. После повторной установки — Установка Webmin пройдёт полностью с нуля: дефолтный порт 10000, дефолтная тема (authentic-theme свежая), miniserv.pem новый, никаких старых настроек прокси, websocket_host и т.д. Если вы устанавливали Webmin не из deb-пакета, а из тарбола (.tar.gz), то удаление только ручное (rm -rf всех перечисленных каталогов + /usr/local/webmin если там).

Добро пожаловать в базу знаний, посвящённую открытым информационным технологиям. Здесь вы найдёте структурированную информацию об интернет-сервисах и других программных решениях, способствующих цифровому суверенитету. Выберите желаемую категорию.