Добрых дел, уважаемые Хабравчане!

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

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

Где-то с полгода назад мне понадобилось поднять сервер для платежных терминалов с подключением к платежной системе по IPSec. Мой выбор пал на Debian Squeeze и KAME ipsec-tools, в простонародье racoon. Ох, и не знаю, почему моя душа прикипела к данному приложению. Сначала, поверхностно изучив теорию IPSec, я взялся за практику:

apt-get install racoon

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

В недавно опубликованной статье TerAnYu описал как производил миграцию домена с Samba на Active Directory. Способ был выбран, на мой взгляд, очень интересный, но, к сожалению, при миграции небольшого домена (автор упоминает в тексте статьи о 70 пользователях офиса) многие интересные проблемы остались «за кадром».
Я, в свою очередь, постараюсь абстрагироваться от скриптов дампа/восстановления пользователей и сконцентрироваться на описании возникших проблем и их решения. Быть может описанный опыт поможет кому-нибудь сократить трудозатраты на подготовку миграции.

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

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

Что такое DKIM и как оно работает

DKIM (расшифровывается как DomainKeys Identified Mail) — метод идентификации письма по доменным ключам.
DKIM настраивается на почтовом сервере для того, чтобы подписывать исходящие письма цифровой подписью. Наличие такой подписи в заголовке отправленного письма сообщает серверу-получателю, что оно действительно было отправлено с указанного домена.
Известно, что в СПАМ-письмах часто в поле From: ставят е-mail, не имеющий совершенно никакого отношения к отправителю. В этом случае DKIM поможет распознать реальное письмо от спама. В отличие от других методов цифровой подписи письма, DKIM совместим с существующими форматами и протоколами и может быть плавно интегрирован в имеющиеся системы доставки и получения почты.

Подпись письма происходит на SMTP-сервере с помощью секретного ключа (Private key), а расшифровка подписи происходит на сервере-получателе или клиентской программе с помощью публичного ключа (Public key). Что интересно, публичный ключ хранится в DNS, что позволяет убить сразу двух зайцев. Во-первых, нет необходимости прикладывать Public key с каждым письмом для его расшифровки. А во-вторых, в таком случае DKIM позволяет сообщать серверам-получателям что делать с письмом, которое не имеет цифровой подписи, но якобы отправлено от вас. Эта технология называется ADSP (Author Domain Signing Practices). ADSP также хранится в DNS SMTP-сервера и доступен всем и отовсюду.

Пару лет назад я писал об использовании базы PAF (Postcode Address File) британской Королевской почты (Royal Mail) для приведения почтовых адресов, вводимых пользователями, к стандартному виду. Поскольку PAF — основная интеллектуальная собственность Royal Mail, то заполучить её не так-то просто: годовая подписка стоит от £400 в зависимости от полноты базы и от частоты апдейтов. Спустя неделю-другую после оформления подписки по почте приходит солидная красная коробочка с CD-диском:


На диске — EXE-файл, который запрашивает «серийный номер» и распаковывает базу (набор CSV-файлов) на диск. Серийный номер присылают отдельно, чтобы злоумышленник, перехвативший посылку, не смог бы воспользоваться базой. (Вот выдумают же — текстовый файл с серийным номером!) Номер у каждого клиента свой, чтобы в случае «утечки» было ясно, к кому предъявлять претензии. Впрочем, организовать «утечку» самих данных серийный номер никак не мешает, и на WikiLeaks в 2009 г. появилась база Postzon (одна из составляющих PAF). В комментариях к ней отмечено, что "данная база составлена на средства налогоплатильщиков, и активисты, в их числе газета The Guardian и сэр Тим Бернерс-Ли, уже давно пытаются убедить Royal Mail открыть свободный доступ к PAF; но до сих пор эти попытки не увенчались успехом". Впрочем, через год после появления Postzon на WikiLeaks аналогичная по содержанию база появилась в открытом доступе от имени британской картографической службы Ordnance Survey и под названием OS Code-Point Open — таким образом и Royal Mail сохранила лицо, не уступив требованиям активистов, и утёкшие данные официально получили статус общедоступных. Тем не менее, полностью PAF до сих пор необщедоступна. (Пока я готовил эту статью, Postzon и с WikiLeaks куда-то пропала; но гугл всё помнит.)

Спустя год после получения PAF мне понадобилось в неё снова заглянуть, но листочек с серийным номером, присланный отдельно от диска, за год успел куда-то затеряться. Тут мне и стало интересно — насколько сложно будет обойти проверку серийного номера в продукте таком солидном и так яростно защищаемом от «освободителей информации»? Через полчаса данные были у меня на винте, а сама программа-распаковщик мне показалась неплохим демонстрационным примером для начинающих реверс-инженеров. Никакая IDA не потребуется — только бесплатные и быстроустанавливаемые инструменты.

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

