НАЙС.ОС: ответы
на частые вопросы.

Операционная система управляет ресурсами сервера: процессами, памятью, дисками, сетью и доступом пользователей. Прикладные программы решают задачи организации: обрабатывают документы, предоставляют веб-интерфейс, хранят данные. При выборе платформы проверяют оба уровня. Совместимость Linux-приложения определяется его зависимостями и конфигурацией, а не только названием операционной системы.

НАЙС.ОС собирается из исходных кодов открытых проектов с собственной сборочной цепочкой, RPM spec-файлами, патчами и настройками. Готовый бинарный репозиторий другой ОС не используется в качестве базы. При этом ядро Linux и многие системные программы являются общими открытыми проектами, используемыми в разных дистрибутивах.

Начните с приложения. Если нужны серверные службы с установкой и настройкой на уровне ОС, рассматривайте CLOUD. Если разработчик поставляет приложение как набор контейнеров с Compose-файлом, рассматривайте Контейнерный хост. Затем проверьте ресурсы, сеть, хранение данных, возможность перезагрузки и совместимость на стенде.

На этом сайте представлены серверные редакции CLOUD и Контейнерный хост. Их назначение — работа серверных приложений и инфраструктуры. Пользовательская рабочая станция с офисной средой и графическим рабочим столом не входит в представленную линейку. Планирование рабочих мест требует отдельного выбора системы и проверки периферии.

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

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

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

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

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

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

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

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

Инструменты автоматизации, включая анализ кода с помощью ИИ, могут использоваться при поиске ошибок и подготовке изменений. Для эксплуатации практическое значение имеет процесс: получать сведения об уязвимостях, определять затронутые компоненты и устанавливать проверенные исправления. Регулярный выпуск ОС помогает организовать этот процесс, но не заменяет защиту приложений.

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

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

Перейдите на страницу «О проекте и НАЙС.ОС CLOUD» и откройте раздел загрузки. Там размещены ссылка на опубликованный ISO НАЙС.ОС 5.2 minimal для x86_64 и его контрольная сумма SHA256. Перед установкой изучите лицензию и документацию и проверьте целостность скачанного файла.

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

Условия доступа к исходному коду определяются лицензиями соответствующих компонентов. В НАЙС.ОС используются открытые проекты; исходные тексты и изменения к ним предоставляются в требуемом их лицензиями объёме. По вопросам конкретного пакета укажите его имя, версию и ревизию в обращении к разработчику.

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

Право использования ОС и техническое сопровождение — разные условия. Объём консультаций, сроки реакции и дополнительные работы определяются выбранным форматом сотрудничества и договором. Для обсуждения поддержки сообщите количество узлов, редакцию, назначение серверов, требуемый режим доступности и критичные приложения.

Документация перенесена на docs.niceos.ru. На основном сайте размещены описание продукта, сравнение редакций, ответы на вопросы и ссылки на получение системы. Порядок установки и команды администрирования следует смотреть на сайте документации с учётом конкретной версии ОС.

Используйте портал поддержки для обращений по эксплуатации. Для обсуждения внедрения, получения образа и сотрудничества доступны контакты разработчика. Укажите версию системы, параметры среды, ожидаемое и фактическое поведение. Если отправляете журналы, заранее удалите из них пароли, токены и персональные данные.