Image via Wikipedia

Результаты совместной работы ATI HD 5870 и NVIDIA GT 220 с эффектами PhysX25.10.2009 09:07

Как известно энтузиасты смогли обойти ограничение NVIDIA, запрещающее работу видеокарт GeForce в качестве ускорителей PhysX в системах, где присутствуют видеокарты Radeon. Узнать по поводу отношения NVIDIA к существованию данного патча, можно на страницах нашего сайта, а текущая новость посвящена тестированию связки ATI Radeon HD 5870 и NVIDIA GeForce GT 220 в игровых тестах, использующих расширенные эффекты PhysX.

Участник форума Coolaler по прозвищу Soothepain провёл серию тестов с целью предоставить исчерпывающий ответ на два вопроса: «Действительно ли работают конфигурации Radeon-графика и GeForce-физика?» и «Насколько хорошо справляется GeForce GT 220 с задачей специализированного ускорителя PhysX?».

Тестовая система представляла собой следующую конфигурацию:

* 4-ядерный процессор Intel Core i7 975 Extreme.
* 6 Гб оперативной памяти.
* Материнская плата EVGA на базе чипсета X58.
* Операционная система Windows 7 RC7100 64-бит.

Для всестороннего анализа были проведены три различных серии тестов:

1. GeForce GT 220 обрабатывала и графику и физику.
2. Процессор обрабатывал физику, а Radeon HD 5870 — графику.
3. Radeon HD 5870 отвечала за визуализацию, а GeForce GT 220 обеспечивала обработку физики (применялась заплатка GenL Mod).

Тестирование проводилось в 4 игровых проектах, последний из которых — Batman Arkham Asylum с максимальными настройками качества эффектов PhysX.

Как видно, расширенные физические эффекты являются очень сложной задачей для одного из самых мощных на сегодняшний день процессоров, что выступает ограничением для производительности видеокарты Radeon HD 5870. При этом видеокарта начального уровня, GeForce GT 220, легко справляется с непосильной для процессора задачей, занимаясь также ресурсоёмкой визуализацией.

При работе же связки HD 5870 и GT 220 достигается наилучший результат, когда каждый компонент исполняет свою задачу: процессор — передаёт данные и распределяет нагрузку между картами, GT 220 занимается физическими расчётами, а HD 5870 — графическими.

Image by arrayexception via Flickr

В этой статье рассмотрены ключевые моменты по работе с групповыми политиками Active Directory на примере политик Microsoft Windows Server 2003.

Введение
С увеличением парка компьютеров на предприятии все более остро встаёт вопрос о стоимости его управления и содержания. Ручная настройка компьютеров отнимает немало времени у персонала и заставляет, с увеличением количества компьютеров, увеличивать штат обслуживающего их персонала. К тому же при большом количестве машин следить за соблюдением принятых на предприятии стандартов настройки становится всё труднее. Групповые политики (Group Policy) являются комплексным инструментом централизованного управления компьютерами с ОС Windows 2000 и выше в домене Active Directory. К компьютерам под управлением ОС Windows NT4/9x групповые политики не применяются: они управляются системными политиками (System Policy), которые в данной статье рассматриваться не будут.



Объекты групповых политик
Все настройки, которые вы создадите в рамках групповых политик, будут храниться в объектах групповой политики (Group Policy Object, GPO). Объекты групповых политик бывают двух типов: локальный объект групповой политики и объекты групповых политик Active Directory. Локальный объект групповой политики есть на компьютерах под управлением Windows 2000 и выше. Он может быть только один, и это единственный GPO, который может быть на компьютере, не входящем в домен.
Объект групповой политики — это общее название набора файлов, директорий и записей в базе Active Directory (если это не локальный объект), которые хранят ваши настройки и определяют, какие ещё параметры вы можете изменить с помощью групповых политик. Создавая политику, вы фактически создаёте и изменяете объект групповой политики. Локальный объект групповой политики хранится в %SystemRoot%\System32\GroupPolicy. GPO Active Directory хранятся на контроллере домена и могут быть связаны с сайтом, доменом или OU (Organizational Unit, подразделение или организационная единица). Привязка объекта определяет его область действия. По умолчанию в домене создается два объекта групповой политики: Default Domain Policy и Default Domain Controller Policy. В первом определяется политика по умолчанию для паролей и учетных записей в домене. Второй связывается с OU Domain Controllers и повышает настройки безопасности для контроллеров домена.
Создание объекта групповой политики
Для того чтобы создать политику (то есть фактически создать новый объект групповой политики), открываем Active Directory Users & Computers и выбираем, где создать новый объект. Создавать и привязывать объект групповой политики можно только к объекту сайта, домена или OU.

