rpm пакеты что это
Rpm пакеты что это
При установке пакета rpm записывает информацию о нем в свою базу данных, что и позволяет в дальнейшем удалять пакет, просматривать информацию о нем и т.д.
Режимы работы rpm
Если вызвать rpm без параметров, то он покажет «краткий» список ключей. Обычно же формат вызова rpm такой:
КлючРежима, указываемый первым, определяет режим работы. Самые частоиспользуемые режимы перечислены в таблице.
Установку, обновление и удаление пакетов мы рассмотрели ранее, поэтому сейчас остановимся лишь на общих параметрах, получении информации и проверке.
Ключи и параметры, общие для разных режимов
В аргументах обычно используется два варианта ссылок на пакеты.
Можно указывать не один файл-пакета или пакет, а сразу несколько, разделяя их пробелами.
Получение информации
Какому пакету принадлежит файл
А как там назывался пакет.
Другой пример («к чему там относится afterstep?»):
Где же был этот файл.
Аналогично иногда возникает необходимость найти некий файл, имя которого помнишь весьма приблизительно, а уж в какой он лежит директории.
Информация о неинсталлированном пакете
Перед установкой нового пакета обычно имеет смысл посмотреть информацию о нем и/или список содержащихся в нем файлов.
В вышеприведенном примере видно, что данный пакет установить не удастся, как минимум потому, что установленная версия пакета gtk+ слишком старая.
Проверка
При нахождении различий печатается ключевая строка, с обозначением отличий и имя файла, в котором они найдены.
Сравниваются следующие параметры: 5 Контрольная сумма (подсчитанная по алгоритму MD5) S Размер файла L Куда указывает символьный линк (если проверяемый файл является симлинком) T Время модификации D Устройство (раздел), на котором расположен файл U Владелец G Группа-владелец M Права доступа
Проверку лучше выполнять как » root «, так как некоторые файлы (например, /usr/X11R6/bin/xterm ) могут быть недоступны на чтение другим пользователям и для них всегда будет выдаваться несовпадение по контрольной сумме.
Как видно из этого примера, в некоторых файлах обязательно будут отличия, поскольку тот же /etc/passwd изменяется при создании и изменении пользователей.
Где еще брать информацию про rpm
Команда RPM в Linux
В этом руководстве мы поговорим о том, как использовать команду rpm для установки, обновления, удаления, проверки, запроса и иного управления пакетами RPM.
Установка, обновление и удаление пакетов RPM
Вы всегда должны предпочитать использовать yum или dnf rpm при установке, обновлении и удалении пакетов.
Только root или пользователи с привилегиями sudo могут устанавливать или удалять пакеты RPM.
Вы можете пропустить загрузку и указать URL-адрес RPM-пакета команде rpm :
Если пакет, который вы устанавливаете или обновляете, зависит от других пакетов, которые в настоящее время не установлены, rpm отобразит список всех недостающих зависимостей. Вам придется скачать и установить все зависимости вручную.
Запрос пакетов RPM
Если пакет установлен, вы увидите что-то вроде этого:
Чтобы получить список всех файлов в установленном пакете RPM:
Если вы хотите узнать, к какому установленному пакету принадлежит конкретный файл, введите:
Проверка пакетов RPM
При проверке пакета команда rpm проверяет, существует ли каждый файл, установленный пакетом, в системе, дайджест файла, право собственности, разрешения и т. Д.
Если проверка прошла успешно, команда не выведет никаких результатов. В противном случае, если некоторые из проверок не пройдут, отобразится символ, указывающий на неудачный тест.
Например, следующий результат показывает, что mTime файла был изменен («T»):
Обратитесь к странице руководства RMP о том, что означает каждый символ.
Чтобы проверить все установленные пакеты rpm, выполните следующую команду:
Выводы
rpm — это низкоуровневый инструмент командной строки для установки, запроса, проверки, обновления и удаления пакетов RMP. При установке пакетов RPM следует предпочесть использование yum или dnf поскольку они автоматически разрешают все зависимости за вас.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
Сборка rpm пакетов и настройка своего репозитория
В данной статье будет подробно описан процесс создание rpm пакетов и организация репозитория. Прошу всех, кому интересна данная тема, пройти под кат.
Я взялся писать крайне подробно, так что Вы можете пролистать очевидные для Вас вещи.
Оглавление
Установка системы
Наш сервис начинается с момента установки на него операционной системы. Естественно, что для сборки rpm пакетов мы выбираем rhel дистрибутив. В данном случае, был выбран CentOS 7.
Скачать CentOS
Создадим директорию, где будет лежать образ и перейдем в нее:
Далее можно непосредственно скачать образ и необходимые для проверки файлы:
или посредством torrent`а с помощью программы aria2, которую для начала установим:
Проверить образ
Скачать образ мало, нужно проверить его целостность и достоверность, что мы и сделаем.
Скачаем ключ для CentOS 7:
Посмотрим на ключ и импортируем его:
Проверим подпись файла, с контрольной суммой образа:
Как мы видим — все отлично и теперь можем проверить сам образ на целостность:
Запись образа на носитель
После того как мы убедились в целостности образа и его достоверности, неплохо было бы его уже записать и установить! Так сделаем это, но вначале определимся, на что записывать будем.
Запись образа на диск
Для записи данного образа, нам понадобится двухсторонний DVD. Допустим мы его нашли и записываем, установив предварительно wodim:
Запись образа на флешку
Двухсторонний DVD это как то архаично, так что возьмем флешку на 16 гб и запишем образ на нее, но прежде /dev/sda тут — это флешка, а у Вас она может быть другой. Смотри команду fdisk:
Если status=progress не поддерживается, то по старинке:
а можно воспользоваться pv:
Установка
Как поставить Centos 7, решать Вам, тут и за RAID подумать можно и за LVM и много чего еще,
я ставил минимальный пакет.
Процесс установки можно посмотреть в этом ролике.
Преднастройка
После установки системы, нам необходимо настроить наш сервер.
Обновление и установка пакетов
В начале мы обновим все установленные пакеты, далее установим репозиторий epel, в котором есть много что полезного для нас:
Следующим шагом установим группу пакетов, которые понадобятся нам для сборки, а так же ряд пакетов необходимые для развёртывания репозитория.
Для того чтобы комфортно и безопасно управлять сервером настроим SSH.
Безопаснее пользоваться ключами, по этому мы и создадим себе ключи для доступа к серверу на своем рабочем компьютере:
и добавим ключ на сервер:
Необходимо еще закрутить гайки в самой службе. Создадим копию файла конфигурации и приступим к редактированию:
В файле стоит добавить/изменить/раскомментировать следующие строки:
Межсетевой экран
Важно ограничить доступ к нашему серверу. По этой причине настроим межсетевой экран:
Тут мы добавили наши службы http https ftp для доступности извне и ssh, но только для сети 192.168.0.0/28.
Подготовка площадки сборки
Подготовим саму площадку для сборки. Стоит отметить, что вернее всего сборку производить на отдельном виртуальном хосте, активно используя технологию snapshot’ов, но тут я опишу все в едином целом. Так же для сборки нужно выделить отдельного пользователя, не являющемся администратором (т.е. sudo ему недоступно).
Создание директорий
Создаем необходимые директории:
Настройка PGP подписи
Наши пакеты, которые мы соберем, необходимо подписать, что будет обеспечивать целостность и достоверность.
Ключ будем использовать свой или если его нет, то создадим. Создавать ключ стоит на своем рабочем компьютере.
Создадим ключ, если его у нас нет:
Нас попросят ответить на ряд вопросов:
тип ключа, выбираем (1) RSA and RSA (default), размер ключа: 4096, срок действия: 6m, наше имя: Alexander F. Mikhaylov, Email: chelaxe@gmail.com, комментарий, тут можно указать для чего нам ключ: repo и ждем.
Сохраняем наш приватный ключ:
Создадим ключ для отзыва:
Экспорт открытого ключа на keyserver:
Теперь ключ можно и импортировать на наш сервер:
Смотрим где находится gpg утилита:
и настроем файл для подписи пакетов:
Создаем репозиторий
Теперь организуем сам репозиторий.
Создадим директорию, где будем хранить пакеты:
Экспортируем ключ в репозиторий:
Создаем сам репозиторий и подписываем метаданные:
Пакет для репозитория
Собираем пакет для автоматической установки репозитория в систему.
Файл репозитория для yum:
Экспортируем ключ для пакета:
Собираем все в архив:
Создаем SPECS файл для пакета:
На этом этапе нас спросят пароль от нашего PGP ключа.
Копируем созданный пакет в репозиторий и обновляем его:
Не забываем подписать метаданные:
Теперь установим наш репозиторий в систему:
После установки должен появиться репозиторий chelaxe и PGP ключ:
Самое важное тут это SPEC файлы, расписывать о них не стану, но предоставлю ряд ссылок:
и одна полезная команда:
она отобразит готовые макросы для сборки.
Собираем Tmux
Теперь соберем, для примера, что нибудь полезное. Собирать будем tmux — терминальный мультиплексор, без которого работать мне не комфортно. Стоит отметить tmux есть в base репозитории CentOS 7, но версия там 1.8, а мы соберем 2.7. Так же у пакета из base репозитория есть зависимость libevent, мы же соберем tmux со статическими библиотеками последних версий.
Готовим исходники
Скачиваем исходники tmux и необходимых библиотек:
Экспортируем GPG ключи для проверки исходников:
Подготовим файл конфигурации tmux:
Готовим SPEC файл
Этот файл будет интереснее предыдущего SPEC файла:
Сборка
Собираем пакет и добавляем его в репозиторий:
Не забываем подписать метаданные:
Смотри что и как получилось:
Установка и запуск
Устанавливаем наш пакет:
Запускаем tmux и радуемся:
Собираем fbida
Собирать будем fbida — комплект приложений для просмотра изображений в консоли. Данный пакет не нашел под Centos 7.
Готовим исходники
Скачиваем исходники fbida:
Экспортируем GPG ключи для проверки исходников:
Готовим SPEC файл
В этом SPEC файле будет больше зависимостей:
Сборка
Собираем пакет и добавляем его в репозиторий:
Не забываем подписать метаданные:
Установка и запуск
Устанавливаем наш пакет:
Настройка доступа по http/https
Теперь обеспечим доступ к нашему репозиторию по http/https.
Настройка
Первым делом настроем наш Apache:
Далее необходимо добавить/изменить/раскомментировать следующие строки:
Запускаем службу и прописываем ее в автозапуск:
Настраиваем наш репозиторий:
Т.к. в Centos 7 у нас Apache 2.4.6, а не 2.4.8, то параметры Диффи-Хеллмана необходимо вшить в сертификат:
По этой же причине с HTTP/2 у нас ничего не получится, но теперь вы можете собрать сами свежий Apache и воспользоваться HTTP/2.
Проверим конфигурацию и перечитаем конфигурацию:
Сертификат от Let’s Encrypt
Пока у нас свой сертификат и это не красиво, так что получим сертификат от Let’s Encrypt:
При ответе на вопросы, выбираем использование rewrite для перенаправления всех на https. В результате в файле изменяться строки у VirtualHost для http:
и у VirtualHost для https:
Строку Include /etc/letsencrypt/options-ssl-apache.conf закомментируем.
Тут стоит напомнить о необходимости добавить файл с параметрами Диффи-Хеллмана в конец сертификата:
И изменить заголовок HKPK (HTTP Public Key Pinning):
И изменим соответственно строку в конфигурации:
Проверим конфигурацию и перечитаем конфигурацию:
Есть еще одна проблема. Для обновления сертификата добавим запись в крон:
Но этого не достаточно, нужно еще дописать автоматическое добавление файла с параметрами Диффи-Хеллмана и параметры HKPK (HTTP Public Key Pinning).
для исключения в отображении на сайте.
Для vsftpd можно использовать опции:
Тут можно используя модуль mod_autoindex Apache настроить внешний вид. Завернуть в noscript тег и используя html5, css3, javascript, jquery, bootstrap, backbone, awesome сделать конфетку, как это сделал я:
Вот что будет при использовании в браузере без поддержки javascript или с отключенным:
Настроить внешний вид листинга через mod_autoindex или в nginx:
Настройка доступа по ftp
Запускаем службу и прописываем ее в автозапуск:
Заключение
Собственно на этом все. Надеюсь, данный мануал будет Вам полезен.
Основы RPM
Эта статья может служить кратким введением в систему Red Hat Package Management, или RPM. Мы поговорим о том, что собой представляет RPM, почему его следует использовать, а также сравним его с другими системами управления программными пакетами для Linux и Unix.
Red Hat Package Manager (RPM) представляет собой набор инструментальных средств, служащих для создания и управления программными пакетами в Unix-системах. RPM, поставляемый вместе с Red Hat Linux и производными от него дистрибутивами, может работать с любым вариантом Unix, поскольку распространяется в исходных текстах. Однако найти RPM-пакеты для других диалектов Unix непросто.
Хотя управление пакетами строится на довольно тривиальных принципах, его реализация может оказаться делом непростым. Конечно, контролируемая установка ПО, управление уже установленными программными пакетами и их удаление из системы трудностей не представляет. RPM был создан в связи с необходимостью выполнять такие операции эффективно; другого содержательного решения тогда не было.
RPM, в отличие от ряда других менеджеров программных пакетов для Unix, использует собственный формат файлов. Это может породить серьезные проблемы, если потребуется выделить какой-то один компонент из пакета, а утилиты RPM под рукой нет. К счастью, существуют такие инструменты, как Alien, позволяющие получить файлы в формате, который допускает управление, скажем, с помощью tar или ar.
Схема именования файлов RPM сама по себе является стандартизованной конвенцией. Названия RPM имеют формат (имя)-(версия)-(сборка).(платформа).rpm. Например, название cat-2.4-7.i386.rpm используется для обозначения RPM-пакета для утилиты cat версии 2.4, сборки 7 для платформы x86. Если вместо названия платформы указано src, значит, речь идет об исходных текстах.
Зачем нужно управление пакетами?
Для небольших утилит, таких, как, скажем, cat, которые имеют один исполняемый модуль и одну страницу справочника man, RPM не нужен. Но возьмем, например, KDE, включающий множество компонентов и зависимостей и требующий их повсеместного соблюдения. Отследить их все крайне сложно, если вообще возможно.
Управление пакетами существенно упрощает задачу. Позволяя программе поддерживать информацию о своих объектных модулях, своих файлах конфигурации и обо всем остальном, что ей требуется, вы можете указать, какие из них следует устанавливать, легко удалить их или без труда обновить.
Управление установленными пакетами также прекрасно осуществляется хорошей системой управления пакетами. Система хранит полный список установленного ПО, который стоит посмотреть, если вы решили что-то установить. Еще важнее то, что такая система позволяет без труда модернизировать имеющиеся решения. Наконец, с ее помощью просто провести проверку корректности пакетов. Зная, какие пакеты установлены и каковы свойства их компонентов, можно быстро диагностировать проблему и с успехом ее устранить.
RPM и другие
Коротко говоря, основное мое недовольство RPM связано с отсутствием для него мощного графического пользовательского интерфейса. При том, что кое-какие интерфейсы есть (такие как gnorpm и glint), в них отсутствуют более сложные функции, реализованные в SGI Software Manager. В целом, я считаю, что RPM лучше выполняет разбор и разрешение конфликтов, чем inst, и намного, намного быстрее. Так что я согласен обойтись и без мощного графического интерфейса.
В RPM меня больше всего восхищает скорость и проверка пакетов, выполняемая с помощью сигнатур пакетов и контрольных сумм компонентов. К примеру, однажды мне пришлось перезагружать SGI Software Manager только потому, что я с ошибками переустановил редактор jot. На установку этого небольшого пакета ушло около 15 минут, не считая перезагрузки.
RPM объединяет несколько файлов в одном архиве и выполняет сжатие архива для создания тела пакета RPM. Более того, вставляется дополнительная заголовочная информация, включающая в себя скрипты, выполняемые перед и после установки для подготовки системы к установке нового пакета, а также информацию для базы данных, которую поддерживает RPM. Зависимости проверяются перед установкой каждого пакета; в соответствии с приведенными флагами могут устанавливаться дополнительные компоненты.
RPM способен творить чудеса именно, благодаря этой своей базе данных.
Установка с помощью RPM
Это базовая функция RPM и одна из наиболее популярных. Для этого запустите команду
И опять-таки, в этом случае вы немногое узнаете о том, что происходит. Только то, что процесс установки идет без сбоев. Я же, как правило, стремлюсь при установке нового пакета получить всю возможную информацию (-vv). Это позволяет мне видеть, что происходит:
Хотя выводимая на экран информация обычно прокручивается, она дает возможность точно знать, не возникло ли каких-то проблем. Плюс к тому, понятно, какие модули уже установлены.
Зависимости RPM поддерживает достаточно разумным образом, но все это в немалой степени определяется качеством модуля сборки пакетов. Я встречал пакеты, которые зависели от себя сами, и те, которые, казалось, зависят от пакетов, портящих что-то другое. Помните об этом.
Иногда RPM будет выдавать замечания по поводу пакетов, которые установлены, но не зарегистрированы. Возможно, вы установили их без помощи RPM (скажем, OpenSSL). Чтобы избавится от таких замечаний, вы можете заставить RPM игнорировать зависимости:
Нужно отметить, что это не всегда разумно и это следует делать только тогда, когда вы точно знаете, во что ввязываетесь. Довольно редко можно повредить уже установленные модули, но иногда установленный пакет не будет работать корректно.
В редких случаях RPM будет создавать путаницу и настаивать на том, что вы установили пакет, хотя вы этого явно не делали. Хотя, как правило, подобный случай свидетельствует о какой-то ошибке, ее тоже можно обойти. Просто принудительно установите пакет:
Будьте осторожны. Точно так же, как и в том случае, когда вы игнорировали зависимости, принудительная установка пакета может оказаться неблагоразумной. Помните, что ваша система может перестать работать. Пеняйте на себя.
Вероятно, самой большой наградой вам станет возможность использовать одну из потрясающих функций RPM: установку по сети. Иногда, в системе нет сетевых клиентов, а вам необходимо их установить через RPM. Для этого в RPM встроено программное обеспечение клиентов Web и FTP:
Управление пакетами
Предположим, что вы хотите работать с какими-то из имеющихся пакетов, вне зависимости от того, установлены они или нет. Можно воспользоваться функциями управления для тех пакетов, которые уже установлены, и для тех, которые не установлены. Также есть возможность провести проверку корректности пакетов.
Когда в ваши руки попадает новый пакет, иногда хочется исследовать его, чтобы понять, какие именно возможности он предлагает. Это можно сделать с помощью режима запросов.
Этот шаг позволит получить имя автора, хост, на котором он собран и дату, а также установлен ли он и так далее. Эта информация также включает в себя описание функциональности и возможностей пакета.
Это будет список всех файлов в архиве с их полными именами, в том числе названиями каталогов. Я часто пользуюсь этой опцией, чтобы понять, нужно ли устанавливать пакет, но, самое важное, где его устанавливать. Я предпочитаю придерживаться соглашения о том, что модули следует размещать в предназначенных для них местах, однако некоторые менеджеры пакетов этого не делают. Наконец, чтобы увидеть все пакеты, которые вы установили в своей системе, используйте:
Вам будет выдан список пакетов, установленных в системе.
Проверить корректность всех пакетов, установленных в системе, тоже довольно просто:
Режим проверки корректности позволяет получить некоторые статистические данные о файле.
5 Сумма MD5; S Размер файла; L Символьная ссылка; T Время модификации; D Устройство; U Пользователь; G Группа; M Режим (включая права доступа и тип файла)
Одной из примечательных особенностей управления пакетами, как можно заметить, является легкость, с которой можно выполнять модернизацию. RPM имеет две возможности модернизации пакетов, которые иногда путают. Первая из них — простая модернизация:
Путаница здесь возникает из-за действий, предпринимаемых менеджером пакетов в том случае, если пакет еще не установлен. Если пакет найден, он модифицируется. Если он не найден, то до него модифицируется система, а пакет устанавливается. Иногда это может вызвать недоумение, если вы не хотели устанавливать пакет и выполнять модификацию, которая следует автоматически. Я предлагаю «освежать» только те пакеты, последнюю версию которых вы действительно хотите иметь:
В этом случае будут модифицированы только установленные пакеты, и, если пакет не найден, то устанавливаться он не будет.
Модификация тоже выполняется весьма интересным образом. Сначала устанавливается новая версия и отмечаются ее отличия от старой. Затем старая версия удаляется, но только отдельные ее части так, чтобы не затронуть новые компоненты. Представьте, если /usr/local/bin/netscape был изменен, а затем удален, то все усилия пропали бы даром!
Удаление пакетов
Вы можете устанавливать, обновлять и управлять пакетами и, конечно же, вы можете деинсталлировать пакеты с помощью RPM. Чтобы «безоговорочно» удалить пакет RPM, используйте:
В отличие от установок и модернизаций, при удалении для указания пакета следует использовать не название «пакет-версия.i386.rpm», а просто «пакет-версия». Это имена, которые выводятся на экран в режиме запроса и именно их и следует указывать. Вы должны дать менеджеру пакетов возможность удалить все компоненты пакета, указав самую общую часть имени, например, для linuxconf и linuxconf-devel это будет linuxconf. Можно также обойтись без зависимостей:
Здесь вы вновь берете риск на себя, поскольку можете в итоге удалить больше, чем рассчитываете. Можно, как и при установке, добавить флаги, чтобы получить более детальную информацию.
Некоторые замечания о RPM
Больше всего в пакетах RPM мне не нравится то, что они имеют имена, которые не соответствуют функциям. Хотя это соглашение можно обойти с помощью инструментария запросов, как было описано, но это требует больше времени, чем я готов потратить. Советую давать своим RPM-пакетам максимально корректные имена.
RPM можно использовать с любым вариантом Linux/Unix, поскольку он распространяется в исходных текстах. RPM распространяется в рамках Red Hat Linux и некоторых производных от него дистрибутивах. Рекомендуется использовать версии 3.0 и выше, чтобы обеспечить совместимость. Версия 4.0, как сообщается, имеет другой формат базы данных, поэтому я рекомендую разобраться, как разрешить эту проблему, прежде чем модернизировать свой RPM до версии 4.0. Не уверен, что для этого достаточно просто реконструировать базу данных в 4.0.
RPM обычно сам распространяется как RPM-пакет. Понятно? К счастью, он также поставляется и в виде архива, подготовленного с помощью gzip tarball, и непосредственно в исходных текстах. У меня, к примеру, RPM установлен на Slackware, но его можно установить и на SGI Irix или Sun Solaris, если потребуется. Впрочем, он практически бесполезен на других платформах помимо Linux, поскольку для других вариантов Unix пакеты готовятся средствами RPM крайне редко.
Хосе Назарио — аспирант факультета биохимии университета Case Western Reserve University. Он работает с Unix почти десять лет, а с Linux — с версии ядра 1.2.
Copyright (c) Хосе Назарио. Данный материал распространяется в соответствии с правилами и условиями, определяемыми «Лицензией на Открытые Публикации» (см. ее текст по адресу http://wwww.opencontent.org/openpub/). Jose Nazario, Using RPM: The Basics (Part I). Linux Gazette, Issue 68, July 2001 (www.linuxgazette.com). Перевод на русский язык: Галина Никитина, сентябрь 2001.
Ресурсы
Поделитесь материалом с коллегами и друзьями