Группа процессов, запущенных под управлением одного пользователя в Astra Linux

Обновлено: 02.07.2024

После нескольких лет итераций и улучшений развертывание кластера DataStax Enterprise (DSE) стало довольно безболезненным процессом. Загрузите tarball, запустите скрипт установки, и все готово.

Ой, подождите, сначала вы должны подготовить несколько серверов для запуска. Тогда было бы хорошо убедиться, что серверы могут общаться друг с другом через правильные порты. Конечно, также гарантируется, что ваши внешние клиенты могут получить доступ к определенным портам, но не смогут получить доступ к другим. И мониторинг, это тоже важно. Поскольку мы собираем метрики для мониторинга, было бы неплохо иметь возможность безопасно их просматривать. Возможно, развертывание одного кластера DSE немного сложнее.

Теперь представьте, что вы делаете это тысячи раз надежным способом и одним нажатием кнопки. Поскольку мы создавали базу данных DataStax Astra DB поверх DSE, это то, что нам нужно было сделать. Чтобы реализовать эту и другие функции Astra, мы создали панель управления Astra.

Включение разработчиков

Развертывание базы данных может быть одной из самых важных функций Control Plane, хотя это лишь малая часть того, что требуется для запуска Astra DB. Есть множество других вспомогательных услуг и работ, необходимых для успеха, включая наш веб-интерфейс, процесс выставления счетов и управление пользователями. Каждая из этих областей может быть далее разбита на другие более мелкие службы, каждая из которых разрабатывается и поддерживается несколькими командами. Однако у них есть одна общая черта — уровень управления.

Когда мы его создавали, одной из наших основных целей было самообслуживание. Мы хотели предоставить различным командам, поддерживающим Astra, возможность переводить свой код из функциональной ветки в производство максимально автоматизированным способом. Это также удовлетворит наши собственные потребности в поддержке нескольких микросервисов, которые нам понадобятся для развертывания баз данных. Нашей целью было предоставить слой поверх таких инструментов, как Kubernetes и Helm, с которым разработчики могли бы добиться успеха, несмотря на неравномерное знакомство с этими инструментами и операциями в целом. Главной задачей наших разработчиков было написать код и предоставить функции для поддержки наших пользователей; им было все равно, как это было выпущено, да и не должно было быть.

Когда мы искали что-то, что соответствовало бы нашим потребностям (в начале 2018 г.), мы обнаружили, что большинство инструментов были либо слишком дорогими, либо требовали слишком большого опыта работы и, следовательно, были слишком сложными. Поэтому мы создали систему, известную как DSCloud, чтобы абстрагироваться от тонкостей непрерывной интеграции и непрерывной доставки (CI/CD).

В основе нашей системы сборки лежит файл dscloud.yaml. Этот файл находится в корне каждого репозитория git и определяет, как репозиторий должен быть развернут. Поскольку каждая команда отвечает за собственное монорепозиторий, состоящее из независимых файлов Dockerfile в каждом подкаталоге, DSCloud использует организационную структуру App, Microservice, Jobs и Cronjobs.

Приложение: сопоставляется один к одному с репозиторием git и развертывается в Kubernetes как пространство имен, содержащее ноль или более развертываний, заданий и заданий cron.
Microservice: подкаталог в монорепозитории, который должен быть развертыванием Kubernetes (или StatefulSet) с соответствующим входом через частный или общедоступный сервис.
Задание: подкаталог в монорепозитории, который должен быть заданием Kubernetes. Это задание гарантированно выполняется ровно один раз при каждой отправке кода.
Cronjob: подкаталог в монорепозитории, который следует развернуть как задание хрона Kubernetes.

Каждый из компонентов, составляющих приложение, микросервис, задания и задания Cron, имеет дополнительные параметры конфигурации, которые можно использовать для определения способа их развертывания. Общими для всех трех являются environmentConfiguration и secretValues. Конфигурация среды содержит список сред (например, dev, test, prod) и для каждой переменной среды со значениями, которые должны быть установлены в модулях. secretValues — это список ключей, которые используются для привязки секретов Kubernetes во время развертывания.

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

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

