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

Дело в том, что в Google применяется защита соединений по SSL для поиска, Gmail и Drive. В будущем применение криптографии только увеличится.

В течение последнего времени у сетевых администраторов была возможность заказывать опцию «безопасного» поиска (SafeSearch), что особенно актуально для школ и университетов, где поиск «клубнички» в интернете с учебных компьютеров не слишком поощряется. Однако, эта функция означает, что поисковые запросы в Google отправляются через незашифрованные соединения. К сожалению, на практике некоторые враждебные группы и организации используют такую слабость настроек, чтобы перехватывать чужие поисковые запросы. Поэтому Google решила убрать эту опцию. Решение введут в силу примерно в начале декабря.

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

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

Apache OpenMeetings

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

Система веб-конференций Apache OpenMeetings позволяет организовать проведение аудио- и видеосовещаний в многоточечном режиме, когда к серверу подключены десятки человек. За несколько лет проект сменил несколько команд и лицензий, в том числе был в Google Code (под лицензией Eclipse Public License). Последняя его дислокация — инкубатор Apache, соответственно, поменялась и лицензия, на Apache License 2.0. Последняя официальная версия 2.0 вышла в конце июля 2012 года.

Совместная работа с документом в OpenMeetings

Главный плюс — для видеосовещания не требуется установка дополнительного ПО, достаточно веб-браузера с плагином для поддержки технологии Flash. Предусмотрена возможность записи и последующего проигрывания совещаний и экспорта в AVI/FLV-файл, импорт в конференцию документов более чем 20 форматов и изображений. Участники могут скачать загруженный файл и совместно редактировать, вводя текст поверх оригинала, рисовать и помечать интересные места. Сами конференции могут быть открытыми и частными. Поддерживается два режима:

• совещание — до 16 участников, каждый может передавать аудио- и видеоданные;
• лекции — до 200 участников, передача аудио и видео только у модератора/лектора.

Предусмотрен также обмен текстовыми сообщениями в окне чата или приватными (используется встроенный Jabber-сервис). Настройки позволяют создать опрос. Модератор, организующий конференцию, отправляет всем участникам приглашение, содержащее прямую ссылку, он же управляет всеми доступными им возможностями. У каждого зарегистрированного пользователя имеется календарь событий с напоминанием о событиях (через электронную почту или iCal). При подключении выбирается вариант участия (видео + аудио, только видео или аудио, рисунки), разрешение и устройство. Настройки в комнате просты и понятны каждому, пользователь, впервые работающий с сервисом, быстро освоится. Возможна интеграция OpenMeetings с другими продуктами — сервером VoIP Asterisk, системой управления обучением Moodle, Drupal, Joomla, SugarCRM и некоторыми другими.

Реализовано три уровня доступа — пользователь, модератор и администратор сервера. Для аутентификации возможно использование внутренней базы или сервиса LDAP / Active Directory (в $RED5_HOME/webapps/openmeetings/conf найдешь готовые шаблоны для подключения). Возможна работа нескольких серверов OpenMeetings в кластере, одна установка может обслуживать несколько организаций.

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

Построен OpenMeetings с использованием технологий Java и XML. Для организации сервера задействуются: веб-сервер Apache Tomcat, Open Source Flash/RTMP Server Red5, OpenOffice.org/LibreOffice. В качестве базы данных может быть использована MySQL, PostgreSQL, Oracle, DB2 или Apache Derby. Предлагается демосайт, на котором можно познакомиться с основными возможностями OpenMeetings. Соединение с сервером осуществляется по протоколам HTTP (порт 5080), RTMP (порт 1935), RTMPT (порт 8088). Встроенный менеджер создания резервных копий упрощает резервирование и восстановление работоспособности сервера и перенос в другую систему.

Выбор устройства при подключении к конференции в OpenMeetings

Компоненты мультиплатформенные, поэтому сервер будет работать на любой *nix-системе или Windows. Установку OpenMeetings сложной назвать нельзя, процесс просто требует должной внимательности, в последующем эксплуатация особых хлопот не вызывает.

Требования к оборудованию невысоки, минимальные, которые указаны на сайте, — компьютер с процессором 1 ГГц CPU и 1 Гб ОЗУ. Но для конвертирования документов, загрузки файлов и записи видео этой мощности не хватит. В качестве рекомендуемых указан компьютер 2x/4x 2 ГГц (32/64 бит) и 4 Гб ОЗУ. Для организации 100 соединений достаточно компьютера класса Pentium 4 с 2 Гб ОЗУ.

BIGBLUEBUTTON

Первая версия BigBlueButton была написана в 2007 году одним из сотрудников Карлтонского университета г. Оттава, Канада (Carleton University), при поддержке программы развития инновационных технологий и управления. Изначально продукт носил имя Blindside, но позже название было изменено на BigBlueButton, чтобы отразить простоту в использовании — для начала конференции нужно всего лишь нажать символическую синюю кнопку. Именно в простоте преимущество BBB перед более функциональным и оснащенным, а значит, и чуть более сложным OpenMeetings. Проект некоторое время искал свое место и сегодня ориентирован на организации, предлагающие услуги дистанционного образования, позволяя проводить обучение через интернет. Особая роль в этом процессе отводится одной из функций — видеоконференции. Но BBB с таким же успехом может быть использован для простого общения, проведения брифингов и вебинаров. В 2009 году была организована компания Blindside Networks для оказания платной поддержки пользователям продукта. Наиболее серьезным толчком к разработке продукта послужило участие в Google Summer of Code в 2010 году. Именно тогда был добавлен API, позволяющий подключать сторонние приложения, и сегодня встроить BBB можно в Sakai, WordPress, Moodle, Joomla, Redmine, Drupal, Matterhorn, LAMS и некоторые другие. Эта возможность более всего востребована пользователями BBB, поэтому из настроек сервера был убран интерфейс администратора: разработчики просто не видят смысла его развивать, так как управление ложится на плечи того, кто встраивает приложение. В случае отдельного сервера все установки можно без проблем произвести при помощи конфигурационных файлов BigBlueButton и возможностей веб-сервера. Проект находится на стадии активной разработки, причем следует отметить особую щепетильность в этом вопросе. Например, выходу версии 0.8 Bailetti предшествовали четыре беты и три RC. Недавно проект присоединился к бизнес-инкубатору для открытых проектов WebFWD («Web Forward»), который поддерживает Mozilla.

BigBlueButton позволяет организовать конференцию нажатием одной кнопки

BigBlueButton обеспечивает многопользовательские аудио- и видеоконференции, чат и обмен личными сообщениями (в качестве клиента поддерживается только собственный Java-апплет BigBlueButton), запись лекций (слайды, аудио и чат) для дальнейшего воспроизведения (используется HTML5, поддерживается пока FF и Chrome), предоставление общего доступа к рабочему столу для практического показа работы с приложениями и ОС, загрузку презентации в формате PDF (и любом другом, поддерживаемом OpenOffice.org/LibreOffice), функции рисования и виртуальную указку. Реализован автоматический перевод при общении в чате пользователей на разных языках. Для подключения к серверу достаточно использовать веб-браузер с поддержкой Adobe Flash, то есть это может быть любой компьютер, работающий под управлением Windows, *nix или Mac OS X. Ведется разработка клиента для Android. Конференции могут быть двух видов: открытые (может подключиться любой зарегистрированный пользователь) и закрытые. В случае приватной конфы список допущенных формирует сам выступающий, высылая им данные для доступа. Пользователи в конференции могут быть в роли выступающего, модератора (по умолчанию получает создатель конференции) и слушателя. Работа виртуального лектора мало отличается от реального: кроме видео, он загружает документы, используя указку, акцентирует внимание на важных моментах, включает аудио выбранного слушателя. Модератор может назначить любого пользователя выступающим, тогда все внимание будет переключено на него. Интерфейс пользователя позволяет приблизить отдельные фрагменты, чтобы лучше рассмотреть их, привлечь внимание, «подняв руку», общаться в групповом или приватном чате. Модератор полностью контролирует возможности присутствующих, при необходимости отключает пользователя или переводит в режим «только просмотр». Поддерживается разрешение 320 × 240, 640 × 480, 1280 × 720, на количество подключений BBB каких-либо ограничений не накладывает.

В своей работе BBB использует более десятка Open Source приложений: FreeSWITCH, nginx, Flash-медиасервер Red5, MySQL, ActiveMQ, Tomcat, Redis, Grails, Xuggler, OpenOffice.org, Image Magick, SWFTools и другие. Ранее в этом списке был IP-PBX Asterisk с модулем для управления конференциями app_konference, но в последних версиях разработчики отказались от данной связки в пользу FreeSWITCH, так как последний не требует дополнительных усилий при реализации функции записи.Веб-интерфейс BBB переведен на 40 языков, в этом списке есть и русский.

Для работы BigBlueButton рекомендуется сервер с CPU Dual Core 2,6 ГГц, 2 Гб ОЗУ и место на жестком диске с учетом записи трансляций. Количество пользователей, которые смогут одновременно общаться на сервере, зависит от мощности оборудования и пропускной способности канала. Отдельный поток требует 30–50 Кб/с. Приблизительные расчеты можно найти в FAQ, там же приводятся данные стресс-теста. Для подключения клиентов по умолчанию используется стандартный 80-й порт, который не должен быть занят другим приложением. В правилах брандмауэра должны быть открыты порты 80 (HTTP), 935 (RTMP) и 9123 (общий рабочий стол).

Функция трансляции рабочего стола в BigBlueButton

Доступен исходный код, позволяющий установить BBB на любой компьютер, работающий под управлением Linux, FreeBSD, Mac OS X или Windows. Для Ubuntu и CentOS есть готовые пакеты и репозитории. Сервер BBB может работать в облачной среде вроде Amazon EC2.

Документация на сайте проекта весьма подробна, в ней можно найти ответы практически на все возникающие вопросы — по установке (есть готовые конфиги), конфигурированию, API, локализации, настройке отдельных компонентов (VoIP, nginx и подобных) и прочим моментам. Свои вопросы можно задать в списке рассылки, предлагается несколько видеоруководств. Доступны образ VM и демосервер, позволяющие познакомиться с основными возможностями BBB, не устанавливая систему.

CISCO WEBEX

