Тесты

Fedora установка программ через консоль. Установка программ в Linux (.tar,.gz,.bz, RPM и DEB)

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

В более старых версиях Linux (базирующихся на Red Hat) существовало только два способа установки программ. Это сборка из исходных кодов и установка из RPM-пакетов. Рассмотрим каждый способ поподробнее.

Исходные коды скачиваются с сайта программы. В общем случае, для установки нужно распаковать и выполнить 3 команды: configure, make и make install . Первая команда имеет очень много параметров (вывести список которых можно, запустив configure -help ), таких, как путь установки программы, пути к различным библиотекам и много других. После удачного завершения первого этапа, нужно запустить команду make . Она скомпилирует исходные коды в бинарные файлы. Если компиляция прошла успешно, то по последней команде скомпилированные файлы скопируются по своим директориям. Преимущество такого способа установки заключаются во-первых в том, что 99% всех open source – программ распространяются в исходниках, а RPM-пакета у нужной программы может не быть (сейчас, правда, формат RPM очень распространился и почти все разработчики стараются создавать пакеты в этом формате). Во-вторых всегда можно отредактировать исходники устанавливаемой программы, исправив ошибку или внеся нужные изменения. Минус только один – для использования этого способа необходимо знать язык программирования c/c++ и архитектуру ОС. Поэтому далеко не каждый может пользоваться этим способом, особенно, если при этом возникли какие-либо ошибки.

Установка из RPM-пакета производится так: необходимо скачать RPM-пакет и выполнить всего одну команду: rpm -Uvh ./packet_name.rpm (где packet_name – имя файла пакета). Такой способ не только намного проще, но и быстрее, так как в пакете программа уже скомпилирована (время на компиляцию программы может уходить довольно много, в зависимости от мощности вашего компьютера). Однако способ тоже не идеальный, так как часто бывает, что программа для своей установки требует, чтобы также были установлены какие-либо другие пакеты (например с нужными библиотеками) – появляются так называемые зависимости. Если программа требует одну библиотеку – не страшно, но программа может требовать 10 и больше библиотек, каждая из которых, в свою очередь, тоже может требовать установку библиотек. Поэтому время установки программы может сильно затянуться.

Однако в последних версиях Fedora с появлением такой консольной утилиты, как yum, устанавливать программы очень приятно. Для этого нужно всего-навсего набрать в консоли команду: yum install name (где name – имя программы для установки). Мало того, что yum сама скачает из интернета нужный пакет и установит программу, она также скачает и установит все программы, требующиеся для этого. Если вы не любите пользоваться консолью, в KDE, например, из меню запустите программу Система / Установка/удаление программ и установите программу, используя графический интерфейс.

FOSS-системы вообще, и Fedora в частности, организованы по пакетному принципу. Точно также, в виде пакетов, распространяются и любые дополнительные программы для них, создаваемые независимыми разработчиками. И потому одна из важных задач пользователя – это интеграция пакетов в свою систему. Пакеты для Fedora распространяются в формате rpm.

Формат rpm

Изобретение формата пакетов rpm и соответствующей утилиты для управления ими оказало очень большое влияние на Linux-дистрибуцию вообще. Так что надо уделить ему толику внимания.

История

Формат пакетов RPM (что тогда расшифровывалось как Red Hat Package Manager) и одноимённая утилита для манипулирования такими пакетами, способная отслеживать зависимости и сообщать об их нарушении, сыграли очень большую роль в приобщении к Linux’у широких народных масс. Правда, разрешать зависимости эта утилита не умела, да и не научилась по сей день: задача эта решается более «продвинутыми» средствами пакетного менеджмента. Но по сравнению с молчаливым пакетным инструментарием из Slackware, зависимости вообще не отслеживающим, и это было большим прогрессом с точки зрения обычных пользователей.

Происхождение системы RPM (будем понимать под этим и набор утилит, и формат пакетов, с которыми они работают) теряется во мраке веков. В первых версиях Red Hat использовалась система RPP, обеспечивающая установку пакетов одной командой, запрос информации о них, а также проверку зависимостей. Однако сборка пакетов для неё требовала существенной модификации авторских исходников, что было напряжно для майнтайнеров дистрибутива.

Параллельно раннему Red Hat некоторое время развивался дистрибутив Bogus, ныне мало кому известный. В нём имелась собственная пакетная система - PMS (Package Management System), написанная Рикардом Файтом (Rikard E. Faith). Она обладала слабым механизмом запросов информации о пакетах, а проверка их зависимостей просто отсутствовала. Но зато пакеты для PMS можно было собирать непосредственно из авторских исходников, без всякой их модификации.

В ходе подготовки 2-го релиза Red Hat Рикард Файт вместе с Дугом Хоффманом (Doug Hoffman) по контракту с компанией Red Hat написали систему PM (Package Management), вобравшую в себя лучшие особенности RPP и PMS. Хотя практически она так и не была задействована, но послужила одной из основ для RPM.

Собственно система RPM была создана Марком Юингом (одним из сооснователей компании) и Эриком Троэном (Erik Troan), основывавшихся на всех достижениях предшественников - разработчиков RPP, PMS и PM. Вариант её, подготовленный для тестовых версий второго релиза, быстроты ради был написан на Perl’е, что создавало ряд проблем, например, при загрузке с дискеты (а в те времена это было достаточно обычным способом старта Linux’а). И непосредственно к выходу релиза Red Hat 2.0 система была полностью переписана на C, база данных пакетов перепроектирована для пущей надёжности и быстродействия, а для использования функциональности RPM сторонними разработчиками была создана библиотека rpmlib. Иными словами, система RPM приобрела практически тот вид, в каком мы знаем её ныне, подвергаясь с тех пор только корректировке ошибок и косметическим доделкам.

Система RPM (то есть формат и утилита), став штатными и общедоступными в релизе Red Hat 2.0, вышедшем в сентябре 1995 года, сразу завоевали популярность и вне родительской системы. Вскоре они были использованы в Caldera Linux (позднее именовавшаяся OpenLinux), которая поначалу была точным клоном Red Hat. Вслед за тем на пакетирование в формате rpm перешёл дистрибутив Suse (генетически — потомок Slackware). Разумеется, и все последующие клоны и дериваты Red Hat, например, Mandrake, также использовали RPM.

