Астра линукс установка rpm

Операционные системы 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. обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.

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

Источник

🏋️♀️ Как установить / удалить / запросить / обновить RPM пакеты в Linux (Шпаргалка)

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

Пакет RPM состоит из архива файлов и информации о пакете, такой как имя, версия, описание и информация о зависимостях от других пакетов RPM.

RPM – это больше, чем инструмент для Red Hat

Многие другие современные дистрибутивы, такие как Ubuntu и SuSE, также используют RPM.

Преимущества использования RPM включают в себя:

• Упрощенное распространение, установка, обновление и удаление программного обеспечения
• Гарантирует, что:
  необходимое программное обеспечение установлено в системе.
  версии обязательного программного обеспечения остаются совместимыми.
  локально модифицированные файлы конфигурации не засоряются при обновлении RPM.
  локально измененные файлы конфигурации сохраняются с суффиксом «.rpmsave», если пакет будет удален позже.
• Позволяет подтвердить, что установленное программное обеспечение не было изменено, модифицировано, повреждено или изменено каким-либо образом.

RPM хранит информацию об установленных пакетах в каталоге «/var/lib/rpm».

Компоненты инструмента RPM:

• Пользовательская база данных, содержащая информацию обо всем программном обеспечении, установленном в системе, собранную с отдельных RPM.
• Исполняемый файл «/bin/rpm».
• Доступные через Интернет репозитории доступных пакетов RPM.

Типы RPM-пакетов

RPM-пакеты делятся на две категории: исходные и бинарные.

Исходный RPM всегда можно распознать, поскольку имя файла заканчивается строкой “.src.rpm”.

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

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

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

Например, двоичный файл RPM:

Он содержит файлы, которые можно использовать только на 64-битном процессоре Intel X86.

Другие общие значения архитектуры включают «i386» для 32-разрядных хостов Intel.

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

Примером этих пакетов «.noarch.rpm» является RPM «tzdata», который содержит информацию о мировых часовых поясах.

Чтобы обновить вашу систему до последней версии пакета, вам потребуется самая последняя двоичная RPM-версия.

Схема именования RPM

Каждый пакет RPM содержится в одном файле.

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

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

Этот RPM предназначен для оболочки BASH («/bin/bash»).

Имя файла состоит из нескольких частей:

• [name] – это название программы или пакета. [name обычно присваивается автором программы. В нашем примере разработчики решили назвать свой продукт «bash» по причинам, которые показались им забавными.
• [version] определяет, какая версия программного обеспечения содержит этот RPM. Номер [версии] присваивается автором программы. Использование номера позволяет определить, какая версия авторских источников использовалась для создания RPM.
• [release] предоставляет номер версии самого файла RPM, а не версию исходных файлов автора. Обновленная RPM может быть выпущена для предоставления исправленной версии оригинального программного обеспечения автора. Патч не обязательно должен быть от оригинального разработчика, поэтому RPM-версия увеличивается вместо [version].
• [arch] описывает содержимое RPM и сообщает, содержит ли этот файл источник продукта («.src.rpm»), независимые от архитектуры файлы («.noarch.rpm») или файлы, которые могут быть установлены только в определенный тип хоста («.sh.rpm» будет работать только на встроенном процессоре STRONGHOLD).

Примечание:[version] контролируется первоначальным автором, а [release] контролируется тем, кто создал RPM.

Понимание версий RPM

Поля RPM [version] и [release] не всегда строго числовые и могут содержать другие символы, кроме обычных цифр.

Обычно можно увидеть как версию «10», так и версию «10а» в одном и том же пакете.

Иногда выбрать самую последнюю версию может быть сложно.

Вот как сам RPM сравнивает номера версий и выпусков внутри себя:

1. Удалите префикс [name] и суффикс «. [Arch] .rpm». Например,:
«Bash-3.1-16.1.x86_64.rpm» становится «3.1-16.1», а «bash-3.1-16.5a.1.x86_64.rpm» становится «3.1-16.5a.1»

2. Сравнивайте оставшиеся строки посимвольно слева направо, пока не встретите цифру.

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

3. При обнаружении цифры преобразуйте всю последовательность цифр в одно двоичное число. В нашем примере два символа «16» объединяются в значение шестнадцать (16). Полученные двоичные значения сравниваются, и чем больше значение, тем выше новизна.

Таким образом, RPM с [версией] «0010» является более новым, чем RPM с «версией» «9».

Шаги 2 и 3 повторяются по мере необходимости, пока не произойдет различие.

Установка и удаление файлов

Примечание. Обычно только один или несколько RPM-пакетов могут быть установлены одновременно.

Более поздние версии обычно устанавливаются с использованием функции RPM «-U» (обновление) вместо функции «-i» RPM.

Распространенными исключениями из единственного правила RPM являются RPM ядра.

В системе обычно установлено несколько версий ядер; У RPM есть список, у которых может быть установлено несколько версий.

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

В архитектуре x86_64 обычно устанавливаются как 32-разрядные пакеты «.i386», так и 64-разрядные пакеты «.x86_64», поддерживающие как 32-разрядные, так и 64-разрядные приложения.

Обычно RPM не отображает архитектуру пакета в запросе, но вы можете отобразить его вручную.

Установка и удаление

Подсказка: никогда, никогда не используйте опцию «-U» для установки нового RPM ядра. Функция обновления «-U» сначала удаляет текущий RPM из системы, а затем пытается установить новый RPM. Любая проблема, которая препятствует установке нового RPM, приведет к тому, что система не будет загружаться. Это не то, что вам нужно, поэтому всегда используйте ключ «-i» для установки RPM ядра.

Запросы (пакеты и / или информация)

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

Вы можете запросить все установленные пакеты или один установленный пакет.

Вы также можете узнать, какой RPM предоставляет конкретный файл.

Информация

по умолчанию (имя пакета)
-i: общая информация
-l: список файлов

Примеры

Подсказка: при поиске определенного пакета RPM, когда точное имя неизвестно, используйте пайп таким образом:

Более поздние версии инструмента RPM позволяют сделать это кратко:

Запросы – проверка (файлы)

База данных RPM содержит множество атрибутов для каждого файла, установленного RPM.

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

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

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

Запросы – проверка (пакеты)

Восстановить базу данных RPM

Средство RPM использует свою собственную реализацию базы данных для хранения своей информации

. Иногда эта база данных может быть повреждена; симптомы включают заявления об отсутствии установленного пакета RPM; или попытки обновить RPM просто зависают.

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

Вы должны войти в систему с привилегиями суперпользователя (он же «root») для этих действий.

Команды могут быть скопированы и вставлены непосредственно в окно рутового терминала.

1. Убедитесь, что в вашей системе не запущены процессы RPM. Используйте команду ps, чтобы идентифицировать их. Используйте команду kill, чтобы завершить любые процессы «rpm», которые вы найдете; «kill -9» на всякий случай.

2. Удалите файлы блокировки, которые использует RPM:

3. Если вы испытыли зависание команды «rpm», попробуйте снова.

Если это работает, это все. Если нет, выполните Шаг № 1 и № 2 снова. Затем перейдите к следующему шагу.

4. Сделайте резервную копию вашей базы данных RPM:

Источник

Сборка и установка 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 для ввода необходимой информации) и приложений, используемых в них.

Источник