По роду деятельности приходится иметь дело с железом, с большим количеством компьютеров разной конфигурации, и, в частности, заниматься их тестированием. Естественно, хочется чтобы этот процесс был автоматизирован на сколько возможно. Для этих целей я использую бездисковую загрузку линукс через PXE, на котором подготовлены к автозапуску соответствующие скрипты с разными тестами, демоны следят за состоянием системы, а мониторинг на сервере показывает результаты и ругается, если что-то не так. В общем-то, всем можно быть довольным, но процесс проверки оперативной памяти никогда мне не нравился. Нативный для линукса memtester, субъктивно, работает слишком долго, прежде чем что-то найдет, да и находит далеко не всегда. Собрать ядро или поиграться с архивами — неплохой способ проверить систему на стабильность, но в глюках не всегда бывает виновата память. А самым действенным способом, в конечном счете, является старый добрый Memtest86. Но с ним необходимо следить за каждым компьютером по отдельности, теряется весь процесс автоматизации, а когда компьютеров слишком много, то начинает поджимать и время. К сожалению, обделен всякими хитрыми kvm'ами.

Размышляя над этим, я обратил свой взгляд на виртуализацию. Почему бы не попробовать? Хотя бы just for lulz. Память ведь используется таже самая.

От переводчика

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

Начав выкладывать на хабре некоторые свои статьи и переводы, касающиеся тематики мониторинга ИТ-инфраструктуры, мне опять пришлось столкнуться с очень узким и техническим пониманием этой темы, которое у меня уже когда-то было и поэтому у меня однажды возникла идея изложить это системно. Я даже начал, не торопясь, писать статью на эту тему, но интуитивно понятные вещи не очень хорошо ложились на бумагу – за деревьями не получалось леса. Конечно, у нас у всех есть Google и возможность подсмотреть что пишут другие авторы, но не тут-то было. Бесчисленные статьи и заметки в блогах были посвящены техническим аспектам взгромождения очередной системы мониторинга на очередную версию операционной системы и связанное с этим героическое преодоление трудностей. Cтатей по методологии мониторинга, принципами выбора метрик, правильного построения процесса и увязывания его с бизнесом было очень мало и они также описывали некоторые частные случаи применения мониторинга для решения той или иной проблемы и не более того. А потом мне случайно попалась в руки совсем небольшая книга Дона Джонса «Создание унифицированной системы ИТ-мониторинга в вашем окружении (ENG)».

Проблематика

Итак, мы имеем коммерческий online-сервис, а наши клиенты — это компании, которые используют сервис 24x7. Наша задача, чтобы клиенты были счастливы и наши внутренние проблемы, связанные с отказом оборудования и ПО оставались для клиента максимально незамеченными. Клиенту вовсе не надо знать о том, что у нас сгорел RAID-контроллер, а системный администратор живет в Таиланде и не привык рано вставать.

В соответствии с законодательными требованиями, отраслевыми нормативами и корпоративными политиками от компании могут требоваться длительные сроки хранения корпоративной информации (5, 10 и даже 30 лет). На что нужно обратить особое внимание в таком случае?

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

У вас есть ESXi (любой гипервизор) на котором запущены виртуальные серваки? Иногда бывает так, что нужен доступ к реальной консоли сервера и не всегда есть возможность использовать консоль vmware. Если решение вам интересно читаем дальше.

Пользователи SharePoint знают, что создавая или редактируя какой-либо элемент, указывать время можно с интервалом в 5 минут. В большинстве случаев этого достаточно. Однако, встречаются такие заказчики, которых это не устраивает. Они хотят встречи назначать в 12:02, требовать выполнения задачи к 16:31, обращения пользователей регистрировать с точностью до минуты. Их право, они за это деньги платят.

Попросить SharePoint считать не по пять минут, а по одной, стандартными средствами не представляется возможным. Некоторые знакомые к такой задаче устраивали пляски с SharePoint Designer'ом и Visual Studio, пытаясь соорудить кастомные формы и/или FieldType'ы. На мой взгляд, есть более красивое решение. Кому интересно, добро пожаловать под кат.

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

В итоге получилась система, сочетающая включение/выключение света как с помощью выключателей, так и через интернет — с помощью кнопок на веб-страничке.
Как это получилось — читайте под катом.

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

