Linux book/Install and configure
Материал из eSyr's wiki.
Содержание |
Установка и настройка ПО
Поиск ПО: где брать?
Одной из насущных проблем сразу после установки операционной системы является установка и настройка ПО для решения своих задач. Отсюда возникает вопрос: какое ПО есть и где его брать? Самый простой (но и наименее информативный) ответ на этот вопрос — apt-cache show *. Подходить к поиску ПО (как и к любой другой задаче) можно по-разному. Рассмотрим некий виртуальный пример, который, тем не менее, довольно часто встречается в реальной жизни:
Приходит человек, говорит: «У меня вот Photoshop, а что у вас в Линуксе есть?». Ему, как правило, отвечают: «А у нас есть GIMP». После чего человек уходит, через некоторое время возвращается и говорит, что в GIMP нет ничего, что ему надо. Это самый плохой подход — подход от названия.
Более сложный и обстоятельный подход — подход от инструмента. Он популярен у людей, которые в определённой мере ориентируются в предметной области. В данном примере, поскольку Photoshop — программа, связанное с графикой, можно рассмотреть инструменты, связанные с графикой. Графики бывает несколько видов: векторная и растровая. Векторная графика, в свою очередь, делится на плакатную, диаграммы и макетную. В плане плакатной графики — Inkskape, Xara Xtreeme, Kontour и ещё добрый десяток различных приложений. Для работы с диаграммами есть Dia, Xfig, OpenOffice.org Draw. Печатные макеты — читаем на Википедии, узнаём, что не надо редактировать программы на PostScript (это язык такой, на котором даже вирус можно написать). Что касается растровой графики, то есть программы для обработки фотографий — GIMP, Krita. Есть аналоги MS Paint — их бесконечно много, один хуже проще другого, например, можно вспомнить Tux Paint, Kolourpaint. Ещё есть пакетные преобразователи, где надо писать скрипты, которые преобразуют картинки, ярким примером подобного инструмента является ImageMagick. Можно вспомнить ещё про 3D-графику — Blender, POV-RAY. В итоге вываливаете человеку 200 названий, человек уходит, возвращается, говорит, что Линукс это ужасно круто, но он не может делать то, что ему надо.
Наконец, третий подход — подход от задачи. Сажаете человека и начинаете распрашивать, что ему нужно. Оказывается, что у него есть фотооппарат и ему нужно управлять каталогом фотографий, назначать им теги, убирать красные глаза, и так далее. Решение в этом случае появляется сразу — Digicam, он всё это умеет. Возможно, ещё понадобится gfoto2, если нужен специфический драйвер для камеры.
Таким образом, получаем три подхода:
- Подход от названия
- Подход от инструмента
- Нужен подход от задачи
Обычно пользуются первым, реже вторым. Но правильный — третий. Сначала необходимо определить круг решаемых задач. После определения круга задач возникает вопрос, где искать инструменты для их решения (то есть, программы). Откуда вообще берутся программы под Linux? Надо дать достаточно точный и полный ответ, ибо обычно ответ звучит как «лежат на диске» или «скачал из сети». Рассмотрим то, где на самом деле берут ПО для Linux.
Дистрибутив и репозиторий
Дистрибутив — скомпонованный и отлаженный набор подготовленных к использованию программ. Эти программы взяты из некоего большего по размерам, чем сам дистрибутив, хранилища. То есть, существует хранилище, где имеется большое количество ПО (на самом деле таких хранилищ, репозиториев, несколько), и его часть используется для создания в дистрибутива. В этом хранилище находятся одни из самых последних версий большого количества программ, и, если человек какую-то программу в нём не находит, он, при достаточной квалификации может добавить недостающую программу (найденную другими путями, которые рассмотрены далее) в хранилище. При этом, поскольку полное тестирование всего добавляемого и обновляемого ПО не проводится, то возможна несовместимость между различными приложениями и невозможность использования отдельных программ на некоторых конфигурациях, как следствие, комфортно использовать ПО из репозитория (а не из дистрибутива) можно только при достаточной квалификации.
Когда принимается решение о создании очередного дистрибутива, то создаётся замороженная копия репозитория, в которой обновления входящих в неё программ производятся только для исправления критических ошибок. Эта замороженная копия тестируется, отлаживается. В последствии на основании этой проверенной копии делается собственно дистрибутив. В результате, если ставить программу из дистрибутива, то ничего нештатного в идеале не может произойти.
Другие варианты
Не исключена ситуация, при которой нужного приложения в используемом репозитории не оказывается. Так как хранилищ существует несколько, то при отсутствии искомой программы в том хранилище, на котором базируется используемый вами дистрибутив, можно попробовать поискать в других репозиториях. Где ещё можно попытаться найти интересующее ПО: существуют специализированные сайты, такие как SourceForge.net, где разработчикам предоставляются средства для ведения разработки, а пользователям — средства поиска по имеющимся проектам. Кроме этого, существуют независимые сайты разработчиков, где программы могут распространяться как в виде исходных текстов, так и в собранном виде.
Рецепт: как искать программы под Linux
В результате выстраивается некая схема поиска ПО:
- Искать в дистрибутиве
- Искать в репозитории
- Искать в чужом дистрибутиве.
- Поиск по специализированным сайтам (sourceforge, savanna, freshmeat)
- Поиск в google на предмет сайта разработчика
- Если всё это проделали, и результатов нет, то не значит, что приложения не существует. Очень хороший источник информации — сообщество.
- Официальные информационные ресурсы (документация, сайт, wiki)
- Списки рассылки
- IRC, форумы
- Сообщество на последнем месте (несмотря на свою достаточно высокую эффективность) потому, что до этого на поиск тратятся только собственное время, а в сообществе тратят своё время другие люди.
Установка ПО
Установку программ в Linux лучше делать в рамках своего репозитория, но можно выделить ряд других способов установки ПО:
- Установка из чужого дистрибутива/репозитория
- Сборка из исходных кодов
- Бинарный инсталлятор
Перед тем, как подробно рассматривать каждую из указанных возможностей, определим ряд понятий, которые нам при этом потребуются.
FHS
В Linux существует строгая иерархия каталогов (File Hierachy System, FHS), которая описывает структуру каталогов и их семантику. Подробно FHS описан в учебнике Курячего Г. В. «Операционная система Linux». Так, в соответствии с FHS, существует 4 места для ПО, 2 каталога для разделяемых библиотек, 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, размещает их в соответствии с их предназначением в соответствующие каталоги в ФС.
Пример размещения некоторых типичных файлов абстрактной программы:
- /usr/bin/prog — исполняемый файл программы
- /usr/share/doc/prog/README — файл-описание программы
- /usr/share/man/1/prog.tgz — страница руководства по программе
И это всё один программный продукт.
В Linux достаточно аккуратно проделано разделение прав доступа, и без ведома пользователя к ним другой пользователь доступа не имеет. Тем не менее, процессы, запущенные под суперпользователем игнорируют их. В частности, установка ПО обычно делается под root'ом (поскольку при этом создаются файлы в каталогах, которые для простых пользователей на запись закрыты), и установку специфических программ, кроме как в свой каталог, обычный пользователь, в отличие от root'а, осуществить не может,.
Пакет
Одной из основополагающих единиц в процессе работы с хранилищем программного обеспечения является пакет.
Пакет — файл, содержащий всё необходимое для установки и удаления программного продукта.
То есть, для установки программного продукта достаточно установить пакет, и после этого он должен заработать. Для удаления программного продукта, соответственно, достаточно удалить пакет.
Рассмотрим подробно, что представляет собой пакет:
- Пакет — архив, содержащий файлы программного продукта. Причём архив этот вполне известной структуры. Достаточно ли просто его разархивировать? Нет.
- Пакет обеспечивает регистрацию программного продукта в системе. Должны быть зарегестрированы список устанавливаемых файлов, а также некая метаинформация, такая как имя пакета, его версия, и так далее.
- Пакет обеспечивает первичную настройку программного продукта. То есть, запуск программы, специфичной для данного пакета — некоего установочного скрипта. Таких скриптов может быть несколько,
В связи с этим возникает ряд вопросов:
- Как разрешать зависимости одних пакетов от других?
- Как разрешать конфликты, то есть, те случаи, когда при попытке установить файл из архива оказывается, что такой файл есть, и создан он не пользователем, а другим пакетом?
Зависимости
Перед рассмотрением проблемы зависимостей дополнительно введём понятие разделяемой библиотеки.
Разделяемая библиотека — самостоятельный набор библиотек, используемый другими программными продуктами.
Преимущества использования разделяемых библиотек:
- При использовании библиотек программы занимают меньше места, так как библиотека одна, а не статически связана с каждым программным продуктом, её использующим
- Библиотека загружается в память один раз
- Для разделяемой библиотеки не нужно даже иметь место в swap — swap'ом этого файла будет файл на диске
- Если библиотека имеет ошибку, то её быстро найдут, поскольку она используется во многих программах, и, как следствие, интенсивно тестирутеся
Но, при всех достоинствах разделяемых библиотек встаёт задача разрешения зависимостей. Разделяемые библиотеки в пакет не входят. Каждая группа библиотек находится в отдельном пакете. И перед установкой программного продукта нужно установить все библиотеки, которые используются им, то есть, удовлетворить его зависимости. Получается палка о двух концах: с одной стороны, использование разделяемых библиотек упрощает и ускоряет разработку; с другой стороны, усложняется порядок установки программ — необходимо скачать и установить в правильном порядке всё дерево (точнее, ацикличесикй орграф) зависимостей. В любом дистрибутиве Linux для целей автоматизации удовлетворения зависимостей существует две программы — установщик и менеджер пакетов, которые подробно рассмотрены далее.
Кроме этого существуют непрямые зависимости. Может быть такая ситуация, что для работы вашего продукта другой программный продукт не нужен, но с ним может быть связана некая некритичная функциональность. Например, для почтового вебсервера не обязательно нужен почтовый сервер, поэтому установка почтового сервера не должна требоваться, но его можно оформить как рекомендованный пакет, поскольку первое без второго используется редко.
Конфликты
Иногда при установке очередного пакета может возникнуть так называемый конфликт.
Конфликт — ситуация, при которой файлы из разных пакетов должны иметь одинаковые абсолютные имена.
Пример конфликта: пакеты с различными вариантами vi: vi, vim-minimal, mvi пытаются установить бинарный файл /usr/bin/vi.
Существует метод, позволяющий разрешать конфликты — альтернатива. При этом для каждого пакета выбираются свои уникальные имена (в данном примере — /usr/bin/vi.original, /usr/bin/vim, /usr/bin/mvi), кроме того, будет файл с конфликтным именем (/usr/bin/vi), но он будет символической ссылкой на один из файлов, которые боролись за данное имя. То, куда будет указывать символическая ссылка, решается при помощи отдельного механизма, например, с назначением некоторых весов пакетам и ссылания на файлы того пакета, у которого вес больше.
Конфликты версий
о_О
Установщик пакетов
Как сказано выше, единицей ПО считается пакет. Пакет обладает массой свойств — это не только распаковка, но и регистрация в системе, запуск некоторых сценариев при установке/удалении. Пакеты друг от друга зависят по причине того, что разделяемые библиотеки нужны нескольким пакетам. Существует понятие конфликта, и конфликты необходимо разрешать (для этого авторам пакетов достаточно договориться и переименовать конфликтующие файлы, и использовать механизм альтернатив). Работой с отдельным пакетом занимается установщик.
Установщик — утилита, которая позволяет управлять отдеьным пакетом. Сюда входят установка и удаление, проверка пакета на различные свойства, просмотр различий в версиях пакета, проверка зависимостей, и так далее.
Менеджер пакетов
По традиции, установщик также используется для сборки пакета. Но это не столь важно, сколь другая особенность установщика: он работает с одним файлом, а для управления всеми доступными пакетами необходим использовать диспетчер (менеджер) пакетов, который работает сразу с хранилищами пакетов. В итоге, задача диспетчера состоит в построении графа зависимостей, разрешения вопроса о получении недостающих пакетов (скачивания их из дооступных источников) и установке недостающих пакетов.
!!! Тут переход от определений к тому, откуда ставить, и что за это будет
Установка ПО из своего дистрибутива
В рамках дистрибутива всё будет хорошо.
Установка ПО не из своего дистрибутива
Установка из хранилища
Когда вы обращаетесь к хранилищу. Может случиться ситуация, что версии программ и уже все поменялось. В этом случае можно попробовать следующий способ: помимо rpm есть src.rpm, в котором всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводится к выполнению новых команд:
- Скачать src.rpm
- Собрать. Образуется бинарный rpm
- Бинарный rpm встанет со всеми зависимости
Установка из другого репозитория
Проблема с чужим репозиторием может заключаться в том, что разделяемые библиотеки могут находиться в пакетах с другими именами.
Проблема с пакетами из чужих репозиториев в том, что они не обновляются, что не позволит с определённого момента обновлять зависимые библиотеки, а также пакеты, которые от них зависят, и так далее.
Сборка из исходных кодов
Существует два основных способа: сборка с использованием вручную написанного makefile и с использованием autotools. Основная проблема в том, что если активно пользоваться программой, то при каждой новой версии выполняется configure-make-make install, в результате чего возникает большое количество версий одних и тех же библиотек, удалить их нельзя, потому что их может ещё кто-то использовать, кроме того, могут возникать ситуации, когда старые библиотеки используются вместо новых.
Установка бинарника
Одна из проблем с бинарными файлами заключается в том, что они могут использовать свои библиотеки определённой версии, что никак не контролируется в рамках репозитория. Выходов два: сборки под разные дистрибутивы средствами разработчика или статическая сборка всех используемых библиотек. Стоит отметить, что в последнем случае гораздо больше вероятность, что запустится бинарник, чем пакет из другого дистрибутива.
В общем случае не рекомендуется пользоваться бинарными инсталляторами. Правильно сделанные инсталляторы выполняют установку в соответствии с FHS, то есть, производят установку одним из нижеуказанных способов:
- В самом лучшем случае он сделает следующее: в /opt/ (в котором ставятся программы вне дистрибутива) будет /opt/(program name)/{bin, lib, ...} Единственная проблема перед разработчиками --- заставить запускаться бинарник оттуда. Поэтому даже в этом случае он создаст в /usr/bin/ специальный файл для запуска приложения (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету).
- Чуть менее хороший вариант — /usr/local/{bin, lib, ...}. /usr/local/ — то, что живёт только на вашей системе и должно быть сохранено после удаления системы и установки новой. Чем это плохо — конфликт имён. Чем это лучше — /usr/local/ обычно есть в PATH и установщик больше нигде файлы создавать не будет.
И то, и другое должно происходить от имени суперпользователя, что потенциально порождает проблемы (как и в любом другом случае установки ПО, но данный усугубляеется тем, что нельзя проконтролировать процесс). Как альтернатива, существуют директории ~/bin и ~/.local, в которые можно произвести инсталляцию, не имея прав root'а, но отнюдь не всегда эти пути прописаны в PATH.
Резюме
При возможности (в частности, в случае использования пакетов из других хранилищ или сборки из исходных текстов) собирать пакеты и добавлять их в используемый репозиторий. Это позволит избежать проблем, связанных с зависимостями и обновлениями.
Настройка
Это довольно нетривиальный и важный вопрос, рассмотрим основные вопросы, с этим связанные:
- Пространство имён. Необходимо настраивать всю систему целиком, как следствие, должен быть такой способ именования этих настроек, чтобы в нём было легко ориентироваться. Например, единая древовидная структура — плохой пример организации
- Гибкость формата представления настроек. Например, если жёстко задана древовидная структура, то в такой структуре отпадает организация в виде графа (tags),или в виде программы; они тоже могут быть штуками, которые управляют системой. То есть в рассматриваемом пространстве имён необходимо предусмотреть возможность нахождения данных произвольной структуры
- Удобный инструментарий для чтения и модификации. В случае с настройкой разумно рассматривать критерий человекоприемлемости: кусок данных можно назвать человекиприемлемым, если его можно написать с нуля.
Текстовые конфигурационные файлы
В Linux до сих пор это решается старым, UNIX-way, способом: любой файл, с которым возможна работа пользователя — человекочитаемый текст. Опишем, как это выглядит:
- Пространство имён — файловая система. Зачем множить сущности (дерево), если дерево уже есть. В /etc/ лежат файлы, необходимые для настройки остальной части системы
- Каждый файл принадлежит пакету, и названия в etc соответствуют названиям пакетов. Это способ локализации настроечной информации
- Гибкость представления. файлы настройки могут иметь произвольные синтаксис и семантику: пары ключ-значение, XML-файлы, скрипты на шелле или любом другом языке.
- Чтение и модификация. С одной стороны, есть графические программы настройки (подробнее про них далее). В каком-то смысле они удобные. Но хорошо графический интерфейс делает настройку графического интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфигурационный файл, учитывая его произвольные синтаксис и семантику? Поскольку мы договорились, что конфигурационные представляются в виде текста, то у нас есть способ работы с ними — текстовый редактор (в случае, если не стоит задач автоматизации работы с оными). Но редактор конфигурационных файлов должен обладать не совсем таким набором возможностей, каким должен обладать редактор текста. При редактировании литературного текста обычно необходимо уметь проверять орфографию, писать и писать, и потом в конце, возможно, переставить пару абзацев. Тогда как при работаете с конфигурационными файлами элементы разметки и другие синт. единицы служат объектами оперирования, то есть, типичный способ работы состоит в том, что находится необходимая секция, в которой хранится свойство, после чего оно изменяется. Поэтому редактор, который редактирует файлы настроек, должен уметь быстро производить поиск, ручную и авотматизированную модификацию. Типичный пример: заменить имя хоста во всех конфигурационных файлах. Почему бы это не оформить в виде парсера? Некоторые задачи можно решить вручную, но некоторые задачи можно решить автоматизированно, и лучше, чтобы таких задач было как можно больше. И в таких случаях нужны процессоры обработки текста.
Яркими примерами инструментов для работы с текстовыми файлами вообще и с конфигурационными файлами в частности являются такие программы, как vim и emacs. Но перед тем, как ими пользоваться, необходимо сначала научиться ими пользоваться. В случае же, если нужно работать сразу, то есть такие программы, как nano, mc, kate, evim.
Конфигураторы
Не смотря на наличие развитых средств по работе с текстовыми файлами конфигурации, имеются графические средства конфигурирования. Причины этого явления понятны: человек привык выбирать «панель управления», и там есть «всё», что можно настроить. Понятно, что там явно не всё и если бы показали всё, то он впал бы в подавленное состояние духа. Что пользователь видит, когда открывает окно настройки: он видит графического плана утилиты, которые что-то настраивают. Они бывают 4 сортов:
- Настройка каких-то графических приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик логично сделать графический. В большинстве графических приложений есть пункт настройка, но есть настройщики и в виде отдельной программы.
- Не столь однозначный вариант, когда программы настройки того же KDE имеют средства для настройки системы. Пример: является ли системной настройка частоты обновления и разрешения экрана? Казалось бы, нет, с другой стороны этот параметр точно была в ведомости администратора сиситемы, так как необходима правка конфигурационного файла графической подсистемы. В том же KDE Control Center или Gnome можно увидеть ряд подобных настроечных утилит, что есть следствие парадигмы «системы в рамках рабочего стола». Аналогично — работа со звуком. Идея в следующем: разработчики, которые делают рабочий стол считают, что разрешение — характеристика рабочего стола, поэтому должны быть инструменты для настройки, если же нет, то нет. Поэтому не обязательно, что эти инструменты из графической подсистемы обязаны заработать.
- Настройка системы в масштабе дистрибутива. Если создатели дистрибутива решили облегчить жизнь пользователю, то создаётся конфигуратор который объявляется системным (альтератор в альте, в SuSE Yast). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно будут тестировать. Правда, обычно в этих конфигураторах не так много всего и есть. Но это связано со спецификой дистрибутива.
- Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы — CUPS и Samba. Почему эти конфигураторы выделяются отдельно — конфигуратор к таким мощным системам разработчик дистрибутива просто не будет создавать и поддерживать.
- Существуют специальные standalone настроечные среды (наиболее характерным примером является webmin), которые тоже предназначены для того же самого — настройки системы. Есть мнение, что необходимость в таких конфигураторах отпадает. Проблема в том, что разрабатывать и поддерживать подобные конфигураторы очень сложно, вплоть до того, что выясняется, что чем универсальнее тот инструмент, который управляет всем и вся, тем меньшим количеством настроек, которое является пересечением, он управляет. То есть, подобные конфигураторы становятся специфическими либо для дистрибутива, либо для задачи.
- Существует ещё ряд вещей, например, web-движки, которые опять же настраиваются через web-интерфейс.
Тем не менее, это не позволяет настраивать всю систему, только определённую её часть, и, как следствие, не решает задачу настройки в общем случае.