Чтобы общаться с группой людей, не обязательно устанавливать свой сервер или закупать оборудование, в некоторых случаях достаточно и SaaS. Так, Google Talk и Skype позволяют собрать аудиоконференцию на несколько пользователей. Кроме того, Skype для бизнес-пользователей (для home требуется Premium-подписка) позволяет организовать видеоконференции до десяти участников. Стоимость подписки относительно невысока, а возможностей вполне достаточно для небольших организаций. Но одно из самых популярных SaaS-решений — сервис веб-конференций Cisco WebEx, который предлагает качественную видео- и аудиосвязь, не требуя установки специализированного оборудования. По сути, это удобная платформа для общения, удаленного обучения и совместной работы, где реализованы все необходимые функции: предварительное обсуждение материалов, screen-sharing, whiteboard, удаленный контроль компьютера, презентации, VoIP, видео в HD-формате, чат, запись совещания на сервере или клиенте, календарь и прочее. Возможно предоставление участникам разного рода анкет для заполнения. Приглашение можно разослать при помощи e-mail, по телефону или через IM-клиент. Причем аудио-конференц-связь возможна не только через VoIP, но и через мобильный/стационарный телефон. Также WebEx интегрируется с WebEx Social и приложениями MS Office, позволяя совместно редактировать и публиковать документы. При помощи специального плагина пользователь публикует материалы и планирует совещания в MS Outlook, полученное приглашение сразу добавляется в календарь. Для доступа к видеоконференции пользователю достаточно подключиться к ней при помощи браузера. Доступны клиенты для iPhone, iPad, Nokia и BlackBerry. Соединение защищено при помощи SSL. Интерфейс очень простой, хотя и не локализованный. Распространяется по подписке, в настоящее время реализовано четыре уровня доступа — Free (до трех участников, видео стандартного качества, 250 Мб места на диске для файлов), Premium 8, Premium 25 (соответственно до 8 и 25 участников, 1 Гб места и дополнительные функции) и Enterprise (до 500 участников). Чтобы активировать Free-аккаунт, достаточно просто зарегистрироваться (на 14 дней дают еще и тестовый Premium), указав валидный e-mail.

Планирование конференции в WebEx

TRUECONF SERVER

Сервер видеоконференций TrueConf Server поддерживает несколько режимов вещания: персональное, симметричная многоточечная конференция (до 16 равноправных участников), видеовещание (до 16 участников, но активен только один), ролевое видеовещание (3 активных участника, до 120 пользователей). В последнем случае пользователи не могут разговаривать друг с другом, но в их распоряжении другие встроенные средства TrueConf — чат, обмен файлами, электронная доска для совместной работы над документом, демонстрация слайд-шоу. Качество может варьироваться от 320 × 240 до HD (1280 × 720). Реализована возможность записи конференции, адресная книга и панель статусов. Пользователь может показать свой рабочий стол другим участникам, которые, в свою очередь, получив разрешение, им управляют. Группы пользователей получают различные права, разграничивающие возможности по использованию системы. Для подключения к конференции требуется Windows-ПК (после установки сервер генерирует клиент TrueConf Client) или специальное оборудование. Доступен также клиент для Android. При помощи отдельного продукта TrueConf Gateway возможно использование H.323/SIP видеотерминалов.

Продукт появился в 2003 году и первоначально распространялся под названием VideoPort VCS, новое имя TrueConf получил в 2011 году. Разрабатывается российской компанией, а поэтому учитывает местные реалии. В частности, нетребователен к качеству соединения, может использовать любые каналы, в том числе и спутниковые, работает из-за NAT. В программе заложена динамическая регулировка битрейта и технология SVC (Scalable Video Coding), позволяющая передавать в одном потоке несколько подпотоков видео различного качества. Список поддерживаемых видеокодеков включает WebM и Cyclon. Последний собственной разработки, не требует мощного CPU и обеспечивает малые задержки, а поэтому применяется на низкоскоростных линиях. Такой эффект достигается в том числе и за счет того, что кодек в первую очередь распознает лица участников видеоконференции. Для асимметричной конференции используется UDP Multicast.

Выбор варианта проведения конференции в TrueConf

Для установки сервера понадобится Win2k/2k3/2k8. Сам процесс, можно сказать, тривиален, справиться с ним может любой пользователь. В firewall нужно лишь открыть порты 4307 и 4310. Доступна также SaaS-версия TrueConf — TrueConf Online, позволяющая организовывать конференции по подписке, не разворачивая инфраструктуру. Пользователю требуется веб-камера, микрофон и браузер. Предлагается несколько вариантов лицензий, в бесплатной возможна только индивидуальная видеосвязь.

MICROSOFT LYNC SERVER

Корпорация Microsoft не могла не посчитаться с тенденциями развития IT-рынка и предложила свой сервер коммуникаций (MS Lync Server, ранее Office Communications Server, версия 2007 R2 которого еще продается), предоставляющий возможности организации не только аудио-, видео- и веб-конференций, но и телефонной связи (голосовая почта, перевод звонков, групповые вызовы и тому подобное), систему IM, передачу файлов, контроль присутствия и многое другое. Возможна интеграция с Asterisk и Skype, при помощи шлюзов сторонних производителей Lync подключается к SIP или телефонным сетям. Реализованы возможности совместного доступа к рабочему столу, функция виртуальной доски для одновременной работы с документом или обучения сотрудников. Для тех, кто переписывается с иностранными партнерами, предлагается плагин Conversation Translator (Lync Guistic), позволяющий автоматически переводить сообщения при помощи сервиса переводчика Bing. Пользователь может подключиться к конференции при помощи обычного или мобильного телефона. Естественно, Lync интегрируется с многими продуктами Microsoft — Exchange, SharePoint, Office и Office 365. Пользователям последнего нет необходимости разворачивать свою инфраструктуру, достаточно подключиться к Lync Online. Приглашения для участия в конференции по умолчанию отправляются при помощи Outlook. Можно организовать несколько конференций и переключаться между ними. Есть возможность выбора пользователя, от имени которого конференция будет начата. Участник, имеющий слово, будет выделен, и камера автоматически переключается на него. Подсоединиться к собраниям можно несколькими способами: установив клиент Lync 2010 или Lync 2010 Attendee, через веб-браузер с поддержкой Silverlight (Microsoft Lync Web App) или клиент Office Communicator. Пользователю, получившему приглашение, будет предложен один из этих вариантов. Кроме того, поддерживается ряд IP-телефонов «Optimized for Lync» (некоторые модели можно найти на сайте MS — goo.gl/C3fGb). Для проведения видеоконференций также не требуется специальное оборудование, хотя здесь предлагаются совместимые комплекты MS RoundTable, делающие общение более комфортным. Доступен клиент Lync Mobile для WP7, Android, iOS, Symbian и BlackBerry, который упрощает подключение к конференции, имеет функции поиска адресата и сведений о присутствии сотрудника.

Благодаря своим возможностям, Lync Server будет интересен тем организациям, которые используют Windows и строят или реорганизуют свою ИТ-инфраструктуру.

Заключение

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

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

Компания Facebook и раньше пыталась сделать нечто подобное, и довольно успешно. Например, в 2012 году запустили проект регистрации доноров. В первый день, когда Facebook запустил эту инициативу, 13 054 человека в США зарегистрировались донорами, что в 21 раз больше среднесуточного количества регистраций в донорской программе (616).

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

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

Что касается «улучшения образа жизни людей», то снимать данные с фитнес-трекеров и публиковать их в онлайне — новый модный тренд у ИТ-компаний. Этим занимаются множество мелких стартапов, которые производят и продают фитнес-трекеры. Людям тоже нравятся меряться пиколичеством сделанных шагов и пройденного расстояния на велосипеде. За это дают разные бэджики и «ачивки».

Facebook пока не начал собирать данные с фитнес-трекеров. Но если он заинтересовался здравоохранением, то ждать осталось недолго.

А вообще, сбором медицинских данных всерьёз намерена заниматься и компания Google, если ей разрешат регулирующие органы. Ларри Пейдж как-то обмолвился, что из-за существующих запретов на сбор конфиденциальной информации только в США в следующем году умрут 100 000 человек, которым Google могла бы спасти жизнь.

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

Настройку большого количества серверов упрощают системы управления конфигурациями Chef, Puppet, CFEngine, позволяющие быстро привести сервер в нужное состояние. Но задачи автоматизации часто выходят за рамки возможностей инструментов, а в сложных средах число различных параметров и флажков к рецептам начинает превышать число рецептов. В итоге инструменты сами становятся источником проблем. Использование Rundeck позволяет объединить и контролировать все, что есть.

Возможности Rundeck

Rundeck представляет собой кросс-платформенный инструмент, позволяющий автоматизировать в ЦОД любые команды, скрипты и процедуры. Созданные при помощи командной строки или через веб-интерфейс задачи могут быть запущены по требованию или по расписанию на любом количестве узлов, администратор получает полную информацию о ходе и результате выполнения. Доступны и другие необходимые в распределенных средах возможности: контроль доступа, создание цепочки событий (многошаговый сценарий), планирование, история и аудит. Проект возник не на пустом месте. Он основан на ControlTier, от которого Rundeck отделился в 2010 году. Со временем большинство разработчиков перешли в новый проект, как более перспективный. В Rundeck был опробован и реализован так называемый сценарий-ориентированный подход, создан интерфейс для фильтрации команд и скриптов для наборов узлов и предложена возможность использовать внешние поставщики данных. В отличие от монолитного ControlTier, Rundeck поддерживает возможность интеграции с другими инструментами: Puppet, Chef, Vagrant, Jenkins, Nexus, Git и Amazon EC2. Практически все дополнительные функции подключаются в качестве плагинов, которые представляют собой файлы, обеспечивающие поддержку одного или нескольких сервисов (Service Provider). Реализовано несколько типов плагинов, позволяющих добавить шаг рабочего процесса, описание нод (Resource Model), механизм исполнения и копирования файлов, предупреждения. Правда, в настоящее время реализованы в основном плагины, предоставляющие возможность получать информацию о нодах. Ссылки на некоторые плагины можно найти, перейдя по адресу.

Создаем новый проект

По сути, Rundeck является связующим звеном, объединяющим все средства управления, он позволяет из одной точки управлять заданиями и отслеживать результат. То есть информацию об узлах мы можем брать прямо с аккаунта Amazon EC2, а сервис разворачивать при помощи shell или Chef, но запускать все это средствами Rundeck, организуя в единое задание с другими скриптами и командами. Сами задания объединяются в проекты, а проекты — в группы. Задания можно выполнять параллельно сразу на всех узлах или последовательно. Предусмотрено оповещение о результате выполнения работы посредством email или отправки POST-запроса по определенному URL.

Rundeck представляет собой серверное приложение. Информация и история заданий хранится в базе данных, выходные данные команд и задания сохраняются в виде XML-файлов на диске. Кроме GUI и CLI, также доступен Web API, позволяющий взаимодействовать с сервером Rundeck в программах и скриптах.

