29.08.2007

Создание дистрибутива Linux

Текст обновлен 27.09.07.

За последние годы многие страны делали громкие заявления о создании национальных операционных систем на основе Linux. Прошли годы, но никто из них так и не преуспел. Самую громкую неудачу потерпел Китай. Цель данного документа – дать обзор основных «компонентов», из которых создается дистрибутив Linux, сделать некоторые оценки насчет стоимости подобного проекта и выгоды от него, описать основные подходы к его реализации.

Часть 1. Что такое "Мой Личный Linux"?

Итак, если говорить о типичном дистрибутиве Linux, то что лежит в его основе? Какие основные “компоненты” делают архив программных пакетов дистрибутивом?

  1. ОГРАНИЧЕНИЯ. Никогда и никаким образом невозможно включить в дистрибутив все открытое ПО, существующее на свете. Поэтому при создании дистрибутива необходимо ориентироваться на определенную аудиторию и на определенные задачи. Отталкиваясь от этого, можно определить, что должно войти в дистрибутив, а что останется за его рамками.

  2. ПОЛИТИКА. Исходя из целевой аудитории необходимо определить политику развития и выбрать те версии программ, которые отвечают вашим потребностям. Включать ли в дистрибутив «новейшие» программы или «проверенные временем» - это полностью зависит от вашей аудитории. Например, Red Hat Enterprise Linux ориентирован на корпоративный сектор, поэтому его политика - «новейшие из стабильных»; Ubuntu ориентирован на домашние компьютеры и его политика - «новейшие» пакеты и т.д..

  3. СИСТЕМА СБОРКИ. Основой для превращения разрозненных программ в дистрибутив служит система управления пакетами. После того, как политика определила, что включать в дистрибутив, система сборки определит, как это сделать. Стандартом LSB (Linux Standard Base) является система RPM. Тем не менее, DPKG или еще какие-либо системы также могут быть вариантами.

  4. ПРАВИЛА. Необходимо сформулировать правила и четко следовать им. “Чистый” open source очень гибок. Это означает, что все правила, которым будет подчиняться ПО с составе дистрибутива, необходимо определить самостоятельно. В частности, это относится к тому, куда устанавливать ПО и библиотеки, где и в каком виде хранятся файлы настроек и т.д.

Часть 2. Пятый элемент.

Таким образом, все выглядит несложно. Необходимо только сделать некоторое количество рутинной работы – выбрать “нужные” версии “нужного” программного обеспечения, “нужным” образом его собрать в “нужные” пакеты. Технически это очень просто, и именно по этой причине многие создают свои дистрибутивы.

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

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

Отсюда возникает «пятый элемент», о котором большинство забывают:

  1. ДОПОЛНЕНИЕ К ТЕХНОЛОГИИ. Ключевой вопрос при создании эффективной Linux-компании – каково ВАШЕ дополнение? Что вы предлагаете своим клиентам? Чем вы отличаетесь от всех остальных?

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