Создание объекта групповой политики.
Чтобы создать GPO и связать его, например, с OU testers щёлкаем правой кнопкой мыши на этом OU и в контекстном меню выбираем properties. В открывшемся окне свойств открываем вкладку Group Policy и нажимаем New.

Создание объекта групповой политики.
Даём название объекту GP, после чего объект создан, и можно приступать к конфигурированию политики. Дважды щёлкаем на созданном объекте или нажимаем кнопку Edit, откроется окно редактора GPO, где вы можете настроить конкретные параметры объекта.

Описание настроек во вкладке Extended.
Большинство основных настроек интуитивно понятны (к тому же имеют описание, если открыть вкладку Extended), и мы не будем подробно останавливаться на каждой. Как видно из рис. 3, GPO состоит из двух разделов: Computer Configuration и User Configuration. Настройки первого раздела применяются во время загрузки Windows к компьютерам, находящимся в этом контейнере и ниже (если не отменено наследование), и не зависят от того, какой пользователь вошел в систему. Настройки второго раздела применяются во время входа пользователя в систему.
Порядок применения объектов групповой политики
Когда компьютер запускается, происходят следующие действия:
1. Читается реестр и определяется, к какому сайту принадлежит компьютер. Делается запрос серверу DNS с целью получения IP адресов контроллеров домена, расположенных в этом сайте.
2. Получив адреса, компьютер соединяется с контроллером домена.
3. Клиент запрашивает список объектов GP у контроллера домена и применяет их. Последний присылает список объектов GP в том порядке, в котором они должны применяться.
4. Когда пользователь входит в систему, компьютер снова запрашивает список объектов GP, которые необходимо применить к пользователю, извлекает и применяет их.
Групповые политики применяются при загрузке OC и при входе пользователя в систему. Затем они применяются каждые 90 минут, с вариацией в 30 минут для исключения перегрузки контроллера домена в случае одновременного запроса большого количества клиентов. Для контроллеров домена интервал обновления составляет 5 минут. Изменить это поведение можно в разделе Computer Configuration\Administrative Templates\System\Group Policy. Объект групповой политики может действовать только на объекты «компьютер» и «пользователь». Политика действует только на объекты, находящиеся в объекте каталога (сайт, домен, подразделение), с которым связан GPO и ниже по «дереву» (если не запрещено наследование). Например: Объект GPO создан в OU testers (как мы сделали выше).

Наследование настроек.
Все настройки, сделанные в этом GPO, будут действовать только на пользователей и компьютеры, находящиеся в OU testers и OU InTesters. Рассмотрим порядок применения политик на примере. Пользователь test, расположенный в OU testers, входит на компьютер comp, находящийся в OU compOU (см. рис. 5).