Наконец, компонент IntegrationTests используется для определения того, в каких средах должны выполняться интеграционные тесты и какие переменные среды им необходимы.

Эти тесты основаны на именовании подкаталогов. Dockerfile в этом каталоге будет использоваться для запуска задания, содержащего любые определенные вами тесты. Инструмент развертывания откатится или продолжит работу в зависимости от кода завершения теста.

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

Для тех, у кого есть опыт работы с Kubernetes, большая часть dscloud.yaml должна показаться знакомой; это по дизайну. При создании этой системы сборки мы старались предоставить достаточно опций, которые будут полезны нашим опытным пользователям, и в то же время абстрагироваться от сложностей для тех, у кого нет такого опыта.

Теперь определение манифеста развертывания — это хорошо, но в какой-то момент нам нужно получить код из git и запустить его в производство, и именно здесь в игру вступает наш сервис Processor. Служба Processor выступает в качестве оркестратора нашего процесса CI/CD посредством:

Постоянно опрашиваем git на наличие изменений в любом из наших репозиториев.
Запуск инструмента сборки при обнаружении новой фиксации, который создаст и опубликует образ Docker в нашем репозитории в случае успеха.
Создание новой диаграммы Helm на основе файла dscloud.yaml.
Запуск инструмента развертывания для развертывания приложения в каждой среде.

После того как мы смогли создать, протестировать и развернуть наш код, пришло время приступить к созданию Astra.

Первые шаги: облачный

В 2018 году, когда мы приступили к развертыванию DSE одним нажатием кнопки, операторы Kubernetes только начинали набирать популярность, а операторы, специфичные для Apache Cassandra®, находились в стадии предварительной альфа-версии. Поэтому мы решили придерживаться того, что знали, а именно виртуальных машин в облаке.

В базовом случае нам нужен кластер DSE с тремя узлами и небольшой кластер Kubernetes для запуска вспомогательных служб для базы данных. Из-за знакомства с платформой наш первый набег на все был на AWS. Мы приступили к созданию сценариев Terraform для предоставления экземпляров EC2, томов EBS и соответствующей сети. Это должна была быть автоматизированная система, работающая по нажатию кнопки, поэтому мы разработали сервис Golang для вызова Terraform из запроса REST, который также выполнял достаточное количество шаблонов для поддержки различных размеров баз данных и регионов.

Поскольку подготовка инфраструктуры занимает некоторое время, мы, очевидно, не могли заставить наших клиентов ждать, пока мы закончим, поэтому этот процесс должен был быть асинхронным. Для этого мы выбрали Argo в качестве механизма рабочего процесса, что позволило нам разбить подготовку инфраструктуры на несколько этапов, которые при правильном выполнении можно было бы легко повторить в случае сбоя. К этому моменту мы автоматизировали подготовку инфраструктуры, хотя это было не очень интересно, поскольку еще ничего не было развернуто.

После завершения Terraform мы смогли запустить еще один рабочий процесс для приведения базы данных в пригодное для использования состояние. Чтобы ускорить процесс, мы использовали пользовательские образы машин для создания инстансов EC2, которые содержали архив DSE и необходимые сценарии запуска.

При запуске узлов DSE важен порядок: если бы вы делали это вручную, вы бы запустили первый узел, подождали, пока он не заработает, установили начальное значение на втором IP-адресе первого, запустили второй узел и скоро. Поскольку наши узлы запускались в случайном порядке, мы не могли гарантировать такое поведение. Это означало, что нам пришлось создавать собственный механизм блокировки и координации для узлов по мере их запуска. Поскольку первоначальный запуск DSE выполнялся с помощью образа машины, наш рабочий процесс мог затем перейти к окончательной настройке и настройке, а также к развертыванию служб в небольшом кластере Kubernetes.