Часть 3. Информация к размышлению.

  1. НЕУПРАВЛЯЕМЫЕ ПАКЕТЫ. Вы можете включить в дистрибутив ПО, на развитие которого никак не влияете. Давайте возьмем для примера типичный дистрибутив, состоящий из примерно 3000 пакетов. Сколько разработчиков работают над ними? Тысячи, а скорее даже десятки тысяч. А теперь задайтесь вопросом – сколько из них будут работать для вас? Если ответ меньше чем хотя бы «сотни» - вы явно не лидер. Вы не определяете развитие «своего» продукта. Вы, конечно, можете изобрести велосипед еще раз, создать неплохой «Еще один дистрибутив», но кому это надо? Кто будет заинтересован в продукте, который не может определить свою собственную стратегию развития?

  2. ПОДДЕРЖКА 3-ГО УРОВНЯ. Для обеспечения адекватной поддержки вам необходимо наладить постоянный контакт с сообществом разработчиков. А сделать это можно только активно участвуя в разработке и тем самым зарабатывая себе авторитет. Без этого ваша поддержка будет крайне ограниченной. Разумеется, можно нанять десяток человек и организовать call-центр. Но такая служба поддержки не сможет решить хоть сколько-нибудь сложную проблему, требующую вмешательства в код. В этом случае ваш дистрибутив никто никогда не установит на важные системы, потому что ему нельзя доверять.

  3. ЧЕЛОВЕЧЕСКИЕ РЕСУРСЫ. Для того, чтобы создать ведущий дистрибутив, недостаточно как-нибудь участвовать в разработке. Невозможно нанять 500 любых разработчиков и стать лидером, потому что эти люди до данного момента не участвовали в каких-либо проектах. Для того, чтобы определять развитие продуктов, необходимо иметь с своем штате «ключевых» разработчиков. Но большинство этих людей уже работают в крупных корпорациях, таких как Google и Red Hat. Таким образом, после того как вы наймете несколько сотен разработчиков, вам придется очень постараться, чтобы они вошли в команды разработки ключевых проектов хотя бы в ближайшие 3 года. Мы сейчас не говорим о том, чтобы возглавить эти проекты, неплохо будет, если они хотя бы войдут в число основных разработчиков. Особая история – разработчики ядра. Они необходимы в команде, если мы говорим о серьезном дистрибутиве, и их сложнее всего найти. И не забывайте – вам придется платить им все эти годы.

  4. СЕРТИФИКАЦИИ. До тех пор, пока вы не подниметесь на определенный уровень, вы не станете частью «экосистемы». Дело в том, что операционная система сама по себе – одна из наименее привлекательных вещей в мире. Без ПО под нее она не стоит вообще ничего. А так как вы не являетесь ведущей компанией, то назовите хотя бы одну причину, по которой независимым разработчикам, таким как Oracle, IBM, SAP и т.д. стоит прикладывать усилия и поддерживать свои приложения на вашем дистрибутиве? Для них гораздо рациональнее работать с признанным корпоративным стандартом, таким как, например, Red Hat. Точно так же обстоит дело с поставщиками оборудования. Вам потребуется как завоевать определенную техническую репутацию, так и занять заметную часть рынка, прежде чем станет возможным сотрудничать с ведущими компаниями.

Часть 4. Создание дистрибутива «революционным» способом.

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

Давайте оценим, во сколько минимально обойдется этот процесс, если выполнять его «революционно», в одну стадию. В качестве примера успешной Linux-компании мы возьмем Red Hat. Относится к Red Hat можно по разному, но Red Hat – это признанный мировой стандарт в области корпоративного Linux. Также мы сделаем оптимистичное предположение, что вы успешно пройдете все этапы, уложившись в намеченные сроки.

В Red Hat около 700 разработчиков, которые создают около 10% кода, входящего в итоге дистрибутив. Так как мы ставим цель стать сильным дистрибутивом, но не обязательно лидером, то мы можем ограничиться 500. Ниже опускаться уже просто опасно – можно потерять контроль над продуктом.

Типичный квалифицированный разработчик стоит около $3000 в месяц. Мы не будем здесь подсчитывать налоги, стоимость инфраструктуры и т.д. - при желании вы можете добавить эти расходы самостоятельно.

Как упоминалось выше, потребуется некоторый срок, прежде чем разработчики начнут в достаточной степени влиять на проекты, в которых они участвуют. Таким образом мы получаем некоторое «мертвое время», в которое компания уже работает и требует денег на содержание, но еще не является значимым игроком на рынке. Оптимистичная оценка этого времени – 3 года. Таки образом, это «мертвое время» обойдется как минимум в $54 000 000. При этом нет, вообще говоря, никакой гарантии, что после этого компания заработает.

На этой стадии, пожалуй, стоит задать себе вопрос – готовы ли вы потратить $55 000 000 на работу, которая УЖЕ сделана, не имея при этом НИКАКИХ гарантий, что в итоге получится хоть что-то новое и значимое?

Кроме того, существует множество рисков, которые невозможно строго учесть – в конце концов, сообщество может не принять ваш дистрибутив лишь потому, что им не понравится ваша политика или логотип. К тому же, мир появление еще одного дистрибутива явно не изменит. Таким образом, затраты на то, чтобы стать «вторым лучшим» оказываются велики, а выгода весьма сомнительна.

