Скачать НАЙС.ОС 5.2 minimal

В НАЙС.ОС используется большое количество компонентов под лицензиями GPL, LGPL, MIT, BSD, Apache и др. Для них действуют именно эти лицензии — никакие дополнительные ограничения EULA на них не распространяются.

Кратко политика:

• исходный код таких компонентов берётся из официальных репозиториев проектов upstream;
• изменения (патчи) к GPL-компонентам не скрываются и предоставляются пользователям в составе исходников или SRPM;
• по запросу пользователя мы предоставляем исходные тексты и/или SRPM для соответствующих пакетов в объёме, требуемом их лицензиями;
• для связи по вопросам лицензирования и исходных кодов можно написать на support@niceos.ru.

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

В базовой установке НАЙС.ОС нет компонентов, которые сами по себе отправляют данные разработчику или третьим лицам без явной настройки администратора.

Сетевую активность инициируют:

• службы, которые вы сами включили и сконфигурировали (SSH, VPN, веб-сервисы и т.д.);
• пакетный менеджер dnf при обращении к официальным репозиториям и зеркалам, которые вы указали.

Как и в любом Linux-дистрибутиве, полный контроль за конфигурацией и сетевой политикой остаётся за администратором: можно ограничить выход наружу через firewall, прокси, локальные зеркала, IDS/IPS и др.

В НАЙС.ОС в пакет ca-certificates может быть включён дополнительный набор корневых/подчинённых сертификатов (в том числе Russian Trusted Root CA / Russian Trusted Sub CA) для совместимости с рядом российских сервисов и корпоративных PKI-цепочек.

Важно:

• сертификаты в trust-store сами по себе не создают сетевой трафик и «никуда не подключаются»;
• они влияют только на решение клиента (TLS-библиотеки/браузера) — доверять или не доверять сертификату удалённой стороны при установлении TLS-соединения.

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

• удалить/отключить соответствующие сертификаты в локальном хранилище и пересобрать bundle;
• использовать собственный корпоративный trust-store (рекомендуемый подход для закрытых/air-gapped контуров);
• поднять локальные зеркала/прокси и зафиксировать доверенные цепочки на уровне инфраструктуры.

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