Могу свидетельствовать как очевидец, что к рубежу 1996–1997 годов (времени моих первых экспериментов с Linux) система RPM была широко распространённой, считалась стабильно работающей и использовалась далеко за пределами родного дистрибутива.

Общие сведения

За свою долгую жизнь формат rpm претерпевал различные изменения, однако в генеральной своей линии сохранял как свои характерные черты, так и обратную совместимость вплоть до настоящего времени. Текущая его версия из числа официально поддерживаемых одноимённым проектом на настоящий момент (01.02.2011) - 4.8.1. Она используется в бессчётном числе дистрибутивов, представляющих как прямые клоны Red Hat (CentOS, Scientific Linux, Oracle Enterprise Linux), так и его дериваты пусть даже удалившиеся от прародителя, вроде Mandriva или Altlinux. Кроме того, его можно видеть даже в некоторых системах, генетически с ним не связанных (например, во всех вариантах Suse).

Параллельно генеральной версии rpm развивается и её обновлённый вариант, известный как rpm5 . Он создан Джеффом Джонсоном (Jeff Johnson), бывшим до того одним из основных разработчиков “обычного” rpm . Согласно его мнению, новая версия существенно усовершенствована по сравнению со своим предком, за что, однако пришлось заплатить отсутствием совместимости между этими двумя форматами. Поэтому rpm5 официально не поддерживается ни проектом rpm , ни одним из распространённых rpm based дистрибутивов. Он используется, насколько я знаю, только в дистрибутиве PLD и, согласно анонсу, будет задействован в релизе Mandriva 2011.1

Не смотря на то, что в перечисленных rpm-based дистрибутивах (и многих других, не перечисленных) теоретически используется один и тот же формат пакетов, на самом деле детали их устройства отличаются. Особенно это касается пакетов исходников (о которых будет отдельный разговор). Однако на этих страницах я ограничусь рассмотрением rpm-пакетов для дистрибутива Fedora. Правда, сказанное о них будет иметь силу и для RHEL, CentOS, Scientific Linux, Oracle Enterprise Linux, ASPLinux.

Номенклатура пакетов

В составе дистрибутива Fedora можно обнаружить разные виды пакетов интересующего нас формата.

Во-первых, выделяются rpm-пакеты бинарные и они же, но с исходными текстами. Как явствует из названия, первые содержат прекомпилированные компоненты дистрибутивного пакета, как то:

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

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

Распознать те и другие очень легко по их именам, образованным по определённым правилам, каковые мы рассмотрим на примере самого показательного пакета - собственно пакета rpm

Имена бинарных rpm-пакетов образованы по следующей схеме:

Rpm-4.8.1-6.fc14.x86_64.rpm

где rpm - имя пакета, 4.8.1 - номер ветки, версии и конкретного релиза пакета, 6 - номер сборки для текущей версии данного дистрибутива, fc14 - имя и версия такового (то есть, в данном примере, - Fedora версии 14), x86_64 - архитектура, под которую пакет собирался.

Имя пакета с исходниками будет похожим:

Rpm-4.7.1-6.fc12.src.rpm

Можно видеть, что отличие только в добавочном суффиксе src, символизирующего, что мы имеем дело именно с пакетом исходников, а не с прекомпилированным бинарником. И очевидно, что понятие архитектуры для исходных текстов смысла не имеет - они (теоретически) должны собираться для любой из них.

Среди бинарных пакетов также можно найти такие, которые не привязаны к какой-либо архитектуре - они опознаются по дополнительному суффиксу noarch . В их числе - сценарии на интерпретируемых языках типа Perl, Python etc, шрифтовые пакеты, документация и так далее. Например, так будет выглядеть пакет для одной из гарнитур шрифтового семейства Dejavu:

Dejavu-sans-fonts-2.30-2.fc12.noarch.rpm

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

Первый пакет содержит собственно код библиотечных функций, необходимых в любом случае; например, работу пакета rpm обеспечивает библиотечный пакет

Rpm-libs-4.7.1-6.fc12.x86_64.rpm

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

Rpm-devel-4.7.1-6.fc12.x86_64.rpm

Разобравшись с номенклатурой rpm-пакетов, можно перейти к вопросу их внутреннего устройства - то есть к собственно формату.

Устройство бинарных rpm-пакетов

Бинарный пакет rpm включает в себя два компонента. С одной стороны, это набор скомпилированных файлов, таких, как исполняемые бинарники и библиотеки, сопровождаемых необходимыми конфигами, документацией и т.д., готовый к инкорпорацию в файловую иерархию системы.

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

Компоненты rpm-пакета запаковывается в архив cpio - одно из древнейших средств архивирования в UNIX, подвергнутый компрессии. Ранее, вплоть до Fedora версии 11 включительно, это делалось посредством утилиты gzip . Начиная с 12-й версии Fedora rpm-пакты сжимаются по алгоритму LZMA, обеспечивающему много большую степень компрессии - правда, ценой времени, на неё затрачиваемого. Что для пользователя, впрочем, неудобств не доставит - потому что распаковка lzma-файлов, как это ни парадоксально, осуществляется практически с той же скоростью, что и gzip . А вот скачивание их, разумеется, происходит много быстрее, что не может не радовать обладателей “толстых” и дешёвых каналов: при этих условиях установка пакетов по Сети происходит быстрее, нежели с локальных носителей.

Вернёмся, однако, к тому, что у rpm-пакета “внутре”. Для чего сначала распакуем пакет любым стандартным средством (rpm2cpio , например, или с помощью утилиты rpm2tgz) и посмотрим, что получилось:

$ ls rpm-4.7.1-6/ bin/ etc/ usr/ var/

То есть мы видим те компоненты пакета, которые будут инкорпорированы в файловую иерархию целевой системы.

Знакомство со вторым компонентом проще всего сделать с помощью Midnight Commander. По клавише F3 (по прежнему для примера рассматривается пакет rpm) он выдаст всю метаинформацию в суммарном виде. Сначала это будет формальное описание пакета:

Name: rpm Relocations: (not relocatable) Version: 4.8.1 Vendor: Fedora Project Release: 5.fc14 Build Date: Втр 10 Авг 2010 11:43:21 Install Date: (not installed) Build Host: x86-12.phx2.fedoraproject.org Group: System Environment/Base Source RPM: rpm-4.8.1-5.fc14.src.rpm Size: 2035701 License: GPLv2+ Signature: RSA/SHA256, Срд 11 Авг 2010 05:58:10, Key ID 421caddb97a1071f Packager: Fedora Project URL: http://www.rpm.org/ Summary: The RPM package management system Description: The RPM Package Manager (RPM) is a powerful command line driven package management system capable of installing, uninstalling, verifying, querying, and updating software packages. Each software package consists of an archive of files along with information about the package like its version, a description, etc.

Смысл всех полей интуитивно понятен. Прошу только обратить внимание на поле Group: о групповой принадлежности пакета нам придётся вспомнить, когда дело дойдёт до управления пакетами с помощью системы yum .

Затем последует установочный сценарий:

Posttrans scriptlet (using /bin/sh): # XXX this is klunky and ugly, rpm itself should handle this dbstat=/usr/lib/rpm/rpmdb_stat if [ -x "$dbstat" ]; then if "$dbstat" -e -h /var/lib/rpm 2>&1 | grep -q "doesn"t match environment version | Invalid argument"; then rm -f /var/lib/rpm/__db.* fi fi exit 0

Rwxr-xr-x 1 root root 20392 Авг 10 11:42 /bin/rpm drwxr-xr-x 2 root root 0 Авг 10 11:42 /etc/rpm -rwxr-xr-x 1 root root 7424 Авг 10 11:42 /usr/bin/rpm2cpio ...

Затем — библиотечные файлы:

Rw-r--r-- 1 root root 40537 Авг 10 11:42 /usr/lib/rpm/macros drwxr-xr-x 2 root root 0 Авг 10 11:42 /usr/lib/rpm/platform drwxr-xr-x 2 root root 0 Авг 10 11:42 /usr/lib/rpm/platform/amd64-linux ...

Rw-r--r-- 1 root root 44206 Дек 7 2009 /usr/share/doc/rpm-4.8.1/COPYING -rw-r--r-- 1 root root 639 Дек 7 2009 /usr/share/doc/rpm-4.8.1/CREDITS -rw-r--r-- 1 root root 496233 Июн 11 2010 /usr/share/doc/rpm-4.8.1/ChangeLog.bz2 -rw-r--r-- 1 root root 656 Дек 7 2009 /usr/share/doc/rpm-4.8.1/GROUPS ...

И, наконец, файлы вариативные:

Drwxr-xr-x 2 root root 0 Авг 10 11:42 /var/lib/rpm -rw-r--r-- 1 root root 0 Авг 10 11:42 /var/lib/rpm/Basenames -rw-r--r-- 1 root root 0 Авг 10 11:42 /var/lib/rpm/Conflictname -rw-r--r-- 1 root root 0 Авг 10 11:42 /var/lib/rpm/Dirnames ...

Всю эту информацию можно просмотреть и по частям - зафиксировав в Midnight Commander курсор на файле

Rpm-4.7.1-6.fc12.x86_64.rpm

и нажав Enter .
Теперь мы увидим список входящих в пакет “метаинформационных” файлов:

/.. │-ВВЕРХ-│Дек 16 12:04 /INFO │ 0│Сен 21 00:00│ CONTENTS.cpio │ 0│Сен 21 00:00 HEADER │ 1185│Сен 21 00:00 *INSTALL │ 39│Сен 21 00:00 *UPGRADE │ 39│Сен 21 00:00

О содержимом файлов легко догадаться. Так, CONTENTS.cpio - полный список всех файлов и путей к ним:

Rwxr-xr-x 1 root root 20808 Sep 21 17:30 ./bin/rpm drwxr-xr-x 2 root root 0 Sep 21 17:30 ./etc/rpm ...

и так далее. Файл HEADER содержит то самое описание, которое мы только что видели через F3 , *INSTALL и *UPGRADE - исполняемые скрипты соответствующего назначения. А в каталоге /INFO лежит множество мелких файликов, из которых в итоге собирается суммарная метаинформация. Из них остановлюсь только на REQUIRENAME - это пресловутый перечень зависимостей, который для пакета rpm выглядит примерно так:

/bin/bash /bin/sh /bin/sh config(rpm) = 4.8.1-5.fc14 coreutils curl db4-utils libacl.so.1()(64bit) ...

На самом деле пакет rpm никакой файловой иерархии внутри себя не содержит. А то, что нам представляется в виде таковой — всецело заслуга Midnight Commander, который восстанавливает её в том виде, в котором она была до сборки.

База данных RPM

База данных rpm-пакетов — компонент, необходимый для функционирования системы: именно она обеспечивает возможность получения информации о пакетах, их обновления и удаления. Она создаётся при инсталляции системы в каталоге /var/lib/rpm и изменяется при каждой операции с пакетами.

База данных rpm-пакетов использует Berkeley DB — древнюю (1986 года розлива), простую (нереляционную) СУБД, однако быструю, эффективную и потому широко используемую по сей день.

Файлы базы RPM — бинарные, и даже волшебство «ночного командира» не позволит разглядеть в них что-либо удобопонятное. Так что остаётся только поверить на слово авторам документации, что

файл Packages является главным и хранит индексированные поля заголовков пакетов,
файлы Basenames, Group, Requireversion и прочие служат для оптимизации запросов к базе, а
файлы __db.001, __db.002 и так далее — содержат в себе сведения о том, какие файлы менялись и создавались при установке и удалении пакетов.

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

Утилита rpm

Ознакомившись в общих чертах с устройством rpm-пакетов, посмотрим, что же с ними можно сделать. И начнём с одноимённой утилиты, предназначенной для работы с единичными пакетами. В давние времена она была благословением и проклятием начинающих пользователей дистрибутива Red Hat, его клонов и дериватов.

Введение

Как уже было сказано, утилита rpm стала благословением пользователей дистрибутива Red Hat и всех его наследников. Ибо она освобождала их от необходимости самостоятельной компиляции: практически все разработчики из числа не брезговавших распространением своих пакетов в бинарном виде, собирали их в rpm-формате, а службы вроде http://rpmfind.net позволяли легко отыскать их на просторах Сети. Помню, в те годы имела хождение такая жизненная максима:

с помощью rpm и Инета любые дистрибутивы можно сделать близнецами-братьями за одну ночь