Принцип работы прост. Администратор вводит команду и выбирает по фильтру узлы, запуская задание (Node Execution). Каждый узел представлен как Resource Model и имеет определенные признаки (параметр: значение), которые могут быть расширены. Например, теги позволяют быстро отобрать группу нод по некоторому критерию.

Добавляем команды, подключаем фильтры

Развертывание Rundeck упрощает то, что не нужно устанавливать на нодах клиентское ПО (этим он отличается от ControlTier). Для управления удаленными системами и передачи файлов по умолчанию используется SSH/SCP. Это очень удобно, так как даже для того, чтобы выполнить простую команду, не надо логиниться на каждом сервере. При этом довольно просто можно подключить любой другой механизм (среди плагинов доступен WinRM) или использовать внешний скрипт.

При создании проекта доступен вариант Stub, позволяющий просмотреть запускаемые команды без выполнения. Это очень полезно, когда требуется понять, что именно будет сделано.

Поддерживается контроль доступа на основе политик, а также интеграция с LDAP и AD. Написан Rundeck на Java, его можно установить на все популярные ОС — Linux, Windows, Solaris и OS X.

Ставим Rundeck

Для установки в Linux предлагается DEB-пакет, RPM-репозиторий и универсальный launcher. Рекомендуется использовать возможности пакетных менеджеров дистрибутива, в этом случае будут созданы все необходимые файлы. В Ubuntu и Debian процесс очень прост.

$ wget -c http://download.с.org/deb/rundeck-1.5.3-1-GA.deb
$ sudo dpkg -i rundeck-1.5.3-1-GA.deb

Конфигурационные файлы сервиса находятся в каталоге /etc/rundeck, здесь можно установить параметры среды и работы сервиса, настроить ACL (admin.aclpolicy), включить SSL, указать настройки проекта по умолчанию (project.properties) и так далее. Их можно пока не трогать, достаточно просто познакомиться, чтобы знать, что где лежит. По умолчанию демон не запущен:

$ sudo service rundeckd start

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

$ sudo java -jar rundeck-launcher-1.5.3.jar

Подключаемся к веб-интерфейсу localhost:4440 (при необходимости порт можно изменить в файле framework.properties, параметр framework.server.url), по умолчанию создаются две учетные записи: «admin/admin» и «user/user».

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

Выпадающий список позволяет выбрать проект, но проектов пока нет. При первом входе пользователь будет сразу переброшен на страницу создания нового проекта. В самом простом случае достаточно ввести имя, остальные периметры можно заполнить потом. Для создания проекта в консоли используется утилита rd-project:

$ rd-project -a create -p examples
Project structure created: /var/rundeck/projects/examples

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

$ sudo chown -R rundeck:rundeck /var/rundeck/projects/examples

Основные настройки проекта содержатся в конфигурационном файле project.properties, который находится в подкаталоге etc папки проекта. В нем настроек пока немного.

$ sudo cat /var/rundeck/projects/examples/etc/project.properties
project.name=examples
project.resources.file=/var/rundeck/projects/examples/etc/resources.xml

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

Нажимаем в браузере и видим вновь созданный проект. Чтобы познакомиться с интерфейсом, можем просмотреть процесс выполнения любой команды на локальной системе. Вводим ее в поле Command, появляется секция «Now running», отображающая процесс и позволяющая просмотреть подробную информацию (консольный аналог — команда rd-jobs). Ссылка рядом дает возможность завершить задание.

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

Ссылка «Save As Job» позволяет сразу сохранить команду (ad-hoc command) для последующего быстрого вызова или создать новую задачу. Задание отличается возможностью запуска по расписанию и отправки предупреждений. Просто заполняем предложенные поля, указываем имя, группу, выбираем проект, вводим описание, отправку оповещения о результате, периодичность выполнения и уровень журналирования.

Чтобы добавить в группу дополнительные команды, скрипты, скрипты с URL, запуск локальной команды и других заданий, выбираем ссылку «Add step». Часть параметров понятна и без описания, другие требуют объяснения:

• флажок «Multiple Executions?» разрешает одновременное выполнение задания;
• параметр «Workflow: Strategy:» определяет порядок выполнения — последовательно (Node-oriented) или параллельно (Step-oriented);
• «Workflow: Keepgoing:» — установлена в «No», то есть в случае ошибки на любом из этапов выполнение прерывается, переопределить можно, изменив на «Yes».

Если флажок «Dispatch to Nodes» снят, команда или задание выполняется только на локальной системе. После его установки открывается поле, позволяющее задать другие системы и установить Include/Exclude фильтры (тег, ОС, версия ОС, архитектура и другие), в том числе поддерживаются и регулярные выражения. Фильтры можно сохранять для дальнейшего использования (ссылка «Save this filter…»). По нажатию «Options» активируется безопасный вывод (позволяет скрыть пароли), здесь можем указать дополнительные параметры, которые задаются локально (в JSON-формате — Имя: значение) или подгружаются с удаленного узла.

Результат может быть показан в нескольких видах и сохранен в файл

Подключаем ноды

Каждый проект содержит как минимум один файл описания ресурсов resources.xml (Resource Model), но при необходимости можно использовать несколько файлов, рассортировав их по каталогам или URL. Каждое описание позволяет однозначно определять ноды. Минимально требуется указать только имя узла, под которым оно будет показано в интерфейсе, и его сетевое имя или IP, опционально задаются и другие параметры — теги, ОС, архитектура и другие. В resources.xml уже будет описание локальной системы:

$ sudo cat /var/rundeck/projects/examples/etc/resources.xml
<project>
 <node name="localhost" description="Rundeck server node" tags="" hostname="localhost" osArch="amd64" osFamily="unix" osName="Linux" osVersion="3.2.0-23-generic" username="rundeck"/>
</project>

Конфигурационные файлы проекта

Если учетная запись входит в группу «Admin», справа вверху появится надпись «Admin» и значок гаечного ключа. Выбрав этот пункт, можно просмотреть состав групп, добавить плагины, изменить и экспортировать настройки проекта.

По умолчанию предлагается получать список ресурсов с удаленного узла, URL которого прописывается в «Resource Model Source URL». Чтобы задать файл ресурсов, каталог, содержащий файлы с описаниями, скрипт и URL, выбираем «Resource Model Sources». Очень удобно, что проект может поддерживать сразу несколько источников. Например, часть нод выбирается из статического файла, а часть генерируется CGI-скриптом. Файл ресурсов — самый простой способ, он может быть в формате XML или YAML. Для небольших проектов достаточно прописать нужное количество нод, добавив новую секцию «node name» в resources.xml. При помощи дополнительных параметров username, password, port указываются учетная запись и порт для соединения с узлом, если они отличаются от установок по умолчанию.

Добавляем новый источник Resource Model

Плагины позволяют расширить эти возможности, подключая Resource Model, прописанные в файлах Chef, Puppet, Amazon EC2 и других. Например, плагин Amazon EC2 подключается очень просто:

$ sudo apt-get install gradle
$ wget -c https://github.com/gschueler/rundeck-ec2-nodes-plugin/archive/master.zip
$ unzip master.zip
$ cd rundeck-ec2-nodes-plugin-master
$ ./gradlew
$ cp ./build/output/lib/rundeck-ec2-nodes-plugin-1.3.jar /var/lib/rundeck/libext

Теперь при выборе «Add Source» появится новый тип «AWS EC2 Resources». Плагин поддерживает большое количество дополнительных опций, например автоматическую расстановку тегов.

На данный момент мы подключили все узлы и можем выполнять на них команды и скрипты через веб-интерфейс или в командной строке. Для примера получим список всех текущих ресурсов проекта и выполним команду по фильтру os-family:

$ sudo dispatch -p examples -v
$ sudo dispatch -I os-family=unix -- uptime

Используем Chef

Основная мощь Rundeck проявляется в совместном использовании с другими средствами автоматизации, вроде Chef или Puppet. Принцип взаимодействия ничем не отличается от обычной работы. При создании задания указываем скрипт, в котором расписаны все шаги, или прописываем их отдельно при помощи «Add step». Например, у нас есть готовый cookbooks и два файла (solo.rb, node.json), необходимые для работы chef-solo, которые загружены на веб-сервер. Необходимо установить Chef и выполнить. Прописываем в проект несколько новых шагов:

echo "deb http://apt.opscode.com/ precise-0.10 main" | sudo tee /etc/apt/sources.list.d/opscode.list
apt-get update
apt-get -y --force-yes install opscode-keyring chef git
chef-solo -c http://example.com/solo.rb -j http://example.com/node.json -r http://example.com/chef-cookbooks.tar.gz

Это самый простой пример. Но если имеем нескольких узлов, отличающихся парой параметров, нам не нужно все это прописывать в cookbooks, создавая путаницу. Теперь мы можем очень просто разделить общее и частное, да и процесс отбора нод стал гораздо проще. И что не менее важно, по окончании задания администратору в понятной форме выводится результат. Вот в этом и есть большой плюс Rundeck.

Просмотр узлов проекта в командной строке

Как минимум два плагина позволяют легко управлять Windows-машинами при помощи WinRM: Rundeck WinRM Plugin и Knife Windows. Второй использует утилиту knife из Chef. Ставим:

$ sudo gem install knife-windows

Прописываем в проект информацию о Windows-сервере:

$ nano resources.xml
<project>
<node name="win2008" description="Windows server node" tags="win2008" hostname="win2008" osArch="Windows" osFamily="windows" osName="windows" osVersion="2008" username="Administrator" password="p@ssw0rd" port="80"/>
</project>

На Win2008-сервере настраиваем возможность удаленного подключения:

C:\Users\Administrator> winrm quickconfig -q

Проверяем из консоли:

$ winrs -u:administrator -p: p@ssw0rd -r:http://win2008 dir
$ knife winrm -m win2008 -P 'p@ssw0rd' -p 80 -x Administrator dir

Если получаем ответ, можем подключать к проекту, изменив программу выполнения (NodeExecutor), используемую по умолчанию:

$ nano project.properties
service.NodeExecutor.default.provider=script-exec
plugin.script-exec.default.command=knife winrm -m ${node.hostname} -P '${node.password}' -p ${node.port}-x ${node.username} ${exec.command}

Теперь можно отдавать команды удаленной Windows-системе. На сайте проекта даны ссылки не на все плагины. Поискав в интернете, можно найти много полезного. Например, скрипт для удобного бэкапа и восстановления заданий Rundeck — rundeck-backup. Однако при выборе плагина следует проверять, с какой версией Rundeck он будет работать. Некоторые плагины давно не поддерживаются и не совместимы с последними релизами Rundeck.

$ sudo apt-get -y install fabric

$ fab -H system1,system2 -- uname -a

WWW

Описание ACL: bit.ly/16oVyNk

