Редактирование: UNИX, осень 2007, 09 лекция (от 30 ноября)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

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

[[UNИX, осень 2007, 08 лекция (от 23 ноября)|Предыдущая лекция]] | [[UNИX, осень 2007, 10 лекция (от 07 декабря)|Следующая лекция]]

'''Официальная страница''': <br />
'''Аудиовариант''': http://esyr.org/lections/audio/uneex_2007_winter/Linux_07_11_30.wav

Не проговорили про серверный софт. У лектора спрашивали про то, какие программы для фаерволла есть под линукс. Раскрытие этого момента тоже не помешало привернуть. Ибо тут линукс для новенького, а сервер для новенького это ...

== Установка софта под Линукс ==

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

Откуда вообще берутся программы под Линукс. Надо дать достаточно точный ответ, ибо обычно это звучит как «лежат на диске» или «скачал из сети». У такого подхода есть неприятное побочное свойство: есть какая-то ОС, вы скачиваете программный продукт из неизвестного места. Вот эти ребята, авторы программного продукта, в курсе, что у вас на машине? Как они могут обеспечить работоспособность программы в вашем окружении? Отсюда растёт проблема...

=== Дистрибутив и репозиторий ===
Засунули диск --- установили из диска; нажали кнопку --- скачалось с сайта. Надо понимать, что практически все современные большие дистрибутивы --- подготовленные к использованию программы, взятые из большего дистрибутива. То есть, вот существует большое количество ПО, и часть его лежит в дистрибутиве. Есть большое хранилище СПО, которое содержит кучу всевозможных программных продуктов, пригодных для использования, которым пользуются пользователи дистрибутива.

Чтобы пояснить: есть копания АльтЛинукс, которая делает деньги помощью дистр. АльтЛинукс. Есть АльтЛинукс тим, и эта тим содержит репозиторий, называемый Сизиф. Этот самый сизиф --- конгломерат программных продуктов условно всегда последней версии. Всякий раз, когда какому-то конкретному человеку понадобится программа более свежая или отсутствующая в сизифе, то, если это сознательный член альтлинукс тим, то он её собирает и выкладывает в сизифе. Надо понимать, что эти пакеты оттестированы частично. Понятно, что оно оттестировано только в окружении того, кто это собирал. После обновления видеодрайверов карточки интел, в которой исправлены 160 ошибок, перестала работать карточка на рабочей машине в альте, оказалось, что она неподдерживаемая, но за счёт взаимоуничтожения ошибок,раньше работала. По картинке хорошо видно, что размер этого хранилища больше, чем объём дистрибутива (Сизиф --- третий по размерам после дебиана и федоры). Пользоваться этим на рабочей системе могут только квалифицированные ребята, однако, учитывая особенности команды, это несложно.

Может случиться так, что при обновлении одного продукта другие работать перестанут (до тех пор, пока их не пересоберут или не обновят). Это нестабильное хранилище, то, что там что-то не работает --- обычная ситуация. В какой-то момент АльтЛинукс принимает решение выпустить дистрибутив. Как это делают: берётся Сизиф и делается заморозка. Делается замороженная копия, в которой не позволено изменять версию, если только она не содержит исправление критических ошибок. Результатом такой политики заморозки становится то, что большинство программ из числа используемых становятся намного более стабильными. Вот тогда-то компания говорит «всё», что мы можем брать и выбирать нужные нам программы для нужных нам целей, оформлять их нужным образом и таким образом делать из этого программный продукт.

=== Другие варианты ===
Лектор специально нарисовал кусочек дистрибутива вне хранилища, поскольку существует часть дистрибутива, которая не входит на полных правах, например, обработанные кувалдой программы (мц, в который вбита поддержка юникода). Эти программы лежат в замороженном дистрибутиве и потом выбрасываются. В некоторых дистрибутивах инсталлятор является несвободным, например в АСП, связанная с инсталляцией под виндовз. Компании выгодно держать одну ветку, из которой нарезаются разные дистрибутивы. Если ставить программу из дистрибутива, то ничего нештатного в идеале не может произойти.
* Если ставите программу из ветки, то возможны мелкие неприятности. 
* Если есть ПО в сизифе и нет в ветке.
* Собрать самому. Может практически любой компьютерно-грамотный, благо примеров много.
* Бинарник. Последний вариант. Ибо непонятно, как он собран, и есть много причин, по которым он может не заработать.

Половину оставшегося времени посвятим дистру+ветке.

=== О каталогах ===
Лектор не знает, говорил ли он про это, но он ещё раз говорит: в Линуксе достаточно аккуратно проделано разделение прав доступа, и без ведома пользователя к ним другой пользователь не имеет доступа. Тем не менее, процессы под рутом чихать хотели на них. И установка делается под рутом. Для простого пользователя на запись открыты только ~ и /tmp, а некоторые закрыты и на чтение, и установку специфического ПО, кроме как в свой каталог, пользователь не может, а рут может.

В линуксе существует строгая иерархия каталогов (FHS), которая описывает какие есть каталоги, и для чего они нужны. Почитайте FHS, почитайте учебник лектора. Существует 4 места для ПО, существует 2 каталога для разделяемых библиотек, существует 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, раскидывает их по дереву.