Порядок применения политик.
В домене существуют четыре GPO:
1. SitePolicy, связанный с контейнером сайта;
2. Default Domain Policy, связанный с контейнером домена;
3. Policy1, связанный с OU testers;
4. Policy2, связанный с OU compOU.
При загрузке Windows на рабочей станции comp, параметры, определённые в разделах Computer Configuration, применяются в таком порядке:
1. Параметры локального GPO;
2. Параметры GPO SitePolicy;
3. Параметры GPO Default Domain Policy;
4. Параметры GPO Policy2.
При входе пользователя test на компьютер comp — параметры, определенные в разделах User Configuration:
1. Параметры локального GPO;
2. Параметры GPO SitePolicy;
3. Параметры GPO Default Domain Policy;
4. Параметры GPO Policy1.
То есть GPO применяются в таком порядке: локальные политики, политики уровня сайта, политики уровня домена, политики уровня OU.
Групповые политики применяются к клиентам с ОС Windows XP асинхронно, а с ОС Windows 2000 — синхронно, то есть пользовательский экран входа появляется только после применения всех политик компьютера, а политики пользователя применяются до того, как появился рабочий стол. Асинхронное применение политик означает, что пользовательский экран входа появляется раньше, чем успевают примениться все политики компьютера, а рабочий стол — раньше, чем применятся все пользовательские политики, что приводит к ускорению загрузки и входа пользователя.
Описанное выше поведение изменяется в двух случаях. Первый — компьютер клиента обнаружил медленное сетевое подключение. По умолчанию в этом случае применяются только параметры настройки защиты и административные шаблоны. Медленным считается подключение с пропускной способностью менее 500 Кб/сек. Изменить это значение можно в Computer Configuration\Administrative Templates\System\Group Policy\Group Policy slow link detection. Также в разделе Computer Configuration\Administrative Templates\System\Group Policy можно настроить некоторые другие параметры политик так, чтобы и они обрабатывались по медленному соединению. Второй способ изменения порядка применения политик — опция User Group policy loopback processing. Эта опция изменяет порядок применения политик по умолчанию, при котором пользовательские политики применяются после компьютерных и перезаписывают последние. Вы можете установить опцию loopback, чтобы политики компьютера применялись после пользовательских политик и перезаписывали все пользовательские политики, противоречащие политикам компьютера. У параметра loopback есть 2 режима:
1. Merge (соединить) — сначала применяется компьютерная политика, затем пользовательская и снова компьютерная. При этом компьютерная политика заменяет противоречащие ей параметры пользовательской политики своими.
2. Replace (заменить) — пользовательская политика не обрабатывается.
Проиллюстрировать применение параметра User Group policy loopback processing можно, например, на общедоступном компьютере, на котором необходимо иметь одни и те же ограниченные настройки, независимо от того, какой пользователь им пользуется.
Приоритетность, наследование и разрешение конфликтов
Как вы уже заметили, на всех уровнях объекты групповой политики содержат одинаковые параметры настройки, и один и тот же параметр может быть определён на нескольких уровнях по-разному. В таком случае действующим значением будет применившееся последним (о порядке применения объектов групповой политики говорилось выше). Это правило распространяется на все параметры, кроме определённых как not configured. Для этих параметров Windows не предпринимает никаких действий. Но есть одно исключение: все параметры настройки учётных записей и паролей могут быть определены только на уровне домена, на остальных уровнях эти настройки будут проигнорированы.

Active Directory Users and Computers.
Если на одном уровне расположены несколько GPO, то они применяются «снизу вверх». Изменяя положение объекта политик в списке (кнопками Up и Down), можно выбрать необходимый порядок применения.

Порядок применения политик.
Иногда нужно, чтобы определённая OU не получала параметры политик от GPO, связанных с вышестоящими контейнерами. В этом случае нужно запретить наследование политик, поставив флажок Block Policy inheritance (Блокировать наследование политик). Блокируются все наследуемые параметры политик, и нет способа блокировать отдельные параметры. Параметры настройки уровня домена, определяющие политику паролей и политику учетных записей, не могут быть заблокированы.

Блокирование наследования политик.
В случае если требуется, чтобы определённые настройки в данном GPO не перезаписывались, следует выбрать нужный GPO, нажать кнопку Options и выбрать No Override. Эта опция предписывает применять параметры GPO там, где заблокировано наследование политик. No Override устанавливается в том месте, где GPO связывается с объектом каталога, а не в самом GPO. Если GPO связан с несколькими контейнерами в домене, то для остальных связей этот параметр не будет сконфигурирован автоматически. В случае если параметр No Override сконфигурирован для нескольких связей на одном уровне, приоритетными (и действующими) будут параметры GPO, находящегося вверху списка. Если же параметры No Override сконфигурированы для нескольких GPO, находящихся на разных уровнях, действующими будут параметры GPO, находящегося выше в иерархии каталога. То есть, если параметры No override сконфигурированы для связи GPO с объектом домена и для связи с GPO объектом OU, действующими будут параметры, определённые на уровне домена. Галочка Disabled отменяет действие этого GPO на данный контейнер.

