Если у вас крутится зоопарк собственных сервисов, рано или поздно встает вопрос: как узнать, что всё работает, до того, как пользователи (или вы сами) обнаружат ошибку 502?

Uptime Kuma - это легковесный, опенсорсный аналог UptimeRobot, который можно развернуть на своем железе за пару минут. У него красивый интерфейс, поддержка десятков видов уведомлений и богатый функционал для создания публичных статус-страниц.

Для каких проектов подходит Uptime Kuma?

Этот инструмент универсален и отлично вписывается в самые разные сценарии:

• Домашние лаборатории (Homelab): Идеально для серверов на базе Raspberry Pi или виртуалок в Proxmox. Можно мониторить локальные DNS-фильтры, прокси-менеджеры, умный дом и базы данных, API.
• Сайты и пет-проекты: Контроль доступности ваших блогов, лендингов и веб-приложений извне
• Проверка открытых TCP-портов. Удобно, если вы держите, например, сервер по Counter-Strike и хотите знать, когда он "прилег".
• Контроль SSL-сертификатов: Kuma умеет заранее предупреждать, что сертификат сайта скоро протухнет.

Как установить?

Самый простой, надежный и чистый способ развернуть Uptime Kuma - использовать Docker.

Создайте директорию для проекта, а внутри - файл docker-compose.yml со следующим содержимым:

version: '3.3' # В новый версиях Docker не обязательно указывать!
services:
 uptime-kuma:
   image: louislam/uptime-kuma:1
   container_name: uptime-kuma
   volumes:
     # Обязательно пробрасываем volume, чтобы статистика не пропала при рестарте контейнера.
     # Хранить данные лучше на надежном носителе (например, eMMC или HDD).
     - ./uptime-kuma-data:/app/data
     # Раскомментируйте строку ниже, если планируете мониторить другие Docker-контейнеры
     # - /var/run/docker.sock:/var/run/docker.sock
   ports:
     - "3001:3001"
   restart: unless-stopped

После этого запускаем контейнер:

docker-compose up -d

Готово! Теперь интерфейс доступен по адресу: http://<IP_вашего_сервера>:3001.

Базовая настройка: с чего начать?

При первом входе система попросит создать учетную запись администратора. Дальше начинается самое интересное:

1. Добавление мониторов:
      Нажмите "+ Новый монитор". Выберите тип (HTTP/HTTPS для сайтов, Ping для хостов, TCP Port для баз данных или игр). Укажите адрес и интервал проверок.
      Лайфхак: Если у вас бывают микроразрывы сети и выскакивают ошибки вроде ECONNRESET, увеличьте параметр "Количество повторных попыток" (Retries) до 2-3. Это избавит от ложных срабатываний.

2. Настройка уведомлений (Алертов):
      Зайдите в настройки монитора -> "Настроить уведомления". Uptime Kuma поддерживает всё: от Email и Webhooks до Telegram и Discord. Проще всего создать Telegram-бота через BotFather, вписать его токен в Kuma и получать моментальные пуши о падении сервисов прямо в мессенджер.

   

3. Публичные страницы статуса (Status Pages):
      В верхнем меню есть кнопка "Страницы статуса". Там можно собрать красивый дашборд с зелеными полосками аптайма, добавить свой логотип, разделить сервисы по группам (например, "Внешние сайты" и "Внутренняя инфраструктура") и выставить это всё в открытый доступ, чтобы ваши пользователи всегда видели актуальное состояние проектов.

   

Работа с инцидентами (Ручное информирование)

Автоматика - это хорошо, но иногда сервер уходит в оффлайн по вашей инициативе. Например, вы планируете провести обслуживание Raspberry Pi 5 (Сервера), обновить ядро или восстановить систему из бэкапа на eMMC диске. Чтобы на странице статуса не появилась пугающая красная полоса "Недоступен", в Uptime Kuma есть механизм Инцидентов.

На странице статуса нажмите зеленую кнопку "Создать инцидент". Перед вами появится форма:

• Название инцидента: Краткая суть (например, "Плановое техническое обслуживание" или "Проблемы с хостинг-провайдером").
• Содержание инцидента: Подробное описание ситуации. Поле поддерживает синтаксис Markdown, так что текст можно красиво отформатировать, добавить списки или ссылки.
• Стиль: Выпадающий список позволяет выбрать визуальное оформление плашки, которая появится на дашборде.
  • ИНФО - нейтральное уведомление (полезно для плановых работ).
  • ВНИМАНИЕ - желтый алерт (сервис работает нестабильно).
  • ОШИБКА - красный алерт (всё упало, мы уже чиним).
  • ОСНОВНОЙ / СВЕТЛЫЙ / ТЕМНЫЙ - системные цвета для кастомизации под дизайн вашей страницы.

Как только работы завершатся, инцидент можно "Закрыть", и он уйдет в историю, а пользователи увидят, что проблема решена.

Глоссарий

• Аптайм (Uptime): Время непрерывной работы вычислительной системы или сервиса с момента последней загрузки. Выражается в процентах (например, 99.9% - отличный показатель).
• Даунрайм (Downtime): Время простоя, когда сервис недоступен для пользователей по техническим причинам.
• Дашборд (Dashboard): Информационная панель (доска), на которую выводятся ключевые показатели и графики в удобном для чтения виде. В Uptime Kuma это "Страницы статуса".
• Монитор (Monitor): Отдельная задача проверки в Uptime Kuma, которая регулярно опрашивает конкретный сервис (сайт, IP-адрес, порт) на предмет его "жизни".
• Инцидент (Incident): Событие, приводящее к прерыванию работы сервиса или снижению качества его работы. На статус-страницах используется для информирования пользователей о текущих проблемах или плановых работах.
• Пинг (Ping): Базовая сетевая утилита для проверки целостности и качества соединений. Отправляет эхо-запрос к узлу сети и фиксирует время ответа.
• Self-hosted (Селфхост): Практика самостоятельного размещения и обслуживания программного обеспечения на собственных серверах, а не использования облачных решений от сторонних компаний.

Uptime Kuma работает по принципу "настроил и забыл", потребляет минимум ресурсов.

Бонус: Мониторинг с Grafana и Prometheus

Встроенные публичные "Страницы статуса" в Uptime Kuma отлично подходят для пользователей вашего сайта. Но если вы лично хотите видеть максимально подробную картину с графиками задержек до миллисекунды, историю SSL-сертификатов и глубокую аналитику - данные нужно выводить в Grafana.