План действий.

Основные этапы создания дистрибутива «революционным» способом:

  1. Определить, что же будет вашим дополнением к технологии – лучший сервис, более удобный интерфейс, поддержка решений? На этом этапе важно не сделать типичной ошибки – не делать основной особенностью дистрибутива лишь его “национальность”. Этим вы ничего не добавите, а лишь отнимете. Основное преимущество open source – его открытость, порождающая очень быстрый темп инноваций. Постановка любых границ лишит ваш продукт этого преимущества.

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

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

Основные проблемы.

Хотя описанный выше подход и может привести к успеху в конечном итоге, он имеет два существенных недостатка:

  1. Крайне высокий риск провала на начальной стадии. Практически невозможно гарантировать успех столь масштабного проекта при его старте «на пустом месте». Необходимо обучить огромное количество специалистов – инженеров поддержки, разработчиков и т.д. Что более важно и сложно – необходимо интегрировать всю огромную инфраструктуру, создаваемую с нуля, в огромное количество процессов взаимодействия, имеющих мировой масштаб.

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

Часть 5. Создание дистрибутива «эволюционным» способом.

Альтернативой описанному выше подходу может быть другой – «эволюционный», лишенный указанных недостатков.

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

План действий.

Основные этапы создания дистрибутива «эволюционным» способом:

  1. Достигнуть договоренности о сотрудничестве с одной из ведущих компаний, имеющей налаженные схемы взаимодействия со всеми участниками рынками. Цель – получить доступ к “закрытой” части их работы и к каналам взаимодействия.

  2. Создать команду для включения поддержки дополнительных языков в «базовый» дистрибутив. Дело в том, что мировые дистрибутивы поддерживают только основные языки (русский, английский и т.д.) и не поддерживают локальные языки, которые могут быть нужны для использования дистрибутива в отдельных республиках. Оценочный размер команды – 5-10 человек.

  3. Создать команду для внедрений и последующей поддержки. Инженеры этой команды решают типовые вопросы, а в сложных ситуациях, требующих взаимодействия с разработчиками или третьими компаниями, используют налаженные каналы сотрудничающей компании. Оценочный размер команды – 20-40 человек.

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

  5. При достижении «критической массы» знаний и опыта можно создавать свой дистрибутив, продолжая сотрудничество. В этом случае дистрибутив имеет множество «точек опоры» (собственная команда разработки и поддержки, сотрудничество с командой «дружественного» дистрибутива, взаимодействие с независимыми разработчиками), и за счет этого никакие локальные проблемы не ведут к провалу проекта в целом. В конечном итоге такой подход порождает УСТОЙЧИВЫЙ дистрибутив.

Комментарии.

Такой «эволюционный» подход практически устраняет риск провала проекта на начальной стадии, так как использует всю инфраструктуру и возможности компании, которая УЖЕ успешно работает в области серьезных внедрений и поддержки Linux.

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

Вывод

Создание “Моего Личного Linux” - крайне сложный и дорогой проект с весьма сомнительными коммерческими перспективами. Единственными разумными причинами создания такого дистрибутива могут быть безопасность и независимость.

Следовательно, компания-разработчик не может быть просто “сборщиком пакетов”. Компания, ставящая своей целью обеспечить высочайшую безопасность, должна быть активным участником сообщества разработчиков, причем ее сотрудники должны быть вовлечены в работу над основными компонентами системы.

Создание такой компании – задача решаемая, хотя и необходимо сразу отдавать себе отчет, что это крайне долгий и рискованный проект, если реализовывать его «с чистого листа». Гораздо эффективнее и быстрее решать такую задачу в сотрудничестве с компанией, уже имеющей большой опыт работы в этой области.

16.08.2007

ODF - Очень Доступный Формат.