Как уже было сказано выше, политики действуют только на пользователей и компьютеры. Часто возникает вопрос: «как сделать так, чтобы определенная политика действовала на всех пользователей, входящих в определенную группу безопасности?». Для этого GPO привязывается к объекту домена (или любому контейнеру, находящемуся выше контейнеров или OU, в которых находятся все объекты пользователей из нужной группы) и настраиваются параметры доступа. Нажимаем Properties, на вкладке Security удаляем группу Authenticated Users и добавляем требуемую группу с правами Read и Apply Group Policy.
Определение настроек, действующих на компьютер пользователя
Для определения конечной конфигурации и выявления проблем вам потребуется знать, какие настройки политик действуют на данного пользователя или компьютер в данный момент. Для этого существует инструмент Resultant Set of Policy (результирующий набор политик, RSoP). RSoP может работать как в режиме регистрации, так и в режиме планирования. Для того чтобы вызвать RSoP, следует нажать правой кнопкой на объекте «пользователь» или «компьютер» и выбрать All Tasks.

Рис. 11. Вызов инструмента Resultant Set of Policy.
После запуска (в режиме регистрации, logging) вас попросят выбрать, для какого компьютера и пользователя определить результирующий набор, и появится окно результирующих настроек с указанием, из какого GPO какой параметр применился.

Другие инструменты управления групповыми политиками
GPResult
GPResult — это инструмент командной строки, обеспечивающий часть функционала RSoP. GPResult есть по умолчанию на всех компьютерах с Windows XP и Windows Server 2003.
GPUpdate (Для Windows XP/2003)
GPUpdate принудительно запускает применение групповых политик — как локальных, так и основанных на Active Directory. В Windows XP/2003 пришла на смену параметру /refreshpolicy в инструменте secedit для Windows 2000.
Описание синтаксиса команд доступно при запуске их с ключём /?.
Вместо заключения
Данная статья не преследует цели объяснить все аспекты работы с групповыми политиками, она не ориентирована на опытных системных администраторов. Все вышеизложенное, по моему мнению, лишь должно как-то помочь понять основные принципы работы с политиками тем, кто никогда не работал с ними, либо только начинает осваивать.
Подборку документации по GP, ссылки и ответы на вопросы можно найти на нашем форуме в теме «Групповые политики (Group Policy, GPO): документация, ссылки»
Автор выражает благодарность lynx за поддержку и понимание, а также всем тем, кто помогал в написании этой статьи. Отдельное спасибо kibkalo и dg за помощь и ценные советы.

Image via Wikipedia

В заметке "A Tour Of A "Pay to Download Firefox" Site" представлен обзор зафиксированных в сети многочисленных попыток организации платной загрузки Firefox. Мошенники используют возросшую популярность браузера для того, чтобы продавать изначально бесплатный продукт. В продаже фигурируют давно устаревшие версии Firefox, стандартные расширения по отдельной цене, а также контракты на загрузку обновлений. То что подобные схемы продажи работают, доказывает то, что разработчики Mozilla регулярно получают письма от людей, заплативших за Firefox деньги.

Image via CrunchBase

Microsoft Windows 7 RTM Build 7600.16385 OEM PREINSTALLATION KIT Russian DVD
picГод выпуска: 2009
Версия: OEM
Разработчик: Microsoft
Платформа: Windows 7
Совместимость с Vista: полная
Описание: OEM Preinstallation Kit используется для создания собственной версии Windows 7. Вы можете использовать его для интеграции языковых пакетов, чтобы создать ваши собственные локализации, в том числе процесс настройки. Вы можете также добавить какие-либо программные функции по выбору, что вы хотите, настроить, какие функции будут установлены по умолчанию. Также включены в языковые пакеты для загрузочного Preinstallation Environment.
The OEM Preinstallation Kit is used to build your own custom version of Windows 7. You can use it to integrate language packs to make your own custom localized builds, including the setup process. You can also add any custom software to the install that you want to, and customize what features are installed by default. Also included are the language packs for the bootable preinstallation environment.
If you need english version, go here: http://torrents.ru/forum/viewtopic.php?t=2046107
Русскую качать от сюда: http://torrents.ru/forum/viewtopic.php?t=2193153

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

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