Некоторое время этот процесс работал у нас хорошо, но вскоре у нас начались проблемы. С самого начала мы заметили, что создание новой базы данных занимает до часа, что имеет смысл, учитывая, что мы выделяем шесть инстансов EC2 (около 45 минут) вместе с другой необходимой инфраструктурой. Еще одна проблема, с которой мы столкнулись, — это повторяемость. Этот метод создания баз данных оказался не очень надежным, поскольку мы использовали очень много элементов инфраструктуры, и нашим сценариям приходилось обрабатывать все. Например, если том EBS не был правильно подключен, наши скрипты должны были обнаружить это, а затем решить проблему самостоятельно. Это стало еще сложнее, когда мы представили новые рабочие процессы для добавления дополнительных узлов в базу данных.

После бета-тестирования мы обнаружили, что тратим слишком много времени на ручные исправления, и, наконец, поняли, что стоимость этой архитектуры несостоятельна. К счастью, к этому моменту наш собственный оператор Kubernetes, cass-operator, добился достаточного прогресса, чтобы его можно было развернуть для использования в рабочей среде.

DataStax — это открытый мультиоблачный стек для современных приложений для работы с данными. DataStax предоставляет предприятиям свободу выбора, простоту и подлинную облачную экономику для развертывания больших объемов данных, доставляемых через API, обеспечивая эффективное взаимодействие в мультиоблачных средах, с открытым исходным кодом и Kubernetes.

Все в Kubernetes!

С появлением оператора cass мы смогли переосмыслить нашу модель развертывания и перейти к архитектуре, ориентированной на Kubernetes.

Это означало, что вместо развертывания отдельных вычислительных экземпляров для каждого облачного провайдера (например, AWS или GCP) мы могли начать подготовку единого управляемого кластера Kubernetes, такого как EKS или GKE, для каждой новой базы данных. Преимущества этого были тройными:

Упрощение. Это значительно упростило процесс подготовки инфраструктуры, поскольку нам больше не нужно было выделять отдельные компоненты инфраструктуры.
Сокращение затрат на техническое обслуживание. Нам удалось снизить нагрузку на техническое обслуживание, поскольку мы могли рассчитывать на то, что оператор выполнит установку и проверку нового кластера DSE вместе со всеми вспомогательными услугами.
Меньше затрат. Расходы нашего поставщика облачных услуг сократились, поскольку нам больше не нужно было выделять выделенное оборудование для DSE, а затем и для кластера Kubernetes. Чем меньше вычислительных экземпляров, тем ниже затраты.

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

Мы достигли этого, перейдя на модель "пространство имен для каждой базы данных". Благодаря этой новой архитектуре инфраструктуру можно было подготовить заранее, потому что нам больше не нужно было создавать новый кластер Kubernetes для каждой базы данных, что сократило процесс создания базы данных до одного рабочего процесса. Теперь, всякий раз, когда мы хотели создать новую базу данных, все, что нам нужно было сделать, это запустить один рабочий процесс, который запускал Helm, дождаться оператора, а затем выполнить окончательную настройку. Кроме того, с помощью этой новой модели мы смогли воспользоваться преимуществами упаковки контейнеров — алгоритма, с помощью которого Kubernetes максимизирует использование ресурсов вычислительного экземпляра, планируя оптимальное количество модулей разного размера, что позволяет нам более эффективно использовать наши вычислительные ресурсы. ресурсы.

Заключение

Чтобы поддержать нашу цель по созданию базы данных как услуги поверх DataStax Enterprise, мы создали Astra Control Plane. Чтобы облегчить это и поддержать множество различных команд, участвующих в этом проекте, потребовалось создание специального инструмента CI/CD, который мы называем DSCloud.

