💡 Полезные Советы

Частая ситуация: вы настраиваете свежий сервер на 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 версии и не ограниченный лимит на генерацию. А так же дополнительные пресеты для подготовки уроков.

Разбор ошибки LightingService.exe: почему падает подсветка ASUS

Если вы заметили в журнале событий Windows множество ошибок, связанных с LightingService.exe, знайте: это сбой фоновой службы ASUS Aura. Она отвечает за управление RGB-подсветкой материнской платы, видеокарты и другой периферии.

Давайте разберем анатомию этого сбоя на примере конкретного лога.

🔍 1. Технический анализ ошибки

В деталях события мы видим следующие ключевые параметры:

• Имя сбойного модуля: AacHal_x86.dll
• Код исключения: c00000fd

Что скрывается за аббревиатурами?
Модуль AacHal расшифровывается как ASUS Aura Controller Hardware Abstraction Layer. Это «прослойка» (уровень аппаратных абстракций), через которую софт общается с физическим контроллером подсветки на железе. Именно здесь происходит критическая ошибка.

Код c00000fd в Windows однозначно указывает на STATUS_STACK_OVERFLOW (Переполнение стека).

🔄 2. Почему ошибок так много? (Бесконечный цикл)

На скриншоте видно, что сбои идут чередой с интервалом в пару минут (0:00, 0:02, 0:04...). Это классическая картина «петли смерти» службы:

1. Служба запускается.
2. Драйвер попадает в бесконечную рекурсию (вызывает сам себя), моментально исчерпывает выделенную память (стек).
3. Происходит аварийное завершение (краш).
4. Windows видит, что служба упала, и согласно настройкам восстановления, пытается запустить её снова.
5. Цикл повторяется.

⚠️ 3. Чем это опасно?

Подобное поведение драйверов (в данном случае — компонента подсветки) несет серьезные риски:

• Синий экран смерти (BSOD): Если переполнение стека произойдет на уровне ядра, Windows не сможет просто перезапустить службу и уйдет в BSOD, часто даже не успев записать дамп памяти.
• Уязвимость системы: Ошибки в драйверах (утечки памяти, состояние гонки) — это дыры в безопасности. Злоумышленники или вирусы могут использовать уязвимый драйвер как лазейку для повышения привилегий или маскировки вредоносных действий.

Золотое правило обновления OpenWrt: "Обновлять прошивку без сохранения настроек всех настроек". Иначе могут возникать различные проблемы и конфликты.

Вот полезная инструкция для тех, кто столкнется с такой же проблемой.

Симптомы(Это означает, что проблема на 100% в настройках роутера.):

• На компьютере ошибка "Не удается связаться с DNS-сервером".

• В интерфейсе OpenWrt (Network -> Interfaces) на wan-интерфейсе есть исходящие пакеты (TX), но нет входящих (RX: 0 B (0 Pkts.)).

• Если подключить кабель провайдера напрямую к компьютеру - интернет есть.

Небольшая инструкция:

1. Скачайте нужный файл прошивки с официального сайта OpenWrt. (Используйте образ Sysupgrade образ можно использовать с веб-интерфейсом LuCI или в терминале.)

2. Зайдите в System -> Backup / Flash Firmware.

3. Загрузите прошивку. В процессе обновления НИ в коем случае НЕ отключайте питание.

4. В процессе обновления ОБЯЗАТЕЛЬНО снимите галочку "Keep settings" (Сохранить настройки).

5. Роутер перезагрузится с настройками по умолчанию. (нужно будет настроить всё с нуля)

Это устраняет 90% всех проблем, связанных с обновлением, включая "призрачные" интерфейсы вроде br-wan, ошибки со значками из-за установки различных сторонних пакетов и прочее.