В 1999г ученому потребовались данные об образцах марсианского грунта, взятых аппаратом «Викинг» в 1975г. Он хотел проверить теорию о существовании марсианских бактерий и микробов – иными словами, о наличии на Марсе жизни. Ученый рассчитывал найти нужную информацию на сайте NASA, но это оказалось не так-то просто. После долгих поисков наконец были найдены старые кассеты с данными, но они были в «формате настолько старом, что его разработчики уже умерли». А ведь у кого-то была теория, позволяющая узнать чуть больше о жизни и о вселенной. Потеря этого знания перекликается с гибелью Александрийской библиотеки. А то, каким образом оно было потеряно, чем-то напоминает сожжение книг – за уничтожение знания полностью ответственны люди.

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

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

Если говорить об электронных документах, то способ защититься от потери информации из-за проблем форматов ее хранения уже существует. Причем эта технология уже достаточно широко используется и распространяется все шире. Имя ей – Open Document Format (ODF). Если вы не пользуетесь ей сегодня, значит вам еще предстоит открыть ее для себя.

ODF – это формат хранения документов, основанный на XML. ODF был изначально разработан в 1999г Stardivision и затем развивался в рамках проекта Openoffice.org компанией Sun Microsystems. Формат был создан как открытая и свободная альтернатива коммерческим закрытым форматам хранения документов, которые доминируют на сегодняшний день. Цель создания ODF – получить формат, не зависящий ни от конкретной компании, ни от конкретного приложения. Формат, который будет доступен для чтения и записи всем без каких-либо ограничений, связанных с лицензиями или интеллектуальной собственностью.

Такой подход дает ODF ряд существенных преимуществ. Открытый формат создаст честную конкуренцию на рынке офисных приложений – формат хранения документов не будет принадлежать ни одной компании. Все приложения будут полностью совместимы между собой, всеми документами можно будет свободно обмениваться. Информация не будет теряться со временем или из-за изменения закрытых форматов. Важные данные – информация переписей, климатические данные, медицинские карты, судебные решения, результаты научных исследований – больше не будут храниться в формате, который является собственностью одной компании.

В 2002г был создан консорциум OASIS (Organization for the Advancement of Structured Information Standards), который работал над стандартизацией формата и его подробным документированием. В итоге в 2006г формат ODF был принят как международный стандарт ISO представления электронных документов. В 2007г он был принят и как стандарт ANSI.

В марте 2006г был образован «ODF-альянс». Цель альянса – способствовать распространению ODF, разъяснять преимущества открытых форматов, особенно для государственных и общественных организаций.

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

Противники ODF активно препятствуют его внедрению. При этом никто из них не спорит с самой необходимостью внедрения новых форматов. Атаке подвергаются открытые стандарты, на которых основан ODF. С точки зрения противников ODF сейчас все идет более чем хорошо. «Стандарты» принадлежат им. «Рынок» документооборота полностью зависит от них, они считают его своей «территорией», которую они «заняли» плотно и надолго. Они не могут представить будущее иначе (это не входит в их бизнес-план). Нынешняя ситуация их устраивает, все зависят от их приложений и форматов, так зачем им что-то менять? Противники ODF тратят значительные усилия, стараясь создать мнение, что ODF вреден и создает дополнительные сложности (в первую очередь для них самих). Они говорят, что переход на новый формат потребует значительных средств. Иногда они даже говорят, что введение ODF затруднит доступ к информации из-за того, что возникнет слишком много различных форматов. В конце-концов, кому вообще нужна открытость форматов?

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

С точки зрения ODF-альянса, введение открытого формата как стандарта стимулирует здоровую конкуренцию поставщиков. Открытость формата ставит всех в равные условия – все разработчики могут свободно реализовать поддержку открытого формата в своих приложениях. В ситуации, когда формат не принадлежит никому, выигрывает тот, кто создает лучшие приложения, наиболее удобные для пользователей. Стоимость перехода на ODF при этом не выше, чем стоимость перехода с одной версии закрытого формата на другую. А если учесть, что закрытые форматы изменяются регулярно и переходить на новые версии приходится также регулярно, то оказывается, что разовый переход на открытый стандарт на деле дешевле. Что касается возможности работы с ODF, то OpenOffice (и другие приложения, поддерживающие ODF) можно уже сегодня скачать свободно и бесплатно и начать использовать. Ни технических проблем, ни проблем с совместимостью на сегодняшний день не существует. Есть только проблемы, связанные с непониманием.