Благодаря DSCloud наши команды разработчиков могут быстро и эффективно поставлять код для поддержки наших пользователей, не увязая в тонкостях облачного развертывания. Затем мы использовали этот же инструмент, чтобы запустить наши собственные усилия по созданию быстрого развертывания кластеров DSE в облаке.

В ходе работы мы не всегда делали все правильно с первого раза, но мы продолжали итерации и улучшения, как и сегодня. Более того, наш Control Plane оказался гибким по мере того, как Astra росла и менялась. Он может обрабатывать растущий объем трафика, а также вносить попутные изменения в плоскость данных, включая существенную перестройку архитектуры, необходимую для Astra DB Serverless. Благодаря исключительной работе сообщества Kubernetes мы смогли намного лучше масштабировать и упростить наши процессы, предоставив нам гораздо больше возможностей для создания функций для наших пользователей.

The New Stack является дочерней компанией Insight Partners, которая является инвестором следующих компаний, упомянутых в этой статье: Docker.

Группа компаний «Астра Линукс», разработчик и производитель серверного и телекоммуникационного оборудования, систем хранения данных и вычислительных платформ ЗАО «НОРСИ-ТРАНС», и компания «Десима», специализирующаяся на высокотехнологичной электронике, объявляют о выпуске импортонезависимого программного и аппаратного комплекса (АПК) КОТМИ-14″ и его успешной сертификации по программе технологического сотрудничества ИТ-вендоров Ready for Astra Linux. В результате трехсторонних испытаний, проведенных экспертами, было установлено, что все компоненты совместного решения работают корректно, а их функционал доступен пользователям в полном объеме. Об этом CNews сообщили представители Astra Linux.

ПАК «КОТМИ-14» предназначен для создания различных оперативно-диспетчерских информационно-управляющих систем: как автономных локальных, так и централизованных, когда автоматизируется работа сразу нескольких связанных центров, создается единое информационное пространство и обеспечивается резервирование. при условии.ПАК собирает информацию из множества источников по разным протоколам, реализует функции телеуправления, обрабатывает данные, архивирует их и предоставляет пользователям. Использование «КОТМИ-14» позволяет выполнять ряд расчетно-аналитических задач как в режиме онлайн, так и в автономном режиме, а на его базе можно строить автоматизированные системы управления технологическими процессами, а также сбора и передачи информации с подстанций, оперативного технологического контроля и системы управления в ситуационных центрах, дата-центрах и центрах управления. Кроме того, КОТМИ-14 может использоваться как платформа, на которой в единую систему интегрировано несколько специализированных комплексов прикладного программного обеспечения от разных разработчиков.

Основой программно-аппаратного стека является единая база оборудования с топологическими связями, а также базы измерений и потребителей. Комплекс полностью состоит из отечественных комплектующих: серверов линейки «Яхонт-УВМ» на платформе «Эльбрус-8С» под управлением ОС Astra Linux Special Edition и другого российского ПО. Обновление Astra Linux Special Edition 8.1 разработано специально для процессорной архитектуры «Эльбрус» и успешно прошло сертификацию по требованиям защиты информации ФСТЭК России для операционных систем типа А 2-го класса защиты и требованиям защиты информации ФСБ России по средствам защиты информации.

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

«Благодаря совместным усилиям получен импортонезависимый программно-аппаратный комплекс, состоящий на 100% из отечественных программно-технических средств. Набор функциональных возможностей решения и его качество не уступают зарубежным аналогам. Использование ПАК позволит российским энергетическим компаниям обеспечить корректную и непрерывную работу своих ключевых систем», — отметил Артем Минаков, начальник отдела информационной безопасности «Норси-транс».

