2012-04-23T21:53:24+04:00 http://hrafn.me Alexander 'Hrafn' Ivanov 2012-04-23T00:00:00+04:00 http://hrafn.me/2012/04/chef-basics-search-and-databags <p><a href="http://wiki.opscode.com/display/chef/Introduction+to+Search+and+Data+Bags">Ссылка на оригинал</a></p> <p>Это последняя часть из Chef Basics. И посвящена она краткому описанию (очень краткому) функций поиска и data bags, не знаю как перевести на русский это словосочетание. В ближайшее время постараюсь собрать все четыре части в PDF. Также в планах дальнейшие переводы по Chef: Chef.Architecture и Chef Essentials. Но об этом позже :)</p> <!--more--> <h2>Поиск</h2> <p>Поиск - это функциональность Chef, позволяющая использовать полнотекстовый поисковый движок (основанный на Apache Solr) для запроса информации об инфраструктуре и приложениях. Информация, содержащаяся в аттрибутах узла, data bags (смотрите ниже), окружения, роли и API клиентов также могут запрашиваться.</p> <p>Поиск можно использовать как внутри рецептов, так и с рабочей станции Chef, используя knife. Например, в рецепте, можно получить список всех серверов приложений, чтобы добавить их в конфигурацию, относящуюся к балансировщикам нагрузки. Чтобы сделать это, можно найти все узлы, которые используют роль "appserver":</p> <pre><code>app_servers = search(:node, 'role:appserver') </code></pre> <p>Следует заметить, что результаты этого поиска не будут статичными. Наоборот, каждый раз при запуске chef-client, результаты будут отображать серверы приложений в пределах окружения на данный момент. Это дает возможность масштабировать инфраструктуру и быть увереным, что новые компоненты будут в должной степени интегрированы с существующими компонентами, например, балансировщиками нагрузки.</p> <p>Как вариант, может потребоваться быстро получить список узлов, использующихся как серверы приложений, с рабочей станции:</p> <pre><code>knife search node 'role:appserver' </code></pre> <p>Для получения более подробной информации следует обратиться к <a href="http://wiki.opscode.com/display/chef/Search">Поиску</a>.</p> <h2>Data Bag</h2> <p>Data Bags хранят вложенные данные ключ-значение (как аттрибуты) на серверах chef. По данным Data Bag можно производить поиск, также их можно загружать прямо по имени в рецепте. Data Bags глобальны для конкретной установки сервера Chef - их можно представить в качестве аттрибутов для всей инфраструктуры.</p> <p>Например, указанному узлу требуется множество учетных записей пользователей. Вместо того, чтобы создавать описание ресурса нового пользователя для каждого из них, можно сохранить информацию о каждом пользователе в data bag и упростить рецепт:</p> <pre><code>search(:users, '*:*') do |u| user u["username"] do home u["home"] shell u["shell"] comment u["comment"] end end </code></pre> <p>Теперь, всякий раз при необходимости создать пользователя на узлах, можно сделать это просто отредактировав data bag вместо рецепта. Это не только упрощает рецепты, но и позволяет убедиться, что важные данные об инфраструктуре будут доступны для поиска. Доступность для поиска означает, что можно будет быстро получить ответ на вопросы об инфраструктуре, используя knife.Например, скажем, если требуется узнать оболочку по умолчанию пользователя "hank", можно проделать с knife следующее:</p> <pre><code>knife search users 'username:hank' -a shell </code></pre> <p>Для data bags, которые содержат конфиденциальную информацию, Chef предоставляет Encrypted Data Bags, позволяющие безопасно хранить информацию на Chef Server в зашифрованном виде. Для получения более подробной информации о databags и зашифрованных data bags следует обратиться к <a href="http://wiki.opscode.com/display/chef/Data+Bags">Data Bags</a> и <a href="http://wiki.opscode.com/display/chef/Encrypted+Data+Bags">Encrypted Data Bags</a>.</p> <h2>Краткий итог</h2> <ul> <li>Поиск позволяет делать запросы на получение информации об инфраструктуре из рецептов или через knife.</li> <li>Data bags позволяет хранить данные в виде, пригодном для поиска. Эти данные в дальнейшем могут быть найдены и использованы в рецептах.</li> </ul> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/OXbRasjxXVY" height="1" width="1"/> http://hrafn.me/2012/04/chef-basics-search-and-databags 2012-04-22T00:00:00+04:00 http://hrafn.me/2012/04/chef-basics-introduction-to-cookbooks <p><a href="http://wiki.opscode.com/display/chef/Introduction+to+Cookbooks+and+More">Ссылка на оригинал</a></p> <p>"Поваренные книги" - способ, которым пользователи Chef и Hosted Chef запаковывают, распространяют и делают общей информацию о конфигурации. Они объединяют все ресурсы, необходимые для автоматизации инфраструктуры, а также облегчают обмен с другими пользователями Chef.</p> <p>Они содержат рецепты, файлы аттрибутов, шаблоны и другие штуки для настройки.</p> <!--more--> <p>При запуске Chef-Client рецепты, перечисленные с списке запуска узла перенаправляются на узел наравне с другим содержимым "поваренной книги", содержащей рецепт. Эти рецепты затем применяются к узлу, приводя его в надлежащее состояние.</p> <p><a href="/media/images/2012/04/22/chef-basics-cookbook.png"><img src="/media/images/2012/04/22/chef-basics-cookbook.png" alt="" /></a></p> <p>Обычно, единственная поваренная книга сожержит информацию, необходимую для настройки одного сервиса или одной части системы. Например, в ней может быть "поваренная книга" "users" для настройки пользователей, которые должны иметь доступ к системе и "поваренная книга" "apache" для настройки веб-сервера Apache.</p> <p>"Поваренные" книги могут быть созданы любым человеком, обладающим начальными навыками программирования, и они могут быть написаны без сохранения каких-либо подробностей о развернутом окружении. Это означает, что их можно безопасно распространять и повторно использовать по всей территории организации и компании. Opscode поощряет публикацию пользователями своих "поваренных книг" на Opscode Community Site, где можно выбрать уже из более 300 "поваренных книг". В результате, можно устанавливать и настраивать многие полезные вещи даже без написания новой "поваренной книги".</p> <p>Если репозиторий Chef использует git, можно быстро найти и использовать "поваренные книги", написанные сообществом, используя инструмент командной строки - Knife. Например, для того, чтобы скачать простую "поваренную книгу" "getting-started", можно запустить следующее из репозитория chef:</p> <pre><code> knife cookbook site install getting-started </code></pre> <p>Для выгрузки ее на Chef Server или Hosted Chef:</p> <pre><code> knife cookbook upload getting-started </code></pre> <p>И, для добавления рецепта "default" в эту поваренную книгу для списка запуска узла:</p> <pre><code> knife node run_list add my_node 'getting-started::default' </code></pre> <p>Chef также предоставляет инструменты для более легкого создания новой поваренной книги. Например, для создания базовой структуры новой поваренной книги в репозитории Chef, можно использовать knife:</p> <pre><code> knife cookbook create new_cookbook_name </code></pre> <h2>Рецепты</h2> <p>Рецепты - это файлы Ruby, в которых используется Domain Specific Language (DSL) для определения того, каким образом конкретные части узла следует настраивать. Как можно будет увидеть в последующих секциях, можно использовать данные, совмещенные с возможностью использовать код ruby в рецептах для динамического изменения конфигурации узла.</p> <p>"Поваренные книги" могут содержать множество рецептов, включая рецепты, добавленные в список запуска по их полному имени, используя форму COOKBOOK_NAME::RECIPE_NAME. В список запуска добавляются только роли и рецепты.</p> <p>Chef, однако, предоставляет укороченную нотацию для имен рецептов и "поваренных книг" в команде списка запуска. (Это полезно для рецептов, которые используются в качестве основной конфигурации для набора узлов).</p> <p>При добавлении COOKBOOK_NAME в список запуска Chef считает, что нужен рецепт с именем "default" из "поваренной книги" с тем же именем. Чтобы посмотреть на пример такого поведения, можно изменить команду knife, использованную выше, для добавления рецепта в список запуска узла. Успользуя укороченный вариант, можно просто дать команду, приведенную выше:</p> <pre><code> knife node run_list add my_node getting-started </code></pre> <p>Этом обновленном примере добавляется рецепт "default" из "поваренной книги" "getting-started" в список запуска "my_node", как и прежде.</p> <h2>Ресурсы и Провайдеры</h2> <p>Ресурсы - это строительные блоки, которые будут использоваться для создания должным образом настроенного узла. Они представляют собой крос-платформенную абстракцию того, что настраивается на узле - отдельные куски конфигурации системы, которые помещены в рецепты и применяются к узлам.</p> <p>Ключевой особенностью ресурсов является то, что они позволяют сфокусироваться на описании конфигурации узла вместо того, чтобы указывать, каким образом конкретная задача должна быть выполнена.</p> <p>Например, следующий ресурс добавляет пользователя на узел:</p> <pre><code> user "sam" do home "/home/sam" shell "bin/zsh" comment "Sam loves DevOps" action :create end </code></pre> <p>Этот ресурс описывает пользователя, "sam", которого необходимо создать на узле. В действительности создание производится Провайдером, который выполняет команды, необходимые для создания нового пользователя.</p> <p>Отдельные ресурсы могут иметь множество провайдеров, каждый из которых знает, как выполнить необходимые задачи на различных платформах. Chef-client выберет лучшего провайдера для платформы узла. Таким образом, описание этого едиснтвенного ресурса можеь быть использовано для создания пользователя "sam" на Linux-системе и FreeBSD-системе, без каких-либо изменений.</p> <p>Ресурс пользователя, описанный выше, структурирован так же, как все описания ресурсов в Chef Domain Specific Language (DSL):</p> <pre><code> resource_type "resource_name" do resource_attribute value ... end </code></pre> <p>Тип ресурса относится к виду ресурса, который необходимо настроить. Многие различные ресурсы определяются при помощи Chef DSL. Полный список этих ресурсов можно найти на странице <a href="http://wiki.opscode.com/display/chef/Resources">Ресурсы</a>. Обладая глубокими знаниями Chef, можно даже расширить Chef DSL с помощью собственных ресурсов.</p> <p>Имя ресурса - это строка, идентифицирующая этот специфичный экзмепляр ресурса. Для конфигурации конкретного узла может потребоваться определение множества ресурсов пользователей, каждый из которых будет иметь свое собственное имя и может быть направлен к другому ресурсу. Имя ресурса, также, по умолчанию, используется как значение для одного из "аттрибутов ресурса". Например, в ресурсе пользователя, описанном выше, имя "sam" будет использоваться в качестве имени пользователя для пользователя, которого создаст chef-client.</p> <p>Аттрибуты ресурса и относящиеся к ним значения описвают желаемое состояние ресурса. Каждый ресурс обладает различными аттрибутами, важными в контексте данного ресурса. Аттрибут "action" - это аттрибут, использующийся всеми ресурсами и определяющий, что должно произойти с этим ресурсом. В примере выше, действие "create" указывает, что требуется создать пользователя. Когда sam покинет организацию, можно изменить это действие на ":delete" для удаления пользователя.</p> <p>Доступные аттрибуты ресурса и их значения по умолчанию подробно описываются на странице <a href="http://wiki.opscode.com/display/chef/Resources">Ресурсы</a>.</p> <p>Когда chef-client загружает рецепты с свой список запуска.</p> <ol> <li>он запускает каждый рецепт как часть кода ruby</li> <li>каждый раз, когда ресурс используется, он добавляетя в коллекцию ресурсов для этого узла</li> <li>затем провайдеры этих ресурсов принимают решение действовать или нет для выполнения описания ресурсов.</li> </ol> <p>Таким образом, ключевым принципом Chef является достижение: идемпотентность. Идемпотентность позволяет убедиться, что ресурс может применяться к машине множество раз и всегда будет получен тот же самый результат: должным образом настроенная машина.</p> <h2>Аттрибуты и Шаблоны</h2> <p>Аттрибуты обеспечивают хранение вложенных пар ключ-значение данных об узле и его конфигурации. Некоторые аттрибуты автоматически собираются на старте каждого запуска chef-client и включают такую информацию, как IP-адрес узлов, имя хоста или загруженные модули ядра. Другие аттрибуты добавляются из других источников, например, "поваренные книги". (Роли и Окружения также могут устанавливать аттрибуты, об этом будет написано далее).</p> <p>Аттрибуты позволяют изменить конфигурацию на основе характеристик узла и установить разумные значения по умолчанию для конфигурации сервиса, что также позволяет легко их изменять. Единственный способ установить аттрибуты - файлы аттрибутов в "поваренной книге".</p> <p>Например, далее устанавливаются некоторые разумные значения по умолчанию для расположения определенного конфигурационного файла:</p> <pre><code> default["my_application"]["config_location"] = "/etc/myapp.conf" </code></pre> <p>Затем этот аттрибут может использоваться напрямую при контроле ресурсов конфигурационного файла:</p> <pre><code> template node["my_application"]["config_location"] do action :create end </code></pre> <p>Определение Шаблона, который является особенностью Chef, позволяет создавать общие файлы, содержание которых может быть сгенерировано автоматически. Если этот файл конфигурации много раз упоминался в рецепте, изменение его расположения - причина изменения одного аттрибута.</p> <p>Аттрибуты узла также содержат игформацию об узле, которая может использоваться в рецепте:</p> <pre><code> if node.attribute?("ec2") # Выполнить специфичные для EC2 задачи. end </code></pre> <p>Это позволит рецепту выполнить некий набор задач по настройке только в том случае, если он был запущен в облаке Amazon EC2. За полной информацией об Аттрибутах необходимо обратиться к <a href="http://wiki.opscode.com/display/chef/Attributes">следующей странице</a>.</p> <h2>Роли</h2> <p>Настройка одного узла может потребовать множество различных "поваренных книг". Для упорядочивания в группы похожих возможностей на похожих хостах Chef предоставляет Роли. Роли содержат список запуска (только для узла) и аттрибуты, относящиеся к конкретной функции. Например, можно создать роль "webserver", которяа будет включать список запуска со всеми сервисами, необходимыми для работы типичного веб-сервера в пределах инфраструктуры. Список запуска узла может содержать эти роли.</p> <p>В случае, если в списке запуска узла находится роль, список запуска самой роли расширяется и добавляется к списку запуска узла, чтобы быть уверенным, что все рецепты для указанной роли применены к узлу.</p> <p>Роли также могут устанавливать аттрибуты. Установка аттрибутов в ролях позволяет переназначить аттрибуты по умолчанию общей "поваренной" книги на значения, более соответствующие узлу с указанной ролью.</p> <p><a href="/media/images/2012-04/22/chef-basics-roles.png"><img src="/media/images/2012/04/22/chef-basics-roles.png" alt="" /></a></p> <h2>Окружения</h2> <p>Окружения в Chef предоставляют механизм для управления такими разлиными окружениями, как production, staging, development и testing в пределах одного Chef Server или организации Hosted Chef. С помощью окружений можно указать "список запуска" в роли, ограничение по версии "поваренной книги" и аттрибуты окружения для каждого их них по отдельности. Роли отличаются в это плане тем, что группируют системы по определенным функциям и могут распространяться между окружениями - например: сервер приложений, веб-сервер, сервер баз данных. Таким образом, есть возможность иметь список запуска для каждого окружения внутри роли - например: в окружении development сервер приложений должен подключаться к другому балансировщику нагрузки, находящимся в окружении test, и этим можно управлять внутри одного рецепта.</p> <p>Можно создавать и управлять окружениями множеством способов, адаптируя их для удовлетворения сосбтвенных нужд и нужд инфраструктуры. Обратитесь к странице <a href="http://wiki.opscode.com/display/chef/Environments">Окружения</a> для получения подробностей.</p> <h2>Кратко об описанном</h2> <ul> <li>Поваренные книги содержат рецепты, файлы аттрибутов и других информацию о конфигурации</li> <li>Ресурсы представляют собой строительные блоки для рецептов и описывают конкретную часть конфигурации узла</li> <li>Ресурсы идемпотентны. Применение одного и того же ресурса дважды должно приводить к одному и тому же результату</li> <li>Провайдеры применяют необходимые действия, требующиеся для приведения узла в состояние согласно описанию ресурса</li> <li>Аттрибуты предоставляет настраиваемые параметры, которые могут использоваться в рецептах, так же как информация об узле</li> <li>Роли предоставляют способ описания определенной функции или типа узла. Роли имеют списки запуска и аттрибуты.</li> <li>Окружения предоставляют способ управления различными инфраструктурными пространствами в пределах одного экземпляра Chef.</li> </ul> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/3i5BXYh-NPg" height="1" width="1"/> http://hrafn.me/2012/04/chef-basics-introduction-to-cookbooks 2012-04-21T00:00:00+04:00 http://hrafn.me/2012/04/chef-basics-core-components <p><a href="http://wiki.opscode.com/display/chef/Core+Components">Ссылка на оригинал</a></p> <p>Чтобы научиться использовать Chef, необходимо понимать, что из себя представляет каждый его компонент и каким образом они работают вместе. (http://wiki.opscode.com/display/chef/Core+Components)</p> <!--more--> <h2>Создание инфраструктуры</h2> <h3>Узлы</h3> <p>Узел - это хост, на котором работает клиент Chef. Основная особенность узла, с точки зрения Chef, - его аттрибуты и его список запуска. Узлы - это те вещи, к которым применяются Рецепты и Роли. Для работы с Узлами в любое время потребуется:</p> <ul> <li>добавить рецепт в систему</li> <li>обновить аттрибуты</li> </ul> <h4>Список запуска (run_list)</h4> <p>В простейшем случае, "список запуска" - это список рецептов, которые узел запускает. При условии, что метаданные "поваренной книги" корректные, можно просто поместить рецепт, который необходимо запустить, в "список запуска", и зависимые рецепты будут запущены автоматически при необходимости. Порядок важен: порядок, в котором рецепты перечислены в "списке запуска", в точности соответствует тому, в котором chef будет их запускать.</p> <p>При более продвинутом использовании, "список запуска" будет включать роли, назначенные узлу в дополнение к любому явно назначенному набору рецептов. В этом случае, когда клиент Chef запускается, "список запуска" "растягивается" в список рецептов, замещая записи роли в "списке запуска" списком рецептов роли, указанным в "списке запуска".</p> <h3>Аттрибуты узла</h3> <p>Узлы и роли связаны аттрибутами, которые представляют собой структуру вложенных пар ключ - значение. Аттрибуты узлов и ролей в целом используются в качестве основы для аттрибутов ресурсов. Например, сервер может использовать одну версию nginx, но необходимо установить версию новее на тестовый сервер для проверки. Используя аттрибуты узла или роли для указания версии, можно использовать один и тот же рецепт как для одного, так и для другого окружения.</p> <p>Chef позволяет устанавливать аттрибуты в файлах аттрибутов (кроме мириада других способов). Код в этих файлах доступен узлу, на котором работает chef, и управляет аттрибутами на этом узле напрямую. В терминах ruby, значение <code>self</code> в файлах аттрибутов - это сам узел. Используя эти фйлы, можно рассчитывать, что узел имеет нормальное значение для аттрибута, когда рецепт пишется без учета того, что узел может не иметь определения этого аттрибута.</p> <p>Продвинутые пользователи Chef часто активно используют аттрибуты, определенные в ролях, для управления аттрибутами на нескольких узлах сразу.</p> <h3>Роли</h3> <p>Роль предоставляет возможность группировать подобные возможности подобных узлов. В масштабе веба, почти никогда не бывает чего-то одного, так что можно использовать роли для представления частей конфигурации, которые будут общими для группы узлов. Роли состоят из тем же частей, что и узлы: аттрибуты и "списки запуска". Когда клиент Chef запускается, он объединяет свои собственные аттриуты и "список запуска" с теми из ролей, которые ему были назначены.</p> <h2>Настройка Узлов</h2> <h3>Поваренные книги (Cookbooks)</h3> <p>"Поваренная книга" - это набор рецептов, определений ресурсов, аттрибутов, библиотеки, файла "поваренной книги" и файлов шаблонов, которые chef использует для настройки системы, плюс метаданные. "Поваренные книги" обычно концентрируются вокруг настройки одного пакета или сервиса. "Поваренная книга" MySQL, например, содержит рецепты как для клиента, так и для сервера, плюс файл аттрибутов для настройки по умолчанию для значений, которые могут меняться.</p> <p>"Поваренные книги" - единица распространения и общего доступа в Chef. Большую часть времени использования Chef составляет написание "поваренных книг".</p> <h3>Рецепты</h3> <p>Рецепты - это файлы, куда записываются Ресурсы (рассмотренные ниже). Рецепты могут также содержать произвольный код на Ruby, однако необходимо понимать немного, как Chef использует это. Каждый запуск Chef - процесс из двух стадий: на первой, вызывается компиляция, Chef проверяет файлы рецептов, создавая список ресурсов. На следующей стадии, Chef выполняет желаемое действие для каждого ресурса на провайдере этого ресурса. Любой произвольный код в рецепте будет запущен на этапе компиляции, а не на этапе выполнения. Для того, чтобы отложит выполнение до этапа выполнения, используется ресурс ruby_block.</p> <h3>Метаданные</h3> <p>"Поваренные" книги часто ссылаются на "поваренных книгах" как необходимое условие. Чтобы сервер знал, какие "поваренные книги" необходимо отправить клиенту, "поваренной книге", зависящей от других, необходимо показать, что эта зависимость где-то находится. Это "где-то находится" и есть в метаданных "поваренной книги". Зависимость отслеживается в большей видимой части метаданных, но метаданные могут также содержать информацию об авторстве, лицензии, описание "поваренной книги", какая платформа требуется для работы на ней, и будет или нет "поваренная книга" нормально работать с другими. На данный момент Chef поддерживает намного больше полей для метаданных, чем реально используется, но поддержка произвольной информации о зависимостях абсолютно необходима, поскольку иначе узлы могут не получить все требуемые "поваренные книги" по причине неполной информации.</p> <h3>Ресурсы</h3> <p>Ресурс - как правило, кросс-платформенная абстракция того, что настраивается на хосте. Например, пакеты могут быть установлены через apt, yum или порты и пакетную систему BSD, но ресурс пакетов абстрагируется от этих разных способов, что позволяет просто указать, что пакет должен быть установлен кросс-платформенным способом. Ресурсы Chef по большей части просто контейнеры для данных, с некоторой функциональностью базовой проверки.</p> <p>Ресурсы декларируются в Рецептах и Определениях. Они являются базовой частью работы в Chef.</p> <h4>Аттрибуты Ресурсов</h4> <p>Как уже упоминалось, ресурсы, по большей части, являются контейнерами для данных. Аттрибуты же - это части данных, которые эти ресурсы содержат. В случае управления пакетами, это может быть имя пакеты, который необходимо установить, версия его для установки или опции, передаваемые менеджеру пакетов.</p> <p><em>Аттрибуты или Параметры Ресурса.</em> Разработчики Chef обсуждали переименовывать ли Аттрибуты Ресурса в "параметры" для переопределения термина "аттрибут", так как этот термин также используется для описания данных, относящихся к узлам и ролям. Текущий документ использует термин "аттрибут", и необходимо помнить, что его значения отличается от значения аттрибутов узлов.</p> <h4>Действия</h4> <p>Действие - это то, что от Chef требуется сделать с ресурсом: должен ли быть пакет установлен? Обновлен ли до новой версии? Удален? Действия, в основном, специфичны для ресурса, но все ресурсы поддерживают действие "ничего", смысл которого заключен в его имени.</p> <h3>Провайдер</h3> <p>Провайдер - это специфичная для платформы реализация того, что ресурс абстрагирует. На Red Hat или CentOS ресурс пакетов будет использовать провайдер пакетов yum для установки пакетов, а на Debian или Ubuntu будет использоваться провайдер apt. Провайдеры очень разумны: они несут ответственность за идемпотентность Chef'а, проверяя, необходимо ли применить действие, и отправляя команду системе для применение действия. В случае провайдеров пакетов, они сначала проверяют, установлена ли нужная версия пакета, и запускают, при необходимости, yum, apt или другие менеджеры пакетов для установки или обновления. При работе с Chef обычно не нужно беспокоиться о провайдерах. В случае, когда это делается, Chef предоставляет ресурсы "для ускорения", которые всегда используют нужные провайдеры. Например, ресурсы dpkg_package и rpm_package позволяют установить пакет напрямую с файловой системы, используя провайдеры, специфичные для этих менеджеров пакетов.</p> <p>Провайдеры применяют действия на Ресурсах. Конкретный Узел выбирает, что Провайдер должен использовать для Ресурса по умолчанию, или Ресурс может указать конкретного провайдера.</p> <h3>Поиск</h3> <p>Поиск создан Chef'ом и позволяет запрашивать произвольные данные об инфраструктуре. Наиболее часто, этот сервис используется при поиске вызова в рецепте.</p> <h3>Data Bags</h3> <p>Data Bags хранит вложенные данные ключ-значение (как аттрибуты) на сервере chef. По данным Data Bag можно искать, также они могут быть загружены напрямую по имени в рецепте. Data bags глобальны для установки chef-server - их можно представить как аттрибуты всей инфраструктуры.</p> <h3>Окружения</h3> <p>Окружения предоставляют механизм управления такими различными архитектурными сегментированными пространствами, как "production", "staging", "development", "testing" и т.д. с единственным экземпляром Chef (или одной организацией, в случае, Hosted Chef). С помощью окружений можно указать список запуска в роли для конкретного окружения, версию "поваренной книги" и аттрибуты: это позволяет установить политики для указания того, какая версия конкретной поваренной книги можеь быть использована в сегменте инфраструктуры. Окружения не являются множеством ограничений конкретных взаимодействий на единой системе, они действуют в качестве ограничения версии "поваренной книги" над сгруппированными системами, на которые распространяется использование - например: development, test, production - где существуют серверы приложений и серверы баз данных. Роли - это сгруппированные системы, которые действуют как функции и которые могут распространяться на окружения - например: сервер приложений, веб-сервер, сервер баз данных. Таким образом, можно иметь "списки запуска" для каждого окружения внутри ролей - например: в окружении development требуется, чтобы сервер приложений подключался к другому балансировщику нагрузки, который работает в тестовом окружении - которые включены в тот же самый рецепт.</p> <h2>Управление Chef</h2> <h3>Knife</h3> <p>Knife - интерфес командной строки для сервера Chef, с помощью которого также предоставляются некоторые возможности, полезные для chef-solo как вариант.</p> <h3>Консоль Управления</h3> <p>Консоль Управления - это графический веб-интерфейс для API chef-server. Многие компоненты могут управляться через эту консоль, включая пользователей, узлы, роли, поваренные книги, data bags и API клиентов. Поиск также может производиться через консоль. Консоль Управления Hosted Chef также позволяет клиентам редактирвоать информацию в собственном профилде пользователя, например, информацию об учетной записи или биллинг, а также управлять Авторизацией Hosted Chef.</p> <h3>Shef</h3> <p>Shef - это интерактивная консоль chef - она позволяет создавать, запускать и проверять рецепты интерактивно.</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/sa4wpEQStH8" height="1" width="1"/> http://hrafn.me/2012/04/chef-basics-core-components 2012-04-20T00:00:00+04:00 http://hrafn.me/2012/04/chef-basics-architecture <p><a href="http://wiki.opscode.com/display/chef/Architecture+Introduction">Ссылка на оригинал</a></p> <p>Эта статья является введением в архитектуру Chef. Здесь описываются основные функции сервера Chef (Chef Server), функции узлов (Node) и управляющих станций Chef (Chef Workstation) при использовании Chef, а также взаимодействие между этими компонентами.</p> <p>Позволю себе сделать несколько замечаний. Однозначных русских вариантов основных понятий я скорее не нашел. Каждый пишущий про Chef, переводит по-своему. Если какие-то варианты переводов покажутся неверными или читающий может предложить свой, более адекватный, милости прошу: пишите в Twitter, G+, Jabber или на почту. Кроме того, перевод не профессиональный. Я перевожу, кроме того, далеко не все, поскольку считаю, что главное передать смысл.</p> <!--more--> <p><a href="/media/images/2012/04/20/chef-basics-nwc.png"><img src="/media/images/2012/04/20/chef-basics-nwc.png" alt="" /></a></p> <h2>Chef Server, Узлы и Управляющие станции</h2> <p>При использовании Chef для управления инфраструктурой придется иметь дело с тремя типами хостов: сервером Chef, узлами и управляющими станциями Chef.</p> <h3>Chef Server</h3> <p>Chef Server - это центральное хранилище конфигурационных данных инфраструктуры. Chef Server хранит данные, необходимые для настройки узлов, а также предоставляет поиск, позволяющий динамически управлять конфигурацией узлов на основе данных. REST API делает эти данные доступными для узлов и управляющих станций. Дополнительно, есть возможность использовать Chef Server's WebUI для управления инфраструктурой через веб-интерфейс.</p> <h3>Узлы</h3> <p>Узел - любой хост, настроенный на использование клиента chef. Клиент chef работает на узле, обращаясь к Chef Server за информацией, необходимой для настройки узла. С точки зрения сервера Chef, узел - чуть больше, чем список запуска (run_list), список рецептов и ролей, которые будут применены к узлу и будут определять его конфигурацию, и аттрибуты, набор данных о самом узле. Поскольку Узел - это машина, на которой работает chef-client, узлы иногда рассматриваются как "клиенты". (Это не относится к клиентскому API, которое аутентифицируется через Chef Server API).</p> <p>В случае, если узлы рассматриваются в качестве "клиентов", предполагается связь между исполняемым файлом chef-client, вызовом API предназначенным для аутентификации и авторизации, используя идентификационную информацию в объекте клиентского API, для сохранения объекта узла на сервере.</p> <h3>Управляющая станция Chef</h3> <p>Управляющая станция - это хост, использующийся для изменения "поваренных книг" и других конфигурационных данных - обычно, это рабочая станция системного администратора. Также управляющая станция имеет два ключевых компонента:</p> <ol> <li>knife - приложение. поставляемое вместе с chef</li> <li>репозиторий, содержащий документы конфигурации инфраструктуры</li> </ol> <p>Как будет видно в дальнейшем, эти документы конфигурации включают "поваренные книги", роли, data bags и многое другое. В идеале, эти документы находятся под управлением какой-либо системы контроля версий. При использовании knife, рабочая станция используется как для выгрузки конфигурационных данных на Chef Server, так и для взаимодействия с отдельными узлами через SSH-соединение, если это необходимо.</p> <h2>Клиенты, Аутентификация и Авторизация</h2> <p>Роль Chef Server внутри инфраструктуры проста. Он хранит информацию о конфигурации, которая загружается на него, и возвращает эту информацию, когда ее запрашивает клиент API.</p> <p>Chef использует клиентский API и систему аутентификации и авторизации, чтобы быть уверенным, что данные конфигурации могут быть прочитаны и обновлены только теми, кто авторизован. Клиент Chef (работающий на узле) и knife (работающий на управляющей станции) взаимодействуют с Chef Server, используя клиентский API.</p> <p>Другими словами, клиент Chef - это сам испольняемый файл 'chef-client'. Клиентский API - объект, который представляется зашифрованной "личностью", использующейся для аутентификации и авторизации в каждом вызове API.</p> <p>Для того, чтобы быть уверенным, что запросы приходят от известного API, Chef использует шифрование публичным ключом, пользователи Hosted Chef имеют некоторые дополнительные возможности более тонкой настройки. Клиенты API обладают соответствующими приватными и публичными ключами шифрования. Каждый запрос API, сделанный исполняемым файлом chef, подписывается конкретным приватным ключом клиента API. Затем Chef Server проверяет, что запрос соответствует публичныому ключу клиента.</p> <p>После этого, Chef Server должен убедиться, что клдиент, сделавший запрос, имеет права, достаточные действий, которые запрашиваются (например, выгрузка "поваренной книги" или получение run_list.) Этот процесс известен как авторизация. Open Source Chef Server и Hosted Chef используют различные системы авторизации.</p> <h3>Open Source Chef</h3> <p>В Open Source Chef определенные клиенты API могут быть помечены как "admin clients". Авторизация для различных действий устанавливается помечен ли клиент API как "admin" или нет. Admin clients используются при создании запросов через knife и обладают всеми возможными правами. Не-"admin" клиенты обладают ограниченными правами и используются для узлов внутри инфтраструктуры.</p> <h3>Hosted Chef</h3> <p>Hosted Chef использует более комплексную систему авторизации, обеспечивающую более точный контроль на основе client-by-client (или user-by-user). В этой системе клиенты API и пользователи могут иметь права на СОЗДАНИЕ, ЧТЕНИЕ, ОБНОВЛЕНИЕ, УДАЛЕНИЕ или права на ВЫДАЧУ ПРАВ для объектов, хранящихся на Hosted Chef (данные узла, данные "поваренной книги" и т.д.). Hosted Chef должен убедиться, что делающий запрос клиент имеет соответствующие права на запрашиваемое действие. Для упрощения управления правами Hosted Chef предоставляет множество заранее созданных групп, обладающих правами в соответствие с определенными ролями. Пользователи и клиенты, входящие в группу "admin", имеют все права на все объекты. Не относящиеся к людям клиенты API (такие, как использующиеся узлами) будут автоматически помещены в группу клиентов, которые имеют права, подобные не-административным клиентам в Open Source Chef, тогда как клиенты-люди могут быть помещены в группу "users", которая обладает правами, подобными административным клиентам в Open Source Chef.</p> <p>Когда chef-client запускается на нвоом узле, Chef спроектирован для автоматического создания нового клиента API для данного узла. По этой причине, поскольку пользователи или административные клиенты настраиваются один раз должным образом для использования knife и подключения через WebUI или Management Console, часто бывает необходимо продумать детали клиентов API, аутентификации и авторизации.</p> <h2>Hosted Chef</h2> <p>В дополнение к более точной системы авторизации у Hosted Chef есть еще две концепции, не использующихся в Open Source Chef: Пользователи и Организации.</p> <h3>Пользователи</h3> <p>Пользователи - это, что и можно представить, исходя из названия: сертифицированные сущности, используюшиеся людьми для подключения к Hosted Chef. Как и клиенты, у них есть ключи, которые используются для программного подключения к Hosted Chef, через api.opscode.com или knife. Но у них также есть пароли, которые можно использовать для входа на различные веб-страницы, которые отображает Hosted Chef.</p> <p>Пользователи могут относиться к организации, которая предоставит им соответствующие права для взаимодействия и управления этой организацией. Однако, в отличие от клиентских API, Пользователи могут относиться к более, чем одной организации, например, консультант мог бы создать отдельную организацию для каждого из своих клиентов. При планировании аутентификации и авторизации проще всего рассматривать пользователя как еще одного клиента API.</p> <p>Пользователи обладают единственной учетной записью для всех страниц Opscode. Одни и те имя и пароль могут использоваться для входа в Hosted Chef Management Console, the Opscode Cookbooks Site или help.opscode.com.</p> <h3>Организации</h3> <p>При регистрации в Hosted Chef создается учетная запись пользователя и организация. Организация может представлять собой всю компанию целиком, какой-то отдельный департамент или любой сгруппированный набор серверной инфраструктуры, которым планируется управлять. Организации - это сущности, которые будут оплачиваться при использовании Hosted Chef. За исключением пользователей, ничего общего между организациями не существует. Клиентский API в одной организации не может прочитать данные узла из другой организации.</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/XshRruulyog" height="1" width="1"/> http://hrafn.me/2012/04/chef-basics-architecture 2012-04-14T00:00:00+04:00 http://hrafn.me/2012/04/about-blog-design <p>Прошлое сообщение устарело практически через несколько дней после публикации. Нынешний внешний вид - это уже наверно третий или четвертый вариант, который я пробовал. Если сначала я пытался просто поправить какие-то уже существующие шаблоны действующих блогов под себя, то потом понял, что надо или смирится с наличием недостатков и ограничений, или сделать так, как устроит именно меня и в том виде, который меня устроит. Что я, в конечном итоге, и сделал.</p> <p>Есть некоторые недоработки, но потихоньку я постараюсь их исправить. Правда, мне кажется, что я это уже писал ранее, но все равно постараюсь. :)</p> <p>В процессе создания нового CSS перетащил на Jekyll своего друга, чей блог можно посмотреть и почитать на <a href="http://nobodyknows.ru">nobodyknows.ru</a>. К сожалению, он пишет редко, но, быть может, какой-никакой приход читателей сподвигнет его на написание статей о различных экспериментах на компьютерную тематику :)</p> <p>Как всегда, у меня множество планов на написание и переводы. Очень постараюсь их осуществить. Кроме того, буду экспериментировать с <a href="http://www.sinatrarb.com/">Sinatra</a>. <a href="http://slavafinn.ru">Мой брат</a> хочет перейти с Wordpress на что-то более легкое, вот и постараюсь ему помочь.</p> <p>Пока как-то так :)</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/emH8uCGD_ac" height="1" width="1"/> http://hrafn.me/2012/04/about-blog-design 2012-02-19T00:00:00+04:00 http://hrafn.me/2012/02/19/new-design <p>Как уже видно пришедшим сюда, я сменил дизайн. Фактически, это получается уже третий вариант. Надеюсь, что окончательный на ближайшее время. Заодно, несколько сменил структуру расположения файлов и сообщений. Убрал отдельный раздел <strong>Articles</strong>. Ссылки оттуда перенес частично в <a href="/links.html"><strong>links</strong></a>, частично просто убрал, поскольку переводы, на которые были указания, сейчас просто лежат в общем списке всех постов.</p> <!--more--> <p>Коротко о дизайне. За основу взят следующий блог - <a href="http://lhzhang.com/">http://lhzhang.com/</a>. Исходники на Github: <a href="https://github.com/waynezhang/blog">https://github.com/waynezhang/blog</a>. Внешний вид переделал самостоятельно, выбирая те цвета и оттенки, которые мне нравятся :)</p> <p>Тэги в нынешнем виде удалось сделать благодаря Matt Foster <a href="http://hackerific.net/about.html">http://hackerific.net/about.html</a> и его Rakefile: <a href="https://github.com/mattfoster/mattfoster.github.com/blob/master/Rakefile">https://github.com/mattfoster/mattfoster.github.com/blob/master/Rakefile</a>.</p> <p>Стоит добавить, что наконец я перевел RSS на FeedBurner, и адрес потока окончательно изменился. Кроме того, теперь в панели навигации ссылка работает и указывает туда, куда нужно.</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/kqN-OJo5aOk" height="1" width="1"/> http://hrafn.me/2012/02/19/new-design 2012-01-02T00:00:00+04:00 http://hrafn.me/2012/01/opensuse-12-1-fonts <p>Немного скажу касательно отображения шрифтов в последней, на данный момент, версии openSUSE - 12.1. Собственно, дело в том, что говорить-то особо и не о чем. Поэтому и ранее не писал ничего на эту тему, хотя у меня на ноутбуке установлена именно эта версия дистрибутива практически с того момента, как она вышла в свет. Почему я использую сейчас именно этот дистрибутив - это отдельная история. Быть может позже я про это тоже напишу, но сейчас тема немного другая.</p> <!--more--> <p>В предыдущих версиях openSUSE настроить адекватное, на мой взгляд, отображение шрифтов можно было, но несколько сложно. Требовалось много лишних телодвижений, а в итоге результат далеко не всегда получался именно таким, какой хотелось бы видеть. Впрочем, стоит отметить, что с каждым релизом ситуация все больше улучшалась. К сожалению, в основном это было связано не с тем, что разработчики озаботились этим вопросом каким-либо образом, а с тем, что в других дистрибутивах ситуация начала слегка меняться. Сначала разработчики Ubuntu показали очень хороший результат. Потом миру стали известны патчи от Infinality, которые сначала начали применяться в Fedora, а позже появились и в OBS от проекта openSUSE. Я видел и пробовал и то, и другое. Шрифты с патчами от Infinality в целом смотрелись чуть лучше, но их результат в итоге получался более точечным. Т.е. в некоторых приложениях шрифты смотрелись просто отлично, где-то похуже, а где-то результат применения патчей был не видел совсем. В отличие от Infinality патчи применяющиеся в Ubuntu давали более комплексный результат. Возможно, это зависит от каких-то дополнительно установленных пакетов, но столько глубоко я не закапывался, кроме того, пакеты в различных дистрах разбиваются на более мелкие совсем по-разному. Теперь что касается шрифтов в openSUSE 12.1. Упоминающийся далее репозиторий я как-то пробовал использовать в более ранних версиях openSUSE, но результат был несколько далек от ожидаемого. Сейчас все совершенно изменилось. Про что я сейчас и напишу :)</p> <p>Для получения нужного результата достаточно подключить следующий репозиторий: <a href="http://opensuse-community.org/subpixel/openSUSE_12.1/">Subpixel.repo</a> Например, скачиваем файл (http://opensuse-community.org/subpixel/openSUSE_12.1/Subpixel.repo) в /etc/zypp/repos.d/ и ставим пакеты из подключенного репозитория. Как минимум, потребуется:</p> <ul> <li>fontconfig-2.8.0-88.1.x86_64.rpm</li> <li>fontconfig-feature-subpixel-hinting-2.8.0-88.1.x86_64.rpm</li> <li>freetype2-feature-subpixel-hinting-2.4.7-666.1.x86_64.rpm</li> <li>libpixman-1-0-0.22.2-666.1.x86_64.rpm</li> </ul> <p>Остальные необходимые подтянутся по зависимостям. В процессе установки будет задан вопрос о смене поставщика. На него требуется ответить согласием. После установки будет необходимо или перегрузиться, или, как минимум, перезапустить Х-сервер для применения новых настроек шрифтов.</p> <p>Как я уже писал однажды, мне предпочтительны следующие шрифты: Droid, Roboto, Liberation. А, например, при написании этой заметки в Gedit использовался PT Mono. В общем, пробуйте, вкусы-то разные у всех. :)</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/wg6Dy0eQNDE" height="1" width="1"/> http://hrafn.me/2012/01/opensuse-12-1-fonts 2011-12-30T00:00:00+04:00 http://hrafn.me/2011/12/change-blog-engine <p>Практически под самый Новый Год я все же перевел блог с Wordpress на Jekyll. Не могу сказать, что сразу все получилось. Первая попытка оказалась не совсем удачной. В основном, это связано с тем, что я не до конца разобрался с принципом работы Jekyll и не мог до конца предполагать, что результат получится не совсем тем, что я ожидал.</p> <p>Пришлось разбираться с проблемами. А заодно переделал и дизайн. Мне кажется, что получилось лучше.</p> <p>В итоге, вторая попытка оказалась более удачная. Результат Вы сами видите. Кому-то понравится, кому-то нет, кому-то будет все равно. Ссылки на мои записи, а также на RSS-ленту остались прежними, поэтому, если исключить данное сообщение, многие могут просто не заметить перехода. Если это так, то оно и к лучше. Значит, я сделал максимум того, что мог :)</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/CbT6-DdcCpM" height="1" width="1"/> http://hrafn.me/2011/12/change-blog-engine 2011-11-29T23:37:54+04:00 http://hrafn.me/2011/11/opensuse-12-1 <p>Очень уж давно не писал ничего. Как-то то времени не найти, то желания. Кроме того, особо ничего интересного не происходило, а плодить бессмысленные посты с очередным двухсоттысячным описанием настройки чего-либо не хочется.</p> <p>Из последних новостей имеется только одна - установка основной системой свежевышедшей openSUSE 12.1. И даже тут рассказывать нечего :) Все работает, как и должно. Gnome, в третьей своей версии, нравится мне все больше, по- крайней мере, сильно удобней, чем Unity на Ubuntu, которой я пользуюсь на работе.</p> <p>Хотел написать еще некоторые вещи, но что-то SpringPad работать не хочет, поэтому позже. Есть пара мыслей для небольших заметок.</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/FNSQe6UeN2A" height="1" width="1"/> http://hrafn.me/2011/11/opensuse-12-1 2011-07-16T16:46:35+04:00 http://hrafn.me/2011/07/rhcsa-po-rhel6 <p>Вчера сдавал, а точнее, пересдавал экзамен RHCSA. Теперь уже по шестой версии RHEL. Пересдавать пришлось по той причине, что начиная с RHEL6, изменился весь стэк сертификации , в связи с этим изменились и курсы, и экзамены и несколько поменялись темы, присутствующие и там, и там. Вчера же вечером пришло письмо с сообщением, что экзамен успешно сдан :)</p> <!--more--> <p>Почитать про существующие правила и темы, а также про разницу между предыдущими и нынешними экзаменами можно по следующим ссылкам:</p> <p><a href="https://www.redhat.com/cour%0Ases/ex200_rhcsa_exam/">https://www.redhat.com/courses/ex200_rhcsa_exam/</a></p> <p><a href="https://www.redhat.com/tr%0Aaining/policy/recert.html">https://www.redhat.com/training/policy/recert.html</a></p> <p>Ну и под конец добавлю, уже почти по традиции, и сам сертификат</p> <p><a href="/media/images/2011/07/16/rhcsa_rhel6.png"><img src="/media/images/2011/07/16/rhcsa_rhel6.png" alt="" /></a></p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/68dSkzPcrpI" height="1" width="1"/> http://hrafn.me/2011/07/rhcsa-po-rhel6 2011-06-10T23:20:00+04:00 http://hrafn.me/2011/06/bridge-kvm-again <p>Снова перевод очередной заметки из базы знаний Red Hat - <a href="https://access.redhat.com/kb/docs/DOC-57734">DOC-57734</a>.</p> <!--more--> <p><strong>Проблема</strong>: Как настроит бридж для KVM на Red Hat Enterprise Linux 5.5 без редактирования множества файлов вручную?<br/> <strong>Решение:</strong></p> <p>Хост должен быть доступен физически либо через последовательный порт, поскольку изменения в конфигурации сети могут привести к тому, что доступ по сети будет потерян. Необходимо произвести следующее:</p> <pre><code> # virsh net-list # virsh net-create bridge_custom (bridge name) default1 f7e96e6f-7946-46f4-96c4-29f288d88c21 ## Change 'forward mode' to 'route' </code></pre> <p>После этого новый файл конфигурации необходимо поместить в /etc/libvirt/quemu/networks/ с названием файла тем же, что и название бриджа.</p> <pre><code> # /etc/libvirt/qemu/networks/bridge_custom.xml </code></pre> <p>Затем определить новый бридж, используя команду, указанную далее:</p> <pre><code> # virsh define /etc/libvirt/qemu/networks/bridge_custom.xml </code></pre> <p>Для получения более подробной информации о конфигурации бриджа можно также посмотреть в этой статье:</p> <p><a href="https://access.redhat.com/kb/doc%0As/DOC-19071">https://access.redhat.com/kb/docs/DOC-19071</a></p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/MzsZEZE6H_w" height="1" width="1"/> http://hrafn.me/2011/06/bridge-kvm-again 2011-05-05T15:00:11+04:00 http://hrafn.me/2011/05/rh-knowledgebase-kak-vosstanovit-bazu-dannyx-rpm <p>Перевод заметки из базы знаний Red Hat: DOC-6904 (<a href="https://access.redhat.com/kb/docs/DOC-6904">https://access.redhat.com/kb/docs/DOC-6904</a>)</p> <!--more--> <p>Иногда база данных RPM "залипает". Одной из причин этой проблемы - убийство процесса, работающего с базой данных, что приводит к неверной информации о состоянии блокировки и ограничению доступа последующих процессов к базе данных. Так что, необходимо убедиться, что процесс действительно завис до того, как убить его - если процесс использует большое количество процессорного времени, то возможно, что он продолжает выполнять полезную работу. Информация о состоянии блокировки должна быть восстановлена вручную, чтобы устранить "зависание" и позволить rpm нормально функционировать.</p> <p>"Убийство" процесса (иногда это происходит при пропадании электропитания, иногда происходит в случае падения стороннего программного обеспечения без очистки информации о состоянии блокировки при выходе, иногда из-за нетерпеливого администратора) может привести к небольшим повреждениям базы данных RPM 'SleepyCat db'. В таком случае, необходимо удалить файлы, хранящие информацию о состоянии блокировки (эти файлы начинают с двух нижних подчеркиваний, например, "__db"). Так как эти файлы автоматически создаются заново при отсутствии, это достаточно безопасная операция.</p> <p><strong>Предупреждение: очень</strong> важно убедиться, что никакой запущенных процесс не обращается к базе данных RPM, перед тем, как удалять '/var/lib/rpm/<strong>db*'. Если такая проверка затруднена, удаление </strong>db* должно производиться в single user mode. В действительности, init-скрипты RHEL делают это автоматически, так перезагрузки обычно достаточно.</p> <p>Далее с осторожностью проделайте следующее:</p> <ol> <li><p>Перед попыткой восстановления базы, СНАЧАЛА сделайте резерную копию.</p> <p> # cd /var/lib # tar zcvf /var/preserve/rpmdb-[today's date].tar.gz rpm</p></li> <li><p>Проверьте целостность с помощью</p> <pre><code> # cd /var/lib/rpm # rm -f __db* # /usr/lib/rpm/rpmdb_verify Packages </code></pre></li> <li><p>Далее проделайте следующее:</p> <p> # mv Packages Packages.orig</p> <pre><code> # /usr/lib/rpm/rpmdb_dump Packages.orig | /usr/lib/rpm/rpmdb_load Packages # /usr/lib/rpm/rpmdb_verify Packages # rpm -qa </code></pre></li> <li><p>И в итоге восстановите базу данных</p> <p> # rpm -vv --rebuilddb</p></li> </ol> <p><strong>Дополнительная информация:</strong> Подробные заметки о восстановлении базы данных RPM можно найти здесь: <a href="http://people.redhat.com/berrange/notes/rpmrecovery.html">http://people.redhat.com/berrange/notes/rpmrecovery.html</a></p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/7641irHRJUI" height="1" width="1"/> http://hrafn.me/2011/05/rh-knowledgebase-kak-vosstanovit-bazu-dannyx-rpm 2011-05-04T14:57:54+04:00 http://hrafn.me/2011/05/usb-3-0-support-in-red-hat <p>Давненько я уже не переводил заметки из Red Hat Knowledgebase, так что вот еще одна :) <a href="https://access.redhat.com/kb/docs/DOC-55131">Оригинал</a></p> <h3>Вопрос:</h3> <p>Есть ли в Red Hat Enterprise Linux 5 поддержка USB 3.0?</p> <h3>Ответ:</h3> <p>USB 3.0 не поддерживается в RHEL5</p> <p>Поддержка доступна в RHEL6 при помощи модуля ядра '<strong>xhci_hcd</strong>'</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/Qq3XPkh9VS4" height="1" width="1"/> http://hrafn.me/2011/05/usb-3-0-support-in-red-hat 2011-04-19T13:17:27+04:00 http://hrafn.me/2011/04/fedora-and-infinality-patches <p>На мой взгляд, патчи для Cairo и Freetype от <a href="http://www.infinality.net/blog/">Infinality</a> довольно существенно улучшают отображение шрифтов в Fedora. Я долгое время ими пользовался. Кроме того, в случае, когда ставил Fedora другим людям, пакеты с патчами также ставил. Но в последнее время сталкиваюсь с проблемами при их использовании. Начнем по порядку.</p> <!--more--> <p>Обычно, после установки системы, я подключаю <a href="http://www.infinality.net/fedora/linux/">репозиторий Infinality</a> и ставлю пакеты оттуда. Пакеты следующие:</p> <pre><code>- cairo-freeworld - freetype-infinality - libXft-freeworld - fonts-config </code></pre> <p>Начиная примерно с альфа-версии Fedora 15, приходится не ставить совсем cairo-freeworld, иначе Иксы просто не запускаются. Как я понимаю, не совместимость с нынешним Xorg. Соответственно, внешний вид становится немного другим, но тоже вполне себе пригодный :)</p> <p>А вчера столкнулся с тем, что некоторые документы при попытке открытия с помощью Writer просто рушили как OpenOffice, так и LibreOffice. Проверял и на том, и на другом. Долго не мог понять, что происходит, пока не посмотрел в логи. Оказалось, офисный пакет падал с руганью на libfreetype. Уж не знаю, что не нравилось именно в этом конкретном документе, но после удаления freetype-infinality все стало нормально.</p> <p>Получается несколько странная ситуация, с которой я сталкивался при использовании OpenSUSE. Там многие полезные пакеты собираются в OBS. Но порой авторы этих сборок при выходе новой версии дистрибутива то ли забывают поддерживать далее свое творение, то ли просто не хотят. Я понимаю, что они и не обязаны делать это, но эффект получается неприятным. В данной ситуации происходит нечто подобное. Последние версии пакетов в репозитории относятся еще к октябрю-ноябрю прошлого года. Сейчас же пошла вторая половина апреля. И пока приходится искать какие-то способы обойти проблемные места. Но чувствую, что вся надежда на <a href="http://tigro.info/wp/">Tigro</a> :)</p> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/_58ZHVLmmDU" height="1" width="1"/> http://hrafn.me/2011/04/fedora-and-infinality-patches 2011-01-24T15:45:53+03:00 http://hrafn.me/articles/spacewalk-intro <p><a href="https://fedorahosted.org/spacewalk/attachment/wiki/WikiStart/logo.png?format=raw"><img src="https://fedorahosted.org/spacewalk/attachment/wiki/WikiStart/logo.png?format=raw" alt="" /></a></p> <p>Управление и котроль большого количества операционных систем не простая задача. Spacewalk - это инструмент , позволяющий сильно упростить выполнение этих задач. Он хранит информацию об оборудовании и программном обеспечении систем, позволяет управлять виртуальными системами, развертывать файлы, запускать скрипты и устанавливать программное обеспечение.</p> <!--more--> <p>В июне 2008 года компания Red Hat анонсировала проект Spacewalk, являющийся open source решением для управления Linux-инфраструктурой. Spacewalk представляет собой открытый по лицензии GPL2 продукт Red Hat Network Satellite Server, имеющий давнюю, с 2001 года, историю разработки.</p> <p>Вот как описывает Spacewalk <a href="http://markelov.blogspot.com">Андрей Маркелов</a>:</p> <p>Сервер Spacewalk обслуживает весь жизненный цикл Linux-инфраструктуры и решает следующие задачи:</p> <ul> <li>Сбор информации о системах (аппаратное обеспечение и установленное ПО)</li> <li>Установка и обновление операционных систем</li> <li>Установка и обновление программного обеспечения</li> <li>Установка систем при помощи kickstart-файлов</li> <li>Управление и распространение конфигурационных файлов</li> <li>Мониторинг систем</li> <li>Установка виртуальных машин</li> <li>Запуск/остановка/настройка виртуальных машин</li> <li>Работа с географически-распределенной сетью</li> <li>Автоматизация задач системного администрирования</li> <li>Распределение ролей администраторов и группировка систем</li> </ul> <p><strong>Управление программным обеспечением</strong></p> <p>Spacewalk позволяет управлять программным обеспечением и его обновлением на redhat-based дистрибутивах: Fedora, CentOS и Scientific Linux. Позволяет распространять контент среди различного окружения, управлять развертыванием обновлений на системах, а также позволяет отслеживать на какой стадии обновления находится конкретная система в данном окружении. Простой централизованный веб-интерфейс просматривать системы и их статус обновлений, кроме того, инициализировать процесс обновления.</p> <p><a href="http://spacewalk.redhat.com/img/screenshots/your_spacewalk.png"><img src="http://spacewalk.redhat.com/img/screenshots/your_spacewalk.png" alt="" /></a></p> <p><em>Пример главной страницы Spacewalk.</em></p> <p><strong>Другие возможности управления</strong></p> <p>Кроме управления программным обеспечением, Spacewalk обеспечивает возможность инициализации и мониторинга. Например, развертыват системы с помощью kickstart-файлов, так же как и управлять и распространять файлы конфигурации на системы. Функции мониторинга позволяет отслеживать статус систем рядом со статусом обновлений. Spacewalk также обладает поддержкой виртуализации, что позволяет подготавливать, контролировать, управлять и мониторить виртуальные гостевые системы Xen.</p> <p>Ниже я выложил еще несколько скриншотов:</p> <p><a href="http://spacewalk.redhat.com/img/screenshots/system-overview.png"><img src="http://spacewalk.redhat.com/img/screenshots/system-overview.png" alt="" /></a><em>Обзор системы.</em></p> <p><em><a href="http://spacewalk.redhat.com/img/screenshots/configuration-overview.png"><img src="http://spacewalk.redhat.com/img/screenshots/configuration-overview.png" alt="" /></a></em>Обзор конфигурации._</p> <p><a href="http://spacewalk.redhat.com/img/screenshots/system-set-manager.png"><img src="http://spacewalk.redhat.com/img/screenshots/system-set-manager.png" alt="" /></a><em>System Set Manager.</em></p> <p><a href="http://spacewalk.redhat.com/img/screenshots/kickstart_overview.png"><img src="http://spacewalk.redhat.com/img/screenshots/kickstart_overview.png" alt="" /></a><em>Обзор профиля kickstart.</em></p> <p>Надеюсь, что из супермаленького обзора более-менее понятно, что из себя представляет данный продукт. Процесс установки здесь и сейчас описывать не буду. Для этого будет отдельная заметка. Лучше посмотрим другие вещи.</p> <p>На данный момент последняя версия - 1.2. Вышла 19 ноября 2010 года. Некоторые интересные моменты в этом релизе:</p> <ul> <li>некоторые страницы веб-интерфейса были переписаны с Perl на Java</li> <li>расширена локализация</li> <li>ограниченная поддержка PostgreSQL в качестве бэк-энда, количество операций пока ограничено</li> <li>поддержка работы на Fedora 14</li> <li>Fedora 12 поддерживается последний выпуск, далее поддержки не будет</li> </ul> <p>А вот что позволяет Spacewalk при работе с PostgreSQL:</p> <ul> <li>синхронизация контента с помощью satellite-sync и spacewalk-repo-sync</li> <li>rhnpush</li> <li>регистрация клиентов</li> <li>работа с yum</li> </ul> <p>Таким образом, на данный момент возможно использование Spacewalk с PostgeSQL для управления программным обеспечением на машине. К сожалению, полная поддержка этой базы данных заявляет в версии 2.0. А вот что предполагается сделать в ближайших релизах:</p> <ul> <li>поддержка RHEL6</li> <li>плагин для apt-get</li> <li>поддержка клиента Oracle 11g</li> </ul> <p><strong><em>Использованные ресурсы:</em></strong></p> <ul> <li><a href="https://fedorahosted.org/spacewalk/"><em>https://fedorahosted.org/spacewalk/</em></a></li> <li><a href="http://markelov.blogspot.com/2008/08/spacewalk-open-source-linux.html"><em>http://markelov.blogspot.com/2008/08/spacewalk-open-source-linux.html</em></a></li> <li><a href="http://spacewalk.redhat.com/"><em>http://spacewalk.redhat.com/</em></a></li> </ul> <img src="http://feeds.feedburner.com/~r/hrafnme/~4/7XE0RvhUP7w" height="1" width="1"/> http://hrafn.me/articles/spacewalk-intro