Можно ли заменить службу каталогов от Microsoft открытыми продуктами? Этот вопрос регулярно поднимается в тематических linux-форумах. При такой его постановке возникает ощущение, что мы пытаемся найти свободный аналог изобретения программистов из Редмонда. Но это далеко не так – разработка протоколов для службы каталогов началась еще в 80-е годы прошлого века. Этим занималась международная организация International Telegraph and Telephone Consultative Committee, а созданный ею стандарт (частью которого являлся DAP – протокол доступа к каталогу), впоследствии стал называться X.500. Стоит отметить, что в современных службах каталогов (в том числе Active Directory) используется LDAP (Lightweight Directory Access Protocol) – облегченный вариант DAP. Это связано с избыточной функциональностью первоначальной версии протокола. Кроме того, если говорить о системном ПО, следует различать службу каталогов и прочие сервисы локальной сети (например, файловый сервер или сервер печати). Служба каталогов (Directory Service) – это программный комплекс, позволяющий хранить в одном месте информацию о сетевых ресурсах (общие каталоги, серверы печати, принтеры, пользователи и т.д.) и обеспечивающий централизованное управление ими. Прочие сетевые сервисы (например, файлсервер) могут выступать клиентами службы каталогов.

LDAP – основа службы каталогов

Протокол, используемый для организации доступа к службе каталогов X.500 – LDAP (Lightweight Directory Access Protocol). Это сетевой протокол, работающий поверх TCP/IP. Он позволяет производить операции аутентификации, поиска и сравнения записей. Кроме того, с помощью LDAP можно добавлять, изменять или удалять записи. Чаще всего LDAP-сервер «слушает» порт 389 (TCP или UDP). Для сеансов, инкапсулированных в SSL, обычно используется порт 636.

Записи в каталоге LDAP состоят из атрибутов и обладают уникальным именем (DN – Distinguished Name), которое может выглядеть так: «cn=Иван Иванов, ou=Работники, dc=company, dc=ru». Другими словами, уникальное имя часто состоит из нескольких относительных уникальных имен (Relative Distinguished Name), разделённых запятой. Относительные имена имеют вид «наименование=значение». К чему такие сложности? Это необходимо для создания древовидной иерархической структуры – на одном уровне каталога относительные уникальные имена не могут повторяться. Для наглядности можно сравнить уникальное имя «cn=Петр Сидоров, ou=Работники, dc=company, dc=ru» с предыдущим примером.

Атрибуты записи определяются в описаниях класса (object class), которые объединены в схемы (schema). Схема указывает, какие атрибуты являются обязательными, а также задает их тип и правила сравнения. В зависимости от типа атрибут записи может хранить несколько значений.

Что же касается серверов LDAP, среди открытых реализаций наиболее известен сервер OpenLDAP, а если говорить о проприетарных — это, безусловно, Microsoft Active Directory. Кроме того, службы каталогов, совместимые с LDAP, есть и у других разработчиков, например у Red Hat, Novell и Sun. В качестве LDAP-клиентов используются как ПО конечных пользователей (например, адресные книги почтовых программ), так и различные сетевые службы (файловые серверы, серверы DNS, SMTP и т.д.).

Службы Microsoft и стандарты

Поскольку мы будем довольно часто говорить о продуктах компании Microsoft, остановимся на них подробнее. В Windows NT использовалась собственная разработка Microsoft – Windows NT Directory Services (NTDS). Но уже в Windows 2000 ей на смену приходит Active Directory, основанная на стандартных протоколах. Система аутентификации новой службы каталогов базируется на протоколе Kerberos 5, а для разрешения имен используется DNS с возможностью динамического обновления. Доступ к информации об объектах домена AD осуществляется через LDAP. Естественно, что при таком подходе возникли проблемы обратной совместимости с доменами Windows NT, но освещение этих вопросов выходит за рамки нашей статьи. Главное было сделано – у Microsoft появился сервер каталогов, основанный на стандарте X.500. Казалось бы, все проблемы совместимости с разработками других производителей решены. Однако при реализации открытых протоколов программисты Microsoft внесли в них собственные расширения, затрудняющие взаимодействие между AD и прочими службами каталогов X.500. В цикле, который открывает эта статья, речь в основном пойдет о преодолении подобных трудностей, поскольку настройка служб каталогов (под Windows и Linux) сама по себе проблем администраторам не доставляет. Притом писать мы будем не только и не столько о замене одной службы каталогов на другую, сколько об их взаимодействии между собой. Для начала приведем небольшой обзор открытых программных продуктов.

Серверы каталогов – обзор

OpenLDAP Software

Cайт проекта: http://www.openldap.org/