Однако она же оказалась и проклятием пользователей, в первую очередь начинающих: отслеживая зависимости пакетов при установке и удалении, утилита rpm отнюдь не занималась их разрешением, а только сообщала об обнаруженной крамоле, причём в достаточно неудобопонимаемой для новичка форме.

Те времена канули в Лету: наступил век пакетных репозиториев и средств для работы с ними, таких, как apt-rpm , urpmi и, наконец, yum - главный герой следующего цикла заметок. Каковые и берут на себя заботу по рутинному манипулированию пакетами. Однако утилита rpm до сих пор остаётся самым простым средством для операций с единичными пакетами, особенно не входящими в официальные репозитории. А в некоторых случаях - например, при подключении репозиториев сторонних - она может оказаться практически незаменимой.

Так что уделим толику времени знакомству с её базовыми, наиболее востребованными в повседневной жизни, функциями. Это просто краткий конспект для практического применения. Причём ориентированный на тех, кто ранее дела с rpm-based системами не имел. Тех, кто будет из зала кричать - давай подробности, авансом отсылаю к тёте Мане, она за всё расскажет.

Общая характеристика

Утилита rpm , подобно dpkg в Deb-based дистрибутивах, - лишь одна из представительниц целого семейства, разрабатываемого, вместе с одноимённым форматом, в рамках самостоятельного проекта .

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

Существует пять основных режимов использования утилиты rpm:

режим запроса (query);
режим проверки (verify);
режим установки (install);
режим обновления (upgrage);
режим удаления (erase).

Существует также режим построения пакета, но о нём мы пока говорить не будем.

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

-? , --help вывод подробной справки об использовании команды rpm (краткая справка выводится в ответ на команду без всяких опций и аргументов);
--version вывод номера версии пакета rpm ;
--quiet вывод минимума сообщений в ходе выполнения команды (обычно это только сообщения об ошибках);
-v вывод подробных сообщений о ходе выполнения команды.

Есть также несколько «внережимных» опций, используемых, в частности, для восстановления базы данных пакетов.

Аргументом команды rpm обычно является имя файла пакета; часто таких аргументов может быть несколько (в пределе — сколько угодно). В одних случаях достаточно указания краткого имени пакета — например, для нашего постоянного примера просто rpm . В других же ситуациях требуется указание полного имени, с указанием номера версии, сборки, дистрибутива, архитектуры — например, rpm-4.8.1-5.fc14.x86_64.rpm . А если файл пакета находится не в текущем каталоге, то потребуется предварить его указанием полного пути к нему, скажем /var/cache/akmods/ .

Режим запроса…

… служит для получения информации о пакете, в частности, его статусе (установлен ли он в системе). Основная опция запроса — -q (или --query), в ответ на неё последует вывод полного имени пакета:

Rpm -q rpm rpm-4.8.1-5.fc14.x86_64

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

Дополнительные опции зависят от цели запроса. Так, наличие пакета в системе проверяется следующей командой:

$ rpm -qa pkgname

где дополнительная опция -a (или --all) предписывает запрос ко всем наличным в базе пакетам. Если пакет установлен, ответом на эту команду будет

$ rpm -qa opera opera-10.00-4440.gcc4.shared.qt3.x86_64

Если нет - последует возврат приглашения командной строки.

Формальное описание пакета можно получить командой

$ rpm -qi rpm

ответом на что будет:

Name: rpm Relocations: (not relocatable) Version: 4.8.1 Vendor: Fedora Project Release: 5.fc14 Build Date: Втр 10 Авг 2010 11:43:21 Install Date: Вск 31 Окт 2010 10:28:06 Build Host: x86-12.phx2.fedoraproject.org Group: System Environment/Base Source RPM: rpm-4.8.1-5.fc14.src.rpm Size: 2035701 License: GPLv2+ Signature: RSA/SHA256, Срд 11 Авг 2010 05:58:10, Key ID 421caddb97a1071f Packager: Fedora Project URL: http://www.rpm.org/ Summary: The RPM package management system Description: The RPM Package Manager (RPM) is a powerful command line driven package management system capable of installing, uninstalling, verifying, querying, and updating software packages. Each software package consists of an archive of files along with information about the package like its version, a description, etc.

Легко видеть, что это та самая заголовочная часть (HEADER), которую мы ранее просматривали через Midnight Commander.

Дополнительная опция l позволит вытащить нам и содержимое CONTENTS.cpio:

$ rpm -ql rpm /bin/rpm /etc/rpm /usr/bin/rpm2cpio /usr/bin/rpmdb /usr/bin/rpmquery /usr/bin/rpmsign /usr/bin/rpmverify ...

Выше речь касалась получения информации об установленном пакете. Однако гораздо интересней получить сведения о пакете не установленном — на предмет нужности или не нужности его в нашем деле. И это возможно — путем добавления к -qi дополнительной опции p и указания полного имени пакета и пути к нему. А поскольку не установленный пакет, скорее всего, лежит на каком-либо сетевом источнике, то в качестве пути тут будет фигурировать URL, например:

$ rpm -qip http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/joe-3.7-5.fc13.x86_64.rpm

Что выведет точно такую же информацию, что и при запросе к локальному пакету:

Name: joe Relocations: (not relocatable) Version: 3.7 Vendor: Fedora Project Release: 5.fc13 Build Date: Срд 10 Фев 2010 09:57:06 Install Date: (not installed) Build Host: x86-03.phx2.fedoraproject.org Group: Applications/Editors Source RPM: joe-3.7-5.fc13.src.rpm Size: 1177186 License: GPLv2+ Signature: RSA/SHA256, Срд 28 Июл 2010 21:59:42, Key ID 421caddb97a1071f Packager: Fedora Project URL: http://sourceforge.net/projects/joe-editor/ Summary: An easy to use, modeless text editor Description: Joe is a powerful, easy to use, modeless text editor. It uses the same WordStar keybindings used in Borland"s development environment.

Дополнительная опция f позволяет определить имя пакета, которому принадлежит некий файл:

$ rpm -qf /usr/lib/rpm/rpm2cpio.sh rpm-4.8.1-5.fc14.x86_64

В режиме запроса возможны и ещё многие опции, с которыми при необходимости можно ознакомиться на man-странице пакета rpm .

Режим проверки…