Плагин Amazon EC2: bit.ly/131T0rp

Скрипт для удобного бэкапа Rundeck: bit.ly/11UqOjv

Rundeck WinRM Plugin: bit.ly/14entO8

Плагин Knife Windows: bit.ly/gHzhJT

Заключение

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

Продолжаем публиковать обзоры Open Source проектов, наиболее популярных на сайте Github за неделю.

1. Bootstrap Material Design: реализация «материального» дизайна, придуманного в Google, в теме для Bootstrap 3. Так что скоро мы увидим эти яркие цвета не только в приложениях для Android L, но и на веб-сайтах.

2. Psychson: набор необходимых файлов для создания вредоносной флэшки (BadUSB): десктопная программа для установки коммуникаций с флэшкой; приложение для снятия дампа прошивки; программы для установки патчей с разными нагрузками и записи прошивки обратно во флэшку, а также готовые сторонние прошивки.

Список поддерживаемых устройств (пополняется):

• Patriot 8GB Supersonic Xpress
• Kingston DataTraveler 3.0 T111 8GB
• Silicon power marvel M60 64GB
• Toshiba TransMemory-MX™ Black 16 GB
• Patriot Stellar 64 Gb Phison

3. Sweetalert: красивая замена для стандартного алерта в JavaScript.

4. Physical Web: эксперимент по привязке повседневных физических объектов к статичным URL и взаимодействию с ними в браузере.

5. Midnight.js: плагин jQuery для смены фиксированных хедеров (nav) на лету, демо.

6. Awesome Shell: модерируемый список фреймворков, тулкитов, руководств и других штучек для командной строки.

7. Gifshot: мощная JS-библиотека, которая создаёт анимированные GIF’ы из медиапотоков, видеороликов или статичных изображений, официальный сайт. Библиотеку можно легко интегрировать на любой веб-сайт: например, чтобы пользователи записывали анимированные GIF’ы со своих веб-камер.

8. JuliusJS: библиотека распознавания речи в реальном времени для веба, демо.

9. Awesome SVG: модерируемый список файлов SVG.

10. Reddit: код, на котором работает популярный сайт Reddit.

SmartOS — одна из ветвей дерева, растущего из корней легендарной ОС Solaris. Несмотря на экзотичную «родословную», эта платформа активно развивается и уже сегодня позволяет добиваться высокой скорости работы и внедрять некоторые фишки, недоступные в более привычном Linux. Эта статья рассказывает о нашем опыте работы со SmartOS.

WWW

• Официальная страница для скачивания SmartOS
• Инструкция по записыванию SmartOS на флешку
• Таблица соответствий команд Linux и SmartOS

Введение (как я узнал про SmartOS)

В конце 2012 года у меня на проекте не хватало JS-программеров для изучения Node.js. И я решил восполнить пробел самостоятельно. Изучил фреймворк, написал «Hello world» и даже немножко больше, ведь на Node.js основан яндексовский инструментарий для работы по методологии БЭМ, который мы захотели использовать в том проекте. А когда что-то берешь для своего проекта, это почти всегда нужно патчить… Но речь пойдет о другом.

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

Оказалось, что SmartOS — это потомок ОС OpenSolaris, которая была похоронена компанией Oracle, купившей Sun Microsystems в 2010 году… Надо отметить, что я с девяностых годов был поклонником Sun. Еще до появления линухов весь роутинг в моей компании, которая продавала dial-up доступ в интернет, крутился на FreeBSD. А мечтой был какой-нибудь SparcStation под Solaris8. Тогда эти системы были несомненными лидерами на коммерческом рынке серверов и серверных ОС. И надо сказать, не зря. Система действительно была надежная, а инженеры в Sun работали одни из лучших в мире.

Когда в 2005-м Sun открыла код Solaris, я подумал, что наконец в мире может появиться что-то мощное, альтернативное линуксу. Я даже заказал на Амазоне книжку OpenSolaris Bible (зачем? Ведь есть интернет).

Но в силу организационных причин и невозможности преодолеть коммерческие лицензионные ограничения, к которым все привыкли, система развивалась плохо. И в конце концов Oracle ее закрыла. Я тогда подумал: жаль, опять в мире исчезло что-то хорошее.

Теперь вы поймете мои чувства, когда спустя более чем два года после закрытия OpenSolaris я узнал, что достаточно крупная фирма развивает этот код. Она наняла для этого бывших инженеров Sun, хоть и не всех. А такие технологии, как ZFS и DTrace, продолжают развиваться, в том числе их создателями, которые работают уже в не Oracle, а в других компаниях. Для меня это было сравнимо с радостью, которую испытываешь при возрождении из пепла чего-то хорошего и прекрасного!

Я погрузился в чтение про SmartOS и стал играться с ней.

Официальный сайт SmartOS

Немного истории

В августе 2010 года в Oracle решили прекратить развитие проекта c открытым кодом OpenSolaris и сосредоточиться на разработке SolarisExpress с закрытым кодом. Сразу вслед за этим сообщество независимых инженеров, ранее работавших в Sun Microsystems, запустило проект с открытым кодом illumos, как форк ядра из проекта OpenSolaris. При этом разработчики illumos не ставят перед собой задачу делать полный дистрибутив, этим занимаются проекты SmartOS, Nexenta OS, OmniOS, BeleniX, OpenIndiana и другие.

Одновременно из Oracle стали уходить инженеры, стоявшие у истоков таких технологий начала двухтысячных годов, как ZFS, DTrace, Zones, — Брайан Кантрилл (Bryan Cantrill), Адам Левенталь (Adam Leventhal), Дэйв Пачеко (Dave Pacheco), Брэндан Грегг (Brendan Gregg), Роберт Мустаччи (Robert Mustacchi) и другие. Инициатором проекта illumos стал Гаррет Д’Амор (Garrett D’Amore).

Многие из дистрибутивов развиваются отдельными компаниями — Joyent, Nexenta, Delphix и другими. Там, как правило, есть один или несколько человек, ранее работавших в Sun или имевших отношение к этой экосистеме. В настоящей статье мы поговорим о SmartOS — дистрибутиве illumos, созданном для управления облачными услугами. Развивает SmartOS сейчас компания Joyent, занимающая 8–9-е место на американском рынке облачных IaaS-услуг.

Грузимся с флешки, работаем из памяти

В чем же состоят основные отличия SmartOS от «обычных» операционных систем?

Наверное, первое, о чем стоит сказать, — это отсутствие системных файлов ОС на локальном диске. SmartOS загружается с флешки или по сети и затем целиком располагается в памяти сервера. На диске находятся только данные (обычно данные виртуальных машин). Такое свойство позволяет системе очень быстро работать в связи с отсутствием дисковых операций, но, конечно, ценой более длительного времени загрузки и усложненным механизмом «запоминания» пользовательских данных сервера — его адресов, конфигураций и прочего, что должно настраиваться при загрузке ОС.

Второе важное отличие — встроенный механизм виртуализации, основанный на контейнерной технологии. В других ОС для виртуализации требуется дополнительное ПО гипервизора. Контейнерная виртуализация позволяет избежать дополнительного слоя гипервизора. Широкая система разделения прав, присутствовавшая в Solaris10 и OpenSolaris, позволила создать технологию Zones, благодаря ей виртуальная машина управляется той же самой ОС, которая стоит на всем сервере. Это похоже на OpenVZ и Virtuozzo Containers, но имеет совершенно другие и более глубокие корни, уходящие в семейство SunOS, развивавшееся с восьмидесятых — девяностых годов.

Третье важное отличие — это файловая система ZFS, используемая как основная. Рассказ о ZFS требует отдельной большой статьи. Здесь я скажу лишь, что эта файловая система несет в себе большое количество высокоуровневых функций и позволяет с легкостью обращаться с образами виртуальных машин — копируя и резервируя их очень гибко. Кроме того, ZFS имеет в своей основе принцип copy-on-write, который позволяет очень эффективно хранить резервные копии данных, занимая минимум физического дискового пространства. Также можно делать очень быстро и много snapshots (моментальные «снимки» папок файловой системы), для разных целей.

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

Ставим систему на сервер

В качестве сервера, на который мы решили поставить тестовую версию SmartOS, мы использовали машинку ASUS RS720-E6/RS12. В качестве дисковой системы в сервере было установлено четыре диска по 2 Тб и четыре SSD по 225 Гб. Для начала мы настроили на аппаратном RAID логические диски RAID-0, которые были равны физическим, — то есть мы получили восемь логических дисков, которые через BIOS отдавались на уровень ОС. ZFS хорошо умеет кешировать, поэтому лучше отдавать ей физические диски, однако в случае Dell его аппаратный RAID оказался более производительным. Если у тебя есть время измерить два варианта для своей системы — лучше измерить.

Качаем самый свежий образ системы с официального сайта, там нужно выбрать твой вариант образа. В нашем случае это был USB Image, который мы записали на флешку по инструкции. Вставляем флешку в сервер и указываем в BIOS, что грузиться надо именно с нее.

Загрузчик SmartOS

После загрузки система спрашивает нас имена дисков, которые надо подключить к ZFS, сетевую конфигурацию и просит ввести имя машины. Забавно, что после загрузки ты сможешь войти под root не с тем паролем, который ты скачал в дистрибутиве, а под паролем root. Ну все, система стоит, теперь можно посмотреть, как сконфигурированы диски при помощи команды zpool status, и настроить их немного по-другому, для лучшей производительности. Так, все SSD-диски, которые у тебя есть, нужно отдать под кеш при помощи команды, аналогичной приведенной ниже, но с твоими именами дисков:

# zpool create pool c0d0 c1d0 cache c2d0 c3d0

Если что-то не будет получаться, обращайся к мануалам :). А если что-то совсем не будет получаться — обращайся к нам.

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

Окно логина в SmartOS

А как насчет стандартного LAMP?

Какой у нас самый распространенный web stack? Правильно. Apache — PHP — MySQL. Посмотрим, как он ставится в виртуалку под SmartOS и как работает. Создадим новую виртуальную машину:

# vmadm -f newmachine.json

В файле newmachine.json находится описание JSON нашей виртуалки:

{
"zonename": "myvm",
"autoboot": true,
"brand": "joyent",
"cpu_shares": 100,
"image_uuid": "9eac5c0c-a941-11e2-a7dc-57a6b041988f",
"max_physical_memory": 768,
"hostname": "myhostname",
"quota": 30,
"zfs_io_priority": 100,
"resolvers": [
"8.8.8.8",
"8.8.4.4"
],
"nics": [
{
"interface": "net0",
"nic_tag": "admin",
"vlan_id": 0,
"gateway": "10.17.0.1",
"ip": "10.17.0.2",
"netmask": "255.255.255.0"
}
]
}