В рамках OpenLDAP Project ведется разработка открытой кросс-платформенной реализации протокола LDAP. Программное обеспечение распространяется под собственной свободной лицензией (OpenLDAP Public License). В настоящее время доступны версии OpenLDAP для различных операционных систем: FreeBSD, GNU/Linux, IBM AIX, HP-UX, Mac OS X, Solaris, Microsoft Windows и других.

OpenLDAP состоит из трёх главных компонентов:

* slapd – демон LDAP и соответствующие инструменты;
* библиотеки, реализующие протокол LDAP;
* примеры клиентов LDAP: ldapsearch, ldapadd, ldapdelete и др.

Кроме того, существует нескольких дополнительных проектов, предназначенных для разработчиков ПО:

* JLDAP – библиотеки классов LDAP для Java;
* JDBC-LDAP – драйвер интерфейса между Java JDBC – LDAP;
* ldapc++ – библиотеки классов LDAP для C++.

На самом деле, OpenLDAP, работающий в связке с файловым сервером Samba, является полноценной заменой Microsoft Active Directory и файловых серверов под Windows. Единственное, что может заставить UNIX-администратора отказаться от внедрения такого решения – сложность настройки сервера OpenLDAP. Существуют также определенные проблемы совместимости, затрудняющие эксплуатацию продукта в «смешанных» корпоративных сетях, где используются «серверные» продукты компании Microsoft и различные UNIX-системы. Службы каталогов, о которых говорится ниже, в той или иной степени позволяют справиться с этими затруднениями.

Fedora Directory Server (389 Directory Server)

Cайт проекта: http://directory.fedoraproject.org/ или http://port389.org

Сервер каталогов корпоративного уровня с открытым исходным кодом. Разработка проекта ведется сообществом при спонсорской поддержке компании Red Hat. Стоит отметить, что Fedora Directory Server (FDS) является составной частью FreeIPA – централизованного решения для управления информацией о пользователях, политиках и аудита на предприятии.

В 1996 году Netscape привлекает авторов оригинального LDAP-сервера (проект slapd, от которого произошел OpenLDAP) из Университета Мичиган для создания собственного сервера каталогов. В 1999 году AOL покупает Netscape и формирует альянс iPlanet, куда вошла также Sun Microsystems. Этот альянс просуществовал до 2001 года, после чего Nescape и SUN разрабатывали отдельные «форки» сервера каталогов. В 2005 году Red Hat приобретает права на исходные тексты Netscape Directory Server (NDS) и начинает их публикацию. Нетрудно догадаться, что FDS был разработан в рамках проекта Fedora на основе опубликованных компанией RedHat исходных текстов. Сервер состоит из нескольких компонентов, которые распространяются под различными свободными лицензиями (MPL/LGPL/GPL/X License и т.д.). Недавно разработчики решили переименовать проект, и теперь он называется 389 Directory Server (по номеру порта, который «слушает» служба LDAP). Это было сделано, чтобы избежать ассоциации с проектом Fedora, тормозящим (по мнению разработчиков) интеграцию продукта в другие дистрибутивы. К моменту написания статьи 389DS еще не вышел (последний стабильный релиз, доступный на сайте проекта – апрельский Fedora Directory Server 1.2.0), поэтому мы используем старое название.

Основные возможности Fedora Directory Server:

* –поддержка протокола LDAP v3;
* возможность использовать до четырёх равноправных мастер-серверов (предусмотрено автоматическое разрешение конфликтов, балансировка нагрузки и переключение на резервный мастер-сервер в случае выхода основного из строя);
* высокая масштабируемость – разработчики заявляют, что один сервер позволяет обрабатывать тысячи операций в секунду, заводить десятки тысяч пользователей, хранить сотни гигабайт данных и десятки миллионов записей;
* возможность синхронизации с контроллерами домена Active Directory 2000/2003 (необходима установка компонента Windows Sync на контроллер домена);
* консоль администрирования с графическим интерфейсом (доступна под Windows), есть возможность управления из командной строки, а также через Web-интерфейс;
* безопасная аутентификация и транспорт (SSL/TLS и SASL);
* механизм разграничения доступа вплоть до уровня отдельных атрибутов (имени пользователя, групп, IP-адреса, времени суток и т.д.).