… обеспечивает проверку целостности установленного пакета. Делается это путём сравнения его файлов с их аналогами из пакета оригинального по таким параметрам, как тип, размер, контрольная сумма (MD5), атрибуты принадлежности и доступа. Основная опция этого режима — -V ; без дополнительных опций, с указанием имени пакета, она проверяет правильность расположения его файлов в файловой иерархии.

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

5 - контрольная сумма MD5
S - размер
L - символическая ссылка
T - дата изменения файла
D - устройство
U - пользователь
G - группа
M - режим (включая разрешения и тип файла)
? - файл не удалось прочитать

Совпадающие параметры обозначаются единичной точкой. Увы, примеров привести не могу — в какой пакет не ткнусь для проверки, с ним всё оказывается в порядке. А специально портить — не хочется.

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

$ rpm -V rpm

мы на выводе увидим следующее:

Prelink: /bin/rpm: at least one of file"s dependencies has changed since prelinking S.?...... /bin/rpm prelink: /usr/bin/rpm2cpio: at least one of file"s dependencies has changed since prelinking S.?...... /usr/bin/rpm2cpio

Это означает всего-навсего, что исполняемый файлы пакета rpm после его установки подверглись процедуре предварительного связывния (prelink — что это такое, я расскажу со временем). В результате чего, разумеется, утратили идентичность со своими тёзками из оригинального пакета.

Дополнительные опции режима проверки позволяют выполнить верификацию конкретного файла:

$ rpm -Vf /usr/bin/rpm2cpio

сравнить установленный пакет с его исходным rpm-пакетом:

$ rpm -Vp path2/full_packagename

а также выполнить полную проверку всех установленных пакетов:

# rpm -Va

Поскольку вывод последней команды будет очень длинным, её целесообразно использовать в корнвейере с командой типа less или most . Можно также с помощью команды grep выявить только пакеты; содержащие расхождения с оригиналом по одному из перечисленных выше критериев. Например, командная конструкция

# rpm -Va | grep S

даст на выходе список пакетов, отличающихся от оригиналов размером, а конвейер

# rpm -Va | grep 5

выявит различия контрольных сумм.

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

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

Режимы установки и обновления…

… тесно связаны между собой. Основными их опциями являются:

-i (от install — не путать с дополнительной опцией режима запроса) установка пакета, отсутствующего в системе;
-F обновление установленного пакета до более «свежей» версии;
-U обобщённая опция установки и обновления: при её использовании установленный пакет будет обновлён, а не установленный — инсталлирован.

Важно, что сферы действия опций -i и -F строго разграничены: команда с указанием первой откажется исполняться, если в системе имеется старая версия одноимённого пакета. И наоборот — команда при второй опции даст сообщение об ошибке, если предшествующая версия в системе не установлена. Поэтому обобщённая опция -U применяется чаще всего. Очевидно, что для успешного выполнения команд с любой их этих опций требуются привилегии администратора.

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

Ранее я уже говорил, что утилита rpm не просто устанавливает пакеты, но и проверяет их зависимости. Хотя, с сожалению, не разрешает их, а только рапортует о нарушениях. Например, попытка «в лоб» установить kdebase

Rpm -ihv http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm

выдаст длиннющий список неудовлетворённых зависимостей:

Retrieving http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm error: Failed dependencies: kdebase-libs(x86-64) = 6:4.5.2-2.fc14 is needed by kdebase-6:4.5.2-2.fc14.x86_64

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

Бывают ситуации более иные: вроде бы простой пакет при попытке установки требует как зависимость другой. А тот, в свою очередь, отказывается устанавливаться, так как ссылается на отсутствие первого. Так, давеча, затеяв апгрейд одной из экспериментальных своих систем до «сыромятной» (rawhide) версии, я столкнулся с тем, что пакет fedora-release-rawhide-15-0.3.noarch.rpm ни в какую не желал устанавливаться без fedora-release-15-0.3.noarch.rpm — и наоборот.

Вот в таких-то случаях и требуется указание всех взаимозависимых пакетов в качестве аргументов одной команды:

# rpm -ivh http://URL/path2/{fedora-release-15-0.3.noarch.rpm, fedora-release-rawhide-15-0.3.noarch.rpm}

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

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

К основным опциям установки и обновления полагается ещё много дополнительных опций, но за ними, как всегда, к тёте Мане.

Режим удаления…

… часто оказывается не менее востребованным, нежели режимы установки и обновления. Впрочем, задача это не сложная, и в общем случае выполняется так:

# rpm -e pkgname

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

В случае нарушения зависимостей при удалении выводится сообщение об ошибке:

Error: Failed dependencies:

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

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

Репозитории

Утилита rpm предназначена в первую очередь для установки индивидуальных пакетов из любых источников - локальных или сетевых (например, с сайтов разработчиков), но преимущественно первых. Система же управления пакетами yum ориентирована на доступ к репозиториям пакетов, причём главным образом сетевым. Хотя и использование её с репозиториями локальными также не возбраняется.

Что такое репозиторий

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

В переводе на русский язык слово репозиторий означает хранилище — и именно его рекомендуют употреблять языковые пуристы (они же те, кто предпочитает называть себя grammar nazi ). Однако, как это обычно бывает по жизни, в народе утвердилось иное их именование — repo или, говоря по нашему, по бразильскому кириллическому, репы . Почему во множественном числе — станет понятно из дальнейшего рассказа. Ну а как синоним я предпочитаю термин хренилищще .

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

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

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

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

А теперь посмотрим, как все эти общие соображения выглядят на практике — применительно к репозиториям Fedora.

Физическая структура репозиториев

Физически репозитории Fedora - это набор вложенных подкаталогов на ftp- или http-серверах, и имеют они подчас довольно сложную и не вполне прозрачную структуру. Знание её для пользователя не обязательно - но в ряде нештатных ситуаций будет не лишним. А поскольку структура эта нигде не описана, по крайней мере, на русском языке, - уделим ей толику внимания.

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

Структура главного репозитория

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

нет, не туда, куда вы подумали в меру своей испорченности, а на наиболее быстрое зеркало. Причём именно наиболее быстрое физически и именно в данный момент — потому что это проверяется не по зональной принадлежности и прочим формальным признакам, а по отклику на всамделишний запрос. Если, конечно, установлен соответствующий плагин к yum ‘у — но об этом мы поговорим несколько позднее.