По словам лидеров ODF-альянса: «Впечатление такое, как будто государственные структуры либо не знают о ODF, либо у них нет специалистов, способных понять все преимущества. Поэтому одна из основных целей ODF-альянса – донести эту информацию до органов, принимающих решения и устанавливающих национальные стандарты».

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

Несмотря на все препятствия, по мере того, как люди понимают, что означает открытость стандарта, ODF завоевывает все новых сторонников. На сегодняшний день в Японии для всех государственных учреждений обязательна работа только с теми приложениями, которые основаны на открытых стандартах. Заявления о готовности перейти на ODF сделали Бразилия, Польша, Малайзия, Италия, Корея, Норвегия, Франция, Голландия, Дания, Бельгия, часть государственных органов США и Индии. И что даже более важно, все эти страны заявили о том, что каким бы ни был итоговый стандарт, он обязательно должен быть открытым.

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

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

Ниже приведены ссылки на логотипы и постеры кампании в поддержку ODF. Что вы можете сделать? Скачать их, распространять, печатать на постерах и футболках. А главное - нести информацию дальше. Разъяснять необходимость использования открытых форматов.

10.08.2007

Управление ПО. Создание собственных репозитариев

Ранее мы уже рассказывали о необходимости упаковывать собственное ПО и ПО третьих поставщиков в RPM. Помимо непосредственно сборки пакетов, в крупной инфраструктуре необходимо обеспечить верификацию подлинности RPM-пакета и безопасное распространение пакетов. Все примеры абсолютно работоспособны и проверены в RHEL5. Если вы пытаетесь использовать эти примеры в отличающейся системе – позаботьтесь об адаптации. =)


GPG-подпись пакетов


GPG-подпись – стандартный механизм подписи пакетов RPM. Для его использования необходимо сделать следующее:

  1. Сгенерировать пару GPG-ключей.

  2. Добавить данные желательной подписи в конфиг RPM

  3. Подписать пакет.

  4. Экспортировать публичный ключ и выложить его в общедоступное место.


Пойдем по порядку.


Генерация пары GPG-ключей


Сначала сгенерируем ключ, для чего выполним команду gpg –gen-key. После ответов на ряд простых вопросов наш ключ будет сгенерирован. Ответы могут быть довольно произвольными, единственное – запомните имя, адрес электронной почты и пассфразу. Я например скромно назвался Albert Einstein <a.einstein@example.com> и записал пассфразу на бумажке. =)

После окончания генерации вы увидите в конце вывода утилиты GPG строки наподобие

gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u

pub 1024D/AE49A408 2007-08-10

Key fingerprint = 4734 6DB2 6078 EAFE 4B3F 8346 8FD7 F01C AE49 A408

uid Albert Einstein



Note that this key cannot be used for encryption. You may want to use

the command "--edit-key" to generate a subkey for this purpose.

Важно запомнить части, выделенные жирным шрифтом. В нашем случае AE49A408– идентификатор моего ключа, а более длинный фрагмент, выделенный полужирным курсивом – это «отпечаток» (fingerprint) моего ключа.

Если вы не послушали меня и не запомнили выделенные жирным данные – вы всегда можете их «подсмотреть», выполнив команду

gpg --fingerprint


Конфигурирование RPM для использования ключа


Конфигурирование RPM в данном (как в прочем и в любом другом) случае сводится к добавлению двух строк в файл ~/.rpmmacros

%_signature gpg

%_gpg_name Albert Einstein <a.einstein@example.com>

Единственным «критичным» моментом является совпадение имени и e-mail адреса в выводе команды gpg –fingerprint с адресом, указанным в файле .rpmmacros.


Подпись пакетов


Задача важная, требующая интерактива и внимания. Хотя бы потому, что вам придется вспомнить пассфразу, введенную ранее. =)
Для подписи RPM-пакетов у утилиты rpm есть два параметра.

  • --addsign – начальная подпись. Используется в случае, если пакет не подписывался ранее.

  • --resign – как очевидно из названия «переподписать». (не верьте переводу Lingvo, сдаваться мы не собираемся).