rm -f /etc/pki/anchors/*.p11-kit
/usr/sbin/make-ca -g --force
update-ca-trust

Под «минимализмом» мы понимаем минимальность установленной системы и её роли, а не рекорды по размеру ISO.

В ISO входят:

• установщик, базовые утилиты и драйверы для типовых гипервизоров и железа;
• инструменты диагностики, сетевые утилиты, средства разметки и восстановления;
• документация, необходимая для установки в офлайн-сценариях.

После установки базовая система остаётся компактной и предназначенной в первую очередь для виртуальных машин и серверных ролей. Для автоматизированных сценариев также используются более лёгкие образы (rootfs, cloud-образы, контейнеры), которые меньше ISO и распространяются отдельно.

Рекомендованный сценарий НАЙС.ОС для серверов и облака — минимальный хост + прикладное ПО в контейнерах. Это уменьшает влияние изменений на базовый слой и упрощает переносимость.

При этом контейнеры — не «религия», а практичный паттерн. В системе остаются RPM и пакетный менеджер, потому что есть классы задач, где установка на хост оправдана (агенты, сетевые утилиты, диагностика, базовые сервисы).

Как это выглядит по режимам:

• RPM (mutable): ставите пакеты на хост через dnf как в обычной серверной ОС.
• OSTree (atomic): системный слой обновляется атомарно; прикладное обычно выносится в контейнеры, а дополнительные компоненты подключаются осознанно, чтобы не размывать предсказуемость базового слоя.

---

Коротко: хост — максимально простой и управляемый, всё сложное и часто меняющееся — поверх (контейнеры/образы/оркестрация).

Вопрос про совместимость справедлив: часть корпоративного и legacy-ПО действительно привязана к конкретному userspace (версии glibc, библиотек, рантаймов, драйверов).

В НАЙС.ОС принята практическая модель эксплуатации:

• хост — минимальная управляемая база для инфраструктуры;
• прикладное ПО — в контейнерах/образах/ВМ с тем userspace, под который оно рассчитано.

Это означает, что для приложений с жёсткими требованиями к библиотекам вы используете:

• контейнер с нужным окружением (например, образ под RHEL/Alt/Rosa/Debian/Ubuntu-совместимый userspace);
• или отдельную ВМ/образ, если это требует политика ИБ или вендор.

Почему так лучше:

• совместимость прикладного ПО не «прибита» к версии базового слоя хоста;
• обновления хоста меньше влияют на приложения;
• проще аудит и сопровождение: состав приложения фиксирован внутри образа.

---

Если ваш сценарий предполагает установку вендор-ПО непосредственно на хост (без контейнеров), рекомендуем начать с пилота и проверки в тестовом контуре. Для таких кейсов обычно выбирают соответствующий режим эксплуатации и набор пакетов, согласованный под ваш стек.

НАЙС.ОС развивается как серверная/облачная платформа, а не универсальная «настольная система для всех». На данный момент приоритет —:

• виртуальные машины в дата-центрах и облаках;
• VPN-шлюзы, защищённые контуры, телеком-узлы;
• контейнерные платформы и сервисы наблюдаемости.

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

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

Что означает LTS в контексте НАЙС.ОС:

• фиксированные релизы и жизненный цикл сопровождения для ветки;
• обновления безопасности и исправления критичных дефектов в рамках ветки;
• предсказуемые обновления без «прыжков» между несогласованными версиями.

Как снижаются риски при обновлениях:

• обновления проходят проверку целостности (подписи/контрольные суммы);
• в режиме OSTree системный слой обновляется атомарно (deployments), доступен rollback одной перезагрузкой;
• для production-сценариев рекомендуется разделение контуров (пилот/стейджинг/прод) и плановое окно обновлений.

Почему это не «ломает совместимость» прикладного ПО:
для приложений с жёсткими требованиями к userspace (версии библиотек и рантаймов) рекомендуется контейнерная модель или изолированные образы/ВМ с нужным окружением. Тогда обновления базового слоя хоста не привязаны к жизненному циклу конкретного приложения.

Практическая рекомендация внедрения:

• начать с тестового контура и пилота;
• зафиксировать модель эксплуатации (RPM или OSTree);
• определить, что ставится на хост, а что выносится в контейнеры;
• включить регламент обновлений и откатов.

---

Идея «чем старее версии, тем стабильнее» появилась не из воздуха — это исторически успешная стратегия крупных дистрибутивов, прежде всего в enterprise-сегменте. Но это не физический закон, а компромиссная политика, которая работает не для всех сценариев.

Почему консервативные версии часто воспринимаются как “стабильные”:

• дольше обкатаны в массовой эксплуатации;
• вендор годами делает backport (перенос исправлений безопасности и багфиксов без смены основной версии);
• есть привычная база сертификаций и вендор-совместимости для “ПО на хосте”.

Но у «старого стека» есть обратная сторона:

• исправления и функциональность приходят через backport и могут вести к “сюрпризам” в патч-сетах;
• иногда сложнее поддерживать современное железо, виртуализацию и контейнерные сценарии без дополнительных слоёв;
• часть современных практик (изоляция, безопасность, supply chain, runtime-ограничения) развивается быстрее, чем “замороженные” базовые компоненты.

Подход НАЙС.ОС: мы проектируем систему как минимальную управляемую платформу, где:

• хост — это предсказуемый фундамент (ядро, системные сервисы, крипто-стек, обновления);
• прикладное ПО — в контейнерах/образах/ВМ с нужным userspace (особенно для legacy и вендор-софта);
• модель обновлений фиксируется выбором режима: RPM (mutable) или OSTree (atomic) с rollback.

Итог: “стабильность” — это не возраст версий, а управляемость изменений:

• есть ли регламент релизов и обновлений;
• можно ли безопасно обновляться и откатываться;
• насколько изолировано прикладное ПО от обновлений базового слоя;
• насколько прозрачен состав системы для аудита.

---

НАЙС.ОС изначально проектируется с учётом требований безопасности и практик безопасной разработки. В том числе:

• подписи пакетов и контроль цепочки поставки;
• поддержка ГОСТ-криптографии и российских УЦ;
• отделение системного слоя от данных и прикладного ПО.

Формальные процедуры сертификации — отдельный долгий процесс. При появлении официальных статусов (ФСТЭК, иные регуляторы) информация будет опубликована в документации и новостях проекта.

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

RPM (mutable) — классическая модель Linux:

• управление пакетами через dnf;
• подходит для сценариев, где требуется установка пакетов на хост и привычное администрирование;
• обновления применяются на уровне пакетов.

OSTree (atomic) — атомарная модель обновлений:

• системный слой обновляется как целостный deployment;
• новая версия активируется при перезагрузке;
• доступен rollback к предыдущему состоянию одной перезагрузкой;
• конфигурация и данные отделены от системного слоя (типично /etc и /var).

Быстрые команды (OSTree-режим): Рекомендация: для облаков/ВМ и инфраструктурных узлов обычно выбирают OSTree, чтобы упростить обновления и откаты. Для «классических» серверов, где много пакетов ставится прямо на хост — RPM-режим.

Варианты связи:

• форма обратной связи на сайте: https://niceos.ru/contact-niceos;
• электронная почта: support@niceos.ru;
• для корпоративных клиентов — каналы поддержки и SLA по индивидуальным договорам.

Неточности в пакетах, spec-файлах, документации и инсталляторе приветствуются как баг-репорты.

ГОСТ реализован на базе опубликованных и проверяемых проектов с открытым исходным кодом:

• OpenSSL с ГОСТ-провайдером. OpenSSL собран с поддержкой ГОСТ через отдельный модуль (engine/provider) из проекта gost-engine/engine. Это стандартный подход, который используется в ряде дистрибутивов и внешних проектов.
• GnuPG + libgcrypt. Поддержка ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 реализована через патчи и настройки к GnuPG и libgcrypt на базе открытых реализаций, совместимых со стандартами ТК-26 и соответствующими RFC.
• libksba и X.509. Библиотека libksba собрана с поддержкой ГОСТ-алгоритмов для работы с сертификатами и CMS-структурами.
• OpenVPN. OpenVPN использует OpenSSL с ГОСТ-провайдером.

Вся криптография, связанная с ГОСТ, собирается из открытых исходников.

Для компонентов, распространяемых на условиях GPL, LGPL и других свободных лицензий, НАЙС.ОС предоставляет исходные тексты и SRPM по запросу. Механизм такой:

1. Вы регистрируетесь на сайте (или отправляете со своего почтового ящика email с запросом) и подтверждаете адрес электронной почты.
2. В заявке указываете интересующие пакеты (имя и версию).
3. Получаете ссылку на соответствующие SRPM и/или архивы исходников.

Регистрация нужна по нескольким причинам:

• отсеять автоматические сканеры и ботов;
• учитывать юридические формальности;
• отделять открытые компоненты (GPL/LGPL/MIT/Apache и т.п.) от собственных частей продукта.

Для базовых компонентов (ядро, glibc, gcc, базовая система) исходные коды и SRPM доступны публично. Для остального — предоставляем по запросу. Они содержат исходный код и сценарии сборки (spec-файлы), которыми мы пользуемся в пайплайне НАЙС.ОС.

В НАЙС.ОС используется несколько LTS-линий ядра Linux, в зависимости от профиля установки и требований проекта:

• Linux 6.6.x LTS с kernel.org — основная, «ванильная» ветка для большинства сценариев. Ядро собирается из официального исходного кода kernel.org с минимальным набором собственных патчей (интеграция с дистрибутивом, безопасность, исправления, необходимые именно для НАЙС.ОС).
• Linux 6.12.x LTS по рекомендациям Linux Verification Center — вариант для инсталляций, где важна привязка к веткам, сопровождаемым Linux Verification Center (LVC).

Что такое portal.linuxtesting.ru?
Это портал Linux Verification Center — центра, который:

• выбирает и сопровождает LTS-ветки ядра (например 5.10, 6.1, 6.12) для долгосрочного использования;
• проводит регрессионное тестирование и публикует результаты проверок;
• готовит рекомендации для российских вендоров и проектов, которые идут в сторону сертификации и формальных требований.

Важно понимать, что LVC не «пишет своё ядро с нуля» — база та же, что и у официального LTS-ядра 6.12 с kernel.org, но с дополнительным циклом тестирования, исправлений и методик сопровождения для критичных и регуляторно-значимых систем.

Почему одновременно 6.6.x и 6.12.x?

• 6.6.x LTS с kernel.org — универсальная и широко поддерживаемая ветка для обычных серверов, виртуализации и контейнерных сценариев.
• 6.12.x LTS (по линии LVC) — выбор для инфраструктур, где заказчик или регулятор ориентируется на ветки и методики, рекомендованные Linux Verification Center.

Конкретная линия ядра указывается в документации к релизу и видна в системе через uname -r. В обоих вариантах ядро получает актуальные обновления и патчи безопасности в течение всего срока LTS-поддержки.

Talos Linux — это специализированная ОС для Kubernetes-нод с максимально жёсткой моделью управления: минимальный состав, отсутствие “классического” SSH-администрирования и управление через API. Это отличный инструмент, когда задача — только Kubernetes.

НАЙС.ОС решает более широкий инфраструктурный класс задач:

• виртуальные машины и облака (включая edge и закрытые контуры);
• сетевые роли, VPN, шлюзы, наблюдаемость, ИБ-инструменты;
• Kubernetes — как один из основных сценариев, но не единственный.

Ключевое отличие модели эксплуатации:

• в НАЙС.ОС доступно два режима: RPM (mutable) и OSTree (atomic) с rollback;
• есть возможность выбирать баланс между “жёсткой” платформой и классическим администрированием;
• акцент сделан на российский контекст: ГОСТ-криптография, практики работы с PKI и инфраструктурой организаций.

Когда обычно выбирают Talos: строго Kubernetes-only, управление через API, узкий профиль ноды.
Когда обычно выбирают НАЙС.ОС: инфраструктурная база под ВМ/облако/edge, где нужны управляемые обновления, возможность пилота, интеграции с ИБ и разнообразие серверных ролей.

RHEL-подобная экосистема популярна в enterprise не случайно: она предсказуема, хорошо документирована и удобна для автоматизации. НАЙС.ОС не “воюет” с этой моделью — мы используем её сильные стороны (RPM, привычные инструменты сопровождения), но делаем акцент на другие принципы эксплуатации и требования рынка.

Что добавляет НАЙС.ОС поверх “обычного enterprise Linux”:

• два режима эксплуатации: классический RPM и атомарный OSTree (deployments + rollback);
• контейнерный паттерн как базовая модель для прикладного ПО (совместимость userspace фиксируется в образе);
• ГОСТ-криптография как часть системного стека и документации, а не как набор разрозненных инструкций;
• минимальная база под ВМ/облако/edge, чтобы уменьшить поверхность атаки и упростить сопровождение.

Важно про “совместимость и версии”:
в традиционных enterprise-дистрибутивах часто делают ставку на максимально консервативный userspace “на хосте”. В НАЙС.ОС другой подход: хост — управляемая база, а прикладное ПО, требующее конкретных версий библиотек, рекомендуется запускать в контейнерах/образах/ВМ с нужным окружением. Это уменьшает зависимость приложений от обновлений хоста.

Когда НАЙС.ОС особенно уместна:

• нужен минимальный серверный фундамент под облака/ВМ/edge;
• нужны контролируемые обновления и быстрый откат (OSTree-режим);
• важны ГОСТ-сценарии и работа с российской PKI в реальных контурах;
• прикладное ПО планируется эксплуатировать контейнерно или изолированно.