Так что, набрав в строке браузера что-нибудь типа http://download.fedoraproejct.org , наш советский пользователь окажется на сервере с URL типа http://mirror.имя_рек.ru/fedora/linux/ (а возможно, что даже и не ru вовсе). Имя этого самого имя река я изрекать не буду — полный список возможных вариантов можно увидеть здесь http://mirrors.fedoraproject.org/publiclist . И отдать предпочтение какому-то одному из них — значит, как сказал бы Шурик, проявить несправедливость к другому имя реку .

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

Итак, оказавшись на имя_рек/fedora/linux/ , мы видим следующие каталоги:

Как нетрудно догадаться, в каталоге development помещаются пакеты, находящиеся в состоянии разработки (здесь важен подкаталог /development/rawhide/ , к которому мы со временем вернёмся), в каталоге updates — недавно обновлённые. А вот каталог releases — это именно то, что нас в данный момент интересует.

12 13 14

и подкаталог test . Иногда он пуст, содержимое в нём появляется, когда от разрабатываемой ветки (той самой rawhide) отщепляется альфа-версия следующего релиза.

Продолжим карабканье по иерархическому древу. В релизном его отростке мы видим следующие подкаталоги:

Everything Fedora Live

Первый включает в себя пакеты различных версий и сборок, произведённых за время существования релиза. Первый, как следует из названия, содержит текущие обновления сборок пакетов, а последний — образы LiveCD для обеих поддерживаемых архитектур (i686 и x86_64). И о том, и о другом будет говориться своевременно. А вот по каталогу Fedora будем карабкаться дальше — тем более, что его можно рассматривать как пример устройства любого каталога на серверах проекта.

Итак, в каталоге fedora/linux/releases/14/Fedora/ можно видеть такие подкаталоги:

I386 source x86_64

Второй из них включает в себя rpm-пакеты исходных текстов (так называемые *.src.rpm), о которых также речь пойдёт отдельная. Первый же и третий содержат сборки для 32- и 64-битных архитектур, соответственно. Очевидно, что внутри они абсолютно одинаковы, поэтому их внутренности рассмотрим на примере более актуальной ныне архитектуры x86_64 .

Iso jigdo os

В первом лежат образы установочных дисков — DVD, набора CD и диска для сетевой установки (netinst), о которых речь будет в разделе про установку системы. Второй содержит файлы метаданных для jigdo (Jigsaw Download) — системы распространения больших файлов (в данном случае — образов тех же установочных дисков) и служит той же цели, что и предыдущий. Ну а в третьем, в подкаталоге Packages, собственно, и находятся искомые пакеты.

Кроме этого, в каталоге fedora/linux/releases/14/Fedora/x86_64/os/ можно видеть служебные файлы, такие, как GPG-ключи для проверки подлинности, файлы описания репозитория (в подкаталогах repodata и repoview), файлы для компоновки собственных образов загрузочных дисков (в подкаталогах images и isolinux), которые в данный момент нас не интересуют.

Что же касается содержимого каталога Packages , то оно представлено rpm-пакетами — теми, которые непосредственно поддерживаются в рамках проекта Fedora.

Структура репозитория RPMFusion

Головным репозиторием, однако, список доступных для нашего дистрибутива пакетов не исчерпывается. Существует также репозиторий для дополнительных пакетов, поддерживаемых волонтёрами в рамках самостоятельного проекта — RPMFusion .

Собственно репозиторий дополнительных пакетов находится . В нём мы видим два каталога — free и nonfree . Первый предназначен для безусловно свободных программ (в головном репозитории Fedora, кстати, только такие и имеются), второй — для программ, на распространение которых накладываются некоторые ограничения. Какие именно — к этому вопросу мы ещё вернёмся.

Внутренняя структура обоих каталогов одинакова. В них имеются подкаталоги el и fedora . Первый включает пакеты, обратно перенесённые (backports) из RHEL и нас сейчас не интересует. Второй же включает подкаталоги:

Development/ releases/ updates/

а также файлы описания репозитория.

Назначение каталогов более или менее понятно из их имён (к этому вопросу мы ещё вернёмся), так что остановимся только на каталоге releases . В нём есть подкаталоги для полудюжины последних релизов — в том числе и куда более «глубоких», нежели поддерживаемые в головном репозитории. В каждом из них мы увидим единственный подкаталог Everything . А в нём — уже привычные «архитектурные» подкаталоги:

Debug/ os/

В первом, как легко догадаться, — отладочная информация, которая нам сейчас не интересна. А вот во втором — уже собственно пакеты. В том числе и основной пакет описания репозитория — rpmfusion-free-release . Тот самый, установка которого однозначно приводит к подключению этой «репы». А в соответствующем подкаталоге каталога nonfree аналогичный пакет и будет именоваться соответственно — rpmfusion-nonfree-release .

Структура репозитория RFRemix

Пользователям оригинальной Fedora в чистом виде перечисленных репозиториев достаточно. Однако для русскоязычных наших сограждан если не обязательным, то более чем желательным является знакомство с репозиторием russianfedora.

Он расположен в одноименном каталоге по следующему адресу (насколько я знаю, пока единственному). И структура его следующая: на первом уровне вложенности идут подкаталоги

build/ с файлами описания репозиториев,
releases/ с образами установочных дисков и LiveCD, и
russianfedora/ , содержащий собственно пакеты.

В данный момент нас интересует только последний подкаталог. Он включает три подкаталога:

fixes/ , представляющий своего рода дельту между базовыми и дополнительными пакетами оригинальной Fedora, с одной стороны, и RFRemix — с другой;
free/ , предназначенный для полностью свободных пакетов проекта Russian Fedora;
nonfree/ , предназначенный для пакетов проекта Russian Fedora, распространение которых ограничено законами некоторых стран (но не нашей).

Подробнее о составе всех трёх категорий будет говориться в следующем разделе — пока же нас интересует только физическая структура соответствующих каталогов.

Она идентична: каждый из них включает подкаталоги el/ и fedora/ того же назначения, что и в RPM Fusion. В подкаталоге fedora/ , в свою очередь, выделяются подкатлоги development/ , releases/ и updates/ , а в подкаталоге releases/ — каталоги для номеров главных (мажорных) релизов, в настоящий момент — с 10-го по 15-й.