В реальной конфигурации рекомендую заменить hostname, resolvers и IP на твои.

Конфигурование SmartOS

В качестве образа мы выбрали практически «пустую» 64-битную систему SmartOS. Создание машины происходит за несколько секунд, после чего в нее можно залогиниться из глобальной зоны:

# zlogin myvm

Теперь нам нужно установить Apache и/или nginx, PHP, MySQL/percona. В качестве менеджера пакетов в SmartOS используется программа pkgin:

// Обновляем список пакетов
# pkgin -y up
// Ищем наши пакеты
# pkgin av | grep "\(percona\|apache\|php\)"

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

# pkgin in apache-2.2 php-5.4 ap22-php54 percona-server

Затем нужно установить необходимые библиотеки для PHP (они разные для разных движков, но те, что ниже, обычно устанавливаются всегда, обратись к документации твоей PHP-программы):

pkgin in php54-mysql php54-mysqli php54-curl php54-gd php54-dom php54-iconv php54-mbstring

Теперь пришло время настроить сервисы:

// Стартуем сервер баз данных
# svcadm enable percona-server
// Устанавливаем пароль
# /opt/local/bin/mysqladmin -u root -p password 'your_new_password'
// Прогоняем скрипт безопасной установки
# /opt/local/bin/mysql_secure_installation

Затем создавай новую базу и загружай туда данные, как в обычном MySQL. Далее настраиваем Apache:

# vim /opt/local/etc/httpd/httpd.conf

Как ты уже понял, все настройки лежат в /opt/local/etc. Думаю, что настраивать Apache умеют все. Хочу лишь напомнить, чтобы ты не забыл загрузить модуль PHP:

LoadModule php5_module lib/httpd/mod_php5.so
AddHandler application/x-httpd-php .php

После изменений файла конфигурации перезапускаем сервис:

# svcadm restart apache

Теперь настроим PHP:

# vim /opt/local/etc/php.ini

Как минимум, нужно прописать в конфигурации наши расширения:

extension=mysql.so
extension=mysqli.so
extension=curl.so
extension=iconv.so
extension=mbstring.so
extension=dom.so
extension=gd.so

Или что там у тебя еще есть… Не забудь заставить Apache перечитать новую конфигурацию PHP:

# svcadm refresh apache

Осталось положить в document_root твой контент, и сайт можно смотреть в браузере. Если твой сервер использует SSD и ты настроил кеш ZFS на нем, то измерения скорости загрузки страниц, скорее всего, приятно тебя удивят.

Кстати, для того, чтобы посмотреть процессы в SmartOS, используется команда prstat. Это аналог top в Linux. А если интересует таблица соответствия команд SmartOS и Linux, ее можно найти по ссылке в INFO.

Фрагмент таблицы соответствий команд Linux и SmartOS

Ставим Zabbix

Конечно, если у тебя стоят виртуальные серверы и что-то делают, имеет смысл запустить на них мониторинг. Один из самых популярных пакетов мониторинга Zabbix прекрасно ставится на SmartOS. Качаем последнюю версию Zabbix в /opt/local/src:

# mkdir -p /opt/local/src; cd /opt/local/src
# wget http://sourceforge.net/projects/zabbix/files/ZABBIX%20Latest%20Stable/2.0.6/zabbix-2.0.6.tar.gz/download
# tar xzvf zabbix-2.0.6.tar.gz

Теперь надо скомпилировать исходники. Не забудь поставить GCC, если он еще у тебя не поставлен:

# pkgin in gcc47

Затем нужно сконфигурировать пакет. Ты можешь сконфигурировать сервер и агент одновременно, а можешь скомпилировать только сервер или только агент. Выбор за тобой. Мы компилировали и то и другое.

# cd zabbix-2.0.6
# ./configure --prefix=opt/local --enable-server --enable-agent --withh-curl --with-iconv=/opt/local

Если не было ошибок, копируем скомпилированные бинарники в место их назначения:

# make install

Надеюсь, компиляция прошла успешно и ты можешь приступить к конфигурационным сайтам Zabbix (обратись к сайту Zabbix, если необходимо).

1. Создай пользователя и группу:# groupadd zabbix; useradd -g zabbix zabbix
2. Создай базу данных и загрузи схему (мы использовали MySQL, если ты используешь другую СУБД, обратись к Zabbix site):

   # cd /opt/local/src/zabbix-2.0.6
   # mysql -u -p
   # create database zabbix character set utf8 collate utf8_bin;
   # quit;
   # mysql -u -p zabbix < database/mysql/schema.sql
   # mysql -u -p zabbix < database/mysql/images.sql
   # mysql -u -p zabbix < database/mysql/data.sql
   

3. Отредактируй конфигурационные файлы. Мы предполагаем, что агент и сервер Zabbix находятся на одной виртуалке. Если это так, то конфигурация будет следующей. Содержание файла /opt/local/etc/zabbix_agentd.conf:LogFile=/var/log/zabbix/agentd.log Server=127.0.0.1 ServerActive=127.0.0.1

Оставь остальные параметры по умолчанию. А содержание /opt/local/etc/zabbix_server.conf будет таким:

LogFile=/var/log/zabbix/server.log
DBName=zabbix
DBUser=<your_user_with_acess_to_zabbix_db>
DBPassword=<password_for_above_user>

Остальные параметры также оставь по умолчанию.

1. Стартуем демоны:

   # LD_LIBRARY_PATH=/opt/local/lib zabbix_server
   # LD_LIBRARY_PATH=/opt/local/lib zabbix_agentd
   

Переменные окружения LDLIBRARYPATH необходимы либо здесь, либо при компиляции (последнее предпочтительнее, конечно). Я компилировал без них, поэтому моя инсталляция не распознает библиотеку iconv, которая находится в папке /opt/local/lib. Вот почему я использую переменные окружения.

1. Теперь пришло время скопировать файлы интерфейса Zabbix (.php) в папку документов твоего веб-сервера:

   # mkdir <htdocs>/zabbix
   # cd /opt/local/src/zabbix-2.0.6/frontends/php
   # cp -a . <htdocs>/zabbix
   

Если твой веб-сервер был настроен на использование PHP и его document_root смотрит в папку htdocs, то ты можешь продолжить установку из браузера, введя в адресной строке http://<адрес твоего сервера>/zabbix. Дальнейшие инструкции можешь взять на сайте Zabbix.

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

Выводы

Уже в течение года мы используем SmartOS в качестве основы инфраструктуры, на которой мы размещаем коммерческие проекты. Можем отметить, что по сравнению со стандартными Linux-системами решения на SmartOS удается делать более производительными и устойчивыми. Конечно, есть и минусы. База совместимого железа у SmartOS намного меньше, чем у Linux. Поэтому нужно тщательно относиться к выбору аппаратных платформ. Кроме того, несмотря на целенаправленную работу Joyent по пакетированию самого распространенного софта и наличию более 10 тысяч пакетов в репозитории, некоторых нужных пакетов, скорее всего, под SmartOS не окажется. Их придется компилировать, что может вырасти в отдельный геморрой. Тем не менее пакетов в репозитории становится все больше, а спектр поддерживаемого оборудования — все шире.

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

INFO

Carpe diem — латинское выражение, в данном случае означающее «Будь счастлив в ту секунду, когда интернет-шлюз выйдет из строя» :).

Введение

Чтобы не перенастраивать маршруты клиентов в случае выхода из строя основного шлюза, можно пойти двумя путями: перестроить таблицы маршрутизации или отдать IP-адрес отказавшего шлюза другому узлу. Каждый способ имеет свои плюсы и минусы. Протоколы динамической маршрутизации, вроде RIP, OSPF, EIGRP или BGP, требуют поддержки со стороны роутеров, плюс придется повозиться с настройками. Для простых сетей второй вариант реализовать на порядок проще, к тому же он имеет свои плюсы.

Сетевой протокол дупликации общего адреса CARP (Common Address Redundancy Protocol) позволяет использовать один IP-адрес несколькими хостами, работающими в пределах одного сегмента сети и имеющими один виртуальный MAC (link layer). Этот IP-адрес клиенты и устанавливают в маршруте по умолчанию, поэтому изменять сетевые настройки в случае выхода из строя мастер-шлюза нет необходимости. Настроив CARP, затем можно смело проводить обслуживание одного из узлов шлюзового кластера (изменять конфигурацию с перезагрузкой, обновлять ПО, проводить плановую модернизацию), не беспокоясь, что офис на какое-то время останется без интернета.

OpenBSD/FreeBSD CARP

Впервые CARP появился в 2003 году в ОС OpenBSD 3.5 как ответ на патентование компанией Cisco протоколов VRRP (Virtual Router Redundancy Protocol) и HSRP (Hot Standby Router Protocol). Впоследствии поддержка протокола была портирована в FreeBSD, NetBSD, DragonFly BSD и реализована для Linux-систем.

WWW

Сайт проекта UCARP: pureftpd.org/project/ucarp

Работает CARP следующим образом. В случае выхода главного узла из состава redundancy group (группа избыточности) его IP и идентификатор подхватывает один из резервных узлов, имеющий более высокий приоритет. Для определения своей работоспособности главный узел использует объявления (IP Protocol 112, защищены при помощи SHA-1 HMAC), как только они прекращаются, делается вывод о сбое. Резервный узел, взяв на себя IP, начинает рассылать объявления. Выбирается такой узел просто: кто быстрее начнет рассылать объявления, тот и главный. Для этого в настройках каждого роутера используются параметры advbase и advskew. Интервал рассылки рассчитывается по формуле advbase + advskew/255, то есть чем меньше значения, тем чаще узел рассылает объявления, а значит, вероятность того, что он станет мастером, выше. Когда мастер-шлюз восстанавливает работоспособность, управление снова переходит к нему (это необязательно, и в некоторых реализациях такое поведение можно отключить).

Схема сети

Самое главное — при выходе из строя главного узла все существующие подключения сохраняются и работа клиентов продолжается как ни в чем не бывало. Хотя для некоторых приложений потребуется согласование настроек и, как результат, переподключение. Для устранения этих неудобств используют дополнительные механизмы, вроде pfsync, синхронизирующие состояния соединений, рассылая сообщения (IP protocol 240) на другие устройства, которые затем импортируют полученные таблицы. Данные, передаваемые pfsync, не шифруются, поэтому для обмена таблицами соединений рекомендуется использовать выделенную физическую сеть.

INFO

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

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

Конфигурирование CARP в OpenBSD и FreeBSD, по сути, ничем не отличается, только используются разные файлы. Текущие установки можно просмотреть при помощи команды

# sysctl -a | grep "net.inet.carp"