«Astra Linux Group делает ставку на сотрудничество с другими производителями ИТ: конструктивное взаимодействие и объединение ресурсов помогают всем нам производить продукты, отвечающие текущим потребностям пользователей. Мы очень ценим активное участие коллег из компаний «Норси-транс» и «Децима» в тестировании корректной работы нашей ОС в связке с другими компонентами ПАК КОТМИ-14. Благодаря тому, что тесты программно-аппаратного стека проводились экспертами всех трех вендоров, мы можем быть полностью уверены в его работоспособности и надежности», — сказал Антон Рудевский, директор департамента по работе с партнерами Astra Linux Group. /p>

О группе компаний Astra Linux

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

Astra Linux Group — участник российского рынка информационных технологий в области разработки программного обеспечения, в том числе операционной системы Astra Linux и платформ виртуализации. На рынке с 2008 года. Все продукты Astra Linux включены в реестр Минцифры России. Операционная система Astra Linux принята в качестве стандарта для федеральных органов исполнительной власти и государственных корпораций. Единственный в стране, имеющий полный комплект сертификатов Минобороны России, ФСТЭК и ФСБ России. Рекомендуется для использования в специализированных программно-аппаратных комплексах, предназначенных для обработки сведений любой степени конфиденциальности, в том числе составляющих государственную тайну уровня «особой важности». Группа компаний «Астра Линукс» является членом Ассоциации РУССОФТ и АРПП.

О Норси-транс

ЗАО «Норси-транс» — российский разработчик и производитель серверного и телекоммуникационного оборудования, систем хранения данных на различных платформах и вычислительных платформах, а также ИТ-решений для здравоохранения, госсектора и др. Основными направлениями деятельности компании являются комплексные ИТ-проекты и отраслевые АПК, разработка и производство ИТ-оборудования и специализированных HPC-решений. «Норси-транс» разрабатывает и производит готовые ПАК по индивидуальным требованиям заказчика, имеет опыт и ресурсы для оперативной реализации крупных ИТ-проектов федерального масштаба, ведет работу по расширению продуктовой линейки.

О Десиме

Заменит ли цифровая копия оригинальные водительские права?

ИТ в государственном секторе

ООО «Децима» специализируется на разработке и производстве высокотехнологичного оборудования для сбора, хранения, обработки, передачи и отображения информации. Ключевыми направлениями деятельности компании являются оборудование для диспетчерского управления воздушным движением и объекты энергетики, цифровые системы видеонаблюдения и аудиозаписи, измерительные и навигационные приборы, а также конференц-средства.

РусБИТех-Астра недавно представила новую версию Astra Linux Special Edition 1.7, которая, как многие из вас знают, имеет разные версии Astra Linux, некоторые из которых используются в зависимости от правительства России, но для общего использования. Таким образом, дистрибутив стал довольно популярным и имеет различные решения как для мобильных устройств, так и для настольных компьютеров.

Одной из таких предлагаемых версий является версия «Astra Linux Common Edition», которая включает в себя проприетарные решения от разработчиков РусБИТех и бесплатные программные компоненты, позволяющие расширить возможности вашего приложения в качестве серверной платформы или на компьютерных рабочих станциях. пользователей.

В то время как другой - "Astra Linux Special Edition", он позиционируется как пакет специального назначения, защищающий конфиденциальную информацию и государственную тайну на уровне "особой важности".

Дистрибутив основан на базе пакета Debian GNU/Linux и содержит дополнительные механизмы безопасности, такие как собственная система обязательного контроля доступа, аудит, проверка целостности и подлинности файлов (PARSEC), гарантированное удаление файлов и создание ядро с исправлениями для повышения безопасности. Пользовательская среда построена на основе фирменного рабочего стола Fly с компонентами, использующими библиотеку Qt.

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

Оглавление

Основные новые функции Astra Linux Special Edition 1.7

В этой новой версии дистрибутив перенес базу системы на Debian 10, вместе с которым сейчас дистрибутив предлагает ядро Linux 5.4, но к концу года обещают перейти на версию 5.10.

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