В каталоге каждого релиза мы видим единственный подкаталог Everything/ , включающий подкаталоги для обеих поддерживаемых архитектур — i386/ и x86_64/ , и подкаталог source/ для пакетов с исходными текстами. Ну и наконец этажом ниже лежат подкаталоги debug/ и os/ понятного (то есть того же, что и в RPM Fusion) назначения.

Дополнительные репозитории

Описанных выше репозиториев большинству пользователей хватит почти на все случаи жизни. Однако в ряде случаев возникает и необходимость в дополнительных пакетах, в официальные «репы» по тем или иным причинам не включённых — возможно, пока не включённых. Типичный на сегодняшний день пример — браузер Chromium: его не найти ни в RPM Fusion, ни в Russian Fedora.

И тут на помощь придёт в первую очередь репозиторий Fedora People — он предназначен именно для пакетов, собираемых независимыми майнтайнерами. По содержанию он не перекрывается с офоциальным и «полуофициальными» репозиториями, однако, насколько мне известно, его пакеты тестируются на совместимость с ними, и потому могут использоваться безбоязненно.

Структура репозитория Fedora People предельно проста: по указанному адресу вы увидите множество каталогов, имена которых повторяют названия содержащихся в них пакетов. Внутри любого из них будет серия подкаталогов для поддерживаемого диапазона релизов — разного в разных случаях. А подкаталог каждого релиза содержит три стандартных подкаталога — i386/ , SRPMS/ и x86_64/ , заключающих в себе файл описания репозитория и собственно файлы пакетов.

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

В статьях и обзорах, посвящённых Fedora, можно встретить упоминания о многих других дополнительных репозиториях для этого дистрибутива — их список можно видеть, например, в ссылках с того же ATrpms . Однако практически все они потеряли актуальность. Одни (Livna, Freshrpms, Dribble) ныне объединены в составе RPM Fusion. В других содержатся пакеты для весьма старых версий Fedora. Ну а репозиторий Tigro стал основой для Russian Fedora — хотя ленивым обладателям старых версий Fedora он будет полезен и сам по себе.

Логическая организация репозиториев

Физическая структура репозиториев Fedora, особенно головного, выглядит довольно запутанной. К счастью, пользователю, как уже говорилось, практически не приходится иметь с ней дело. В 99 случаях их 100 ему достаточно ориентироваться в логической их организации, которую мы сейчас и рассмотрим.

Классификация программ

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

Вторая категория называется nonfree — название не очень удачное, поскольку вызывает ассоциации со всякого рода варезом, контрафактом или необходимостью каких-либо платежей при их использовании. На самом деле это совершенно не так. В категории nonfree объединены исключительно бесплатные (в смысле free beer ) и легально распространяемые программы. Однако на распространение их накладываются те или иные ограничения. И потому с точки зрения FSF они не могут называться истинно свободными (в смысле free word ).

С одной стороны, в категорию nonfree попадают программы, распространяемые только в бинарном виде — без всяких ограничений, но и без исходных текстов. Примерами таких программ являются фирменные драйвера устройств, например видеокарт и сетевых устройств, или проигрыватель флэш-роликов от фирмы Adobe, браузер Opera, некоторые шрифты и игры.

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

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

Основные репозитории

Для начала рассмотрим основные репозитории, которые автоматически подключаются при установке RFRemix.

Главный, официально поддерживаемый, репозиторий проекта Fedora содержит только пакеты категории free . И поэтому называется просто и незатейливо — fedora , с расшифровкой в виде номера версии и целевой архитектуры, например: Fedora 15 — x86_64.

А вот в составе RPMFusion имеются как полностью свободные, так и «несвободные» пакеты. А потому в нём обособляются два репозитория — rpmfusion-free и rpmfusion-nonfree .

Внутреннее устройство Russian Fedora ещё «богаче» — в нём имеется целых три репозитория:

russianfedora-fixes — это пакеты, которые имеются в репозиториях fedora или rpmfusion , однако представленные версиями либо более новыми, либо адаптированными к нашим условиям и кириллическому окружению; пакеты этого репозитория не разделяются на свободные и несвободные;
russianfedora-free — полностью свободные пакеты, отсутствующие в репозиториях fedora или rpmfusion ;
russianfedora-nonfree — «не совсем свободные», в указанном на прошлой странице смысле, пакеты, также отсутствующие в репозиториях оригинальной Fedora.

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

updates - для собственно Fedora;
rpmfusion-free-updates - для Rpmfusion-free;
rpmfusion-nonfree-updates - для rpmfusion-nonfree;
russianfedora-fixes-updates — для Russian Fedora Fixes;
russianfedora-free-updates — для Russian Fedora Free;
russianfedora-nonfree-updates — для Russian Fedora Nonfree.

Кроме того, каждому из основных репозиториев соответствуют специальные ветки отлаживаемых и тестируемых пакетов: fedora-debuginfo и fedora-updates-testing , соответственно — для основного репозитория и образованные по образу и подобию — для всех остальных.

И, наконец, существует ветка репозиториев rawhide . Она содержит пакеты следующей, разрабатываемой в настоящий момент, версии дистрибутива и, естественно, включает в себя те же самые репозитории, что и в ветках стабиольных релизов: fedora-rawhide , rpmfusion-free-rawhide , rpmfusion-nonfree-rawhide и так далее.

Сказанное выше относилось к репозиториям бинарных пакетов для архитектур i386 и x86_64 . Однако есть ещё и репозитории исходных текстов — fedora-source , rpmfusion-free-source и так далее.

Что делать после установки Fedora 21 — руководство по настройке

Процесс загрузки и установки операционной системы Fedora 21 не вызывает затруднений у большинства заинтерисованных пользователей и ИТ специалистов, тем не менее будет описан в отдельной статье для «самых маленьких» и начинающих.

Стоит отметить, что в данной ОС семейства Linux используется большое число изменений и обновленных приложений. Свежеустановленная система не идеально подходит для ежедневного использования. Сейчас выполним настройку Fedora 21, а именно, самые основные и базовые операции, чтобы получить «более полированный» рабочий стол.

Обновление системы

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

Добавление репозитория RPM Fusion

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

su -c ‘yum localinstall —nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm’

Установка плагиров и основных программ

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

