RISH 2.9.4: фикс AlmaLinux 8 и новое меню пользователей

RISH по-прежнему должен устанавливаться на AlmaLinux 8, однако актуальный установщик фактически перестал проходить весь сценарий на этой системе.

Проблема состояла сразу из нескольких предположений, справедливых для более новых систем, но не для EL8.

• Для чтения списка swap использовался вариант параметров swapon, несовместимый с установленной в AlmaLinux 8 версией util-linux.
• Установщик ожидал наличие logrotate.timer, хотя в AlmaLinux 8 штатный пакет запускает ротацию через /etc/cron.daily/logrotate.
• Пакет rclone отсутствовал в доступном системном репозитории EL8. Обычная установка через yum повторялась после очистки кэша, снова завершалась ошибкой и останавливала установку RISH.

В 2.9.4 мы не стали маскировать это формулировкой «улучшена совместимость». Сценарий установки на AlmaLinux 8 был сломан — теперь он исправлен с отдельной логикой для компонентов, которые отличаются от AlmaLinux 9 и 10.

Проверка активных swap-устройств теперь использует совместимую форму команды:

swapon --show=NAME --noheadings --raw

Если в системе уже есть обычный дисковый swap, RISH не создаёт второй. ZRAM учитывается отдельно: наличие только сжатого swap в памяти не мешает установщику предложить дисковый swap-файл.

После создания или обнаружения /swapfile RISH проверяет всю цепочку постоянной настройки:

1. swap-файл должен быть активен;
2. в /etc/fstab должна находиться запись именно для этого пути и типа swap;
3. vm.swappiness=10 применяется к работающей системе через sysctl;
4. то же значение записывается в /etc/sysctl.conf;
5. после записи файл перечитывается и значение проверяется.

Если любой обязательный шаг не выполнен, установщик больше не помечает настройку завершённой. Он останавливается, сообщает причину и предлагает после её устранения повторно запустить /root/rish/ri.sh.

Перед включением расписания RISH запускает диагностическую проверку:

logrotate --debug /etc/logrotate.conf

Повреждённая конфигурация теперь останавливает установку до того, как шаг будет отмечен выполненным.

Дальше программа определяет, какой механизм действительно присутствует в системе. Если доступен logrotate.timer, RISH включает его, запускает и отдельно проверяет состояния enabled и active. Если таймера нет, но существует исполняемый /etc/cron.daily/logrotate, включается crond.service, проверяются его состояния и результат run-parts --test /etc/cron.daily.

Для AlmaLinux 8 штатным оказывается второй путь. Для более новых систем обычно используется systemd timer. Если не найден ни один рабочий механизм, установка останавливается: наличие пакета logrotate без его регулярного запуска больше не считается готовой настройкой.

rclone нужен RISH для отправки резервных копий в S3, WebDAV, Яндекс Диск, Облако Mail.ru, SFTP и другие внешние хранилища. Поэтому пропустить его установку и продолжить было бы неправильно: сервер выглядел бы готовым, но одна из основных функций не работала бы.

На системах, где пакет доступен в подключённых репозиториях, RISH устанавливает его штатным пакетным менеджером DNF через совместимую команду yum. Для AlmaLinux 8 добавлен отдельный сценарий загрузки официального RPM с сайта rclone.

Загрузка не сводится к команде «скачать последний файл и установить». RISH:

1. получает version.txt и проверяет строгий формат номера версии;
2. выбирает RPM для архитектуры сервера;
3. скачивает RPM, подписанный файл SHA256SUMS и опубликованный rclone файл KEYS;
4. импортирует ключи в отдельный временный каталог GnuPG;
5. проверяет подпись SHA256SUMS и fingerprint известного ключа rclone;
6. извлекает ожидаемую SHA-256 именно для выбранного RPM;
7. вычисляет контрольную сумму скачанного файла и сравнивает значения;
8. только после успешной проверки передаёт RPM пакетному менеджеру.

Временный каталог удаляется после завершения, а сетевые загрузки и установка получают повторную попытку. Если rclone уже установлен и команда rclone version работает, RISH оставляет существующую версию как есть. Обычное обновление RISH не превращается в незапрошенное обновление rclone.

Системный пользователь в RISH связывает сразу несколько сущностей: каталоги сайтов, PHP-FPM pools, доступ к MariaDB, пользовательский CRON, SFTP-ключи и защищённый файл учётных данных. Старое меню показывало список пользователей отдельно, а создание и удаление предлагало как разные сценарии. Для получения общей картины приходилось переходить между разделами и проверять сервер вручную.