Типичная структура:
* /usr/bin/prog
* /usr/share/doc/proc/README
* /usr/share/man/1/prog.tgz
И это всё один программный продукт.

=== Пакет ===
Теперь сведём всё это воедино и выстроим понятие пакета. Вводим понятие пакета:

Пакет --- файл, содержащий всё необходимое для установки и удаления программного продукта.
* Пакет --- архив. В отличие от системы, в которой нет иерархии каталогов, этот архив имеет понятную структуру. Это архив вполне известной структуры. Достаточно ли просто его разархивировать? Нет.
* Регистрация в системе.
* Первичная настройка.
Этого на самом деле недостаточно. А в случае, если эти файлы уже есть? Конфликт.

Разделяемая библиотека.
* При использовании библиотек программы занимают мало место
* Библиотека загружается в память один раз
* Для такой штуки не нужно даже своп заводить --- свопом этого файла будет файл на диске.

* Если библиотека имеет ошибку, то её быстро найдут

* Зависимости. Разделяемые библиотеки в пакет не входят. Каждая группа библиотек лежит в отдельном пакете. И перед установкой программного продукта нужно установить все его зависимости. Палка о двух концах. С одной стороны, очень упрощает разработку; усложняет оно порядок установки программ --- необходимо скачать всё дерево (ацикличесикй орграф) зависимостей. В любом дистре линукс существует две программы --- программа-установщик и менеджер пакетов. В частности, в качестве установщика используется rpm, а в качестве установщика --- apt. Очень важная штука для  понимания того, что такое дистрибутив.

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

* Конфликты. Пакеты называются по-разному (vi), но файлы одинаковые. Есть метод --- альтернатива --- который позволяет избежать конфликтов. Будет vi, но будет ещё файл vi.original, и там будет несколько файлов, и за имя vi побеждает тот, у кого вес больше.

Кроме этого существуют непрямые зависимости. Может быть такая ситуация, что для работы вашего продукта другой программный продукт не нужен. Например, для почтового вебсервера нужен почтовый сервер --- нет, но это ситуация редкая. Поэтому установка почтового сервера требовать или нет? По-хорошему надо, но это рекомендованный пакет. <i>(vvk: веб-интерфейс может быть размещён на отдельном хосте, ovz-контейнере, etc, так что в данном случае такая зависимость скорее вредна чем полезна ;))</i> По принципу нестрогих зависимостей была устроена документация в альте.

В рамках дистрибутива всё будет хорошо.

Когда вы обращаетесь к хранилищу, может случиться ситуация, что уже все поменялось. В этом случае можно попробовать следующий способ: помимо rpm есть src.rpm, в котором всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводитя к выполнению новых команд:
* Скачать src.rpm
* Собрать. Образуется бинарный rpm
* Бинарный rpm встанет со всеми зависимости

Рассказ про us army lab

Важная вещь: откуда берутся пакеты. Существует хранилище (указанное в /etc/apt/sources.list), которое в сумме даёт граф зависимостей, их можно как-то сравнивать и производить обновления.

Против чужих пакетов в репозитории:
* Чужие пакеты --- может перестать работать обновление
* Сборка. Если хотите активно пользоваться программой, то скачали, conf-make-make install, потом ещё раз скачали... В результате, 16 версий библиотеки, удалить их нельзя, потому что может их ещё кто-то использовать, начинают находиться старые библиотеки вместо новых. Поэтому надо класть в сизиф собранные пакты.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2007%2C_09_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_30_%D0%BD%D0%BE%D1%8F%D0%B1%D1%80%D1%8F%29

Редактирование: UNИX, осень 2007, 09 лекция (от 30 ноября)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 59: / Строка 59: @@
 Вернёмся к бинарнику. Теперь понятно, почему скачанный бинарник может не заработать. Потому что кроме того, что там непонятно какие зависимости, каких версий... Поэтому делают сборки под разные дистрибутивы. Или делают статическую линковку. Поэтому гораздо больше вероятность, что запустится бинарник, чем чужой rpm.
-* Конфликты. Пакеты называются одинаково (vi), но файлы разные. Есть метод --- альтернатива --- который позволяет избежать конфликтов. Будет vi, но будет ещё файл vi.original, и там будет несколько файлов, и за имя vi побеждает тот, у кого вес больше.
+* Конфликты. Пакеты называются по-разному (vi), но файлы одинаковые. Есть метод --- альтернатива --- который позволяет избежать конфликтов. Будет vi, но будет ещё файл vi.original, и там будет несколько файлов, и за имя vi побеждает тот, у кого вес больше.
 Кроме этого существуют непрямые зависимости. Может быть такая ситуация, что для работы вашего продукта другой программный продукт не нужен. Например, для почтового вебсервера нужен почтовый сервер --- нет, но это ситуация редкая. Поэтому установка почтового сервера требовать или нет? По-хорошему надо, но это рекомендованный пакет. <i>(vvk: веб-интерфейс может быть размещён на отдельном хосте, ovz-контейнере, etc, так что в данном случае такая зависимость скорее вредна чем полезна ;))</i> По принципу нестрогих зависимостей была устроена документация в альте.