sudo yum install gstreamer1-plugins-good gstreamer1-plugins-good-extras gstreamer1-plugins-ugly gstreamer1-plugins-base gstreamer1-plugsins-base-tools gstreamer1-plugins-bad-freeworld gstreamer1-plugins-bad-free gstreamer1-plugins-bad-free-extra gstreamer1-libav

Установка архиватора unrar:

yum install unrar p7zip p7zip-plugins

Установка плагина Adobe Flash Player состоит из нескольких шагов:

sudo rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm

Импортируем ключ:

sudo rpm —import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux

Выполняем инсталяцию плагина:

sudo yum install flash-plugin

Медиа

Установка VLC Media Player:

Установка музыкального плеера Audacious:

sudo yum install audacious

Установка музыльного редактора Audacity:

sudo yum install audacity

Установка Gnome Music Player:

sudo yum install gnome-music

Браузеры

На вкус и цвет — все браузеры разные, представлю вашему вниманию процесс установки самых популярных браузеров в ОС Fedora 21. По умолчанию, используется Mozilla Firefox.

Установка последний версии Google Chrome состоит не нескольких этапов, сначала устанавливаем репозитории (источник для получения пакетов и программ):

sudo gedit /etc/yum.repos.d/google-chrome.repo

Далее введите следующий текст в редакторе текста , который будет открыт после ввода указанной команды:

name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/$basearch
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

Теперь выполняем установку Google Chrome:

sudo yum install google-chrome-stable

Установка Lightweight Midori Browser:

sudo yum install midori

Графика

Inkscape

sudo yum install inkscape

Blender

sudo yum install blender

Gwibbe

sudo yum install gwibber

Pidgin

sudo yum install pidgin

Установка торрент-клиента qbittorren

sudo yum install qbittorrent

Установка альтернативного торрент-клиента:

sudo yum install deluge

Для все остальных загрузок рекомендуется к использования плагин DownloadThemAll для браузера.
Установка Dropbox:

sudo gedit /etc/yum.repos.d/dropbox.repo

name=Dropbox Repository
baseurl=http://linux.dropbox.com/fedora/20/
gpgkey=http://linux.dropbox.com/fedora/rpm-public-key.asc

Выполнение операции установки:

sudo yum install nautilus-dropbox

Первая часть руководства по настройке операционной системы Fedora 21 завершена. Подписывайтесь на обновления сайта, чтобы получать новости и продолжение циклов статей:

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

В этой статье мы рассмотрим самые важные действия после установки Fedora 24. Только после выполнения всех этих шагов ваша система будет полностью готова к использованию. Этот список можно продолжать до бесконечности, но мы рассмотрим только самое важное.

1. Полное обновление системы

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

2. Настройка имени компьютера

Для того чтобы настроить имя компьютера, которое будет отображаться в терминале и других программах мы будем использовать утилиту hostnamectl. Она может устанавливать имена хоста разных видов. Чтобы посмотреть текущее имя хоста наберите:

Изменить имя хоста можно такой командой:

hostnamectl set-hostname "losst"

3. Настройка статического IP адреса

На серверах очень часто используются статические IP адреса. Одно из первых, что нужно сделать после установки fedora, это настроить сеть. Если у вас такой вариант, откройте и отредактируйте файл конфигурации eth0 или enp2s0 в папке /etc/sysconfig/network-scripts/:

vi /etc/sysconfig/network-scripts/ifcfg-enp0s3

Вот настройки которые нужно добавить:

BOOTPROTO - протокол получения адреса, нам нужно static
ONBOOT - автоматическое подключение
IPADDR - нужный вам ip адрес
NETMASK - маска вашей сети
GATEWAY - шлюз, через который компьютер будет выходить в интернет
DNS1 - DNS, с помощью которого нужно разрешать доменные имена.

Например, это может быть такая конфигурация:

BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.1.1
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=202.88.131.90
DNS2=202.88.131.89

Чтобы применить изменения перезагрузите службы сети:

systemctl restart network.service

Чтобы посмотреть изменения вы можете воспользоваться командой:

4. Добавить репозиторий RPMFusion

Настройка fedora после установки должна включать настройку дополнительных репозиториев. Некоторых пакетов нет в официальных репозиториях RHEL и Fedora. Но вы можете установить эти пакеты из репозитория RPMFusion. Здесь есть как проприетарные, так и свободные пакеты. Для добавления репозитория выполните команду:

sudo rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-24.noarch.rpm

5. Установить Gnome Tweak

По умолчанию окружение рабочего стола Gnome может выглядеть не так, как бы мы этого хотели. Утилита GNOME Tweak поможет настроить множество параметров внешнего вида Fedora 24, панель, пространство рабочего стола и многое другое.

Вы можете установить ее открыв центр приложений, набрав в поиске Gnome Tweak и нажав кнопку Установить:

6. Подключить онлайн аккаунты

Fedora 24 позволяет получить доступ к онлайн-аккаунтам непосредственно из системы. Вы можете их настроить во время установки. Но если вы этого не сделали, то это всегда можно сделать в настройках, на вкладке Персональные, онлайн аккаунты:

7. Установка расширений Gnome

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

Затем установите командой:

rpm install teamviewer.rpm

Выводы

Это еще далеко не все действия после установки Fedora 24 которые нужно сделать, но здесь собрано главное. Если что-то было упущено, напишите в комментариях.

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

Проект Linux Fedora является тестовой базой для коммерческого дистрибутива Red Hat Enterprise Linux: перед включением новых функций в RHEL они обязательно появляются в Fedora . Изменения, предназначенные для Red Hat Enterprise Linux, сначала проходят тестирование в данном дистрибутиве.

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

Новое в версии Linux Fedora 13

Полная интеграция с PackageKit . Теперь программа Brasero может автоматически устанавливать отсутствующие кодеки GStreamer , если они необходимы для записи аудио-CD. File-roller устанавливает программы, необходимые для обработки различных форматов архивов;

Использование в качестве менеджера фотографий Shotwell вместо Gthumb и F-Spot. Shotwell - легкая в обращении свободная программа управления фотографиями для окружения рабочего стола GNOME ;

Работа с Simple Scan. Данная программа сканирования предназначена для подключения сканера и выполнения сканирования изображения или документа в подходящем формате;

Автоматическая установка драйверов печати. При подключении параллельного или USB-принтера PackageKit выполняет поиск и устанавливает драйвер, соответствующий производителю и модели.