В RISH 2.9.4 создание, выбор, просмотр и удаление собраны в одном контекстном интерфейсе. В основном меню находится пункт «Создать пользователя», затем список существующих пользователей и выход. После выбора пользователя рядом открывается меню его действий: подробная информация, удаление или возврат.

Контекст Midnight Commander сохраняется. Если меню открыто внутри /var/www/<пользователь> или выбран каталог этого пользователя, соответствующая строка сразу становится активной. После просмотра сведений интерфейс возвращается к тому же месту списка, а после удаления не стирает результат операции с экрана.

Так управление пользователями перестаёт быть набором разрозненных команд. Один и тот же объект выбирается одинаково, а перед административным действием можно увидеть связанные с ним данные и состояние служебных файлов.

Экран информации начинается с имени, UID, домашнего каталога и пути данных в /var/www. Затем RISH разбирает верхний уровень /var/www/<пользователь>/www и строит таблицу содержимого.

Каталоги, обычные файлы, символические ссылки и прочие объекты показываются раздельно. Для ссылки выводится её назначение. Ширина таблицы рассчитывается по размеру терминала; длинные имена и пути переносятся внутри ячеек, а не разрушают весь экран.

Ниже собирается состояние связанных подсистем:

• MariaDB. Показываются существующие базы, к которым пользователь имеет права на уровне схемы, таблицы, столбца или процедур.
• PHP-FPM. RISH находит pools пользователя для установленных Remi PHP и проверяет, существует ли соответствующий исполняемый файл php-fpm. Необычный тип объекта или отсутствующий бинарник выводятся как проблема.
• CRON. Показывается отсутствие crontab, пустой crontab или количество активных строк без комментариев.
• SFTP-ключи. Считаются публичные ключи и проверяются ожидаемые владелец и права: root:root 644 для файла пользователя и root:root 755 для каталога. Символическая ссылка или другой неожиданный тип считаются небезопасными.
• Учётные данные. Проверяется защищённый файл /root/rish/credentials/<пользователь>. Интерфейс различает корректный, отсутствующий и повреждённый файл либо небезопасные права.

Это не замена полной диагностике rish check, а быстрый обзор конкретного пользователя перед обслуживанием или удалением.

В RISH 2.9.0 зашифрованный backup можно было назначить на публичный SSH-ключ, уже находящийся на сервере. Это удобно: публичная часть лежит в authorized_keys, а приватная обычно хранится на компьютере администратора.

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

Зашифрованный backup невозможно открыть без соответствующего приватного ключа. Поэтому перед назначением SSH-получателя RISH теперь просит предоставить приватный ключ, вычисляет из него публичную часть через ssh-keygen -y и сравнивает её с выбранным ключом. Такая проверка подтверждает, что приватный ключ доступен администратору в момент настройки и не был ранее утрачен.

Проверка выполняется при назначении основного SSH-ключа, добавлении запасного и замене существующего получателя.

1. Администратор выбирает публичный ключ из списка.
2. RISH просит целиком вставить соответствующий приватный SSH-ключ.
3. Текст принимается только как поддерживаемый блок OPENSSH PRIVATE KEY, RSA PRIVATE KEY, PRIVATE KEY или ENCRYPTED PRIVATE KEY.
4. Ключ временно записывается в каталог вида /run/rish-ssh-key-check.XXXXXX. Каталог получает права 700, а файлы создаются с umask 077.
5. Команда ssh-keygen -y вычисляет публичную часть приватного ключа. Если ключ защищён паролем, его запрашивает сам ssh-keygen.
6. Тип и данные вычисленного публичного ключа сравниваются с выбранным получателем. Комментарий в конце строки на соответствие не влияет.
7. Настройка шифрования применяется только при точном совпадении.

Временный каталог удаляется при любом завершении сценария. Он находится в /run, который в обычной конфигурации Linux размещён в tmpfs, поэтому приватный ключ не сохраняется как постоянный файл на диске.

При вставке ключ виден в терминале. Не следует выполнять эту операцию во время демонстрации экрана, записи сеанса или в присутствии посторонних. Проверка проходит локально на сервере и нужна только для подтверждения соответствия ключей.

Для шифрования age можно использовать как собственные публичные ключи формата age1…, так и публичные SSH-ключи. Раньше поле ручного ввода принимало оба формата. Поэтому SSH-ключ можно было добавить без новой проверки доступности его приватной части.