Uptime Kuma спроектирована по всем канонам современного мониторинга и умеет отдавать свои метрики в формате базы данных Prometheus (по адресу http://<ваш-ip>:3001/metrics).

Как это работает на практике:

• Вы разворачиваете контейнер с базой данных Prometheus и указываете ему забирать метрики из Uptime Kuma (добавив блок в prometheus.yml).

  Пример:

  global:
    scrape_interval: 15s
  
  scrape_configs:
    - job_name: 'node-exporter'
      static_configs:
        - targets: ['node-exporter:9100']
  
    - job_name: 'cadvisor'
      static_configs:
        - targets: ['cadvisor:8080']
  
    - job_name: 'uptime-kuma'
      basic_auth:
        username: 'Ваш логин'
        password: 'Ваш пароль'
      static_configs:
        - targets: ['uptime-kuma:3001']

• Разворачиваете контейнер с Grafana и подключаете к ней Prometheus как источник данных (Data Source).
• Импортируете готовый шаблон дашборда (например, введя ID 18278 или 25062 в разделе Import).

В результате вы получаете роскошную, интерактивную панель управления с детализацией каждого пинга, которую можно тонко настраивать под себя. Это идеальный вариант для главной страницы вашей внутренней панели управления инфраструктурой.

Приветствую! С вами riopass.ru, и сегодня мы поговорим о боли, слезах и единственной вещи, которая отделяет системного администратора от нервного срыва - о резервном копировании.

Предыстория: ничто не предвещало беды. Изначально я задумал развернуть локальную нейросеть на базе Ollama на своей Raspberry Pi 5 под управлением Raspberry Pi OS. Через скрипты Pi-Apps установка не завелась. Я, как положено, всё вычистил и решил ставить с официального сайта, чтобы скрипт сам подтянул нужную архитектуру и всё настроил.

Туда же "до кучи" была установлена пачка других утилит и запущен процесс обновления компонентов. А потом я просто решил выключить "Малинку" для плановой замены домашнего роутера. И оставил так спустя день.

И она больше не включилась...

При подаче питания вентилятор начинал выть на все 120%, а графическая оболочка и система в целом отказывались стартовать. Умные ИИ-ассистенты, к которым я пошел за советом, дружно начали хоронить железо: "у вас умер адаптер - просадка V5", "сгорела SD-карта", "повредилась файловая система". Максимум, что показала диагностика - это пресловутый dirty bit на загрузочном разделе (признак внезапного отключения питания), который утилита fsck успешно сняла, но систему это не оживило.

Основная проблема крылась в самой Ollama и криво вставших обновлениях - они просто намертво вешали инициализацию ядра.

И тут я вспомнил про raspiBackup. Это гениальный скрипт от немецких разработчиков, который я когда-то давно настроил на еженедельный сброс дампов на свой мини-сервер через SMB-шару. Помню, тогда ещё думал: "Блин, ну это же минус 30-40 ГБ места на диске! Бэкапы, которые никогда не пригодятся мне не пригодяться".

В итоге именно эти "лишние" гигабайты меня и спасли. Потому что реанимировать систему удалось только накатив бэкап. Ниже - подробная инструкция, как восстановить Raspberry Pi из архива raspiBackup, используя сторонний ПК (в моем случае - рабочий ноутбук на Debian 13).

Инструкция: Восстановление raspiBackup на другом Linux-ПК

Если ваша Малинка "мертва", вы не сможете запустить скрипт восстановления на ней самой. Нам понадобится любой компьютер с Linux (например, Ubuntu, Debian или Mint) и кардридер/переходник.

Шаг 1. Готовим накопитель и бэкап

1. Подключаем флешку или NVMe-накопитель от мертвой Raspberry к нашему Linux-ПК.

2. Проверяем, под каким именем накопитель определился в системе:

   lsblk

   Внимательно ищем свой диск по размеру (например, /dev/sdb). Это критически важно, чтобы случайно не отформатировать системный диск ноутбука!

3. Убеждаемся, что папка с вашим бэкапом (вида Имя@debian-tar-backup-Дата) доступна на этом ПК - локально или примонтирована по сети. Я перекинул заранее через команду scp.

Шаг 2. Скачиваем утилиту

Если скрипта raspiBackup нет на вашем ПК, скачиваем его одной командой:

curl -sSLO https://raw.githubusercontent.com/framps/raspiBackup/master/raspiBackup.sh
chmod +x raspiBackup.sh

Шаг 3. Запускаем магию (Осторожно, пофиг!)

Если вы просто запустите скрипт на ПК (архитектура x86_64), он выдаст ошибку RBK0268E: Only Raspberries running Raspberry PI OS are supported. Он "видит", что вы не на ARM, и отказывается работать.

Чтобы заставить скрипт развернуть бэкап на "чужеродной" системе, нужно использовать специальный флаг --unsupportedEnvironment.

Выполняем команду (не забудьте подставить свои данные!):

sudo ./raspiBackup.sh --unsupportedEnvironment -d /dev/sdb /путь/к/папке/с/бэкапом

Где /dev/sdb - это ваш накопитель от Малинки.

На скриншоте выделил красным IPv6 Link-Local, то что подключился по RDP с PC на ноутбук. (на самом роутере у меня IPv6 выключен)

Что произойдет дальше:
Скрипт прочитает структуру старого диска, сам переразметит разделы, зальет boot-сектор и распакует ваш тяжелый tar.zst архив прямо в корень. Прогресс-бара распаковки архива не будет - терминал просто "задумается" на 10–20 минут. Не прерывайте процесс! Дождитесь сообщения об успехе, извлеките диск и вставляйте его в Raspberry. Она загрузится так, будто ничего и не ломалось. (У меня в обще ноутбук заснул, я думал всё сломалось, но нет, успех!)

Бонус: IPv6 Link-Local - как найти сервер, если роутер умер

В моей истории всё началось с замены роутера. Часто при смене сетевого оборудования, изменении подсетей (например, с 192.168.1.x на 192.168.0.x) или выходе из строя DHCP-сервера, ваш headless-сервер (без монитора) становится недоступным по сети. Вы не знаете его новый IP-адрес.

Здесь на сцену выходит IPv6 Link-Local (Локальный адрес канала).

Даже если в вашей сети нет интернета, нет роутера и нет DHCP-сервера, любое современное устройство с поддержкой IPv6 автоматически генерирует себе адрес в диапазоне fe80::/10. Этот адрес создается на основе MAC-адреса сетевой карты и существует только в пределах физического сегмента сети (от кабеля до кабеля).

Как это использовать для спасения?

Если Raspberry Pi потерялась в сети:

1. Берем обычный патч-корд и соединяем порт Ethernet на вашем ноутбуке напрямую с портом Raspberry Pi.
2. Включаем устройства. Они автоматически договорятся и создадут себе Link-Local адреса.
3.  На вашем ноутбуке (Windows/Linux) открываем терминал и сканируем соседей по IPv6 с помощью мультикаст-пинга:

•        На Linux/macOS: ping6 -I eth0 ff02::1 (где eth0 — ваше сетевое подключение).
•        На Windows: ping -6 ff02::1

Вам ответят адреса, начинающиеся на fe80::.... Один из них - это ваш ноутбук, второй - ваша потерянная Raspberry Pi!

Берем этот адрес и спокойно подключаемся по SSH:

ssh user@fe80::xxxx:xxxx:xxxx:xxxx%eth0

(Знак процента и имя интерфейса в конце обязательны, чтобы система поняла, через какой именно кабель стучаться).

Подключились напрямую - поправили настройки netplan или dhcpcd.conf под новый роутер, и сервер снова в строю.

Мораль: Изучайте сетевые технологии и делайте бэкапы. Это экономит не только время, но и не будете как Ганвест разговаривать потом.

Глоссарий к статье

Для тех, кто только погружается в мир Linux и домашних серверов, вот расшифровка ключевых терминов из статьи:

•  Ollama - инструмент (фреймворк), позволяющий разворачивать и запускать большие языковые нейросети (LLM) прямо у себя на домашнем железе, без интернета и цензуры.
•  Headless-сервер (безголовый сервер) - компьютер или микрокомпьютер (как наша Raspberry Pi), который работает без подключенного монитора, клавиатуры и мыши. Управляется исключительно по сети.
•  fsck (File System Consistency Check) - стандартная системная утилита в Linux. Врач-травматолог для жестких дисков и флешек: проверяет файловую систему на ошибки и пытается их исправить.
• Dirty bit (Грязный бит) - специальный флаг (метка) в файловой системе. Ставится автоматически, если выдернуть питание устройства до того, как система успела безопасно завершить работу с диском. Сигнализирует о том, что при следующей загрузке нужно запустить fsck.
• raspiBackup - мощный opensource-скрипт для Raspberry Pi. Умеет делать резервные копии работающей системы по расписанию и сохранять их на сетевые диски.
• SMB-шара (SMB Share) - общая сетевая папка, доступная другим устройствам в локальной сети. Названа в честь протокола Server Message Block, который исторически используется в Windows, но отлично понимается и Linux-системами.
• tar.zst - формат сжатого архива. Утилита tar собирает всю файловую систему в один большой файл-контейнер, а алгоритм zstd (Zstandard) сжимает его. Работает гораздо быстрее и эффективнее старых форматов вроде .gz или .zip.
• NVMe (Non-Volatile Memory Express) - современный протокол и формат быстрых твердотельных накопителей (SSD). Raspberry Pi 5 поддерживает их подключение через специальный шлейф (PCIe), что дает колоссальный прирост скорости по сравнению с обычными MicroSD-картами.
• DHCP-сервер (Dynamic Host Configuration Protocol) - служба, которая автоматически выдает IP-адреса всем устройствам в вашей домашней сети. Чаще всего эта функция встроена в ваш домашний Wi-Fi роутер.
• IPv6 Link-Local (Локальный адрес канала) - автоматический сетевой адрес (всегда начинается с fe80::), который любое современное устройство назначает себе само. Работает только в пределах одного физического провода или Wi-Fi сегмента. Позволяет устройствам общаться напрямую, даже если роутер сгорел, а DHCP-сервер мертв.
• SSH (Secure Shell) - защищенный сетевой протокол для удаленного управления компьютером через командную строку. Тот самый черный экран с белыми буквами, через который админы творят магию.

Частая ситуация: вы настраиваете свежий сервер на AlmaLinux, Rocky Linux или RHEL, пытаетесь установить привычные утилиты (например, ncdu для анализа диска или htop), но получаете ошибку:

Error: Unable to find a match: ncdu

Это сбивает с толку, ведь в других дистрибутивах эти пакеты доступны сразу. Разберемся, почему так происходит и как это исправить за одну минуту.

Почему ncdu "нет" в AlmaLinux?

На самом деле ncdu существует и отлично работает на этих системах. Проблема кроется в философии RHEL-подобных дистрибутивов:

1. Минимализм базы: Официальные репозитории (BaseOS, AppStream) содержат только самый необходимый и максимально стабильный софт, поддерживаемый вендором.

2. Сообщество: Большинство "удобных" инструментов администрирования (ncdu, htop, nload, jq, screen) вынесены в отдельный репозиторий - EPEL (Extra Packages for Enterprise Linux).

3. Результат: Пока EPEL не подключен, пакетный менеджер просто не видит эти программы.

Решение: Подключение EPEL

Чтобы пакеты стали доступны, нужно установить один специальный пакет, который добавит конфигурацию репозитория EPEL в систему.

1. Устанавливаем репозиторий EPEL:

sudo dnf install epel-release -y

2. Обновляем кэш (необязательно, но полезно):

sudo dnf makecache

3. Устанавливаем ncdu: Теперь команда сработает без ошибок:

sudo dnf install ncdu -y

Как проверить, что всё получилось?

Вы можете проверить информацию о пакете и убедиться, что он берется именно из EPEL:

dnf info ncdu

В выводе вы увидите строку Repository : epel и версию программы (например, 1.17 или новее).

Совет

Если вы часто настраиваете серверы, добавьте установку epel-release в свой базовый скрипт первоначальной настройки. Это сэкономит время при установке большинства популярных утилит для мониторинга и администрирования.

Коротко: большинство экспертов рекомендуют менять SSH‑ключи раз в 6 - 12 месяцев, но частота зависит от уровня риска и требований безопасности. Современные рекомендации подчёркивают, что ключи нельзя оставлять "вечными", потому что со временем они превращаются в скрытый риск для инфраструктуры.

1. Для личных проектов и своего сервера

Рекомендуемая частота: Раз в 1 год (или даже реже).

Для личного использования (если вы единственный администратор) частая смена ключей может создать больше проблем, чем пользы (например, риск потерять доступ при неправильной замене). Главное правило: Меняйте ключ немедленно, если:

• Вы потеряли ноутбук или флешку с ключом.

• Вы подозреваете, что ваш компьютер был заражен вирусом.

• Вы случайно "засветили" приватный ключ (выложили на GitHub, отправили в чат и т.д.).

2. Для работы и продакшна (Лучшая Практика)

Рекомендуемая частота: Раз в 3-6 месяцев.

В корпоративной среде риски выше.

• Стандарт PCI DSS (для работы с картами), из-за него многие корпоративные регламенты требуют ротацию каждые 90 дней (корпоративной среде существует огромная разница между "что написано в стандарте" и "что требуют аудиторы / безопасники на местах".)

• Это защищает от сценария, когда ключ был украден тихо (без вашего ведома) и злоумышленник использует его месяцами.

PCI DSS (Payment Card Industry Data Security Standard) - это "золотой стандарт" безопасности для любой организации, которая хранит, обрабатывает или передает данные банковских карт (Visa, Mastercard, МИР).

SSH - это главная дверь для управления сервером. Если ваш сервер имеет отношение к платежам или картам, то настройки SSH становятся объектом пристального внимания аудиторов PCI DSS.

Даже если вы не банк, требования PCI DSS полезно знать, потому что это готовая инструкция "как сделать действительно безопасно".

1. Запрет прямого входа root (Требование 8.6)

• Что требует стандарт: Каждое действие на сервере должно быть привязано к конкретному человеку. Если все заходят под общим логином root, то в логах будет видно «root удалил базу данных», но непонятно, кто именно это был - Вася или Петя.

• Ваша ситуация: Вы только что создали личного пользователя (h...) и отключили PermitRootLogin. Это полное соответствие стандарту. Теперь в логах будет видно: "Пользователь h... повысил права до root и удалил базу".

2. Запрет простых паролей и использование криптографии (Требование 2.3)

• Что требует стандарт: Для административного доступа через интернет нужно использовать сильную криптографию. Передача паролей в открытом виде запрещена.

• Ваша ситуация: SSH сам по себе шифрует трафик. А отключение входа по паролю (PasswordAuthentication no) и переход на ключи - это лучшая практика (Best Practice), которую аудиторы очень любят.

3. Регулярная смена ключей (Требование 3.6.4)

• Что требует стандарт: Криптографические ключи (Ключи шифрования данных (Data Encryption Keys)) должны меняться по расписанию (обычно каждые 90 дней), а старые - уничтожаться.

• Что это: Это ключи, которыми шифруется сама база данных с номерами карт. Если хакер украдет этот ключ и дамп базы, он сможет прочитать номера карт.

• Почему: Потому что эти ключи используются автоматически программами. Если такой ключ утечет, вы не узнаете об этом годами. Поэтому их принудительно меняют, чтобы ограничить объем данных, которые можно расшифровать одним ключом.

4. Не использовать "дефолтные" настройки (Требование 2.1)

• Что требует стандарт: Нельзя использовать пароли и настройки, которые идут "из коробки" (vendor-supplied defaults).

• Ваша ситуация: Вы уже изменили порт (если меняли?), отключили рута, создали своего юзера. Вы уже не используете дефолт.

Стандарт PCI DSS настоятельно рекомендует (а версия 4.0 требует) двухфакторную аутентификацию (MFA) даже для администраторов. PCI DSS не предписывает конкретный метод, например "SSH‑ключ + код Google Authenticator". Он требует наличия MFA, а конкретная реализация остаётся на усмотрение организации!

3. Критические ситуации (Менять немедленно)

В этих случаях расписание не имеет значения - нужно действовать сразу:

1. Увольнение сотрудника. Если ушел админ или разработчик, все ключи, к которым он имел доступ, должны быть удалены с серверов, а оставшиеся сотрудники должны сгенерировать новые.

2. Скомпрометированное устройство. Логика "я почистил компьютер антивирусом, значит всё в порядке" здесь не работает. Вирусы (трояны, стилеры) настроены искать именно файлы в папке .ssh. Как только вирус попадает на компьютер, он мгновенно копирует эти файлы и отправляет их злоумышленнику. Вы можете возразить: "Но у меня ключ защищен паролем (passphrase)!". Если устройство скомпрометировано, скорее всего, на нем работал кейлоггер (программа, записывающая нажатия клавиш). Когда вы вводили пароль, чтобы разблокировать ключ, хакер получил и файл ключа, и пароль к нему.

3. Смена алгоритмов шифрования. Если вы использовали старые ключи RSA-1024 или DSA (которые сейчас считаются слабыми), их нужно срочно заменить на современные Ed25519 или RSA-4096.

Частая ошибка при обновлении

Многие думают, что создание нового ключа автоматически отменяет старый. Это не так. SSH-сервер пускает по списку ключей. Если вы добавите новый ключ, но забудете удалить строку со старым ключом из файла ~/.ssh/authorized_keys, то старый ключ продолжит работать.

Правильный алгоритм ротации:

1. Сгенерировать новую пару ключей (ssh-keygen -t ed25519).

2. Добавить новый публичный ключ на сервер.

3. Проверить вход с новым ключом.

4. Удалить старый публичный ключ из файла authorized_keys на сервере.

5. Удалить старый приватный ключ с локального компьютера.

Стандартные инструкции с YouTube не всегда помогают, особенно когда имеешь дело со сложными конфигурациями. Статей по теме не нашлось, а стандартный вход через init=/bin/sh приводил либо к зависанию системы при попытке загрузки (exec init=/sbin/init), либо к ошибкам в графическом интерфейсе в духе "Извините, но сейчас это невозможно сделать".

Потратив 2 часа на эксперименты, я нашел рабочий алгоритм. Проблема крылась в SELinux и правах доступа, которые блокировали изменение пароля, выдавая ошибку Authentication token manipulation error.

Ниже - пошаговая инструкция для "тяжелых" случаев.

Предыстория: Вы забыли все пароли, включая root

Симптомы проблемы

• Вы сбросили пароль через passwd, но система выдает Authentication token manipulation error.
• Файловая система находится в режиме "Только чтение" (Read-only).
• При попытке входа в GUI вы видите ошибку о недоступности входа или пароль не подходит.

Инструкция по восстановлению

Шаг 1. Вход в режим редактирования загрузки

1. Перезагрузите компьютер.
2. Как только появится меню загрузки GRUB (черный экран со списком систем), быстро нажмите клавишу e (Edit).
3. Найдите строку, которая начинается с linux, linux16 или linuxefi.

4. В конце этой строки (через пробел) допишите:

   init=/bin/sh

5. Нажмите Ctrl + X (или F10), чтобы загрузиться в консоль.

Шаг 2. Подготовка файловой системы

По умолчанию диск смонтирован в режиме Read-only, поэтому изменения не сохранятся. Исправим это:

mount -o remount,rw /

Проверка (должно быть rw в строке вашего диска):

mount | grep root

Шаг 3. "Ручной взлом" пользователя

Если команда passwd не работает или выдает ошибки токенов, мы вручную отредактируем файлы конфигурации, чтобы система считала, что пароля у пользователя нет вовсе.

Этап А: Убираем хеш пароля

Откройте файл теней:

nano /etc/shadow

(Если nano нет, придется использовать vi).

Найдите строку нужного пользователя (например, cdr или root). Строка выглядит примерно так:
cdr:$6$hG7s... (длинный набор символов) ...:18416...

Вам нужно стереть всё, что находится между первым и вторым двоеточием. Должно стать:

cdr::18416...

Сохраните файл (Ctrl+O -> Enter) и выйдите (Ctrl+X).

Этап Б: Отключаем проверку "x" (Обязательно для надежности)

Откройте файл пользователей:

nano /etc/passwd

Найдите строку пользователя: cdr:x:1000:1000...
Удалите букву x после имени.

Должно стать:

cdr::1000:1000...

** Примечание: Если не помните пользователя, делайте это для пользователя root — под ним можно всё.

Сохраните и выйдите. Перезагрузитесь.

Шаг 4. Самый важный шаг (SELinux)

Вы увидите графическую оболочку, но нам нужна текстовая консоль, зайди в неё при помощи Ctrl+Alt+F7 или Ctrl+F7 например.

На большинстве систем:
•     GUI - Ctrl+Alt+F1 или Ctrl+Alt+F2
•     текстовые консоли - Ctrl+Alt+F3-F6

Ctrl+Alt+F7 - это старый Xorg-подход, сейчас не всегда работает.

Именно здесь большинство инструкций терпят неудачу. Поскольку мы редактировали системные файлы (shadow и passwd) вручную через редактор, метки безопасности SELinux сбились. Система думает, что файлы повреждены злоумышленником, и блокирует любые операции с паролями.

Восстановите контекст безопасности командами:

restorecon -v /etc/shadow
restorecon -v /etc/passwd

Шаг 5. Финальная установка пароля

Теперь препятствий нет. Задайте нормальный пароль прямо сейчас, чтобы войти в графический интерфейс без проблем.

passwd имя_пользователя

(Например: passwd cdr)

Введите новый пароль дважды. Вы должны увидеть заветное сообщение:

passwd: all authentication tokens updated successfully

Шаг 6. Перезагрузка

Теперь можно перезагружаться. Введите:

reboot -f

После загрузки вы сможете войти в систему. Ошибка «Извините, в данный момент это не работает» исчезнет, так как мы восстановили права доступа и корректно обновили токен.

P.S. Существуют и другие методы сброса, например, через Live CD или специализированные утилиты вроде Rescatux или SystemRescue. Они позволяют сбросить пароль в пару кликов, но если под рукой нет флешки с инструментами, а доступ к системе нужен "здесь и сейчас" - метод выше работает безотказно.

1. Регистрируем временную почту через сервис https://em.bjedu.tech - обязательно с доменом erzi.me, например teacher666@erzi.me
2. После регистрации будет получен токен и автологин ссылка для входа во временную почту - это лучше сохранить в блокнот для последующего входа.
3. Регистрируемся на https://chatgpt.com  желательно с нового браузера в котором не было ChatGPT или в старом нужно удалить все куки. На временную почту придет код, его нужно ввести, потом указать имя и фамилию желательно на латинице.

P.S: Могу ошибаться, но как я понял версия для учителя, дает неограниченный доступ к более мощным моделям в отличии от Free версии и не ограниченный лимит на генерацию. А так же дополнительные пресеты для подготовки уроков.