Разрешаем форвардинг и включаем CARP:

# vi /etc/sysctl.conf
net.inet.ip.forwarding=1
# Разрешаем принимать CARP-пакеты
net.inet.carp.allow=1
net.inet.carp.preempt=1
net.inet.carp.log=2

Активированный параметр net.inet.carp.preempt позволит узлу участвовать в выборе мастера, при этом если откажет хотя бы один из CARP-интерфейсов, то advskew автоматически устанавливается в 240 и инициируются выборы мастер-шлюза. В случае если необходима балансировка, используем net.inet.carp.arpbalance, указав режим балансировки: arp, ip, ip-stealth или ip-unicast.

INFO

CARP позволяет разделить нагрузку между узлами.

CARP-интерфейс создается на лету при помощи команды ifconfig carp create. Для постоянных установок директивы прописываются в /etc/rc.conf (FreeBSD) или /etc/hostname.* (OpenBSD). Помимо стандартных для сетевых интерфейсов параметров, необходимо указать пароль, установить группу vhid и расставить приоритеты advskew.

Предположим, что имеется три сети: 192.168.0.0 (WAN), 192.168.100.0 (LAN) и 172.16.0.0 (между роутерами для pfsync). Виртуальный IP, создаваемый CARP, будет оканчиваться на 1. Нам требуется, чтобы на WAN и LAN «висел» постоянный IP, это позволит не менять настройки шлюза по умолчанию на компьютерах клиентов и подключаться к сервисам, расположенным внутри. Кстати, возможно использование уже имеющегося физического адреса хоста в качестве виртуального адреса.

Настраиваем параметры CARP

Интерфейсы конфигурируются как обычно (это можно сделать во время установки OC), разберем только то, что относится непосредственно к CARP и pfsync. В FreeBSD:

# vi /etc/rc.conf
network_interfaces="lo0 em0 em1 em2 pfsync0"
cloned_interfaces="carp0 carp1"
ifconfig_carp0="vhid 1 pass <password> 192.168.0.1/24"
ifconfig_carp1="vhid 2 pass <password> 192.168.100.1/24"
# Включаем pfsync
ifconfig_pfsync0="up syncif em2"

По окончании проверяем работу интерфейсов командой ifconfig carp.

Есть еще один момент, о котором стоит упомянуть. Все интерфейсы CARP разделены на группы (по умолчанию группа carp, ifconfig -g), каждой можно назначать счетчик demotion counter, позволяющий задавать некоторые ограничения: устанавливать master при загрузке, ограничивать число отказоустойчивых carp.

На резервном узле настройки полностью аналогичны, только в вызов ifconfig добавляем значение advskew. Покажу на примере OpenBSD:

# vi /etc/hostname.carp0
inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 1 carpdev em0 advskew 100 pass <password>

Параметр carpdev можно не указывать, в этом случае CARP использует физический интерфейс, который соответствует той же подсети, что и назначенный IP для виртуального интерфейса.

И второй:

# vi /etc/hostname.carp0
inet 192.168.100.1 255.255.255.0 192.168.100.255 vhid 2 carpdev em1 advskew 100 pass <password>

Теперь настала очередь псевдоинтерфейса pfsync:

# vi /etc/hostname.pfsync0
up syncdev em2

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

up syncdev em2 syncpeer 172.16.0.2

На данный момент пакетный фильтр блокирует передачу служебной информации, необходимо добавить пару разрешающих правил в /etc/pf.conf:

# vi /etc/pf.conf
pass quick on { em2 } proto pfsync keep state (no-sync)
pass on { em0 em1 } proto carp keep state (no-sync)

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

Теперь можно проверять. Выключаем основной шлюз, IP и МАС подхватывает резервный шлюз, при этом существующие соединения не обрываются. Хотя в случае активных VPN-туннелей есть свои особенности.

Настройка CARP в интерфейсе pfSense

Устанавливаем виртуальный IP в pfSense

Сохраняем состояние IPsec VPN

Соединения IPsec, одного из популярных протоколов, используемых для обеспечения VPN, также можно «перекидывать» через CARP. Однако основная трудность заключается в том, что IPsec оперирует механизмами Secure Associations (SA), определяющими, что нужно делать с пакетом (алгоритм шифрования, аутентификация, уникальный номер и прочее). В случае смены шлюза часть данных теряется, поэтому подключение обрывается. Для сохранения состояния VPN-туннелей используется демон sasyncd, также работающий в режиме ведущего или ведомого. Мастер отслеживает состояние локальных IPsec SA и SPD и отправляет изменения (TCP/500) на другие системы. Отказоустойчивость обеспечивается средствами CARP, передаваемая информация защищена при помощи AES и SHA.

Конфигурацию IPsec трогать не будем (демон должен стартовать с опцией -S), остановимся лишь на настройке собственно sasyncd.

# vi /etc/sasyncd.conf
interface carp0
# Группа по умолчанию
group carp
listen on 172.16.0.1 inet
# IP slave роутера, можно указать несколько peer
peer 172.16.0.2
# AES-ключ 'openssl rand -hex 32'
sharedkey /etc/sasyncd.key

Устанавливаем корректные права доступа:

# chown root /etc/sasyncd.conf
# chmod 600 /etc/sasyncd.conf

Настройки на подчиненном шлюзе аналогичны, только в peer указываем IP-адрес основного шлюза (172.16.0.1).

Перезапускаем isakmpd и смотрим результат. Трафик между роутерами у нас разрешен, поэтому обмен должен происходить без проблем.

# pkill isakmpd
# isakmpd -S -K
# sasyncd

Чтобы sasyncd стартовал при загрузке системы, в конфиг /etc/rc.conf.localдобавляем запись:

sasyncd_flags=""

Справочная страница sasyncd

Конфигурационный файл sasyncd.conf

А что же Linux?