Структура FDS довольно проста: ее основной компонент – сам сервер каталогов. Кратко рассмотрим его архитектуру. Здесь можно выделить часть, которая отвечает за сетевую коммуникацию, базовое древо каталогов (DIT) и механизм расширений, с помощью которого реализуются дополнительные функции (например, контроль доступа и репликация). Кроме того, существует прослойка между сервером каталогов и Berkeley DB, которая была адаптирована для NDS компанией Sleepycat Software.

Следующий важный компонент – сервер администрирования (Administration Server). Его задача – управление серверами каталогов (через Web-интерфейс или Java-консоль).

Основным инструментом системного администратора является написанная на Java Fedora Management Console. С ее помощью можно вызывать консоли управления сервером каталогов и сервером администрирования. Взаимодействует FMC с сервером администрирования по протоколам HTTP/HTTPS или напрямую, через LDAP. Кроме того, на сайте проекта доступна версия Fedora Management Console (в виде пакета msi). Еще в состав Fedora Directory Server входят вспомогательные утилиты командной строки для администрирования сервера, переноса данных, миграции пользователей и т.д.

Компания Red Hat выпускает коммерческий Red Hat Directory Server (RHDS) на основе FDS. Главным отличием RHDS от его свободного аналога является наличие технической поддержки с гарантированным временем отклика (включая вариант 24×7).

Mandriva Directory Server (MDS)

сайт проекта: http://mds.mandriva.org/

Компания Mandriva выпустила свой вариант свободно распространяемого сервера каталогов. В отличие от FDS, официальные бинарные сборки которого поставляются только для дистрибутива Fedora, на сайте проекта доступны пакеты для Mandriva Linux 2008.1 и 2009.0, Mandriva Corporate Server 4, а также Debian (Etch и Lenny). Кроме того, продукт включен в Mandriva Enterprise Server 5.

Mandriva Directory Server способен заменить контроллер домена Active Directory. Он позволяет администрировать пользователей, DNS и DHCP-серверы, а также почтовые и прокси-серверы. Архитектура MDS наглядно представлена на рисунке 1. Сервис состоит из двух основных блоков – веб-интерфейса администратора (MMC web interface) и модуля управления сервисами с плагинами, написанными на Python (MMC Agent). Остановимся подробнее на структуре веб-интерфейса. MMC Web interface включает несколько модулей:

* базовый модуль (base module);
* модуль файловых серверов SAMBA (SAMBA module);
* модуль прокси-серверов Squid/Squidguard (Web proxy);
* модуль почтового сервера PostFix (Mail service);
* модуль серверов ISC DHCP и BIND (DNS/DHCP).

MMC Web interface взаимодействует с MMC Agent через XML-RPC. Агент управляет сервисами через собственный API и работает с каталогом LDAP (поддерживаются OpenLDAP и FDS). Сервисы локальной сети в свою очередь являются клиентами службы каталогов.

Таким образом, мы видим, что MDS нельзя назвать полноценным сервером каталогов – скорее это административная надстройка над существующими решениями. Его основная задача – управление каталогом LDAP и сервисами локальной сети. Что же касается масштабирования – Mandriva Directory Server спроектирован с поддержкой от десятков до тысяч записей. Основное преимущество MDS перед аналогичными продуктами – простота установки и настройки. Кроме того, компания Mandriva предлагает коммерческую и техническую поддержку MDS, а также включает его в свои продукты для корпоративных клиентов.

Apache Directory Server

Cайт проекта: http://directory.apache.org/

Еще один сервер каталогов с открытым исходным кодом разрабатывает Apache Software Foundation. Apache Directory Server полностью написан на Java и распространяется под лицензией Apache. В 2006 году он был сертифицирован Open Group как совместимый с протоколом LDAPv3. Кроме LDAP, Apache DS поддерживает Kerberos5 и Change Password Protocol.

Разработчик позиционирует сервер как встраиваемое решение, предназначенное для интеграции в другие Java-приложения и работающее с ними в контексте одной VM. На сегодняшний день он встроен в такие продукты, как Apache Geronimo, JBoss и другие. Тем не менее, Apache DS можно запустить автономно, например, как службу Windows.

Поскольку программа полностью написана на Java, она успешно компилируется и работает на огромном количестве аппаратных и программных платформ. На сайте проекта доступны инсталляторы для GNU/Linux, Windows и MacOS, а также бинарные пакеты для Debian, Fedora и Solaris (для платформ SPARC и Intel), но на самом деле набор поддерживаемых ОС значительно шире.