Базовая. Без дополнительной защиты функциональность аналогична Astra Linux Common Edition. Режим подходит для защиты информации в государственных информационных системах третьего класса защищенности, информационных системах персональных данных 3-4 уровней защищенности и важных объектах критической информационной инфраструктуры.
Улучшенная- Предназначена для обработки и защиты информации ограниченного доступа, не составляющей государственную тайну, в том числе в государственных информационных системах, информационных системах персональных данных и важных объектах критической информационной инфраструктуры любого класса (уровня) защищенности (категории важности) .
Максимум: обеспечивает защиту сведений, составляющих государственную тайну любой степени секретности.

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

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

Реализована возможность создания больших изолированных уровней целостности. Для дополнительной изоляции контейнеров добавлены инструменты для фильтрации сетевых пакетов по флагам классификации, а на файловом сервере Samba обеспечивает обязательный контроль доступа для всех версий протокола SMB.

Из других выдающихся изменений:

Обновленные версии компонентов дистрибутива, включая FreeIPA 4.8.5, Samba 4.12.5, LibreOffice 7.1, PostgreSQL 11.10 и Zabbix 5.0.4.
Реализована поддержка виртуализации в контейнерах с усиленной изоляцией.
В пользовательскую среду добавлены новые цветовые схемы.
Изменен дизайн темы входа, панели задач и значка меню "Пуск".
Был предложен Astra Fact, аналог шрифта Verdana.

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

Загрузить Astra Linux Special Edition 1.7

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

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

Содержание статьи соответствует нашим принципам редакционной этики. Чтобы сообщить об ошибке, нажмите здесь!.

Китайские военные также работают над аналогичным планом по замене Windows пользовательской ОС.

Каталин Чимпану работала корреспондентом ZDNet по безопасности с сентября 2018 г. по февраль 2021 г.

См. также

Российские власти приблизились к реализации своего плана по замене ОС Windows на военных системах на операционную систему местной разработки под названием Astra Linux.

В прошлом месяце Федеральная служба по техническому и экспортному контролю (ФСТЭК) России предоставила Astra Linux допуск к секретным данным «особой важности», что означает, что ОС теперь может использоваться для обработки правительственной информации Российской Федерации с наивысшей степенью секретности.

До сих пор российское правительство использовало только специальные версии Windows, которые были модифицированы, проверены и одобрены для использования ФСБ.

Что такое Astra Linux?

Но начиная с прошлого месяца российские военные теперь могут начать переход на Astra Linux, производную от Debian, разработанную российской компанией RusBITech с 2008 года.

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

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

С тех пор Astra Linux постепенно проникла в государственные учреждения и в настоящее время используется в Российском национальном центре управления обороной, а также в различных других правительственных и военных учреждениях.

Уже используется российскими военными

В январе 2018 года Министерство обороны России объявило о планах перевода военных систем с ОС Windows на Astra Linux, сославшись на опасения, что подход Microsoft с закрытым исходным кодом может скрывать бэкдоры Windows, которые разведка США может использовать для шпионажа за российским правительством. операции.

С тех пор RusBITech проходит процесс сертификации российского правительства, чтобы получить классификацию «особой важности» для Astra Linux, что и было сделано 17 апреля, согласно сообщениям двух местных СМИ [1, 2].< /p>

Помимо сертификата ФСТЭК, Astra Linux также получила сертификаты соответствия от ФСБ, высшего разведывательного управления России и Министерства обороны, что открывает двери для полного принятия высшими российскими военными и спецслужбами.

Сертификация была предоставлена для Astra Linux Special Edition версии 1.6, также известной как выпуск Smolensk, согласно местным отчетам. Это коммерческая (платная) версия.

Эта новость появилась после того, как ранее на этой неделе стало известно, что китайские военные предпринимают аналогичные шаги для замены ОС Windows на военных системах из-за опасений взлома со стороны США. Китайские военные не пошли на дистрибутив Linux, а вместо этого сослались на планы разработки собственной ОС.

Читайте также: