Linux: Полное руководство — страница 30 из 98

7.4.1. Ядро и поддержка устройств

Ядро ОС Linux может быть собрано как монолитное или модульное. Монолитное ядро — это один большой файл, в который включены сразу все возможности, заложенные в данную версию ядра. Оно без всяких изменений находится в оперативной памяти от запуска до остановки системы.

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

Раньше, в первых версиях ядра Linux, механизм работы с модулями не был предусмотрен, и ядра тех времен содержали в себе код драйверов для всех поддерживаемых устройств. Такое решение нельзя было назвать рациональным: невозможно предусмотреть, какие устройства будут установлены у конечного пользователя, даже если включить в состав ядра драйверы всех известных устройств. Кроме того, даже если нужное устройство (скажем, звуковая плата Yamaha) ядром распознается, то драйверы остальных устройств того же назначения будут впустую занимать оперативную память. Поэтому, начиная с версии 2.0, ядро Linux поддерживает модульную организацию и из дистрибутива, основанного на ядре 2.x, ставится в модульном виде.

При этом, кроме файла образа ядра /boot/vmlinuz-<версия_ядра>, ставится каталог с модулями /lib/modules/<версия_ядра> и файл образа загрузки /boot/initrd-<версия_ядра>. Образ загрузки содержит все модули, необходимые для того, чтобы ядро загрузило систему. Без этих модулей оно неспособно подключить системный раздел жесткого диска и прочитать файлы. Другие модули подключаются к ядру сценариями загрузки при старте системы.

Перед тем, как устанавливать новое оборудование, нужно убедиться, что ядро поддерживает ваше устройство. Если это не так, нужно пересобрать ядро, включив поддержку нового устройства. Можно со стопроцентной уверенностью сказать, что ваше ядро будет поддерживать вашу сетевую плату RTL8139 или любую другую, совместимую с NE2K PCI. А вот о поддержке USB-модема или принтера заранее ничего сказать нельзя: пользуйтесь диалоговым конфигуратором ядра (п.7.2.3.1) или загляните в базу поддерживаемого оборудования по адресу http://www.mandrakelinux.com/en/hardware.php3. Ничего, если у вас другой дистрибутив, например, основанный на Red Hat: основные устройства те же. Современное ядро версии 2.6 поддерживает очень много устройств, и проблемы могут возникнуть только со следующими их типами:

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

2. Win-принтеры — комментарии те же, что и для Win-модемов. Разработчики дешевых устройств, как правило, стараются сэкономить на драйверах для менее распространенных ОС.

3. Экзотические TV- и FM-тюнеры.

7.4.2. Утилиты для работы с модулями

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

Рис. 7.6. Связь модуля с ядром

Утилиты, обеспечивающие загрузку, выгрузку и просмотр загруженных модулей, собраны в пакет, который для ядер 2.4.x называется modutils, а для ядер 2.6.x — module-init-tools. Не смешивайте эти пакеты: одноименные утилиты из них конфликтуют друг с другом.

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

♦lsmod — просмотр списка загруженных модулей;

♦modinfo <имя_модуля> — получение информации о загруженном модуле;

♦insmod <имя_модуля> — загрузка модуля;

♦rmmod <имя_модуля> — выгрузка модуля;

♦depmod — нахождение зависимостей между модулями;

♦modprobe — загрузка модуля с аргументами и теми модулями, от которых он зависит.

Из сценария инициализации системы вызывается именно modprobe. Эта команда руководствуется конфигурационным файлом /etc/modprobe.conf, в котором могут быть записаны аргументы, передаваемые загружаемым модулям, определены псевдонимы модулей и указаны команды, которые нужно выполнить перед стандартной процедурой загрузки модуля или вместо нее. В дистрибутивах, основанных на ядре 2.4, этот файл называется /etc/modules.conf и имеет несколько более сложный синтаксис. В совсем старых версиях Linux (до дистрибутива Red Hat Linux 7.0) вместо этого файла использовался /etc/conf.modules.

7.4.3. Kudzu — утилита для автоматического определения устройств

В Linux для автоматического определения устройств используется специальная утилита kudzu, названная в честь китайской лианы — злостного сорняка. В дистрибутивы, основанные на Linux Mandrake, вместо нее может входить утилита harddrake. Задача этой утилиты состоит в том, чтобы определить, какие устройства установлены, и добавить в файл /etc/modprobe.conf (как бы он ни назывался в вашем дистрибутиве) команды загрузки модулей ядра с драйверами для этих устройств.

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

Напоминаю, что отключить автоматический запуск служб можно с помощью диалогового конфигуратора (см.п.7.1) system-config-services или drakxservices, в зависимости от дистрибутива.

Если нужно передать драйверу нового устройства дополнительные параметры, отредактируйте вручную файл /etc/modprobe.conf.

7.4.4. Настройка установленных устройств

Настройка устройства обычно выполняется с помощью диалогового конфигуратора устройств соответствующего типа. Например, для настройки принтера можно запустить system-config-printer в дистрибутивах Fedora, redhat-config-printer в дистрибутивах Red Hat, printerdrake в дистрибутиве Mandrake.

Если вы не знаете точного названия нужного конфигуратора, вам поможет функция автозаполнения командной строки (п.2.1.4.7): имена многих конфигураторов начинаются одинаково, с «system-config» («redhat-config») или «drak». Если подходящий конфигуратор таким способом не нашелся, командой which определите каталог, в котором находятся найденные конфигураторы, поройтесь в нем командой ls *conf* и man <утилита_похожая_на_нужную>.

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

7.5. Установка программного обеспечения

В ОС Windows установка новых программ происходит просто: достаточно запустить setup.exe, ввести серийный номер, каталог для установки и нажать на кнопку «Далее». После этого вы можете поступить так. как рекомендует Microsoft: «откиньтесь на спинку стула и подождите, пока программа установки все сделает за вас».

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

7.5.1. Установка из исходных текстов

Бесплатное распространение исходных текстов программ — именно то, что делает Linux уникальной операционной системой и составляет одно из Величайших Достижений Человечества. Поэтому традиционный способ распространения приложений под Linux — это архивы исходных текстов (в просторечии — тарболлы).

Обычно имя файла, содержащего такой архив, имеет двойное расширение; например, tar.gz или tar.bz2. Это означает, что данный файл получился в результате работы сначала архиватора tar (Таре Archive, по первоначальному назначению — работе с ленточными накопителями), а потом компрессора gzip или bzip2. Чтобы распаковать архив, нужно применить сначала декомпрессор gunzip или bunzip2, после чего разархивировать его командой tar.

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

Формат команды tar:

tar [ключи] [файл_архива] [архивируемые файлы и/или каталоги]

Подробные сведения о ключах команды tar ищите на man-странице, я перечислю только самые употребительные:

♦с (create) — создать архив;

♦x (eXtract) — извлечь файлы из архива;

♦t (lisT) — показать содержимое архива;

♦v (verbose) — выводить на консоль подробный отчет о своей работе;

♦f — работать с файлом, а не ленточным накопителем;

♦z — применить фильтр-компрессор при создании архива или декомпрессор при распаковке.

Архивный файл обычно содержит дерево каталогов, которое после распаковки будет создано в вашем текущем каталоге, или, по случайной небрежности создателя архива, — несколько деревьев и файлов россыпью: в этом случае каталог для распаковки вам нужно создать вручную. Таким образом, первый шаг при установке из исходных текстов пакета program3.14.tar.bz2 — распаковка — выглядит так:

$ bunzip2 program3.14.tar.bz2
$ tar tvf program3.14.tar # проверьте, есть ли объемлющий каталог
$ ^tv^xv # оболочка bash превратит это в команду tar xvf program3.14.tar

Следующий шаг — собственно установка. Перейдите в распакованный каталог (обычно он называется < имя_пакета-версия > ) и прочитайте все README-подобные файлы, которые там найдете. Обычная процедура установки состоит из трех этапов:

1. $ ./configure # помните, что текущего каталога в $РАТН нет?

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

2. $ make

Собственно компиляция и сборка.

3. $ make install

Установка собранных программ пакета, конфигурационных файлов и справочных страниц в каталога, указанные в Makefile. Обычно исполняемые файлы помещаются в каталог /usr/bin, а man-страницы — в /usr/man, но после этапа конфигурирования ничто не мешает отредактировать Makefile вручную.

После этого можно, прочитав приложенную к пакету документацию, запустить программу.

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

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

7.5.2. Установка из бинарных пакетов

Как это делается и что для этого нужно

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

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

В мире Linux известны два формата бинарных пакетов: RPM от компании Red Hat, используемый не только в клонах Red Hat, но и в других популярных дистрибутивах: Mandrake, SuSE, ASPLinux, ALTLinux, Black Cat, и DEB, разработанный для Debian Linux и применяемый в его потомках: Knoppix, Corel Linux, Lindows. Пакеты дистрибутива Slackware — это просто сжатые архивы .tgz, не поддерживающие зависимостей. От архивов исходных текстов они отличаются только тем, что в них находятся заранее скомпилированные программы.

Набор утилит для установки, конфигурирования, удаления и ведения базы пакетов определенного формата называется системой управления пакетами. Наиболее распространены системы:

♦ RPM — менеджер пакетов формата RPM;

♦ DPKG — система управления пакетами DEB;

♦ APT — менеджер пакетов, поддерживающий автоматическое разрешение зависимостей, разработанный для Debian и заимствованный RPM-дистрибутивами.

На сегодняшний день самым распространенным в бывшем СССР средством управления пакетами является RPM, на котором я остановлюсь подробнее.

Менеджер пакетов RPM

Первоначально название программы RPM расшифровывалось как Red Hat Package Manager, но в соответствии с соглашением GNU о рекурсивном именовании (GNU's Not Unix) сейчас оно читается как RPM Package Manager. Это открытая пакетная система, позволяющая создавать пакеты из исходного и двоичного кода, так что двоичные файлы легко установить и сопровождать, а исходный код легко собрать. Система также поддерживает базу данных обо всех установленных пакетах и входящих в них файлах.

Пакеты формата RPM — это файлы с расширением .rpm. В имени файла обычно присутствуют название и версия приложения, выпуск пакета и платформа, для которой он собран. Например, для пакета software-3.0-2.i386.rpm: 3.0 — это версия программы software, 2 — выпуск пакета, i386 — платформа Intel 386. Обратите внимание на разницу между версией программы и выпуском пакета: номер версии назначается автором программы и характеризует ее саму, а номер выпуска — сборщиком пакета и характеризует этот пакет. В некоторых случаях, даже если программное обеспечение не изменилось, бывает необходимо его переупаковать.

Самыми «универсальными» пакетами являются пакеты, рассчитанные на архитектуру Intel 386. Собранная таким образом программа должна работать на любом процессоре Intel, начиная с 80386DX (или совместимого с ним). А вот если у вас процессор 80486, пакет, рассчитанный для работы с архитектурой 80586 (Pentium), скорее всего, не установится в вашей системе. Обычно для процессоров архитектуры CISC (с набором команд x86) используются следующие обозначения:

♦ i386 — Intel 80386DX;

♦ i586 — Intel Pentium (MMX), AMD K5 (K6);

♦ i686 — Intel PPro, Celeron, PII, PIII, PIV.

Узнать о своем процессоре можно по команде uname -а.

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

$ rpm -i <пакет>.rpm

Установку можно производить не только с локального диска, но и по протоколу FTP:

$ rpm -i ftp://somehost.domain/pub/package.rpm

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

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

$ rpm -е <пакет>

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

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

Для пропуска проверки зависимостей нужно использовать ключ --nodeps. Например, у вас установлен агент отправки почты (MTA — Mail Transfer Agent) postfix, а вы хотите установить программу того же назначения sendmail, которая с ним конфликтует. Просто так удалить пакет postfix вы не сможете, потому что он нужен многим почтовым клиентам. Удаляйте его командой:

$ rpm -е --nodeps postfix

После такого удаления нормальная работа других программ, использующих MTA, невозможна, поэтому вам сразу же нужно установить программу sendmail или другой агент MTA.

Ключ -U служит для обновления программ. Я рекомендую использовать его и при установке программ, потому что если устанавливаемый пакет у вас уже стоял, то будет произведено его обновление, а если нет, то будет просто установлен новый пакет:

$ rpm -Uhv <пакет>

Просмотреть все установленные пакеты можно с помощью команды:

$ rpm -qa | less

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

$ rpm -qa | grep <пакет>

Просмотреть общую информацию о пакете можно с помощью команды:

$ rpm -qi <пакет>

а информацию о файлах, которые установит этот пакет:

$ rpm -ql <пакет>

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

$ rpm -qf <файл>

Графические менеджеры пакетов

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

Существуют и графические (под X Window) реализации менеджера пакетов — например, для оконной среды KDE разработан kpackage, для GNOME — gnorpm, аналогичный по своим функциям. Какую из этих программ использовать — дело вкуса и привычки (я вообще обхожусь одним rpm).

Скажу несколько слов о программе kpackage (рис. 7.7).

Рис. 7.7. Просмотр установленных пакетов

В функции программы kpackage входит:

1. Установка и удаление пакетов;

2. Получение сведений о пакете;

3. Проверка зависимостей пакета;

4. Поиск файлов и пакетов в базе RPM.

Вы можете установить пакет со своего жесткого диска, с инсталляционного компакт-диска или по протоколу FTP. Для установки пакета выберите в меню команду File→Open и введите путь (или URL) к каталогу с пакетами. Открывать подкаталоги можно и в окне выбора пакетов (рис. 7.8). Выбрав пакет, нажмите OK и в появившемся окне установки (рис. 7.9) закажите режим установки. Поставьте флажок Test, если вы хотите только проверить зависимости пакета, не устанавливая его.

Рис. 7.8. Выбор пакета для установки

Рис. 7.9. Проверка зависимостей пакета

Для поиска установленных пакетов и входящих в них файлов служат команды File→Find Package и File→Find File.

Apt: Debian-совместимый менеджер пакетов

Система управления пакетами программного обеспечения APT была разработана для Debian Linux, но впоследствии заимствована многими Red Hat-совместимыми дистрибутивами. В сам Red Hat и его потомки (Fedora Core) эта система не включена, но включена, например, в состав ALT Linux, и ее можно скачать из репозитория Сизиф http://sisyphus.ru/srpm/apt/get.

Для управления пакетами используется программа apt-get. Формат ее вызова:

$ apt-get [ключи] [команды] [пакеты]

Самые полезные команды перечислены в таблице 7.4.

Команды программы apt Таблица 7.4

Команда	Назначение
update	Используется для синхронизации файлов описаний пакетов с их источником, который указан в файле /еtс/аpt/sources.list
upgrade	Используется для обновления установленного пакета до новейшей версии, доступной в источнике. Может также использоваться для обновления всех установленных в системе пакетов. Новые пакеты при этом не устанавливаются. Перед этой командой обязательна должна быть выполнена команда update
dist-upgrade	Более «интеллектуальная» версия команды upgrade. Кроме установки новых версий пакетов, она также проверит изменившиеся зависимости между новыми версиями пакетов и попытается разрешить конфликты в пользу более важных пакетов
install	Установка пакета. Если источник, из которого вы собираетесь устанавливать этот пакет, перечислен в файле источников, то в качестве имени пакета нужно указывать только имя упакованной программы
remove	Удаление пакетов
check	Используется для диагностики нарушенных зависимостей между пакетами
clean	Очищает локальное хранилище полученных файлов пакетов. Перед установкой пакеты копируются из источника в локальное хранилище, а оттуда потом устанавливаются. Пользуйтесь этой командой время от времени для освобождения места на диске

В отличие от системы rpm, которая только докладывала о неразрешенных зависимостях, предоставляя вам справляться с ними самому, программа apt-get пытается разрешить зависимости самостоятельно. Для этого она пользуется файлом /etc/apt/sources.list, в котором перечислены источники пакетов (каталоги и FTP-архивы), к которым она обращается за необходимыми пакетами. Раскомментируйте в нем нужные строки и добавьте свои.

При установке группы пакетов с помощью apt-get будьте внимательны. Обычно для установки группы пакетов используются символы шаблона «?» и «*». Если нет пакетов, имена которых совпадают с указанным шаблоном, то этот шаблон будет рассматриваться как выражение POSIX. В этом случае, если вы указали шаблон а*, то будут установлены ВСЕ пакеты, имена которых содержат букву «а», а не только те, которые начинаются на эту букву. Это же касается и команды remove.

Из ключей apt-get полезными для вас будут -f и -d. Ключ -f требует попытаться исправить нарушенные зависимости, а при указании ключа -d пакеты только скачиваются из источника, но не устанавливаются. Ключ --no-upgrade, указанный при установке группы пакетов, запрещает обновлять те из них, что уже установлены. Еще одна полезная, но опасная возможность — ключ --force-yes, принуждающий программу не задавать вопросов, выполняя потенциально разрушительные действия. Иногда она действительно необходима.

Для установки пакета не по сети, а с дистрибутивного компакт-диска предназначена команда apt-cdrom.

7.5.3. Установка из пакетов, содержащих исходный код

Иногда в пакетах RPM находятся не откомпилированные версии программ, а их исходный код. Признаком этого является слово «src» вместо названия архитектуры. Для установки такого пакета введите:

$ rpm -iv <пакет>.src.rpm

Менеджер пакетов распакует исходные тексты в каталог Red Hat: по умолчанию это /usr/src/redhat, но вы можете установить другой каталог директивой topdir в конфигурационном файле /etc/rpmrc. В подкаталог SOURCES будут распакованы исходные тексты и заплатки (патчи) к ним, в подкаталог SPECS — spec-файлы, содержащие инструкции по прикладыванию заплаток и последующей сборке. Чтобы собрать программу, выполните команды:

$ cd /usr/src/redhat/SPECS
$ rpm -bp <пакет>.spec

Явление патча (заплатки — мы же на русском языке говорим) очень распространено в мире открытого кода, поэтому я скажу о нем здесь. Допустим, кто-то нашел и исправил ошибку в каком-нибудь известном пакете. Исправление может заключаться в двух строках кода, так что же — выкладывать в общий доступ исправленные исходники целиком? Нет, он распространяет заплатку, которую желающие могут приложить сами. Заплатка представляет собой текстовый файл, содержащий список отличий исправленного кода от исходного.

Такой список в стандартном виде генерирует утилита diff с ключами -uNr. Чтобы его приложить, нужно перейти в корневой каталог дерева исходного кода пакета и выполнить команду

$ patch -р0 <<файл_заплатка>
# < - это знак перенаправления ввода

Ключ -p указывает, сколько отделенных «/» частей нужно отщипнуть от путей к файлам, подлежащим исправлению (вдруг каталог пакета у автора заплатки назывался иначе?).

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

$ ./configure
$ make
$ make install

7.6. Клонирование и восстановление системы