Астра линукс deb или rpm

Что лучше deb или rpm

Установка программного обеспечения — очень важный момент в работе с операционной системой. Сейчас есть две самые распространенные системы установки программного обеспечения. Это используемая в Debian и всех ее производных, в том числе и в Ubuntu — deb, а также разработанная в RedHat и используемая в Red Hat и всех основанных на ней дистрибутивов — rpm.

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

Основы

С точки зрения пользователя, эти два варианта установки пакетов не имеют очень больших различий. Оба файла и Deb и Rpm — это всего лишь архивы, созданные с помощью утилиты ar. Эти архивы включают в себя файлы программ, исполняемые файлы, библиотеки, или файлы конфигурации. Кроме этого, в каждый пакет входят метаданные системы управления пакетами, именно этим и отличаются rpm и deb. Собственно файлы пакетов отличаются в основном только этим, но еще есть система управления пакетами. А там уже различий в базе данных намного больше.

Давайте рассмотрим каждую систему управления пакетами подробнее, а затем сравним что же в них особенного, и что лучше rpm или deb.

RPM (Red Hat Package Manager)

Как мы уже говорили, RPM — это менеджер пакетов, используемый в операционных системах, основанных на Red Hat, это вся ветка дистрибутивов: Fedora, OpenSUSE, Red Hat, CentOS и т д. Изначально этот пакетный менеджер был разработан в компании Red Hat еще в 1997 году и только для их дистрибутива, но затем он распространился и в другие операционные системы. Вместо обычного сжатия здесь используется сжатие gzip по алгоритму cpio и особый формат файла архива, его мы рассмотрим ниже. Здесь в сравнении rpm или deb, первый кажется лучше, но не все так просто, если в системе нет нужных утилит, то вы не сможете распаковать такой пакет. Кроме cpio могут использоваться и другие алгоритмы сжатия, например, lzma или xz. В последнее время все программное обеспечение подписывается ключами для удостоверения подлинности, вот и RPM поддерживает подпись с помощью GPG и MD5. Технология PatchRPMs или DeltaRPMs позволяет грамотно обновлять RPM пакеты без больших затрат трафика.

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

Для работы с RPM могут использоваться несколько различных пакетных менеджеров, это универсальная утилита rpm, пакетный менеджер zypper в OpenSUSE, dnf в Fedora, urpmi в Mageia, yum — во многих дистрибутивах, основанных на Fedora.

Рассмотрим основные особенности RPM:

• Автоматическое разрешение зависимостей в большинстве случаев корректно
• Файл архива имеет специальный формат
• Не поддерживается реализация зависимостей с выбором завистимости от пакет1 или пакет2.
• Не поддерживаются рекомендованные пакеты
• Позволяет настроить зависимость от файла, а не пакета
• Все данные об установленных пакетах хранятся в базе данных поэтому при надобности можно проверить контрольные суммы
• Поддерживаются сценарии как до, так и после установки программ
• Поддерживается формат SRPM, который содержит в себе исходники программы все патчи с инструкции по сборке, позволяющие собрать программу из исходников на локальной машине.
• Отличная поддержка Multilib пакетов

Deb (Debian Package Manager)

Файлы deb — это архивы, созданные с помощью утилиты ar. Они могут быть сжаты с помощью GZIP, Bzip2, lzma, или XZ. Чаще всего для управления пакетами deb в терминале используется утилита dpkg, Но могут и другие, например, gdebi, apt, aptitude и т д. Deb пакеты используются для установки программного обеспечения во многих операционных системах, основанных на Debian, это ветка Ubuntu со многими основанными на ней дистрибутивами и так далее. Поскольку Ubuntu в последнее время набирает популярность среди новичков, то пакетов для нее становится больше.

Из особенностей системы управления пакетами DEB можно назвать использование приоритетов для классификации пакетов по важности, а также поддержку рекомендованных пакетов. Это пакеты, которые не находятся в зависимостях программы, но желательны для установки вместе с ней. Рекомендованные утилиты устанавливаются автоматически в таком инструменте, как apt. Чтобы сравнить rpm vs deb рассмотрим особенности deb:

• Файл пакета — обычный архив
• Поддержка приоритетов для пакетов различной важности
• Поддержка рекомендованных пакетов
• Не поддерживаются файловые зависимости
• Не поддерживается технология Delta для экономии трафика

Аналоги команд

Давайте рассмотрим аналоги команд для выполнения одних и тех же действий в этих системах управления пакетами с помощью утилит rpm и dpkg:

Источник

Сборка и установка Linux пакетов в российских сертифицированных ОС

Введение

Ранее в статье мы описали сборку расширений для LibreOffice. Теперь мы расскажем, как наработки были перенесены на платформу Linux, а также как решались вопросы с подготовкой пакетов для российских сертифицированных операционных систем, таких как AstraLinux, ALTLinux и RedOS.

Постановка задачи и первичная реализация

После успешной реализации нашего продукта DSS для платформы Windows потребовалось перенести наработки (в том числе и расширение для LibreOffice на C++, о сборке и установке sdk которого было рассказано ранее) на платформы семейства Linux.

Состав пакета

Соответственно, необходимо определить, что мы переносим:

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

Последний пункт легче всего интегрировать, так как сборка под Linux для него описана в нашей статье .
Что касается служб для связи сервером и для обработки обращений к файловой системе, то они написаны на .net core, а данный фреймворк с версии 3.0 также легко переносим на Linux.
Windows драйвер мы заменили на Linux Kernel Module (LKM), подробности по его созданию будут описаны в одной из дальнейших статей.

Службу шифрования также пришлось немного переписать, так как она реализована на C++.
Для переноса приложения, обеспечивающего нас диалоговым окном, написанного на WinForms, мы использовали фреймворк Avalonia. По применению и сложностям будет создана отдельная статья. Также возникла необходимость добавить запуск данного приложения через нажатие ПКМ на определённый файл. В Ubuntu в этом помог filemanager-actions (он же в ранних версиях nautilus-actions). При помощи него можно добавить практически любой сценарий обработки ПКМ, но, повторюсь, в рамках Ubuntu (как окажется далее ещё и в AltLinux).

Сборка

Теперь, когда мы определились с содержимым, для начала соберём deb пакет.
Так как у нас есть службы — их необходимо демонизировать. Для этого используем systemd.
Изначально было принято решение для сборки deb пакета использовать checkinstall. Первый пакет был собран при помощи него. Но при добавлении сборки в CI появились/возникли проблемы с окружением сборки, зависимостями и скриптами до/после установки. Поэтому было решено, что лучше это делать через fakeroot. Эти действия, по большей части, были описаны в данной статье.

Создаём отдельную директорию, содержащую инструкции для systemd, которую после перенесём в /lib/systemd/system.

Создаём директорию с содержимым, которое необходимо перенести при установке пакета.

А также создаём директорию DEBIAN, содержащую сценарии для действий перед/после установки/удаления и control, описывающий основную информацию пакета и его зависимости.
После созданного контента выполняем fakeroot dpkg-deb —build «имя пакета».

В итоге на выходе мы имеем deb пакет с содержимым.

Установка, удаление и проверка работы

Устанавливаем его командой:

При установке переносятся и запускаются три демона (приложения, работающие фоном, аналог служб Microsoft).

Для проверки их работоспособности выполняем:

Для примера статус нашего dssservice

Далее началось тестирование пакета и выявление всех зависимостей, которые в процессе создания не были учтены. После успешной обработки всех зависимостей выяснилась одна интересная деталь. Если мы хотим подключаться по rdp к машине, то данный функционал необходимо настроить, так как по дефолту сервера для подключения по данному протоколу нет, как на Microsoft. Самым простым способом нaстройки rdp является настройка xrdp совместно с xfce4. При настройке xfce4 используется в качестве проводника Thunar и, соответственно, пункт в ПКМ, который мы добавляли через filemanager-actions, для него не добавляется. Но решение довольно быстро было найдено — находясь в домашней директории, проходим по следующему пути: и там будет лежать файл uca.xml, содержащий сценарии для ПКМ.

Разворачивание пакетов в российских сертифицированных ОС

После успешного тестирования данного пакета на Ubuntu возник вопрос о работоспособности его на других ОС, использующих dpkg, как менеджер пакетов, а, соответственно, поддерживающих .deb. А, в частности, вспомнилась отечественная разработка (импортозамещение никто не отменял) — AstraLinux.

