вторник, 20 октября 2009 г.
14:51 | 
Автор:
Евгений
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vXoUA9-me3tN3FQesFplSkayyT4lrXm_pBQZX_Ygciq6GiPtTuYPJYoGN1d1jymOKf7dCKYUJRdxBA7fOMBaHKypUpolXtgb3rtny8ncRPVOKpHNUQ3dFTO6c-oFMDOU223TnB38EnJvXweS2xkbTU=s0-d)
Ярлыки:
вторник, 13 октября 2009 г.
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
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_v2gZcuOm4OB9O08_7obrY-uKoyRw3P6i36dGvjdQWnVOsuPwz3jmEomgzL30G8ktY9h4e1Mq5tAusgCH7MmlZKng1-keVHpHwVO3AfYPNfRflroPvVn3HzyCtpd0shxPInvyPWsX5C9YEOqOy6D4iy=s0-d)
четверг, 8 октября 2009 г.
Служба каталогов (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.
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_ueYn4ox1GwDEU6DauYVgoeg2qLAqbYZ14FSEVV2xPrZkGryvI5cSfKWAGKEAdxBhSddgSY6ehPhui_WJoFp5N-twEX4pO8d4rhzOMp0re5EBW4hg84sTT7oaQIo_jRVJGXDCousCsdv0SZJWjPfJlB=s0-d)
Серверы, клиенты, протоколы и стандарты
Можно ли заменить службу каталогов от 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.
понедельник, 5 октября 2009 г.
Но основным критерием всё же должно быть разрешение, поскольку оно является физическим ограничением для большинства геймеров. Обычно 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 Гбайт памяти.
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_u8jQXP3JQmyzR5wV1rKpwafZbL8dq3vmph-jOZQzGfX2Aqc8ilXBDC068E19nJeXzWzLzSYo87FaW6nykELGnMMQ5SjPiSn_P_uDWwY5VoSTZ2pmnM2GarBjEtU4aTKQJNppiFXliiFKDXGdECd-wK=s0-d)
Подписаться на:
Сообщения (Atom)
Спасобо Google
Реклама баннерообменных сетей
Наши рейтинги