Формат вызова и использование параметров довольно очевидно:

rpm –addsign hello-1.0-1.i386.rpm

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

rpm –resign kernel-2.6.18-8.1.8.el5.i686.rpm

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


Экспорт ключа


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

gpg --export --armor AE49A408 > /tmp/gpg-key

После этого «объявление» должно быть донесено до каждой системы. Для локальной системы можно тут же, не отходя от кассы, выполнить команду

rpm –import /tmp/gpg-key

а для использования GPG-ключа в нашем репозитарии нам необходимо обеспечить удаленный свободный доступ к этой публичной части ключа. Наиболее простое решение (предполагающее, что у вас запущен httpd) – выполнить команду

cp /tmp/gpg-key /var/www/html/

После этого на прочих системах достаточно выполнить команду

rpm –import http://192.168.0.1/gpg-key

где 192.168.0.1 – IP-адрес вашей системы. После этого вы можете проверить подлинность пакета вызвав rpm с ключом -Kv

rpm -Kv hello-1.0-1.i386.rpm


Создание репозитория

Для создания репозитария вам потребуется:

  1. Набор пакетов для репозитария. Если пакеты, которые вы хотите включить в свой репозитарий зависят от пакетов, не входящих в стандартный репозитарий дистрибутива – хорошей практикой будет включение подобных зависимостей в ваш репозитарий. Разумеется, удаленный доступ к пакетам с клиентских систем должен быть обеспечен. Наиболее простой способ – обеспечение доступа по HTTP или анонимному FTP. Мы надеемся, что с этим читатель справится. В нашем примере мы просто создали директорию /var/www/html/repository/5/i386/ и переместили наши RPM-пакеты туда.

  2. GPG-ключ. Мы уже обеспечили свободный доступ к нему; уровень «свободности» доступа может ограничиваться вашей организацией, а может быть глобальным – это совершенно безопасно.

  3. Метаданные для пакетов. Это данные, которые необходимы утилите yum для разрешения зависимостей. Процесс создания прост. Нам потребуется установить пакет createrepo. Найти ее можно в стандартной поставке RHEL5. Простейший вариант использования:

    cd [директория-с-пакетами]; createrepo .

  4. Файл описания репозитория, Этот файл необходимо «донести» до широких масс систем, которые будут пользоваться вашим репозитарием. Способ оставляем на ваше усмотрение. Содержание файла может быть примерно следующим

    [user@fortice ~]$ cat /etc/yum.repos.d/packages.repo

    [epel]

    name=Extra Packages for Enterprise Linux 5 - $basearch

    baseurl=http://192.168.0.1/repository/5/$basearch

    enabled=1

    gpgcheck=1

    gpgkey=http://192.168.0.1/gpg-key

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


Заключение.


Описанный метод позволит вам наладить распространение ПО собственной сборки, а также ПО третьих, особо доверенных сборщиков и управлять им так же, как и ПО, входящим в дистрибутив. Это хороший метод, имеющий правда один существенный недостаток. Этот недостаток заключается в том, что управление ПО можно осуществлять только методом «PULL», то есть непосредственно с клиентской системы.

Существуют решения для управления ПО, позволяющие использовать также метод PUSH и иметь централизованный источник информации и пульт управления ПО в вашей инфраструктуре. Имя ему Red Hat Satellite Server и его возможности этим не ограничиваются.

09.08.2007

Управление пакетами. Создание собственных RPM.

Несколько лет назад, когда Linux использовали на инфраструктурных серверах и компьютерах энтузиастов, было «модно» собирать ПО из исходных текстов. Плох тот линуксоид, который не может пройти книжку LFS и собрать свой дистрибутив.

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

Решение подобной проблемы – использование специального ПО и политики управления пакетами с целью стандартизации управления жизненным циклом ПО. Одним из решений для управления ПО является использование формата RPM, а также одноименного менеджера пакетов.

RPM – что это такое?