Теперь поле ручного ввода принимает только ключи age1…. SSH-ключи добавляются через отдельный сценарий: RISH просит приватный ключ, вычисляет из него публичную часть и сравнивает её с выбранным получателем.

При создании отдельного ключа age также уточнено предупреждение о пароле: независимо от того, сгенерирован он автоматически или придуман вручную, RISH его не хранит. В списке объектов теперь видно не только количество получателей, но и их тип: age, SSH или age + SSH.

Проверка не перешифровывает старые архивы и не устанавливает задним числом, сохранился ли приватный ключ для получателей, назначенных в 2.9.0. Возможность восстановления существующих копий по-прежнему нужно проверить отдельно.

Мессенджер, офисный редактор или «умная» клавиатура могут незаметно заменить обычные дефисы в строках -----BEGIN… и -----END… типографским тире. Для человека изменение почти незаметно, но приватный SSH-ключ или защищённый ключ age становится невалидным.

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

Если сайт удаляется, его строка теперь исключается из /root/rish/backup_list_all атомарно. RISH создаёт временный файл в том же каталоге, переносит в него остальные записи, копирует владельца и права исходного списка и только затем заменяет файл через mv.

Это защищает список резервного копирования от частично записанного состояния и не оставляет удалённый сайт среди активных объектов backup.

Многотомный backup в RISH использует окончание .end на последней части. Это не декоративное расширение: по нему программа понимает, что в хранилище присутствует полный набор частей.

Передача выполняется в два этапа. Сначала rclone отправляет все обычные части, исключая *.end. Только после успешного завершения первой операции загружается последняя часть с признаком окончания. Если передача оборвалась раньше, удалённый набор не выглядит завершённым.

В Облаке Mail.ru использовавшаяся операция rclone copyto для этой последней части работала несовместимо с ожидаемой структурой пути. В RISH 2.9.2 она заменена на копирование от корня временного дерева с точным фильтром --include. Порядок передачи и смысл .end при этом сохранены.

В том же изменении защищена очистка временного каталога. Перед первым rm путь DIR_BACKUP приводится к нормальной форме через realpath -m; пустое значение и корневой каталог / немедленно отклоняются. При очистке дополнительно используется проверка непустой переменной. Ошибка конфигурации больше не может превратить удаление временных частей в удаление содержимого неожиданного каталога.

mod_ssl зависит не только от конфигурации Apache, но и от версии OpenSSL, для которой он собран. Если обновить части этой связки раздельно, пакеты могут формально установиться, а Apache сообщит:

AH01882: Init: this version of mod_ssl was compiled against a newer library

RISH 2.9.3 рассматривает httpd, mod_ssl, mod_http2, openssl и openssl-libs как одну группу. При первоначальной установке программа запрашивает актуальные версии всех пакетов одной операцией. В меню обновлений они также передаются dnf вместе, чтобы пакетный менеджер разрешал общую транзакцию зависимостей.

Обычного кода возврата apachectl configtest недостаточно. RISH отдельно ищет AH01882 в выводе и считает такую комбинацию нерабочей, даже если команда завершилась без явной ошибки.

При чистой установке локальный самоподписанный сертификат создаётся до первой итоговой проверки Apache. Шаги установки пакетов и сертификата отмечаются завершёнными только после успешного configtest и отсутствия несовместимости OpenSSL.

После установки обновлений RISH предлагает выполнить полный restart Apache. Перед ним снова запускается проверка конфигурации; при ошибке restart отменяется. Затем needs-restarting -s показывает другие службы, которые продолжают использовать старые библиотеки и требуют планового перезапуска либо перезагрузки сервера. Та же проверка AH01882 добавлена в rish check.

При первоначальной установке MariaDB RISH теперь рассчитывает innodb_buffer_pool_size по объёму оперативной памяти:

Значение записывается в отдельный файл:

/etc/my.cnf.d/rish-performance.cnf

Если такой файл уже существует, RISH не перезаписывает его. Это изменение предназначено для новой установки MariaDB и не меняет автоматически настройки работающих серверов после обычного обновления RISH.

После перезапуска MariaDB программа запрашивает фактическое значение @@innodb_buffer_pool_size и сравнивает его с ожидаемым. Одновременно проверяются удаление анонимных пользователей и тестовой базы, локальность root, utf8mb4 и utf8mb4_unicode_ci.

Раньше функция проверки могла вернуть ошибку, но внешний установщик всё равно переходил к отметке выполненного шага. Теперь результат обрабатывается явно: если установка или любая обязательная проверка MariaDB не прошла, RISH останавливается и не сообщает о готовой базе данных.