AstraLinux

С ходу установить пакет не удалось, так как наш пакет имеет в зависимостях filemanager-actions, который мы используем для добавления пункта ПКМ в Nautilus Ubuntu. Но в AstraLinux используется файловый менеджер fly, и для добавления в него мы не будем использовать filemanager-actions, пришли к выводу, что для AstraLinux будем собирать пакет без учёта этой зависимости. А для добавления используется сценарий «имя_процесса».desktop, который добавляется в /usr/share/flyfm/actions/.

Также были разрешены некоторые моменты, связанные с LKM, но их мы рассмотрим в следующей статье.

Cборка RPM

Следующей ОС стала ALTLinux. Она интересна тем, что имеет пакетный менеджер APT, но при этом вместо dpkg у неё используется rpm. А, следовательно, пора нам собрать наш пакет и под rpm.

Изначально попробовали сделать преобразование deb в rpm, как описано в этом мануале.

Alien достаточно мощная утилита, и с её помощью можно достаточно просто преобразовать пакет, достаточно только следовать её подсказкам и добавить недостающее (если она об этом попросит). В итоге при конвертации получили rpm пакет, но при попытке его установки вылезли зависимости, ссылок на которые изначально не было (позже расскажу, в чём была изюминка). Поэтому было принято решение собрать rpm пакет непосредственно средствами rpmbuild.

Сначала решили собирать не под ALTLinux, а под RedOs, так как со стороны бизнеса на неё более перспективные планы. RedOs основана на CentOS, поэтому сборку решили проводить в ней.

Часть с systemd остаётся без изменений, а вот Debian заменяем на файл «имя_проекта».spec, который содержит в себе всю информацию и зависимости из control, сценарии для действий перед/после установки/удаления, а так же описание содержимого пакета (непосредственно пути до того, что необходимо добавить).

После создания файла выполняем:

переносим .spec в rpmbuild/SPECS и выполняем:

после чего забираем из директории rpmbuild/RPMS созданный пакет.

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

Как оказалось, изюминка заключается в том, что при создании rpm система подтягивала дополнительные библиотеки, и ставила их в зависимость. Чтобы такого не было — необходимо в файл .spec добавить строку после описания зависимостей:

Пробуем установить и да — победа, пакет корректно устанавливается.

Для установки rpm пакета используем команду:

Для удаления (без удаления пакетов, находящихся в зависимости):

RedOs

Далее необходимо разобраться с зависимостями, так как необходимые для работы наших приложений пакеты уже имеют другие названия, а также необходимо разобраться с добавлением пункта в ПКМ.

В RedOs в качестве файлового менеджера используется nemo. Для добавления в него пункта в ПКМ необходимо создать файл «имя_действия».nemo_action, в котором по аналогии с файлом .desktop (для AstraLinux) будет сценарий обработки нажатия на новый пункт меню, и переместить его в

/.local/share/nemo/actions/, перезагрузить nemo и пункт появится.

ALTLinux

После успешного тестирования rpm пакета на RedOs перешли к формированию rpm пакета под
ALTLinux. По сути, необходимо скорректировать зависимости, так как для каждой оси пакеты будут иметь своё название, и снова понять, как произвести добавление пункта в ПКМ. Тут нам на помощь снова пришёл filemanager-actions, через который также можно добавить пункты в ПКМ и для Mate и Caja, которые как раз и используются в ALTLinux.

В итоге, мы собрали пакеты для основных, используемых у заказчика, ОС.

Заключение

В дальнейших статьях мы расскажем, почему использовали LKM и Avalonia и какие трудности из-за этого были, а также о дальнейших планах на доработку пакетов (в частности, доработка UI для ввода необходимой информации) и приложений, используемых в них.

Источник

Операционные системы Astra Linux

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

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

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

1. инструкций и методических указаний по настройке и особенностям эксплуатации ОС, содержащих сведения о компенсирующих мерах или ограничениях по примене- нию ОС при эксплуатации;
2. отдельных программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, инструкций по их установке и настройке, а также информации, содержащей сведения о контрольных суммах всех файлов оперативного обновления;
3. обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.

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

Источник