Что такое пакет? Прежде всего пакет – это единица управление ПО. Пакет состоит из:

  1. Файлов, исполняемых и конфигурационных
  2. Предустановочных действий.
  3. Постустановочных действий
  4. Действий, необходимых для удаления ПО.
  5. Различной служебной информации (списки и контрольные суммы файлов и т.д.)

Соответственно, пакет – это несколько больше, чем просто архив файлов. RPM-пакеты – основной способ управления ПО во многих дистрибутивах Linux. Разумно использовать его и для управления собственным ПО / ПО третьих лиц, которое не распространяется в виде RPM по умолчанию. Именно этим мы и займемся. Примеры из данной статьи разобраны и протестированы на RHEL5, хотя по аналогии будут работать и во многих других дистрибутивах.

Подготовка окружения для сборки RPM

В любой системе существует стандартная инфраструктура для сборки RPM. По умолчанию она расположена в /usr/src/redhat/. Если подобного каталога нет, установите пакет rpm-build. Его наличие позволяет собирать пакеты, имея административные привилегии, что не всегда безопасно. Мы будем использовать сборку под непривилегированным пользователем, которого назовем brewbuilder.

Для демонстрации нам потребуется пакет hello-1.0.tar.gz, который можно взять с сервера ftp://62.205.185.52/765591143807cc23efcfb4f1b436ebbc/hello-1.0.tar.gz

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

$ mkdir -p ~/workspace/redhat/{RPMS,SRPMS,SPECS,SOURCES,BUILD}
$ echo '%_topdir /home/brewbuilder/workspace/redhat' > ~/.rpmmacros

Теперь мы готовы к сборке. Для сборки нам необходим единственный файл hello-1.0.tar.gz, который надо разместить в ~/workspace/redhat/SOURCES.

Часть основная – содержательная. SPEC-файл.

SPEC-файл – центральная часть процесса сборки. Написание корректного SPEC-файла и является целью нашей сегодняшней работы. Итак приступим.

Есть простой способ обеспечить себе шаблон для сборки – запустите emacs. =) Сложный – сделайте себе шаблон в вашем любимом редакторе (читай VIM) или запомните необходимые стадии. Мы приведем сразу весь SPEC-файл, позже разобрав его построчно. (Нумерация строк приведена только для удобства, в реальном SPEC-файле нумерация не нужна.)

  1. Name: hello
  2. Version: 1.0
  3. Release: 1
  4. Summary: A sample package, saying hello, world
  5. Group: Applications/Productivity
  6. License: GPL
  7. Source0: hello-1.0.tar.gz
  8. BuildArch: i386
  9. BuildRoot: %{_tmppath}/hello-root

  10. %description
  11. This package basically does nothing, but it potentially could
  12. do something useful.


  13. %prep
  14. %setup -q -n %{name}-%{version}

  15. %build
  16. make

  17. %install
  18. mkdir -p $RPM_BUILD_ROOT/usr/local/{bin,lib,share}
  19. mkdir -p $RPM_BUILD_ROOT/usr/local/share/man/man1
  20. install libhello.so.1.0 $RPM_BUILD_ROOT/usr/local/lib
  21. install hello $RPM_BUILD_ROOT/usr/local/bin
  22. gzip -9c hello.1 > hello.1.gz &&
  23. install hello.1.gz $RPM_BUILD_ROOT/usr/local/share/man/man1

  24. %files
  25. %defattr(-,root,root)
  26. /usr/local/lib/libhello.so.1.0
  27. /usr/local/bin/hello
  28. /usr/local/share/man/man1/hello.1.gz

  29. %clean
  30. make clean
  31. rm -rf $RPM_BUILD_ROOT

  32. %post
  33. echo "/usr/local/lib" >> /etc/ld.so.conf
  34. ldconfig

  35. %changelog
  36. * Tue Jul 17 2007 Andrey Meganov
  37. - Initial build

Итак, начнем. В строчках [1-6] находится стандартное описание пакета. Эти поля необходимы, но назначение их чисто описательное за исключением поля Source0, в котором указано имя архива с исходными текстами. Помимо поля Source0, могут быть и Source1, Patch0 и далее по аналогии.