Но мы не из тех, кто ищет легких путей и сделаем вот такое устройство:

     Бывает так — что в крупной организации, подчиненной сложным корпоративным правилам — возникает несколько точек проникновения информации из реального мира в мир production! Например — мелкая торговая фирма вела список своих сотрудников в 1С — с помощью нанятого со стороны сотрудника отдела кадров — а потом — раз, и выросла в большую фирму — с разветвленной сетью филиалов и большой IT — инфрастуктурой! Нанято большое количество сотрудников — на скорую руку (с привлечением интеграторов, разумеется)  построена AD инфраструктура — заведены пользователи, настроены сайты, групповые политики работают, etc… и вдруг — оказывается, что информации в AD о пользователях — ноль! ну то есть имя — фамилия,  OU, членство в группах, пароль, logon-скрипт — и все! ни тебе имени, ни комнаты, ни телефона — где он и кто он — пустые поля. Что делать???

     Или вот взять мою ситуацию — пришел работать маленьким винтиком большой корпоративной системы! Она распределена по всей стране — и была не организована — но за время моей работы — подтянулась к реалиям современного мира, и вместо отдельно взятого домена в каждом филиале, не связанным с остальными — построила большое AD на всю страну! И поехали мои пользователи в новое прогрессивное будущее через ADMT, и их рабочие станции поехали, и они сами! И быстро организовались и OU, и групповые политики с логон — скриптами, действующими WMI — фильтрами и прочее — прочее! Да только вот старый их домен не хранил никаких знаний о них — ни о кабинете, где сидят, ни о том, как их зовут толком, ни об отделе, где трудятся! И так они поехали, простите, голыми в новый домен, что уже само по себе неприлично! А отсюда выросла задача первая:

1) Заполняем данные о пользователе в AD с помощью powershell

Плагинов для систем мониторинга существует огромное количество. Можно посмотреть и найти нужное в каталогах exchange.nagios и monitoringexchange. При поисках нужного плагина проверять лучше в обоих репозиториях — несмотря на кажущуюся идентичность, их содержимое различается.

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

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

Данная статья посвящена мониторингу серверов HP Proliant, и автор искренне надеется, что она поможет в работе тем, кто имеет оборудование HP, и хотел бы более полно отслеживать его параметры.

В первой части я рассказал о причинах, побудивших меня заняться построением своего “умного дома”, и об используемом “железе”.
Но “железо”, само по себе, умным быть не может, главное это “софт”. Вот об этой стороне своего проекта я и хочу рассказать в этой части. Банальное управление освещением с пульта, конечно, выглядит круто в глазах непосвященной публики, но “ума” тут никакого.
Так что же такого умного можно сделать? И, главное, как?

Во многих компаниях в качестве основной платформы автоматизации используется 1С. Так повелось и у нас. Однако процесс становления платформы был произведен без должного подхода, в связи с чем сначала у нас было 5 ключей защиты на 95 лицензий, затем появилось еще 3 физических ключа на предоставление еще 50 клиентских лицензий для 3-х юридических лиц. Ситуация дурацкая, так как каждый ключ по нормальному требует отдельных хост, а подходящих для этого серверов становилось все меньше, а маячащее увеличение количества пользователей и, следовательно, покупки новых ключей, заставило меня задуматься над альтернативным решением, позволяющим избежать лишней информационной нагрузки на наши сервера и вообще сделать систему с ключами более гибкой и, желательно, более устойчивой.

Продолжаем знакомиться с тем, как осуществлять управление службами Windows с использованием PowerShell. В предыдущем посте мы рассмотрели, как получить статус службы на локальном и удаленном компьютере, произвести фильтрацию служб (например, найти только остановленные службы) и определить зависимые службы. В этом посте будут рассмотрены такие достаточно тривиальные вещи, как:

1. Остановка службы
2. Запуск службы
3. Перезапуск службы
4. Приостановка и возобновление работы
5. Управление удаленными службами
6. Настраиваем автозагрузку службы

Мы уделим большее внимание разбору команд в PowerShell для осуществления выше перечисленного на локальном компьютере. В разделе “управление службами удаленных компьютерах” мы рассмотрим, ограничения работы в PowerShell v2 и v3. Подробности под катом.

Предыдущая статья:
Управляем службами Windows с помощью PowerShell. Часть 1. Получаем статус служб

Возвращаемся к теме удаленного использования Powershell Web Access. В первой статьей было рассмотрено, как установить PSWA на новом веб-сервере, во второй мы обсуждали конфигурирование. В этом посте протестируем PSWA на различных устройствах (компьютер, планшет на Android).