RISH хранит собственные правила SSH и SFTP в /etc/ssh/sshd_config.d/00-rish.conf. Но наличие файла в этом каталоге само по себе не гарантирует его применения: основной /etc/ssh/sshd_config должен содержать подходящую директиву Include.

В 2.9.4 RISH разбирает существующие строки Include, учитывает абсолютные и относительные пути, кавычки и glob-шаблоны. Если 00-rish.conf уже покрывается одной из директив, новая строка не добавляется. Если каталог не подключён, в начало временной версии конфигурации записывается:

Include /etc/ssh/sshd_config.d/*.conf

Дальше сохраняется прежняя безопасная схема: резервная копия, проверка конфигурации SSH, проверка фактически действующих параметров и откат при ошибке. Таким образом, RISH подтверждает не только наличие своего drop-in, но и его участие в итоговой конфигурации.

При создании пользователя адрес администратора будущих сайтов теперь проверяется до сохранения. Поле можно оставить пустым, но непустое значение должно иметь допустимые длину, локальную часть и структуру домена. Проверяются границы DNS labels, дефисы и домен верхнего уровня; поддерживаются Punycode TLD. При ошибке RISH повторяет запрос, а не продолжает создание с заведомо некорректным адресом.

Путь PHP-FPM slowlog в создаваемом pool приведён к общей структуре логов пользователя: /var/www/<пользователь>/logs/php-slow-log. Параметр остаётся закомментированным до явного включения slowlog, а отдельный неиспользуемый каталог slowlog при создании пользователя больше не создаётся.

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

В окне подтверждения сохранения SSH-ключа отключён режим управления мышью в меню. Благодаря этому колесо мыши прокручивает историю терминала и позволяет вернуться к ранее показанному ключу.

В меню DNS длинное имя записи теперь сокращается с начала, сохраняя значимый правый суффикс. Имена выравниваются по правому краю, поэтому одинаковые доменные окончания легче сравнивать в списке.

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

Не все изменения должны переписывать уже работающий сервер. RISH разделяет миграции существующей установки и новые правила первоначальной настройки.

• Новое меню пользователей, проверки ключей backup, совместимость с Облаком Mail.ru, обновление Apache/OpenSSL, проверка SSH Include и интерфейсные исправления доступны после обновления RISH.
• Если rclone отсутствует или не запускается, postupdate.sh повторяет шаг установки; на AlmaLinux 8 используется проверенный официальный RPM. Уже работающий rclone автоматически не обновляется.
• Новый расчёт InnoDB buffer pool выполняется при первоначальной установке MariaDB. Конфигурация существующей базы не изменяется.
• Исправленные проверки swap и механизма запуска logrotate относятся прежде всего к чистой установке сервера. Они не являются скрытой перенастройкой уже работающей системы.
• Назначенные ранее SSH-ключи backup и старые зашифрованные архивы не перепроверяются и не перешифровываются автоматически.

Такой подход не подменяет настройки администратора новыми значениями без запроса и одновременно делает чистую установку воспроизводимой.

После обновления до RISH 2.9.4 снова откройте пункт «Обновление/проверка RISH» и выберите «Проверка обновлений Apache».

На существующем сервере могут быть доступны обновления httpd, mod_ssl, mod_http2, openssl и openssl-libs. RISH проверит всю связку и при наличии обновлений установит пакеты одной транзакцией.

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

RISH 2.9.4 возвращает рабочую установку на AlmaLinux 8 и одновременно делает повседневное администрирование понятнее. Управление пользователями приведено к единому стандарту: один список, контекстные действия и подробное состояние связанных каталогов, баз, PHP-FPM pools, CRON, SFTP-ключей и учётных данных.

Вокруг этого интерфейсного изменения выстроена более важная техническая работа. RISH проверяет доступ к соответствующему приватному SSH-ключу до назначения шифрования, проверяет происхождение RPM rclone, фактический размер InnoDB buffer pool, постоянную настройку swap, реальный механизм запуска logrotate, подключение SSH drop-ins и совместимость Apache с OpenSSL.

Ни одна из этих проверок не выглядит большой функцией сама по себе. Но именно из них складывается надёжность сервера: установка должна либо закончиться рабочей системой, либо остановиться в точке, где результат ещё нельзя подтвердить.

После обновления RISH запустите проверку обновлений Apache. Других специальных действий для перехода на 2.9.4 не требуется.