Строчки [11-13] (секция %description) задают описание пакета. Это стандартное многострочное описание, выводимое командой rpm -qi.

Строки [16-17] (секция %prep) отвечаю за подготовку пакета к сборке. Единственная строчка в нашем случае – макрос %setup отвечает за «тихую» (флаг -q) распаковку исходников Source0 в каталог %{name}-%{version}. В этой секции полагается размещать подготовку исходников с сборке, применение патчей и т.п.

Строки [19-20] (секция %build) отвечают за сборку исходников. В нашем случае это делается просто командой make. В общем случае это почти всегда комманды ./configure –prefix=$RPM_BUILD_ROOT/usr; make.

Секция %install [22-28] отвечает за установку файлов в окружении сборки. В нашем случае стандартной цели make install нет, поэтому мы устанавливаем все вручную. В общем случае make install в этой секции почти всегда решит ваши проблемы. Заметьте, что все пути начинаются с $RPM_BUILD_ROOT. Это достаточно важно и это главная причина не собирать пакеты под пользователем root. В случае если вы – root и вы забудете $RPM_BUILD_ROOT в начале пути, то вместо установки в «песочнице» ваш файл будет установлен на вашей рабочей системе, чего вы вряд ли хотите. =)

Секция %files [30-34] – одна из наиболее важных частей нашего SPEC-файла. Она описывает файлы, входящие в RPM-пакет. В этой секции желательно определить макросом %defattr(-,root,root) атрибуты по умолчанию (владелец – root, группа root, доп. атрибутов нет.), иначе при установке RPM-пакета пользователь увидит жалобы на то, что пользователь brewbuilder не существует. При создании списка файлов можно использовать шаблоны с символами '*' и '?', но делать это следует осмотрительно, так как указание списка файлов как /* приведет к включению лишних файлов в пакет. Специально можно пометить конфигурационные файлы (%config), что приведет к специальному обращению с ними, например при обновлении пакета, документацию (%doc) и пустые директории, принадлежащие пакету (%dir). Подробнее об использовании этих и других опций вы сможете прочитать в отдельных статьях.

Секция %clean [36-38] описывает очистку временного окружения сборки и обычно ничего кроме двух указанных команд не содержит.

Секция %post [40-42] описывает постинсталляционный скрипт. В нашем случае мы добавляем /usr/local/lib к пути, по которым доступны разделяемые библиотеки и успокаиваемся на этом. При написании данной секции мы сделали очевидную ошибку. Ошибка заключается в том, что мы не выдержали транзакционность. При удалении пакета мы не можем просто убрать строчку /usr/local/lib из файла /etc/ld.so.conf, потому что мы не можем рассчитывать, что никто другой не проверял наличие там этой строчки. С другой стороны, если мы – последний пакет, которому эта строчка нужна – неплохо было бы все таки иметь возможность удалить ее – для чистоты процесса. Для этого придумали директории, вроде /etc/ld.so.conf.d/. Чтобы добавить путь к библиотекам корректно, нам просто необходимо создать свой файл со строчкой /usr/local/lib в этой директории, а при удалении пакета (например, в неописанной в данной статье секции %preun) удалить этот файл.

И последняя секция %changelog содержит историю пакета. История пишется записями с фиксированным форматом даты, имени и адреса электронной почты. Формат дальнейших заметок произволен. Рекомендуется серьезно отнестись к changelog'ам, дабы избежать проблем в будущем.

Сборка пакета

Сборка пакета осуществляется одной командой

rpmbuild -ba [путь к SPEC-файлу]

После чего вы можете исследовать директории %_topdir/RPMS и %_topdir/SRPMS, найти там собранные пакеты и исследовать их командами rpm -q ...., установить и удалить соответственно.

Заключение

Вот мы и собрали наш первый RPM-пакет. Если вы хотите узнать более тонкие моменты сборки RPM, то рекомендуем прочесть книгу RPM Guide, доступную по адресу http://docs.fedoraproject.org/drafts/rpm-guide-en/. В дальнейшем мы обязательно расскажем о подписи RPM-пакетов и создании собственных репозитариев для yum.