Помимо стандартного функционала сервера LDAP, в Apache DS реализованы такие интересные расширения, как хранимые процедуры и триггеры. Автор проекта Алекс Карасулу (Alex Karasulu) в 2001 году предложил включить в сервер OpenLDAP поддержку этих объектов, которые давно используются в реляционных базах данных, но отсутствуют в спецификациях LDAP. Его попытка провалилась из-за сложности существующего программного обеспечения. В октябре 2002 года Алекс начинает разработку собственного сервера каталогов, написанного на Java. Затем, в октябре 2003 года, он передает права на код своей разработки в Apache Software Foundation.

К моменту написания данной статьи, на сайте проекта доступны две версии Apache DS: 1.0.2 и 1.5.4. Кроме того, в рамках проекта разрабатывается Apache Directory Studio, которая включает LDAP-браузер, браузер схем, редактор LDIF, редактор DSML и другие клиентские программы, необходимые для администрирования сервера каталогов.

Заключение

Как мы видим, свободных реализаций сервера каталогов X.500 существует не так уж много. В следующих статьях мы обязательно поговорим о них подробнее, поскольку русскоязычной документации по использованию серверов LDAP в Сети явно недостаточно. Помимо чисто практических моментов, мы сосредоточимся на подробном описании архитектуры существующих решений, а также расскажем о перспективах развития протокола LDAP. Разумеется, не будем забывать и о главной проблеме использования свободных DS – интеграции с Microsoft Active Directory. Во второй статье цикла речь пойдет об установке и настройке Mandriva Directory Server.

Image via Wikipedia

Для геймера можно назвать три основных фактора, которые сильнее всего будут сказываться на требуемой видеопамяти: разрешение, уровень визуального качества (детализация) и полноэкранное сглаживание. Для большинства геймеров 512 Мбайт видеопамяти будут достаточным объёмом, чтобы выкрутит на максимум один из приведенных параметров, а в большинстве случаев поднять оба параметра одновременно. Но если вы планируете выжать до максимума все три настройки (самое высокое разрешение, самый высокий уровень детализации и самый высокий уровень сглаживания), то покупка видеокарты с памятью больше 512 Мбайт кажется нам здравой идеей.

Но основным критерием всё же должно быть разрешение, поскольку оно является физическим ограничением для большинства геймеров. Обычно 20" мониторы или модели с меньшей диагональю ограничены разрешением 1680x1050, поэтому в данном случае тратиться на 1 Гбайт видеопамяти смысла не имеет. Напротив, если диагональ вашего монитора 21" или выше, а "родное" разрешении составляет 1920x1200, то покупка видеокарты с 1 Гбайт видеопамяти себя оправдает, если вы не будете значительно за это переплачивать.

Карта с 2 Гбайт видеопамяти будет полезна только для тех, кто использует разрешение 1920x1200 и выше с самыми высокими настройками визуального качества вместе с полноэкранным сглаживанием. Разница в цене таких моделей весьма существенна, поэтому видеокарта с 2 Гбайт памяти будет явно избыточна для владельцев мониторов с разрешением меньше 1920x1200.

Конечно, необходимо учитывать и другие факторы. Со временем игры будут наверняка требовать больше и больше видеопамяти. Впрочем, помните, что объём видеопамяти на карте не является абсолютным критерием производительности: 512-Мбайт Radeon HD 4870 или 896-Мбайт GeForce GTX 260 всегда будет работать быстрее, чем 2-Гбайт Radeon HD 4670 или GeForce 9600 GTS. Суть в том, что тип графического процессора намного сильнее влияет на производительность, чем объём установленной памяти. Мы регулярно проводим тесты, поэтому для сравнения производительности видеокарт мы рекомендуем заглянуть в соответствующий раздел.

В итоге даже 512 Мбайт видеопамяти дают прекрасную производительность в высоких разрешениях, если пользователь чуть снизит настройки качества и режимы сглаживания, чтобы карта полностью раскрыла свой потенциал. Но если вы планируете играть с максимальными настройками качества и полноэкранного сглаживания, то действительно имеет смысл доплатить за видеокарту с 1 или 2 Гбайт памяти.