Для Linux существует два варианта реализации CARP: в виде модуля ядра и пользовательской программы UCARP (http://pureftpd.org/project/ucarp,goo.gl/p4ADwj). Причем оба проекта не полностью совместимы со спецификацией CARP. Первый работает только для ветки 2.4/2.6 и давно не развивается, поэтому его можно встретить только на роутерах, использующих старые ядра. Второй совместим с Linux 2.4+, OS X, OpenBSD, MirBSD и NetBSD (ставить его в последних трех нет смысла). И хотя последние изменения кода датированы 2010 годом, UCARP работает в современных дистрибутивах и доступен в репозиториях. Единственный минус проекта — функция pfsync в UCARP не реализована, поэтому все соединения при переходе на другой роутер будут сброшены. Но стоит пользователям переподключиться, и они сразу получат доступ к требуемому ресурсу.

Итак, ставим UCARP. В Ubuntu и Debian он уже есть в репозитории, поэтому собирать ничего не нужно:

$ sudo apt-get install ucarp

Реализация в виде userspace имеет свои особенности, UCARP, по сути, обычная программа, которую можно запустить любым способом, в том числе из стартовых скриптов. В официальномreadme показан только общий для всех дистрибутивов принцип, помогающий понять, как построен UCARP. Пользователям Ubuntu/Debian повезло больше, поскольку мантейнер положил в пакет все нужные скрипты и предоставил хорошее описание (/usr/share/doc/ucarp).

Прописываем на мастер-сервере:

$ sudo /etc/network/interfaces
iface eth0 inet static
    address 192.168.0.2
    netmask 255.255.255.0
    ucarp-vid 1
    ucarp-vip 192.168.0.1
    ucarp-password password
    ucarp-advskew 0
    ucarp-advbase 1
    ucarp-master yes
iface eth0:ucarp inet static
    address 192.168.0.1
    netmask 255.255.255.0
    ...

Перезапускаем сеть:

$ sudo /etc/init.d/networking restart

Второй интерфейс прописываем по аналогии, изменяем только IP-адрес и значение ucarp-vid.

Теперь резервный роутер:

$ sudo /etc/network/interfaces
iface eth0 inet static
    address 192.168.0.3
    netmask 255.255.255.0
    ucarp-vid 1
    ucarp-vip 192.168.0.1
    ucarp-password password
    ucarp-advskew 100
iface eth0:ucarp inet static
    address 192.168.0.1
    netmask 255.255.255.0

Все готово, можно использовать.

Дела виндовые

Использование Windows в качестве маршрутизатора не такая плохая идея, как это кажется на первый взгляд. Тем более что этот вариант предусмотрен самими разработчиками. Достаточно вспомнить большое количество сервисов: VPN, DirectAccess, Remote Desktop Service (RDS), да и собственно сервер маршрутизации и удаленного доступа Windows (RRAS), обеспечивающий подключение клиентов к интернету. Доступность любой из этих ролей потребует наличия второго сервера, а вот инструменты отказоустойчивости придется выбирать в зависимости от сервиса и версии ОС. Служба RRAS и связанные с ней VPN, а также RDS уже давно поддерживают балансировку сетевой нагрузки (NLB, Network Load Balancing), и проблем с их использованием нет никаких. Но например, в Win2k8R2 DirectAccess ограничен развертыванием только на одном сервере, и, чтобы обеспечить резервирование, приходится задействовать отказоустойчивый кластер Hyper-V, настроенный для динамической миграции. В таком сценарии все равно функционирует только один сервер DirectAccess. В Win 2012 роль DirectAccess совместно работает с RRAS и, главное, поддерживает NLB, конфигурацию которой легко настроить прямо в мастере настройки роли. Также можно использовать решения по NLB от сторонних поставщиков.

Сама служба RRAS поддерживает RIP, умеющий динамически обновлять маршрутную информацию. Кроме того, в Win 2012 доступна функция объединения сетевых карт, позволяющая также организовать балансировку нагрузки и обеспечить отказоустойчивость (LBFO).

В Win 2012 DirectAccess интегрирован с RRAS

При настройке сервера RRAS потребуется выбрать топологию

Заключение

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

Сегодня ночью официально представлено общественности ядро Linux 3.17.

В этой версии реализовано большое количество важных нововведений.

• Нормальная поддержка AMD Radeon R9 290 со свободным драйвером.
• Поддержка контроллера Xbox One и геймпада Sony SIXAXIS от приставки PS3.
• Частичная подготовка к Cherry Trail, будущей архитектуре Intel Atom с чипами 14 нм и графикой класса Broadwell. Раньше выход Cherry Trail планировался на 2014 год, но теперь его сдвинули на I пол. 2015 года.
• Синхронизация DMA-BUF между устройствами, которые делят между собой один буфер.
• Расширение поддержки различных ARM-чипов и плат: Rockchip RK3288 SoC, Allwinner A23 SoC, Allwinner A31 Hummingbird, Tegra30 Apalis, Gumstix Pepper AM335x, AM437x TI.
• Определение, когда ноутбуки Toshiba переходят в свободное падение через акселерометр, который есть в последних моделях (например, HID TOS620A). В таких случаях головка HDD паркуется, чтобы не испортить поверхность диска. Раньше функцию реализовали для ноутбуков HP и Dell Latitude.
• ACPI 5.1 и другие улучшения в управлении питанием, в том числе патч для CPUfreq.
• Как обычно, улучшения в поддержке свободных драйверов Nvidia.

В последнее время Linux всё больше становится похожим на нормальную десктопную систему с отличным графическим интерфейсом, высокими функциональностью и быстродействием. Даже проблема с играми, по большому счёту, решена. Для Linux только в каталоге Steam есть 998 игр, среди них такие хиты как XCOM: Enemy Unknown, Wasteland 2, Portal 2, Counter Strike, Left 4 Dead 2, DOTA 2, TF2, Garys Mod, Half Life 2, Civ 5, Borderlands 2, Witcher 2, System Shock 2, Killing Floor и др.

Теперь вот ещё и поддержка контроллера Xbox One и геймпада PS3.

Способов развертывания Linux-систем существует достаточно много — начиная от простого клонирования и заканчивая установкой по сети. Для каждого семейства дистрибутивов также существуют свои способы, которые заметно облегчают установку на множество машин.

Введение

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

• Клонирование итоговой установки одного компьютера на несколько дисков с помощью dd/Clonezilla. Плюс у этого метода очевиден — он универсален и не надо заморачиваться с изучением дистроспецифичных методов развертывания. Минусы, тем не менее, тоже имеют место. Во-первых, конфигурация железа должна совпадать. Во-вторых, при клонировании мы получаем абсолютно точную копию системы — копируются в том числе пароли/SSH-ключи. В случае компрометации одной системы будут скомпрометированы и все остальные.
• Клонирование по сети. Преимущество перед первым методом — не надо отключать и подключать жесткие диски к клонируемой системе или бегать с флешкой, содержащей клонируемый образ, что для большого числа компьютеров довольно монотонно и смысла не имеет. Минус же, помимо тех, что у предыдущего способа, — сеть может отвалиться, что приведет к простою в развертывании. Впрочем, время простоя всяко меньше, чем если бы устанавливали вручную.
• Наконец, дистроспецифичные методы. Плюсы — возможно установить по сети, в том числе используя PXE, возможность гибкой конфигурации (в случае разных классов компьютеров, например компы для офиса, компы разработчиков, сервер) — для этого необходимо указать другой файл конфигурации, различие данных, которые клонироваться не должны. Минусы — для каждого дистрибутива способ развертывания свой и синтаксис конфигурационных файлов, соответственно, разный.

В этой статье мы рассмотрим третий метод для RHEL/Fedora и Debian/Ubuntu — эти дистрибутивы, в общем-то, самые распространенные в корпоративной среде, и в них предусмотрены средства автоматизации развертывания.

Развертывание Fedora/RHEL с помощью Kickstart

Средство автоматической установки Kickstart в Red Hat появилось очень давно — во всяком случае, в Red Hat Linux 6.2 (не Enterprise!) оно уже присутствовало. Существует три способа создания конфигурационного файла, и их можно комбинировать:

• Использовать готовый файл, который создается по завершении каждой установки дистрибутивов, основанных на RHEL/Debian.
• Использовать графический инструмент system-config-kickstart.
• Наконец, написать ручками.

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

Структура конфигурационного файла kickstart и пример

Условно можно выделить следующие части конфигурационного файла kickstart:

• тип инсталляции: установка или обновление;
• выбор языка и раскладки клавиатуры;
• аутентификация;
• конфигурация загрузчика;
• разбиение на разделы;
• наборы пакетов;
• постинсталляционные действия.

Вот и пример конфига kickstart (anaconda-ks.cfg) с комментариями:

# Устанавливаем с CD/DVD
install
cdrom
# Конфигурация языка и клавиатуры
lang ru_RU.UTF-8
keyboard us
# Конфигурация сети — используется eth0, адрес IPv4 получаем по DHCP
network --onboot=yes --device=eth0 --ACTIVATE --bootproto=dhcp --noipv6
# Пароль root. В данном примере — 12345
rootpw  --iscrypted $6$tl/40ovclGKvu.em$ozESAVNBRlVVT61DxUpnu72XMAHdDEFv1eOKg9ip9yvbA9a6GkRJi0OiSlMhq8FBtRlF5oi1irV4EInTb7HLo1
# Брандмауэр. Разрешаем доступ к машине по SSH, все остальные входящие подключения запрещаем
firewall --service=ssh
# Пароли хранятся в файле /etc/shadow, алгоритм хеширования — SHA-512
authconfig --enableshadow --passalgo=sha512
# Временная зона
timezone Asia/Omsk
# Конфигурация загрузчика. Ставим в MBR, а в качестве параметров ядра передаем строку через опцию --append
bootloader --location=mbr --driveorder=sda --append="crashkernel=auto rhgb quiet"
# Отключаем постинсталляционную настройку
firstboot --disable
# Разметка диска (исключительно в качестве примера)
clearpart --all --drives=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 --initlabel
part --ondisk=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 /boot --fstype=ext2 --label=boot --asprimary --size=128
part --ondisk=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 swap --fstype=swap --label=swap --size=512
part --ondisk=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 / --fstype=ext4 --label=root --size=2048
part --ondisk=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 /var --fstype=ext4 --label=var --size=2048
part --ondisk=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 /usr --fstype=ext4 --label=usr --size=4096
part --ondisk=disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0 /home --fstype=ext4 --label=home --size=1 --grow
# Создаем нового пользователя. Пароль — 123
user --name=rom --password=$6$V.WpsK6y.OKRmwcC$wFfX8bi5LimfOaXWo1uAaWhf1cQzXQ1vtafQGhU61ri9c2j1t1m.9B4oeCedGWWCqXgwCH0bbuSLHy3lkiy0// --iscrypted

%packages
@base
@client-mgmt-tools
@core
@debugging
@basic-desktop
# <...>
mtools
pax
# <...>
%end

Графическая утилита для создания файлов kickstart

Еще раз хочу отметить, что это всего лишь простейший пример, — в файлах kickstart можно использовать целые сценарии, которые будут выполняться перед установкой и после нее — %pre и %post. В %pre-скрипте, к примеру, можно разметить диск более гибко, чем это позволяют делать штатные методы kickstart, а в %post — совершить некоторые действия по конфигурированию.

$ perl -e 'print crypt("password", q($6$salt$)), "\n";'

Хеширование пароля

Сложная разбивка дисков в kickstart

Для разбиения на разделы используются следующие команды kickstart: autopart, part, raid, volgroup и logvol. Если требуется автоматическая разметка, воспользуйся autopart — к тому же ты можешь выправить размеры разделов ручками с помощью команды part. Однако я бы предпочел полностью ручное разбиение. Порядок создания разделов LVM такой: сперва создаем раздел /boot (обязательно вне LVM), затем с помощью part физический том, потом уже поверх него группу томов, для чего применяем volgroup, и, наконец, используем logvol для создания логических томов с файловыми системами. Программный RAID-массив создается примерно по такой же схеме.

Поскольку разбиение дисков довольно сложная тема, имеет смысл привести фрагмент файла kickstart, где описан вариант создания массива RAID5 с одним запасным устройством, поверх которого создан LVM:

clearpart --all --initlabel --drives=sda,sdb,sdc,sde
# Создаем разделы /boot и swap
part /boot --fstype=ext2 --size=128 --asprimary --ondrive=sda
part swap --hibernation --fstype=swap --asprimary --ondrive=sda
# Создаем разделы для RAID
part raid.01 --size=1 --grow --ondrive=sda
part raid.02 --size=1 --grow --ondrive=sdb
part raid.03 --size=1 --grow --ondrive=sdc
part raid.04 --size=1 --grow --ondrive=sde
# Создаем массив RAID5 с одним резервным диском, поверх которого будет создан физический том LVM
raid pv.01 --device=md0 --level=5 --spares=1 raid.01 raid.02 raid.03 raid.04
# Создаем группу томов LVM и уже поверх нее создаем сами тома
volgroup sysvg pv.01
logvol / --fstype=ext4 --vgname=sysvg --size=2048
logvol /usr --fstype=ext4 --vgname=sysvg --size=4096
logvol /var --fstype=ext4 --vgname=sysvg --size=4096 --maxsize=16384 --grow
logvol /home --fstype=ext4 --vgname=sysvg --size=1 --grow

Итоговый конфиг ks.cfg

Запуск автоматической установки

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

• Какой-либо накопитель. Указывается так: hd:<имя накопителя>:/ks.cfg. Например,ks=hd:sda1:/ks.cfg. Также допустимо размещение на CD/DVD ks=cdrom:/ks.cfg, что, впрочем, имеет смысл только в случае самосборного образа.
• NFS. В данном случае указывается через nfs:<имя сервера>:/<путь к файлу ks.cfg>.
• HTTP/HTTPS. ks=http://192.168.0.1/ks.cfg.

Инфраструктура для развертывания виртуальных машин

Kickstart можно использовать и для развертывания ВМ. Далее я опишу их развертывание на примере VirtualBox и Scientific Linux. Создаем VM из командной строки:

$ VM="SciLinux6"
$ VBoxManage createvm --name "${VM}" --ostype "RedHat" --register

Создаем диски:

$ VBoxManage createhd --filename "VirtualBox/${VM}/${VM}.vdi" --size 32768
$ VBoxManage storagectl "${VM}" --name "SATA Controller" --add sata --controller IntelAHCI
$ VBoxManage storageattach "${VM}" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "VirtualBox/${VM}/${VM}.vdi"

512 Мб — минимальный объем памяти, необходимый для установки Scientific Linux:

$ VBoxManage modifyvm "${VM}" --memory 512

Изменяем тип сетевого адаптера — тот адаптер, который стоит по умолчанию, не поддерживает загрузку по сети:

$ VBoxManage modifyvm "${VM}" --nictype1 Am79C973

Установим порядок загрузки:

$ VBoxManage modifyvm "${VM}" --boot1 disk --boot2 net --boot3 none --boot4 none

Не станем рассматривать процесс конфигурирования TFTP. Конфиг pxelinux.cfg/defaultбудет выглядеть следующим образом:

LABEL sl64
KERNEL /sl64/vmlinuz
APPEND initrd=/sl64/initrd.img ks=http://10.0.2.2/ks-vm.cfg

Изменения в файле ks-vm.cfg минимальны:

install
url --url=http://10.0.2.2/sl64

Установка пакета debconf-utils для получения файла ответов на свежеустановленной системе

INFO

Kickstart доступен и для Ubuntu.

Preseed в Ubuntu

В системах на основе Debian есть свое средство автоматизации установки под названием preseed. Существует три способа загрузки файла с заданными параметрами установки:

• файл в initrd (наиболее сложный способ);
• файл на самосборном CD или флешке;
• по сети.

WWW

Документация по preseed: bit.ly/168711o Установка с использованием preseed на VirtualBox: bit.ly/1f5BLYR

В последнем случае необходимо указать как файл, так и его MD5-сумму. Опишем кратко, как грузить файл по сети, а затем создадим самосборный CD со своим файлом preseed. Для загрузки файла по сети в параметрах загрузчика необходимо указать параметр preseed/url=, который можно сократить до url=. Файл рекомендую размещать на внутреннем веб-сервере. Конечный набор параметров будет выглядеть примерно так:

url=http://192.168.0.3/oem.seed preseed/checksum=0adf69ba731d9eeebf468036c9a0c82

А вот для загрузки файла preseed с локального установочного носителя необходимо, во-первых, чтобы он там присутствовал. Во-вторых, нужно опять же указать путь к файлу. И если второе проще простого — для этого используем опцию file=/cdrom/seed/oem.seed в случае установки с CD или file=/media-hd/preseed.cfg в случае установки с флеш-накопителя, — то первое требует более подробного описания. Расскажу, как подготовить ISO-образ с файлом автоматической установки.

Для того чтобы это сделать, нужно перепаковать уже готовый ISO-образ.

### unpack.sh — скрипт для распаковки образа
#!/bin/bash

BUILD=iso
IMAGE=$1
TMPDIR="$(mktemp -d)"

rm -rf $BUILD/
mkdir $BUILD/

# Монтируем образ и копируем файлы
sudo mount -o loop $IMAGE $TMPDIR/
rsync -av $TMPDIR/ $BUILD/
chmod -R u+w $BUILD/
# Подчищаем
sudo umount $TMPDIR
rmdir $TMPDIR

### pack.sh — скрипт для упаковки образа
#!/bin/bash

IMAGE=$1
BUILD=iso

# Вычисляем контрольные суммы
rm $BUILD/md5sum.txt
(cd $BUILD/ && find . -type f -print0 | xargs -0 md5sum | grep -v "boot.cat" | grep -v "md5sum.txt" > md5sum.txt)

# Запаковываем содержимое iso/ в образ
mkisofs -r -V "Ubuntu OEM install" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o $IMAGE $BUILD/

Ну а теперь самое время перейти к описанию файла preseed.cfg.

preseed.cfg — структура и пример

Технология preseed основана на debconf — то есть фактически можно управлять не только процессом установки, но и некоторыми другими вещами. Каждая инструкция preseed вмещается, как правило, в одну строку и состоит обычно из четырех частей, разделенных пробелами: владельца параметра, его имени, типа параметра и его значения. В большинстве случаев в первой части будет стоять d-i, то есть debian installer. А вот вторая часть, собственно, и является, в терминологии debconf, «вопросом», на который в четвертой части задается ответ. Третья же часть инструкции указывает тип вопроса/ответа:

• string — самый распространенный тип вопроса; строка, содержащая (относительно) произвольные данные;
• boolean — ответ может быть либо true, либо false;
• select и multiselect — поскольку вопросы фактически те же самые, что задает программа установки, то среди них могут быть вопросы на выбор одного или нескольких вариантов. Ответ в случае multiselect разделяется запятой и пробелом;
• password — используется для паролей;
• note — предупреждение пользователя. Установщик иногда выводит информационные сообщения данного типа. В общем-то, это некритичные предупреждения, но если их проигнорировать в файле ответов, то на них придется отвечать ручками. В данном типе параметра ответа не предусмотрено.

Необходимо учесть также, что стандартный live-дистрибутив для создания своего образа не подходит, поскольку в нем запускается графический установщик ubiquity, а нам необходим Debian Installer. Для этой цели необходимо использовать ISO-образ с постфиксом alternate. Я использовал Xubuntu 12.04.3.

Переупаковываем содержимое ISO-образа

Далее будет приведен урезанный пример файла preseed.cfg с комментариями (файл должен быть в кодировке UTF-8):

# Локализация
d-i debian-installer/locale string ru_RU.UTF-8

# Клавиатура
d-i localechooser/shortlist select RU
d-i console-setup/ask_detect boolean false
d-i console-setup/layoutcode string ru
d-i console-setup/varian select Russia
d-i console-setup/toggle select Ctrl+Shift

# Сеть
d-i netcfg/choose_interface select auto
d-i netcfg/get_hostname string ubuntu
d-i netcfg/dhcp_failed note
d-i netcfg/dhcp_options select Do not configure the network at this time
# <...>

# Пользователи
d-i passwd/root-login boolean false
d-i passwd/make-user boolean true
d-i passwd/user-fullname string Roman
d-i passwd/username string ubuntu
d-i passwd/user-password-crypted password $6$JZPLyQ9Qx/1$JE9Vk25Ttm4cNiz1/huQ..2xARrB4RrFiFWTXIkk1ojW5dDN5fIisHXUx9Zl.ewceLUQ1Ebw4WPUZvtIVctUd1
d-i user-setup/allow-password-weak boolean true
d-i user-setup/encrypt-home boolean false

# Разбиение диска. Выбираем автоматическое
d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string regular
partman-auto partman-auto/init_automatically_partition select Guided - use entire disk
partman-auto partman-auto/automatically_partition select
d-i partman-auto/purge_lvm_from_device boolean true
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

# Загрузчик
d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean true

# Настройка репозиториев
d-i apt-setup/restricted boolean true
d-i apt-setup/universe boolean true
# <...>

# Перезагрузка
d-i finish-install/reboot_in_progress note

Для проверки соответствия формату можно использовать команду

$ debconf-set-selections -c preseed.cfg

Чтобы установка была полностью автоматической, необходимо также задать некоторые параметры загрузки — поскольку не все параметры debconf могут быть прочтены установщиком из preseed-файла на ранних стадиях загрузки. Параметры могут дублировать аналогичные строки в файле preseed. Для этого необходимо в распакованном ISO-образе отредактировать файл isolinux/txt.cfg, добавив в него новый пункт меню. У меня получилось примерно следующее:

label oem-install
menu label ^OEM install
kernel /install/vmlinuz
append file=/cdrom/preseed/oem.seed debian-installer/locale=ru_RU.UTF-8    keyboard-configuration/modelcode=SKIP keyboard-configuration/layout=Russian keyboard-configuration/variant=Russian console-setup/toggle=Ctrl+Shift initrd=/install/initrd.gz quiet --

В случае если тебе нужна полностью автоматическая загрузка, измени default install на default oem-install.

Запаковываем образ и, по необходимости записав его на диск, загружаемся с него.

Конфиг isolinux для preseed-установки Ubuntu

Обновление Debian до новой версии с помощью preseed

Существует возможность обновить свежеустановленный дистрибутив со старой ветки до новой, используя firstboot-скрипт. Для этого необходимо иметь, во-первых, в локальной сети веб-сервер, с которого скрипты будут загружаться, а во-вторых, сами скрипты и немного подправленный файл preseed. В последнем необходима примерно такая строка:

d-i preseed/late_command string chroot /target sh -c "/usr/bin/curl -o /tmp/postinstall http://webserver/postinstall && /bin/sh -x /tmp/postinstall"

Скрипт же postinstall содержит следующее:

#!/bin/sh

# Скачиваем firstboot-скрипт
/usr/bin/curl -o /root/firstboot http://webserver/firstboot
chmod +x /root/firstboot

# Создаем init-скрипт, который выполняет firstboot-скрипт. Разумеется, это будет работать только при классическом `/sbin/init`, но никак не при новых системах инициализации.
cat > /etc/init.d/firstboot <<EOF
### BEGIN INIT INFO
# Provides:        firstboot
# Required-Start:  $networking
# Required-Stop:   $networking
# Default-Start:   2 3 4 5
# Default-Stop:    0 1 6
# Short-Description: A script that runs once
# Description: A script that runs once
### END INIT INFO

cd /root ; /usr/bin/nohup sh -x /root/firstboot &

EOF

chmod +x /etc/init.d/firstboot
update-rc.d firstboot defaults

echo "finished postinst"

А вот, собственно, и сам скрипт firstboot — в него можно записать что угодно, но ниже будет рассмотрен только скрипт обновления до Wheezy.

#!/bin/sh

# Задержка необходима, поскольку это первый запуск — некоторые службы еще не инициализированы как следует
sleep 30

# Добавляем новый репозиторий apt-get
cat > /etc/apt/sources.list <<EOF
deb http://my-debian-mirror.mydomain.com/debian wheezy main
EOF

/usr/bin/apt-get update

# Предустанавливаем параметры апгрейда
cat > /tmp/wheezy.preseed <<EOF
libc6 glibc/upgrade boolean true
libc6 glibc/restart-services string
libc6 libraries/restart-without-asking boolean true
EOF

/usr/bin/debconf-set-selections /tmp/wheezy.preseed

# Собственно апгрейд дистрибутива
/usr/bin/apt-get -y dist-upgrade

# Удаляем init-скрипт и перезагружаемся
update-rc.d firstboot remove
/sbin/reboot

Preseed и виртуальные машины

Можно установить Debian с помощью virt-install, при этом полностью автоматически:

$ sudo virt-install --connect=qemu:///system     --location=http://ftp.us.debian.org/debian/dists/stable/main/installer\-i386     --initrd-inject=/path/to/preseed.cfg --extra-args="auto" --name d-i --ram=512     --disk=pool=default,size=5,format=qcow2,bus=virtio

Данная команда, хоть и выглядит устрашающе, делает следующее: грузит инсталлятор, инжектит файл preseed.cfg (он должен называться именно так) в initrd и передает аргумент auto инсталлятору. Остальные опции в описании не нуждаются.

К слову, можно легко клонировать уже существующую ВМ KVM, используя следующую команду:

$ sudo virt-clone -o vm1 -n vm2 -m 52:54:00:7A:DF:08 -f /var/lib/libvirt/images/vm2.img

Она создает точный клон (за исключением MAC-адреса) машины vm1, именует ее vm2 и копирует образ диска. Замечу, что, во-первых, гостевая система должна быть остановлена, а во-вторых (и это крайне важно!), на гостевой системе нужно перегенерировать SSH-ключи.

default linux

# default label linux
kernel linux
append initrd=initrd install=http://192.168.1.115/install/suse-enterprise/       autoyast=nfs://192.168.1.110/profiles/autoyast.xml

Заключение

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