Системный администратор (янв-февр 2010)

Работа с HDD и файловыми системами из консоли

DNSSEC-расширение к DNS для повышения безопасности

Репликация Active Directory

Евгений Касперский: «Наш бизнес – это пятый элемент»

Управление Linux с помощью LIRC

Виртуализация: да/нет?

Буревестники кремниевой революции

SourceForge – кузница проектов с открытым кодом

№1-

2(86

-87)

янв

арь-

фев

раль

201

0 С

исте

мны

й ад

мин

истр

атор

№1-2(86-87) 2010

От редакции

1системный администратор январь-февраль 2010

Хорошо, когда плохо

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

формационных технологий уже не обойтись. Если хочешь побеждать конкурентов.

Как говорит наш гость номера Евгений Касперский (не путайте с Крисом Касперским!) руководство компаний, от мала до велика, начинает понимать, что «сокращая бюджет на ИТ, они либо рушат бизнес, либо делают его неэффективным, либо раздувают общие бюджеты». Значит, есть все основания утверждать, что 2010 год мо-жет стать временем расцвета ИТ-отрасли. Особенно у нас, в России.

Дело в том, с 1 января 2010 года Федеральный за-кон «О персональных данных» окончательно и бес-

поворотно стал обязательным для всех организаций и компаний, которые являются операторами персо-

нальных данных. А таких тысячи и тысячи в стра-не. Легче перечислить исключения из закона,

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

домление об обработке пер-сональных данных в уполно-

моченный орган. Это означает, что системный администратор

отныне нужен везде и всегда. Его по-зиции заметно укрепляются. Что не может не радовать.

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

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

Специальный выпуск журнала выйдет в конце февраля.

Галина Положевец, главный редактор

Где купить «Системный администратор»:> г. Москва, выставочный компьютерный центр «Савеловский»;> г. Москва, редакция журнала, проспект Мира, д. 102, корпус 1.

Подробную информацию о подписке смотрите на стр. 112.

УЧРЕДИТЕЛИ ИЗДАНИЯЧастные лица

Генеральный директорВладимир ПоложевецГлавный редакторГалина Положевец[email protected]Технический директорВладимир Лукин

Главный редактор электронного приложения «Open Source»Дмитрий Шурупов[email protected]

Дизайн-макетМарина РязанцеваДмитрий Бессонов

ИллюстрацииВиктор Чумачев

Над номером работали:Алексей БарабановАлександр ЕмельяновВалентин СиницынКирилл Сухов

Реклама и PR-службаДарья Зуморина, [email protected], Полина Гвоздь, [email protected], тел./факс: (495) 628-82-53 (доб.120)

РаспространениеСветлана Зобова(495) 628-82-53 (доб.120)

Адрес редакции129626, г. Москва, проспект Мира, д. 102, корпус 1.тел./факс: (495) 687-93-57 (внут. 357) Сайт журнала: www.samag.ru

ИздательООО «С 13»

Отпечатано в типографииООО «Периодика»Тираж 17000 экз.Тираж электронной версии 62000 экз.

Все права на материалы принадлежат журналу «Системный администратор». Перепечатка материалов и использование их в любой форме, в том числе и в элект-ронных СМИ, запрещена. При использова-нии материалов ссылка на журнал «Систем-ный администратор» обязательна

Дело в том, с 1 января 2010 года Федеральный закон «О персональных данных» окончательно и бес

поворотно стал обязательным для всех организаций и компаний, которые являются операторами персо

нальных данных. А таких тысячи и тысячи в стране. Легче перечислить исключения из закона,

чем назвать сегодня точную цифру тех, кто

что системный администратор

В номере

2 январь-февраль 2010 системный администратор

05 Информбюро

Острый угол

06 Технология MEDV. Виртуализа-ция в Windows 7. Виртуализация помогает

избавиться от многих проблем с совместимостью.

Рассмотрим решения, имеющиеся в WIndows 7.

Андрей Бирюков

09 Что лучше: использовать виртуализацию или купить несколь-ко серверов? На вопрос «СА» отвечают

ИТ-специалисты.

10 Один сервер – много задач. Оптимальные решения для вирту-альных машин. Способны ли технологии

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

их бизнес-целей, или это просто модная тема,

не выходящая за рамки теоретических обсуж-

дений?

Александр Светлаков

12 Суперкомпьютер без недо-статков. Охлаждаем, оптимизируем, экономим. Традиционная инфраструктурная

инженерная среда слабо приспособлена для раз-

мещения блейд-серверов. Что делать?

Михаил Балкаров

Кафедра

14 Кодирование. Введение в сис-темное программирование. Часть 3. Кодирование – это момент истины всех программ-

ных проектов. Рисовать ромбики да квадратики

может любой, но компьютеры пока не понимают

таких абстракций. Напишем программу, как это

принято.

Алексей Барабанов

20 Взгляд на ext4. Не новое, но хорошо доработанное старое. Ext4 подходит для самых разнообразных рабочих

нагрузок и способна полностью заменить ext3

в качестве «файловой системы Linux».

Андрей Пешеходов

27 Bugtraq

Гость номера

28 Евгений Касперский: «Наш биз-нес – это пятый элемент». На вопросы

читателей «Системного администратора» отвеча-

ет генеральный директор компании «Лаборатория

Касперского» Евгений Касперский.

Галина Положевец

Администрирование

34 Что «под капотом»? Работа с HDD и файловыми системами из консоли. Можно использовать ПО с гра-

фическим интерфейсом, а можно решать задачи

более оптимизированно – из командной строки,

всегда зная, что происходит «под капотом».

Игорь Штомпель

41 Миграция без проблем. Еще раз о Windows Server 2008 R2.

Миграция ролей AD, DNS и DHCP с ОС Windows

Server 2003 занимает мало времени. Попробуйте.

Никита Панов

44 WDS поможет. Установка операционных систем. Часть 2. При развертывании операционных систем может

возникнуть необходимость в дополнительных

настройках. Рассмотрим, какие средства пред-

лагает WDS.

Андрей Бирюков

48 Проект одного человека. Цен-трализованное управление при по-мощи Cfengine. Трудно управлять большим

количеством систем без средств автоматизации.

Этот проект облегчит задачу и позволит централи-

зовано устанавливать параметры.

Сергей Яремчук

54 Разговор на «ты». Репликация Active Directory. Одна из главных рекоменда-

ций Microsoft касательно ADDS – необходимость

развертывания в производственной среде не ме-

нее двух контроллеров домена. Однако их может

быть гораздо больше.

Илья Рудь

Константин Леонтьев

60 ClearOS 5.1: открыт и... ? Что принесло это коммерческому продукту. Популярный серверный дистрибу-

тив снимает все ограничения некоммерческой

версии. Выиграют ли от нововведения его

пользователи?

Валентин Синицын

20

86

100

14

В номере


62 АТС Samsung OfficeServ? Теперь работаем с Installation Tool. Единственная в своем роде программа для уп-

равления офисными АТС Samsung – Samsung

OfficeServ Manager больше не разрабатывается.

Ей на замену пришла Installation Tool.

Рашид Ачилов

68 Ряд волшебных изменений. Что нового появилось в проекте Wine? Проект Wine быстро развивается.

Обрастает все большей функциональностью,

за которой достаточно сложно уследить. Попро-

буем разобраться, какие изменения претерпел он

в 2009 году.

Игорь Штомпель

Безопасность

72 Спасительный протокол. DNSSEC-расширение к DNS для по-вышения безопасности. Практически

25 лет DNS-запросы не считались безопасными,

но после внедрения DNSSEC на корневых серве-

рах эта проблема будет решена.

Сергей Яремчук

78 Dr.Web ES в полевых условиях. Как защитить бизнес от вирусов?

При информатизации предприятий обеспече-

ние защиты информационных систем выходит

на первое место. Причины объективны.

Валерий Ледовской

Программирование

80 SourceForge. Кузница проектов с открытым кодом. Популярный хостинг

для программного обеспечения с открытым

исходным кодом SourceForge имеет большие

возможности для разработки, поддержки и рас-

пространения открытых программ.

Семен Есилевский

86 Расширяем возможности. PowerShell: другие языки програм-мирования. PowerShell – язык командной

строки, разработанный для определённого круга

задач. Расширить его можно за счет интегрирова-

ния программного кода из VBScript или VB.NET.

Иван Коробко

90 Мышеловка для админа. Осто-рожно: сыр прилагается. Три кита, на ко-

торых основано ПО для удаленного управления

компьютерами, безопасность, скорость и удобство

использования.

Евгений Лисовский

92 Bugtraq

Веб

94 Google Web Toolkit – современ-ное средство создания Rich Internet Application. Любое интернет-приложение

эпохи WEB2 – это прежде всего «богатый»

и функциональный пользовательский интерфейс,

выполненный с использованием технологии Ajax,

а следовательно, JavaScript.

Кирилл Сухов

Dolce Vita

100 Три в одном. Управление Linux с помощью LIRC. Если хотите

использовать ваш ПК в качестве медиацентра,

смотреть фильмы и слушать музыку, не вставая

с дивана, вам нужен LIRC!

Олег Воронин

Ретроспектива

107 История транзисторов. Бу-ревестники кремниевой революции. Нелепая ошибка привела к открытию, которое

принесло его авторам Нобелевскую премию.

Владимир Гаков

Приз! Приз! Приз!

Журнал «Системный Администратор» рад объявить на-ших новых победителей второго этапа розыгрыша «Ад-минский приз». От всей души поздравляем!

Счастливыми обладателями наград стали:

Харыбин Евгений Владимирович – выиграл приз «Интернет-шлюз» от компании Ideco.Соловьёв Андрей Игорьевич – получает сертификат на обучение в «Академии Корпоративных Систем».Мирзагалимов Марат Галимзянович – выиграл приз «Пакет программного обеспечения» от компании Allsoft. Дрогаль Сергей Викторович – выиграл приз «Виртуальный выделенный сервер».Захваткин Александр Владимирович – выиграл приз «Виртуальный выделенный сервер».Крайнов Андрей Евгеньевич – выиграл приз «Виртуальный выделенный сервер».Соловьёв Константин Валентинович – выиграл приз «Виртуальный выделенный сервер».Бочков Илья Владимирович – выиграл приз «Почтовый сервер на 50 пользователей».

– получает сертификат на обучение в «Академии Корпоративных Систем».

– выиграл приз «Пакет программного обеспечения» от компании Allsoft.

– выиграл приз



Соловьёв Константин Валентинович – выиграл приз

– выиграл приз «Почтовый сервер на 50 пользователей».









– получает сертификат


– выиграл приз – выиграл приз – выиграл приз





Соловьёв Константин Валентинович – выиграл приз

– выиграл приз «Почтовый сервер на 50 пользователей».



– выиграл приз – выиграл приз «Почтовый сервер на 50 пользователей».

Информбюро


ВизиткаМайкл Видениус пытается убедить обще-ственность в том, что в результате по-глощения Sun корпорация Oracle может навредить развитию MySQL

ДМИТРИЙ ШУРУПОВ, ведущий рубрики

VMware покупает Zimbra у Yahoo!Компания VMware, известная своими реше-ниями в области виртуализации, объявила о достижении договоренности с интернет-гигантом Yahoo! по поглощению поставщика

Open Source-решений для совместной работы Zimbra.Zimbra была независимой компанией до сентября

2007 года, когда стало известно о том, что ее поглощает Yahoo! за 350 миллионов долларов США. Тогда сообща-лось, что решения Zimbra помогут Yahoo! расширить воз-можности одной из ее ключевых услуг – электронной почты (Yahoo! Mail).

Теперь Yahoo! договорилась с VMware о продаже Zimbra последней. Сделка будет завершена в первом квартале это-го года, а ее финансовые подробности пока не разглаша-ются. В VMware намерены с приобретением Zimbra и всех ее наработок расширить список своих решений, предлагая программное обеспечение для совместной работы в качест-ве готовых виртуализированных продуктов.

VMware планирует осуществлять поддержку существую-щих продуктов и Open Source-инициатив Zimbra, а одновре-менно с этим заниматься оптимизацией решений для облач-ной инфраструктуры на базе vSphere.

Тед Тсо поможет Google с переходом на ext4Теодор Тсо (Theodore «Ted» Ts'o), который был техническим директором организации Linux Foundation чуть больше года, перешел

в компанию Google для внедрения файловой системы ext4 в ИТ-инфраструктуру интернет-гиганта.

Тсо хорошо известен в Linux-сообществе как один из ключевых авторов файловых систем ext3 и ext4. В сере-дине января стало известно о том, что в Google завершили тестирование нескольких файловых систем (JFS, XFS, ext4) для того, чтобы перевести на одну из них свою существую-щую Linux-инфраструктуру (на базе ext2). Результаты тести-рования оставили Google выбор между ext4 и XFS, но клю-чевым аргументом в пользу ext4 стала простота перехода на эту файловую систему с используемой до сих пор ext2.

Теперь именно Теодор Тсо поможет Google с переходом на современную файловую систему ext4. Кто станет новым техническим директором Linux Foundation, пока не сообща-ется: на сайте организации по-прежнему указан Тсо, хотя Джим Землин (Jim Zemlin), исполнительный директор неком-мерческой организации LF, уже официально подтвердил переход Тсо в Google.

У WordPress появилась некоммерческая организацияУ популярного Open Source-движка для соз-дания блогов и сайтов, WordPress, появилась некоммерческая организация – WordPress

Foundation. Благотворительная организация WordPress

Foundation была основана американским предпринимате-лем Мэттом Малленвегом (Matt Mullenweg), который явля-ется разработчиком первой версии WordPress. Заявляется, что цель новой некоммерческой структуры – продолжение миссии, возложенной на сам движок WordPress: демокра-тизация публикации программного обеспечения в виде Open Source-продуктов. WordPress Foundation станет ответ-ственной за защиту таких торговых знаков, как WordPress и WordCamp, а также будет обучать работе с WordPress и другим связанным с этим движком открытым ПО.

Официальный анонс публичного запуска WordPress Foundation появился 22 января на сайте организации wordpressfoundation.org. Уже на следующий день было объ-явлено о том, что организаторы WordCamp NYC, мероприя-тия для разработчиков и сообщества WordPress, которое прошло в ноябре 2009 года в Нью-Йорке, сделали первое пожертвование для WordPress Foundation, оно превысило 28 тысяч долларов США.

Еврокомиссия одобрила поглощение Sun корпорацией OracleНесмотря на различные инициативы Майкла Видениуса (Michael «Monty» Widenius), авто-ра СУБД MySQL, который пытался убедить

Европейскую комиссию в сомнительных перспективах сдел-ки между Oracle и Sun, Совет ЕС одобрил поглощение Sun Microsystems корпорацией Oracle.

Безусловное одобрение сделки между Oracle и Sun было принято Еврокомиссией 21 января. Несмотря на это решение и предшествовавшее ему одобрение сделки в США, поглоще-ние Sun корпорацией Oracle формально еще под вопросом, поскольку дожидается одобрения в других странах: России и Китае. Тем не менее ни у кого в ИТ-индустрии уже не возни-кает вопросов насчет того, что поглощение произойдет.

Майкл Видениус выступал с обращением не только ко всему мировому сообществу, но и конкретно к жителям России и Китая. Автор MySQL активно пытается убедить об-щественность в том, что в результате поглощения Sun (а зна-чит, и приобретения прав на MySQL) корпорация Oracle, рас-полагающая своими интересами на мировом рынке СУБД, может навредить дальнейшему развитию популярнейшей системы управления базами данных с открытым кодом.

В рамках инициативы Save MySQL from Oracle уже со-брано более 35 тысяч подписей на онлайн-петицию со всего мира, из которых около 5800 приходится на Китай и почти 1500 – на Россию. Впрочем, даже в Open Source-сообществе многие скептически относятся к предупрежде-ниям Видениуса, считая, что СУБД MySQL будет развивать-ся вне зависимости от результатов сделки между Oracle и Sun, поскольку сообщество сможет поддерживать кодо-вую базу продукта благодаря распространяющимся на нее Open Source-лицензиям. Кроме того, представители Oracle уже неоднократно заявляли, что «хоронить» MySQL совсем не входит в их интересы.

EOF

EOF

EOF

EOF


6

Визитка

январь-февраль 2010 системный администратор

Проблемы совместимостиВо многих организациях используют-ся приложения, совместимые только с Windows XP. Но при этом существует парк машин, работающих под Windows Vista или Windows 7. Сейчас в основ-ном это ноутбуки и брендовые рабочие станции с установленной по OEM опе-рационной системой. Конечно, возмож-ным решением данной проблемы может стать даунгрейд операционной сис-темы и установка Windows XP. Но мо-гут возникнуть трудности, к примеру с поиском драйверов под Windows XP для новых моделей ноутбуков. Стоит ли отказываться от новых возможностей, имеющихся в Windows 7? Может, лучше поискать другое решение для пробле-мы совместимости с Windows XP?

Еще один вариант – использование виртуальных машин. Существует мно-жество решений по виртуализации, большинство из них коммерческие и требуют дополнительных финансо-вых затрат для внедрения. Можно раз-вернуть виртуальные машины, на кото-рых будет работать наша операционная система Windows XP, на основе средств, используемых в Windows 7.

Windows XP Mode в Windows 7 пред-ставлен технологией, которая носит название Microsoft Enterprise Desktop Virtualization, MEDV. На самом деле Windows XP Mode – это лишь ма-лая часть технологии виртуализации MEDV. Небольшая, но главная часть – Windows XP Mode – позволяет запустить процесс виртуальной ОС (Windows XP

или Windows Vista) в специально раз-рабатываемой редакции Virtual PC. При этом у пользователя будет отображать-ся не рабочий стол виртуальной маши-ны, а только окно приложения, которое установлено в виртуальной ОС, но опу-бликовано в виде «обычного» линка в меню «Пуск» родительской системы. Таким образом, для пользователя рабо-та с приложениями, как установленными в родной Windows 7, так и в виртуальной Windows XP, абсолютно прозрачна – он сможет их отличать только по оформ-лению окон. И никакой путаницы с дес-ктопами, переключениями и подобными проблемами. Для администраторов – никакой мороки с совместимостью при-ложений, написанных для Windows XP при их запуске в Windows 7, поскольку они запускаются в родной, пусть и вир-туальной, среде XP. При этом в вирту-альной Windows XP поддерживаются USB-устройства, так что вы сможете работать напрямую с флеш-картами и другими USB-устройствами.

Что касается лицензий, то вам не придется доплачивать за использо-вание дополнительной на Windows XP. Windows 7 позволяет использовать Windows XP Mode (предоставляемый в виде отдельно скачиваемой утилиты, подробнее мы рассмотрим ее чуть поз-же), который создает виртуальную ма-шину с XP под управлением Virtual PC, клиентской технологии виртуализации в Windows 7.

Однако некоторые расходы на лицен-зии все-таки потребуются. Если у вас

достаточно большое количество машин требует совместимости с Windows XP, тогда необходим сервер управления под Windows 2008. Для развертывания сервера управления нам нужно пред-варительно установить на нем роль IIS, а также Microsoft SQL Server 2008. Дан-ные компоненты предназначены для уп-равления виртуальной средой, развер-нутой на рабочих станциях.

Если у вас небольшая сеть, мень-ше пяти машин, то, возможно, сервер управления MED-V, об установке ко-торого пойдет речь далее, не понадо-бится. Вам достаточно просто вручную развернуть из Desktop Optimization Pack виртуальную машину с образом Windows XP на каждой из клиентских машин и настроить на них публикацию требуемых приложений.

Установка и настройкаТеперь поговорим об этой технологии более подробно. Какие именно редак-ции Windows 7 поддерживают ее?

Технология виртуализации не под-держивается редакциями Home/Starter, но другие редакции ее поддерживают. Однако сейчас технология виртуа-лизации MEDV не входит в базовый функционал операционной системы, для установки данный дистрибутив нужно скачивать отдельно. Скачать дистрибутив можно по адресу [1].

Перейдем к рассмотрению прак-тической части, то есть развертыва-нию средств виртуализации Microsoft Enterprise Desktop Virtualization.

Виртуализация помогает избавиться от многих проблем с совместимостью. Рассмотрим решения, имеющиеся в WIndows 7

Технология MEDVВиртуализация в Windows 7

АНДРЕЙ БИРЮКОВ, специалист по информационной безопасности. Работает в крупном системном интеграторе. Занимается внедрением решений по защите корпоративных ресурсов



Нам необходимо запустить дис-трибутив Desktop Optimization Pack, который, как уже упоминалось ранее, можно скачать по адресу [1]. В от-крывшемся окне выбираем Microsoft Enterprise Desktop Virtualization 1.0. В открывшемся списке необходимо выбрать установку Install the server component of Microsoft Enterprise Desktop Virtualization 1.0. В зависимости от используемой архитектуры процес-сора можно выбрать 32- или 64-битную системы. Затем производим стандарт-ную установку сервера (см. рис. 1).

В меню Start у нас присутствует раз-дел MED-V. Запустим MED-V Server Configuration Manager и произведем необходимые настройки сервера уп-равления. В открывшемся окне начнем с раздела Connections. Здесь нам пред-лагается выбрать способ соединения и указать используемые порты. По умол-чанию можно использовать нешифро-ванное соединение по протоколу http.

Для большей безопасности лучше воспользоваться шифрованным соеди-нением по https. Обратите внимание, что при использовании https необхо-димо вручную прописать хеш серти-фиката с помощью командной стро-ки. Выполним необходимые для этого действия. Прежде всего откроем кон-соль управления Administrative Tools → Internet Information Services. В открыв-шемся окне выберем Server Certificates. Затем Create Domain Certificate.

Укажем необходимые учетные дан-ные для создания сертификата и сер-вер центра сертификации Certification Authority. Когда сертификат будет соз-

дан, необходимо открыть его свойства и выбрать пункт Thumbprint (см. рис. 2).

В этом пункте находится искомый хеш сертификата. Скопируем эту стро-ку в текстовый редактор и удалим про-белы между байтами, чтобы строка была непрерывной. Вернемся к MED-V Server Configuration Manager. Как видно в окне (см. рис. 1) приведен пример ко-манды, которую нужно выполнить для настройки соединения по https. В ко-мандной строке введем ее, указав хеш, который мы получили ранее. Например:

В случае удачного выполнения дан-ной команды появиться надпись:

Затем в окне MED-V Server Configuration Manager выбираем раз-дел Images, в котором необходимо ука-зать путь к файлу образа операцион-ной системы и соответствующий URL.

Наконец последний раздел – это Reports. Вот здесь нам и потребует-ся установленный ранее Microsoft SQL Server 2008. Выберем Enable Reports и в строке соединения Connection String внесем необходимые изменения. В частности, укажем правильный путь к базе данных. По окончании нажмем Create Database.

Затем перейдем к разделу Permissions. В нем выберем Add и до-бавим группу пользователей, которые могут работать с данной виртуальной

машиной. В общем случае это может быть группа Everyone.

Далее нам необходимо выполнить еще одно небольшое действие для настройки MED-V. Нужно вернуться в настройки IIS, в свойствах Default Web Site выбрать раздел BITS uploads. В нем необходимо выбрать опцию Allow clients to upload files. Технология BITS (Background Intelligent Translation Service) предназначена для передачи больших объемов данных без падения производительности сети. Она пере-дает данные маленькими частями, ис-пользуя свободные ресурсы, когда они становятся доступны, и пересобирая данные в месте назначения. В частнос-ти, с помощью этой службы осущест-вляется передача файла образа вир-туальной машины. Теперь наш сервер управления MED-V готов к работе.

Следующим шагом будет установ-ка клиента для сервера управления MED-V. Установку клиента можно про-извести также из Desktop Optimization Pack. Она тривиальна и не требует подробного описания. В процессе ра-боты вам необходимо указать учетные данные сервера MED-V для установки соединения с сервером.

При первом запуске клиента будет произведена индексация локального жесткого диска. После загрузки кли-ента нам доступны разделы Policy, Images, Reports (см. рис. 3).

Итак, мы разобрались со средст-вами управления Microsoft Enterprise Desktop Virtualization. Теперь необхо-димо установить на рабочих станци-ях виртуальные машины, развернуть

netsh http add sslcert ipport= ↵ 0.0.0.0:8443 certhash-07665a5db ↵ abb6effbed332f0af6db1a8c8a3096c ↵ appid-{00000000-0000-0000-0000- ↵ 000000000000}

SSL certificate successfully added

Рисунок 1. Настройка сервера управления MEDV Рисунок 2. Свойства созданного сертификата



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

Виртуальная средаНачнем с установки виртуальных ма-шин. Как нетрудно догадаться, в качест-ве средства виртуализации в продуктах Microsoft используется виртуальная ма-шина Pocket PC. Установить ее можно также из Desktop Optimization Pack. Вместе с установкой виртуальной ма-шины вы устанавливаете и образ вир-туальной машины WIndows XP.

После установки в меню «Старт» клиентской машины в «Программах» появляется раздел Windows Virtual PC, а в нем – собственно пункт Virtual Windows XP. При первом старте образ конфигурируется весьма тривиаль-ным образом – запрашивается толь-ко пароль будущего пользователя. Все настройки этой виртуальной ОС соответствуют типичным настройкам виртуальных машин Virtual PC, кроме появившегося пункта Auto Publish. Он отвечает за то, как будут публиковаться приложения из виртуальной Windows XP в стартовом меню Windows 7. По умол-чанию стоит режим автоматической публикации, а это значит, что все вновь установленные приложения в вирту-альной машине будут автоматически «всплывать» в меню родительской Windows 7. Этому моменту следует уде-лить особое внимание, иначе вы ри-скуете получить несколько одинаковых

ярлыков на рабочем столе пользовате-ля и соответствующую путаницу.

Теперь настроим политику для пу-бликации приложения. Для этого необ-ходимо сначала открыть раздел Images в клиенте MED-V Management. Далее в Local Test Images нужно нажать кноп-ку New… Будет добавлен образ вирту-альной машины (см. рис. 4).

Процесс упаковки файла образа займет некоторое время. По оконча-нии упаковки образ появится в разде-ле Local Packed Images.

Теперь перейдем к непосредствен-ному созданию политики. Для этого откроем раздел Policy. Нажмем кнопку Add… В закладке General необходи-мо указать имя политики, а также вы-брать Seamless Integration (публикуе-мое приложение будет отображаться на рабочем столе клиентской машины пользователя). При этом можно вы-брать цвет, которым будет окрашено каждое из публикуемых окон. Затем перейдем во вкладку Virtual Machine и из списка Assigned Image выберем нужный образ. После этого во вкладке Deployment необходимо указать группу пользователей, которым будет доступ-но данное приложение. Лучше заранее создать в AD группу и занести в нее всех пользователей, которым необхо-димо публикуемое приложение. В этой же вкладке нужно разрешить исполь-зовать буфер обмена при работе с пу-бликуемым приложением.

После этого во вкладке Applications необходимо нажать кнопку Add и ука-зать путь к публикуемому приложению. Во вкладке Network вы можете указать

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

По окончании настройки применим созданную политику. Если в политике некорректно указан путь к публикуемо-му приложению, будет выведено соот-ветствующее сообщение об ошибке.

Устанавливаем, что нам требуется, в стартовом меню, в том же разделе Windows Virtual PC появляется раздел Virtual Windows XP Application со ссыл-ками на эти виртуальные приложения.

***Итак, мы развернули виртуальную сре-ду, в которой приложения, работающие только под Windows XP, запускаются и под Windows 7, причем совершенно прозрачно для пользователя. Какие ограничения накладывает Windows XP Mode? Это требование аппаратной поддержки виртуализации в процессо-рах. Инструкция по конфигурированию аппаратной виртуализации находит-ся на той же странице, что и загрузка самих средств виртуализации. Часто для включения аппаратной виртуали-зации после установок параметров BIOS требуется еще физическое вы-ключение питания компьютера.

1. Описание Desktop Optimization Pack – ht tp: / /www.microsoft .com/windows/ enterprise/products/mdop/default.aspx.

2. Видеоматериалы по развертыванию MEDV – http://technet.microsoft.com/en-us/virtualization/dd981013.aspx.

EOF

Рисунок 3. Клиент MED-V Рисунок 4. Добавление образа виртуальной машины

Острый угол: опрос


На вопрос «СА» отвечают ИТ-специалисты

Что лучше: использовать виртуализацию или купить несколько серверов?

Игорь Штомпель, инженер, системный ад-министратор

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

Артем Сычев, начальник управления инфор-мационной безопасности «Россельхозбанка»

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

Нередко организации сталкиваются с проблемой физиче-ского размещения серверов. Как на своих собственных (арен-дованных) площадях, так и в коммерческих ЦОДах. И в этом случае виртуализация может помочь в решении проблем. Даже с учетом адекватного горячего резерва решения на базе виртуализации по совокупной стоимости (в том числе и аренд-ных платежей) могут составить конкуренцию традиционным решениям. При этом вопросы физической охраны решаются точно так же, как и при традиционных технологиях.

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

Алексей Ватутин, системный инженер ком-пании «Крок»

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

Рашид Ачилов, администратор сетей и средств защиты крупной торговой сети

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

Я в 1992 году работал на заводе, где была ЕС ЭВМ под уп-равлением ОС СВМ (система виртуальных машин). И у нас там крутились две основные машины и с десяток програм-мистских, типа персональных рабочих мест. Но какие тогда были машины и какие сейчас! Малонагруженные серверы, не генерящие большой трафик, выход из строя которых вле-чет за собой приостановку только некоторых, не особо важных бизнес-процессов, спокойно можно виртуализовать. Серве-ры же с высокой сетевой нагрузкой, загруженные постоянным обменом (БД, например), играющие стратегическую роль, на-пример, брандмауэры я не вижу смысла виртуализовать. Стои-мость компьютера, который способен адекватно работать, мо-жет значительно вырасти, да и потери от простоя, когда этот суперкомпьютер выйдет из строя, могут свести всю экономию на нет. У нас виртуализация используется для того, чтобы сократить количество «унаследованных» серверов, которые были когда-то зачем-то поставлены, у них есть свои функции, но под их никто и никогда не даст денег на новую машину.


10

Визитка


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

Один сервер – много задачОптимальные решения для виртуальных машин

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

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

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

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

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

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

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

а резкое снижение стоимости серве-ров стандартной архитектуры еще бо-лее упростило этот процесс. В резуль-тате большинство серверов работают с загрузкой в 10-15% от располагае-мой мощности.

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

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

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

В-третьих, полноценное решение по виртуализации невозможно без внеш-ней системы хранения данных (СХД), а блейд-серверы оптимизированы для подключения к СХД, как по удобству, так и по затратам. Главный же аргумент в пользу блейд-серверов – широкое их применение в решениях виртуализации у наших заказчиков – Альфа-Банка, На-ционального Банка «ТРАСТ», «БТА Бан-ка», МГИМО и многих других.

Отдельно хочется упомянуть Страховой Дом «ВСК», в котором

АЛЕКСАНДР СВЕТЛАКОВ, специалист по продажам программных решений, отдел серверов стандартной архитектуры компании Хьюлетт-Паккард в России, сертифицированный инструктор HP и Microsoft



более 600 виртуальных систем, об-служивающих все филиалы компа-нии, выполняются на пяти полках HP BladeSystem c7000 с четырехпро-цессорными серверами BL680c, под-ключенными к дисковым массивам HP StorageWorks EVA.

В 2008 году компания HP представи-ла рынку комплексное решение для уп-равления серверной инфраструктурой Insight Dynamics – VSE. Решение бази-руется на функциональных возможно-стях компонентов управления инфра-структурой HP Systems Insight Manager, HP Insight Control, HP Virtual Server Environment и позволяет проводить мо-ниторинг физических и виртуальных ресурсов. Этот инструмент дает воз-можность заказчикам сформировать всегда готовую к изменениям техно-логическую среду, которая обладает гибкостью, необходимой для сквозной виртуализации.

Продукт Insight Dynamics позволил реализовать в условиях ИТ-инфра-структуры предприятия технологию так называемых логических серверов. Бла-годаря этой технологии физические платформы HP получают все преиму-щества быстрого развертывания и пе-ремещения, которые ранее были при-сущи только виртуальным системам.

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

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

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

при необходимости сервер может быть «материализован» по шаблону в тече-ние считанных минут.

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

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

Средства HP Insight Dynamics – VSE также позволяют просчитывать объем потребляемого электричества и могут предоставить информацию о том, как можно те же задачи выполнять с мень-шим энергопотреблением.

Существенной «проблемой» вне-дрения виртуальных серверов может

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

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

Компания HP поставляет аппарат-ные решения на основе блейд-систем. В качестве OEM-партнера основных поставщиков VMware, Microsoft и Citrix устанавливает средства виртуализа-ции от этих компаний на свое обору-дование и, кроме того, предоставляет мощные собственные средства кон-солидированного управления вирту-альной средой. В состав ПО HP Insight Control входит модуль по управле-нию виртуальными машинами Virtual Machine Management, с помощью ко-торого можно производить основные действия с виртуальными машинами (старт, стоп, пауза, копирование и пе-ремещение), контролировать разме-щение виртуальных машин на физи-ческих серверах (хостах) и проактивно реагировать на аппаратные сбои, по-вышая «живучесть» систем.

HP Insight Dynamics – планирование ресурсов в режиме реального времени

EOF


12

Визитка


Традиционная инфраструктурная инженерная среда слабо приспособлена для размещения блейд-сер-веров. Что делать?

Суперкомпьютер без недостатковОхлаждаем, оптимизируем, экономим

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

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

деляется большое количество тепла) и нуждаются в специализированном охлаждении.

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

Так, блейд-серверы легко «дают» на выходе температуру в 40 градусов (а новые модели и все 60!), а между тем температура в 30 градусов уже яв-ляется критической для многих моде-

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

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

МИХАИЛ БАЛКАРОВ, системный инженер компании APC by Schneider Electriс

APC Symmetra PX 150kW APC Symmetra PX 160kW



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

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

Компания APC by Schneider Electriс может предложить целый ряд решений

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

Кроме того, оборудование ком-пании APC by Schneider Electriс из-начально ориентировано на работу с высокой температурой горячего воз-духа на входе, поэтому кондиционеры не боятся подачи воздуха напрямую с блейд-серверов. Также в результа-те размещения кондиционеров рядом с нагрузкой датчики кондиционеров получают информацию о текущем локальном состоянии нагрузки и, со-

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

Помимо внутрирядного охлаждения наша компания предлагает системы контейнеризации «горячего» коридора и систему контейнеризации на уров-не стоек (HACS, Hot Aisle Containment System и RACS, Rack Air Containment System соответственно). Это достаточ-но простое решение. К стандартным стойкам с внутрирядными кондицио-нерами устанавливаются дополнитель-ные механические элементы, панели и двери, позволяющие контейниризи-ровать (изолировать) поток горячего воздуха, а в случае применения систем контейнеризации на уровне стоек еще и поток холодного воздуха.

При применении этих систем эффек-тивность охлаждения кондиционеров еще более возрастает, так, в случае контейнеризации «горячего» коридора можно «снимать» со стойки до 60 кило-ватт, а при полной контейнеризации – до 70 киловатт, что вполне достаточно для эффективного охлаждения совре-менного оборудования. EOF

Кафедра

14

Визитка


Краткое введение в тему: в предыдущей части [1] был по-строен обобщенный универсальный алгоритм системно-го администрирования. Предполагается, что он пригоден для создания программ автоматического администрирова-ния. Вот и воспользуемся этой наработкой, чтобы выяснить, какую реальную пользу можно извлечь из подобного алго-ритма.

Инструментальная платформаПрежде всего договоримся об инструментарии. В качестве целевой платформы я выбираю GNU/Linux, и следователь-но, все написанное далее можно будет с минимальными коррекциями с успехом применить практически в любой UNIX-системе. Но это не значит, что предложенные методы нельзя использовать для управления семейством операци-онных систем MS Windows. Без проблем! Надо только по-добрать небольшой «напильник», как говорят. Однако про-приетарные платформы далее не будут рассматриваться принципиально, потому что разрабатываемый проект дол-жен оставаться в первую очередь свободным!

И поскольку выбран GNU/Linux, то вполне естествен-но, если в качестве инструментария будут использоваться консольные утилиты и команды оболочки bash. Оболочка bash имеет достаточно мощный встроенный язык, и все это вместе с юниксовыми утилитами позволяет решить прак-тически любую задачу администрирования. И вот пример такого решения [2]. Скрипт достаточно старый. Возможно, автор давно его модернизировал или, напротив, забросил. Но за неимением иного публичного примера я буду «тер-зать» труд Геннадия Калашникова, да простит он мне это! Итак, начнем подбирать форму построения скрипта для ав-томатизации.

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

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

Но в инструментальном плане универсальные скрипты, пригодные для практического запуска на необследован-ных системах (здесь обсуждается администрирование, но возможен альтернативный, пользовательский взгляд: неизвестные скрипты на «своих» системах), категориче-ски нельзя создавать в расчете на выполнение от имени суперпользователя, потому что всякая эскалация привиле-гий должна быть явной!

Способ 2. Локальная работа с эскалацией привилегий с помощью suСхематично такой подход изображен на рис. 2. Можно так сказать, что это «общерекомендованный ортодоксальный» способ. Администратор работает локально от пользова-тельской учетной записи, и в случае необходимости выпол-няет привилегированные команды с помощью утилиты su, которая в обязательном порядке требует подтверждения полномочий путем введения парольной фразы. Все полит-корректно, но в работу вносится неизбежная интерактив-ность. Ее можно ограничить, объединив все команды в один скрипт. Например, так можно использовать программу [2], запуская ее изначально от непривилегированного пользо-вателя с помощью команды su. Но тогда будет потеряна из-бирательность эскалации прав. Резюме: непригодно!

Способ 3. Локальная работа с эскалацией привилегий с помощью sudoЭтому варианту отвечает рис. 3. Сейчас такой способ с лег-кой руки разработчиков Knoppix-а стал повсеместной прак-тикой. Утилита sudo позволяет сменить права на суперполь-

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

КодированиеВведение в системное программирование. Часть 3

АЛЕКСЕЙ БАРАБАНОВ, системный администратор, аутсорсер и консультант по вопросам применения информационных технологий. Хобби – программирование

Кафедра


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

Здесь уместно отметить, что корректно написанные руко-водства по установке могут практически без особого труда быть переложены в форму консольных команд. Например, статья [3] написана как раз с таким расчетом. И хотя все исполнение там идет от суперпользователя, команды со-ставлены так, что интерактивность их минимальна. А подси-стема эскалации прав не использована лишь потому, что ее описание не укладывалось в тему статьи. Забегая вперед, открою секрет – упомянутая работа [3] вообще бэк-порт из скрипта автоматической установки LDAP. Таким образом, при создании локальных административных скриптов жела-тельно использовать явную, не интерактивную эскалацию

привилегий с помощью sudo. И такая работа требует соот-ветственной настройки локальной учетной записи систем-ного администратора. А что если нужно выполнить команду на удаленной системе?

Способ 4. Удаленная работа с сепаратным исполнением командДумаю, не ошибусь, если предположу, что подобный способ используют очень и очень многие. Схематично он изобра-жен на рис. 4. Администратор, авторизуясь под локальной учетной записью на собственном компьютере, запускает на выполнение отдельные команды вида:

Кто незнаком с такой работой, могут прочитать отлич-ную статью на эту тему [4]. Дам лишь некоторые поясне-ния. Поскольку необходимо в конце концов написать скрипт для автоматического выполнения настроек, то потребует-ся обеспечить неинтерактивное выполнение всех команд.

Потеря семантики ведет к тому, что по инструкции можно написать программу, а по программе создать ин-струкцию практически нельзя

ssh staff@target sudo cmd1

Рисунок 1. Локальная работа от суперпользователя Рисунок 3. Локальная работа с эскалацией привилегий с помощью sudo

Рисунок 2. Локальная работа с эскалацией привилегий с помощью su

Кафедра


Для этого на целевой системе (target) должна быть создана служебная запись (назовем ее staff), внесенная в sudoers как stuff ALL = (root) NOPASSWD: ALL, и соответствующий ключ ssh должен быть записан в authorized_keys в директо-рии ~/.ssh этой учетной записи. Вот тогда можно будет вы-полнять команды на удаленной системе с эффективностью локальных.

Но и тут есть некоторые недостатки:Такая схема требует наличия бесперебойного уда-ленного доступа во время выполнения всей серии команд, собранных в единую программу. Это мо-жет вызвать затруднения в настройке таких подсистем, где в процессе работы приходится менять параметры сетевых соединений. И это вне зависимости от того, что, возможно, в конце выполнения серии команд связь снова будет восстановлена.Вся работа состоит из серии открывающихся и потом завершающихся сеансов связи с удаленным хостом, что может привести к существенному замедлению в слу-чае большого набора команд.В процессе отправки команд на удаленную систему через конвейер ssh происходит сложная синтакси-ческая трансляция. Ситуацию усугубляет возможное использование таких утилит, как sed и grep, требующих защиты своих служебных символов. Все это приводит к появлению возможных ошибок в зависимости от пред-ставления входных данных. И ошибки эти очень трудно обнаружить, поскольку строки, передаваемые через ssh на «ту» сторону, формируются налету, и даже отладоч-ное протоколирование в виде echo не дает 100% пра-вильной картины.Именно такой способ настройки применяется на боль-

шей части моих серверов в течение нескольких лет. И пере-численные недостатки заставили «двигаться» в переборе способов далее.

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

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

и потом запускаются на исполнение

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

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

Способ 6. Удаленная работа в автономном терминальном окнеЭто, безусловно, самый изощренный и универсальный ва-риант удаленного выполнения команд (см. рис. 6). Команды не просто группируются во временный скрипт, но и запуск его происходит с помощью консольного оконного менедже-ра screen, например, так:

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

cat | ssh staff@target "cat >cmd.$$"

ssh staff@target "bash cmd.$$"

ssh staff@target "screen -S scr$$ -dm \"bash cmd.$$\""

Рисунок 4. Удаленная работа с сепаратным исполнением команд Рисунок 5. Удаленная работа с групповым исполнением команд

Кафедра


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

Выбор модели разработкиИз вышеперечисленных способов следует особо отметить способ 3 и способы 5-6.

Взаимосвязь способа 3 и обычного текстового описания уже была отмечена (см. [3]). И точно так же, как по тексто-вому пошаговому руководству, можно написать последова-тельность консольных команд, так и в обратную сторону – ничего не должно мешать написать инструкцию по скрипту установки.

Ну а 5-й и 6-й способы фактически производят отправку сформированного по способу 3 скрипта на удаленный хост и дальнейшее его выполнение. Иначе говоря, они являются технологической «оберткой» для все того же скрипта, полу-ченного по текстовому руководству и предназначенного для локального исполнения. Причем здесь число инкапсуляций может быть произвольно увеличено. Например, отсылае-мый скрипт может быть обработан обфускатором [5] для за-щиты ноу-хау системного администратора, производящего удаленную настройку и прочее, и прочее.

Таким образом, чтобы исключить излишнюю детализа-цию описания, последовательность разработки построю та-ким образом: инструкция, локальный скрипт по способу 3, удаленное исполнение по способу 5 или 6. Это не времен-ный учебный план. Создание рабочих скриптов тоже лучше строить именно по такой схеме, начиная с текстового опи-сания и продолжая локальным скриптом с явной эскалаци-ей привилегий. Естественно, в конце цепочки разработки должна стоять некая продукционная система. Здесь предпо-лагается, что это исполнитель удаленных скриптов по спо-собу 5 или 6, разработку которого отложим на потом. То есть сейчас обсуждается лишь первый шаг данной цепочки пре-образований, а именно:

От руководства к локальному скриптуНачнем, как и обещано, с руководства. Например, с инструк-ции по настройке почтовой системы CentOS [6]. Хотя оно и так не велико, дополнительно упростим задачу, ограничив-шись только настройкой Postfix. В тексте [6] за это отвечает раздел 3.1. Актуальными являются лишь первый абзац этого раздела и 8 строк настроек в main.cf. Будем воспринимать данное руководство как техническое задание на разработ-ку локального скрипта автоматической настройки (причем в точности с описанными параметрами).

Итак, текст просто указывает на место, где надо произ-вести настройки – в main.cf, а сами настройки должны быть следующими:

Выбор именно Postfix как объекта настройки не случаен. Этот smtp-сервер имеет встроенную утилиту конфигури-рования postconf, что позволит обойтись без привлечения сложных комбинаций grep/awk/sed и так далее.

Попробуем построить скрипт согласно обобщенному алгоритму из части 2 [1]. Сначала подготовим все необхо-димые элементы. Настройка избранного параметра postfix производится следующим образом:

Предварительный опрос установленного ранее значения можно сделать как:

Хочу обратить внимание: эскалация прав требуется толь-ко для модификации. Все операции изменяют содержимое main.cf. Это значит, что данный файл надо будет сохранить до начала настроек, чтобы в случае возникновения проб-лем можно было произвести откат. Зависимый процесс – это сам postfix. Его перезапуск также очевиден:

Элемент проверки начальных зависимостей прежде все-го выражается в анализе установки пакета postfix. Проверя-ется она с помощью команды:

а ставится при необходимости как:

Но поскольку данную зависимость можно, и нужно, устранить в процессе настройки, то процедуру проверки и установки postfix просто помещаем в самом начале испол-нения. А вот другую зависимость, что требует средой испол-нения считать CentOS, можно только проверить, и в случае

sudo postconf -e myhostname=mail.example.com

rpm -q postfix

yum install postfix

postconf myhostname

sudo service postfix restart

myhostname = mail.example.com mydomain = example.com myorigin = $mydomaininet_interfaces = all

mydestination = $myhostname, localhost.$mydomain, ↵ localhost, $mydomainmynetworks = 192.168.0.0/24, 127.0.0.0/8 relay_domains =home_mailbox = Maildir/

Рисунок 6. Удаленная работа в автономном терминальном окне

Кафедра


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

Описывать пошаговое создание скрипта не позволит объем журнальной публикации, да и не стоит такая при-митивная задачка детального рассмотрения. Даже если кому-то подобное внове, то после перечисленных выше наводящих подсказок с этой задачкой справятся, надеюсь, все. Потому сразу дам окончательный вариант, который почти в точности соответствует рекомендациям к построе-нию таких алгоритмов из части 2 [1], за исключением того, что введены некоторые служебные макросы и добавлены служебные подпрограммы для сокращения текста. Итак, локальная форма настроечного скрипта представлена в листинге 1.

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

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

В ходе написания скрипта были сделаны некоторые сти-левые преобразования для удобства программирования – применены служебные макросы, и часть повторяющегося кода вынесена в подпрограммы. На первый взгляд не видно, но такие макросы, как chkc=/sbin/chkconfig, на самом деле устанавливают скрытую зависимость от расположения ути-литы chkconfig в системе. Более того, замена тривиальным $(which chkconfig) тоже будет платформеннозависимой. На-пример, в openSUSE такое будет работать. Там даже можно положиться на поиск по $PATH и не указывать путь вовсе. А вот в CentOS и RHEL для правильного исполнения надо использовать только описанный в скрипте код.

Следующим элементом, зависимым от предпочтений кодировщика, является группирование команд в подпро-граммы. В тексте на одну страничку не опасно, но в боль-шом проекте это может привести к скрытому увеличению вложенности кода. В сегменте «3- проверка параметров» можно увидеть, что передача значения $mydomain потре-бовала размещения защитного слеша перед знаком долла-ра. Но не все подпрограммы делают простую подстановку параметров. Возможно, где-то потребуется использовать конструкцию eval для подстановки значений в вызов awk, например (там знак доллара уже зарезервирован). То есть в таком случае надо точно знать глубину вложений и число разыменований, чтобы использовать нужное число защит-ных символов. Конечно, можно писать код без подпрограмм, но тогда даже подобная простейшая задача по трудоемко-сти ручного кодирования вырастет вдвое! Соответственно

Листинг 1. Скрипт автоматический настройки postfix

null=/dev/nullcnf0=/etc/postfix/main.cf.$$ pconf=/usr/sbin/postconf chkc=/sbin/chkconfigabort() { echo $1 ; exit -1 ; }abort2() { mv $cnf0 /etc/postfix/main.cf ; abort "$1" ; } cnt=0 # счетчик срабатыванийcheckconf() { $pconf $1 | awk 'BEGIN{FS="= "} ↵ {print $2}' | grep "^$2$" >$null ; } fixconf() { local t ; t=$2 ; [ -n "$t" ] || t=" " checkconf $1 $t || { sudo $pconf -e "$1=$t" checkconf $1 $t || abort2 не могу настроить $1 cnt=$((cnt+1)) } }

# 1- проверка зависимостейgrep CentOS /etc/redhat-release >$null 2>&1 || ↵ abort использовать только в CentOS

# 2- проверка пакетовrpm -q postfix >$null || { sudo yum install postfix rpm -q postfix || abort не могу поставить postfix cnt=$((cnt+1)) }

# 3- проверка параметровsudo cp /etc/postfix/main.cf $cnf0 fixconf myhostname mail.example.com fixconf mydomain example.com fixconf myorigin "\$mydomain" fixconf inet_interfaces allfixconf mydestination "\$myhostname,localhost.\ ↵ $mydomain,localhost,\$mydomain"fixconf mynetworks "192.168.0.0/24,127.0.0.0/8" fixconf relay_domainsfixconf home_mailbox Maildir/

# 4- проверка активностиLC_ALL=C $chkc --list postfix | grep $(runlevel | ↵ awk '{print $2}'):on >$null || { sudo $chkc postfix on LC_ALL=C $chkc --list postfix | grep $(runlevel | ↵ awk '{print $2}'):on >$null || \ abort2 не могу активировать postfix cnt=$((cnt+1)) }

# 5- рестарт зависимых процессов[ $cnt -gt 0 ] && sudo /sbin/service postfix restart ↵ >$null 2>&1

# 6- проверка зависимых процессовsudo /sbin/service postfix status | grep pid >$null || { mv $cnf0 /etc/postfix/main.cf sudo /sbin/service postfix restart >$null 2>&1 sudo /sbin/service postfix status | grep pid >$null && ↵ abort установки не верны

# 7- система в неопределенном состоянии echo срочно вызывайте из отпуска настоящего сисадмина ; ↵ exit -2 }

# 8- успешное завершениеrm $cnf0echo smtp-сервер postfix настроен ; exit 0

Кафедра


отладка и поиск ошибок точно так же усложнятся как мини-мум в два раза!

Можно поступить просто: в каждой подпрограмме про-водить сканирование аргументов и размещение дополни-тельных защитных слешей, например, так: sed 's/\$/\\\$/'. Но это надо будет сделать для всех таких символов, для «$», для «'», для «\» и многих других, что отнюдь не упростит код. Все вышесказанное приводит к тому, что визуально выде-лить в полученном скрипте те самые 8 строк настроек очень трудно.

Синтаксис программы ничем не напоминает исходное руководство [6]. Если допустимо утверждать, что по ру-ководству можно построить программу, то создать по та-кой программе руководство уже нельзя! Что это значит? Как минимум то, что такой скрипт затруднителен в пони-мании, не обладает свойством самодокументированности, сложен в отладке и, как следствие, тяжелый в сопрово-ждении.

Давайте зафиксируем парадокс: из ясного и понятного руководства был создан малопонятный скрипт, который для своего использования требует наличия руководства уже к скрипту! Хотя изначально программа автоматизиро-ванного администрирования создавалась как эквивалент и замена документации. Проблема эта не надуманная. Учтите, типичный цикл разработки новых релизов плат-форм на основе GNU/Linux не превышает года. Значит, даже если не учитывать возможное портирование на дру-гие совместимые платформы и выходы новых релизов ис-пользованного ПО, все равно минимум раз в год придет-ся проводить повторное тестирование и отладку такого скрипта. А он может иметь нешуточные размеры в сотни килобайт текста! И это без учета требований из части 2, которые превратили 8 строк документации в 50 строк про-граммы bash.

Обычно 8 строк в точности соответствуют 8 стро-кам в скрипте, как это сделано в программе [2]. Однако скрипт Геннадия Калашникова имеет объем 129 Кбайт! Он до сих пор доступен в Интернете, хотя скорее всего уже не актуален для новых версий программного обеспече-ния. А другие авторы, осознавая тщетность усилий, даже не переводят свои разработки в ранг релизов и изымают их из обращения, например, как это сделал Вячеслав Ка-лошин [7]. Поскольку скрипт изъят автором из публичного доступа (в Интернете и рукописи горят!), то я могу лишь предложить на веру принять, что в этой программе объе-мом в 26272 байта вопрос настройки postfix решен в точ-ности, как и в работе [2].

Таким образом, практика показывает, что требования полноты и универсальности в процессе разработки по-добных программных проектов вступают в противоречие не только с требуемой логикой алгоритмов (см. [1]), но и очень часто приводят к невозможности развития или со-провождения получаемого программного продукта. Тут уже можно сознаться, что автоматизация системного админист-рирования таким путем недостижима.

***Скриптовые консольные языки, например bash, обладают необходимой инструментальной и в какой-то степени син-таксической мощностью для решения задач системного

администрирования. Но они не имеют, точнее, не содер-жат средств выражения или отражения специфической семантики предметной области. Спросите, а при чем тут семантика и зачем она нужна? А вот потеря «этой самой» семантики и ведет к тому, что по инструкции можно напи-сать программу, а по программе создать инструкцию прак-тически нельзя. И спорить с этим не надо! Иначе каждый второй проект с открытыми исходными текстами не стра-дал бы от отсутствия адекватной сопровождающей доку-ментации. Чтобы не создавать еще один «проект-сироту», займемся проблемами семантики. Снова посмотрим сек-цию «3- проверка...». Внутри скрипта часть аргументов ко-мандных строк содержат лексические повторы. Например, mail.example.ru включает в себя подстроку example.ru, кото-рая также используется в качестве независимого аргумен-та. Очевидно, не просто так, потому что example.ru является доменом для mail. Данную семантическую связь можно от-разить в макроподстановке:

Текст стал более читаемым? Отнюдь! Кроме того, прос-тое перечисление макросов в начале скрипта (как в [7] – поверьте на слово) или в ini-файле, как в [2], решает проб-лему лишь отчасти, так как в проекте, включающем много скриптов-решений, такой подход создаст проблему стан-дартизации точно так же, как ее создает выделение части кода в общую библиотеку, приводящее к возникновению стандартов API.

Кроме того, example.ru не просто какая-то литеральная строка, это строка, написанная в соответствии с форма-том FQDN. Поищите проверку форматов параметров в [2] – не найдете! Кто успел скопировать [7], чтобы изучить, тоже будут разочарованы. Пути решения всех перечисленных вопросов и проблем начинаются с создания так называе-мой параметрической модели информационной системы. Но об этом уже в следующей части!

1. Барабанов А. Вычислительная модель. Введение в системное программирование. //Системный администратор, №12, 2009 г. – С. 18-22.

2. Новость со ссылкой на пакет автоматической установки Open-Xchange, Samba PDC и проч., разработанный Геннадием Ка-лашниковым (04.01.2006) – http://www.opennet.ru/openforum/ vsluhforumID3/13191.html.

3. Барабанов А. Размещаем пользовательские бюджеты в LDAP. Часть 1. //Системный администратор, №1, 2007 г. – С. 36-43.

Барабанов А. Размещаем пользовательские бюджеты в LDAP. Часть 2. //Системный администратор, №2, 2007 г. – С. 32-37.

4. Erdal Multu. Автоматизация системного администрирования с помощью ssh и scp. LinuxFocus.org (27.01.2003) – http://www. linuxfocus.org/Russian/January2003/article278.shtml.

5. Сайт разработчика компилятора скриптов shc – Francisco Javier Rosales Garcia – http://www.datsi.fi.upm.es/~frosal.

6. Руководство по настройке почтовой системы CentOS. Postfix HOWTO – http://wiki.centos.org/HowTos/postfix.

7. Вячеслав Калошин aka multik/kiltum. Презентация «альфа-бета-гамма»-версии скрипта настройки виртуального сервера. (29.06.2007) – http://kiltum.livejournal.com/1185215.html.

tld=example.comfixconf myhostname mail.$tld fixconf mydomain $tld

EOF

Кафедра

20

Визитка


Ext3 много лет является наиболее популярной файловой системой для Linux. Для соответствия возможностям но-вых жестких дисков и требованиям времени на ее основе была разработана ФС нового поколения – ext4, сочетаю-щая улучшенные масштабируемость и производительность при поддержке больших файловых систем с сохранением надежности и стабильности ext3. Мы рассмотрим мотивы разработки ext4, ее новые возможности, методы миграции с ext3 и сравним ее с другими файловыми системами.

Почему не ext3?Ext3 стала столь популярной благодаря своей надежности, богатому набору возможностей, относительно хорошей производительности и отличной совместимости с преды-дущими версиями Extended File System. Консервативный дизайн ext3 создал ей репутацию высоконадежной, но не-сколько ограниченной в работе с большими хранилищами файловой системы.

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

Для снятия этого ограничения в августе 2006 года была опубликована серия патчей, дающих ext3 две ключевые возможности: поддержку больших разделов и учет блоков на экстентах (необходимый из-за того, что обработка би-товых карт даже на терабайтном разделе довольно сильно нагружает CPU и память). Эти патчи необратимо меняли дисковый формат и нарушали обратную совместимость. Из соображений поддержания стабильности кода ext3 раз-работчики решили создавать на основе этих патчей новую файловую систему, назвав ее ext4.

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

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

Так была рождена ext4, присутствующая в основной вет-ке, начиная с ядра 2.6.19, и помеченная стабильной с 2.6.28 (после двух лет разработки).

Масштабирование16-терабайтный лимит размера раздела в ext3 обуслов-лен 32-битным номером блока. Логичным решением про-блемы является использование большего количества би-тов под этот параметр по всему коду ФС. В экстент-патче для ext3 вводились 48-битные номера блоков, сохранен-ные и в ext4. Теперь поддерживаются разделы размером до 1 эксабайт (Эб) (1024 Тб при 4-килобайтном блоке).

После расширения номера блока до 48 бит потребовалось внести изменения в метаданные ext4 – суперблок, дескриптор группы блоков и журнал. Новые поля были добавлены в ко-нец суперблока, расширяя s_free_blocks_count (количест-во свободных блоков), s_blocks_count () и s_r_blocks_count до 64 бит. Аналогичным образом скорректирован и дескрип-тор группы блоков – были расширены указатели на битовую карту и таблицу inodes.

Модуль журналирования блоков, JBD, был переработан в JBD2 для поддержки новых возможностей ext4. Хотя сей-час подсистему JBD2 использует только ext4, потенциаль-но она может обеспечить журналирование для любой 32- или 64-битной файловой системы.

48-битная разрядность номера блоков была выбрана по-тому, что, во-первых, предела размера ФС в 1 Эб должно хватить на много лет вперед, и, во-вторых, полная проверка с помощью e2fsck (-pf) экзабайтного раздела займет 119 лет при современных скоростях дисков.

Несмотря на расширение номера блока до 48 бит, размер раздела ext4 все еще ограничен количеством групп блоков в файловой системе. В ext3 из соображений безопаснос-ти все дескрипторы групп блоков продублированы в первой

Ext4 подходит для самых разнообразных рабочих нагрузок и способна полностью заменить ext3 в ка-честве «файловой системы Linux»

Взгляд на ext4Не новое, но хорошо доработанное старое

АНДРЕЙ ПЕШЕХОДОВ, выпускник Ивановского государственного энергетического университета, главный инженер ООО «Иваново ТВ-Тренд». Профессиональные интересы: GNU/Linux, MS Windows, архитектура файловых систем

Кафедра


из них. Поскольку новый дескриптор группы блоков имеет длину 64 байта, ext4 могла бы иметь объем не более 256 Тб.

Решение проблемы – использовать метагруппы блоков (META_BG), существующие в ext3, начиная с ядра 2.6.0. С оп-цией META_BG ext4 разбивается на несколько метагрупп, каждая из них является кластером такого количества групп блоков, дескрипторы которых могут храниться в одном бло-ке ФС. В 4-килобайтном блоке помещается 64 дескрипто-ра нового формата, т.е. одна метагруппа может адресовать до 8 Гб дискового пространства. Использование метагрупп позволяет вынести дескрипторы конкретных групп блоков из перегруженной первой группы раздела в первые группы каждой метагруппы. Резервные копии дескрипторов хранят-ся во второй и последней группе блоков каждой метагруп-пы. Все эти меры позволяют адресовать с помощью групп блоков 1 Эб дискового пространства.

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

Экстентом называется дескриптор, определяющий уча-сток в нескольких непрерывно расположенных дисковых блоках. В ext4 экстент может адресовать до 128 Мб дис-кового пространства при 4-килобайтном блоке. 4 экстен-та могут храниться прямо в inode – их вполне достаточно для небольших или нефрагментированных файлов. Когда встроенных экстентов не хватает, для адресации блоков файла используется дерево экстентов постоянной глубины (см. рисунок). Корень его хранится в inode, сами экстен-ты – в листьях. Каждый узел дерева начинается с заголовка (fs/ext4/ext4_extents.h):

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

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

Еxt4 сочетает улучшенные мас-штабируемость и производитель-ность при поддержке больших файловых систем с сохранением надежности и стабильности ext3

/* * Каждый узел (листовой, индексный или корневой) * начинается с этого заголовка */struct ext4_extent_header {

/* в будущем возможны несколько форматов узлов, * тогда пригодится этот magic */ __le16 eh_magic; /* количество элементов */ __le16 eh_entries; /* максимально элементов */ __le16 eh_max; /* глубина дерева, начиная с этого уровня */ __le16 eh_depth; /* номер поколения дерева */ __le32 eh_generation; };

/* * Структура индекса в дереве экстентов: */struct ext4_extent_idx { /* индекс покрывает логические блоки, * начиная с этого */ __le32 ei_block; /* указатель на блок следующего уровня * (младшие 32 бита) */ __le32 ei_leaf_lo; /* (старшие 16 бит) */ __le16 ei_leaf_hi; __u16 ei_unused; };

/* * Экстент ext4 */struct ext4_extent { /* логическое начало экстента */ __le32 ee_block; /* длина экстента в блоках */ __le16 ee_len; /* физическое начало экстента (старшие 16 бит) */ __le16 ee_start_hi; /* (младшие 32 бита) */ __le32 ee_start_lo; };

Кафедра


Большие файлыВ файловой системе ext3 размер файла ограничен 32-бит-ным полем i_blocks в inode, которое содержит количество секторов (512 байт), занимаемых файлом. В итоге мак-симальный размер файла в ext3 ограничен величиной 232 * 512 = 2 Тб, что для ФС нового поколения недостаточно.

В ext4 эта проблема решена достаточно прямолиней-но и бесхитростно: разрядность поля i_blocks увеличена до 48 бит, размер теперь исчисляется в блоках. В результа-те размер файла ext4 ограничен только 32-битным номером логического блока в текущем формате экстента и состав-ляет 16 Тб. В будущем планируется снятие этого ограниче-ния и достижение полной 48-битной емкости в несколько эксабайт.

Большие каталогиНекоторые приложения уже в наше время оперируют мил-лиардами файлов и даже замахиваются на триллионы. Тео-ретически ext4, располагая 32-битным номером inode, мо-жет оперировать миллиардами файлов, однако на практике эта величина недостижима из-за архаичного статического выделения inodes, пришедшего в Extended Filesystem еще из BSD FFS. Количество файлов на разделе жестко зада-ется во время создания ФС. Задумавшись о реализации динамического выделения inodes с увеличенными 64-бит-ными номерами, разработчики остановились на следующих моментах:

производительность – необходим эффективный способ отображения номеров inodes в их физическое положе-ние на диске;устойчивость к сбоям оборудования – e2fsck должна иметь возможность быстро отыскивать все inodes после разрушения ФС;совместимость – необходимо решать проблемы обра-ботки 64-битных номеров inodes на 32-битных машинах. При динамическом выделении inodes они больше не об-

ладают фиксированным положением на диске. Одним из способов отображения номера inode на номер содер-жащего его блока является прямое кодирование координат inode в его номере, как это сделано в XFS. Недостатки мето-

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

Панацеей может стать введение дополнительных карт, отображающих старые координаты inodes на новые, что трудно назвать хорошей идеей. Решение проблемы поиска динамически выделяемых inodes с помощью ин-дексирующих их бинарных деревьев (как это сделано в подавляющем большинстве файловых систем) приведет к полной переделке структуры ФС, утрате аккумулирую-щей роли групп блоков и фактически выльется в создание полностью новой, ни с чем не совместимой ФС, что непри-емлемо. То же можно сказать и о расширении номера inode до 64 бит.

Выгоды от динамического выделения и 64-битных номе-ров inodes очевидны, однако объем требуемых изменений дисковой структуры необычайно велик, поэтому сейчас эти вопросы все еще находятся в стадии обсуждения. Со-ответствующий функционал не вошел в релиз и, видимо, будет осуществлен не скоро (а по мнению автора, не бу-дет реализован вообще, в свете успехов в разработке btrfs (btrfs.wiki.kernel.org) и все большего внимания к ней не толь-ко пользователей, но и многих мэйнтейнеров ядра).

Масштабируемость каталоговОбъем каталога ext3 ограничен величиной в 32 000 файлов. В ext4 этот лимит полностью устранен, то есть количество файлов в одном каталоге там не ограничено. Для поддержки больших каталогов в ext4 вместо односвязного списка ис-пользуется схема индексирования их элементов с помощью так называемых HTree-структур, своего рода B-деревьев постоянной глубины, индексирующих элементы директории по 32-битному хешу имени. Для каталогов, содержащих бо-лее 10 000 файлов, производительность поиска имени воз-росла в 50-100 раз относительно ext3.

Inodes и расширенные атрибутыExt3 поддерживает inodes различного размера, задаваемо-го во время mke2fs параметром -I [inodes_size]. В ext4 мини-мальный размер inode увеличен вдвое – до 256 байт. Для со-хранения совместимости с кодом драйвера ext3 и e2fsck размеченная часть inode имеет старый формат. В допол-нительной секции расположены несколько новых полей (к примеру, наносекундные временные штампы) и динами-ческая область, используемая под расширенные атрибуты (extended attributes, EAs).

/* Дисковый inode ext4s */ struct ext4_inode { /* флаги доступа и типа */ __le16 i_mode; /* с */ __le16 i_uid; /* размер в байтах */ __le32 i_size_lo; /* время доступа */ __le32 i_atime; /* время модификации inode */ __le32 i_ctime;

Дерево экстентов ext4

Кафедра


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

Суперблок содержит два связанных с этим вопросом поля:

s_min_extra_size – гарантированный размер дополни-тельной статической области;s_want_extra_size – желаемый некоей версией, но не га-рантируемый размер экстра-области.Оставшееся пространство в inode может быть исполь-

зовано для хранения встроенных расширенных атрибутов прямо в inode, что существенно увеличивает производи-тельность их обработки. Также по-прежнему доступен до-полнительный EA-блок, позволяющий хранить еще 4 Кб атрибут-данных для каждого файла. Возможность хранения большего количества EAs в форме регулярного каталога не реализована.

Предразмещение (preallocation)Некоторым приложениям, например базам данных и пото-ковым медиа-серверам, необходимо размещать впрок бло-ки для расширения файла, но без записи в них каких-либо данных. Это позволяет выделять блоки более непрерывно и гарантирует необходимое пространство для записи в пре-делах предразмещенной области. Внутренне файловая сис-тема рассматривает неинициализированные участки файла как заполненные нулями, что позволяет избежать несанкци-онированного просмотра устаревших данных. Предразме-щение должно быть устойчивым к перезагрузке, в отличие от так называемого резервирования блоков в ext3/4.

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

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

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

Отложенное размещение – хорошо известная техни-ка, суть которой в отсрочке выделения блоков до времени сброса страниц (flush). Это позволяет обеспечить более эф-фективную с точки зрения фрагментации и нагрузки на CPU группировку запросов на размещение. Короткоживущие временные файлы при этом могут вообще не получить дис-кового воплощения, оставаясь лишь в кэше. Патчи с реа-лизацией отложенного размещения для ext4 уже написаны, сейчас идет работа по выносу соответствующего функцио-нала на уровень VFS для его разделения с другими файло-выми системами.

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

/* время модификации данных файла */ __le32 i_mtime; /* время удаления */ __le32 i_dtime; /* младшие 16 бит GID владельца */ __le16 i_gid; /* количество ссылок на inode */ __le16 i_links_count; /* количество блоков (младшие биты) */ __le32 i_blocks_lo; /* флаги */ __le32 i_flags; union { struct { /* младшие 32 бита версии */ __le32 l_i_version; } linux1; struct { /* не Linux */ __u32 h_i_translator; } hurd1; struct { /* не Linux */ __u32 m_i_reserved1; } masix1; } osd1; /* указатели на блоки данных файла */ __le32 i_block[EXT4_N_BLOCKS]; /* номер поколения (для NFS) */ __le32 i_generation; /* указатель на ACL (младшие биты) */ __le32 i_file_acl_lo; __le32 i_size_high; /* не используется */ __le32 i_obso_faddr; union { struct { /* количество блоков (старшие биты) */ __le16 l_i_blocks_high; /* указатель на ACL (старшие биты) */ __le16 l_i_file_acl_high; /* старшие 16 бит UID владельца */ __le16 l_i_uid_high; /* старшие 16 бит GID владельца */ __le16 l_i_gid_high; __u32 l_i_reserved2; } linux2; struct { /* не Linux */ __le16 h_i_reserved1; __u16 h_i_mode_high; __u16 h_i_uid_high; __u16 h_i_gid_high; __u32 h_i_author; } hurd2; struct { /* не Linux */ __le16 h_i_reserved1; __le16 m_i_file_acl_high; __u32 m_i_reserved2[2]; } masix2; } osd2; __le16 i_extra_isize; __le16 i_pad1; /* время модификации inode (наносекунды) */ __le32 i_ctime_extra; /* время модификации i-данных файла (наносекунды) */ __le32 i_mtime_extra; /* время доступа (наносекунды) */ __le32 i_atime_extra; /* время создания файла */ __le32 i_crtime; /* время создания файла (наносекунды) */ __le32 i_crtime_extra; /* старшие 32 бита версии */ __le32 i_version_hi; };

Кафедра


что исключает множество лишних вызовов ext4_get_blocks() и ext4_new_blocks() и уменьшает нагрузку на процессор.

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

Прирост производительности от отложенного и много-блочного размещения оказался существенным: на 30% возросла пропускная способность ФС, нагрузка на CPU снизилась почти на 50%. Цена этого решения – увеличение времени монтирования ФС.

Кроме прочего, в разработке находятся еще две воз-можности, надстраиваемые над отложенным многоблочным размещением, с которыми связывают большие надежды на серьезное уменьшение фрагментации ФС:

Перспективное предразмещение (in-core preallocation) – информацию о свободных экстентах можно использовать для построения более мощного механизма предразмещения и резервирования дисково-го пространства. Каждый inode может иметь несколько заранее зарезервированных сегментов, индексируе-мых в логических блоках, что, к примеру, облегчит HPC-приложениям запись в файл с множества узлов по со-вершенно непредсказуемым смещениям.Группы размещения (locality groups) – сейчас решение по выделению блоков принимается независимо для каж-дого файла. Однако если аллокатор будет располагать информацией о логических взаимосвязях объектов ФС, он сможет размещать связанные файлы ближе друг к другу, что существенно улучшит производительность чтения/поиска. Аллокатор может отслеживать некоторое количество еще не выделенных блоков (на уровне групп) и пытаться зарезервировать для них соответствующее количество дискового пространства. Этот объем бу-дет использован позднее, при сбросе страниц на диск, для назначения конкретных блоков конкретным файлам. Все это, ценой незначительного повышения нагрузки на CPU, приведет к существенному уменьшению фраг-ментации файловой системы и более оптимальному, с точки зрения производительности, размещению свя-занных данных на диске.Можно с уверенностью сказать, что ext4 располагает до-

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

Фоновая дефрагментацияХотя функционал, описанный выше, заметно улучша-ет фрагментационную устойчивость файловой системы, со временем на активно используемой ФС фрагментация все же может стать существенной. Для решений этой про-блемы была разработана программа e4defrag, способная дефрагментировать как отдельные файлы, так и весь том. При работе над отдельным файлом программа создает вре-менный inode и выделяет под все данные файла один (если возможно) или несколько экстентов, используя многоблоч-ное размещение. После копирования данных файла блоч-ные указатели в inodes подменяются на новые, а временный inode удаляется.

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

Одна из важнейших характеристик любой файловой системы – время восстановления после сбоя. К примеру, на вполне обычном в наше время массиве объемом в 2 Тб ext3 будет восстанавливаться до работоспособного состоя-ния в среднем от двух до четырех часов, а в худшем слу-чае – до нескольких суток. Использование экстентов очень хорошо сказалось на масштабировании этого параметра, в разработке также находятся еще несколько дополнитель-ных схем.

Подсчет неиспользуемых inodes и ускорение e2fsckБезусловно, наиболее трудоемкой операцией в e2fsck яв-ляется проверка inodes на первом проходе. Она требует чтения с диска всех таблиц inodes, поиска в них целых, раз-рушенных и неиспользуемых inodes, внесения необходи-мых исправлений и обновления битовых карт размещения блоков и inodes. Неиспользуемые группы блоков и табли-цы inodes теперь имеют особую логическую метку, позво-ляющую пропустить значительную часть первого прохода, что поможет существенно уменьшить общее время работы e2fsck. Эта возможность может быть задействована во вре-мя mke2fs или позднее с помощью опции -O uninit_groups утилиты tune2fs.

С этой опцией ядро сохраняет количество неисполь-зуемых inodes в конце inode-таблицы каждой группы бло-ков. В результате e2fsck может пропустить как чтение этих блоков с диска, так и их сканирование на предмет поиска разрушений. Для подтверждения подлинности информации о неиспользуемых inodes дескриптор группы содержит кон-трольную сумму (CRC16).

Типичная ФС типа ext3 использует от 1 до 10% своих inodes, и все они находятся в началах inode-таблиц, поэтому указанное нововведение позволяет избежать чтения и об-работки существенного количества метаданных на пер-вом проходе e2fsck. Сейчас драйвер ext4 не увеличивает счетчик неиспользованных inodes при удалении файлов – это делает только e2fsck. Поэтому на ФС с большим коли-чеством удаленных файлов fsck будет работать значительно быстрее при втором запуске.

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

Кафедра


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

Каждая транзакция имеет блок-заголовок и фиксирую-щий блок (commit-block). Во время нормальной журнальной операции фиксирующий блок не сбрасывается на диск, пока там не окажутся заголовок и все метаданные. Следую-щая транзакция будет вынуждена ждать полной фиксации предыдущей, прежде чем начинать изменение ФС. Таким образом, совпадение номера транзакции у заголовка и фик-сирующего блока служит сигналом к запуску этой транзак-ции во время восстановления ФС, а если номера различа-ются – чтение журнала прекращается. Однако существуют несколько сценариев, в которых подобное поведение может вызвать разрушение метаданных.

В защищенном журнале драйвер ext4 вычисляет кон-трольную сумму (CRC32) для всех блоков транзакции (включая заголовок) и записывает ее в фиксирующий блок. Если при восстановлении из журнала обнаружива-ется несоответствие этой контрольной суммы фактиче-ски прочитанным с диска данным, это значит, что один или несколько блоков метаданных оказались разрушены или вовсе не были записаны на диск в результате ошибки оборудования. В таком случае транзакция отбрасывается целиком, а пользователю рекомендуется воспользоваться e2fsck.

Также значительным выигрышем от использования по-добной защиты журнала является отказ от пошаговой фик-сации транзакции (запись фиксирующего блока теряет вся-кий смысл), что может увеличить пропускную способность журнала более чем на 20%.

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

Другие нововведенияРазработчики продолжают постоянно добавлять новые воз-можности в ext4. Два наиболее ожидаемых – реализация на-носекундных временных штампов и отслеживание версий inode (versioning). Эти возможности позволяют достичь аб-солютной точности при работе с временем доступа к файлу и отслеживании изменений в нем.

Ext3 располагает тайм-штампами второго порядка, одна-ко на современных высокопроизводительных процессорах и системах хранения этого недостаточно. С введением уве-личенного inode в ext4 появилась возможность записывать временные штампы с наносекундной точностью, на что до-статочно 30 бит 32-битного поля штампа. Оставшиеся 2 бита применяются для расширения эпохи на 272 года.

Клиенты четвертой версии NFS нуждаются в возможнос-ти обнаруживать изменения в файле, сделанные на стороне

сервера, чтобы поддерживать клиентский кэш в актуальном состоянии. Для этого в ext4 на каждый inode введен глобаль-ный 64-битный счетчик, инкрементируемый драйвером пос-ле каждого обновления файла. Сравнивая значения счет-чика на стороне сервера со своими, клиент NFSv4 может понять, изменялся ли файл. Этот счетчик обнуляется при создании файла, а его переполнение не имеет значения, т.к. проверяется лишь равенство.

Миграция на ext4В свое время разработчики уделили особое внимание со-хранению обратной совместимости ext3 с ext2, и пользо-ватели оценили эту возможность. Однако в случае с ext4 не удалось избежать ряда несовместимых с ext3 изме-нений дискового формата, хотя пользователи могут ис-ключительно просто обновить свою ext3 до новой версии, так же, как это было при переходе с ext2. Доступны методы как для простого ознакомления с возможностями новой ФС, так и для миграции всей файловой системы без применения резервных копий.

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

Кафедра


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

Кроме того, для полной миграции с ext3 на ext4 со вре-менем будет подготовлена специальная утилита, осущест-вляющая преобразование косвенной структуры адресации в экстентную и увеличивающая размер inode до 256 байт. В качестве частичной меры переход к экстент-адресации может быть выполнен достаточно просто – с использовани-ем процедуры дефрагментации, во время которой файлы не только перемещаются в новые экстенты, но и дефраг-ментируются. Эта процедура может работать на смонтиро-ванной ФС.

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

Откат с ext4 обратно к ext3 также возможен, хотя и не столь очевиден и красив, как обновление ФС. Для этого необходимо смонтировать раздел с опцией -noextents, ско-пировать все файлы во временные, а затем заменить ими оригинальные. После того как все файлы будут приведе-ны к косвенной схеме адресации, необходимо с помощью tune2fs сбросить флаг INCOMPACT_EXTENTS, а затем смон-тировать ФС как ext3.

Для выполнения полной миграции на ext4 с файловых систем предыдущих поколений (ext2/3) разработчики, не-смотря на признанную стабильность кода новой ФС, реко-

мендуют сделать резервную копию важных данных с обнов-ляемого раздела.

Поскольку обновленный раздел более не удастся при-монтировать как ext2/3, необходимо убедиться, что вы рас-полагаете необходимым набором ПО для полноценного ис-пользования новой файловой системы:

> e2fsprogs 1.41.6;> mount 2.16;> ядро Linux от 2.6.28 и выше;> grub 1.96+20090808 (если обновляется загрузочный

раздел).Если обновляется раздел ext2, то для начала нужно кон-

вертировать его в ext3:

Перед началом обновления до ext4 рекомендуется сде-лать проверку файловой системы на наличие ошибок:

Затем включаем все предоставляемые ext4 новые воз-можности:

После чего также рекомендуется пройтись по разделу утилитой fsck:

Опция -D заставит fsck заняться оптимизацией ката-логов – для директорий с поддержкой индексов будет вы-полнено переиндексирование, для обычных линейных ката-логов ext3 – пересортировка и сжатие. Опция -p отвечает за проверку ошибок, -y заставит утилиту автоматически отвечать согласием на все возникающие в ходе проверки вопросы, -f – принудительная проверка даже в случае, когда файловая система выглядит чистой.

Еxt4 на фоне предшественников и конкурентовПосмотрим на сравнительную таблицу основных характе-ристик ext3, ext4 и XFS (как наиболее производительной и функциональной, по мнению автора, из современных ФС). Как видно, ext4 уступает по многим параметрам даже разра-ботанной более 15 лет назад XFS, не говоря уже о файловых системах нового поколения – ZFS и btrfs.

И все же она остается идеальным выходом для систем-ных администраторов, годами использующих ext3 как наи-более надежную и хорошо поддерживаемую файловую систему с богатым набором средств устранения неполадок и восстановления поврежденных данных. Довольно легко обновив существующие ext2/3-разделы до новой версии, пользователи получают для своих хранилищ производи-тельную и очень надежную ФС, не имеющую каких-либо явных ограничений типа максимального размера раздела или файла.

1. Исходные коды ядра Linux версии 2.6.32.2. http://ext4.wiki.kernel.org.3. Ext4 block and inode allocator improvements – http://ols.

fedoraproject.org/OLS/Reprints-2008/kumar-reprint.pdf.4. The new ext4 filesystem: current status and future plans – https://

ols2006.108.redhat.com/2007/Reprints/mathur-Reprint.pdf.

sudo tune2fs -j [device]

fsck.ext3 -pfy [device]

tune2fs -O extents,uninit_bg,dir_index [device]

fsck.ext4 -yfpD /dev/sdc1

ext3 ext4 XFS

Предельный

размер раздела

16 Тб 1 Эб 16 Эб

Предельный

размер файла

2 Тб 16 Тб 8 Эб

Количество файлов 232 232 264

Размер inode 128 байт 256 байт переменный

Учет занятых

блоков

косвенно-

блочная схема

экстенты экстенты

Учет свободных

блоков

битовые карты битовые карты B+ деревья

Разрешение

временных

штампов

секунды наносекунды секунды

Количество

подкаталогов

216 не ограничено не ограничено

Объем под Extended

Attributes

4 Кб >4 Кб не ограничен

Дефрагментация отсутствует реализована реализована

Индексирование

каталогов

отсутствует реализовано B+ деревья

Отложенное

размещение

отсутствует реализовано реализовано

Многоблочное

размещение

элементарное продвинутое продвинутое

EOF

Сравнительная таблица основных характеристик ФС ext3, ext4 и XFS

Bugtraq


Составил Александр Антипов

Множественные уязвимости в Sun Java System Web ServerПрограмма: Sun Java System Web Server 7.0u7, возмож-но, другие версии.Опасность: Высокая. Наличие эксплоита: Нет.Описание: 1. Уязвимость существует из-за ошибки про-верки границ данных при обработке OPTIONS-запросов. Удаленный пользователь может с помощью слишком длинного пути в запросе вызвать переполнение сте-ка и выполнить произвольный код на целевой системе. Для успешной эксплуатации уязвимости требуется под-держка WebDAV.

2. Уязвимость существует из-за ошибки при обра-ботке TRACE-запросов. Удаленный пользователь может с помощью специально сформированного запроса вы-звать переполнение динамической памяти и получить доступ к потенциально важным данным.

3. Уязвимость существует из-за ошибки при обработке заголовков Authorization в PUT-запросах. Удаленный поль-зователь может с помощью специально сформированно-го запроса вызвать переполнение динамической памяти. URL производителя: www.sun.com.Решение: В настоящее время с пособов устранения уяз-вимости не существует.

Уязвимость при расшифровке RC4 и AES в Kerberos KDCПрограмма: Kerberos-версии до 1.6.4 и 1.7.1. Опасность: Высокая.Наличие эксплоита: Нет.Описание: Уязвимость существует из-за ошибки потери значимости целочисленных при обработке AES и RC4-шифров, которые короче минимальной ожидаемой дли-ны. Удаленный пользователь может с помощью специ-ально сформированных данных вызвать переполнение динамической памяти и выполнить произвольный код на целевой системе.URL производителя: web.mit.edu/kerberos/www. Решение: Установите исправление с сайта производи-теля.

Множественные уязвимости в Oracle JRockitПрограмма: Oracle JRockit R27.6.5 и более ранние вер-сии.Опасность: Высокая. Наличие эксплоита: Нет.Описание: Обнаруженные уязвимости позволяют уда-ленному пользователю обойти некоторые ограничения безопасности, вызвать отказ в обслуживании и скомпро-метировать целевую систему.URL производителя: www.oracle.com.Решение: Установите исправление с сайта производи-теля.

Множественные уязвимости в Oracle DatabaseПрограмма: Oracle Database 11g версия 11.1.0.7; Oracle Database 10g Release 2 версии 10.2.0.3 и 10.2.0.4; Oracle Database 10g версия 10.1.0.5; Oracle Database 9i Release 2 версии 9.2.0.8 и 9.2.0.8DV.Опасность: Высокая. Наличие эксплоита: Нет.Описание: 1. Уязвимость существует из-за ошибки в ком-поненте Listener. Удаленный пользователь может выпол-нить произвольный код на целевой системе. Для успеш-ной эксплуатации уязвимости приложение должно быть установлено на Windows-систему.

2. Уязвимость существует из-за ошибки в компоненте Oracle OLAP. Удаленный аутентифицированный пользо-ватель может выполнить произвольный код на целевой системе.

3. Уязвимость существует из-за ошибки в компоненте Application Express Application Builder. Удаленный аутен-тифицированный пользователь может изменить и про-смотреть некоторые данные.

4. Уязвимость существует из-за ошибки в компонен-те Oracle Data Pump. Удаленный аутентифицированный пользователь может изменить и просмотреть данные.

5. Уязвимость существует из-за ошибки в компоненте Oracle Spatial. Удаленный аутентифицированный пользо-ватель может изменить и просмотреть некоторые данные.

6. Уязвимость существует из-за ошибки в компоненте Logical Standby. Удаленный аутентифицированный поль-зователь может изменить некоторые данные.

7. Уязвимость существует из-за ошибки в компоненте RDBMS. Удаленный аутентифицированный пользователь может изменить и просмотреть некоторые данные.

8. Уязвимость существует из-за ошибки в компоненте Oracle Spatial. Удаленный аутентифицированный пользо-ватель может изменить и просмотреть некоторые данные.

9. Уязвимость существует из-за ошибки в компоненте Unzip. Удаленный аутентифицированный пользователь может изменить и просмотреть некоторые данные.URL производителя: www.oracle.com.Решение: Установите исправление с сайта производи-теля.

Повреждение памяти в FASYNC в ядре LinuxПрограмма: Linux kernel 2.6.28 и более ранние версии. Опасность: Низкая.Наличие эксплоита: Да.Описание: Уязвимость существует из-за ошибки исполь-зования после освобождения при обработке дескрипто-ров файлов, с установленным флагом FASYNC. Локаль-ный пользователь может вызвать отказ в обслуживании или выполнить произвольный код на системе с повышен-ными привилегиями.URL производителя: www.kernel.org.Решение: Установите последнюю версию 2.6.31.12 или 2.6.32.4 с сайта производителя.



Евгений Касперский:«Наш бизнес – это пятый элемент»На вопросы читателей «Системного администра-тора» отвечает генеральный директор компании «Лаборатория Касперского» Евгений Касперский

Галина Положевец

Евгений Касперский родился в Ново-российске в 1965 году. Любовь к мате-матике предопределила его техническое будущее. Одним из любимых увлечений Евгения в школьные годы было решение задачек из математических журналов. В старших классах посещал факульта-тивную физико-математическую школу при МФТИ. Последние два класса учился в физико-математическом интернате при МГУ. В 1987 году окончил Институт крип-тографии, связи и информатики, где по-мимо математики и криптографии изучал компьютерные технологии. Специальность – инженер-математик.

Евгений Касперский после института попал в многопрофильный НИИ при Министерстве обороны. Здесь он стал изучать феномен компьютерных вирусов. Обнаружив на своем рабочем компьютере вирус Cascade, Евгений разобрал его и придумал первое в своей жизни компьютерное противоядие. Затем стал коллекционировать вредонос-ные программы, создавая к ним лечащие модули. В 1991 году перешел на работу в компанию «КАМИ», где вместе с группой единомышленников развивал антивирус-ный проект Antiviral Toolkit Pro – прототип будущего Антивируса Касперского. 21 июля 1997 года «Лаборатория Касперского» была зарегистрирована как самостоятельная компания. Евгений стал ее соучредителем. В 2007 году назначен на пост генерального директора «Лаборатории Касперского».

Евгений Касперский – один из ведущих мировых антивирусных экспертов. Он ре-гулярно выступает на профессиональных семинарах и конференциях антивирусных специалистов по всему миру. Кроме того, ему принадлежит немало статей и обзоров, посвященных компьютерной вирусологии. Его коллекция вредоносных программ легла в основу антивирусной базы Антивируса Касперского. Сейчас она насчитывает бо-лее 1,3 миллиона записей и является одной из наиболее полных в мире.



– Нужен ли антивирус в защищен-ной операционной системе, если она работает правильно и не содер-жит уязвимостей?– Во-первых, под понятием «антиви-рус» сейчас подразумевается защита не только от компьютерных вирусов, но от всевозможных киберугроз. При-чем угрозы различаются в зависимости от типа электронных устройств. Допу-стим, для мобильных телефонов суще-ствует риск не только заражения, но и потери конфиденциальных данных – никому не хочется, чтобы его адресная книжка попала в чужие руки. Поэтому в нашем решении для смартфонов и КПК одна из важнейших составляю-щих – модуль «Антивор». Таким обра-зом, даже защищенной операционной системе – например, Symbian 9 – тре-буется решение по безопасности.

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

Доверенные приложения долж-ны быть прописаны в неком реестре. Чтобы добавить в него свой продукт, разработчики софта вынуждены по-лучать «добро» от производителей ОС либо в сертификационном центре. В Symbian, например, решения прини-маются месяцами – виноват длинный бюрократический процесс. И ничего не поделаешь.

Разрабатывать приложения для за-щищенной операционной системы не так удобно, как для свободной не-безопасной ОС. Все, точка. Поэтому ответ на вопрос, нужен ли антивирус защищенной операционной системе, однозначен: нет, потому что защищен-ная ОС мало кому нужна.

Однако я верю в победу защищен-ных ОС в узких сегментах, допустим, для банкоматов. Или, к примеру, в во-енном секторе – я более чем уверен, что в России при выполнении военных, космических, ядерных программ ис-пользуются собственные разработки, а не «массовые» операционные сис-темы.

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

Однажды меня спросили, что вы будете делать, когда не будет виру-сов? Я ответил: «Я буду делать то же, что и метеорологи, когда наступит ис-ключительно хорошая погода. Или чем

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

На самом деле я бы в любом случае нашел себе занятие. Меня бы захва-тила другая идея, и без работы я бы не остался.

– Какой антивирус посоветуете, если используется ОС Solaris 10 c поднятым Trusted Extensions?– Ребята, не знаю. Я не большой спе-циалист в этих вопросах. Заходите к нам на форум (http://www.kaspersky. ru/support/forums или http://forum. kasperskyclub.ru), вам обязательно помогут. Я же на «солярке» никогда не работал.

– Как быть, если я хочу про-верить файл размером более 1 мегабайта на странице http://www.kaspersky.ru/scanforvirus? Эта услуга похожа на PR-акцию, ведь скачиваемые в сети архивы по раз-меру часто больше мегабайта.– Здесь нет никакого подвоха. Огра-ничение по размеру установлено для того, чтобы не грузить наш сервис.

– Летом пострадал от того, что поль-зовалась банкоматом ATM Diebold Opteva 720, в котором была заклад-ка, скорее всего программная. Если

назвать оное вирусом, то каково ваше мнение об их присутствии в банкоматах? Технически откуда они там берутся?– Действительно, в прошлом году было зафиксировано несколько атак на бан-коматы различных банков и систем. Атаки были инсайдерские – «закладка» попадала в банкомат во время его из-готовления. Злоумышленники провели атаку с помощью типичной троянской программы, особенностью которой было то, что она «заточена» именно под ОС для банкоматов. И люди, ко-торые писали программу, точно знали протокол работ, по которому идет про-цесс считывания пластиковых карт.

После этого случая руководители компаний, выпускающих банкоматы, оказались в тупиковом положении: не будет же над каждым программи-стом стоять человек с ружьем!

Правда, были в России случаи, когда банкоматы взламывали извне. Первый подобный эпизод произошел в Уфе в ноябре 2008-го. Ребята полу-чили физический доступ к банкомату, «хакнули» Windows, установили курс доллара на уровне 1500 рублей и об-меняли по нему 800 долларов, полу-чив таким образом более миллиона рублей. Однако проделывали они эту аферу под видеокамерой, потому их быстро обнаружили.

– Кто по закону должен нести от-ветственность за несвоевременное удаление троянской программы?– Хороший вопрос! Нет такого термина, как «несвоевременное удаление». Од-нако между банком и клиентом обыч-но заключается договор об оказании услуг. И если банк нарушает какой-либо из пунктов договора, то на него, конечно, можно подать в суд.

– Заключают ли банки с вашей ком-панией соглашение об антивирус-ном обслуживании ATM-машин (бан-коматов)?

Ответ на вопрос, нужен ли антивирус защищенной операционной системе, однозначен: нет, потому что защи-щенная ОС мало кому нужна



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

– Каковы принципы работы утили-тов Лаборатории Касперского? По-моему, бесплатные утилиты от ЛК просто издевательство над здра-вым смыслом.– Объясняю, зачем нужны бесплатные утилиты. Порой встречаются особенно хитрые способы заражения компьюте-ра, которые «заточены» на то, чтобы их не могли вылечить стандартным антивирусом. И в таких случаях мы вы-пускаем отдельные бесплатные утили-ты – никак не для того, чтобы привлечь к себе внимание. Например, утилита KKiller.exe помогла очень многим лю-

дям, заразившимся известным червем Kido (Conficker).

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

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

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

– В нашем городе некоторые си-стемные администраторы до сих пор переустанавливают серверы

и плачут по пропавшим данным в результате действий вируса Kido. Что это: российская ментальность, плохая информационная пропаган-да или плохие антивирусы?– Не надо называть это российской мен-тальностью. Бардак есть везде, просто у каждого свой уровень бардака.

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

Пенять можно только на собст-венную лень: на каждом углу кричали о Kido, надо просто не лениться и чи-тать, интересоваться своей темой.

– Вы с вирусами боретесь или сосу-ществуете?– Я ими не болею!

– Когда индусы будут писать вирусы под Linux?– Вирусы в основном пишутся в Китае и Латинской Америке. Вирусы пишут и этнические русские, проживающие в разных странах, и турки, и американ-цы. А вот Индия в самом конце этого списка. Почему? Казалось бы, Китай и Индия сопоставимы по численности населения, по экономической ситуа-ции, но менталитет разный. А я уверен, что уровень компьютерной преступ-ности зависит в том числе и от мента-литета ее граждан. Есть государства, где не воруют – например, японцы рас-ценивают воровство как неуважение к себе.

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

вирусов. Так же просто можно объяс-нить, почему мало «вирья» под смарт-фоны. Дело в том, что ИТ-преступники живут в основном в странах, где не распространены смартфонные сервисы, на которые пользователи тратят деньги.

– Не кажется ли вам, что как-то не-скромно называть свой продукт в честь самого себя?– Абсолютно согласен! Я страшно со-противлялся, не хотел, чтобы компания носила мое имя. Однако моя бывшая жена, Наталья Касперская, настояла, и большое ей за это спасибо, потому что имя работает. Да, иногда я от сло-восочетания «Лаборатория Каспер-ского» вздрагиваю. Но что делать: есть у меня такой «недостаток», я к нему привык и живу с ним.

– Как скоро устареют антивирусы? Не может же эта гонка продолжать-ся бесконечно?– Сколько тысяч лет существуют уличные воришки? «Не может же это продолжаться бесконечно?» Может! Просто раньше преступность была «уличная», а теперь она перешла в ки-берсреду.

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

– Смогут ли люди, погружающиеся в виртуальную реальность, зара-жаться компьютерными вирусами?– Да. Мне однажды сон такой приснил-ся. Я думаю, что рано или поздно чипы будут встраиваться в организм челове-ка. Да уже проводятся подобные экс-перименты! Так что все может быть. Почему нет?

Если бы неандертальцу сказали, что рано или поздно ему в обязательном порядке придется ходить с пластико-вой карточкой в кармане, он бы не по-верил и, наверное, спросил: «А что та-кое карман?»

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

Я думаю, что рано или поздно чипы будут встраиваться в организм чело-века. Да уже проводятся подобные эксперименты! Так что все может быть. Почему нет?



сить пользу человечеству, потому что не сможет поднять в воздух ни одного пассажира.

– Собирается ли «Лаборатория Кас-перского» бороться с «социальны-ми вирусами», перегружающими сайты?– Социальный вирус – неправильный термин, он не технологический. Есть спам, с ним боремся. С компьютерным «вирьем» – боремся. Делаем защи-ту для мобильников от воров. То есть наша работа – защищать пользовате-лей от компьютерных информацион-ных угроз.

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

Кстати, то, что мы не хотим зарабо-тать все деньги мира, нам очень сильно помогает. Мы не осуществляем прямых продаж, работаем только через парт-неров – наша сеть объединяет уже бо-лее 700 партнеров первого уровня бо-лее чем в 100 странах мира. Мы всегда делимся, и нас за это очень любят.

– Были ли «Лабораторией Кас-перского» зафиксированы случаи продажи поддельных антивирусов от «Лабораторией Касперского»? Какие предпринимались действия?– Да сколько угодно! В Индии и Китае это массовое явление. По экспертным оценкам, около 50% «коробочной» продукции в Китае – контрафакт.

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

– Вы сами когда-нибудь вирусы пи-сали? Если да, то какие?– Меня замучили этим вопросом! Да, я писал их три раза. Первый раз году в 1992-1993-м, когда появился первый конструктор вирусов. У меня тогда была идея написать универсаль-ную «лечилку». Я штук двадцать виру-сов сделал и уничтожил.

Второй случай – объявили кон-курс на самую маленькую программу, которая может делать свои копии. Я ухитрился втиснуться в 13 байт: при запуске эта вирусоподобная прог-рамма под MS-DOS создавала свою копию в файле с именем «5». Если файл переименовать в «5.exe» и сно-ва запустить, создавалась еще одна копия. Естественно, потом я убил эту штуку. Написал на форуме о своих подвигах и очень удивился, когда че-рез год мне прислали точно такую же программу!

А третий случай произошел, когда журналисты меня уже вконец замучи-ли! Я подошел к доске и фломастером написал bat-вирус, после чего сразу стер свои записи. Все! В остальном я чист.

– Если вам надо безопасно передать файл с одного компьютера в Интер-нете на другой, каким способом это сделаете, чтобы ни файл не подме-нили, ни вирус не приписали, ни со-держимое не просмотрели?– Отправлю по корпоративной почте – это гарантия безопасности при усло-вии того, что стандартом является ис-пользование VPN-соединения.

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

– Хорошей практикой у многих антивирусных компаний является выпуск обрезанной версии антиви-русного продукта для персональ-ного (домашнего) использования, где пользователь получает при-емлемый функционал и простые рычаги управления бесплатно или за ежедневный просмотр рекламы более серьезного продукта. Есть ли какие-нибудь задумки у ваших мар-кетологов на этот счет?– Мы думали об этом и пришли к мне-нию, что технически можно сделать все что угодно. Но нужно ли это нам? Дело в том, что самое важное и доро-гое, что есть в антивирусе, – это сис-тема распространения антивирусных обновлений, и именно за нее платит пользователь. Тогда как бесплатные антивирусы выпускают всего один ап-

Уникальная экспедиция лыжниц из восьми стран Содружества наций стартовала 19 ноября 2009 года. Команда прошла 900 км от побережья Антарктиды к Южному полюсу. Новый год на станции «Амундсен-Скотт» лыжницы встречали вместе с Евгением Касперским и журналистами из разных стран мира



дейт в день, чего, конечно, недостаточ-но для полноценной защиты.

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

– KIS 2010 поставляется с лицензи-ей, позволяющей устанавливать его сразу на два компьютера. Но если мне не нужна вторая лицензия, и платить за одну неиспользуемую лицензию не хочется. Как быть?– Никак. Представьте, что продает-ся двухлитровая бутылка минераль-

ной воды, один литр в которой дается в подарок. А я выпил только полови-ну. Что мне делать? Ничего. Так же и в нашем случае: есть вторая лицензия, которая идет в подарок, не хочешь – не используй.

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

– Почему бы в «Антиспаме» не де-лать анализ заголовков писем, что-бы для подозрительных писем ска-чивать только заголовки, не тратя трафик пользователей?– Такой сервис у нас есть. Компонент Анти-Спам, который входит в состав Kaspersky Internet Security 2010, ис-пользует технологию эвристического анализа технических заголовков пись-ма. Анализатор распознает ошибки в технических заголовках, в которых

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

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

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

И это именно не мечта, а план, ко-торый совершенно реализуем. Мы уже являемся многолетним лидером на российском рынке, а также в ряде стран постсоветского пространства. Если взять консьюмерский сегмент, то мы №1 в Германии. Если говорить о ритейле, то мы занимаем первую по-зицию во Франции, Германии, Испании и, по моим личным ощущениям (к сожа-лению, по этой стране пока нет точной статистики), в Китае. В Соединенных Штатах «Лаборатория Касперского» вышла на второе место. По отчетам IDC, в 2009 году мы стали 4-й компани-ей в мире среди производителей соф-та в сфере безопасности по объему выручки.

– Есть страны, где вас нет?– Нет таких стран. Мы везде, где есть Интернет, и даже там, где нет наших прямых партнеров или офисов. До-

пустим, у нас нет партнеров в Ираке. Но и там делают закупки наших про-дуктов.

– Вы называете себя не бизнесме-ном, а лидером. Что отличает лиде-ра от других, как вы считаете?– Бизнесмен занимается постоянным оперативным управлением бизнес-процессов, вникает во все детали, вы-страивает бизнес-процессы, контро-лирует их качество и результаты.

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

Примеров подобного управления бизнесом немного. Я могу назвать, по-жалуй, лишь Ричарда Брэнсона, соз-дателя и владельца корпорации Virgin. Такие лидеры участвуют в жизни ком-пании, но не ежедневно: они указыва-ют направление, в котором нужно бе-жать, и примерную скорость.

Главное здесь – найти правильных людей и четко определить задачи, ко-торыми они будут заниматься. И пусть они исполняют их любым доступным способом. Но без «косяков». По край-ней мере, со мной два раза подряд «косячить» нельзя!

– Вы долго подбирали команду?– Всю свою бизнес-жизнь. И продол-жаю подбирать, потому что правиль-ных людей не так много. При этом я стараюсь разделить ответственность между всеми. Чтобы не просто делали, как начальник сказал, а учились рабо-тать самостоятельно, предлагали свои идеи. Причем самый шик, когда есть интересная задачка, и ты ее препод-носишь таким образом, что сотрудники сами приходят и говорят: «Женя, а да-вай мы это сделаем!»

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

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

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



и в технической поддержке компании. Я многое начинал сам делать, а с го-дами передавал свои функции другим.

Сейчас я в основном занимаюсь пиаром и разработкой стратегии ком-пании. Я гарант бренда: гарантирую, что мы делаем и что мы не делаем.

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

– Расскажите, пожалуйста, об экспе-диции в Антарктику, которую спон-сировала Лаборатория Касперского. Ее цель?– Группа товарищей, которые случай-но оказались женского пола, захотела пробежаться с ветерком в Антаркти-ку. Объединяющий лозунг экспедиции звучал примерно так: за чистоту при-роды и против глобального потепле-ния. Экспедиция также была призвана отметить 60-летие создания Содруже-ства наций – объединения независи-мых государств, в которое входят Ве-ликобритания и почти все ее бывшие доминионы, колонии и протектораты. По этой причине в экспедиции прини-мали участие девушки только из стран, входящих в состав Содружества.

В общем, у девочек лыжи были, а «на ветерок» им не хватало. Одна из них, сингапурская китаянка, наш клиент, позвонила в локальный офис с просьбой о помощи. А разве мож-но отказаться от такой грандиозной затеи? Так мы и стали генеральными спонсорами мероприятия.

В результате эту экспедицию даже признали главным антарктическим со-бытием сезона.

– Что вы пережили сами в этом пу-тешествии?– Улетая оттуда, я понял, что Антар-ктида меня укусила. Я хочу вернуться назад. Там нет запахов и звуков, толь-ко три краски – синяя, белая и чер-ная. Организм очищается полностью. Нет ощущения расстояния: кажется, что до горы рукой подать, а она нахо-дится от базы на расстоянии 20 кило-метров.

День отличается от ночи только тем, что ночью тени длиннее. Постоянно

светло и спать приходится в специаль-ных очках. Фантастическое место!

– Вы когда-то назвали лучшим вло-жением денег издание своей первой книги. В последние годы пишете в основном путевые заметки. Со-бираетесь ли написать что-нибудь, связанное с работой компании?– Да, есть идея написать книгу, причем в сотрудничестве с ключевыми сотруд-никами компании. Книга будет о нашем опыте успешной разработки продук-тов. Заодно дадим практические реко-мендации.

– Что вы больше всего цените в жиз-ни?– Людей, с которыми работаю.

– Что нравится в людях, а что не при-емлете?– Люблю открытых людей. Не люблю – глупых и вороватых.

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

Кроме того, что такое ИТ в бытовом смысле? Это коммуникации и развле-чения. Один из сегментов, от которого человек, жаждущий хлеба и зрелищ, откажется в последнюю очередь.

Я называю наш бизнес одним из пяти элементов, без которых люди, хоть зарежьте их, не обойдутся никак! Вот эти элементы: вода, еда, развлече-ния, коммуникации, безопасность. Ин-тернет – это развлечения, коммуника-ции, а мы занимаемся безопасностью. Поэтому думаю, что развитие ИТ будет только набирать обороты.

Да, продажи компьютеров падают, но посмотрите, как растут продажи но-утбуков! Если у человека сломался ав-томобиль, он пересаживается на трол-лейбус или метро, если же у него сло- мался ноутбук, он покупает новый! EOF

Компьютерный андеграунд 2009‑2010: итоги и перспективыПод таким названием «Лаборатория Кас-

перского» провела недавно большую пресс-

конференцию в Москве. Об итогах и перспек-

тивах рассказывали – Евгений Касперский,

руководитель центра глобальных исследова-

ний и анализа угроз Александр Гостев и ру-

ководитель лаборатории контентной фильтра-

ции Андрей Никишин.

Основные тенденции в сфере угроз – со-

кращение темпов роста вредоносных про-

грамм, изменение направления вектора атак,

усложнение технологий вирусописателей,

повышение уровня глобальных эпидемий,

разнообразие мошеннических схем, рост по-

пулярности псевдоантивирусов.

На первом месте – китайская киберпре-

ступность, на втором – США, на третьем – Гер-

мания, на четвертом – Голландия, на пятом –

Россия.

По числу потенциальных жертв киберпре-

ступников по-прежнему лидирует Китай, сле-

дом за ним идут США, Германия, Великобри-

тания и Россия.

Особо выделялись такие угрозы как

Sinowal (буткит), TDSS и Clampi. Главной эпи-

демией года стал червь Kido.

Больше всего уязвимостей было обна-

ружено в решениях Microsoft, Apple, Adobe

и Sun. Самыми распространенными стали

уязвимости в продукте компании Apple –

QuickTime 7.x.

Что касается мобильных ОС, то для iPhone

были обнаружены первые вредоносные про-

граммы (черви Ike), для Android создана

первая шпионская программа, для Symbian-

смартфонов – зафиксированы первые инци-

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

граммами.

Еще одно событие 2009 года – первая тро-

янская программа Backdoor.Win32.Skimer.

В 2010 году станет больше атак через фай-

лообменные сети.

На рынке ботнет-услуг ожидается появле-

ние серых схем. Основными причинами воз-

никновения эпидемий станут обнаруженные

уязвимости. Если таковых не будет, 2010 год

может оказаться одним из самых спокойных

за последние годы.

Может упасть активность поддельных

антивирусов. В области веб-сервисов темой

года должен стать Google Wave и атаки через

данный сервис.

Для iPhone и Android год ожидается

достаточно сложным. Растущая популяр-

ность телефонов на базе Android в Китае

и слабая технология контроля публикуемых

приложений приведут к новым вирусным ин-

цидентам.


34

Визитка


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

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

Как показано на рис. 1, жесткий диск (или накопитель на жестких магнитных дисках Hard Disk Drive) состоит из па-кета дисков (пластин), которые приводятся в движение шпиндельным двигателем, а также считывающих головок и привода. Пластины являются той составляющей, которая ответственна за хранение информации. Они, как правило, изготавливаются из алюминия, стекла или керамики. Маг-нитный слой, покрывающий последние, является ферромаг-нитным материалом (окиси железа) или более прочным – окиси хрома. Для чтения или записи данных применяются магнитные головки.

Чтобы получить доступ к пространству пластин, его необ-ходимо каким-либо образом адресовать. Тут мы и подходим к такому понятию, как геометрия жесткого диска. Минималь-ная единица адресного пространства – сектор (его размер, как правило, варьируется в зависимости от устройств в та-ких пределах: 512, 1024 и 2048 байт). Для адресации послед-них применяются два способа: CHS (cylinder-head-sector, цилиндр-головка-сектор) и LBA (linear block addressing, ли-нейная адресация блоков).

При использовании CHS адресация осуществляет-ся посредством номеров цилиндра, головки и сектора, т.е. по физическим признакам, а при использовании LBA – числом, которое является абсолютным номером. Кроме

того, возможно преобразование из одного способа адре-сации в другой:

где:c – номер цилиндра,H – количество головок,h – номер выбранной головки,S – количество секторов в одном треке, s – номер сектора.Последнее впервые было определено в проекте стандар-

та ATA-1, представленном еще в 1994 году Американским национальным комитетом по стандартизации и аккредита-ции X3 (American National Standard of Accredited Standards Committee X3) [1].

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

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

Первым физическим сектором на жестком диске явля-ется главная загрузочная запись, или Master Boot Record (MBR). Она содержит таблицу разделов и исполняемый код, который позволяет определить активный раздел и загру-зить из него загрузочную запись. Сектор, имеющий адрес цилиндр 0, головка 0, номер 1, – это Master Boot Sector (MBS, загрузочный сектор). Его содержимое совпадает с MBR.

Следующим шагом развития в данном направлении ста-ло создание формата GUID Partition Table (GPT) для раз-мещения таблицы разделов на жестком диске. Последний определен в стандарте Extensible Firmware Interface (EFI, Расширяемый микропрограммный интерфейс). EFI был предложен как замена BIOS компанией Intel (разработка на-чата в 1998 году), а сейчас EFI курируется Unifed EFI Forum

Можно использовать ПО с графическим интерфей-сом, а можно решать задачи более оптимизирован-но – из командной строки, всегда зная, что проис-ходит «под капотом»

Что «под капотом»?Работа с HDD и файловыми системами из консоли

ИГОРЬ ШТОМПЕЛЬ, инженер, системный администратор. Сфера профессиональных интересов – свободное программное обеспечение

LBA = ((c * H + h) * S) + s — 1

Емкость цилиндра = количество головок * количество секторов на дорожке * количество байт в секторе



или UEFI (создан в 2005 году) [2]. Спецификации последней доступны по адресу http://www.uefi.org/specs.

Итак, GPT – это интерфейс между микропрограммами, оборудованием и операционной системой. При его исполь-зовании, как показано на рис. 3, в начале диска находит-ся MBR (LBA0). Остался на месте в целях совместимости и безопасности – например, чтобы какая-либо утилита, ори-ентированная на работу с MBR, не перезаписала диски с GPT. Следом за ним начинается Оглавление таблицы раз-делов (Partition Table Header) – это и есть начало GPT (LBA1). GPT основан на использовании более современной системы адресации LBA, а MBR – CHS (о данных системах адресации мы говорили выше). За оглавлением GPT следует таблица разделов. Как в начале, так и в конце диска записываются оглавление и таблицы разделов, обеспечивая дублирование.

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

Взаимодействие файловых систем в GNU/Linux невоз-можно без общего интерфейса для них. Ядро (далее будет употребляться термин Linux, а для обозначения операцион-ной системы – GNU/Linux) предоставляет последний. По-этому нет необходимости использовать низкоуровневый интерфейс каждой отдельной системы, достаточно вос-пользоваться системными вызовами (например, такими, как open (), read (), write ()). На практике это может выгля-деть следующим образом: копирование данных с устройст-ва с файловой системой ext2 на устройство с ext3 или пере-мещение.

В роли данного общего интерфейса выступает VFS (Virtual File System, виртуальная файловая система). Это элегант-ное и удобное решение, но в то же время достаточно слож-ное. Как сказал Роберт Лав, один из разработчиков Linux: «…сделать так, чтобы общие системные вызовы работали для всех поддерживаемых файловых систем и физических сред хранения данных, – задача не тривиальная»[3]. Кстати, получить представление, насколько сложен процесс раз-

Работать из консоли или ис-пользовать графический интер-фейс? Вот в чем вопрос

Рисунок 1. Устройство жесткого диска Рисунок 2. Геометрия жесткого диска



работки и поддержки файловой системы на примере ext4, можно из интервью, которое дал Тед Цо (ответственный за подсистему ext4) [4].

Помимо общего интерфейса для работы с системными вызовами, VFS еще и дает общую базу или файловую модель. Последняя состоит из набора структур данных (их также на-зывают объектами, а саму VFS объектно-ориентированной, хотя и реализованной на С.). Можно выделить четыре типа базовых объектов: суперблок (superblock), файловый ин-декс (inode), представление элемента каталога (dentry) и от-крытый файл, связанный с процессом (file).

Суперблок содержит информацию с описанием конкрет-ной файловой системы. Без него не может быть реализова-на ни одна файловая система в контексте VFS. Структура суперблока определена в заголовочном файле linux/fs.h. Файловый индекс хранит информацию из дисковых индек-сов (без нее невозможно работать с файлами и каталогами). Структура файлового индекса также определена в заголо-вочном файле linux/fs.h. Элемент каталога – это определен-ная часть пути (например, /etc/fstab), в роли которой могут выступать обычные файлы (последовательность байтов). Структура файлового индекса также определена в заголо-вочном файле linux/dcache.h. Объект file используется для представления (храниться в оперативной памяти) файлов, которые открыты процессом. Как и структуры суперблока и файлового индекса, структура file определена в заголо-вочном файле linux/fs.h.

Если посмотреть на внутренние структуры ext2/ext3 (мы не будем их описывать, так как Владимир Мешков под-робно описал архитектуру ext2 [5]. Логическая организация ext3 принципиально не отличается от ext2. Основное нов-шество ext3 – поддержка журналирования), то можно уви-деть реализацию файловой модели, о которой мы говорили выше. Лишь еще раз заострю внимание: при использовании ext2 все пространство раздела или жесткого диска делится

на блоки, размер которых кратен размеру сектора – 1024, 2048 или 4096.

Работаем с файловой системойНачнем, пожалуй, с получения статистической информации о файловой системе. Для этого воспользуемся утилитой df, которая входит в пакет GNU Core Utilities (coreutils), вклю-чающий основные утилиты [6]. Итак, командуем:

У меня был отображен вывод, приведенный на рис. 4. У вас вывод может несколько отличаться (например, в зави-симости от количества смонтированных файловых систем).

Итак, утилита отобразила:> файловую систему (например, /dev/sda2);> количество блоков (26004256 или чуть более 25 Гб

(26004256/размер блока));> количество используемых блоков (20674212);> количество свободных блоков (4009100);> количество используемых блоков в процентах (84%);> точку монтирования (/).Чтобы вывод был отображен в так называемом human-

readable формате, надо использовать опцию -h (размер ис-пользуемого и доступного пространства будет отображать-ся в Мб и Гб, а не блоках):

Соответственно, варьируя опции, можно получать раз-личные выводы (-i для отображения информации о фай-ловых индексах (inode), -T добавит в вывод для каждой файловой системы ее тип, -k вместо блоков размер будет отображаться в килобайтах).

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

Если необходимо в каком-либо разделе создать фай-ловую систему, то для этого надо использовать команду mkfs (make a filesystem). Mkfs является оберткой (wrapper) для различных утилит, ориентированных на создание фай-ловых систем. Чтобы получить полный список данных ути-лит, необходимо:

> ввести в консоли команду mkfs;> затем дважды нажать клавишу табуляции.Полученный вывод представлен на рис 5. Как видно,

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

Для создания в разделе /dev/sda1 файловой системы ext3 необходимо дать команду:

Если опция -t не используется, то по умолчанию создается файловая система ext2. Данное форматирование произво-дится следующим образом: создается суперблок (напомню, в файловой модели, о которой мы говорили выше, он содер-жит информацию о данной файловой системе). Оставшееся свободное пространство сразу не форматируется (по мере надобности драйвер файловой системы будет обращаться к блокам жесткого диска, и свободное пространство станет заполняться файлами).

df

df -h

mkfs -t ext3 /dev/sda1

df -- help

Рисунок 3. GUID Partition Table



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

Для создания файловых систем ext2/ext3 можно при-менять команду mke2fs. После того как файловая система в разделе /dev/sda1 создана, необходимо ее смонтировать. Для этих целей воспользуемся командой mount. В общем виде синтаксис команды выглядит следующим образом:

Итак, смонтируем вновь созданную файловую систему:

В данном случае раздел /dev/sda1 с файловой системой ext3 будет смонтирован в каталог /mnt/sda1 (точка монтиро-вания). Кстати, если дать команду mount без параметров, то она осуществит вывод списка всех смонтированных фай-ловых систем.

Процесс отмонтирования данного раздела будет выгля-деть следующим образом:

Если по какой-либо причине раздел не отмонтировался, то можно повторить данную команду с опцией -l:

что позволяет произвести «ленивое» отмонтирование. Как сказано в руководствах (для вывода: man umount), файловая система будет отключена из иерархии файловых систем, а все ссылки на нее будут удаляться в процессе ее освобождения.

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

Рассмотрим внесенные изменения подробнее. Вначале мы указали наименование раздела – /dev/sda1, затем точку монтирования – /mnt/sda1. Потом файловую систему – ext3, опции монтирования – defaults (для ext3 – это rw (чтение/за-пись), suid (разрешены операции с битами suid, sgid), dev (распознавать специальные блочные файлы), exec (разре-шено запускать исполняемые файлы), auto (автоматическое монтирование при загрузке или по команде mount с опци-ей -a для монтирования всех файловых систем, прописан-ных в рассматриваемом конфигурационном файле), nouser (только root сможет смонтировать файловую систему), async (отсутствуют синхронные операции чтения/записи)).

Для создания образов дисков CD и DVD можно исполь-зовать команды: dd и mkisofs. Рассмотрим первую из них. Предположим, что файловая система диска, с которого не-обходимо снять образ, смонтирована в каталог /dev/cdrom. Тогда даем команду:

В данном случае файл с итоговым образом – image.iso бу-дет создан в каталоге /home/user. Но использование dd име-ет свои недостатки – чтение пустых секторов. А значит, если создается образ диска CD, условно 650 Мб, на котором объ-ем информации лишь 100 Мб, то итоговый образ будет иметь размер 650 Мб. Поэтому воспользуемся утилитой mkisofs:

Указанные опции означают:

-R – файловая система RockRidge (для поддержки длин-ных имен файлов);-J – файловая система Joilet (для поддержки длинных имен файлов; потребуется, например, если диск будет воспроизводиться под MS Windows);-input-charset – определяет кодировку, на базе которой файлам давались имена. Как правило, использовать эту опцию не требуется, но иногда необходимо;-o – указывает файл, в который будет записан образ диска. Несколько слов о том, как смонтировать получившийся

образ. Чтобы смонтировать получившийся образ (image.iso) в каталог /mnt/cdrom, даем команду:

Как видно, единственным отличием от указанных выше способов монтирования файловых систем является исполь-зование опции -o loop. Она позволяет использовать файл как блочное устройство (псевдоустройство).

Дополнительной опцией работы с файловыми система-ми из консоли является возможность создания RAM-диска. Для этого воспользуемся уже знакомой командой mkfs.

Для начала выведем список зарезервированных уст-ройств RAM (виртуальная файловая система, призванная ускорить работу с временными файлами):

В моей системе (Trisquel GNU/Linux 3.0) по умолчанию создано 16 дисков RAM, которые не используются. Отфор-матируем один из них. Для этого даем команду:

Будет использоваться виртуальное устройство /dev/ram1. Последняя цифра означает, что выделяется 64 Мб из опера-тивной памяти.

/dev/sda1 /mnt/sda1 ext3 defaults 1 1

dd if=/dev/cdrom of=/home/user/image.iso

mount -t iso9660 -o loop /home/user/image.iso /mnt/cdrom

mount -t ext3 /dev/sda1 /mnt/sda1

umount /dev/sda1

umount -l /dev/sda1

mount -t [опции] [-t тип файлововой системы] ↵ [-o опции монтирования] устройство точка_монтирования

mkisofs -R -J -input-charset utf8 ↵ -o /home/user/image.iso /dev/cdrom

ls -l /dev/ram*

mkfs -t ext3 /dev/ram1 65536

Рисунок 4. Вывод команды df Рисунок 5. Вывод списка утилит оболочки mkfs



После форматирования необходимо подключить данный виртуальный диск. Для этого сначала создадим точку монти-рования, а затем примонтируем RAM-диск:

Подробнее о создании RAM-диска можно прочитать в со-ответствующих источниках [7].

Для настроек файловых систем семейства ext использу-ется утилита tune2fs. Замечу, что ряд операций с использо-ванием данной утилиты стоит осуществлять только на от-монтированном разделе.

Программа tune2fs позволяет делать следующее:> настройка проверки диска после определенного ряда

операций монтирования (например, при загрузке);> добавление файла журнала и настройка его парамет-

ров (можно использовать для перевода ext2 в ext3);> изменение зарезервированного за суперпользовате-

лем дискового пространства;> получение информации из суперблока;> изменение метки файловой системы.Приведем примеры использования tune2fs. Например,

необходимо получить информацию из суперблока (как по-казано на рис. 6). Для этого командуем:

Кстати, для вывода данных о файловой системе из су-перблока можно использовать также следующую команду:

Далее убираем 5-процентное резервирование диско-вого пространства для суперпользователя, создающееся при форматировании в ext3:

Добавим файл журнала и тем самым превратим ext2 в ext3:

Кстати, доступно три режима журналирования для ext3:Writeback – журнал записывается информация об из-менении файловой системы (метаданные). Целостность данных не гарантируется.Оrdered – похож на предыдущий режим, за исключени-ем того, что гарантируется: «запись данных в файл осу-ществляется до записи информации об его изменении». Целостность данных также не гарантируется.Journal – полное журналирование (метаданные и пользо-вательские данные). Целостность данных гарантируется при хранении журнала на отдельном разделе/диске [8].Задать режим журналирования можно либо командой:

либо в /ect/fstab.Дополнительную информацию можно получить в стра-

ницах руководств команды mount, в разделе FILESYSTEM SPECIFIC MOUNT OPTIONS.

Для выявления ошибок и по возможности их исправления применяется команда fsck (размещает все обнаруженные поврежденные данные в каталог /lost+found). Эта команда также является своеобразной оболочкой для других утилит. Если вы проделаете те же операции, что и для команды mkfs (при выводе списка утилит – см. выше), заменив mkfs на fsck, то увидите список всех утилит (fsck.ext2, fsck.ext3 и т.д.).

Приведем несколько примеров использования fsck. Ука-жем, что при проверке необходимо исправлять ошибки ав-томатически:

или запрашивать подтверждение на исправление ошибок:

Добавив опцию -С, мы получим вывод индикатора с про-центами выполнения проверки.

Осуществить сканирование всех файловых систем из /etc/fstab за один раз можно так:

С помощью утилиты debugfs из набора e2fsprogs можно осуществлять отладку файловой системы (ext2, ext3 и ext4). Инструмент предоставляет прямой доступ к структурам дан-ных файловой системы (помните, мы говорили выше о фай-ловой модели) и «является интерактивным интерфейсом к библиотеке EXT2fs, то есть транслирует набранные коман-ды в вызовы функций библиотеки» [9].

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

tune2fs -l /dev/sda1

fsck -A

dumpe2fs /dev/sda1

tune2fs -m 0 /dev/sda1

fsck -a /dev/sda1

tune2fs -j /dev/sda1

fsck -r /dev/sda1

mkdir -p /mount/ramdisk && mount /dev/ram1 ↵ /mount/ramdisk -o defaults,rw

mount /dev/sda1 /mnt/sda1 -t ext3 -o [data=writeback ↵ / data=ordered / journal]

debugfs /dev/sda1 help

Рисунок 6. Вывод информации, хранящейся в суперблоке

Рисунок 7. debugfs по умолчанию работает в режиме read-only



Как показано на рис. 7, по умолчанию debugfs взаимо-действует с файловой системой в режиме read-only. Чтобы получить доступ и для записи, необходимо запускать про-грамму с опцией -w.

В качестве еще одного примера использования debugfs получим вывод статистической информации:

В заключение рассмотрим программу Linux Disk Editor, которая является редактором файловых систем (поддержи-ваются ext2fs, minix и xiafs, а также имеется минимальная поддержка FAT) и позволяет просматривать и редактиро-вать блоки диска в шестнадцатеричном или ASCII-режимах. Программа имеет интерфейс, основанный на ncurses. Пер-воначально редактор был написан для восстановления уда-ленных файлов.

В моем дистрибутиве он оказался доступен из репозито-риев (размер ~429 Кб).

Для установки надо скомандовать:

а после установки для запуска:

LDE сам попытается определить тип файловой системы. Далее нажимаем любую клавишу и, как показано на рис. 8, увидим отображение суперблока. Если необходимо ра-ботать в режиме Inode, то нажимаем клавишу <I>, а если в блочном режиме – клавишу <B>.

Для навигации в данных режимах используются клавиши <PgUp> и <PgDn>.

Для режима Inode – это переход к следующей/предыду-щей inode, а для блочного режима – к следующему/предыду-щему экрану. Кроме того, в любом из режимов при нажатии клавиши <F2> выводится меню (пример вывода меню при-веден на рис. 9). Оно позволяет переключиться из одного режима в другой. Просмотреть отдельный блок или inode, на которых находится курсор. Переключиться в режим вос-становления.

На этом завершим рассмотрение работы с файловыми системами ext2/ext3 из консоли.

Работаем с разделамиРассмотрение работы с жестким диском из консоли начнем с создания на нем разделов. Для этого воспользуемся ути-литой fdisk. Для запуска программы необходимо указать ей, на каком устройстве мы хотим произвести изменения:

Будет выведено приглашение для ввода команд fdisk, а если вы впервые используете эту программу, то обратите внимание, что в приглашении предусмотрительно указано: «m для справки». Воспользуемся этой командой – вывод представлен на рис. 10.

Отобразить список разделов позволит команда p. Создадим раздел с использованием fdisk. Для того что-

бы создать новый раздел, необходимо дать команду n. Программа предложит выбор – создать расширенный раз-дел (e extended) или первичный (p primary partition (1-4)). Для создания первичного раздела нажимаем клавишу p. За-тем программа предложит выбрать номер первичного раз-дела: Partition number (1-4). Нажав клавишу, мы создадим раздел с номер один, и т.д. Далее надо будет ввести первый цилиндр, с которого начнется раздел: First cylinder (1-6373, default 1). Значение по умолчанию нас вполне устроит, вы-берем его. Программа вывела сообщение: Using default value 1 (используется значение по умолчанию 1). Далее необходимо выбрать последний цилиндр раздела или ука-зать его размер в цилиндрах, Кб, Мб или Гб – Last cylinder, or +cylinders or +size{K,M,G} (1-6373, default 6373):. Исполь-зуем значение по умолчанию. Все, новый раздел создан.

Теперь о том, как изменить тип файловой системы на вновь созданном разделе. Для этого даем fdisk команду t. Если на жестком диске несколько разделов, то програм-ма предложит выбрать номер раздела, а если один, то он будет выбран автоматически. Кроме того, будет выведено сообщение: Hex code (type L list codes). На этом шаге не-обходимо либо ввести код файловой системы, либо нажать клавишу <L> для просмотра списка кодов. Определитесь с кодом и введите его.

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

fdisk /dev/sda

apt-get install lde

lde /dev/sda2

debugfs stats

Рисунок 8. LDE отображает суперблок Рисунок 9. LDE в блочном режиме с открытым меню



Для проверки таблицы разделов используется команда v. Для занесения изменений в последнюю надо дать команду w, которая осуществит выход с записью изменений. Если надо выйти из программы без их записи – q.

Бывают ситуации, когда необходимо произвести перена-значение раздела подкачки (например, приобретен новый жесткий диск, на котором теперь и будет размещен раз-дел подкачки). Создать swap-раздел можно будет и в fdisk (код 82), а вот подключить – нет. Для этого сначала преоб-разуем требуемый раздел в раздел подкачки:

Добавление опции -с позволит произвести проверку раз-дела на наличие поврежденных блоков (бэд-блоков). Кстати, проверку разделов жесткого диска на наличие бэд-блоков можно осуществлять с использованием утилиты badblocks:

Итак, раздел подкачки создан. Теперь подключим его:

Кроме того, с помощью swapon можно вывести информа-цию обо всех используемых swap-устройствах (кстати, в вы-вод попадет и устройство подкачки для RAM-диска, который мы создали ранее – /dev/ramzswap0).

Если надо, чтобы раздел подкачки использовался при пе-резагрузке автоматически, добавьте в файл /etc/fstab (со-держит описания устройств, которые автоматически монти-руются при загрузке) следующее:

Для отключения раздела подкачки даем команду:

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

го диска применяется команда du. Если скомандовать ее без параметров, то начнется вывод в «столбик» всех фай-лов и их размеров из домашнего каталога. Это не очень удобно, разве что перенаправить вывод в какой-либо файл:

Команда du обладает опциями, которые могут значитель-но облегчить жизнь администратора. Для начала осуще-ствим вывод в формате human-readable:

Размер файлов стал отображаться в Кб, Мб и Гб. Далее делаем вывод только размера каталога (напомню, по умол-чанию действия совершаются над домашним каталогом):

Теперь используем du для получения информации о про-извольном каталоге, например /var:

Далее получаем информацию только о его размере:

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

Работать с параметрами жесткого диска (SATA/ATA) удоб-но с программой hdparm. Она позволяет:

> устанавливать объем резервируемых данных при опе-рациях чтения записи:

> осуществлять вывод геометрии жесткого диска:

> выводить идентификационные параметры жесткого диска:

> выводить информацию о температуре жесткого диска:

> производить тестирование производительности:

И многое другое. Для вывода всех возможностей дайте команду hdparm без параметров.

1. http://www.t13.org/Documents/UploadedDocuments/project/d0791r4c-ATA-1.pdf.

2. http://www.intel.com/technology/efi; http://www.uefi.org/home.3. Лав Р. Разработка ядра Linux, 2-е издание. М. : ООО «И.Д. Виль-

ямс», 2006. С. 266.4. Супер-Тед//LinuxFormat, 11, 2009. С. 26-27.5. Мешков В. Архитектура файловой системы ext2. //Ситемный ад-

министратор, №11, 2003 г. – С. 26-32.6. http://www.gnu.org/software/coreutils/manual/coreutils.html#Disk-

usage.7. http://wiki.linuxformat.ru/index.php/LXF98: Спецрепортаж; http://

www.vanemery.com/Linux/Ramdisk/ramdisk.html.8. http://www.ibm.com/developerworks/linux/library/l-fs8.html.9. http://lib.ru/LINUXGUIDE/user_guide_lars.txt_Piece40.05.

fsck -r /dev/sda1

badblocks /dev/sda1

/dev/sda5 none swap sw 0 0

du -h /var

swapon /dev/sda5

hdparm -a 1024 /dev/sda

hdparm -g /dev/sda

hdparm -i /dev/sda

hdparm -H /dev/sda

# Тайминги чтения с устройства и кэша устройстваhdparm -Tt /dev/sda

swapoff /dev/sda5

du -h -- summarize /var

du > inf_hd.txt

du -h

du -h -- summarize

EOF

Рисунок 10. Вывод fdisk справки по командам



Визитка

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

Множество подобных вопросов возникло с выходом Windows Server 2008 R2, и о последней из вышеуказанных тем я бы и хотел поговорить. Какие роли сервера большин-ство системных администраторов назовут основными? Я поч-ти уверен, что это будут AD, DNS и DHCP – основа инфра-структуры сети любого большого предприятия. И раз уж мы заговорили о Windows Server 2008 R2, то давайте рассмот-рим вариант, когда ваш менеджер принял решение обно-вить текущие серверные ОС на новое решение от Microsoft, а вы решили начать именно с переноса основных ролей.

Преимущества миграцииКакие же варианты перехода на новую ОС существуют? Это чистая установка, локальное обновление и миграция. В каких случаях процесс миграции является более предпо-чтительным выбором?

> Различия в оборудовании не позволяют выполнить обновление. В силу того, что операционная сис-тема Windows Server 2008 R2 поддерживает толь-ко архитектуру x64, версии Windows Server 2003 и Windows Server 2008 на базе архитектуры x86 не мо-гут быть обновлены до Windows Server 2008 R2.

> Microsoft также рекомендует «выполнять миграцию вместо обновления, даже если вы используете обору-дование на основе архитектуры x64. Например, в слу-чае разделения ролей сервера, когда исходный сервер имеет несколько ролей и нагрузка на него возрастает, может быть принято решение о разделении этих ро-лей между несколькими дополнительными серверами на базе архитектуры х64. В этом случае лучшим реше-нием будет перенос (а не обновление) отдельных ро-лей сервера на другие серверы.

> Упала производительность старого сервера и возник-ла необходимость сохранить текущие, а также удалить устаревшие настройки и параметры конфигурации.

> Нужно перенести устаревшие производственные сер-веры в виртуальную среду.

> Необходимость перейти от полного варианта установ-ки к Server Core.

> Сократить время простоя в ходе переноса ролей.

Nota Bene!Процесс подготовки к миграции состоит из ряда важных мо-ментов.

Создание резервных копий! Я уверен, что системные администраторы понимают, насколько важен и прин-ципиален данный шаг. Microsoft создала все условия для того, чтобы миграция прошла без проблем, но «приз-раков в машине» еще никто не отменял.Нужно позаботиться о клиентах сети. Естественно, цель процесса миграции в том, чтобы конечный сер-вер начал выполнять те же функции, что и исходный; при этом клиентские компьютеры в сети не должны стол-кнуться с нарушением порядка обслуживания. Однако нужно осознавать, что если сервер у вас единственный, то сбоев в обслуживании не избежать. Особенно это ка-сается миграции роли DHCP. Microsoft в этом случае рекомендует создать на период миграции standalone-сервер, который будет выполнять обслуживание клиен-тов. В среде, где для клиентских компьютеров настроен только один DNS-сервер, также рекомендуется создание одного или нескольких дополнительных DNS-серверов, чтобы обеспечить возможность разрешения имен клиен-тами во время выполнения миграции основного исходно-го сервера.Настоятельно рекомендуется продумать сценарий миграции, учитывающий все особые обстоятельства, конфигурации и топологии, которые могут оказать влияние на процесс миграции. При выполнении ми-грации DNS-сервера следует определить метод рас-пределения доменных служб Active Directory в домене.

Миграция ролей AD, DNS и DHCP с ОС Windows Server 2003 занимает мало времени. Попробуйте

Миграция без проблемЕще раз о Windows Server 2008 R2

НИКИТА ПАНОВ, работает в корпорации Microsoft техническим инженером, модерирует русскоязычный сектор портала TechNet, является лидером MCP-

клуба в Воронеже. Любит преподавать и взаимодействовать с аудиторией



Например, будет ли миграция DNS-сервера выполнять-ся с того же компьютера, что и в случае с сервером до-менных служб Active Directory? Миграцию DNS-сервера можно выполнить отдельно от сервера доменных служб Active Directory, однако в большинстве случаев роли сер-вера размещаются на одном и том же компьютере, поэто-му их миграцию требуется выполнять совместно и одно-временно. Также продумайте исход миграции: останется старый сервер в рабочем состоянии в качестве вспомо-гательного или будет выведен из эксплуатации – от этого тоже зависит сценарий миграции.Определитесь со временем, ведь продолжитель-ность процесса миграции зависит не только от дли-тельности выполняемых шагов, но и от исходного со-стояния серверов. Устаревший «софт» и оборудование (например, сетевое), «замусоренность» и фрагментация жесткого диска, старые и ненужные настройки – все это может значительно замедлить процесс.Теперь давайте рассмотрим важные моменты миграции

каждой роли.

AD и DNSСначала выясним, позволяет ли операционная система ва-шего исходного сервера выполнить миграцию.

Поддерживаемые операционные системы для проведения миграцииПриведу таблицу. Обращаю ваше внимание на необходи-мость наличия пакета обновлений SP2 для Windows Server 2003. Были случаи, когда админы жаловались на то, что ми-грация у них не инициируется. Как оказалось впоследствии, именно по причине отсутствия пакета SP2.

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

Аппаратные требования для контроллера домена на базе Windows Server 2008 R2Уверен, что системные администраторы, которые ежеднев-но имеют дело с серверными ОС, представляют либо зна-ют наверняка аппаратные требования для контроллеров домена.

Несмотря на новизну, Windows Server 2008 R2 не так уж «прожорлива» до ресурсов. Например, требование к сво-бодному пространству на жестком диске в основном зави-сит от базы AD и в среднем вычисляется по формуле 0,4 Гб свободного места на каждую тысячу пользователей плюс 1,5 Гб для журналов AD и папки SYSVOL. Как вы понимаете, дорогие читатели, даже в самом аховом случае 500 Гб будет вполне достаточно. Вряд ли кому-то придет в голову уста-навливать на сервер маленький жесткий диск. Что касается оперативной памяти, то здесь нужно исходить из принципов разумности. При тестировании в нашей виртуальной лабо-ратории контроллер домена прекрасно работал и с 1 Гб RAM, но у нас не было большой инфраструктуры, поэтому берите, что называется, с запасом. 4 Гб должно хватить с лихвой, если, конечно, не предполагается использовать этот сервер с дополнительными ролями, кроме AD и DNS.

Сегодня стандартом «де-факто» в скорости переда-чи данных является, конечно же, 1 Гб/сек. Я понимаю, что в России масса достаточно древних серверов с медлен-ными сетевыми адаптерами. Но ведь мы производим мигра-цию на новое оборудование, верно? Нужно учитывать то, что нагрузка на этот сервер может со временем возрасти. Тогда давайте продолжим наш процесс и перейдем к сле-дующему этапу.

Подготовка к миграции> Проверьте наличие всех критических обновлений

на исходном и конечном сервере, если какие-то из них отсутствуют, то крайне рекомендуется их уста-новить.

> Установите средства миграции Windows Server на ис-ходном и конечном серверах. Это не очень сложно, но тем не менее ответственно. Для начала необхо-димо установить на исходный сервер платформу .NET Framework 2.0 и Windows PowerShell 1.0 или более позднюю версию. Оба инструмента вы сможете найти на странице загрузок Microsoft. Затем на конечном сер-вере через оснастку Features установите компонент Windows Server Migration Tools.

> Создайте папку развертывания на конечном серве-ре. Она необходима для переноса инструментария миграции на исходный сервер. Для этого на конеч-ном сервере надо выполните команду (для Windows Server 2003 x64):

где deployment_folder_ path – путь к папке, в которой будут находиться инструменты развертывания. Это мо-жет быть и сетевой путь на исходный сервер. Либо ко-манду:

если исходная ОС Windows Server 2003 x86.> Нужно зарегистрировать средства развертывания

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

Поддерживаемые операционные системы для проведения миграции

Процессор

исходного

сервера

Операционная система

исходного сервера

Операционная

система целе-

вого сервера

Процессор

целевого

сервера

На базе

архитек-

туры x86

или x64

Windows Server 2003 с па-

кетом обновления 2 (SP2)

Windows Server

2008 R2, полная

установка

и установка

Server Core

На базе

архитекту-

ры x64

Windows Server 2003 R2

Windows Server 2008, пол-

ная установка и установка

Server Core

На базе

архитекту-

ры x64

Windows Server 2008 R2

Установка Windows Server

2008 R2 в варианте Server

Core

SmigDeploy.exe /package /architecture amd64 /os WS03 ↵ /path <deployment_folder_ path>

SmigDeploy.exe /package /architecture X86 /os WS03 ↵ /path <deployment_folder_path>



и содержит необходимые инструменты. Перейдите к ней и запустите файл smigdeploy.exe с правами ад-министратора (!!!). Это запустит процесс регистрации инструментов миграции. Теперь они будут доступны на исходном сервере в «Пуск → Выполнить → Ад-министрирование → Средства миграции Windows Server».

> Убедитесь в исправной работе исходного сервера с ролями AD и DNS. Для этого выполните на нем ко-манду:

> Убедитесь в том, что записи Active Directory, необходи-мые для проведения репликации, зарегистрированы корректно. Выполните команду:

> Если dnslint вернет сообщение о неполадках в конфи-гурации DNS, то воспользуйтесь статьей «Устранение неполадок репликации Active Directory» из базы знаний TechNet – http://support.microsoft.com/?kbid=824449.

> Проверьте, чтобы количество сетевых адаптеров на ис-ходном и конечном серверах было одинаковым. Это необходимо в случае, когда один сервер обслуживает несколько подсетей.

> Заранее определите, каким образом будет заполнять-ся база данных AD на конечном сервере: путем ре-пликации содержимого каталога другого контроллера домена по сети или с помощью метода установки с но-сителя (IFM), при котором используется копия каталога на переносном носителе. При копировании больших каталогов метод установки с носителя позволяет зна-чительно сэкономить время.

> Загрузите сценарий проверки схождения, который будет полезен при проведении миграции с целью про-верки синхронизации записей DNS – http://go.microsoft. com/fwlink/?LinkId=135502.

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

> Создайте резервную копию AD или DNS исходного сервера.

> Используйте «лист сбора данных для проведения ми-грации» на исходном сервере для сохранения всей не-обходимой информации (http://technet.microsoft.com/ ru-ru/library/dd379556(WS.10).aspx).

> Установите конечному серверу временное имя и IP-ад-рес и проверьте, что данный сервер является членом вашего текущего домена.

> Если вы планируете сохранить исходный сервер в ка-честве дополнительного контроллера домена, то опре-делите, какие роли FSMO будут переданы новому сер-веру, а какие останутся на исходном.

Если все выполнено, то можете смело приступать к ми-грации ролей AD и DNS.

К сожалению, в рамках одной статьи невозможно описать все подробности проведения миграции, поэтому подробно изучить все этапы самой миграции вы можете, изучив «Ру-ководство по миграции ролей AD и DNS» в библиотеке зна-ний TechNet (http://go.microsoft.com/fwlink/?LinkId=134771)

или в более удобном варианте веб-каста на портале TechDays.ru (http://www.techdays.ru/videos/1491.html).

DHCPКонечно, миграция роли DHCP проще, чем AD и DNS, но так-же требует предварительной подготовки и внимательного отношения.

Требования к ОС при миграции DHCP такие же, как и при миграции ролей активного каталога и DNS. Кстати, в обоих случаях в качестве исходных или целевых серве-ров поддерживаются следующие версии Windows Server: Foundation, Standard, Enterprise и Datacenter.

Также похож и процесс подготовки серверов, за исклю-чением специфичных именно для AD- и DNS-пунктов.

Подготовка к миграции> Установите последние обновления на исходный и ко-

нечный серверы.> Установите средства миграции Windows Server.> Проверьте количество сетевых адаптеров на исходном

и конечном серверах – оно должно быть одинаковым.> Создайте общую папку, доступную обоим серверам,

для переноса файлов миграции.> Добавьте конечный сервер в домен и проверьте, что-

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

> Если после миграции роли DHCP планируется вывод сервера из эксплуатации, то IP-адреса исходного и ко-нечного сервера(ов?) можно сделать одинаковыми, в противном случае на период миграции конечному серверу нужно выдать свободный IP-адрес.

> На исходном сервере необходимо сделать резервное копирование DHCP, используя команду netsh:

Теперь вы готовы к проведению миграции. Детальный процесс очень подробно описан в «Руководстве по мигра-ции роли DHCP» в базе знаний TechNet (http://go.microsoft. com/fwlink/?LinkId=134770), а еще есть полноценный веб-каст, в котором все этапы показаны детально (http://www. techdays.ru/videos/1578.html).

Очень часто нас спрашивают: «Сколько времени зани-мает процесс миграции?» Как вы понимаете, это зависит от множества факторов: уровня сетевого оборудования и аппаратных средств сервера, работоспособности исход-ного сервера, уровней фрагментации жесткого диска, под-готовки администратора… Но в идеале миграция каждой роли занимает 2-3 часа плюс время, необходимое на тести-рование/подготовку исходного сервера.

***Не нужно бояться проведения подобной миграции. Если вы сделали необходимые резервные копии, провели все необ-ходимые тесты и внимательно изучили руководства, то мо-жете быть уверены: у вас все получится.

dcdiag /test:dns /s:<source_server>

dnslint /ad /s <source server IP address> /v

netsh dhcp server export C:\<имя_файла.txt> all

EOF


44

Визитка


В первой части статьи [1] мы подробно обсудили установку Windows Deployment Service и создание основных видов об-разов. Можно сказать, что это лишь половина работы, са-мое интересное нас ждет впереди, ведь нам еще потребует-ся выполнить массу действий по дополнительной настройке образов. В частности, мы развернем образ с помощью PXE и установим необходимую операционную систему. Затем создадим образ обнаружения и произведем ряд дополни-тельных настроек.

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

Перед началом развертывания первого установочного образа нужно проверить свойства сервера WDS и опции области действия сервера DHCP. Для этого сделайте сле-дующее:

1. С помощью консоли WDS откройте свойства сервера WDS и выберите вкладку Advanced, чтобы проверить, отме-чены ли флажки Authorize This Windows Deployment Service in DHCP (авторизовать службу WDS в DHCP) и Allow the Windows Deployment Services to Dinamically Discover Valid Domain Controllers (разрешить службе Windows Deployment Services динамически обнаруживать действительные кон-троллеры доменов) (см. рис. 1).

2. Используя консоль WDS, откройте свойства сервера WDS и выберите вкладку PXE Response Setting (настройка отклика PXE).

Далее убедитесь, отмечен ли переключатель Respond to All (Known and Unknown) Client Computers (отвечать всем (известным и иеизвестным) клиентским компьютерам). При этом не нужно отмечать опции Notify Administrator (уве-домлять администратора) и Respond After Approval (отвечать после одобрения). Позднее, при более тонкой настройке, вы сможете самостоятельно включить данные опции, одна-ко сейчас их лучше не включать.

3. Наконец, третье подготовительное действие. Исполь-зуя консоль DHСP в Windows Server 2008, убедитесь, что до-менное имя DNS и опции DHCP сервера DNS содержат под-ходящие значения для среды вашей организации. Проще говоря, нужно убедиться в том, что настроено верно.

Разворачиваем образВыполнив предварительные настройки, можем перейти к процессу формирования образа. В нашем первом при-мере мы будем разворачивать образ с помощью загрузки PXE. В качестве образа, который разворачиваем, будет ис-пользоваться образ, созданный в первой части статьи [1]. Для развертывания выполним следующие действия.

> В процессе загрузки системы войдите в BIOS. Про-верьте, чтобы сетевая загрузка PXE была разрешена для основного сетевого адаптера и что в списке прио-ритета загрузка по сети PXE указана перед системным жестким диском (см. рис. 2).

> Сохраните настройки и выйдите из BIOS, чтобы запу-стить последовательность загрузки системы.

> Когда в процессе загрузки вам будет предложено на-жать клавишу <F12> для загрузки по сети, нажмите ее для того, чтобы запустить процесс создания образа WDS.

> Если система может соединиться с сервером WDS пос-ле вывода подсказки Press F12 for Network Boot и нажа-тия клавиши <F12>, то загрузочный образ будет загру-жен с сервера WDS с использованием сервера TFTP, встроенного в него, и начнется процесс создания об-раза.

> После того как система завершит загрузку фай-лов Windows, начнется выполнение среды Windows Preinstallation Environment. Страница должна иметь имя Windows Deployment Services.

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

> На экране откроется окно аутентификации. Введите имя пользователя и домен учетной записи, используе-мой для установки WDS, а также пароль, и щелкните кнопку ОК.

> На странице установки Install Windows будет перечис-лен каждый установочный образ, загруженный на сер-вер WDS. Выберите необходимую операционную сис-тему и нажмите Next.

При развертывании операционных систем может возникнуть необходимость в дополнительных на-стройках. Рассмотрим, какие средства предлага-ет WDS

WDS поможетУстановка операционных систем. Часть 2

АНДРЕЙ БИРЮКОВ, специалист по информационной безопасности. Работает в крупном системном интеграторе. Занимается внедрением решений по защите корпоративных ресурсов



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

> После выполнения этих действий будет создан и от-форматирован том диска, начнется процесс установки операционной системы посредством развертывания и копирования необходимых файлов и установки опера-ционной системы со стандартными настройками.

> Далее начнется настройка непосредственно Windows. На странице Set Up Windows необходимо будет выпол-нить стандартные действия, которые обычно выпол-няете при установке Windows: указать часовой пояс, ввести лицензионный ключ, настроить автоматическую активацию.

> Процесс установки завершится автоматическим при-соединением к домену.

Итак, мы рассмотрели процесс установки образа WDS по умолчанию. Однако настроек по умолчанию, как прави-ло, недостаточно.

Создание образов обнаруженияВ тех случаях, когда загрузка PXE не поддерживается в сис-теме или в сети, может возникнуть необходимость использо-вать загрузочный носитель, для того чтобы начать процесс клонирования образа WDS. Это можно сделать с помощью образа обнаружения WDS. Данный образ создается из су-ществующего загрузочного, содержащего Windows PE, и клиента WDS, который может храниться на переносимом носителе, облегчая развертывание в старых системах, где могут возникнуть проблемы с PXE. Для создания образа об-наружения выполните следующие действия.

> Откройте консоль WDS.> Укажите локальный сервер и добавьте его в консоль.> В панели с древовидным представлением разверните

ветвь WDS и выберите узел Boot Images.

> В панели инструментов найдите и щелкните правой кнопкой мыши на требуемом образе загрузки и вы-берите в контекстном меню пункт Create Discover Boot Image (создать загрузочный образ обнаружения).

> На странице Discover Image Metadata введите имя и описание нового загрузочного образа обнаружения. В разделе Location and File Name перейдите к папке в локальной системе, в которой можно создать новый загрузочный образ обнаружения, введите имя образа обнаружения и щелкните на кнопке Open.

> Введите полностью определенное доменное имя сер-вера WDS, с которым будет соединяться образ обнару-жения после загрузки в среде Windows PE и загрузки клиента WDS. Щелкните Next, чтобы создать образ об-наружения.

> Когда образ обнаружения будет создан, щелкните Finish. Все, образ обнаружения успешно создан. Однако преж-

де чем его можно будет использовать для загрузки систе-мы и соединения с сервером WDS, необходимо произвести определенные действия. Чтобы создать загружаемый CD- или DVD-диск, который будет использовать новый загрузоч-ный образ обнаружения, потребуются средства из набора Windows Automated Installation Kit. Скачать данный набор можно по адресу [2]. Набор Windows Automated Installation Kit (WAIK) используется главным образом для того, чтобы по-мочь производителям OEM-компьютеров и развертывания операционных систем семейства Windows на новом обору-довании. Он содержит средства развертывания, совмести-мые с последней версией Windows.

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

> После того как WAIK будет инсталлирован, скопи-руйте созданный ранее образ обнаружения в папку на локальном диске. Например, e:\DiscoverImages\ Win2008Discover.WIM.

> Далее перейдите в каталог c:\Program Files\Windows AIK\Tools\PETools\.

> Затем необходимо сделать копию среды Windows Preinstallation Environment с помощью команды:

Рисунок 1. Авторизация сервера WDS в DHCP Рисунок 2. Настройки BIOS



> Теперь у нас имеются файлы WinPE, необходимые для загрузки системы. А нам нужно скопировать об-раз обнаружения в требуемую папку. Это можно сде-лать с помощью следующей команды, которая копиру-ет созданный файл загрузки обнаружения и заменяет файл boot.wim, находящийся в установочной папке WinPE:

> Итак, у нас готова инсталляция WinPE для создания за-грузочного образа ISO, включающего наш специаль-ный образ обнаружения. Введем следующую команду:

> В результате выполнения предыдущей команды мы по-лучаем ISO-образ. Вам достаточно будет просто раз-вернуть этот образ на компакт диск.

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

Чтобы предварительно созданные учетные записи компьютеров можно было связать с системами, потре-буется уникальный идентификатор (GUID), связанный с сетевым адаптером системы. В большинстве систем GUID-идентификатор будет отображаться во время после-довательности загрузки PXE.

После того как GUID-идентификатор будет получен и за-фиксирован, можно создать учетную запись компьютера Active Directory. Учетную запись необходимо создать до того, как будет создан образ системы с использованием WDS. Чтобы создать учетную запись компьютера Active Directory, которая будет использоваться для WDS, выполните следую-щие действия.

> Осуществите вход на сервер WDS под учетной записью администратора.

> Если средства Remote Server Administration для роли Active Directory Domain Services не были установлены на сервере WDS, то это необходимо сделать сейчас.

> Затем откройте консоль администрирования Active Directory Users And Computers.

> Разверните домен и выберите контейнер, в который сервер WDS будет помещать новые учетные записи компьютеров, как это определено на вкладке Directory Services страницы WDS Properties. По умолчанию все новые учетные записи помещаются в контейнер Computers.

> Щелкните правой кнопкой мыши на контейнере Computers и выберите в контекстном меню пункт New → Computer.

> Когда откроется окно New Object – Computer, введи-те требуемое имя новой учетной записи компьютера в поле Computer Name и нажмите Next.

> На странице Managed отметьте флажок This Is a Managed Computer (это управляемый компьютер).

> После того как будет отмечен флажок, введите ранее зарегистрированный GUID-идентификатор, связанный с сетевой платой в системе, и щелкните Next. Обратите внимание на то, что в поле GUID-идентификатора вво-дить тире не нужно.

> Следующей является страница Host Server, на кото-рой задается определенный сервер WDS, который предоставит образы для этого хоста. Здесь необхо-

copy /y E:\DiscoverImages\Win2008Discover.WIM ↵ E:\DiscoverImages\WinPE\ISO\Sources\Boot.wim

oscdimg –n –b E:\DiscoverImages\WinPE\ISO\Boot\ ↵ etfsboot.com E:\DiscoverImages\WinPE\ISO ↵ E:\DiscoverImages\MyDiscoverImage.ISO

CopyPe x86 e:\DiscoverImages\Winpe

Рисунок 3. Мастер создания образа захвата Рисунок 4. Процесс создания образа захвата



димо или указать сервер WDS, или оставить вариант по умолчанию, чтобы любой сервер WDS мог предо-ставить образ этому клиенту; щелкните на кнопке Next.

> Проверьте настройки и нажмите кнопку Finish.> После того как будет создана учетная запись компью-

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

Создаем специальные образыЕсли установочные образы по умолчанию, включенные в Windows Vista и Windows 2008, не удовлетворяют тре-бованиям данной организации к развертыванию, можно употребить специальные образы посредством создания загрузочных образов захвата и подготовки системы с ис-пользованием утилиты sysprep.exe. Чтобы создать новый образ захвата, выполните следующие действия.

> Откройте консоль WDS. В панели с древовидным пред-ставлением выберите и разверните сервер WDS.

> Выберите узел Boot Images. В панели задач щелкните правой кнопкой мыши на требуемом загрузочном обра-зе и выберите в контекстном меню пункт Create Capture Boot Image (Создать загрузочный образ захвата).

> На странице Capture Image Metadata введите имя и опи-сание нового загрузочного образа захвата. В разделе Location and File Name перейдите в папку в локальной системе, в которой можно создать новый загрузочный образ захвата, и щелкните на кнопке Open, чтобы вер-нуться на страницу Capture Image Metadata. Щелкните Next для продолжения (см. рис. 3).

> Когда загрузочный образ захвата будет создан, щел-кните по кнопке Finish, чтобы закрыть окно и вернуться в консоль WDS.

> В панели с древовидным представлением выберите узел Boot Images, щелкните на нем правой кнопкой мыши и выберите команду Add Boot Image.

> На странице Image File щелкните на кнопке Browse, найдите и выделите только что созданный файл загру-зочного образа захвата и щелкните на кнопке Open. Вернитесь на страницу Image File и щелкните на кнопке Next.

> На странице Image Metadata измените имя, чтобы оно отражало образ захвата, щелкните Next.

> Просмотрите настройки на странице Summary и щел-кните на кнопке Next.

> По завершении нажмите Finish (см. рис. 4).Обычно, когда организация принимает решение ис-

пользовать продукт для создания образов серверов и или настольных компьютеров, основные усилия должны быть направлены на упрощение развертывания систем. Если развертываются только базовые операционные системы с помощью WDS, то сэкономленное время будет очень не-значительным, а если этот процесс займет несколько ча-сов инсталляции программного обеспечения операционной системы и специальных настроек, то создание и развер-тывание специальных образов может быть очень кстати. Чтобы создать образ предварительно сконфигурированной операционной системы Windows 2008 и Windows Vista, по-требуется выполнить следующие действия.

> Разверните образ в системе с помощью установочного и загрузочного образа, используемого по умолчанию, с сервера WDS.

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

> Запустите утилиту Sysprep.exe из папки c:\windows\system32\sysprep. В окне System Preparation Tool выбе-рите опцию Enter System Out-of-Box Experince (OOBE) (введите параметры операционной системы) в меню System Cleanup Action (действие по очистке системы). Выберите опцию Shutdown в меню Shutdown Options и щелкните ОК. После этого система будет выключена.

> На сервере WDS создайте загрузочный образ захвата и добавьте загрузочный образ в список образов WDS.

> Загрузите систему, которая была подготовлена для создания образа, с помощью загрузки PXE. Когда будут представлены доступные образы, выберите ра-нее созданный образ захвата.

> Выберите образ захвата, когда диспетчер Windows Boot Manager отобразит список образов.

> Когда будет отображено окно мастера Windows Deployment Image Capture Wizard (мастер захвата об-раза развертывания Windows), щелкните на кнопке Next для продолжения.

> В выпадающем меню на странице Image Capture Source выберите том, который будет захвачен, введите имя и описание для нового установочного образа и щел-кните Next.

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

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

> Загрузите систему с помощью PXE в загрузочный об-раз WDS и выберите новый установочный образ, чтобы протестировать развертывание данного образа.

> При необходимости снова настройте образ и выполни-те повторный захват.

Также вам может понадобиться дополнительная настрой-ка захваченных установочных образов с помощью диспет-чера System Image Manager, который входит в состав набо-ра средств Windows Automated Installation Kit.

***Итак, мы научились разворачивать образы с помощью Windows Deployment Service. Надеюсь, что с помощью дан-ного средства вы сможете существенно автоматизировать и облегчить развертывание операционных систем на рабо-чие станции.

1. Бирюков А. WDS поможет. Установка операционных систем. Часть 2. //«Системный администратор», №12, 2009 г. – С. 50-55.

2. Дистрибутив Windows Automated Installation Kit для Windows Vista SP1 и Windows Server 2008 – http://www.microsoft.com/ downloads/en/confirmation.aspx?familyId=94bb6e34-d890-4932-81a5-5b50c657de08&displayLang=en.

EOF


48

Визитка


Чтобы вручную произвести изменения в нескольких конфи-гурационных файлах на серверах, выполняющих разную роль, придется потратить немало времени. Как минимум потребуется проанализировать имеющиеся установки, вы-брать системы, на которых будут производиться перестрой-ки, подготовить новые конфигурационные файлы или вы-брать другие средства для изменения настроек серверов. И чем больше количество и разнообразнее системы, находя-щиеся в подчинении администратора, тем более значитель-ных усилий потребует перестройка всей сети, тем больше вероятность сделать ошибку. Использование единой точки, в которой были бы собраны все настройки, позволило бы сократить время на активацию новых установок и снизило вероятность ошибки. В журнале уже обсуждались возмож-ности системы централизованного управления Puppet [1]. Это достаточно новый проект, его основные идеи были взяты Cfengine [2], который имеет аналогичное назначение. О Cfengine и пойдет речь далее.

О CfengineПроект Cfengine анонсирован в 1993 году, его разработкой занимается в основном один человек – профессор Норвеж-ского университета (Осло) Марк Бюргес (Mark Burgess). В основе построения Cfengine лежит «Теория обязательств» (Promise Theory), адаптированная Марком Бюргесом приме-нительно к области автоматизации и управления. Основная идея Promise Theory состоит в добровольном взаимодей-ствии автономных агентов между собой. При этом особое внимание уделяется стабильному состоянию системы, а не перестройкам. Система дает обещание, что она пра-вильно настроена и проверяет это состояние. Изменения вносятся только в случае, если обещания, то есть указания на перестройку, не выполнены. В итоге при внесении каких- либо изменений вся сеть через некоторое время приходит к единому состоянию.

Предоставляя достаточно большие возможности, Cfengine тем не менее так и не стал популярен среди си-стемных администраторов, несмотря на то что за время существования проекта код был загружен более миллиона

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

Исходный код доступен и распространяется под лицензи-ей GNU GPL, но все изменения и пожелания весьма жестко контролировались Марком Бюргесом. Вероятно поэтому, Cfengine ранее называли проектом одного человека. Се-годня ситуация несколько изменилась, в том числе создана и коммерческая версия продукта. Правила можно предста-вить как язык программирования очень высокого уровня, на изучение которого в любом случае придется потратить некоторое время. Большие возможности сделали систему относительно сложной в изучении, язык при этом выглядел достаточно запутанным. Это главные причины малой попу-лярности веток 1 и 2.

В апреле 2009 года была представлена 3-я (Сommunity edition) версия Cfengine, лицензируемая под GPL v3. Беглого взгляда на документацию достаточно, чтобы понять, что пе-ред нами существенно переработанный продукт, который даже позиционируется несколько по-иному, как фреймворк. Здесь уже используется новый язык описания с более чет-ким и простым синтаксисом, поддержкой классов и шабло-нов функций. Добавлены новые функции отчетов, поддерж-ка управления знаниями и виртуализации, более тесной интеграции с другими программными продуктами. Однажды созданная конфигурация легко читаема, и соответственно в нее просто внести изменения. Возможно использование в одной сети систем Cfengine 2 и 3, что упрощает переход на новую ветку.

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

В дальнейшем речь пойдет именно об Cfengine 3. В се-редине 2008 года образована Cfengine AS, которая зани-мается распространением коммерческой версии Cfengine Nova, построенной на тех же принципах, что и Cfengine 3,

Трудно управлять большим количеством систем без средств автоматизации. Этот проект облегчит задачу и позволит централизовано устанавливать параметры

Проект одного человекаЦентрализованное управление при помощи Cfengine

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и четырех книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС



но более удобной в развертывании, управлении и генера-ции отчетов.

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

Главные требования к Cfengine – работа в большой сети с изменяющейся конфигурацией и высокая безопасность. Приложение способно работать практически в любой ге-терогенной среде, с любым количеством компьютеров, в том числе при использовании низкоскоростных каналов, и в мобильных агентах, редко подключающихся к сети. Написан Cfengine на языке С. Поддерживаются Windows (cygwin), Linux, Mac OS X, Solaris, AIX, HPUX и прочие UNIX-системы.

При помощи Cfengine можно автоматизировать:> создание, изменение и удаление файлов и символиче-

ских ссылок;> изменение конфигурационных файлов в соответствии

с правилами;> проверку и настройку сетевых интерфейсов;> проверку и установку прав доступа к файлам и катало-

гам;> монтирование файловых систем;> контроль над изменением файлов при помощи MD5-

суммы;> откат несанкционированных изменений;> запуск скриптов и команд, контроль над выполнением;> управление и контроль над работой сервисов (демо-

нов);> дублирование системных настроек – при замене сер-

вера нужные настройки будут произведены автомати-чески;

> изменение реестра Windows и зон Solaris.Основная идея Cfengine – создание единого набора

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

Типичная инфраструктура может состоять из трех компо-нентов:

Policy Definition Point – не обязательная, но очень же-лательная часть системы, построенная на системе кон-троля версия вроде CVS, позволяющая отслеживать все изменения в настройках;Distribution point – один или несколько серверов, ко-торые распространяют файлы политики, описанные в promises.cf и расположенные в каталоге /var/cfengine/ masterfiles;конечные узлы – на которых применяются политики, скопированные из Distribution point в каталог /var/cfengine/ inputs.

После получения политик в конечной точке извлекаются и применяются только те настройки, которые имеют отно-шение к текущему узлу.

Установка Cfengine 3 в UbuntuВ репозитарии текущей LTS-версии Ubuntu 8.04 доступ-на только вторая версия Cfengine. Третья имеется лишь в Ubuntu 10.4 (Lucid Lynx), который также планируется к выпуску с приставкой LTS (Long Term Support). Поэтому установка последнего релиза возможна лишь из исходных текстов. В качестве зависимостей указаны библиотеки OpenSSL, libc6, база данных BerkeleyDB, компилятор и опци-онально PCRE (Perl Compatible Regular Expression). В боль-шинстве случаев все необходимое в системе есть.

При наличии библиотек OpenLDAP, MySQL, PostgreSQL будут доступны дополнительные возможности, хотя Cfengine cможет работать и без них.

Скачиваем исходные тексты Cfengine 3:

Распаковываем архив и компилируем стандартным обра-зом (./configure; make; make install).

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

После установки в каталоге /usr/local/sbin появится не-сколько исполняемых файлов:

cf-agent – клиентская часть, агент, непосредственно вы-полняющий конфигурирование системы, именно он осу-ществляет модификацию, перезапуск сервисов, выпол-няет сценарии и прочие настройки;cf-serverd –серверная часть, коорая обеспечивает аген-там совместное использование любых файлов, в том чис-ле и конфигурационных, и получает запросы на выполне-ние текущей политики;cf-execd – планирует выполнение заданий, обеспечива-ет сбор результата и отправку сообщения на системную учетную запись, может служить заменой cron;cf-key – создает открытые и частные ключи, используе-мые утилитами cf-agent и cf-serverd для опознавания друг друга;cf-know – агент, позволяющий построить карту семанти-ческой сети обмена знаниями по стандарту ISO;cf-monitord – агент мониторинга, контролирующий теку-щее состояние системы (процессы, сетевые соединения, использование ресурсов и т.д.), также анализирует из-менения на предмет аномальности;cf-promices – проверка набора конфигурации перед ее применением;cf-report – создание отчетов в различных форматах;

$ sudo apt-get install libdb4.6 libdb4.6-dev libssl0.9.8 ↵ libc6 libpcre3 bison flex

$ wget –с http://www.cfengine.org/tarballs/ ↵ cfengine-3.0.2.tar.gz

$ mkdir cfengine $ cd cfengine$ svn checkout https://svn.iu.hio.no/projects/ ↵ cfengine-3/trunk



cf-runagent – вспомогательная программа, при помощи которой можно потребовать от cf-serverd выполнения cf-agent с существующей политикой. Может применяться для имитации изменений на клиентских системах и при-нудительного применения политик.В Cfengine 2 названия исполняемых файлов отличались. Для своей работы различные компоненты Cfengine ис-

пользуют подкаталоги в /var/cfengine или ~/.cfagent (при за-пуске под учетной записью, отличной от root). Причем не-которые пути в /var/cfengine жестко вшиты в исходный код. Это сделано для повышения безопасности, поэтому при по-пытке вынести отдельные файлы или настройки за пределы /var/cfengine утилит из его состава не могут их найти.

Файлы, расположенные в /var/cfengine/masterfiles, со-держат политики и используются в Distribution point, в /var/ cfengine/inputs на клиентских системах хранятся получен-ные с Distribution point файлы, которые будут считываться при запуске, в /var/cfengine/outputs – отчеты об изменени-ях и текущем состоянии. Все каталоги, за исключением masterfiles, будут созданы автоматически при запуске про-граммы клиента.

После установки шаблоны политик находятся в катало-ге /usr/local/share/doc/cfengine. Их можно использовать при ознакомлении с принципами работы. Создаем на Distribution point нужный каталог и копируем в него шаблоны:

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

Далее необходимо создать ключи сервера:

После запуска утилиты в /var/cfengine будет создано еще несколько подкаталогов, ключи будут сохранены в /var/ cfengine/ppkeys.

По умолчанию имя начинается с localhost, но, используя дополнительные параметры (их можно узнать при помощи -help), можно указать другое название файла и каталог, но это не всегда желательно. Кроме политик, в inputs долж-ны находиться три обязательных файла:

promises.cf – основной конфигурационный файл, агент и сервер будут считывать его при запуске;update.cf – файл, определяющий настройки обновлений, получаемых агентами;failsafe.cf – файл, считываемый сервером и агентом в том случае, когда другие настройки недоступны или не-правильны. С его помощью агент может восстановить на-стройки.Если таких файлов не будет найдено, получим сообще-

ния вроде:

Кроме этого, возможно использование отдельных фай-лов для настройки каждого компонента или вспомогатель-

ных целей. Имена можно задавать произвольно, но обыч-но выбирают более описательные: cf-server.cf, cf-execd.cf, cfbackup.cf и так далее. Но чтобы их задействовать, они должны быть описаны в файле promises.cf в секции inputs в body common control. Как это сделать, будет показано далее.

Заготовки основных файлов уже есть, копируем:

Теперь, после изменений в файлах политики, можно за-пускать агента для приведения их в действие.

По умолчанию cf-agent ищет настройки в текущем ка-талоге, inputs и /home/user/.cfagent. Здесь есть несколько особенностей. Если для удобства создать символическую ссылку в каталог /etc, например /var/cfengine/inputs -> /etc/ cfengine, то после запуска cf-agent она будет переименова-на в inputs.cf-moved -> /etc/cfengine, а каталог inputs будет создан вновь и, естественно, без конфигурационных фай-лов внутри.

Кроме этого, агент требует, чтобы исполняемый файл cf-promises был установлен в домашний каталог /var/ cfengine/bin:

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

Проверяем:

И устраняем:

Текущая версия Cfengine 3.0.2 почему-то разрешает ис-пользование такой символической ссылки, выходящей за пределы /var/cfengine:

Но такое поведение несвойственно Cfengine, ранее символическая ссылка не работала, поэтому файл лучше именно копировать. После первого запуска агента в ката-лог /var/cfengine/bin или ~/.cfagent/bin будут скопированы и все остальные исполняемые файлы, входящие в комплект Cfengine. Кроме этого, здесь образуются символические ссылки для запуска named-checkzone и утилит из комплекта dnssec-tools (если такие есть в системе).

Теперь можно попробовать загрузить (восстановить) кон-фигурацию Cfengine из failsafe.cf.

Эта команда считает все файлы с расширением .cf в те-кущем каталоге и переместит их в inputs. Кроме этого, в /var/ cfengine будут созданы файлы журналов (выполненных опе-раций), базы с классами, аудита, системными настройками и т.п.

$ sudo mkdir -p /var/cfengine/masterfiles$ sudo cp /usr/local/share/doc/cfengine/*.cf ↵ /var/cfengine/masterfiles

$ sudo /usr/local/sbin/cf-key

localhost.priv localhost.pub

cf-promises: /usr/local/sbin/cf-promises

Can't stat file "/var/cfengine/inputs/failsafe.cf" for parsing

$ sudo ls /var/cfengine/ppkeys/

$ whereis cf-promises

$ sudo cp /usr/local/sbin/cf-promises /var/cfengine/bin

$ sudo ln -s /usr/local/sbin/cf-promises /var/cfengine/bin

$ sudo /usr/local/share/doc/cfengine/inputs/*.cf ↵ /var/cfengine/inputs

$ cd /var/cfengine/masterfiles$ sudo /usr/local/sbin/cf-agent --bootstrap

cf-promises needs to be installed in /var/cfengine/bin for pre-validation of full configuration



Чтобы продвигаться дальше, необходимо разобраться с правилами и обязательствами.

Описание политикВ терминологии Cfengine все указания называются обяза-тельствами или обещаниями (англ. promises), что полностью соответствует используемой теории, но чтобы не путать, я буду использовать более привычные компьютерные – по-литика и правила, чем они, собственно, и являются. В от-личие от предыдущей версии механизм описания правил переработан. Сейчас политики стали более структуриро-ванными и могут содержать правило (promises), коллек-цию правил (promise bundles), которые также группируют-ся в большую единицу – promise body. Также присутствуют и остальные атрибуты – классы, функции, циклы, массивы, переменные и данные. Те, кто изучал язык Perl, найдут в го-товых правилах много знакомого.

Собственно, правила в Cfengine могут состоять из четы-рех компонентов – типа, класса, объекта (promiser) и атри-бутов:

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

Поле «тип» указывает на вид операции, то есть что необ-ходимо сделать. В зависимости от типа системы может быть использован один из следующих классов:

в любом правиле – vars (переменная), classes (класс, по-казывающий состояние системы), reports (отчет);только в агентах – commands (выполнение команды), databases (настройка базы данных), files (создание и на-полнение файла, установка атрибутов), interfaces (нас-тройка сетевых интерфейсов), packages (установка па-кета), storage (проверка подключенного диска), methods (обработка других правил);относятся к остальным компонентам – access (доступ к объектам в cf-serverd), measurements (выбор данных для отчета или мониторинга, в Cfengine Nova), roles (раз-решение активации отдельных классов при удаленном запуске cf-agent через cf-serverd), topics (ассоциация с именем при запуске cf-know) и occurrences (обращение к ресурсу в cf-know).Поле «класс» описывает группу объектов, к которым от-

носятся правила. Во многих встроенных правилах это поле отсутствует, что соответствует значению any, то есть любой. Здесь могут стоять имя ОС (linux, solaris, ubuntu, debian …), имя или IP-адрес узла, название интерфейса, зона Solaris, учетная запись или группа, время (год, день, час, минута, цикл и т.п.). Просмотреть список классов на текущем узле можно при помощи команды:

Список классов также доступен в файле allclasses.txt, расположенном в каталоге /var/cfengine/state. Кроме встро-енных (hard) классов, различают и пользовательские (soft) классы. Классы с типом common являются глобальными, любые другие – локальные. При вызове класса можно ис-пользовать круглые скобки для группировки и операторы сравнения (!, & (или точка «.»), | (или ||)). В итоге достаточно легко задать практически любое условие выполнения, кото-рое к тому же хорошо читается.

Например:

Такая запись класса задает условие: Ubuntu 8.04, 2010 год, ночь в понедельник или пятницу, 5-я минута часа. Имя файла можно задать как полностью, включая путь (на-пример, /etc/passwd), так и использовать регулярное выра-жение.

Для примера возьмем один из файлов шаблона unit_helloworld.cf, копируем его в inputs.

Смотрим, что внутри:

Перед применением необходимо проверить политику на отсутствие синтаксических ошибок, для этого запускаем cf-promises. Чтобы получить большую информацию по рабо-те утилиты, используем дополнительно ключи -r (создание отчета) и -d (отладочный режим). В обычном режиме они не нужны, здесь лучше использовать ключ -v:

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

type: class::"promiser" -> { "promisee1", "promisee2", ... } attribute_1 => value_1,…attribute_2 => value_n.

$ cat unit_helloworld.cf

# Объявляем глобальный набор классов control body common control{bundlesequence => { "hello" }; # Определение класса}

# Локальная коллекция hello, ориентированная на агентовbundle agent hello{reports: # Тип отчеты

linux:: # Класс linux

"Hello world!"; # Выводимые данные}

cf-promises: /usr/local/sbin/cf-promises

cf3 -> Defined hard classes = { any verbose_mode Wednesday Hr02 Night Min07 Min05_10 Q1 Hr02_Q1 Day16 December Yr2009 Lcycle_2 GMT_Hr23 linux ubuntu undefined_domain 32_bit linux_2_6_24_19_server i686 linux_i686 linux_

$ whereis cf-promises

# cf-promises -v

ubuntu_hardy&Yr2010&(Monday| Friday)&Night&Min05

NewClass(ipv4_192)NewScalar(sys,ipv4[eth0],192.168.17.156) AddVariableHash(sys.ipv4[eth0]=192.168.17.156 (string) rtype=s)Searching for scope context sysAdded Variable ipv4[eth0] at hash address 1834 in scope sys

$ sudo cf-promises –d 3 –r –f /var/cfengines/inputs/ ↵ unit_helloworld.cf

i686_2_6_24_19_server linux_i686_2_6_24_19_server__1_ SMP_Wed_Jun_18_15_18_00_UTC_2008 compiled_on_linux_gnu virtual net_iface_lo net_iface_eth0 ipv4_192_168_17_156 ipv4_192_168_17 ipv4_192_168 ipv4_192 fe80__20c_29ff_fed7_ a8e1 cfengine_3_0_2 cfengine_3_0 cfengine_3 debian lsb_compliant ubuntu_hardy ubuntu_8_4 ubuntu_8 common }



Далее идет проверка каталогов, доступа и так далее. Если все правильно, последней строкой будет идти:

По окончании работы в текущем каталоге появятся два файла (txt и html) с отчетом.

Если ошибок нет, запускаем политику на выполнение. Ре-зультат увидим в консоли, кроме этого, будет создан журнал (в моем случае /var/cfengine/c3.ubuntu.runlog).

Конечно, это самый простой пример, вполне достаточ-ный, чтобы понять структуру правил. При наличии большого количества параметров их объединяют в списки или масси-вы. Например, список сервисов: Теперь к нему можно об-ратиться, указав в правиле $(service).

Описание рабочих систем может занимать много места и содержать не один десяток правил. Часто одни правила зависят от результата выполнения других, чтобы не воз-лагать на администратора задачу по их согласованию, все объявления обрабатываются циклически, до их выполнения. Кроме этого, если Cfengine изменяет файл, он создает его резервную копию с префиксом – cf-before-edit.

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

Настройка сервераСервер cf-serverd при запуске по умолчанию считывает файлы site.cf, promises.cf, update.cf, library.cf, шаблоны ко-торых мы скопировали из /usr/local/share/doc/cfengine/inputs.

Разберем некоторые настройки из promises.cf. Вначале настраивается периодичность работы агента:

В правиле body monitor control настраиваются параметры работы системы мониторинга. Чуть ниже, в body executor control, настраивается запуск агента. Здесь необходимо указать адрес электронной почты, на который будут прихо-дить сообщения, и SMTP-сервер:

По умолчанию сервер принимает подключения только с localhost, чтобы удаленные клиенты могли подключаться, необходимо отредактировать правило body server control, указав в Allowconnects и/или Allowallconnects IP-адреса или доменные имена, соединения с которых будут прини-маться.

Теперь при запуске сервер будет принимать подключе-ния агентов, прослушивая 5308 порт. Проверяем:

Кстати, если отследить процессы, то мы увидим, что за-пуск сервера cf-serverd приведет к автоматическому старту сf-monitor и cf-agent.

Но удаленные клиенты еще не смогут подключаться к серверу. Для обеспечения безопасности в Cfengine ис-пользуется механизм защиты и обмена ключами, подобный OpenSSH. При этом нет необходимости вручную копиро-вать открытый ключ на сервер (это делается автоматиче-ски при первом подключении), такая децентрализованная структура более устойчива к сбоям всякого рода.

По умолчанию только ключи локальной системы являют-ся доверенными. Поэтому при попытке удаленного соедине-ния получим ответ:

Чтобы разрешить прием ключа, необходимо перечислить IP-адреса удаленных систем в параметре Trustkeysfrom:

body agent control {# Минимальное время (в минутах) перед проверкой, # наличие новых правилifelapsed => "15";# Expireafter – максимальное время ожидания завершения # перестроек, по умолчанию 120 минут}

body server control {Allowconnects => { "127.0.0.1" , "::1", ↵ "192.168.17.100" , "192.168.1.0/24" }; Allowallconnects => { "127.0.0.1" , "::1", ↵ "192.168.17.100" , "192.168.1.0/24" }; # Слушать только на определенном интерфейсеbindtointerface => "192.168.17.1";Trustkeysfrom => { "127.0.0.1" , "::1" ... }; }

"service" slist => { "ssh", "apache", "mysql" };

with value (omitted)NewScalar(sys,ipv4_3[eth0],192.168.17) AddVariableHash(sys.ipv4_3[eth0]=192.168.17 (string) rtype=s)…NewClass(lsb_compliant)cf_popen(/usr/bin/lsb_release --id) cf_pclose(pp)cf_pwait - Waiting for process 27979 NewClass(ubuntu)cf_popen(/usr/bin/lsb_release --codename) cf_pclose(pp)cf_pwait - Waiting for process 27982 NewClass(ubuntu_hardy)

cf3 Inputs are valid

mailto => "[email protected]"; smtpserver => "localhost";

tcp6 0 0 :::5308 :::* LISTEN

Not authorized to trust the server=192.168.17.1's public key (trustkey=false)

$ cf-serverd -v$ netstat -an | grep 5308

Trustkeysfrom => { "127.0.0.1" , "::1", ↵ "192.168.17.100" …. };

Подготавливаем систему к сборке



Дополнительно производится проверка соответствия DNS-имени IP-адресу. Ее можно отключить, использовав параметр skipverify, что не рекомендуется с точки зрения безопасности, но для локальных сетей такой проверкой можно пренебречь.

Теперь первый ключ, отправленный клиентом, автома-тически принимается, попытка передать следующий ключ будет заблокирована. Хотя в целях безопасности, вероят-но, все же лучше копировать открытые ключи вручную. Имя файла открытого ключа необходимо изменить, чтобы оно указывало на учетную запись и IP-адрес системы, к которой она относится. Например, user-192.168.17.200.pub.

После того как подключение к серверу организовано, не-обходимо разрешить узлам и пользователям доступ к фай-лам. Это делается при помощи правила access в файле site.cf. Например, чтобы разрешить пользователю root дос-туп ко всем файлам сервера со всех адресов, за исключе-нием 192.168.17.200, создаем такое правило:

Теперь, используя masterfiles, мы можем автоматически распространять на клиентские системы не только политики, но и обновления, и прочие файлы.

Следует учитывать, что по умолчанию привязка идет к /var/ cfengine и доступ к корню сервера невозможен. То есть ис-пользовать в предыдущем правиле («/») нельзя. Если же та-кая необходимость все же есть, то следует пропатчить файл server.c, прописав в 1923 линии код, разрешающий доступ к корню файловой системы сервера:

Следующее правило в promises.cf позволяет указать cf runagent и cf-agent, где ему искать сервер Distribution point:

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

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

Для периодического запуска cf-agent вместо cron пред-лагается использовать специальный демон cf-execd. В этом

случае мы получаем возможность управлять режимом за-пуска централизованно, при помощи политик, и отправлять отчеты на электронный адрес.

Для управления запуском cf-execd создадим файл cf-execd.cf такого содержания:

Теперь, чтобы файл был «виден», объявим его в promices.cf в секции inputs:

Вообще можно вместо создания cf-execd.cf все пара-метры вписать сразу в promises.cf, но при наличии боль-шого количества записей читаемость от этого ухудшается. При запуске cf-agent будет загружен и cf-execd, который пе-риодически будет выполнять cf-agent.

***Теперь можно полностью контролировать подчиненные сис-темы, распространяя изменения, устанавливая обновления, производя мониторинг и получая отчеты.

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

1. Яремчук С. Централизованная настройка UNIX-систем с помо-щью Puppet. //Системный администратор, №7, 2007 г. – С. 58-61.

2. Сайт Cfengine и Open Source-сообщества Cfengine – http://www.cfengine.com, http://www.cfengine.org.

3. Wiki Cfengine – http://www.cfwiki.org.4. Cfengine на SourceForge – http://cfengine.sourceforge.net.5. Страница Cfengine в проекте GNU – http://www.gnu.org/software/

cfengine.6. Архив рассылки сообщений об ошибках – http://www.mail-

archive.com/[email protected]/info.html.7. Cfengine reference manual – http://www.cfengine.org/manuals/cf3-

reference.html.

cf3 Host localhost/::ffff:127.0.0.1 was found in the list of hosts to trust

skipverify => { "192.168.17.*" };

bundle server access_rules() { access:"/var/cfengine/masterfiles"deny => { "192.168.17.200" }; admit => { "192.168.17.*" }; roles: ".*" authorize => { "root" }; }

body executor control {

# Задержка запуска cf-agent, может потребоваться # для завершения копирования файлов политикsplaytime => "1";mailto => "[email protected]"; smtpserver => "localhost"; mailmaxlines => "100";schedule => { "Min00_05" }; # Собственно расписание# Журналирование в syslogexecutorfacility => { "LOG_DAEMON" };

}

# Команда запуска

bundle agent executor {processes: "cf-execf" "cf-execf" restart_class => "start_cfexecd"; commands: start_cfexecd:: "/usr/local/sbin/cf-execd"; }

/* Exact match means single file to admit */

if (strcmp(ap->path,"/") == 0 ) { res=true; }

body common control { inputs => { "update.cf", "site.cf", "library.cf" , "cf-execd.cf" # Добавили };}

body runagent control {hosts => { "127.0.0.1", "example.com:5308", …. };

}

EOF


54

Визитка


Когда системный администратор начинает работать в круп-ной сети на базе Active Directory Domain Services (ADDS), его одной из важнейших забот становится репликация Active Directory. Даже если учесть, что этот механизм полностью автоматизирован и при правильной изначальной конфи-гурации редко требует вмешательства, не стоит забывать о таких реалиях жизни, как выключения света, медленные и нестабильные каналы, ошибки администраторов и просто внештатная работа службы, вызванная вспышками на Солн-це или лунным затмением. Как раз для борьбы с вышепере-численными недугами и необходимо понимание механизмов репликации, а также способов управления ею.

База данных Active DirectoryВпервые появившись в Windows Server 2000, технология Active Directory (это прежде всего транзакционная база данных, содержащая информацию об объектах вашей сети, глубоко интегрированная с системой безопасности Windows) более чем за девять лет претерпела некоторые из-менения. Но даже в Windows Server 2008 R2 работает на хо-рошо зарекомендовавшем себя движке Extensible Storage Engine (ESE). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с нескольки-ми миллионами объектов, а вырасти база может до 16 те-рабайт. Сердцем Active Directory является файл NTDS.DIT, в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров до-мена происходит создание копии данного файла и разме-щение ее на введенном в строй новом контроллере. Можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT.

Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть «Active Directory Поль-зователи и Компьютеры» или, как вариант, «Active Directory

Сайты и Сервисы», вы всегда подключаетесь к конкретному контроллеру домена. И при желании можете выбрать, с ка-ким контроллером работать. Это означает, что вы работаете с конкретной версией базы данных, которая в настоящий момент может отличаться от других копий. Естественно, соз-давая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS.DIT, который находит-ся на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры о них и новых данных и как можно скорее произвести синхрони-зацию. В Active Directory этот процесс синхронизации на-зывается репликацией, в дальнейшем будет использован именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигура-ции AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT.

Физически NTDS.DIT – это просто один файл, но логиче-ски он состоит из нескольких разделов (иногда их называ-ют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему.

Раздел Schema хранит в себе схему Active Directory, ко-торая описывает, какие объекты могут быть созданы и что они собой будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операци-онную систему либо при установке в организации почто-вой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы, и это не случайно, т.к. отменить данные изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный

Одна из главных рекомендаций Microsoft касательно ADDS – необходимость развертывания в производственной среде не менее двух контроллеров домена. Однако их может быть гораздо больше

Разговор на «ты»Репликация Active Directory

ИЛЬЯ РУДЬ, сертифицированный тренер Microsoft, специализируется на технологии Active Directory, один из основателей ресурса itband.ru

КОНСТАНТИН ЛЕОНТЬЕВ, архитектор подразделения консалтинга Microsoft Services в России, занимается технологиями Core Infrastructure. Обладатель высшей сертификации Microsoft Certified Architect и Microsoft Certified Master по специализации Windows Server 2008 Directory



раздел, чья репликация не является мультимастерной. Ре-пликация раздела Schema всегда односторонняя и выпол-няется от контроллера домена, владеющего ролью FSMO «Хозяин Схемы», на все оставшиеся контроллеры домена (см. рис. 1). (Впоследствии оставшиеся контроллеры до-мена реплицируют информацию своим репликационным партнерам, но источником этой цепочки репликации всегда будет «Хозяин схемы».)

Раздел Configuration – содержит информацию о конфи-гурации Active Directory. Он описывает, какие и сколько доменов создано, как они между собой связаны, сколько существует сайтов, какие сервисы доступны в организации и просто системные настройки службы каталогов, такие как квоты, политики LDAP-запросов, правила неточного поиска, разрешения имен объектов. Раздел реплицируется между всеми контроллерами доменов в лесу, может быть изменен на любом контроллере домена. Изменения данного раз-дела связаны с конфигурированием и настройкой самой ActiveDirectory.

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

Разделы Application – опциональные разделы. Зона ре-пликации зависит от настройки. Как правило, создается два Application-раздела, это ForestDNSZones и DomainDNSZones.

ForestDNSZones – хранит SRV и CNAME записи для леса AD и реплицируется на все контроллеры домена в лесу, являющиеся DNS-серверами.DomainDNSZones – содержит DNS-записи для зоны до-мена. Реплицируется на все контроллеры домена с уста-новленным на них DNS-сервером.Посмотреть на каждый раздел каталога и данные, в нем

хранящиеся, можно через утилиты ADSI Edit AdExplorer и LDP.exe (см. рис. 2). Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на кон-троллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и пос-ле выхода Windows Server 2008.

Теперь важно уяснить следующее: когда клиент аутенти-фицируется на контроллере домена и применяются группо-вые политики, образуется трафик (85 Кб на вход станции в домен – с DefaultDomainPolicy и 75 Кб на вход пользова-теля – тоже с DefaultDomainPolicy). Более того, репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять. Представьте себе, что организация и, естественно, ваш до-мен Active Directory располагается в двух городах, связан-ных WAN-каналом. Однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, рас-положенному в центральном московском офисе. А контрол-леры домена начнут реплицировать информацию в любое время и по первому требованию. Минимум с чем вам при-дется столкнуться – это высокая утилизация WAN-канала

Рисунок 1. Разделы базы Active Directory Рисунок 2. Выбор раздела для подключения в утилите LDP.exe

Рисунок 3. Свойства репликационной связи Рисунок 4. Принцип создания связей репликации службой KCC



и медленный вход пользователей в домен. Поэтому в Active Directory введено понятие сайтов.

Репликация в рамках одного сайта Active DirectoryСайт – это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространя-ется за пределы одного сегмента локальной сети, следова-тельно, вы работаете с односайтовой структурой. Именно она является дефолтной, именно с нее мы начнем разговор.

При создании Active Directory и поднятии (подразуме-вается процедура dcpromo) первого контроллера домена формируется сайт по умолчанию с именем Default-First-Site-Namе. Если не создавать дополнительных сайтов и придер-живаться односайтовой структуры, все новые контроллеры будут попадать в данный сайт. После появления второго и последующих контроллеров должны образоваться Репли-кационные связи (connection objects), указывающие на то, какой контроллер и откуда должен реплицировать измене-ния. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы».

На рис. 3 открыта оснастка «ActiveDirectoryСайты и Служ-бы». По имеющейся информации можно сказать, что в дан-ном примере есть единственный сайт по умолчанию, в кото-ром находятся два контроллера домена Server1 и Server2. А также что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных свя-зей репликации между контроллерами работать не будут.

Нередки случаи, когда системные администраторы, уста-новив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространен-ная ошибка. За создание связей, базируясь на определен-ной логике, отвечает служба KCC (Knowledge Consistency Checker). Самостоятельное создание связей чревато воз-никновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, суще-ствует способ ее поторопить.

Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим об-разом:

Если нужно запустить генерацию связей на всех контрол-лерах домена в сайте, то команда Repadmin принимает вид:

Можно также запустить процесс генерации тополо-гии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения.

Без административного вмешательства служба KCC стартует на каждом контроллере домена раз в 15 минут, в случае необходимости добавляет или удаляет лишние репликационные связи (учтите, что связи, созданные вруч-ную, не управляются KCC). Логика создания связей в рам-ках одного сайта кажется довольно простой. Каждый кон-троллер не реплицируется с каждым, служба KCC всегда пытается создать кольцо репликации, причем по мере до-бавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существу-ет «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть боль-ше трех посредников.

Как только число контроллеров достигнет восьми, прави-ло «трех прыжков» приведет к тому, что служба KCC выпол-нит «ход конем» и добавит дополнительные прямые связи, сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рис. 4. Создание связей между контроллерами, расположенными в разных сайтах, выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении меж-сайтовой репликации читайте в следующей части статьи. Следует отметить, что кольцо при создании топологии репли-кации строится независимо для каждого контекста реплика-ции (раздела Active Directory), далее эти кольца накладывают-

#Вместо server1.itband.ru вы укажете FQDN вашего сервераrepadmin /kcc server1.itband.ru

#Если имя сайта было изменено, "Default-First-Site-Name" #заменяется реальным именемrepadmin /kccsite: "Default-First-Site-Name"

Рисунок 5. Расписание репликации Рисунок 6. Просмотр значения highestCommittedUSN на контроллере домена



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

Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение. Это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли перемены, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уве-домление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последу-ющие уведомления отправляются каждому партнеру с трех-секундной задержкой (верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие – 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трехсекундная задержка предотвращает чрез-мерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотифика-ций можно настроить командой repadmin /notifyopt.

Следует обратить особое внимание читателей, что про-цесс репликации всегда происходит в режиме pull, т.е. «стя-гивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер – хозяин файла NTDS.DIT – имеет право в нем что-то изменять, он отвечает за целостность своей БД. Из этого также следует, что все линки репликации, которые создаются вручную или служ-бой KCC, имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.

Некоторые изменения реплицируются без пятнадцати-секундной задержки. Такая репликация называется сроч-ной (urgent replication). В события, ее вызывающие, входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути, это не репликация вовсе, механизм передачи этих изменений в корне отличается от процесса репликации, хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механиз-мом репликации, а специальными вызовами RPC. По сути, это запросы, аналогичные изменению объектов через ADSI.

В зависимости от режима работы леса список событий мо-жет меняться.

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

Данное расписание является основным и обязательным способом репликации (см. рис. 5). Несмотря на то что сис-тема уведомлений, описанная выше, в большинстве случаев обеспечивает синхронизацию до запуска этого расписания, она не гарантирует успеха. Возможна ситуация, когда кон-троллер домена будет занят on-line-дефрагментацией базы, пересчетом связей службой KCC и просто проигнорирует необходимость обработать пришедшие к нему уведомления об изменениях на партнерах по репликации. В такой ситуа-ции изменения будут прореплицированы в течение часа.

При возникновении трудностей с репликацией можно, используя утилиту replmon, вручную запустить процесс ре-пликации, не дожидаясь расписания:

С ключем /replicate необходимо задать, куда (server2. itband.ru) и с какого контроллера (server1.itband.ru ) долж-ны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru).

Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для этого следует выполнить:

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

Алгоритм распространения измененийТеперь необходимо разобраться, как после получения ре-пликационного уведомления от партнера контроллер до-мена решит, есть ли изменения, необходимые для реплика-

repadmin /replicate server2.itband.ru server1. itband.ru ↵ dc=itband,dc=ru

Repadmin /syncall /AeS

Рисунок 7. Просмотр вектора обновлений на контроллере DC1 Рисунок 8. Просмотр атрибутов uSNCreated и uSNChanged для учетной записи



ции? Если есть, то какие объекты или их отдельные атрибуты должны быть прореплицированы? Алгоритм выглядит сле-дующим образом.

Любой контроллер домена ведет некий счетчик, на-зываемый highestCommittedUSN, который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена счет-чик свой и между контроллерами его значения не совпа-дают. Например, в 9 утра значение highestCommittedUSN у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе данного кон-троллера произошло 17 изменений. Посмотреть значение highestCommittedUSN можно с помощью утилиты ldp, просто подключившись к нужному контроллеру домена. При под-ключении выводится состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и при-сутствует highestCommittedUSN (см. рис. 6).

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

Таблица, в которой хранится информация о highest CommittedUSN репликационных партнеров, называется вектором обновления, или up-to-date vector. Посмотреть ее можно с помощью утилиты repadmin.

В данном примере результатом будет вывод значений highestCommittedUSN репликационных партнеров DC1 (а также актуальный USN его самого), это будут значения, о которых DC1 знает, в действительности они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что highestCommittedUSN увеличивается как после изменений, внесенных в базу непосредственно на контроллере, так и после изменений, прореплицирован-

ных с других контроллеров (см. рис. 7).Есть одно «но». Сам по себе up-to-date vector отвечает

на вопрос: были ли изменения? Этого недостаточно, необ-ходимо вычислить, что изменилось. Давайте рассмотрим данный механизм на примере.

В нашей сети находятся два синхронизированных контрол-лера домена (DC1и DC2). До изменений highestCommittedUSN у DC1 равен 20902, а у DC2 16940. На контроллере DC1 соз-дается учетная запись пользователя Федя Рашпин. После создания учетной записи highestCommittedUSN на DC1 стал показывать 20909. Это говорит о том, что было произведе-но семь изменений. Напоминаем, что считаются атомарные изменения, т.е. создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers.

Если пользователь подключится через LDP.exe к на-шему объекту, то можно увидеть два атрибута uSNCreated и uSNChanged (см. рис. 8).

uSNCreated будет говорить, какой highestCommittedUSN был в момент создания объекта на данном контроллере, а uSNChanged – в момент последнего изменения. Получа-ется, что первый показатель (uSNCreated) будет оставать-ся неизменным, а второй, в свою очередь, (uSNChanged) по мере обновления объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере до-мена у объекта будут свои.

Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, исполь-зуемой при репликации, задействуем ключ /showmeta.

При этом нас интересует информация с каждого кон-троллера. Но начнем с DC1.

Какую же информацию нам дает repadmin (см. рис. 9)? Данный список – это объект пользователя, разложенный по атрибутам.

По каждому атрибуту можно увидеть:Loc.USN – это highestCommittedUSN контроллера DC1 в момент внесения последних изменений.Originating DC – говорит о том, на каком контроллере были произведены последние действия с этим атрибу-том, т.е. откуда пошло распространение.Org.Usn – это highestCommittedUSN контроллера, автора изменений в момент внесения последних.

Default-First-Site-Name\DC2 @ USN 16667 @ Time 2009-09-21 01:24:15Default-First-Site-Name\DC1 @ USN 20704 @ Time 2009-09-21 01:31:25

repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru

repadmin /showmeta "CN=Федя Рашпин,OU=testou,DC=lab, ↵ DC=itband,DC=ru"

Рисунок 9. Вывод метаданных о созданном пользователе на DC1 Рисунок 10. Вывод метаданных о созданном пользователе на DC2



Ver – версия атрибута, растет на единицу при каждом его изменении (локально или в результате репликации). Attribute – непосредственно название самого атрибута.Взглянув на эту таблицу, можно сделать вывод,

что пользователь «Федя Рашпин» был создан (или из-менен) на контроллере домена DC1, при этом увидеть, что highestCommittedUSN DC1 в процессе создания учетной записи рос от 20904 до 20909 (Org.USN).

Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить то же самое на втором контроллере, результат будет не-сколько другой (см. рис. 10).

На DC2 четко просматривается, что автором всех изме-нений (кроме одного) были DC1 и его highestCommittedUSN (Org.Usn) в момент изменения каждого атрибута. А также highestCommittedUSN в момент внесения обновлений в базу контроллера DC2 (Loc.USN).

А вот теперь пора сделать небольшой вывод. Когда кон-троллер домена рассылает репликационным партнерам уве-домления об обновлении базы, он сообщает свой текущий highestCommittedUSN. Партнер, получивший уведомление, сравнивает этот highestCommittedUSN с тем, что он запом-нил с прошлой процедуры репликации. Если он вырос, зна-чит, необходимо запускать репликацию. Например: DC2 по-лучил от DC1 уведомление и текущий highestCommittedUSN, равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и за-прашивает изменения, произошедшие в период роста highestCommittedUSN с 20850 до 20912.

DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN, и те атрибуты, которые меня-лись в заданном диапазоне highestCommittedUSN, реплици-руются на DC2.

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

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

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

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

В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ к которому можно, только переключив оснастку «Active Directory – пользователи и ком-пьютеры» в расширенный режим (см. рис. 11).

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

Другой вид разногласий может возникнуть в случае одновременного создания объектов с одинаковыми имена-ми, это может быть организационное подразделение или учетная запись пользователя. В такой ситуации принцип довольно простой: объект, созданный первым, переиме-новывается, точнее, к его имени добавляется objectGUID. Если необходимость в этом объекте впоследствии сохра-нится, ничто не мешает администратору дать ему новое имя (см. рис. 12).

Большим преимуществом с точки зрения реплика-ции является переход на режим работы домена Windows Server 2003 и более поздние. В них изменилась процедура репликации атрибутов типа linked-valued (пример: «Член-ство в группах»). При добавлении разных пользователей на разных контроллерах в одну и туже группу результатом будет членство всех добавленных пользователей в составе этой группы. В случае с Windows 2000 состав группы при та-ком конфликте определялся бы по ее членству на том кон-троллере, на котором изменения в группе были бы сделаны позже по времени.

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

Рисунок 11. Контейнер LostAndFound Рисунок 12. Автоматическое разрешение конфликта


60

Визитка


Североамериканскую компанию PointClark Networks едва ли можно назвать новичком на рынке Linux-решений: ClarkConnect, ее шлюз и сервер уровня малых и средних предприятий, разрабатывается еще с 2000 года. Поэтому анонсированное в середине сентября 2009 года решение превратить ClarkConnect в полностью свободный проект (ранее часть функционала присутствовала только в ком-мерческой Enterprise-редакции), управляемый фондом ClearFoundation [1], вызвало в сообществе определенный резонанс.

Изначально ClearOS 5.1 (так, с упором на «чистоту» открытых решений, стал называться дистрибутив) предпо-лагалось выпустить 30 сентября 2009 года, но планы изме-нились. На начало декабря была доступна только вторая бета-версия. Разработчики предупреждают, что работа над продуктом еще не завершена. Тем не менее мы сочли возможным установить ClearOS и поглядеть, что же принес-ло это «открытие» коммерческому продукту.

УстановкаClearOS 5.1 распространяется в виде загрузочного ISO-образа объемом чуть менее 700 Мб. Текстовый инсталлятор предложит выбрать режим работы (самостоятельный сер-вер или шлюз – впоследствии настройку можно поменять), ввести слово «ClearOS» в знак того, что вы понимаете – все данные на локальном жестком диске и подключенных USB-устройствах (!) будут потеряны, разметить жесткий диск (можно автоматически) и выбрать модули для установки. По-следний пункт выгодно отличает ClearOS от аналогичных ре-шений, где набор встроенного ПО жестко зафиксирован.

В основе системы лежит CentOS, на базе исходных тек-стов Red Hat собираются многие серверные дистрибути-вы, например Endian Firewall [2]. Необычно другое: ClearOS не отказывается от управления пакетами в традиционной для CentOS форме. Обновление системы (например, с Beta 1 до Beta 2) выполняется командой yum update, для добавле-ния нового модуля служит yum install, и так далее.

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

предложит вам выбрать язык (русский пока поддержива-ется лишь формально – он влияет на системную локаль, но не веб-интерфейс). А также уточнить сетевые настрой-ки (включая имя домена), указать часовой пояс, сведения об организации и зарегистрировать систему (последнее яв-ляется атавизмом коммерческой эпохи и сейчас не функци-онирует). Будьте осторожны и не закройте случайно вкладку Firefox, в которой открыт веб-интерфейс – простого способа вернуть ее назад не обнаружилось. Покончив с первичной настройкой, вы сможете войти в систему, как root, с паро-лем, указанным при установке.

Первый взглядClearOS предлагает административный веб-интерфейс (ко-нечно, на базе AJAX): https://адрес-сервера-clearos:81. Раз-работчики признают, что этот вариант не слишком удобен, и предлагают поделиться соображениями по усовершен-ствованию, нажав на соответствующую ссылку.

Набор базовых сервисов, предлагаемых ClearOS 5.1, до-статочно стандартен: межсетевой экран, кэширующий DNS, DHCP, прокси-сервер с возможностью фильтрации контента (Squid/DansGuardian), почта (Postfix + Cyrus и веб-интерфейс от Horde), антивирус (ClamAV), антиспам (SpamAssassin и серые списки PostGrey), файл-сервер (Samba), VPN (OpenVPN 2.1, PPTP, IPSec), но есть и изюминки.

Это, во-первых, поддержка нескольких интернет-соединений (MultiWAN), ранее присутствовавшая только в Enterprise-редакции. Данная функция позволяет как ба-лансировать нагрузку на несколько равноправных каналов, так и распределять исходящие соединения по провайдерам в зависимости от источника и порта получателя. К сожале-нию набор критериев для выбора исходящего канала доста-точно прост, что затрудняет создание средствами ClearOS сложных (пусть и статических) схем маршрутизации.

Во-вторых, это так называемые Flexshare – средства для обмена файлами в локальной сети. Ничего необычного в самой идее нет, но доступ к ресурсу Flexshare можно по-лучить через HTTP/FTP (включая защищенные аналоги), сеть Windows, а выложить файлы – еще и отправкой электрон-

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

ClearOS 5.1: открыт и... ?Что принесло это коммерческому продукту

ВАЛЕНТИН СИНИЦЫН, кандидат физико-математических наук, доцент Уральского государственного университета. Читает авторские курсы по Linux. Главный редактор журнала Linux Format в России



ного письма с прикреплением на особый почтовый адрес. Для объектов, хранящихся на разделяемом ресурсе, поддер-живаются базовые средства контроля доступа (полноценных ACL, увы, не предусмотрено), но отсутствуют дисковые кво-ты. Реализация Flexshare повторяет историю MultiWAN: удоб-ный инструмент, подходящий в типовых случаях, но недоста-точно гибкий для более сложных сценариев.

Пользователи (наряду с группами) лежат в основе на-строек ClearOS: для контроля доступа ко всем ресурсам сервера применяется единый LDAP-каталог. При создании учетной записи пользователя можно отметить, с какими ре-сурсам (почта, VPN, WEB и так далее) он будет иметь воз-можность взаимодействовать. Список пользователей мож-но импортировать в нескольких форматах, включая даже OpenDocument Spreadsheet, но, увы, нельзя настроить ClearOS для работы с внешним LDAP-каталогом: это услож-няет его внедрение в существующую инфраструктуру.

Ложки дегтяУ ClearOS имеются и досадные недостатки: речь идет не об ошибках, которые для бета-версии простительны, а об архитектурных недоработках. Начнем с поддержки сети. ClearOS справляется со статически и динамически настраи-ваемыми Ethernet-интерфейсами, DSL/PPPoE, но не имеет понятия о PPTP или L2TP, весьма «уважаемых» отечествен-ными интернет-провайдерами, не говоря уже о к 3G- или WiMax-сетях. «Трехногая» схема деления сетей на локаль-ную, интернет- и демилитаризованную зоны не предусматри-вает специального интерфейса, выделенного для беспро-водных соединений, которые есть в организациях и должны жестко контролироваться по соображениям безопасности.

Неудобно реализована поддержка OpenVPN. Коробоч-ное решение – это компромисс между гибкостью и просто-той настройки, но OpenVPN-модуль не позволяет указать ни тип используемого интерфейса (это TUN), ни IP-адреса, назначаемые виртуальному каналу. Если локальный адрес совпал с подсетью, в которой находится мобильный клиент, считайте, что вам не повезло.

К чему эти нападки? Можно просто взять исходные тек-сты и поправить их! Исходные коды ClearOS пока отсутству-ют: на сайте [3] можно найти полный набор SRPM-пакетов, но для ClarkConnect 5.0; по адресу [4] доступны неполные (нет как минимум всех веб-модулей административного ин-терфейса) исходные тексты ClearOS 5.1. Нет также ни SDK,

ни платформы для сборки дистрибутива, ни даже инструк-ции, объясняющей, как это делать.

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

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

Видны активные попытки создать вокруг ClearOS спло-ченное сообщество (достаточно сказать, что сам сайт www.clearfoundation.com во многом является социальной сетью), маркетинговая машина работает на полную катуш-ку, но сроки выхода финальной версии ClearOS 5.1 постоян-но сдвигаются. Документация к версии 5.1 также оставляет желать лучшего, если не считать справочник разработчика. Хочется надеяться, что перечисленные здесь моменты явля-ются трудностями переходного периода и будут преодолены к дате выпуска финальной версии. Возможности, открывае-мые для проекта открытой моделью разработки, слишком заманчивы, чтобы не воспользоваться ими.

1. ClearFoundation – http://www.clearfoundation.com.2. Endian Firewall – http://www.endian.com. Синицын В. Endian Firewall 2.2: из Италии с любовью. //Систем-

ный администратор, №6, 2008 г. – С. 18-21.3. Исходные тексты ClarkConnect 5.0 – http://download.clarkconnect.

com/community/sources/5.x.4. Исходные тексты ClearOS 5.1 – http://download.clearfoundation.

com/clearos/enterprise/sources/5.x.

Через браузерПопробовать ClearOS можно и без установки: просто зайдите на https://

demo[12].clearos.com:81, используя реквизиты get/clear. Административ-

ный доступ к этим виртуальным системам открыт всем желающим, поэто-

му не удивляйтесь, увидев странный набор системных сервисов и бра-

зильский/португальский в качестве языка по умолчанию.

EOF

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

Рисунок 1. Большинство серверных дистрибутивов желают занять весь жесткий диск, но только ClearOS покушается и на USB-носители


62

Визитка


Ты единственная мояИменно так. В среде людей, обслуживающих АТС Samsung OfficeServ, до некоторого времени существовала единст-венная программа настройки – Samsung OfficeServ Manager (OSM). Что поделать, закрытый протокол, рады были и тому, что есть, потому что альтернативой было только програм-мирование с системного телефона. Но все меняется к луч-шему, и Samsung наконец-то выпустила новую программу для управления АТС – Installation Tool (IT), которая в корне отличается от OSM.

Отказались от идеи панели запуска (launchpad), ис-пользуемой в OSM. Идея была хорошая на тот момент – программы для управления OS12, OS500 и OS7200 могли серьезно различаться, но с унификацией в новых сериях эти различия стерлись и в IT все управление подключени-ями выполняется непосредственно в самой IT, что значи-тельно повышает удобство работы с программой. Кроме того, наконец-то в описании АТС можно применять не-ASCII-символы, то есть вводить описания АТС по-русски.

Изменился формат базы данных настроек, сохра-няемых на компьютер, – файл настроек стал меньше, и настройки стали сохраняться и восстанавливаться зна-чительно быстрее. Даже не то что значительно – по ощу-щениям быстрее раз в пять! Правда, за счет кардиналь-ного пересмотра формата базы и потери совместимости, из-за чего переход, например с версии прошивки 2.69 на 4.30 – достаточно долгий процессБыл сделан первый шаг к созданию не просто сред-ства управления АТС, а средства, дружественного к пользователю. При проектировании интерфейса программы отказались от простого перечисления MMC и сгруппировали их (настройки) по некоторым функцио-нальным признакам. Это значительно повысило удоб-ство работы – перед тобой теперь не безликие ряды цифр, а имеющие осмысленное наименование группы настроек.У IT наконец-то появился русский интерфейс! Но не думайте, что там профессиональный – про-

Единственная в своем роде программа для уп-равления офисными АТС Samsung – Samsung OfficeServ Manager больше не разрабатывается. Ей на замену пришла Installation Tool

АТС Samsung OfficeServ?Теперь работаем с Installation Tool

РАШИД АЧИЛОВ, поклонник FreeBSD с 14-летним опытом использования ее в совмещенных с Windows сетях и сторонник Open Source. Администратор сетей и средств защиты крупной торговой сети

Рисунок 1. Общий вид окна Installation Tool Рисунок 2. Общий вид окна Installation Tool с подключенной АТС



сто все английские слова переведены на русский, так что вместо quick link вы, разумеется, увидите «быстрый подключить». Тем не менее в данной статье все пункты меню будут называться по-русски. Кроме русского и английского, доступны и другие языки: ко-рейский, китайский, немецкий и итальянский. Справ-ки по настройкам АТС как не было, так и нет, вместо нее по-прежнему придется пользоваться инструкцией по программированию, а для того, чтобы не запутаться, в IT есть быстрый поиск – по меню и по ММС и поиск этот весьма полезен – многие настройки, ранее сгруп-пированные в одном MMC, оказались разнесены в раз-ные группы меню.Наконец-то появилась возможность выделения ячеек группой и возможность автоматической последова-тельной нумерации ячеек. Скажете, не очень нужно? Ошибаетесь! Когда необходимо изначально перенуме-ровать все порты, например сидеть и вручную вбивать? А раньше было именно так – для внесения в программу номеров от 2000 до 2050, например, приходилось сидеть и забивать вручную 2000, 2001, 2002...Новый пароль для доступа в программу. Раньше для доступа к АТС через OSM использовался пароль программирования уровня технического специалиста по умолчанию 4321. Теперь пароль может быть буквен-ным, и по умолчанию он samsung.А теперь отметим... нет, не минусы, конечно, но все же

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

> Программа IT работает только с АТС семейства OS7x – 7100, 7200, 7400 и с новыми моделями АТС, недавно прибавившимися к семейству – 7070 и 7030, причем разные версии программы могут не поддерживать те или иные модели АТС и те или иные версии проши-вок. В IT есть специальная «Таблица совместимости», в которой прописано, какая версия программы поддер-живает какие АТС и какие прошивки MCP. Беспокоить-ся не о чем, как правило, только тем, кто своевремен-но обновляет прошивки и саму IT, остальным же стоит прочитать.

> Программа не поддерживает и, вероятно, не будет под-держивать OS500 и другие АТС, которые выполнялись в корпусе для настенного монтажа – OS100, OS12... Также программа НЕ поддерживает OS7x с прошивка-ми MCP версии меньше 4.x – тем, кто все еще поль-зуется бесплатным SIP/H323, придется, как и раньше, пользоваться OSM.

Скачивается Installation Tool там же, где и все про-чее программное обеспечение, прошивки, документация и прочее. Нет, я не имею в виду сайт Samsung. Компания Samsung честно и откровенно предупреждает, что техни-ческая поддержка по данному продукту осуществляется поставщиками.

Соответствующий раздел форума ([3]) просто закрыт для чтения, доступен только зарегистрированным пользова-телям, да и, судя по количеству сообщений, там искать нече-го – одни спамеры. И хотя по логике вещей именно там все это и должно быть сложено, все это сложено вовсе не там, а на форуме «Офисные АТС» [4]. Там есть соответствующие разделы для программного обеспечения, где можно найти все необходимое, включая советы настоящих профессио-налов.

А теперь посмотрим на то, как выглядит IT (см. рис. 1). После подключения справа загружается древовидная

структура, в которой можно выбирать пункты меню, а спра-ва – данные, выгружаемые по выбранному пункту меню из АТС. Вот так выглядит IT, когда подключение к АТС уста-новлено (см. рис. 2).

Сверху развернута панель поиска (когда используешь документацию, в которой все привязано к MMC, а такой мно-го, – вещь просто незаменимая), а снизу в строке состояния отображается различная информация:

На заметкуВ прошивках MCP версии 2.69 и ниже возможно использование SIP/

H323 без приобретения дополнительных лицензий, в прошивках 4.х,

которые дают возможность использовать IT, для включения SIP/H323

требуется приобрести отдельные лицензии на каждый порт SIP/H323.

Стоит одна лицензия недорого – около 70 руб. SPNet же лицензирова-

ния не требует!

Рисунок 3. Контроль соединения с АТС Рисунок 4. Установка кода региона



> состояние подключения («Онлайн»);> имя АТС, данное во время настройки подключения

(«Станционная»);> модель АТС (OS7100);> страна («Россия/СНГ»);> номер версии прошивки (081208-4.30а).Здесь мы также видим, что обещанная русификация

на самом деле неполная – русифицирован только интер-фейс IT, а то, что выгружается из АТС, – нерусифицировано (и вряд ли когда будет).

Новое – это хорошо забытое староеИли, по крайней мере, подзабытое. С момента публика-ций [1, 2] прошло два с половиной года, но актуальности своей они не потеряли ни капельки. Но чтобы не блуждать каждый раз по поиску MMC в IT, я вкратце перескажу, где нужно выполнять настройки, упомянутые в статьях [1, 2] с использованием IT.

Итак. Настройка связи со станцией выполняется через меню «Система → Контроль соединения» (см. рис. 3).

Все просто – в поле «Имя» пишете имя АТС (можно ис-пользовать все символы русского алфавита, пробелы и ка-вычки), в поле «IP-адрес» – адрес АТС и нажимаете кнопку «Обновить».

Для подключения к АТС нажимаете на «стрелку вниз» возле самого левого значка на панели инструментов – по-является список АТС, который редактируется в «Контроле соединения».

Если просто нажать на самый правый значок на панели инструментов или выбрать «Подключить» в меню «Систе-ма», будет выполнено подключение к той станции, к которой подключались в последний раз (если еще не подключались никуда – к той, что была создана последней). Напоминаю, что пароль по умолчанию – samsung.

Для установки кода региона используем меню 2.1.0. Щел-каем на списке в System Country, справа появляется «стрел-ка вниз». Выбираем RUSSIA/CIS (см. рис. 4).

Внимание! Напоминаю, что регион нужно задавать в первую очередь, потому что при смене региона сбрасыва-ются все настройки!

Время отключения по неактивности устанавлива-ется в меню 5.14.2. Установить надо и KMMC Lock Out Time и Application MMC Lock Time. Максимальное время, как и раньше, – 60 мин.

Дата и время задаются в меню 2.1.3. Кроме того, в этом меню можно указать дату перехода на летнее/зимнее время (см. рис. 5). К сожалению, указать адрес внешнего сервера времени нельзя. А жаль.

Время распознавания сигнала Flash задается в меню 5.5.0. Номерной план АТС настраивается в меню 2.8.0. Но-мерной план вещь чрезвычайно важная, поэтому под него выделено отдельное меню (см. рис. 6).

Включение внутренних линий в группы выполняется в меню 4.1.1, направление вызовов с определенного транка на определенную группу – в меню 3.2.1. Я не привожу кар-тинки, аналогичные картинкам в статьях [1, 2], там смотреть особо не на что, таблица выглядит точно так же.

Вот в формировании групп доступа произошли некото-рые изменения.

Во-первых, группировка портов для внутренних линий те-перь не 001-300, а 001-100, а внешних – начиная со 101. По умолчанию все внутренние порты входят в группу 1, а все внешние – в группу 101.

Внимание! В группу 101 входят также порты SPNET. Рекомендуется перенести их в отдельную группу и управ-лять доступом отдельно. Настройка групп выполняется в меню 5.1.1.

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

Таким образом, для формирования обычных четырех групп, из которых:

> группа 1 может и звонить, и принимать вызовы;> группа 2 может звонить, но не может принимать вызовы;> группа 3 не может звонить, но может принимать вызовы;> группа 4 не может ничего.

Рисунок 5. Установка системного времени Рисунок 6. Номерной план в Installation Tool



Необходимо в меню 5.1.2 поставить № в столбцах 3 и 4, а в меню 5.1.3 – в столбцах 2 и 4. И, разумеется, не забыть разнести внутренние линии по соответствующим группам (см. рис. 7).

Ну вот, теперь АТС в режиме «обычной станции» должна работать. Как и в прошлый раз, мы не трогаем «планы звон-ка» – по умолчанию действует Plan 1, что нас вполне устраи-вает. Перепрошивка блоков MGI выполняется, как и рань-ше, через Device File Uploader (DFU) или вручную. Вручную, надо сказать, я никогда перешивать не пробовал, но на [4] есть ссылки на документацию, описывающую этот процесс.

Что же касается DFU, компьютер, на котором будет запу-щен DFU, должен находиться с АТС в одном локальном сег-менте или, по крайней мере, доступ между ними не должен запрещаться – иначе ничего не получится, потому что DFU использует собственный TFTP-сервер для загрузки прошив-ки в блок MGI. Впрочем, прошивки MGI выходят весьма ред-ко – с момента выхода статьи [2] было выпущена всего одна прошивка – 1.14.

В логике перепрошивки MCP не изменилось вообще ни-чего. Прошивка, то есть обновление файлов на карте па-мяти, выполняется практически точно так же, как раньше. Окно «Контроль файла» вызывается или через «Утилиты → Контроль файла» или через кнопку на панели инструмен-тов (см. рис. 8). Хорошо заметно, насколько коряво выгля-дит «русский» перевод – он банально не умещается в поле кнопки.

При перепрошивке блока MCP, когда он находится в ре-жиме «загрузить установки по умолчанию», невозможно удалить файл STARTUP.PRE для замены его на более новую версию – программа постоянно заявляет This is the latest file (это самый последний файл) и файл не удаляется, в нор-мально режиме все проходит без ошибок.

Раздел для внесения номеров N-LCR находится там, где и должен – в номерном плане, меню 2.8.0. Щелкаете на список рядом со словом Cabinet в правом верхнем углу и выбираете N-LCR.

Системные идентификаторы задаются в меню 3.3.1. На-строек стало больше, описание системы теперь можно вводить на русском языке (не более 16 символов). Кроме

того, теперь можно задать кодек для связи непосредственно с конкретным узлом (см. рис. 9).

Связь между системным идентификатором и блоком из N-LCR задается в меню 3.3.2. Таблица для задания связей ничуть не изменилась.

Ничуть не изменились и блок выбора маршрута, который задается в меню 3.1.2, и таблица временных зон, которые задаются в меню 3.1.3.

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

Ну и, наконец, таблица маршрутов находится в меню 3.1.4. Формат таблицы был переработан, из-за чего перестал ка-заться сверхъестественно громоздким. Теперь это не трех-мерная таблица с абсциссой, ординатой и аппликатой, а на-бор двумерных, в котором конкретная таблица выбирается списком Route в правом углу. По вертикали идут классы, по горизонтали – зоны. Так же, как и раньше, во всем этом нужно только поставить номер группы линий SPNET/город-ских транков/, еще чего-нибудь в поле Group-зоны 1 клас-са 1 и, если необходимо, задать номер таблицы модифика-ции (см. рис. 10).

Маршрутизация входящих номеров задается в меню 3.2.3 и ничем не отличается от прежнего вида. Все настройки LCR, связанные с включением и временными параметрами, вынесены в меню 3.1.1 – включение LCR и прочее делает-ся оттуда. Удаление номера «9» из списка транковых групп делается, как и раньше в номерном плане, то есть в 2.8.0, отключение непосредственного доступа – в меню 2.5.2.

И немного полезных советов.> Для очистки некоторого блока ячеек теперь наконец-то

можно как в табличных процессорах – выделил блок ячеек, нажал <Del> – ячейки очистились. В OSM такого не было.

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

Рисунок 7. Настройка групп доступа в Installation Tool Рисунок 8. Контроль файла в Installation Tool



в OSM. Режим автозаполнения включается в панели ин-струментов конкретного MMC (и, разумеется, может быть неактивным) значком «Повторить». Необходимо выделить область для автозаполнения, потом нажать «Повторить» и ввести начальное значение и через запятую – значение, на которое необходимо увеличивать каждое следующее. Если в качестве второго значения указать 0, выбранный диапазон будет заполнен одинаковыми значениями.

Обновление прошивки с версии 2.69Здесь я немного расскажу о порядке обновления прошивки MCP OS7200 с версии 2.69, последней версии, в которой SIP/Н323 не требует лицензирования (но и не поддерживает IT), на последнюю на данный момент версию 4.30к. Проце-дура это довольно сложная, требует изрядных временных затрат и непременного наличия человека с системным теле-фоном возле АТС. Имеется в виду, конечно же, обновление прошивки таким образом, чтобы сохранить все старые на-стройки. Если старые настройки не важны – достаточно просто заменить прошивку.

Итак, проблема состоит главным образом в том, что с мо-мента выхода прошивки 2.69 формат базы настроек менял-ся несколько раз – сначала в 4.14, потом в 4.21, потом в 4.30. И для сохранения настроек необходимо будет постепенное преобразование базы последовательной установкой всех этих прошивок. При этом АТС должна находиться в режиме «не хранить настройки», в котором каждый раз при загруз-ке происходит загрузка настроек по умолчанию – АТС здесь выступает этаким конвертором базы настроек и больше ни-чего. Мне довелось проводить эту операцию удаленно, ру-ководя по ICQ и сотовому телефону.

Обязательно проверьте наличие системного телефона. В процессе обновления постоянно придется использовать MMC 818, которое недоступно из программ управления.

Начали.> Устанавливаем на тот компьютер, на который будут со-

храняться данные настройки, OSM версии 4.14, если он там еще не стоит (последняя на данный момент вер-сия OSM).

> Сохраняем настройки АТС.

> Устанавливаем прошивку версии 4.14 (это единст-венная версия прошивки, которая поддерживается как OSM, так и IT), с помощью MMC 818 обновляем про-шивку так, чтобы грузилась 4.14.

> Выключаем АТС и переводим джампер на блоке MCP в положение «сброс в заводское умолчание»

> Включаем и загружаем АТС. Если настройки IP сле-тели, выставляем их заново с системного телефона. Убеждаемся, что загрузилась 4.14.

> Подключаемся через OSM и загружаем настройки. В этот момент произойдет преобразование базы.

> Закрываем OSM и подключаемся через IT. Сохраняем базу настроек.

> Устанавливаем прошивку версии 4.21, обновляем с по-мощью MMC 818.

> Перезагружаем АТС (если надо, заново настраиваем IP MCP), убеждаемся, что загрузилась 4.21.

> Загружаем настройки. В этот момент произойдет еще одно преобразование базы настроек. Сохраняем базу настроек.

> Устанавливаем прошивку версии 4.30, обновляем че-рез MMC 818.

> Перезагружаем АТС (если надо, заново настраиваем IP MCP), убеждаемся, что загрузилась 4.30.

> Загружаем настройки, убеждаемся, что все преобразо-валось нормально, если что-то не так – подстраиваем. Сохраняем настройки.

> Выключаем АТС и вот только теперь переводим джам-пер в положение «хранение настроек».

> Включаем АТС, настраиваем IP MCP (все будет сбро-шено) и заново загружаем настройки АТС.

1. Ачилов Р. Развертываем корпоративную телефонную сеть на основе технологии VoIP. Часть 1. //«Системный администра-тор», № 6, 2007 г. – С. xx-xx.

2. Ачилов Р. Развертываем корпоративную телефонную сеть на основе технологии VoIP. Часть 2. //«Системный администра-тор», № 8, 2007 г. – С. xx-xx.

3. http://ru.samsung.com/forum.4. http://forum.officeats.ru.

Рисунок 9. Системные идентификаторы станций Рисунок 10. Таблица маршрутизации в Installation Tool

EOF


68

Визитка


Проект Wine был начат Бобом Амштадтом (Bob Amstadt) в 1993 году для запуска приложений Windows 3.1 (16 бит) в среде GNU/Linux. Акроним Wine расшифровывается следующим образом: Wine – это не эмулятор (Wine Is Not an Emulator). Основная цель проекта – свободная реализа-ция Windows API (Application Programming Interface), т.е. до-бавление определенного «слоя совместимости» между программным обеспечением, ориентированным на опера-ционную систему MS Windows и GNU/Linux. Поскольку Wine не эмулирует аппаратную часть, то скорость работы прило-жений, как правило, не замедляется.

Первый релиз в 2009 году был выпущен 2 января – 1.1.12, последний – 18 декабря – 1.1.35. Всего выпущено 24 рели-за, которые включили исправления более полутора тысяч ошибок.

Рассмотрим, как развивался проект в минувшем году. Для удобства я условно выделил ряд направлений.

Общесистемные измененияРазработчики реализовали совместимость с протоколом Freedesktop.org, что позволяет отправлять уведомления о запуске программ (1.1.13 – здесь и далее номер версии Wine, кроме того, там, где это возможно, изменения опи-саны в хронологическом порядке по старшинству версий). Со стандартом протокола можно ознакомиться по адре-су: http://standards.freedesktop.org/startup-notification-spec/ startup-notification-latest.txt.

Затем разработчики обеспечили поддержку ассоциа-ции файлов, которую использует сообщество freedesktop (для start.exe добавлена возможность запуска файлов MS Windows с ассоциациями freedesktop – 1.1.24).

Была проделана работа по добавлению необходимой поддержки кросс-компиляции в winegcc (1.1.15), а также по улучшению поддержки кросс-компиляции с использова-нием Mingw. Появилась поддержка сборки PE-приложений (winegcc), для winedbg добавлены обертки для Read/ WriteProcessMemory с целью исправления ошибок сборки Mingw (1.1.23).

Появилась поддержка сборки автономных (stand-alone) 16-битных модулей (1.1.16). Впоследствии ряд 16-битных DLL был разбит на отдельные модули (1.1.31). В процессе подготовки выпуска версии 1.1.35 работа по отделению 16-битных библиотек была продолжена.

Получила развитие и поддержка MSI. В выпуске 1.1.18 была улучшена поддержка функции обновления пакетов MSI. Затем в выпуске 1.1.35 усовершенствована производи-тельность: клонирование открытого потока вместо открытия нового; замена хеш-строк таблицы с сортировкой индекса; удалены неиспользуемые поля из строк таблицы, а также сделаны другие изменения.

Разработчики внесли ряд изменений в поддержку OLE. Так, были решены проблемы с работой буфера обмена (1.1.19) и усовершенствованы возможности по копиро-ванию/вставке в него OLE-объектов (1.1.20). Затем была усовершенствована передача объектов OLE через буфер обмена (1.1.22). Улучшился процесс преобразования (мар-шалинг) представления в памяти с целью использования формата данных, который соответствует в конкретных усло-виях требованиям хранения и передачи для библиотеки OLE (1.1.34).

Далее разработчики усовершенствовали поддержку хра-нилища транзакций OLE (OLE transacted storage): ошибка доступа к памяти в storage32, использование виртуальных таблиц (vtable) для чтения/записи из/в потоки, WriteDirEntry и ReadDirEntry добавлены в виртуальные таблицы storage, и другое (1.1.35).

Большое количество изменений претерпели регрессив-ные тесты для Windows (1.1.14, 1.1.16, 1.1.17), в том числе были исправлены ошибки, возникающие при регрессивных тестах для Win64 и Windows 7 (1.1.29).

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

Ряд волшебных измененийЧто нового появилось в проекте Wine?

ИГОРЬ ШТОМПЕЛЬ, инженер, системный администратор. Сфера профессиональных интересов – свободное программное обеспечение

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

В.О. Ключевский



Кроме того, появилась начальная поддержка обра-ботки исключений для платформы x86_64. Например, для ntdll – для стека обработчиков (handlers) (1.1.22). Также продолжала развиваться поддержка выполнения 64-раз-рядных программ Windows: добавлена поддержка гене-рации 32/64-битного кода для прокси/клиентов/серверов (widl); код отладки переработан для поддержки 64-битных платформ (ntdll) (1.1.12); для ntdll – исправление ошибок в структурах, возвращаемых NtQuerySystemInformation; для MSHTML – исправление тестов для платформы Win64 и многое другое (1.1.13, 1.1.17). Что касается 64-разряд-ных приложений, то появилась обработка исключений для 64-разрядных сборок (1.1.24), а в отладчике исправлены ошибки 64-битного режима (1.1.35).

Изменилось и обеспечение поддержки безопаснос-ти. Здесь необходимо сказать несколько слов о биб-лиотеке crypt32. Разработчики оптимизировали интер-фейс в менеджере сертификатов. Например, в cryptui добавлены диалог менеджера сертификатов и возмож-ность включения/отключения контроля на основе выбо-ра в диалоговом окне менеджера сертификатов (1.1.13). Улучшена ее работа, последняя наделена специальным ин-струментом для экспорта (заглушки для PFXImportCertStore и PFXExportCertStoreEx-1.1.14).

Затем разработчики внесли ряд изменений в реализа-цию библиотеки, в частности, затрагивающих поддержку 64-разрядных платформ (1.1.32). Они усовершенствовали поддержку цифровых сертификатов в crypt32: исправлено расширение AKI, используемое в конце сертификата, и CRL для проверки отзыва; появилась возможность чтения дове-ренных корневых сертификатов системных брелков опера-ционной системы Mac OS X. (1.1.33, 1.1.34). Отдельно отме-чу улучшение проверки сертификатов для SSL-соединений (1.1.35).

Кроме того, winemaker получил поддержку файлов про-ектов из интегрированной среды разработки MS Visual C++ (1.1.19) и 64-разрядного режима (1.1.21). Упростилось управление дисковыми разделами за счет усовершенство-вания поддержки соответствующего API (1.1.27). Стало воз-

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

Рассмотрим изменения конкретных операционных систем. Так, была исключена устаревшая поддержка LinuxThreads (библиотека потоков) (1.1.17). Для платформы Solaris реализована библиотека iphlpapir (IP Helper) (1.1.17). Для платформы OpenBSD решены проблемы, возникавшие при сборке (1.1.19). Появилась возможность отладки симво-лов в WineDbg для операционной системы Mac OS X (Debug symbols in WineDbg on Mac OS X) (1.1.18), а также поддерж-ка сборки Wine в Mac OS X Snow Leopard (1.1.21).

Отметим и ряд более мелких улучшений. Работа прило-жения Richedit была усовершенствована (1.1.13), прило-жение получило поддержку безоконного режима (1.1.14). Ряд изменений коснулся DIB (Device-Independent Bitmap). Увеличена производительность (1.1.31, 1.1.32), добавлена поддержка 16/32-битных секций (1.1.31). Усовершенство-ван диалог вывода на печать (1.1.14). Добавлена начальная реализация поддержки MS Text Framework (1.1.15). Вклю-чено специальное диалоговое окно, которое выводится при крахе приложения (1.1.20). Расширены возможности по просмотру списков, называемых listview: исправлены ошибочные описания функций, добавлены дополнитель-ные тесты для LVS_EX_HEADERDRAGDROP (1.1.20, 1.1.21, 1.1.24, 1.1.34). Появились поддержка реализации функций COM-прокси (COM proxy delegation – 1.1.23) и автоматиче-ская очистка меню рабочего стола (1.1.25). Переработа-на поддержка функций управления календарем (comctl32/ monthcal) (1.1.31). Улучшена работа типовых элементов уп-равления (1.1.32). Проделана работа по чистке кода от уте-чек памяти, найденных при отладке при помощи системы Valgrind (1.1.33).

Поддержка мультимедиа-технологийРассмотрение изменений в области мультимедиа-технологий начнем с поддержки устройств. Так, разработ-чики улучшили работу со сканерами с использованием инфраструктуры SANE (например, для приложений опера-ционной системы MS Windows – 1.1.16), а также добавили

В 2009 году проект Wine про-шел большой и плодотворный путь. В новой ветке разработчи-ки обещают много интересного



возможность воспроизведения дисков аудио-CD (1.1.16). Для джойстика добавлена возможность изменения коорди-нат через edev (1.1.28). Платформа Mac OS X получила под-держку джойстика (1.1.17) и доступ к DVD (1.1.32).

Небольшое количество улучшений добавлено в работу с кодеками. Появилась начальная поддержка dll-библиотек для кодеков операционной системы MS Windows (1.1.25). В WindowsCodecs включены новые форматы изображений, включая JPEG и PNG (1.1.27, 1.1.28). Реализована поддерж-ка кодека GSM 06.10 (1.1.27).

В области работы с графикой изменения более суще-ственны. В библиотеку GDIPlus добавлена поддержка де-сяти новых функций (Graphic Device Interface, графический интерфейс устройств) – предоставление графических объ-ектов и передача их на устройства вывода графической ин-формации (1.1.15):

> GdipIsEqualRegion;> GdipTranslateRegion;> GdipTranslateRegionI;> GdipGetRegionBounds/GdipGetRegionBoundsI;> GdipTranslateClip/GdipTranslateClipI;> GdipCreateBitmapFromHICON (с тестами);> GdipGetClipBounds/GdipGetClipBoundsI;> GdipSetClipHrgn;> GdipFillRegion;> GdipGetLogFontA.Затем разработчики улучшили код для совмести-

мости с данной библиотекой: добавлена заглушка для GdipBitmapSetPixel; появилась возможность проверки указателей заголовков в CreateDIBitmap и другое – 1.1.21.

Кроме того, разработчики ускорили операции растягивания битовых карт посредством использования XRender (1.1.26). XRender (X Rendering Extension), или Расширение рендеринга для X, – позволяет реализовать алгоритмы Портера-Даффа в X-сервере [1]. Они улучшили поддержку XShm-технологии (Xlib Shared Memory Extension), позволяющей осуществлять передачу пиксельных карт. Основная цель включения послед-ней – увеличить производительность (1.1.27).

Значительные изменения претерпела поддержка Direct3D. Произведена масштабная чистка кода, которая затронула три релиза – 1.1.18, 1.1.19 и 1.1.20: добавлены интерфейсы ID3D10EffectRasterizerVariable и ID3D10Effect

SamplerVariable, а IsValid() реализован для нескольких ин-терфейсов; улучшены ID3D10EffectVariable::GetType(), ID3D10EffectType::GetDesc().

Была исправлена работа режима FBO (Frame Buffer Object), который стал после выпуска 1.1.23 установленным по умолчанию для Direct3D: для wine3d – проверка связей с использованием stretch_rect_fbo(); откат к закадровому рендерингу backbuffer, если нет доступа к FBO (1.1.20).

Разработчики начали реализацию четвертой модели шейдеров () из Direct3D 10 (1.1.21), отладили работу с бло-кировками в коде (1.1.22). Работа по реализации функций и улучшению поддержки Direct3D 10 была продолжена (1.1.30, 1.1.31). В выпуске 1.1.33 разработчики добавили ряд новых функций Direct3D 10 (1.1.33).

Что касается поддержки OpenGL, то в выпуске 1.1.22 была усовершенствована поддержка пиксельного форма-та (1.1.22), а в выпуске 1.1.25 – управление памятью.

Также разработчики усовершенствовали реализацию ARB-шейдеров (wine3d – добавлена поддержка расширения ARB_depth_buffer_float, усовершенствование texldd и texldl – 1.1.22, 1.1.24).

Кстати, в версии 1.1.12 была реализована поддерж-ка субпиксельного рендеринга шрифтов (subpixel font rendering), а в версии 1.1.23 появилась полноценная реа-лизация полноэкранного режима виртуального рабочего стола (1.1.23).

Работа над поддержкой звука тоже повлекла ряд важных изменений. Так, работа звукового драйвера Esound была улучшена (1.1.19), а библиотека libmpg123 стала исполь-зоваться для декодирования mp3 (1.1.29). В выпуске 1.1.30 появилась поддержка звукового API – OpenAL (1.1.30).

OpenAL (Open Audio Library) является свободной крос-сплатформенной реализацией 3D аудио-API. Поэтому би-блиотека может быть использована как в игровых приложе-ниях, так и в других, где необходима подобная обработка звука. Домашняя страница проекта находится по адресу: http://connect.creativelabs.com/openal/default.aspx.

Релиз 1.1.31 принес исправления в работе ряда звуковых драйверов, а 1.1.33 – улучшенную поддержку звука в mciwave (исправлена ошибка, затрагивающая приостановку/воспро-изведение; произведено обновление сообщений и коммен-тариев; формат wave по умолчанию – 11025 КГц/8 бит).

Рисунок 1. Отправка сообщений с приложением Рисунок 2. Поддержка Unicode в Notepad



Кроме того, добавлена поддержка копирования/вставки изображений посредством буфера обмена из приложений X11 (1.1.21).

Поддержка веб-технологийЗначительное количество изменений претерпел движок Gecko. Сначала до версии 0.9.0 (1.1.12) и 0.9.1 (1.1.15), за-тем была интегрирована новая версия – 1.1.0 (1.1.27). Далее проведено усовершенствование интеграции Gecko в се-тевую подсистему Wine (1.1.29). А с версии 1.1.33 движок Gecko стал устанавливаться во время создания wineprefix (1.1.33).

Изменилась поддержка JScript. Разработчики добави-ли большое количество новых функций для Jscript (Bool_ valueOf, Date_valueOf, Function_valueOf, String_fontcolor, String_fontsize и другие – 1.1.26), затем реализовали началь-ную поддержку ActiveX в движке Jscript (1.1.31).

Несколько улучшилась поддержка Internet Explorer. Сна-чала стала качественнее обработка графики (1.1.13), затем было внесено немало изменений в работу Internet Explorer 7 для ее улучшения (1.1.14).

Перемены затронули и MAPI: улучшены поддержки MAPI (исправлена ошибка, приводящая к утечке памяти; усовершенствованы MAPIInitialize, Logon, Logoff, LogonEx, Uninitialize) (1.1.30); возможность добавления приложений к письму (1.1.31), что показано на рис. 1.

Отметим и ряд других изменений. Так, версия 1.1.16 по-высила качество управления cookies в Wininet (провер-ка cookie-информации на основе cookie-значений, тесты для сложных значений cookies и другое – 1.1.16). Появились поддержки работы RPC поверх протокола HTTP (1.1.18) и для рабочего стола GNU/Linux, зарегистрированных ти-пов MIME (1.1.23). WinHTTP получило возможность работы с прокси (1.1.26). Внесено большое количество усовершен-ствований в код поддержки HTML и JavaScript (1.1.30).

Улучшения затронули и рендеринг HTML (1.1.32). Усо-вершенствована библиотека MSHTML (использование глобального значения wine_dbgstr_w, улучшена заглушка для IHTMLWindow4, обновлен ряд переводов – 1.1.34).

ЛокализацииЛокализации Wine активно развивались в 2009 году. На-пример, выпуск 1.1.25 принес множество обновлений пе-реводов. Добавились или обновились следующие языки: норвежский, немецкий, японский, литовский, итальянский, французский, испанский, словенский, румынский, фин-ский, голландский. Кстати, выпуск 1.1.26 также содержал большое количество изменений в данной области.

Какие изменения произошли в поддержке русского язы-ка? Так, в версии 1.1.14 были исправлены опечатки. В вер-сии 1.1.23 появился перевод winedbg. Выпуск 1.1.28 при-нес обновления переводов winecfg и wininet. А следующий выпуск – корректировку перевода для библиотеки shdoclc (Microsoft Shell Doc Object and Control Library), которая ис-пользуется для базовых операций с файлами и операций в сети. Выпуск 1.1.30 содержал добавление и обновле-ние перевода для JScript. Кстати, обновление последнего было осуществлено и в следующей версии. Обновились переводы для программ и dll-библиотек (1.1.32) и Setupapi, JScript (1.1.33), а также MSHTML (1.1.34).

Кроме того , как показано на рис. 2, была добавлена под-держка Unicode для Notepad (ОС – MS Windows) (1.1.25).

ПерспективыВ Голландии 7-8 ноября 2009 года прошла VII ежегодная конференция разработчиков Wine – WineConf 2009 [2]. На-мероприятии было сказано о том, что настала пора выхода релиза 1.2, цель которого – обеспечение 64-битной под-держки. Среди других возможностей, которые было бы неплохо обеспечить в новой ветке, по мнению разработ-чиков: движок DIB (необходимо исправить – bug #412) [3]; MacOSX QuartzDriver (графический драйвер для Wine, ко-торый призван заменить X11drv, для обеспечения лучшей интеграции Wine в Mac OS X) [4]; поддержка USB (необхо-димо исправить – bug #9649) [5]; Direct3D 10 [6]; мульти-пользовательский Wineserver (необходимо исправить – bug #11112) [7]. С обширным списком того, что предполагается сделать в будущем, можно ознакомиться по адресу http:// wiki.winehq.org/TodoList.

Кроме того, разработчики выделили ряд критериев, соот-ветствие которым позволит осуществить выпуск версии 1.2. Сегодня они имеют три «номинации» – ошибки, фокус при-ложений, документация и интерфейс пользователя (UI). Для первой «номинации» это: отсутствие несовместимости с 1.0.1 и с недавними бета-версиями Wine; небольшие ошиб-ки могут остаться не исправленными. Для второй «номина-ции»: повторение Platinum Regression Hunt [8]; обеспечение поддержки всем приложениям, которые поддерживаются Wine 1.0.1; изучение вопроса о поддержке новых версий данных приложений; обсуждение, каким из «больших при-ложений» необходимо добавить поддержку. Для послед-ней «номинации»: стандартизация методов упаковщиков для обеспечения совместимости с различными дистрибути-вами; необходимость проявления особого внимания к доку-ментации пользователя, а также по winelib накануне выхода релиза.

После стабилизации ветки 1.1.x (или выпуска 1.2) начнет-ся работа над новой нестабильной ветвью – 1.3.

В 2009 году проект Wine прошел большой и плодотвор-ный путь. Многое сделано для поддержки 64-битного ре-жима, работы с объектами OLE, поддержки библиотеки crypt32 (в том числе цифровых сертификатов), реализации Direct3D 10, работы со звуком, интеграции движка Gecko и поддержки других веб-технологий, локализации. В новой ветке – 1.2, разработчики обещают обеспечение 64-битной поддержки и других функций. Будет интересно узнать, ка-ким получится первый выпуск 1.2. Тем более что ждать оста-лось недолго – «несколько следующих месяцев».

1. http://ru.wikipedia.org/wiki/Альфа-композиция.2. http://wiki.winehq.org/WineConf2009.3. http://wiki.winehq.org/DIBEngine; http://bugs.winehq.org/show_bug.

cgi?id=421.4. http://wiki.winehq.org/MacOSX/QuartzDriver.5. http://wiki.winehq.org/USB; http://bugs.winehq.org/show_bug.

cgi?id=9649.6. http://wiki.winehq.org/Direct3D_Debugging.7. http://wiki.winehq.org/wineserver; http://bugs.winehq.org/show_

bug.cgi?id=11112.8. http://wiki.winehq.org/PlatinumRegressionHunt.

EOF


72

Визитка


Не секрет, что все современные технологии Интернета получили свою жизнь еще в 70-80-х годах. В то время раз-работчиков интересовала сама возможность, и никто осо-бо не рассчитывал на то, что Сеть станет общедоступной и разрастется до мировых масштабов, а подключаться к Ин-тернету можно будет с любой точки планеты.

В итоге практически во всех протоколах не была пред-усмотрена возможность защиты или повышения безопас-ности. Результат мы получили в виде спама, атак на ре-сурсы Сети путем подделки DNS-адресов и многих других проблем.

Сегодня изменить что-то глобально невозможно, слиш-ком много сил и средств необходимо потратить. Поэтому и проблемы пытаются решить при помощи разного рода надстроек над протоколами, расширений, использующих в качестве защиты стойкую криптографию. Для SMTP таким спасательным кругом является DKIM (DomainKeys Identified Mail) [1], для DNS – протокол DNSSEC.

Зачем нужен DNSSEC?Служба DNS, сопоставляющая IP-адреса именам доменов, по сути, является фундаментом Интернета. К ее услугам обращаются практически все остальные популярные сер-висы, предназначенные для отправки почты, веб-серфинга, VoIP, ICQ и так далее. Соответственно, если DNS выдает не-правильную информацию, это сказывается на работе любо-го сервиса, его запрашивающего.

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

Известны две возможные атаки на DNS как на сервис разрешения имен:

DDoS (Denial of Service) – атака на отказ в обслужи-вании, в результате которой сервер перестает отве-чать на запросы клиентов (это мы видели в октябре 2002 года, когда перестали отвечать 10 из 13 коренных серверов);

DNS Spoofing/DNS cache poisoning – атака, заключаю-щаяся в подмене действительной записи о соответствии имени и IP-адреса в кэше DNS-сервера ложной записью, в результате пользователь, набравший это имя, направ-ляется совсем по другому адресу.Признаю, что есть и другие атаки на DNS вроде man-in-

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

Универсального решения против DDOS-атаки на любой сервис нет, DNS здесь не является исключением. Защита строится на тех же принципах:

> повышаем;> увеличиваем;> фильтруем;> блокируем.Хотя у DNS есть одно существенное преимущество –

иерархическая структура, при которой информация не хранится в одном месте, а на многочисленных серве-рах и запрашивается по мере необходимости. Обращение к серверам верхнего уровня происходит только при отсут-ствии информации в текущем DNS-сервере. Кэширова-ние DNS-данных приводит к уменьшению числа запросов. В итоге, чтобы DDOS-атака действительно была эффектив-ной, необходимо, чтобы она затронула максимальное коли-чество серверов, в том числе 13 корневых, и действовала в течение продолжительного времени. А это далеко не так просто реализовать.

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

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

Практически 25 лет DNS-запросы не считались безопасными, но после внедрения DNSSEC на кор-невых серверах эта проблема будет решена

Спасительный протоколDNSSEC-расширение к DNS для повышения безопасности

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и четырех книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС



Кроме этого, злоумышленнику не нужно атаковать все DNS-серверы, достаточно взять на прицел только один.

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

Особенности DNSSECРасширение к протоколу DNS – DNSSEC (DNS Security Extensions) [2], разработанное одноименной группой, не мо-жет защитить от самой атаки, направленной на подмену адреса, но дает возможность обнаружить такую попытку и отклонить неправильные данные, обезопасив тем самым клиента.

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

Работа по улучшению DNS велась давно, первые упо-минания об этом датированы еще январем 1997 года в RFC 2065 (через 10 лет после принятия RFC 1034), в ко-тором были предложены два дополнительных поля DNS Security (DNSSEC, так раньше расшифровывалась аб-бревиатура). Затем в последующих RFC [3] эта идея раз-вивалась и уточнялась. Эксперименты по развертыванию DNSSEC по RFC 2535 показали, что имеется много нюансов, в основном в процедуре распространения ключевых дан-ных, что в итоге привело к появлению доработок, назван-ных – RFC 2535bis или DNSSECbis.

Сегодня актуальными/базовыми являются доработки, вы-шедшие в марте 2005 года:

RFC 4033 – DNS Security Introduction and Requirements – введение и общие условия;

RFC 4034 – Resource Records for the DNS Security Extensions – описания расширений в ресурсных записях DNS;RFC 4035 – Protocol Modifications for the DNS Security Extensions – изменения в протоколе DNS.Эти RFC заменили более ранние, в том числе и RFC 2535,

которые считаются уже устаревшими. Сами разработчики называют для технологии DNSSEC переломным 2004 год, когда на новые расширения обратили внимание в группе по IESG (Internet Engineering Steering Group, выработка ин-женерного регламента Интернета), которая следит за про-цессом стандартизации в Интернете.

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

Для этого администратор доменной зоны подписывает информацию о соответствии имен и IP-адресов, исполь-зуя свой закрытый ключ. Клиент (Security-Aware Resolver) вместе с адресом получает подписанную адресную инфор-мацию, которую он может проверить, используя открытый ключ администратора. Соответственно, если данные в по-лученном сообщении не соответствуют подписи, они отбра-сываются. Механизм подтверждения применяются только к данным по зоне и при подтверждении отсутствия DNS записей, но не предназначен для защиты таких операций, как перенос зон и динамические обновления.

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

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

DNSSEC дает возможность обнаружить попытку подмены адреса и отклонить неправиль-ные данные, обезопасив тем самым клиента



следить цепочку доверия к открытому ключу, начиная от са-мого верхнего сервера root/TLD к серверу, отвечающему за конкретную зону.

Очевидно, что данный подход требует поддержки DNSSEC в корневых серверах или хотя бы в TLD (top-level domain). Ведь при использовании DNSSEC в root-серверах клиенту потребуется знание единственного ключа для подтвержде-ния любых (в идеале) данных. Иначе потребуется импорти-ровать ключ для каждой зоны или отдельного домена.

В отсутствии поддержки DNSSEC корневой зоны и TLD допускается участие в подтверждении ключа третьей сторо-ны (look-aside). Это может быть необходимо при построении «островка безопасности» (в RFC – Island of Security), то есть автономно работающего DNS-сервера, поддерживающего DNSSEC и не завязанного на TLD (в котором не реализован DNSSEC) или другие серверы верхнего уровня. Чтобы упро-стить процедуру, было принято решение развернуть отдель-ную инфраструктуру, обеспечивающую централизованное хранение публичных ключей зон, и подтверждать любые зоны, не являющиеся дочерними. Такая структура описана в RFC 4431 и 5074, она получила название DLV (DNSSEC Lookaside Validation). Сейчас централизованная база под-держивается организацией ISC, хотя DLV может быть раз-вернута на любом DNS-сервере.

Кстати, наличие открытых ключей в DNS-записях позво-ляет использовать их и для других операций – SSH, элек-тронная почта и тому подобное.

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

DNSSEC предполагает подписывать не каждую отдель-ную запись, а все множество ресурсных записей (RRSet). Его внедрение потребовало внесения некоторых изменений в DNS-протокол, в частности в ресурсные DNS-записи:

RRSIG (Resource Record Signature) – цифровая подпись и связанная с ней информация (интервал времени, ал-горитм, тег для определения связанного DNSKEY и т.д.);DNSKEY (DNS Public Key) – открытый ключ, который ис-пользуется клиентом для проверки подписи;DS (Delegation Signer) – необязательное поле использу-ется в тех случаях, когда необходимо разрешить провер-ку подлинности открытых ключей дочерних зон для орга-низации цепочки доверия;DLV – похоже на предыдущий, но разрешает проверку подлинности для любых зон, в ней описанных;NSEC (Next Secure) – перечисление типов ресурсных за-писей, существующих в данном домене.Детально они рассмотрены в RFC 4034. Так, поле

DNSKEY содержит кроме самого ключа еще три записи – флаг (16 позиций, установленный в «1» 7-й бит означает, что запись содержит ключ DNS-зоны), протокол (только зна-чение 3) и алгоритм.

Список поддерживаемых алгоритмов дан в Appendix A.1 RFC 4034 – RSA/MD5, Diffie-Hellman, DSA/SHA-1, Elliptic Curve DSA (ECDSA) и RSA/SHA-1. Два поля помечены как Private

и позволяют при необходимости задействовать другие алго-ритмы в отдельных решениях.

Кроме этого, в настоящее время действителен RFC 5702, в котором добавлены алгоритмы RSA/SHA-256 и RSA/SHA-512. В результате DNSKEY может выглядеть так (цифра «5» на третьей позиции – RSA/SHA-1):

Запись RRSIG содержит большее количество полей:

По порядку – владелец, TTL, цифра «5» указывает на ал-горитм шифрования. Цифра «3» указывает на метку label (количество ресурсных записей, она используется для уточ-нения имени владельца). Например, root имеет label = 0, домен верхнего уровня – 1 и так далее. Следующее число (7200) описывает Original TTL, который определяет значе-ние времени жизни для подписанных ресурсных записей. За ним две даты – Signature Expiration и Signature Inception (время истечения и начала действия ключа, то есть период действия ключа 20091110090150, 20091103182315 13173). Далее следует тег (определяет хеш DNSKEY), FQDN ре-сурсной записи DNSKEY, которая должна использоваться для проверки подписи, и собственно сигнатура в Base64-кодировке.

Имеющиеся утилиты практически полностью автоматизи-руют создание DNSKEY- и RRSIG-записей, поэтому проблем здесь быть не должно.

Протокол DNSSEC потребовал новых полей в заголов-ке DNS-сообщения: Checking Disabled (CD) и Authenticated Data (AD). Кроме этого, задействуются механизмы расши-рений для DNS (EDNS0, RFC 2671), которые позволяют ис-пользовать UDP-пакеты свыше 512 байт, как это изначаль-но установлено в RFC 1035. Не следует увлекаться большой длиной ключей. Кроме дополнительной нагрузки на сервер, это может привести к увеличению результирующего UDP-пакета. Некоторые сетевые устройства могут не пропускать пакеты с длиной больше, чем 512 байт. Учитывая возможные потери фрагментов, разработчики не рекомендуют превы-шать этот «лимит».

Как видно, ключи должны периодически обновляться и зоны переподписываться. Чтобы упростить эти операции, рекомендовано (именно рекомендовано, но не обязательно) использовать два ключа – KSK (Key Signing Key) и ZSK (Zone Signing Key).

Ключ KSK используется для подписывания ресурсных за-писей зоны (DNSKEY), в родительской зоне (запись DS) при аутентифицированном делегировании открытая часть KSK передается клиенту.

Ключ ZSK используется для подписывания всего множе-ства ресурсных записей в зоне и подписывания DS. Такая схема рекомендована с целью ускорения процесса про-верки подписей DNS, так как размер ZSK-ключей выбирают меньше, чем KSK.

При создании KSK следует исходить из требований безо-пасности, производительность играет меньшую роль, по-этому здесь рекомендована большая длина ключа. Менять KSK следует один раз в год, ZSK чаще, можно ежемесячно.

host.example.com. 7200 IN RRSIG A 5 3 7200 20091110090150 ( 20091103182315 13173 example.com.raR/8vMh37yX…..6LOsE1TqzqPJ # Сигнатура в Base64)

example.com. 7200 IN DNSKEY 256 3 5 (открытый ключ)



Здесь виден еще один минус DNSSEC – периодически ключи меняются, а администраторы подчиненных серверов должны отслеживать их смену, иначе в один прекрасный день DNS-сервер не сможет разрешать адреса.

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

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

Действительный переход начат только в 2008 году, ког-да были переведены TLD-домены, обслуживающие зоны ORG и NET. Постепенно к этому списку начали добавляться и другие зоны – SE, PR, BG, CZ и так далее. О начале подго-товки к переходу зоны EDU объявлено в сентябре 2009 года. РосНИИРОС заявил, что технически все готово к перево-ду на DNSSEC-зоны RU. По сообщению Internetnews.com, к октябрю 2009 года расширение DNSSEC активировано на 15 TLD. Полная поддержка технологии DNSSEC в корне-вой зоне системы DNS будет введена с 1 июля 2010 года (вначале был заявлен другой срок – конец 2008 [4]). Закры-тое тестирование началось с 1 декабря 2009 года, а с января 2010 года – поэтапный переход к полному использованию. Пока этого нет, необходимо вносить ключи для каждого до-мена верхнего уровня. По сообщению компании VeriSign, к 2011 году все доменные зоны, администрированием ко-торых она занимается (cc, tv, com, net), будут переведены на DNSSEC. Учитывая размеры зоны com, она планируется к переводу последней.

Просмотреть наличие соответствующих записей можно при помощи утилиты dig (или drill из состава ldns). Напри-мер, запрос к зоне SE сразу выводит наличие соответству-ющих записей (см. рисунок):

Кроме этого, о поддержке технологии говорит и установ-ленный флаг ad в ответе, полученном при помощи dig. На-пример, получим ключ одного из серверов:

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

В зоне RU серверы с поддержкой DNSSEC встречаются крайне редко.

С технической стороны также не все было готово. Ис-пользование DNSSEC требует поддержки нового расшире-ния с обеих сторон: сервера (Security-Aware Name Server) и клиента (Security-Aware Resolver).

Поддержка DNSSEC в самом популярном DNS-сервере BIND включена еще в 2004 году в версии 9.3 (напомню, что BIND доступен как для UNIX, так и для Windows). Но-вую версию BIND 9.7 разработчики называют не иначе как DNSSEC Usability release.

Тогда же, в 2004 году, появилась эксперименталь-ная поддержка нового расширения в NSD (Name Server Daemon) [5] (собирается с --enable-dnssec), заявлена под-держка в PowerDNS, Unbound и в некоторых других DNS-серверах [6].

С клиентским ПО дело обстоит немного хуже. Очевидно, отсутствие DNSSEC на DNS-серверах сказалось на том, что клиентское ПО в этом направлении практически не раз-вивалось.

В ОС от Microsoft данная спецификация уже поддержива-ется. В Windows Server 2008 (RFC 2535), а в новых – Windows 7 и Windows Server 2008 R2 (RFC 4033, 4034, 4035) [7]. Более ранние версии Windows Server 2003 и Windows XP имели ба-зовую поддержку RFC 2535, которая состояла в том, что они принимали подписанный пакет, но больше никаких действий с ним не производили. Сервер DNS на Windows Server 2003 может выступать как secondary DNS, работающий совмест-но с DNSSEC-совместимым сервером (с оговоркой выше).

Однозначного утверждения о том, что штатный DNS-клиент в Linux и других UNIX-системах поддерживает рас-ширение DNSSEC и обрабатывает их, найти не удалось. Эксперименты с tcpdump показывают, что в некоторых слу-чаях отправляются дополнительные DNS-запросы, в дру-гих – нет. Поэтому лучшей рекомендацией пока является ак-тивация DNSSEC на DNS-сервере организации/провайдера, а клиенты будут получать с него уже проверенную инфор-

$ dig +retry=1 +dnssec +multiline +trace se

Eagle.roysdon.net IN SSHFP 1 1 37c2af30b0083602254fb0c5780a0de9e15231bf

; <<>> DiG 9.4.2 <<>> +adflag SSHFP Eagle.roysdon.net. @atlt-dnssec-trial.s3woodstock.ga.atlanta.comcast.net. ;; global options: printcmd;; Got answer:

$ ssh-keygen -r Eagle.roysdon.net ↵ -f /etc/ssh/ssh_host_rsa_key

$ dig +adflag SSHFP Eagle.roysdon.net. ↵ @atlt-dnssec-trial.s3woodstock.ga.atlanta.comcast.net.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64778 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

Ответ сервера поддерживающего DNSSEC



мацию. Провести атаку на подмену IP-адреса в отношении единичного компьютера достаточно проблематично, здесь проще пойти другим путем (подложное письмо, вирус и т.п.). Соответственно если бизнес завязан на Интернет, то пла-нировать перевод своих серверов на DNSSEC или подпись DNS-данных нужно уже сейчас.

Здесь хочется отметить проект DNSSEC-Tools [8], кото-рый предлагает специализированное расширение к веб-браузеру Firefox, почтовому клиенту Thunderbird, SMTP-серверам Sendmail и Postfix, FTP-серверам proftpd, ncftp, Jabber-серверу jabberd, OpenSSH, позволяющее добавить поддержку DNSSEC в эти приложения, а также ряд вспомо-гательных утилит, патч к logwatch, библиотеки libsres и libval. Правда, готовых сборок, в которых присутствует этот патч, не представлено, поэтому тот же Firefox необходимо пере-компилировать самостоятельно.

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

Настройка BIND в режиме кэширующего/ неавторитативного DNS-сервераДля начала заставим BIND проверять полученные с опреде-ленной зоны данные, клиенты, которые будут использовать этот DNS-сервер, будут защищены от подмены. Примеры покажу на основе Ubuntu. Устанавливаем BIND.

При самостоятельной сборке BIND необходимо активи-ровать флаг --with-openssl.

После установки в /etc/bind/named.conf (в Ubuntu секция options вынесена в named.conf.options) добавляем следую-щие параметры:

Далее необходимо сконфигурировать доверенные якоря (trust anchor) для тех зон/доменов, которые будут проверять-ся. Узнать нужный публичный ключ можно разными спосо-бами. Самый простой – получить при помощи dig из DNS (как это показано выше), но в этом случае нужно четко знать, что ключ принадлежит именно тому, кому нужно. Про-верить полученный ключ можно, зайдя на один из сайтов зоны. Сегодня также доступны специальные сервисы, в ко-торых администраторы размещают trust anchor своих доме-нов [9].

Далее заносим анкоры в файл в секцию trusted-keys фай-ла named.conf:

Принцип, думаю, понятен. DLV-записи создаются анало-гичным образом (в options требуется dnssec-lookaside).

Для удобства отслеживания запросов можно создать от-дельный канал для протоколирования запросов DNSSEC:

Переконфигурируем BIND:

И проверяем запрос:

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

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

И так далее.

Настройка BIND в режиме «Мастер сервера»Чтобы настроить любой DNS сервер в качестве мастер сер-вера, отвечающего за зону, необходимо пройти несколько шагов:

> сгенерировать ZSC и KSK;> прописать ключи в файл зоны;> подписать зону.Для создания ключей и подписи зоны используются ути-

литы, входящие в состав BIND, хотя доступны уже решения сторонних разработчиков, но о них в конце статьи. Ключе-вая пара генерируется при помощи dnssec-keygen. Общий формат вызова ее прост:

Все параметры понятны, за исключением типа ключа. Их несколько. В контексте статьи нас интересуют ZONE илиHOST, с остальными можно ознакомиться на man-странице.

Создаем ZSC:

$ sudo apt-get install bind9

> dig @127.0.0.1 4x4.org +retry=1 +dnssec +multiline

dnssec-keygen –a алгоритм –b длина –n тип имя_домена

options { dnssec-enable yes; # Активируется поддержка DNSSEC # Включается только для неавторитативного сервера dnssec-validation yes; };

options { dnssec-lookaside . trust-anchor dlv.isc.org.; };

zone "se." { type forward; forwarders { 212.247.7.228; }; };

trusted-keys { # зона se "se." 257 3 54w6RVY0ciZ/a8t1xy5FIxkg2U95ZV5VuLtwmx2rgtAbx BACzTKrqYIpJ6LYSmjdQ3or+ZiO2tEMr53EwAjA6GKrf qQ2S1y7Rblz2kaS6PK2Gh5MOCufhGozUhPQSGFTn/mV8 H9hlQptfcFCpFZrQQDAQqFAyxQginDgrwSripBk=

Nov 5 21:41:35 ubuntu named[32464]: /etc/bind/ named.conf:47: trusted key 'ru.' has a weak exponentNov 5 21:43:53 ubuntu named[32464]: not insecure resolving 'samag.ru/A/IN': 89.253.192.21#53

logging { channel dnssec_log { file "log/dnssec" size 20m; print-time yes; print-category yes; print-severity yes; severity debug 3; }; category dnssec { dnssec_log; }; }

$ sudo rndc reconfig $ sudo rndc flush

# Далее аналогично добавляются ключи и для других зон, # например для 4x4.org"4x4.org" 256 3 5 "BEAAAAOxYIG/de/sEWGkMlMw/+WZHw72QMNAdC bneozk4BU4OCAbv9krBFnk52CZ67QPEfDMwV0k12Hr6sXkgZgeBpRV"; };

$ dnssec-keygen –a RSASHA1 –b 1024 –n ZONE example.com



В некоторых дистрибутивах необходимо задать устрой-ство, которое будет участвовать в выработке ключа -r /dev/ random. В результате получим два вида файла:

Kdomain+<alg>+<fing>.key – открытый ключ; Kdomain +<alg>+<fing>.private – закрытый ключ.В нашем примере это Kexample.com.+004+10141.key

и Kexample.com.+004+10141.private.KSK-ключ создается аналогично:

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

Как вариант ключи можно подключить в файле зоны при помощи параметра $include.

Теперь необходимо подписать зону, добавить RRSIG, NSEC и другие ассоциированные записи. Для этого вызыва-ется утилита dnssecsignzone (общий вид):

Пример:

В результате на выходе получим файл зоны – db.example. com.signed, в котором ресурсные записи будут рассортиро-ваны по алфавиту, а записи – содержать необходимые поля RRSIG, NSEC и DNSKEY.

Осталось добавить описание новой зоны в named.conf:

Это все. Не забываем активировать параметр dnssec-enable в named.conf.

К слову, в RedHat/Fedora доступны утилиты: командная dnssec-configure и графическая system-config-dnssec, упро-щающие настройку DNSSEC в BIND. Особых чудес, правда, они не делают, просто добавляют нужные строки в секцию options файла named.conf.

Например, проверим статус DNSSEC:

Ряд проектов DNSSEC-tools, OpenDNSSEC [10] и Autotrust от NLnet Labs [11], DICI Tools от RIPE NCC [12], DNSSEC-monitor [13] предлагают различные инструменты для более удобного управления зонами, наблюдения за DNSSEC-зонами, обновления якорей и так далее. Например, утилита maketestzone, входящая в состав DNSSEC-tools. позволя-ет одной командой создать весь набор файлов для тесто-вой зоны.

***Итак, процесс выхода в массы DNSSEC начался. Как мы ви-дим, во внедрении DNSSEC не все так однозначно, админи-страторам как минимум добавится работы, ведь теперь при-дется заботиться об актуальности ключевой информации. Это признают и сами разработчики. Надеемся, что к тому времени, когда поддержка этой технологии будет внедрена в корневых серверах и TLD, многие вопросы по управлению будут решены.

1. Яремчук С. Технология борьбы со спамом DKIM. //Системный администратор, №11, 2008 г. – С. 37-41.

2. Сайт DNSSEC – http://www.dnssec-deployment.org, российский – http://www.dnssec.ru.

3. Связанные RFC – http://www.dnssec.net/rfc.4. Заявление ICANN о переводе корневых серверов на DNSSEC

– http://www.icann.org/en/announcements/announcement-24jul08-en.htm.

5. Сайт проекта NSD – http://www.nlnetlabs.nl/projects/nsd.6. Comparison of DNS server software – http://en.wikipedia.org/wiki/

Comparison_of_DNS_server_software.7. DNS Security Extensions (DNSSEC) в Windows 2008 R2

и Windows 7 – http://technet.microsoft.com/en-us/library/ ee683904%28WS.10%29.aspx.

8. Сайт проекта DNSSEC-tools – http://www.dnssec-tools.org, http://dnssec-tools.sourceforge.net.

9. Доверенные анкоры сайтов – https://www.ripe.net/projects/disi/keys, http://secspider.cs.ucla.edu/trust-anchors.conf, https://www. iks-jena.de/leistungen/dnssec.php, https//itar.iana.org/.DNSSEC-tools; на Java – http://www.verisignlabs.com/dnssec-tools.

10. Сайт проекта OpenDNSSEC – http://www.opendnssec.org.11. Сайт Autotrust от NLnet Labs – http://www.nlnetlabs.nl/projects/

autotrust.12. DICI (Deployment of Internet Security Infrastructures) Tools от RIPE

NCC – https://www.ripe.net/projects/disi/code.html.13. Сайт проекта DNSSEC-monitor – http://opensource.iis.se/trac/

dnssec/wiki/DNSSEC-monitor.14. Сайт проекта java-dnssec-tools – http://www.verisignlabs.com/

dnssec-tools.

dnssecsignzone [o zonename] [N INCREMENT] [k KSK.key] ↵ zonefile [ZSK.key]

Kexample.com.+004+34980.key Kexample.com.+004+34980.private

$ dnssec-keygen –r /dev/random -a RSASHA1 –b 1024 -n ZONE ↵ -f KSK example.com

example.com. IN KEY 256 3 5 bzA2wu … U1asmQg==

$ cat Kexample.com +*.key >> /etc/bind/zones/db.example.com

$ dnssecsignzone o example.com k Kexample.com.+004+34980 ↵ /etc/bind/zones/db.example.com Kexample.com.+004+10141

zone "example.com" { type master; file "/etc/bind/zones/db.example.com "; };

Bind DNSSEC:enabled Bind DLV:disabled

# dnssec-configure -s -b

$ maketestzone example.com

$ cat Kexample.com+004+10141.key

EOF


78

Визитка


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

Антивирусных решений для защиты крупного и средне-го бизнеса на российском рынке представлено в избыт-ке. Есть известные зарубежные разработки от компаний McAfee, Trend Micro, Symantec, есть и решения российских разработчиков, ни в чем не уступающие и даже превосхо-дящие их. Об одном из таких решений – Dr.Web Enterprise Suite (Dr.Web ES) – мы и расскажем в этой статье. Более того, постараемся показать, насколько это возможно на бу-маге, как этот антивирусный комплекс действует в полевых условиях.

Dr.Web Enterprise Suite – уникальное программное реше-ние со встроенной системой централизованного управле-ния антивирусной защитой рабочих станций и файловых серверов Windows на предприятиях любого масштаба. Причем «любого» здесь следует понимать буквально – раз-работку используют и предприятия с десятками тысяч ком-

пьютеров, и небольшие компании с 50 рабочими станциями и одним сервером.

Компания «Доктор Веб» начала работать над Dr.Web Enterprise Suite еще в 2002 году, когда перед программи-стами была поставлена задача создать антивирусное ПО, способное обеспечить централизованное управление безо-пасностью в государственной автоматизированной системе (ГАС) «Выборы» (Dr.Web специальная версия ES работает и по сей день). Управление производится в Центральной избирательной комиссии РФ, а защищаемые станции на-ходятся в региональных офисах ГАС «Выборы», количество которых исчисляется тысячами.

Выпуск коммерческого варианта Dr.Web ES состоялся в середине 2005 года. До начала 2009 года версия реше-ния имела номер 4.44. Однако уже в мае «Доктор Веб» вы-пустила версию 5.0, на основных особенностях которой мы остановимся подробнее.

Важнейшим преимуществом новой версии Dr.Web ES 5.0 стало обновленное антивирусное ядро, позволившее зна-чительно снизить нагрузку на систему и увеличить быстро-действие антивирусного сканера на 30 %. В обновленном ядре также реализованы новые технологии борьбы с рут-китами и возможность работы с еще большим количеством архивов и упаковщиков, в том числе неизвестных для анти-вируса сегодня. Пятая версия Dr.Web ES имеет новые моду-ли – веб-антивирус SpIDer Gate, отвечающий за блокиров-ку угроз из сети Интернет, компонент самозащиты Dr.Web SelfPROtect, препятствующий антиантивирусным програм-мам вывести Dr.Web из строя, и модуль Офисного контро-ля, который блокирует сотрудникам компаний возможность посещения нежелательных, с точки зрения администрации, сайтов. Кроме того, появился веб-интерфейс администрато-ра, позволяющий сотруднику и с начальной квалификацией управлять системой, причем даже извне защищаемой сети. Таким образом, привлекательность для внедрения Dr.Web ES на предприятиях существенно повысилась.

Один из примеров, который мы рассмотрим в этой ста-тье, – внедрение и использование Dr.Web ES в компании «Югавиа». Это одно из крупнейших российских предпри-

При информатизации предприятий обеспечение за-щиты информационных систем выходит на первое место. Причины объективны

Dr.Web ES в полевых условияхКак защитить бизнес от вирусов?

ВАЛЕРИЙ ЛЕДОВСКОЙ, аналитик компании «Доктор Веб»

Административный интерфейс



ятий в сфере организации перевозок, которое работает на рынке авиационных услуг более сорока лет.

Руководство ИТ-департамента «Югавиа», не раз сталки-ваясь со сбоями в работе сети по причине вирусных атак, ясно сознавало острую необходимость в комплексной системе антивирусной защиты рабочих станций. При этом были выдвинуты следующие требования: способность обе-зопасить компанию от рисков отказа/простоя в работе обо-рудования (в результате вирусных атак); лёгкое управление всеми компонентами антивирусной защиты из единой консоли; поддерж-ка широкого спектра операционных систем (в том числе ранних версий ОС Microsoft Windows).

Для решения данных задач был вы-бран именно Dr.Web Enterprise Suite, который полностью соответствовал заявленным требованиям. «Данный продукт легок в установке, настройке и управлении, при этом он надежен и отвечает всем требо-ваниям клиента, – говорит Максим Пух, менеджер по про-дукции Центра информационной безопасности Softline, ком-пании, которая осуществляла поставку «Югавиа» решения Dr.Web ES. – Проблемы, связанные со скоростью доступа в Интернет, решаются за счет компрессии, объем сигнатур-ных баз Dr.Web ES невелик по сравнению с аналогичными решениями, это дает экономию на трафике».

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

Начальник отдела ИТ «Югавиа» Дмитрий Ремезов от-мечает, что проект был рассчитан на защиту уже суще-ствующего оборудования. «Выбранное решение должно было поддерживать в том числе и системы Windows 95 и 98, и соответствовать имеющимся мощностям, проще говоря, не нагружать систему. Нам нужно было решение, простое в установке и управлении и в то же время надёжное, хорошо зарекомендовавшее себя. Выбор пал именно на Dr.Web ES, поскольку функциональность данного продукта нас полно-стью устраивала. Более того, сотрудники компании уже име-ли положительный опыт использования данного продукта для защиты файловых серверов».

Другой пример – внедрение Dr.Web ES компанией «БазэлЦемент-Пикалево», производителем строитель-ных материалов высокого качества. Ранее в сети данного предприятия функционировала система защиты, которая заметно снижала производительность рабочих станций. Кроме того, возможности эксплуатации решения на ПК разных конфигураций и с разными операционными систе-мами были сильно ограничены. Поскольку корпоративная сеть предприятия насчитывает более четырёхсот рабочих станций, порядка 20% из которых работают под управле-нием Microsoft Windows 95/98/MЕ, этот недостаток оказался одним из ключевых для принятия решения о перестройке

системы безопасности. Проанализировав ситуацию, руко-водство предприятия поставило своим ИТ-специалистам задачу внедрить другое решение, отвечающее следующим критериям:

> защита рабочих станций, работающих под разными ОС;> всесторонний и полный контроль, а также удобное

управление настройками системы безопасности;> минимальное влияние на производительность;> оптимальная стоимость.

ИТ-специалисты «БазэлЦемента» тщательно изучили возможности продуктов, представленных на российском рынке, и выбрали комплексное решение Dr.Web Enterprise Suite, как наиболее приемлемое по соотношениям цена/воз-можности и цена/качество.

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

«Документация Dr.Web ES выполнена на высоком уров-не, поэтому установка и настройка продукта доступны даже не очень продвинутым пользователям», – отмечает началь-ник отдела АСУ «БазэлЦемента» Владимир Смирнов. EOF

Пятая версия Dr.Web ES имеет новые модули – веб-антивирус SpIDer Gate и компонент самозащиты Dr.Web SelfPROtect

Схема работы DrWeb Enterprise Suite


80

Визитка


Проекты с открытым кодом рождаются по-разному. Одни возникают стихийно из доморощенных разработок, призван-ных решать конкретную, сугубо прикладную задачу, быстро перерастающих эти узкие рамки. Другие изначально заду-мываются и тщательно планируются как открытые, а третьи переводятся в разряд открытых уже на стадии стабильных продуктов. Так или иначе, но перед любым новорожденным открытым проектом стоит вопрос хостинга, предоставляю-щего нужные для его разработки, поддержки и распростра-нения средства. Эта статья посвящена хостингу SourceForge (http://sourceforge.net), который является самой популярной площадкой для разработки открытого программного обес-печения. Я коснусь его наиболее востребованных возмож-ностей и опишу некоторые нетривиальные моменты, кото-рые часто ставят в тупик начинающих пользователей.

История и возможности SourceForgeSourceForge был основан в 1999 году компанией VA Software, которая с тех пор успела дважды поменять на-звание: сначала на SourceForge в 2004 году, а затем на Geeknet. Совсем недавно, в 2009 году, Geeknet объединила ресурсы SourceForge, Slashdot, ThinkGeek и freshmeat.net и, таким образом, сейчас является крупнейшей сетью сай-тов, посвященных свободному ПО. Сегодня SourceForge – это огромный централизованный репозитарий открытых исходных кодов. По данным на февраль 2009 года, на SourceForge было зарегистрировано более 230 тысяч про-ектов (не все из них, конечно, активны) и более двух мил-лионов пользователей.

Для обычного пользователя SourceForge – это колоссаль-ная структурированная база данных свободного ПО с воз-можностью удобного поиска (см. рис. 1). Любую программу можно скачать с ближайшего из многих зеркал, разбросан-ных по всему миру. За полюбившуюся программу можно проголосовать или сделать денежное пожертвование ее ав-торам. Можно и поучаствовать в ее разработке, отправляя сообщения об ошибках или занимаясь локализацией.

Что же предлагает SourceForge для разработчиков ПО с открытым кодом?

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

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

Репозитарий исходного кода проекта. Поддерживают-ся практически все популярные системы контроля вер-сий – Subversion, Git, Mercurial, Bazaar и CVS.Система для создания и управления релизами, кото-рые сразу же будут доступны конечным пользовате-лям для скачивания через разветвленную всемирную сеть зеркал. Для создания релизов можно использовать веб-интерфейс, scp, rsync и sftp.Веб-сайт проекта с полной поддержкой PHP, Perl, Python, Tcl, Ruby и MySQL.Система сбора информации об ошибках (bug tracker) на основе Trac (http://trac.edgewall.org) или MantisBT (http://www.mantisbt.org).Статистика скачиваний, изменений исходного кода, сообщений об ошибках и т.д. Статистика является от-крытой и доступной для всех, но для администраторов проектов имеются дополнительные возможности.Модуль веб-аналитики, базирующийся на Piwik (http:// piwik.org). Позволяет отслеживать число посетителей, время их пребывания на сайте проекта, тип браузера, по-исковые системы, приведшие на сайт, и использованные в них ключевые слова, сайт, откуда «пришли» пользова-тели, изменения посещаемости во времени.Гостевая книга на основе AN Guestbook (http://aguestbook.sourceforge.net).Просмотр исходного кода проекта через браузер на основе Codestriker (http://codestriker.sourceforge.net) с интеграцией в системы контроля версий CVS и Subversion.Галерея рисунков (например, для скриншотов).Создание блогов разработчиков на основе WordPress (http://wordpress.org) и микроблогов на основе Laconica (http://laconi.ca).Вики на основе MediaWiki (http://www.mediawiki.org). Форум на основе phpBB (http://www.phpbb.com).

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

SourceForgeКузница проектов с открытым кодом

СЕМЕН ЕСИЛЕВСКИЙ, научный сотрудник, вычислительный программист и энтузиаст Linux и Open Source. Кандидат физико-математических наук, работает в области теоретической биофизики и молекулярного моделирования



Списки рассылки для проекта на основе GNU Mailman 2.1 (http://www.gnu.org/software/mailman) с гибкой настройкой, фильтрацией, автоматическим созданием архивов, поиском по архиву, спам-фильтром.Система публикации новостей проекта с возможно-стью автоматического создания тем на форуме и под-держкой RSS.Любая программа, помещенная на SourceForge, долж-

на распространяться по свободной лицензии. На выбор предлагаются все возможные варианты таких лицензий, начиная от обычной GPL и заканчивая такой «экзотикой», как Motosoto License или OCLС Research Public License. Это ограничение, а также полностью открытые для чтения репозитарии кода сужают число проектов, которые потен-циально могут размещаться на SourceForge. Например, этот хостинг не подходит для свободно распространяемых про-грамм с закрытым кодом.

Регистрация и создание проектаИтак, что же нужно, для того чтобы создать новый проект на SourceForge? В первую очередь зарегистрировать свою учетную запись. Процедура стандартная, требует наличия e-mail адреса и ничем особенным не выделяется. Если у вас уже имеется учетная запись Google, Yahoo, LiveJournal, Flickr, Blogger или других сайтов, поддерживающих иденти-фикацию по OpenID, то можно не регистрироваться, а ис-пользовать ваш OpenID.

После входа на сайт мы видим несколько пунктов меню (в виде «вкладок»), которые позволяют настроить разнооб-разные сервисы SourceForge. Нужно сказать, что в размеще-нии настроек логика просматривается не всегда, но в случае с регистрацией все логично. На странице Projects находим искомую ссылку Register a new project. Для создания про-екта нужно указать его название, уникальное имя (только прописные латинские буквы без пробелов), и короткое опи-сание. Как правило, проект становится активным уже через несколько минут после регистрации и появляется в списке на вкладке Projects. Создатель проекта автоматически становит-ся его администратором с максимальными правами доступа.

Описание и категоризация проектаДалее нужно заполнить страницу свойств новорожденного проекта (см. рис. 2) важной информацией, которая позво-лит пользователям и потенциальным разработчикам найти его среди множества других. Необязательно сразу запол-нять все разделы описания, но чем больше информации, тем в конечном счете лучше для проекта. Нужно заметить, что ссылки Edit в каждом разделе на странице описания не всегда позволяют напрямую редактировать всю инфор-мацию из этого раздела. Поля редактирования для описа-ния и категоризации проекта разбросаны по нескольким большим формам, которые только приблизительно соот-ветствуют по структуре самой странице описания. Это за-частую сильно сбивает с толку. Описание включает:

> эмблему (в виде изображения 48х48), название, краткое описание (до 250 слов) и стадию разработки (послед-няя почему-то редактируется совсем в другом блоке);

> произвольные теги для поиска;> список возможностей программы;> область знаний, к которой относится проект, операци-

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

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

Добавление участников проектаSourceForge может быть очень полезен даже для проектов с единственным разработчиком, но полностью его возмож-ности раскрываются в коллективных проектах. На странице Project Admin → Membership находится список всех участ-ников проекта. В новом проекте там находится только его создатель. В проект можно добавить любого зарегистриро-ванного на SourceForge пользователя. После добавления для любого участника можно указать права доступа к веб-

SourceForge является самой популярной площадкой для раз-работки открытого программно-го обеспечения



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

SourceForge также позволяет искать разработчиков, по-тенциально заинтересованных в работе над вашим проек-том. На странице Project Admin → Feature Settings имеется сервис Help wanted, позволяющий заполнить специальную заявку на помощь в разработке проекта. В заявке указы-вается, кто именно вам необходим (программист, перевод-чик, тестер), какими навыками и в каком объеме он должен обладать. На такие объявления, как правило, откликаются школьники и студенты, особенно часто летом, во время ка-никул. Шансы найти таким способом действительно грамот-ного разработчика невелики.

Консоль сервераSourceForge предоставляет удаленный доступ к консоли своего сервера (shell service). Из консоли можно работать с веб-сайтом проекта, загружать файлы для релизов, ад-министрировать репозитарии кода и базы данных MySQL. Доступ к серверной консоли настраивается отдельно для каждого участника проекта на странице Project Admin → Membership. Чтобы создать новую консоль, для пользовате-ля USER-проекта PROJECT достаточно выполнить следую-щую команду:

Процесс создания консоли занимает, как правило, около минуты и сопровождается такими сообщениями:

Будучи созданной, консоль доступна в течение четы-рех часов (после чего ее нужно создавать заново). Коман-да sf-help вместе с различной информацией выдает прямой адрес и порт для доступа в течение этого времени, например:

Если нужно просто загрузить файлы на сервер (на-пример, для веб-сайта), то можно и не создавать консоль, а использовать прямой доступ через USER,PROJECT@web. sourceforge.net. Файлы в дереве репозитария кода в этом случае недоступны.

Работа с репозитарием кодаДля определенности будем считать, что наш проект ис-пользует систему контроля версий Subversion, хотя можно использовать и любую другую (Git, CVS, Mercurial). На стра-нице Project Admin → Feature Settings включаем поддержку Subversion, создается репозитарий для нашего проекта. Ре-позитарий открыт для чтения для всех (в том числе и для анонимного доступа). Закрыть доступ для чтения невозмож-но. Права записи нужно настраивать для каждого участника проекта отдельно на странице Project Admin → Membership. Более тонкой настройки прав доступа пока не предусмотре-но, но проходит голосование пользователей для добавления такой функции. Адрес репозитария для проекта PROJECT – https://PROJECT.svn.sourceforge.net/svnroot/PROJECT.

Рисунок 1. Основная страница сайта SourceForge Рисунок 2. Страница свойств проекта

ssh -t USER,[email protected] create

USER,[email protected]'s password:

Requesting a new shell for "USER" and waiting for it to start. queued... starting...

...For direct access to this shell, use shell2.sourceforge.net on port 22002: ssh -p 22002 [email protected] ...

This is an interactive shell created for user USER,PROJECT. Use the "timeleft" command to see how much time remains before shutdown. Use the "shutdown" command to destroy the shell before the time limit. For path information and login help, type "sf-help".



Подробно останавливаться на деталях работы с Subversion в этой статье не имеет смысла. В Сети есть множество хоро-ших учебников по этому вопросу (например, http://svnbook. red-bean.com).

Для тех операций с репозитарием, которые невозмож-но выполнить удаленно через svn-клиент, предусмотрена команда adminrepo в консоли сервера. Типичный сеанс ра-боты с adminrepo выглядит так. Сначала создается полная копия репозитария в директории /svnroot/PROJECT, а доступ к самому репозитарию полностью блокируется:

Теперь с копией, находящейся в /svnroot/PROJECT, мож-но производить любые манипуляции. Например, можно пол-ностью очистить репозитарий и создать его с нуля:

После того как все нужные манипуляции выполнены, ста-рый блокированный репозитарий заменяется отредактиро-ванной копией:

Блокировка при этом снимается. Перед тем как присту-пать к любым рискованным операциям с репозитарием, сто-ит создать его резервную копию (консоль сервера для этого не нужна):

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

фортно чувствует себя с командами Subversion. Для него гораздо удобнее скачать последний стабильный релиз про-граммы. Управление релизами в SourceForge происходит либо через вполне интуитивный веб-интерфейс (Project Admin → File Manager), либо через scp, sftp или rsync. Каж-дый релиз – это просто отдельная директория. Логическая структура дерева релизов полностью определяется разра-ботчиками, а не навязывается хостингом. Глубина дерева, как и размер файлов релизов, не ограничивается.

Нужно иметь в виду, что при доступе по scp или sftp пол-ный путь к корневой директории проекта определяется по следующей схеме «первая буква названия/две первые буквы названия». Например, для проекта myproject и поль-зователя user:

Аббревиатура FRS означает file release system.Дерево релизов каждого проекта автоматически син-

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

Сайт проектаSourceForge дает прекрасные возможности для создания веб-сайта проекта (а также для разработки открытых проек-тов, полностью основанных на WEB). Предоставляется стан-дартный сервер на базе CentOS 5.x Linux и Apache 2.2.x. Поддерживаются PHP со всеми основными модулями, Perl, Python, Tcl, Ruby и MySQL 5.x, с централизованно установ-ленным phpMyAdmin.

Доступ к файлам веб-сайта проекта осуществляется че-рез сервер web.sourceforge.net. Например:

Рисунок 4. Страница Project Database (MySQL) ManageРисунок 3. Главная страница сайта проекта по умолчанию

adminrepo --checkout svn

adminrepo --save svn

rsync -av PROJECT.svn.sourceforge.net::svn/PROJECT/*

scp file.zip user,[email protected]:/home/ ↵ frs/project/m/my/myproject/Rel_1

svnadmin create /svnroot/PROJECT

rm -rf /svnroot/PROJECT/*



При этом файлы физически попадают в директорию /home/groups/m/my/myproject/htdocs/. «Внешний» адрес сайта проекта myproject – http://myproject.sourceforge.net. По умолчанию главная страница сайта проекта формиру-ется автоматически (см. рис. 3), но ее, естественно, можно заменить на свою.

Доступ к MySQL, как правило, уже активирован изначаль-но, но иногда необходимо сделать это вручную. Для этого на странице Project Admin → Feature Settings нужно вклю-чить опцию Project Database (MySQL).

Работа с MySQL на SourceForge имеет несколько нюан-сов. Имя сервера MySQL для каждого проекта формирует-ся исходя из первой буквы его имени. Например, для про-екта myproject полное имя сервера mysql-m.sourceforge.net. Для доступа «изнутри» (из веб-директории самого проекта) достаточно указывать просто mysql-m. Имена баз данных так-же специфичны для каждого проекта, чтобы избежать пута-ницы. Базы данных имеют уникальный суффикс, состоящий из первой буквы имени проекта и идентификатора GROUP ID, которые вместе представляют уникальную комбинацию.

Узнать GROUP ID для проекта не так просто, как это должно быть по логике вещей. Для этого нужно зайти на страницу Summary и щелкнуть на Edit в блоке с названи-ем проекта. На открывшейся странице переходим по ссыл-ке Registration и наконец видим искомый идентификатор среди другой служебной информации (GROUP ID также по-является как последний параметр в адресной строке брау-зера после щелчка на Edit). Предположим, GROUP ID про-екта myproject – 123456, тогда все базы данных для этого проекта будут иметь префикс «m123456 _».

По умолчанию для каждого проекта создаются три поль-зователя сервера MySQL с разными правами доступа. В на-шем примере это m123456ro с доступом только для чтения (разрешены только запросы SELECT), m123456rw с правами доступа для чтения и записи (разрешены запросы SELECT, INSERT, DELETE, UPDATE) и m123456admin с полными пра-вами администратора.

Альтернативный путь – открыть страницу Project Admin → Feature Settings → Project Database (MySQL) Manage (см. рис. 4) где явно отображены имя базы данных и пре-фиксы таблиц. Там же можно задать пароли для пользовате-лей базы данных и найти прямые ссылки на документацию.

Для всех задач, связанных с администрированием баз данных проекта, можно использовать либо phpMyAdmin (доступен по адресу https://mysql-LETTER.sourceforge.net), либо серверную консоль. Например, так можно создать ре-зервную копию базы данных в серверной консоли:

где LETTER – первая буква имени проекта.

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

ный опыт автора говорят о том, что камнем преткновения, как правило, становятся интерфейс сайта и система по-мощи. До недавнего времени интерфейс SourceForge был ярким примером сумбурного интернет-портала с непроду-манной системой навигации. Учитывая, что SourceForge – это одновременно портал и для разработчиков, и для поль-зователей, создать практичный и понятный интерфейс действительно непросто, а богатство возможностей застав-ляло мириться с неудобствами. К счастью, совсем недавно дизайн сайта кардинально поменялся в лучшую сторону (см. рис. 1), хотя его все еще трудно назвать идеальным.

Помощь в SourceForge сосредоточена в wiki-разделе сайта https://sourceforge.net/apps/trac/sourceforge/wiki. Под-робная информация есть практически по каждому вопросу, однако найти ее, мягко говоря, непросто. Централизованно-го индекса wiki-страниц нет (не говоря уже о том, что ему по-ложено быть структурированным по категориям), а ссылки с главной страницы далеко не всегда последовательно ведут к нужным разделам. Например, попасть на страницу, посвя-щенную администрированию репозитария кода, через сер-верную консоль (https://sourceforge.net/apps/trac/sourceforge/ wiki/SVN%20adminrepo) с главной страницы wiki нельзя ни-как. Соответственно невозможно догадаться, что такая до-кументация вообще существует. Приходится пользовать-ся Google или встроенным поиском. Последний, кстати, по умолчанию ищет не только в wiki, но и в bug-трекере, так что первым десятком ссылок оказываются сообщения об ошибках (что явно не соответствует ожиданиям пользова-теля). Информация в wiki может быть несколько устаревшей, но никаких серьезных ошибок я ни разу не заметил.

Нужно также упомянуть, что скорость отклика сайта SourceForge, как правило, удручающе невелика. Судя по все-му, это связано именно с серверами SourceForge, т.к. практи-чески не зависит от провайдера и качества внешнего канала.

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

> Bazaar (http://bazaar-vcs.org/en);> BerliOS (http://www.berlios.de);> Lauchpad (https://launchpad.net);> GNU savannah (http://savannah.gnu.org).Подробное сравнение этих и других, менее популярных,

хостингов можно найти в Википедии (http://en.wikipedia.org/ wiki/Comparison_of_open_source_software_hosting_facilities).

***SourceForge по праву считается самым популярным хостин-гом для открытого ПО. Богатые возможности делают его очень привлекательным как для масштабных проектов, так и для совсем небольших домашних разработок. В последнее время интерфейс SourceForge существенно улучшился, есть надежда, что со временем будут устранены и оставши-еся недостатки. Если свыкнуться с некоторыми особенно-стями интерфейса, искать ответы на возникающие вопросы через Googlе, не полагаясь на путанную систему навигации, то использование SourceForge можно назвать приятным и беспроблемным.

mysqldump --host=mysql-{LETTER}.sourceforge.net ↵ --user={LETTER}{GROUP ID}admin -p --opt ↵ {LETTER}{GROUP ID}_{DATABASENAME} | ↵ gzip --fast > dumpfile.mysql.gz

EOF

scp file.html user,[email protected]:

Реклама


86

Визитка


Каждый язык программирования имеет своё индивидуаль-ное назначение. Например, PowerShell создан для решения административных задач, совмещая в себе возможности ко-мандной строки; частично VBScript; .NET FrameWork, а зна-чит и VB.NET или C#. Оболочка на базе командной строки, унаследованная из MS-DOS предназначена для управления ОС из командной строки. Созданные с использованием их командные файлы позволяли автоматизировать процессы. С появлением Windows возможности оболочки расшири-лись и появился конкурент – VBScript и Jscript. Вместе с WSH сценарии созданные на этих скриптовых языках позволяли решить множество различных задач. Спустя годы появился набор библиотек FrameWork, с помощью которых диапазон действий еще больше расширился. Однако администрато-ры не могли использовать преимущества этих библиотек, требовались серьезные познания в программировании. Шаг на встречу наконец был сделан – это PowerShell совме-щающий в себе возможности командной строки; поддержи-вающий COM-объекты (замена VBS+WSH); .NET FrameWork (VB.NET или C#). Все это так, но не смущает ли читателя слово «частично»? Попробуйте подключить сетевой диск или сетевой принтер с помощью PowerShell. Не получилось? А ведь в VBscript/JScript это можно было сделать одной строкой. Давайте попытаемся удаленно управлять серве-рами, например, настройками ABE или DFS. Как, PowerShell основан на .NET, но «не умеет работать» c API-функциями? Так и хочется сделать вывод – Microsoft опять не доделал свой продукт. Но это только на первый взгляд. Если разо-браться, то можно заимствовать код из VBScript и VB.NET в PowerShell, передавать и получать параметры.

PowerShell и интерпретируемые языки программированияК интерпретируемым языкам программирования относят-ся такие интегрированные в операционную систему языки как VBScript, Jscript. Интерпретируемые языки характеризу-ются, прежде всего, тем, что программный код хранится в тек-стовом виде, а при вызове файла осуществляется компиля-ция программного кода интерпретатором и его исполнение.

Именно это свойство используется. Фрагмент программ-ного кода, который необходимо исполнить в текстовом виде, помещается в листинг PowerShell, затем выполняется его компиляция и немедленное исполнение. С практической точки зрения это осуществляется в PowerShell вызовом COM-объекта ScriptControl с помощью командлета New-Object. Его экземпляр создается с ключом comObject. Соз-данным объектом поддерживается ряд свойств и методов. Некоторые из них приведены в таблицах 1 и 2.

По правилам синтаксиса PowerShell вставка многостроч-ного текста, а именно фрагмент листинга на VBScript/JSсript, помимо обычных кавычек, заключается в символ «@ с обеих сторон. В листинге 1 приведен пример отображения тексто-вого сообщения, вызываемого в VBScript-сценарии, храня-щемся в переменной $txtCode.

Внимание! Во всех примерах текст интегрированного в PowerShell сценария выделен красным цветом.

Передача параметров из PowerShell в VBScriptДля передачи параметров в PowerShell используется один из методов: Eval(), Run(), АddCode(). Первые два метода сходны между собой: оба выполняют код, загруженный ра-нее в оперативную памятью. Третий метод принципиально отличается от первых двух тем, что параметры передаются сценарию, а не функции. Из-за этого с помощью первых двух методов можно получить какой-либо объект обратно в PowerShell, а с помощью третьего – нет.

Реализация первых двух методов проста, поэтому описы-вать их подробно нет смысла. Пример использования мето-да Eval() приведен в листинге 3 (см. подраздел «Передача результатов из VBScript в PowerShell»).

PowerShell – язык командной строки, разработанный для определённого круга задач. Расширить его мож-но за счет других языков программирования, инте-грировав программный код из VBScript или VB.NET

Расширяем возможностиPowerShell: другие языки программирования

ИВАН КОРОБКО, сертифицированный специалист MCP, автор более 50 статей и двух книг. Занимается созданием различных приложенийдля Active Directory

Листинг 1. Выполнение сценария на VBScript из PowerShell

$sc = New-Object –comObject ScriptControl $sc.Language = 'VBScript'$txtCode = @"MsgBox "Тестовое сообщение""@$sc.AddCode($txtCode) $sc.CodeObject



Рассмотрим подробнее практику использования метода AddCode(). В листинге 2 приведен пример, в котором с по-мощью этого метода передаётся значения параметра. Дан-ный процесс состоит из двух частей: передачи параметра сценарию и чтения переданного значения. Передача значе-ния осуществляется с помощью ключа -f, за которым через запятую перечислены передаваемые параметры. В при-мере – это единственный параметр $ps1. В VBScript встав-ке получение значения параметра осуществляется при-своением произвольной переменной инструкции {Number}, где Number – порядковый номер считываемого параметра. Передача результата из VBScript в PowerShell

Передать параметры из PowerShell в VBScript – это билет в один конец. Достаточно часто необходимо вернуть получен-ный результат обратно в PowerShell. Для решения этой зада-чи лучше всего подойдет метод Eval(). Этот метод имеет всего

Microsoft опять не доделал свой продукт? Но это только на первый взгляд. Если разо-браться, не все так плохо

Таблица 2. Свойства объекта ScriptControlТаблица 1. Свойства объекта ScriptControl

Метод Описание

AddCode(String) Добавляет код, заданный параметром к спис-

ку процедур компонента. В дальнейшем эти

процедуры могут быть вызваны при помощи

метода Run() или других процедур скрипта

Eval(String) Выполняет код, заданный в параметре, и воз-

вращает результат исполнения. Позволяет

выполнить код без добавления его к списку

процедур компонента (см. листинг *)

Run(ProcedureName, Arg1,

Arg2, …)

Выполняет указанную процедуру из ранее

загруженных с помощью метода AddCode().

В массиве Parameters могут быть переданы

параметры

Reset Сбрасывает компонент в начальное состоя-

ние, удаляя все добавленные ранее объекты

и код

_Aboutbox Вывод справочной информации о версии

Script Control (см. рис. 1)

Свойство Тип данных Описание

Language String Задает язык интерпретатора описывае-

мой вставки. По умолчанию доступны

VBScript и JScript. При установке расши-

рений Windows Host Scripting возможно

использование других языков, например,

Perl или Rexx

Timeout Integer Интервал исполнения скрипта, по ис-

течении которого генерируется ошибка.

Значение «-1» позволяет отключить об-

работчик ошибок, что позволит скрипту

исполняться неограниченное время

Error Integer При вызове этого свойства получают код

ошибки и ее описание. Если код ошибки

«0», то сценарий выполнен правильно

UseSafeSubset Boolean При установке этого свойства в TRUE

компонент может выполнять ограничен-

ный набор действий, заданный текущими

установками безопасности в системе

Листинг 2. Пример передачи параметра из PowerShell в VBScript вставку

function call_vbs($p1)

{$sc = New-Object -comObject ScriptControl $sc.Language = 'VBScript'$ txtCode = @"str1="{0}" MsgBox str1"@$sc.AddCode($($code -f $p1)) $sc.CodeObject}call_vbs("Тестовое сообщение")



один параметр, значение которого – имя функции и ее пара-метры. Во фрагменте на VBScript, вставленном в PowerShell, обязательно должна быть объявлена функция, а не процеду-ра. Передача параметра обратно из VBScript обеспечивает-ся стандартным механизмом: в VBScript необходимо в конце функции присвоить одноименной переменной результирую-щее значение функции. Это значение автоматически будет возвращено в метод Eval() (в листинге 2 – переменная result). В листинге 2 приведен пример вычисления суммы двух чи-сел: из PowerShell передаются в VBScript функцию два чис-ла – 2 и 5. Функция вычисляет сумму и возвращает результат в PowerShell. Полученное значение выводится на экран.

Выполнение VBS-файла из PowerShellВстречаются случаи, когда необходимо интегрировать не программный код в PowerShell, а вызвать готовый VBS-файл, задав аргументы командной строки. Для реализации этого метода используется встроенный в операционную систему интерпретатор Wscript.exe или Cscript.exe. В листин-ге 4а) приведен пример вызова файла test.vbs. Текст файла test.vbs листинге 4б). Результатом выполнения сценариев является вывод информационного сообщения (см. рис. 2).

PowerShell и компилируемые языки программированияДовольно часто возникает потребность использовать встав-ки VB.NET или C# в листинге PowerShell. Это обуславливает-ся невозможностью реализовать тот или иной функционал при помощи PowerShell. Как правило, любую манипуляцию

с любым объектом можно выполнить с помощью с API-функции, вызываемой на низком уровне. Ярким примером является служба DFS, программное управление которой возможно только с помощью API-функций. Чтобы упро-стить изложение материала? отвлечемся от DFS и приведем пример вывода обычного окна сообщения – MessageBox(). Реализуем вызов сообщения с помощью вставки листинга программного кода, написанного на VB.NET в тело сцена-рия PowerShell, и с помощью вызова соответствующей API-функции, описанной в VB.NET.

Интеграция кода на VB.NET в PowerShellИнтеграция в PowerShell кода компилируемых языков, напри-мер VB.NET или C#, осуществляется несколько иным меха-низмом. Вставка программного кода также компилируется, однако вместо файла записывается в оперативную память.

Успешная интеграция программного кода на VB.NET обеспечивается с помощью двух объектов. С помощью первого – CompilerParameters осуществляется настройка параметров компиляции указанного кода, а также иденти-фикация языка программирования. Второй объект изме-няется в зависимости от используемого во вставке языка программирования. Например, для Visual Basic – Microsoft. VisualBasic.VBCodeProvider.

Фрагмент исполняемого кода на VB.NET представляет собой описание класса с произвольным именем и минимум одну функцию, имя которой также произвольно. Листинг является значением переменной, заключенного помимо ка-вычек в символы «@» (см. листинг 5). При переносе листин-га из Visual Studio в PowerShell необходимо следить за тем, чтобы иерархический путь ко всем методам и функциям был указан целиком, т.к. импорт пространств имен не поддержи-вается. Таким образом, вывести окно с помощью MsgBox() невозможно, необходимо указать полный путь – Microsoft. VisualBasic.Interaction.MsgBox().

Рисунок 1. Справка Script Control Рисунок 2. Информационное сообщение

Листинг 3. Передача и возвращение параметров между VBScript и PowerShell

$sc = New-Object -comObject ScriptControl $sc.Language = 'VBScript'$txtCode = @"Function test(a,b) test = a+bend Function"@$sc.AddCode($txtCode)$a=2 $b=5$result = $sc.Eval("test($a,$b)") write-host $result

Листинг 5. Вызов VB.NET вставки из PowerShell

$provider = New-Object Microsoft.VisualBasic.VBCodeProvider $params = New-Object ↵ System.CodeDom.Compiler.CompilerParameters $params.GenerateInMemory = $True$refs = "System.dll","Microsoft.VisualBasic.dll" $params.ReferencedAssemblies.AddRange($refs)

$txtCode = @"Class mBox Sub Main()Microsoft.VisualBasic.Interaction.MsgBox ↵ ("Тестовое сообщение")End Sub End class"@

Листинг 4а. Вызов VBS-файла из PowerShell

$txt = "Тестовое сообщение" cscript.exe test.vbs $txt

Листинг 4б. Файл test.vbs

Set obj = Wscript.Arguments MsgBox obj(0)



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

Передача параметров из PowerShell во вставку VB.NETЧасто требуется передать параметры из PowerShell в какую-либо функцию в VB.NET вставки. Для этого необходимо при вызове функции указать параметр, а в листинге VB.NET описать его как параметр функции. Внутри VB.NET вставки работа с параметром функции ведется в обычном режиме. В листинге 6 приведен пример передачи параметра строки «Тестовое сообщение» в функцию showString. Полученное значение выводится на экран с помощью функции MsgBox().

Механизм передачи параметра из выполненного VB.NET сценария обратно в PowerShell выглядит так же, как в ли-стинге 3 (случай VBScript). Для передачи параметра исполь-зуется функция. В конце функции переменной, имя которой совпадает с названием функции, присваивается перемен-ная, передаваемая в PowerShell. В качестве переменной может выступать любой объект, поддерживаемый VB.NET – строка, объект, массив и т.д.

В листинге 7 приведен пример сложения двух чисел. Два исходные числа передаются из PowerShell в VB.NET. В сценарии осуществляется их сложение, затем результат обратно передается в PowerShell и выводится на экран.

Обратите внимание, что вопреки правилам синтаксиса VB.NET, при объявлении функции Summa() в классе Summ, тип данных переменных не указан. Это сделано специально. В противном случае сценарий работать не будет.

Вызов API-функций из VB.NET вставки в PowerShellAPI-функция – это низкоуровневая функция, описанная в на-боре динамических библиотек ядра операционной системы Windows. Использование API значительно расширяет возмож-ности программиста, позволяя создавать очень сложные при-ложения. Так, доступ к DFS программным способом осущест-вляется только с помощью API-функций. Даже .NET здесь бессилен. Приведем пример вызова простейшей API-функции (листинг 8), выводящей окно сообщений – Message Box. Лю-бая API функция объявляется непосредственно в классе VB.NET, как любая другая функция, например, MyMessageBox. При объявлении функции обязательно указывается библиоте-ка, в которой она описана и псевдоним (алиас), который на-значается произвольно. После объявления функции, она вы-зывается в одной из функций в VB.NET вставке.

***В заключение отмечу, что приведенный материал лишь не-много раскрывает скрытые возможности языка PowerShell. Умелыми руками с его помощью можно создавать очень сложные программы, которые невозможно будет отличить по внешнему виду от обычных Windows-приложений.

Листинг 6. Передача параметров функции из PowerShell в VB.NET вставку


$txtCode = @"Class mBoxSub showString (str)Microsoft.VisualBasic.Interaction.MsgBox (str) End SubEnd class"@ $results = $provider.CompileAssemblyFromSource( ↵ $params, $txtCode) $mAssembly = $results.CompiledAssembly $i = $mAssembly.CreateInstance("mBox") $r = $i.showString("Тестовое сообщение")

Листинг 7. Передача и возвращение параметров между VB.NET и PowerShell


$txtCode = @"

Листинг 8. Вызов API-функции из VB.NET вставки в PowerShell


$txtCode = @"Class mBoxDeclare Auto Function MyMessageBox Lib "user32.dll" ↵ Alias "MessageBox" _(ByVal hWnd as Integer, ByVal msg as String, ↵ ByVal Caption as String, ByVal Tpe as Integer) ↵ As Integer Sub Main()MyMessageBox(0, "Текстовое сообщение", "", 0) End SubEnd class"@ $results = $provider.CompileAssemblyFromSource( ↵ $params, $txtCode) $mAssembly = $results.CompiledAssembly $i = $mAssembly.CreateInstance("mBox") $r = $i.main()

$results = $provider.CompileAssemblyFromSource( ↵ $params, $txtCode) $mAssembly = $results.CompiledAssembly $i = $mAssembly.CreateInstance("mBox") $r = $i.main()

Class SummFunction Summa (x ,y ) Dim s As integer = x +y Summa = sEnd Function End class"@ $a=2 $b=5 $results = $provider.CompileAssemblyFromSource( ↵ $params, $txtCode) $mAssembly = $results.CompiledAssembly $i = $mAssembly.CreateInstance("Summ") $result = $i.Summa($a,$b)Write-Host $result

EOF


90

Визитка


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

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

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

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

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

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

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

Во-первых, администратор элементарно экономит время, силы и драгоценную «ману», совершая все манипуляции со своего родного админского компьютера.

Во-вторых, время выполнения задач пользователя суще-ственно сокращается, что может сэкономить компании не-

Три кита, на которых основано ПО для удаленного управления компьютерами, безопасность, скорость и удобство использования

Мышеловка для админаОсторожно: сыр прилагается

ЕВГЕНИЙ ЛИСОВСКИЙ, директор по маркетингу ООО «Фаматек Трейд»

Спектр решений на базе программ для удалённого доступа: администрирование, обуче-ние, презентации, удаленная работа



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

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

Наравне с удалённым офисом, можно использовать ту же программу, к примеру, для дистанционного обучения новых сотрудников навыкам работы с офисным ПО. Тут вы-года также очевидна: два человека за одним рабочим сто-лом умещаются с трудом, да и неудобно это как-то.

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

Что греха таить, некоторые работодатели также исполь-зуют программы удаленного доступа для контроля над дея-тельностью сотрудников, хотя я не сторонник таких методов.

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

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

Web-based-решения рассматривать не будем, ибо они, в первую очередь, предназначены для домашнего пользо-вателя.

Бесплатные продукты для некоммерческого использова-ния также оставим в стороне.

Клиент-серверные в свою очередь делятся на две про-стые категории: платные и бесплатные. А вот тут то и пора вспомнить про мышеловку! Возьмем, к примеру, бесплат-ное решение UltraVNC и знакомый каждому админу платный Radmin. Какое решение вы выберете для использования в корпоративной сети? Не спешите с ответом, ведь, как го-ворится, бесплатный сыр бывает только в мышеловке. Ка-кие достоинства у UltraVNC? Первое, что приходит в голо-ву, – это бесплатная программа. В остальном выполняемые UltraVNC функции схожи с Radmin. В чем же тогда различия с точки зрения использования в корпоративной сети?

Во-первых, UltraVNC и прочие подобные бесплатные про-граммы написаны на основе VNC, их предка с открытым ко-дом, отсюда вытекает возможность изучения кода с целью поиска уязвимостей. В Интернете можно найти целый ряд модифицированных клиентов и «эксплоитов» для программ на базе VNC. Radmin, в отличии от подобных программ, написан, как говорится, с нуля, имеет уникальный код, и не подвержен «болезням» VNC.

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

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

Регулярные отчёты о «багах» в версиях UltraVNC под грифом «стабильная» Дружелюбный интерфейс (как говорит одна моя знакомая) – это наше всё!

Bagtraq


Составил Александр Антипов

Уязвимость при обработке больших пакетов в Realtek 8169-драйвере в XenServerПрограмма: Citrix XenServer 5.0 Update 3 и более ранние версии; Citrix XenServer 5.5.Опасность: Средняя. Наличие эксплоита: Нет.Описание: Уязвимость существует из-за ошибки в RTL8169-драйвере при обработке слишком больших сетевых пакетов. Удаленный пользователь может с помо-щью слишком большого сетевого пакета вызвать панику ядра системы.URL производителя: www.citrix.com.Решение: Установите исправление с сайта производи-теля.

Выполнение произвольного кода в Apache mod_proxyПрограмма: Apache 1.3.41, возможно, другие версии. Опасность: Высокая.Наличие эксплоита: Нет.Описание: Уязвимость существует из-за ошибки об-работки целочисленных в функции ap_proxy_send_fb() в файле src/modules/proxy/proxy_util.c. Удаленный поль-зователь может вызвать переполнение динамической па-мяти и выполнить произвольный код на целевой системе. Уязвимость распространяется на системы, где размер типа данных long больше чем размер типа данных int (на-пример, на 64-битных системах).URL производителя: www.apache.org.Решение: Установите последнюю версию 1.3.42 с сайта производителя.

Обход ограничений безопасности в qla2xxx-драйвере в Red Hat Enterprise LinuxПрограмма: Red Hat Enterprise Linux 5 . Опасность: Низкая.Наличие эксплоита: Нет.Описание: Уязвимость существует из-за того, что qla2xxx-драйвер для адаптера QLogic Fibre Channel PCI/ PCIe устанавливает привилегии на запись всем поль-зователям для файлов /sys/class/scsi_host/[a qla2xxx host]/vport_create и /sys/class/scsi_host/[a qla2xxx host]/ vport_delete. Злоумышленник может изменить некото-рые атрибуты SCSI. Уязвимость распространяется толь-ко на системы, использующие qla2xxx-драйвер с NPIV-устройствами.URL производителя: www.redhat.com.Решение: Установите исправление с сайта производи-теля.

Утечка памяти в CRYPTO_free_all_ex_data() в OpenSSLПрограмма: OpenSSL 0.9.x. Опасность: Низкая . Наличие эксплоита: Нет.Описание: Уязвимость существует из-за того, что не-которые приложения (например Apache с модулем PHP) вызывает преждевременно OpenSSL функцию CRYPTO_ free_all_ex_data(). В некоторых случаях это может при-вести к утечке памяти и вызвать отказ в обслуживании системы.URL производителя: www.openssl.org.Решение: Установите исправление из CVS-репозитория производителя.

Множественные уязвимости в phpMyAdminПрограмма: phpMyAdmin версии до 2.11.10. Опасность: Низкая .Наличие эксплоита: Нет.Описание: 1. Уязвимость существует из-за того, что при-ложение создает временную директорию с привилегия-ми на запись для всех пользователей. Злоумышленник может изменить файлы.

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

3. Уязвимость существует из-за того, что некоторые данные, передаваемые сценарию scripts/setup.php, ис-пользуются для вызова функции unserialize().URL производителя: www.phpmyadmin.net.Решение: Установите последнюю версию 2.11.10 с сайта производителя.

Уязвимость при обработке подключений к SQL-серверу в HP Web JetadminПрограмма: HP Web Jetadmin 10.2 и более ранние вер-сии.Опасность: Низкая . Наличие эксплоита: Нет.Описание: Уязвимость существует из-за того, что не-зашифрованные данные передаются к удаленным SQL-серверам. Удаленный пользователь может посредством атаки «человек посередине» получить доступ к данным и вызвать отказ в обслуживании.URL производителя: h20392.www2.hp.com/portal/ swdepot/displayProductInfo.do?productNumber=J6052AA. Решение: В настоящее время способов устранения уяз-вимости не существует.

Веб

94

Визитка


Его создание – довольно непростая, требующая скрупулез-ности задача, на решение которой тратишь немало време-ни – на отладку, обеспечение кроссбраузерной совмести-мости, борьбу с капризами JavaScript и прочие вещи, мало имеющие общего с разработкой и проектированием реали-зации бизнес-логики. К счастью, уже создано немало инстру-ментов, облегчающих эту задачу. Фрэймворк Google Web Toolkit пусть и не единственная предназначенная для этого среда, но она уже успела себя зарекомендовать полнофунк-циональными, работоспособными RIA-приложениями.

Что это? Зачем?На первый вопрос ответить легко – это фрэймворк-среда, набор средств и API-интерфейсов для разработки веб-при-ложений. Её отличительная особенность в том, что вся раз-работка и, что существенно, отладка ведётся на Java с помо-щью привычной IDE (сейчас существуют плагины для Eclipce и NetBeans) с последующей компиляцией готового приложе-ния в HTML/JavaScript. Собственно, реальность использова-ния сред разработки частично является ответом на второй

вопрос. Создавать сложное веб-приложение на строго типи-зированном ООП-языке, с возможностью нормального про-ектирования в любимой IDE, «человеческой» отладкой, Unit тестированием ещё недавно казалось недостижимой мечтой.

Google Web Toolkit во многом является воплощением этой мечты в жизнь. Процесс отладки приложения здесь гораздо более лёгок и эффективен, так как наиболее распростра-нённые ошибки в JavaScript теперь всплывают во время компиляции, а не выполнения, а такие ошибки, как несоот-ветствие типов или отсутствие необходимых методов, выяв-ляются ещё на стадии написания кода. Подсказки и автодо-полнение – нормальный функционал IDE, хоть и не жизненно важный, но довольно существенно повышающий производи-тельность, а полноценный рефакторинг (который также те-перь доступен) в современных условиях просто необходим.

Отдельно следует упомянуть про ООП-разработку. Реа-лизация этой концепции в JavaScript вызывает много спра-ведливых нареканий и является причиной неоправданной сложности разработки. В среде GWT вы программируете на Java, и никаких проблем такого рода не возникает.

Любое интернет-приложение эпохи WEB2 – это прежде всего «богатый» и функциональный пользо-вательский интерфейс, выполненный с использова-нием технологии Ajax, а следовательно, JavaScript

Google Web Toolkit –современное средство создания Rich Internet Application

КИРИЛЛ СУХОВ, веб-программист в дистрибьюторской компании MICS. Занимаюсь проектированием и разработкой различных интернет-сервисов. Круг интересов банален – веб-технологии, RIA, Framework-среды

Рисунок 1. GWT работает! Рисунок 2. Скомпилированное GWT-приложение

Веб


Кроме того, при написании веб-приложений теперь можно использовать такие привычные утилиты, как Jprofiler или Junit.

Как это работает?Код пишется и отлаживается на Java с использованием ти-пов данных из пакетов java.lang и java.util, а также с новыми классами, предоставляемыми GWT. Поддерживаются все внутренние типы Java (в том числе и Object). Поддержива-ется работа с исключениями, в том числе и определяемыми пользователем.

После отладки приложения при помощи GWT-компиля-тора создаётся приложение, использующее традицион-ные веб-технологии – HTML/JavaScript/XML/JSON, которое для GWT-приложения является аналогом бинарного пред-ставления в Java. Но GWT это не совсем Java!

Прежде всего не поддерживается Reflection и динамиче-ская загрузка классов (что естественно, этот механизм про-сто невозможно перенести в JavaScript). Не поддерживает-ся сериализация. Не поддерживается модификатор Strict Floating Point.(strictfp), предписывающий «строгую» ариф-метику для чисел с плавающей точкой. Нет финализации объекта перед сборкой мусора.

GWT-приложение как любое веб-приложение состоит из клиентской (обрабатываемой в браузере) и серверной частей. Весь код, отвечающий за клиентский функционал, в процессе компиляции переводится в html/javascript и, сле-довательно, имеет ряд естественных ограничений.

Серверная часть приложения может вызываться кли-ентским кодом посредством асинхронных RPC-запросов. При этом серверный код выполняется отдельно от клиент-ского и не имеет каких-либо ограничений, накладываемых компиляцией в JavaScript. Более того, нет ограничений в вы-боре технологий реализации серверной части программы. Наряду с Java это может быть PHP, Perl, Python и т.д.

Механизм отложенного связывания (deffered binding), вы-полняемого при генерации JavaScript, обеспечивает решение проблем с кроссбраузерной совместимостью и локализаци-ей приложения. GWT компилирует различные версии прило-жения под каждый браузер и локализацию. Во время запуска клиентской части такого приложения в браузере определяет-ся нужная версия, она и поставляется пользователю.

Библиотеки GWT лицензированы под Apache License 2.0, что даёт полную свободу использования среды как в откры-тых, так и в пропроетарных приложениях.

Как установить?На компьютере должна быть установлена Java SDK версии 1.5 или выше. Ещё одно требование – наличие Apache Ant, java-утилиты для автоматизации процесса сборки. Если её нет, просто скачайте из сайта проекта (http://ant.apache.org) и распакуйте в любое удобное место, не забыв прописать переменную окружения ANT_HOME и путь к Ant/bin в пере-менной PATH. (Впрочем, при использовании Windows можно прибегнуть к сценарию установки в составе дистрибутива.)

Сначала скачиваем дистрибутив с сайта code.google.com (http://code.google.com/intl/ru/webtoolkit/download.html) и рас-паковываем его в выбранную директорию. Собственно, на этом процесс установки закончен. Осталось только про-писать путь к этой папке в системной переменной PATH.

Для проверки работоспособности GWK перейдём в папку /samples, расположенную в корневой папке установленно-го фрэймворка. Это примеры простейших приложений ис-пользования среды. Заходим (в консоли) в /samples/Hello и выполняем команду:

Если всё правильно установлено, результат должен быть похож на рис. 1. Этой командой мы запускаем приложение в так называемом размещённом (hosted) режиме. В нём оно выполняется на виртуальной машине Java (JVM). Этот ре-жим предназначен для отладки и разработки.

Мы видим два окна встроенного браузера, в первом из них запущено само приложение, во втором отображается отладочная информация, в том числе данные Http-запросов.

Теперь откомпилируем наше приложение в HTML/Java Script. Для этого вызовем команду:

запускающую GWT-компилятор. Результат его работы мож-но увидеть в папке samples/Hello/war, раскрыв в браузере файл MailBoxes.html. Как видим (см. рис. 2), всё прошло успешно. Правда, не впечатляет.

ant hosted

ant build

Рисунок 3. Почтовый клиент на JavaSxript Рисунок 4. Наше первое GWT-приложение

Веб


Чтобы увидеть настоящее GWT-приложение, заглянем в папку samples/Mail, где хранятся демонстрационные при-меры приложений, проведем аналогичные действия. В ре-зультате получим уже нечто вполне приемлемое (см. рис. 3).

Первое приложениеТеперь попробуем создать собственное простенькое GWT-приложение. Для этого воспользуемся утилитой webApp Creator, входящей в комплект GWT:

MailBoxes – это название нашего приложения (да-да, ин-терфейс к почтовому серверу). После выполнения команды будет создано несколько папок и файлов в папке MailBoxes/, которые составят скелет приложения и обеспечат базовый «Hello GWT» функционал:

Скрипт webAppCreator создал несколько файлов в ката-логе MyApplication/, в том числе базовую функциональность «Hello, world» в классе. В корневой папке приложения по-явился сценарий его сборки, для Ant – build.xml, следова-тельно, наше приложение уже можно компилировать и за-

пускать. Воспользовавшись вышеописанными командами ant hosted и ant build, мы получим простейшее рабочее AJAX (а как же!) приложение (см. рис. 4). Как видите, оно состоит из поля ввода, куда следует поместить имя, и кнопки «От-править», после нажатия на которую появляется ответ сер-вера с приветствием, учитывающим ваши данные.

Давайте теперь посмотрим, что у него внутри.GWT-приложения оформлены в виде модулей, их струк-

тура подчиняется правилам, сходным с организацией па-кетов в Java-приложении. Она определяется в xml-файле (в нашем случае MessageBox.gwt.xml).

Как уже говорилось, GWT-приложение состоит из двух основных частей – клиентской и серверной. Клиентский код, как нетрудно догадаться, содержится в MailBoxes\src\com\ samag\client\. как и MailBoxes\src\com\samag\server\, он рас-положен на одном уровне с конфигурационным файлом.

В папке MailBoxes\war\ расположены все веб-ресурсы приложения – HTML, CSS, JavaScript файлы. Там же рас-положена директория WEB-INF, в которой содержатся ме-таданные и GWT JavaScript-библиотека среды исполнения (GWT run-time JavaScript library).

Если мы заглянем в исходный код файла MailBoxes\src\ com\samag\client\MailBoxes.java (основного кода нашего при-ложения), то обнаружим обычный Java-код. Вот кнопка Send:

Я не собираюсь пересказывать документацию [2], но ба-зовые понятия изложить придется. Основной класс при-ложения (в нашем случае MailBoxes) реализует интерфейс EntryPoint. Его метод onModuleLoad() вызывается в тот мо-мент, когда веб-страница с встроенным GW- модулем ото-бражается в браузере клиента. Все элементы визуального интерфейса (кнопки, поля ввода, чекбоксы и т.д.) унасле-дованы от суперкласса Widget. Все эти виджеты компону-ются в рамках объекта класса Panel, который, разумеется, сам является виджетом (его аналог в .Swing – Layout).

//Создание кнопкиfinal Button sendButton = new Button("Send"); // Привязка её к таблице стилейsendButton.addStyleName("sendButton"); // Добавление в панель приложенияRootPanel.get("sendButtonContainer").add(sendButton);

C:\www\gwt>webAppCreator -out MailBoxes com.samag.MailBoxes

Created directory MailBoxes\src Created directory MailBoxes\warCreated directory MailBoxes\war\WEB-INF Created directory MailBoxes\war\WEB-INF\lib Created directory MailBoxes\src\com\samagCreated directory MailBoxes\src\com\samag\client Created directory MailBoxes\src\com\samag\serverCreated file MailBoxes\src\com\samag\MailBoxes.gwt.xml Created file MailBoxes\war\MailBoxes.htmlCreated file MailBoxes\war\MailBoxes.css Created file MailBoxes\war\WEB-INF\web.xmlCreated file MailBoxes\src\com\samag\client\MailBoxes.java Created file MailBoxes\src\com\samag\client\ GreetingService.javaCreated file MailBoxes\src\com\samag\client\ GreetingServiceAsync.javaCreated file MailBoxes\src\com\samag\server\ GreetingServiceImpl.javaCreated file MailBoxes\build.xml Created file MailBoxes\README.txt Created file MailBoxes\.project Created file MailBoxes\.classpathCreated file MailBoxes\MailBoxes.launchCreated file MailBoxes\war\WEB-INF\lib\gwt-servlet.jar

Рисунок 5. Устанавливаем Google Plugin Рисунок 6. GWT-приложение в IDE Eclipse

Веб


Компоновка в пространстве веб-страницы происходит в элементы контейнера HTML (в данном случае sendButton Container- это id HTML-элемента <td>), в который будет по-мещена кнопка. Далее добавляется обработчик:

И связывается с кнопкой:

Мне кажется, что всё ясно. Про серверную часть пока речь не ведём, а что касается компиляции в JavaScript/ HTML, то сгенерированные JavaScript объекты загружают-ся в контейнеры, обозначенные в шаблоне HTML-страницы (MailBoxes\war\MailBoxes.html). Поскольку наше приложение сложностью не отличается, то и шаблон довольно прост:

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

Теперь в MailBoxes\src\com\samag\client\MailBoxes.java добавляем новый виджет (в терминах данной среды кнопка и прочие функциональные элементы графического интер-фейса – это именно виджеты (widgets). После кода создания кнопки Send добавляем строчку:

Добавим этот виджет на главную панель приложения:

Теперь следует связать кнопку с внешним событием (в данном случае с кликом по кнопке). Для этого в GWT су-ществуют различные интерфейсы.

GWT предоставляет несколько интерфейсов Listener для улавливания событий (щелчков мыши, нажатия клавиа-туры, изменения содержаний поля ввода и прочие, знако-мые по Javascript). Один из них – ClickHandler – отвечает за обработку клика мыши. Напишем его реализацию:

Готово. Компилируем приложение и наслаждаемся но-вым функционалом.

Всё это хорошо, но преимущества нового способа разра-ботки совершенно не очевидны. Не для того мы совершали столько телодвижений, чтобы учить ещё один диалект Java и отлавливать сообщения об ошибках в консоли. Сделаем следующий шаг – подключим к разработке современную IDE.

Работа в IDE EclipceСначала скачаваем и установливаем плагин для IDE Eclipse (http://code.google.com/intl/ru/eclipse). К слову сказать, если

class MyHandler implements ClickHandler, KeyUpHandler { public void onClick(ClickEvent event) { sendNameToServer(); } ........................................... }

<table align="center"> <tr> <td colspan="3" style="font-weight:bold;"> ↵ Please enter your name:</td> </tr> <tr> <td id="nameFieldContainer"></td> <td id="sendButtonContainer"></td>

resButton.addClickHandler(new ClickHandler() { public void onClick(ClickEvent event) { nameField.setText(""); sendButton.setFocus(true); }});

final Button sendButton = new Button("Send"); final Button resButton = new Button("Reset");

RootPanel.get("sendButtonContainer").add(sendButton); RootPanel.get("resContainer").add(resButton);

<table align="center"> <tr> <td colspan="2" style="font-weight:bold;"> ↵ Please enter your name:</td> </tr> <tr> <td id="nameFieldContainer"></td> <td id="sendButtonContainer"></td> </tr> </table>

MyHandler handler = new MyHandler(); sendButton.addClickHandler(handler);

<td id="resContainer"></td> </tr> </table>

Рисунок 7. Выводим список пользователей Рисунок 8. Применяем стили

Веб


GWT ещё не установлены, это будет сделано на данном эта-пе автоматически (а заодно и SDK App Engine – средство разработки для платформы Google App Engine).

Инсталляция плагина несколько отличается для разных версий IDE. Для Eclipse 3.5 эта процедура выглядит следую-щим образом:

Заходим в Help → Install New Software. В появившимся окне в поле Work with вводим url: http://dl.google.com/eclipse/ plugin/3.5, нажимаем Add. В появившейся форме вводим название для источника обновлений (например, Google Updute) и после подтверждения выбираем необходимые компоненты (см. рис. 5). Поскольку GWT SDK мы уже уста-новили, его можно пропустить. Далее остаётся только пару раз нажать Next и принять лицензионное соглашение.

Теперь импортируем наше приложение в IDE. Для этого нажимаем File → Import, в появившемся окне мастера вы-бираем General → Existsing Project into Workspace. В следую-щем окне в поле Select root directory указываем путь до кор-ня нашего приложения и жмём Finish. Приложение должно появиться в левом окне Eclipse (см. рис. 6).

Для включения поддержки GWT щёлкаем на проекте правой кнопкой мыши. И в контекстном меню выбираем Google → Web Toolkit Setting. В появившемся окошке поме-чаем чекбокс Use Google Web Toolkit. Если мы ставили GWT SDK не вместе с плагином, то, нажав на ссылку Configure SDK, указываем расположение фрэймворка.

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

Список ящиков – это, очевидно, таблица. Чтобы вы-брать подходящий объект из арсенала GWT, отправля-емся в галерею виджетов (http://code.google.com/intl/ru/ webtoolkit/doc/1.6/DevGuide.html), представленную в доку-ментации фрэймворка, и выбираем наиболее подходящий объект для нашей задачи. В данном случае это будет Grid-реализация абстрактного класса HTMLTable.

Включаем его в наше приложение:

При этом вначале надо импортировать класс из соответ-ствующего GWT-пакета:

В дальнейшем добавления почти любых новых элемен-тов влечет за собой импорт необходимых пакетов, я не буду на этом останавливаться, так как их название подскажет IDE. Если лёгкий путь не для вас и разработка происходит в vi/notepad, можно воспользоваться описанием применяе-мых нами компонентов в документации.

Заполняем первый ряд таблицы (заголовки столбцов):

Далее заполним таблицу значениями.

По-настоящему такие сведения должны предоставлять-ся по запросу к внешнему источнику (к базе данных или, например, к LDAP), но мы договорились, что сейчас не об-ращаем внимания на серверную часть кода. Поэтому метод getUsers пока будет своеобразной заглушкой, впрочем, не совсем бестолковой:

Затем создадим в HTML-шаблоне (MailBox.html) необхо-димый контейнер:

Подключаем нашу таблицу к основной панели приложения:

После компиляции мы можем видеть ужасно выглядящую и почти бесполезную таблицу почтовых ящиков (см. рис. 7).

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

final Grid mailGrid = new Grid(1,5); mailGrid.setTitle("mailboxes");

mailGrid.setText(0, 0, "ID"); mailGrid.setText(0, 1, "Name"); mailGrid.setText(0, 2, "Email"); mailGrid.setText(0, 3, "Activity");

private void getUsers(Grid grid) { int rows;int newRow; String rid; rows=grid.getRowCount(); newRow=grid.insertRow(rows); grid.setText(newRow, 0, "1"); grid.setText(newRow, 1, "Ivfnov"); grid.setText(newRow,2, "[email protected]"); grid.setText(newRow, 3, "On"); rows=grid.getRowCount(); newRow=grid.insertRow(rows); grid.setText(newRow, 0, "2"); grid.setText(newRow, 1, "Sidorov"); grid.setText(newRow, 2, "[email protected]"); grid.setText(newRow, 3, "On");

import com.google.gwt.user.client.ui.Grid;

this.getUsers(mailGrid);

mailGrid.setStyleName("emailTables");

<div id="mailTable" align="center"></div>

RootPanel.get("mailTable").add(mailGrid);

Рисунок 9. Приложение готово!

Веб


И прописать его с таким названием в таблице стилей (MailBox/war/MailBox.ccs):

Любуемся результатом (см. рис. 8) и приступаем к соз-данию функционала. Сначала обеспечим возможность уда-ления записи. Создадим виджет кнопки для удаления как самостоятельный класс, производный от класса Button (ко-торый в свою очередь произведён от Widget):

Я думаю, что по аналогии с кнопкой Reset тут всё понят-но. Новые только обращение к объекту Window, аналогу объекта window веб-страницы, и метод removeRow, который «подсказал» Eclipse. Для того чтобы вставить эту кнопку в список акаунтов, немного изменяем заполнение таблицы:

На следующем этапе сделаем возможным активацию/ блокирование акаунтов. Для этого создадим ещё один вид-жет – кнопку-переключатель, найдя предварительно подхо-дящий класс (ToggleButton) в галерее виджетов:

Вносим изменение в заполнение таблицы:

Осталось создать возможность заносить в таблицу но-

вые акаунты. Для этого добавим форму в последнем ряду таблицы. Сначала создадим необходимые виджеты (кото-рые после компиляции станут полями html-формы):

Создаём новый ряд таблицы и заполняем его виджетами:

В последнею ячейку мы помещаем новую кнопку, на этот раз не создавая нового класса, а просто привязывавя к объ-екту класса Button новый хендлер. Метод addRow, конечно, нуждается в реализации:

Компилируем и проверяем результат (см. рис. 9). Обрати-те внимание, как мы совершенно безболезненно перешли с Windows/Chrome на Linux/Firefox.

Для первого знакомства с технологией GWT пока до-статочно, но за рамками осталось, как всегда, самое ин-тересное – взаимодействие с сервером, передача данных, удалённый вызов процедур, механизм DWR (Direct Web Remoting) и многое другое. Эти вопросы мы рассмотрим во второй части статьи.

1. Домашняя страница проекта – http://code.google.com/intl/ru/webtoolkit.

2. Документация по GWT – http://code.google.com/intl/ru/webtoolkit/doc/1.6/DevGuide.html; http://code.google.com/intl/ru/webtoolkit/ doc/latest/DevGuide.html.

3. Доклад «Архитектура Google Web Toolkit: полезные советы по написанию приложений на GWT» на конференции Google Developer Day 2009, Москва – http://www.youtube.com/watch?v= sjyy9WgaObc&feature=channelа.

emailTables{ font-size: 120%; line-height: 1em; background: url(images/hborder.gif) repeat-x; }

package com.samag.client;import com.google.gwt.event.dom.client.ClickEvent; import com.google.gwt.event.dom.client.ClickHandler; import com.google.gwt.user.client.Window;import com.google.gwt.user.client.ui.Button; import com.google.gwt.user.client.ui.Grid; public class delButton extends Button { public delButton(final Grid grid,final int row) { super("Delete", new ClickHandler() { public void onClick(ClickEvent event) { Window.alert("Удаляем ряд"+row); grid.removeRow(row); } }); } }

newRow=grid.insertRow(rows); grid.setText(newRow, 0, "1");grid.setText(newRow, 1, "Ivanov");grid.setText(newRow,2, "[email protected]");grid.setWidget(newRow, 3, new ActiveButton(grid,1)); grid.setWidget(newRow, 4, new delButton(grid,1));

final TextBox Name = new TextBox(); final TextBox Email = new TextBox();final CheckBox Activity = new CheckBox(); Activity.setValue(true);

package com.samag.client;import com.google.gwt.user.client.ui.Grid;import com.google.gwt.user.client.ui.ToggleButton; import com.google.gwt.user.client.Window;public class ActiveButton extends ToggleButton { public ActiveButton(final Grid grid, int turn) { super("On", "Off"); if(turn!=1){ this.setDown(true); } public void onClick(ClickEvent event) { Window.alert("Меняем активность"); } }

newRow=grid.insertRow(rows); grid.setText(newRow, 0, "1");grid.setText(newRow, 1, "Иванов");grid.setText(newRow,2, "[email protected]"); grid.setText(newRow, 3, "On");grid.setWidget(newRow, 4, new delButton(grid,1));

int rows=mailGrid.getRowCount();int newRow=mailGrid.insertRow(rows); mailGrid.setWidget(newRow, 1, Name); mailGrid.setWidget(newRow, 2, Email); mailGrid.setWidget(newRow, 3, Activity);mailGrid.setWidget(newRow, 4, new Button("Add", ↵ new ClickHandler() { public void onClick(ClickEvent event) { this.addRow(mailGrid,Name.getValue(), ↵ Email.getValue(),Activity.getValue()); }

private void addRow(Grid mailGrid,String uName, String ↵ uEmail, Boolean uActivity) { if(uName.isEmpty() && uEmail.isEmpty()){ Window.alert("Не все параметры заполнены!"); return; } int rows=mailGrid.getRowCount(); String rid=String.valueOf(Integer.parseInt( ↵ mailGrid.getText(rows-2, 0))+1); int newRow=mailGrid.insertRow(rows-1); mailGrid.setText(newRow, 0, rid); mailGrid.setText(newRow, 1, uName); mailGrid.setText(newRow, 2, uEmail); int turn = 0; if(uActivity.booleanValue()){ turn = 1; } ActiveButton uActive = ↵ new ActiveButton(mailGrid,turn); mailGrid.setWidget(newRow, 3, uActive); mailGrid.setWidget(newRow,4, ↵ new delButton(mailGrid,newRow)); }

EOF

Dolce Vita

100

Визитка


Что такое LIRC?LIRC (Linux Infrared Remote Control) – набор драйверов и программ для ОС Linux, предназначенный для приема сиг-налов от инфракрасных пультов дистанционного управле-ния (ПДУ), передачи таких сигналов, а также для управления другими программами с этих пультов. LIRC поддерживает большое количество приемников/передатчиков сигнала и почти любой ПДУ.

Упрощенная схема работы LIRC изображена на рис. 1. Сигналы от ПДУ принимаются приемником и с помощью

модуля ядра отображаются на виртуальное устройство /dev/ lircX. Первый загруженный драйвер использует устройство /dev/lirc0, следующий – /dev/lirc1 и т.д. Эти сигналы декоди-руются демоном lircd, к которому могут подключаться другие программы через сокет /var/run/lirc/lircd. Программы, входя-щие в LIRC, такие как irexec, irxevent, а также любые другие, могут читать декодированные сигналы непосредственно из этого сокета, а также с помощью библиотеки liblircclient.

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

Сигналы с ПДУ принимаются датчиком IC1 и поступают на вход DCD последовательного порта. Питание для датчика берется с выхода RTS-порта, но поскольку ему нужно на-пряжение +5 В, а на выходах стандартного COM-порта на-пряжение около 10-12 В, то на элементах IC2, R1, D1 и C1 собран преобразователь напряжения 12 В – 5 В (для рабо-ты IC2 нужно входное напряжение не менее 7 В, поэтому на некоторых ноутбуках, где на выходах последовательно-го порта меньшее напряжение, схема работать не будет). На схеме приведена разводка разъема последователь-ного порта с 9 выводами, если у вас 25-портовый разъем, то на нем DCD – 8-й вывод, GND – 7-й, а RTS – 4-й.

Датчик IC1 марки TSOP 1738 или аналогичный (пол-ный список можно найти на странице http://www.lirc.org/ receivers.html) (см. рис.3). Вместо 78L05 (IC2) можно взять

советский аналог КР142ЕН5 (левый вывод – вход, правый – выход, средний – заземляем) (см. рис. 4). Диод D1 подойдет любой.

Я собрал свой приемник навесным монтажом в корпусе старой мыши (см. рис. 5).

УстановкаДля установки LIRC можно использовать два варианта: сборка из исходных текстов или установка из готовых паке-тов вашего дистрибутива.

Установка из исходных текстов подробно описана в до-кументации на странице http://www.lirc.org/install.html. Я же устанавливал LIRC на свой Ubuntu 9.10 из менеджера паке-тов. Просто установите lirc и lirc-x со всеми зависимостями. Вы обнаружите у себя необходимые утилиты и демоны, а так-же документацию в каталоге /usr/share/doc/lirc/html. Драйве-ров в этих пакетах нет, они включены в стандартное ядро.

Настройка LIRCНастройка LIRC сводится к ручной правке некоторого коли-чества конфигурационных файлов.

В первую очередь нужно определиться с модулем ядра принимающего устройства. В документации приведена та-блица поддерживаемого оборудования (/usr/share/doc/lirc/ html/table.html), где можно узнать необходимый вам модуль ядра, драйвер и типы ПДУ, которые данный приемник под-держивает. (Следует учесть, что некоторые приемники под-держивают любые пульты, а некоторые – только те, которые поставляются с ними в комплекте, в таблице они обозна-чаются bundled.) К моему настольному компьютеру я под-ключал самодельный приемник, а на ноутбуке настраивал встроенный инфракрасный порт (IrDA).

В первом случае нужно использовать модуль ядра lirc_serial:

По умолчанию используется первый последовательный порт /dev/ttyS0, но вы можете это изменить, задав явно адрес и прерывание порта:

Если хотите использовать ваш ПК в качестве ме-диацентра, смотреть фильмы и слушать музыку, не вставая с дивана, вам нужен LIRC!

Три в одномУправление Linux с помощью LIRC

ОЛЕГ ВОРОНИН, окончил Хмельницкий университет по специальности инженер-системотехник. Хобби – программирование на всем, на чем можно программировать

$ sudo modprobe lirc_serial

Dolce Vita


Все параметры модуля можно посмотреть с помощью ко-манды modinfo:

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

Иногда модуль не загружается, поскольку последова-тельный порт уже занят:

Тогда установите пакет setserial и выполните команду:

Для установки LIRC есть два ва-рианта: сборка из исходных тек-стов или установка из готовых пакетов вашего дистрибутива

$ sudo modprobe lirc_serial io=0x2f8 irq=3

filename: /lib/modules/2.6.31-16-generic/kernel/ ubuntu/lirc/lirc_serial/lirc_serial.ko license: GPLauthor: Ralph Metzler, Trent Piepho, Ben Pfaff, Christoph Bartelmus, Andrei Tanasdescription: Infra-red receiver driver for serial ports. srcversion: B438F3E79E374F0A09BD6FCdepends: lirc_devvermagic: 2.6.31-16-generic SMP mod_unload modversions 586parm: type:Hardware type (0 = home-brew, 1 = IRdeo, 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug) (int)parm: io:I/O address base (0x3f8 or 0x2f8) (int) parm: irq:Interrupt (4 or 3) (int)parm: share_irq:Share interrupts (0 = off, 1 = on) (bool)

$ modinfo lirc_serial

parm: sense:Override autodetection of IR receiver circuit (0 = active high, 1 = active low ) (bool)parm: txsense:Sense of transmitter circuit (0 = active high, 1 = active low ) (bool) parm: softcarrier:Software carrier (0 = off, 1 = on) (bool)parm: debug:Enable debugging messages (bool)

FATAL: Error inserting lirc_serial (/lib/modules/ 2.6.31-16-generic/kernel/ubuntu/lirc/lirc_serial/ lirc_serial.ko): Device or resource busy

$ sudo modprobe lirc_serial

Рисунок 1. Упрощенная схема работы LIRC Рисунок 2. Схема приемника ИК-сигналов

Dolce Vita


После этого модуль должен загрузиться.Примечание: если вы используете команду fuser

для того, чтобы определить, какой процесс блокирует по-следовательный порт, у вас ничего не выйдет. Как указано в документации к LIRC, ядро Linux использует для последо-вательных портов стандартный драйвер в виде модуля или встроенный в ядро. Этот драйвер «захватывает» все порты, которые обнаружит, и поэтому драйверы LIRC (модули ядра) не могут эти порты использовать. Можно загрузить модуль LIRC раньше модуля ядра для стандартного COM-порта, но проблема в том, что обычно стандартный драйвер после-довательного порта не компилируется как модуль! Поэтому необходимо использовать setserial, который освобождает захваченный порт.

Однако эти изменения сохраняются только до переза-грузки компьютера, а вам нужно будет обеспечить запуск setserial при каждой загрузке до запуска LIRC. Обычно это настраивается автоматически при установке пакета setserial, в таком случае в файл /var/lib/setserial/autoserial. conf добавьте строку:

Если автоматическая настройка у вас не прошла, по-пробуйте другой способ, добавив строчку в файл /etc/init.d/ boot.local:

Для встроенного инфракрасного порта мне пришлось зайти в BIOS ноутбука и принудительно задать ему режим IrDA и второй последовательный порт (io=0x2f8). После чего загружаем модуль lirc_sir:

Проверяем, все ли нормально:

Как видите, должен автоматически загрузиться и модуль lirc_dev.

Если вы передаете модулю параметры, то вам нужно сде-лать так, чтобы они задавались автоматически. Для этого в каталоге /etc/modprobe.d создайте файл имя_модуля.conf и пропишите в нем необходимые параметры, например /etc/ modprobe.d/lirc_serial.conf:

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

После того как модули были успешно загружены, можно проверить работоспособность приемника с помощью про-грамм mode2 или xmode2:

Эти программы читают информацию из устройства, ука-занного вами, и отображают ее на экране, mode2 – в тек-стовом, а xmode2 – в графическом виде. У вас должно по-лучиться примерно как на рис. 6, это значит, что приемник работает!

Теперь нам нужно настроить демон lircd, который занима-ется декодированием сигналов, поступающих с приемника, в названия нажатых клавиш ПДУ.

Для конфигурации lircd используются два файла: /etc/lirc/ hardware.conf, который отвечает за настройку приемника, и /etc/lirc/lircd.conf, содержащий профили ПДУ, использую-щиеся с приемником.

Файл /etc/lirc/hardware.conf простой и достаточно проком-ментированный, поэтому настроить его не составит труда, у меня вышел такой файл (для IrDA, встроенного в ноутбук):

$ sudo setserial /dev/ttyS0 uart none

$ sudo xmode2 -d /dev/lirc0

/dev/ttyS0 uart none

#Пульт, можно вписать любое названиеREMOTE="panasonic"#Список автоматически загружаемых модулейREMOTE_MODULES="lirc_sir"#Драйвер (см.таблицу /usr/share/doc/lirc/html/table.html) REMOTE_DRIVER="default"#Устройство, с которого считывать сигналREMOTE_DEVICE="/dev/lirc0"REMOTE_SOCKET=""REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS=""

setserial /dev/ttyS0 uart none

$ sudo modprobe lirc_sir io=0x2f8

options lirc_serial io=0x2f8 type=0

lirc_sir 15268 0lirc_dev 10804 1 lirc_sir

$ lsmod | grep lirc

Рисунок 3. Датчик IC1 марки TSOP 1738 Рисунок 5. Приемник навесным монтажом в корпусе старой мыши

Рисунок 4. Советский аналог КР142ЕН5

Dolce Vita


Обязательно нужно задать параметры REMOTE_MODULES, REMOTE_DRIVER, REMOTE_DEVICE.

Файл /etc/lirc/lircd.conf должен соответствовать вашему ПДУ. Несколько готовых файлов устанавливаются вместе с пакетом lirc, также огромная база ПДУ есть на сайте LIRC (http://www.lirc.org/remotes). Возьмите файл с профилем ва-шего пульта и скопируйте его в файл /etc/lirc/lircd.conf. Если же вашего пульта в базе нет, не отчаивайтесь, вы можете настроить его вручную с помощью команды irrecord:

Вам будет предложено понажимать все клавиши на ПДУ, а затем задать название для каждой клавиши. Если что-то пойдет не так, попробуйте ту же команду с дополнительным параметром -f, который заставит irrecord не дешифровать коды, получаемые с пульта, что может помочь с некоторыми ПДУ. На выходе у вас будет файл, имя которого вы задали, вам останется всего лишь скопировать его в файл /etc/lirc/ lircd.conf. Формат этого файла разбирать не будем, скажу лишь, что в нем может находиться описание сразу несколь-ких пультов, но у них должны быть разные названия.

Все готово, можно запускать демон lircd:

Если что-то пошло не так, еще раз проверьте конфигу-рационные файлы /etc/lirc/lircd.conf и /etc/lirc/hardware.conf.

Если демон запустился, можно проверить его работу про-граммой irw, которая читает из сокета /var/run/lirc/lircd назва-ния нажатых клавиш пульта. Просто запустите программу и попробуйте понажимать клавиши:

В выводе программы первая колонка – код клавиши

из файла /etc/lirc/lircd.conf, вторая – количество повторе-ний нажатия, третья – название клавиши, четвертая – на-звание ПДУ. Демон lircd настроен.

Использование LIRCТеперь нам нужно настроить программы, которыми вы бу-дете оперировать при помощи пульта управления. Есть два типа таких программ: те, которые поддерживают управле-ние через lirc, и те, которые о нем ничего не знают.

Проще всего настроить программы первого типа. Они ис-пользуют библиотеку liblircclient и файл настройки ~/.lircrc. Этот файл состоит из таких секций:

prog – имя программы, которая будет реагировать на дан-ную секцию, например mplayer.remote – название ПДУ, которым посылается сигнал. Должно соответствовать названию пульта в файле /etc/ lirc/lircd.conf. Можно в качестве имени пульта использо-вать знак звездочки (*), что будет означать любой ПДУ.button – название клавиши ПДУ. Должно соответство-вать названию клавиши пульта в файле /etc/lirc/lircd.conf. Можно в качестве имени клавиши использовать *, что бу-дет означать любую клавишу ПДУ. Секций button может быть несколько, что будет соответствовать последова-тельному нажатию нескольких клавиш.repeat – задает поведение программы, если клавиша по-вторяется (длинное нажатие клавиши). При значении 0 повторы клавиши игнорируются. При значении 1 дейст-вие выполняется каждый повтор, при 2 – каждый второй повтор и т.д.delay – пропустить указанное число повторов клавиши, перед тем как использовать конфигурацию repeat.config – строка, которая будет передана программе prog при нажатии соответствующих клавиш. Если задается несколько строк config, они будут отсылаться программе по очереди, то есть при первом нажатии клавиши пере-дается первая строка, при втором – вторая, при третьем – опять первая и т.д. Для каждой программы существуют свои управляющие строки, которые можно найти в доку-ментации к этой программе.

$ sudo irrecord -d /dev/lirc0 lg.conf -n

* Loading LIRC modules [ OK ] * Starting remote control daemon(s) : LIRC [ OK ]

0000bffbf6fffff6 00 stop panas 0000bffbf6ff3f36 00 ff panas 0000bffbf6ff535a 00 down panas 0000bffbf6ff939a 00 vtr/tv panas 0000bffbf6fffff6 00 stop panas 0000bffbf6fffff6 01 stop panas

$ sudo service lirc start

$ irw

begin prog = ... remote = ... button = ... [button = ...] repeat = ... delay = ... config = ... [config = ...] mode = ... flags = ... end

#ПередатчикTRANSMITTER="None" TRANSMITTER_MODULES=""TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="" TRANSMITTER_SOCKET=""TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS=""

#Запускать lircd?START_LIRCD="true"

#Автоматически загружать модулиLOAD_MODULES="true"

Рисунок 6. Проверка работоспособности приемника

Dolce Vita


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

flag – флаги. Могут быть такими:once – секция выполняется один раз при входе в соот-ветствующий режим mode;quit – прекращает обработку файла, дальнейшие сек-ции рассматриваться не будут;mode – выйти из текущего режима;startup_mode – запустить программу в режиме mode, например:

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

Давайте для примера сконфигурируем проигрыватель mplayer. Список команд для него можно получить, набрав:

Запишем такой код в файл .lircrc (допустим, у нас есть пульт с названием panas):

Как вы видите, в каждой секции задается пульт стро-кой remote=panas, программа prog=mplayer, кнопка пуль-та button, и действие config, соответствующее указанной кнопке. Для повторяющихся кнопок, таких как увеличение и уменьшение громкости, обязательно задаем repeat=1, то есть когда мы держим кнопку нажатой, строка config пе-редается в программу постоянно.

Примечание: если вы хотите облегчить создание фай-ла конфигурации, попробуйте программу mythbuntu-lirc-generator. Она попытается самостоятельно создать кон-фигурационные файлы для программ mplayer, elisa, mythtv, totem, vlc, xine, xmame и xmess, используя файл конфигура-ции вашего ПДУ /etc/lirc/lircd.conf

Все эти секции распознаются уже работающей програм-мой mplayer, но ее еще нужно запустить. Тут нам на помощь придет программа irexec. Она предназначена для запуска других программ с помощью ПДУ.

Задайте в файле ~/.lircrc секцию для irexec:

Далее запускаем программу irexec в режиме демона:

Нам нужно сделать, чтобы она запускалась автоматиче-ски при входе в систему, например, выбрав «Система → Па-раметры → Запускаемые приложения» в настройках Gnome и добавив в список запускаемых программ irexec -d.

Теперь при нажатии кнопки vtr/tv пульта panas будет за-пущен gmplayer.

Касательно программ, которые не поддерживают LIRC напрямую. Если они могут управляться с клавиатуры, то ис-пользуем программу irxevent, если же нет, то в LIRC есть эмулятор мыши.

Программа irxevent позволяет эмулировать нажатие кла-виш клавиатуры или кнопок мыши. Конфигурируется она опять же через файл ~/.lircrc таким образом:

В данном случае нажатие клавиши <F> отправляется в текущее окно.

Клавиши можно задавать так:

begin flags = startup_mode mode = browserend

include ~/.lirc/xawtv

$ mplayer -input cmdlist

$ irexec -d

[shift-][numlock-][ctrl-][alt-][meta-][mod3-][mod4-] ↵[scrlock-]Keyname

begin remote = panas button = display prog = irxevent config = Key F CurrentWindow end

begin remote = panas button = vtr/tv prog = irexec config = gmplayer & end

begin remote = panas prog = mplayer button = operate config = quit endbegin remote = panas prog = mplayer button = reset config = vo_fullscreen endbegin remote = panas prog = mplayer button = up config = volume +10 repeat = 1end begin remote = panas prog = mplayer button = down config = volume -10 repeat = 1end begin remote = panas prog = mplayer button = pause config = pause end

begin remote = panas prog = mplayer button = ff config = seek +30 0

begin mode ... end mode

repeat = 1 endbegin remote = panas prog = mplayer button = rew config = seek -30 0 repeat = 1end

Dolce Vita


Например, ctrl-c, SHIFT-KP_Subtract и т.д. Названия кла-виш берутся из файла /usr/include/X11/keysymdef.h. Кроме того, можно посылать нажатия не только в текущее окно, но и в любое другое, поставив вместо CurrentWindow имя окна или его идентификатор. Их можно узнать с помо-щью программы xwininfo.

Нажатия кнопок мыши эмулируются так:

где 1 – номер кнопки мыши, а 15 и 95 – координаты курсора, в которых производится нажатие.

Опять же программу irxevent после настройки следует за-пустить как демон:

Замечу, что irxevent работает не очень надежно, поэтому иногда лучше использовать xdotool. Она позволяет переда-вать целые строки другим программам, перемещать курсор мыши и даже переключать рабочие столы. Просто устано-вите пакет xdotool и задайте конфигурацию для него через программу irexec:

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

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

Сначала сконфигурируем lircd, добавив в файл /etc/ hardware.conf строку (это заставить компьютер запускать lircmd при старте lircd):

Затем нужно составить файл конфигурации /etc/lirc/ lircmd.conf для демона lircmd. Он состоит из следующих ин-струкций:

Выбор протокола мыши. Можно выбирать между MouseSystems, IntelliMouse и IMPS/2. Лучше выбрать IntelliMouse, так как он поддерживает колесо.

Обычно курсор мыши передвигается на один пиксель при каждом нажатии кнопки на пульте, но это очень медлен-но. При использовании данной инструкции, если вы будете удерживать кнопку управления курсором, скорость переме-щения будет увеличиваться, после того как количество пов-торов достигнет значения start, до значения repeat*multiplier, но не более max.

или

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

Задает кнопку пульта для перемещения курсора мыши в указанном направлении:

Задает кнопку пульта для вращения колеса мыши вверх и вниз соответственно.

Назначает кнопку пульта для нажатия кнопки мыши (x=1 – левая кнопка, x=2 – средняя, x=3 – правая).

В этом файле использование * вместо названия ПДУ означает выбор любого пульта для управления.

Вот приблизительно что вышло у меня:

Можно перезапускать lirc:

START_LIRCMD="true"

TOGGLE_ACTIVATE <remote> <button>

config = Button 1 15 95 Mplayer

$ irxevent -d

MOVE_[ N [ E | W ] | E | S [ E | W ] | W ] <remote> <button>

BUTTONx_CLICK <remote> <button>

NW N NE W X E SW S SE

MOVE_[IN|OUT] <remote> <button>

PROTOCOL IntelliMouse ACCELERATOR 2 30 5 ACTIVATE * recMOVE_N * 2 MOVE_NE * 3 MOVE_E * 6 MOVE_SE * 9 MOVE_S * 8 MOVE_SW * 7 MOVE_W * 4 MOVE_NW * 1BUTTON1_CLICK * recall BUTTON2_CLICK * 0 BUTTON3_CLICK * enter MOVE_IN * upMOVE_OUT * down

ACCELERATOR <start> <max> <multiplier>

ACTIVATE <remote> <button>

PROTOCOL <protocol>

begin remote = panas button = display prog = irexec config = xdotool key ctrl+alt+n end

#!/bin/sh# Activate Firefox and paste the clipboard contents # into the url barwid=`xdotool search --title "Mozilla Firefox"` xdotool windowactivate $widsleep 0.2xdotool key "ctrl+j" xdotool key "BackSpace" xdotool key "ctrl+v" xdotool key "Return"

* Stopping remote control mouse daemon: LIRCMD [fail] * Stopping remote control daemon(s): LIRC [ OK ] * Loading LIRC modules [ OK ] * Starting remote control daemon(s) : LIRC [ OK ] * Starting remote control mouse daemon : LIRCMD [ OK ]

$ sudo service lirc restart

Dolce Vita


Но это еще не все, теперь осталось подключить нашу виртуальную мышь к серверу Xorg. Для этого добавим в файл /etc/X11/xorg.conf следующую секцию:

Затем в секцию ServerLayout нужно добавить такую стро-ку к уже имеющимся:

После чего в секцию ServerFlags добавим:

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

В вашем домашнем каталоге появится файл xorg.conf.new, содержащий конфигурацию Xorg по умолчанию. Скопируй-те его в файл /etc/X11/xorg.conf, внесите все необходимые правки и перезагрузите Xorg.

Можно пробовать виртуальную мышь. Сначала нажмите выбранную вами клавишу для включения режима эмуляции, затем попробуйте подвигать курсором. Если что-нибудь у вас не получается, в первую очередь проверьте, запустил-ся ли lircmd, существует ли файл /var/run/lircm, и, наконец, проверьте логи Х-сервера.

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

Если вы используете KDE, попробуйте очень неплохую программу IrKick (находится в пакете kdelirc). Она поз-воляет назначать действия клавишам пультов в графи-ческом режиме (см. рис. 7), но lircd уже должен быть на-строен, то есть IrKick можно рассматривать как замену ~/.lircrc+irexec+irxevent для KDE.

В ней можно использовать несколько пультов, для каждо-го из которых создать несколько режимов. Кроме запуска других программ, можно посылать сообщения по DBus за-пущенным приложениям KDE, для чего существует удобный мастер настройки. Также есть модули расширения, позво-ляющие управлять Amarok, Konqueror, регулировать звук, выключать компьютер.

Передача инфракрасных сигналовЕсли у вас есть не только приемник, но и передатчик ИК-сигналов, то с помощью LIRC можно и передавать инфра-красные сигналы управления, используя компьютер в ка-честве универсального ПДУ. К самодельному приемнику можно легко добавить ИК-диод, а если есть IrDA-порт в но-утбуке, то передатчик у вас уже имеется.

Передача сигналов реализуется программой irsend:

Remote – пульт, нажатие кнопки которого эмулируется; Button – собственно кнопка указанного пульта (как ука-зано в файле /etc/lirc/lircd.conf);Directive – может быть одним из вариантов:

SEND_ONCE – послать нажатие кнопки один раз; SEND_START – нажать кнопку пульта (посылает по-вторяющиеся сигналы);SEND_STOP – отпустить кнопку пульта.

Например:

LIRC для WindowsСуществует реализация LIRC для Windows, которая называ-ется WinLIRC. Правда, она давно не обновлялась, но работа-ет. Существенный ее недостаток – поддержка только само-дельных приемников, подключаемых к последовательному порту. WinLIRC поддерживается некоторыми популярными программами, например, WinAMP, BSPlayer, VLC, LightAlloy.

Конфигурирование WinLIRC сводится к обучению ее ва-шему пульту. Если нашли подходящий конфигурационный файл для вашего ПДУ, можете попробовать его. WinLIRC сидит в трее и мигает значком при нажатии кнопок на пуль-те. Сторонние программы взаимодействуют с ней через TCP по адресу 127.0.0.1:8765.

Что получилось?Надеюсь, ваша борьба с конфигурационными файлами LIRC завершится победой, и вы почувствуете неимоверное удобство этого инструмента. Пишите на форум, постараюсь ответить на все вопросы. Успехов!

1. Официальный сайт LIRC, где можно загрузить исходные тексты, конфигурационные файлы для ПДУ и почитать документацию (на английском) – http://www.lirc.org.

2. Программу WinLIRC для Windows – http://winlirc.sourceforge.net.

InputDevice "LIRC-Mouse"

Option "AllowEmptyInput" "false"

$ Xorg -configure irsend DIRECTIVE REMOTE BUTTON [BUTTON...]

$ irsend SEND_ONCE panas operate

Section "InputDevice" Identifier "LIRC-Mouse" Driver "mouse" Option "Device" "/var/run/lirc/lircm" Option "Protocol" "IntelliMouse" Option "SendCoreEvents" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection

EOF

Рисунок 7. Программа IrKick



ВЛАДИМИР ГАКОВ, журналист, писатель-фантаст, лектор. Окончил физфак МГУ. Работал в НИИ. С 1984 г. на творческой работе. В 1990-1991 гг. – Associate Professor, Central Michigan University.

С 2003 г. преподает в Академии народного хозяйства. Автор 8 книг и более 1000 публикаций

Нелепая ошибка привела к открытию, которое при-несло его авторам Нобелевскую премию

История транзисторовБуревестники кремниевой революции

Более шестидесяти лет назад, 23 де-кабря 1947 года, три американских физика, Уильям Шокли, Джон Бардин, Уолтер Браттейн, продемонстрировали коллегам новый прибор – полупровод-никовый усилитель, или транзистор. Он был миниатюрнее, дешевле, проч-нее и долговечнее радиоламп, а кро-ме того, потреблял гораздо меньше энергии. Словом, открытие стало на-стоящим рождественским подарком трех «санта-клаусов» человечеству – именно с этого основного элемента интегральных схем началась Великая кремниевая революция, приведшая к появлению общепринятых сегодня «персоналок».

Все трое получили заслуженную Нобелевскую премию, а Бардин впос-ледствии ухитрился получить и вто-рую – в 1972-м, за создание микроско-пической теории сверхпроводимости (вместе с Леоном Купером и Джоном Шриффером – о чем ниже). Судьба Уи-льяма Шокли вообще сложилась очень любопытно.

Усилитель технического прогрессаИстория изобретения полупроводни-ковых усилителей – транзисторов – вышла драматичной, несмотря на ее скоротечность. Вся она уместилась в два послевоенных десятилетия, но чего в ней только не было! Тут и по-разительные «пролеты» конкурентов удачливой тройки: находясь в букваль-ном смысле в сантиметрах от откры-тия, они не разглядели его и прошли мимо, в том числе и мимо светившей

им Нобелевской премии. Ученики на-столько хорошо усвоили идеи учителя, что чуть было не оставили его самого без означенной «нобелевки», так что раздосадованному шефу пришлось за неделю совершить невозможное, чтобы нагнать свою чересчур шуструю команду. Да и сам транзистор появил-ся на свет, как это часто случалось, в результате нелепой ошибки одного из героев этой истории, измученно-го затяжной полосой неудач. Ну и, наконец, не менее поразительная «слепота» масс-медиа, сообщивших об одном из главных технологических переворотов ХХ века… мелким шриф-том на последних полосах!

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

Тут не статью – увлекательный ро-ман писать впору!

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

К решению этой задачи одновременно подбирались несколько ученых и це-лые исследовательские группы.

Хотя все началось еще раньше – в 1833 году, когда англичанин Майкл Фарадей обнаружил, что электропро-водность сульфида серебра увеличи-вается при нагревании. Спустя без ма-лого век, в 1926-м, соотечественник Фарадея Джулиус Эдгар Лилиенфилд получил патент под названием «Метод и прибор для управления электриче-скими токами», фактически предвос-хитив, но так и не построив транзи-стор. А по окончании Второй мировой войны изучением электропроводных свойств полупроводниковых мате-риалов занялись специалисты иссле-довательской фирмы Bell Telephone Laboratories, чья штаб-квартира рас-полагалась в Марри-Хиллз (штат Нью-Джерси).

Именно там под руководством вид-ного теоретика Уильяма Шокли был создан один из первых «мозговых цент-ров» в истории американской науки. Шокли еще до войны пытался решить задачу повышения проводимости по-лупроводников с помощью внешнего электрического поля. Эскиз прибора в рабочем журнале ученого за 1939 год весьма напоминал нынешний полевой транзистор, однако испытания тогда закончились неудачей.

К концу войны в полупроводники успели поверить многие коллеги Шок-ли и, что самое главное, потенциаль-ные заказчики и инвесторы – большой бизнес и «оборонка». На них произ-

Визитка



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

Первым делом Шокли пригласил в Марри-Хиллз бывшего однокашни-ка – теоретика Джона Бардина, пере-манив его из университета простым способом: предложил в два раза больший оклад. Кроме них двоих, в состав группы входила еще пятерка специалистов: теоретик, два экспери-ментатора, физико-химик и инженер-электронщик. Капитан этой команды ученых поставил перед ними ту же за-дачу, над которой бился до войны.

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

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

Друзья-коллеги так и поступили, и снова ничего. Казалось, дело зашло в тупик, но тут законченный трудого-лик Браттейн, про которого говорили, что он может крутить ручки осцилло-графа по 25 часов в сутки («лишь бы было с кем поболтать»), неожидан-но сорвался и совершил непрости-тельную для профессионала ошиб-ку. Что он там замкнул не так и какие полюса перепутал, в состоянии по-нять и оценить по достоинству только специалист-физик, для остального человечества важен результат той до-садной ошибки, ставшей поистине зо-лотой. Подсоединив электрод не туда, куда надо, Браттейн с удивлением за-фиксировал резкое усиление входного сигнала: полупроводник заработал!

Проваленная премьераПервым, кто сразу же оценил всю прелесть совершенной ошибки, был Бардин. Вместе с Браттейном он про-должил движение в «неправильном» направлении, начав экспериментиро-вать с кристаллом германия, обладав-шим большим, чем у кремния, сопро-тивлением. И 16 декабря 1947 года друзья продемонстрировали осталь-

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

Это был уродливый на вид герма-ниевый брусок с торчащими из него закрученными усиками-электродами. Как именно он действует, в ту пору по-нимал, очевидно, один только Бардин: выдвинутая им по горячим следам ги-потеза об инжекции (испускании) за-рядов одним электродом (эмиттером) и их собирании другим электродом (коллектором) была выслушана кол-легами в недоуменном молчании. Спе-циалистов можно было понять – под-тверждения теоретической правоты Бардина пришлось ждать годы.

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

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

Вдвойне несправедливо было и то, что Шокли раньше других оценил со-вершенно фантастические перспекти-

Нарушитель конвенцииВ случае с Джоном Бардиным члены Шведской

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

в более чем вековой истории Нобелевских

премий пошли на нарушение ее статута. Один

из его пунктов запрещает присуждать премии

дважды в одной номинации. Однако отме-

тить успех сотрудников Бардина (очевидный

для членов комитета и всего мирового науч-

ного сообщества) и при этом проигнориро-

вать главного виновника торжества было бы

просто неприлично, и американскому физику

сделали исключение.

Анди Гроув, Роберт Нойс и Гордон МурУильям Шокли, Джон Бардин и Уолтер Браттейн



вы, которые сулил транзистор в иной области – стремительно прогресси-ровавшей вычислительной технике. Тут уже определенно светила «нобе-левка», и Шокли, обладавший често-любием и болезненным самолюбием, совершил фантастический рывок, чтобы успеть на уходящий поезд. Бук-вально за неделю ученый создал тео-рию инжекции и более основательную, чем бардинская, теорию транзистора – так называемую теорию p-n-переходов. А в новогоднюю ночь, когда коллеги исследовали в основном оставшие-ся с рождественских гуляний бутылки из-под шампанского, придумал еще один тип транзистора – плоскостной (его еще называют «бутербродный»).

Героические усилия честолюби-вого Шокли не пропали даром – спу-стя восемь лет он вместе с Бардиным и Браттейном разделил заветную Но-белевскую премию. На торжествах в Стокгольме, кстати, вся тройка в по-следний раз собралась вместе и боль-ше никогда в полном составе не встре-чалась.

Через полгода после удачной пре-мьеры транзистора в нью-йоркском офисе фирмы состоялась презента-ция для прессы нового усилителя. Од-нако реакция СМИ вопреки ожиданиям оказалась более чем вялой. На одной из последних полос (46-й) газеты The New York Times от 1 июля 1948 года в разделе «Новости радио» появилась короткая заметка – и все. Сообщение явно не тянуло на мировую сенсацию – с конца июня все американские и ми-ровые СМИ были заняты обсуждением другой новости – советской блокады Западного Берлина, начатой за неделю до презентации транзистора. Изобре-тение троих ученых померкло на фоне репортажей о «воздушном мосте», с помощью которого американцы до-ставляли в блокированный сектор Бер-лина продукты питания и прочие пред-меты первой необходимости.

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

в неожиданной области – слуховых аппаратов.

Микроэлектроника и макроевгеникаСреди прочих на нью-йоркской пре-зентации присутствовал еще один бу-дущий нобелевский лауреат – в ту пору инженер небольшой фирмы Centralab Джек Сент-Клер Килби. Вдохновив-шись увиденным, он наладил в своей фирме производство первых в мире миниатюрных слуховых аппаратов на транзисторах. А в мае 1958 года Килби перебрался в Даллас и поступил на работу в компанию Texas Instruments, производившую транзисторы, конден-саторы, резисторы и прочие «кубики», из которых собираются электросхемы.

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

Руководство компании пришло в восторг от идеи сотрудника и тут же «нагрузило» его срочным заданием: построить опытную модель схемы, це-ликом сделанной из полупроводника. 28 августа 1958 года Килби продемон-стрировал работавший макет тригге-ра, после чего приступил к изготовле-нию первой монолитной интегральной микросхемы (генератора с фазовым сдвигом) на кристалле германия.

Первый в истории простейший ми-крочип размером со скрепку для бумаг заработал 12 сентября, и этот день так-же вошел в историю. Однако Нобелев-ской премии Джеку Килби пришлось ждать почти полвека – ученый получил ее в последний год ХХ столетия, разде-лив премию с соотечественником, вы-ходцем из Германии Гербертом Креме-ром и российским коллегой Жоресом Алферовым.

Что касается личных и профессио-нальных судеб трех отцов транзисто-ра, то они сложились по-разному. Бар-дин, которого ревнивый до паранойи Шокли начал откровенно «затирать», в 1951 году оставил Bell Telephone Laboratories и перешел на работу в Университет штата Иллинойс в Урба-не. Дополнительным стимулом послу-жил редкий в те времена годовой оклад в $10 тыс. Спустя пять лет профессор Бардин, уже забывший о полупровод-никах и переключившийся на кван-товые системы, услышал по радио о присуждении ему Нобелевской пре-мии. А в 1972-м, как уже говорилось, за созданную вместе с сотрудниками Леоном Купером и Джоном Шриф-фером микроскопическую теорию сверхпроводимости получил и вторую. Умер единственный в истории дважды лауреат Нобелевской премии (в одной и той же номинации!) в 1991 году в воз-расте 82 лет.

Для Уолтера Браттейна, скончавше-гося за четыре года до того, точечный транзистор так и остался пиком науч-ной карьеры.

Зато их руководитель Уильям Шок-ли и после полученной премии актив-

На сенсацию явно не тянуло…«Вчера Bell Telephone Laboratories впервые

продемонстрировала изобретенный ею при-

бор под названием «транзистор», который

в ряде случаев можно использовать в области

радиотехники вместо электронных ламп. При-

бор был применен в схеме радиоприемника,

не содержащего обычных ламп, а также в те-

лефонной системе и телевизионном устройст-

ве. Во всех случаях прибор работал в качестве

усилителя, хотя фирма заявляет, что он может

применяться и как генератор, способный соз-

давать и передавать радиоволны. Транзистор,

имеющий форму маленького металлическо-

го цилиндра длиной около 13 миллиметров,

совсем не похож на обычные лампы, в нем

нет ни полости, из которой откачан воздух,

ни сетки, ни анода, ни стеклянного корпуса.

Транзистор включается практически мгновен-

но, не требуя разогрева, поскольку в нем от-

сутствует нить накала. Рабочими элементами

прибора являются лишь две тонкие проволоч-

ки, подведенные к куску полупроводника ве-

личиной с булавочную головку, припаянному

к металлическому основанию. Полупроводник

усиливает ток, подводимый к нему по одной

проволочке, а другая отводит усиленный ток».

The New York Times, 1 июля 1948 г.



но работал в различных областях, хотя транзисторы вскоре забросил. Любопытно, что с технологической и коммерческой точек зрения его пло-скостной транзистор оказался более перспективным, чем точечный Барди-на и Браттейна: последний продер-жался на рынке лишь до конца 1950-х, в то время как плоскостные выпуска-ются и поныне. И именно на их основе были созданы первые микросхемы.

Но более всего Шокли прославился в сфере, весьма далекой от физики.

А по мнению многих, и от науки вооб-ще. В середине 1960-х годов он неожи-данно увлекся евгеникой, вызываю-щей у многих неприятные ассоциации с арийскими сверхчеловеками, низши-ми расами и тому подобными «приве-тами» из недавнего прошлого. Шокли разработал собственную модифика-цию евгеники – дисгенику. Эта теория говорит о неизбежной умственной деградации человечества, в котором с течением времени вымывается ин-теллектуальная элита (люди с высоким IQ), а их место занимают те, у кого не-достаток интеллекта скомпенсирован избытком репродуктивной функции.

Иными словами – более плодовитыми и более глупыми.

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

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

План Шокли, который он неодно-кратно представлял в американскую Академию наук и правительственные учреждения, предусматривал матери-альное стимулировение людей с низ-

ким IQ, согласившихся на доброволь-ную стерилизацию.

Можно себе представить реакцию коллег Шокли на подобные открове-ния. В 1960-е годы о тотальной по-литкорректности в Америке говорить не приходилось, но и откровенный расизм был уже не в моде. А когда по-добные идеи излагал профессор и но-белевский лауреат, результатом могли быть только шок и возмущение. Пол-ная обструкция со стороны интеллек-туальной элиты сопровождала Шокли до последних дней (он умер от рака в 1989 году).

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

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

Но занятно, что первый толчок науч-ной карьере Нойса дал тот же Шокли – еще до того, как окончательно «сдви-нулся» на расовой почве. В 1955 году будущий нобелевский лауреат покинул компанию Bell Telephone Laboratories и основал собственную фирму

Современные транзисторыИстория развития транзисторов

Подсоединив электрод не туда, куда надо, Уолтер Браттейн с удивле-нием зафиксировал резкое усиление входного сигнала: полупроводник заработал!



Shockley Semiconductor Laboratories в южном пригороде Сан-Франциско – Пало-Альто, где прошло его детство. Так был заложен первый камень в основание легендарной Кремниевой (или Силиконовой) долины.

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

Гениальных идей у «восьмер-ки предателей» (как заклеймил их Шокли) было хоть отбавляй – чего не скажешь о стартовых капиталах. Друзья-компаньоны еще не рожденной компании начали хождение по банкам и инвесторам в поисках денег. И пос-ле нескольких отказов счастливо нат-кнулись на такого же молодого и ам-бициозного финансиста Артура Рока, чьим коньком было как раз привлече-ние инвестиций. Что именно «напели» инженеры-технари бизнесмену, исто-рии неведомо, но, как бы то ни было, он сыграл поистине судьбоносную роль в их будущем бизнесе. А также в судьбе других фирм Кремниевой до-лины, у основателей которых на старте не было ни гроша за душой – одни ге-ниальные идеи и проекты.

С помощью Рока местная компа-ния Fairchild Camera & Instrument со-гласилась инвестировать в новое дело $1,5 млн, но с одним условием: у нее

останется право в будущем выкупить компанию «восьмерки» за вдвое боль-шую сумму – если у тех дела пойдут в гору. Так была создана компания Fairchild Semiconductor, название кото-рой буквально переводится как «Полу-проводник чудо-ребенка» (в немецком варианте – вундеркинда). И вундеркин-ды из Пало-Альто скоро заявили о себе.

Нойс сам себя считал отменным лентяем. И главное изобретение жизни сделал, по его собственным словам, также из лени. Ему надоело наблю-дать, как при изготовлении микро-модулей пластины кремния сначала разрезали на отдельные транзисторы, а затем опять соединяли друг с другом в единую схему. Процесс был трудоем-ким (все соединения паялись вручную под микроскопом) и дорогостоящим. И в 1958 году Нойс наконец сообра-зил, как изолировать друг от друга отдельные транзисторы в кристалле. Так родились всем знакомые микро-схемы – пластинки с графическим ла-биринтом «дорожек» из алюминиевых напылений, отделенных друг от друга изолирующим материалом.

На первых порах микросхемы с тру-дом пробивали себе дорогу на рынок. Но в начале 1970-х все резко измени-лось: после того как в 1969 году Fairchild Superconductor продала определен-ный тип микрочипов (предсказанных Бардиным еще во время работы в Bell Telephone Laboratories) на $15 млн. Спу-стя два года объем продаж той же про-дукции подскочил до $100 млн.

Однако успехи «вундеркиндов» омрачили обычные в таких случаях приоритетные дрязги. Дело в том, что

Джек Килби подал заявку на патент ми-кросхемы в феврале 1959 года, а Нойс сделал это только спустя пять меся-цев. Тем не менее он получил патент первым – в апреле 1961-го, а Килби – только через три года. После этого между конкурентами развязалась де-сятилетняя «приоритетная война», за-кончившаяся мировым соглашением: Апелляционный суд США подтвердил претензии Нойса на первенство в тех-нологии, но одновременно постановил считать Килби создателем первой ра-ботающей микросхемы.

Роберт Нойс не дожил до положен-ной ему по праву Нобелевской премии 2000 года ровно десять лет – в 63-лет-нем возрасте он скончался в своем рабочем кабинете от сердечного при-ступа.

Но до этого он основал вместе с Муром еще одну знаменитую компа-нию. Бросив в 1968 году налаженный бизнес в Fairchild Semiconductor, дру-зья решили назвать свое новое дети-ще без затей: Moore Noyce. Однако по-английски это звучало более чем двусмысленно – почти как more noise («больше шума»), и компаньоны оста-новились на более официальном, зато содержательном названии: Integrated Electronics. Затем их компания неодно-кратно меняла имя, и сегодня каждый пользователь «персоналок» ежеднев-но лицезреет ее логотип с нынешним названием, коротким и звучным – Intel. Который «внутри».

Так спустя два десятилетия после открытия Бардина, Браттейна и Шокли завершилась Великая кремниевая ре-волюция. EOF

МикрочипСовременный микрочипПервый транзистор

подписка на 2010 год


Редакционнная подпискадля физических лиц

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

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

> Журнал высылается почтой заказной бандеролью только пос-ле поступления денег на расчетный счет и копия заполненного и оплаченного бланка, отправленная в редакцию по факсу: (495) 628-8253, (доб. 120) или на e-mail: [email protected]

Подписные индексы:

20780*+ диск с архивом статей 2009 года

81655**без диска

по каталогу агентства «Роспечать»

88099*+ диск с архивом статей 2009 года

87836**без диска

по каталогу агентства «Пресса России»

* Годовой** Полугодовой*** Диск вкладывается

в февральский спецвыпуск журнала, распространяется только на территории России