• ↓
  • ↑
  • ⇑
 
21:04 

Индексы not equal и pres

Индекс pres нужно использовать только для очень редко встречающихся, но часто "искомых" атрибутов
Индекса not equal не существует в природе, но _некоторые_ (сдаётся, мне что двузначные, то есть флаговые например :) ) атрибуты могут создавать индекс not equal на основании индекса equal. В общем для zimbraIsSystemResource, который таки флаг, я индекс eq добавил, а там хоть трава не сохни.
Вообще полезно бывает в 25-й раз одну и ту же страницу документации читать: склероз побуждает к неожиданным открытиям, в особенности если раньше читал то же самое, но по другому поводу :)

Ах да, ещё лучше бы держать логи низкоуровневой БД и собственно данные на разных дисках .
Цитирую OL Admin Guide:

Use fast subsystems. Put each database and logs on separate disks configurable via DB_CONFIG:

# Data Directory

set_data_dir /data/db


# Transaction Log settings
set_lg_dir /logs

Эх, где бы эти раздельные диски ещё найти в наш век тотального RAID'а с LVM'ом...

P.P.S. А вообще по моим наблюдениям ту же MySQL нередко используют почти read-only.

20:55 

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

06:24 

"Заметки на полях" переезжают

В связи с утомившими меня вечными проблемами форматирования на движке diary.ru, в особенности это касается кода, я в ближайшее время переношу блог на новый движок (и на другой сайт, разумеется). В связи с этим хотелось бы услышать ваши пожелания, уважаемые читатели:
1) Какой блог движок использовать?
Склоняюсь к LiveStreet, поскольку знаком с ним и возможности форматирования кода устраивают. Неудобно, что нет возможности прикреплять файлы - только ссылки на них. Да вот вроде и всё, что неудобно...
2) На какой сайт переезжать?
У меня есть freeadmins.org.ru, но там движок - Joomla, а блогов нормальных для Джумлы я что-то не нашёл...
Есть ещё идея переехать на sysadminblog.ru - я в принципе не гордый и мне совершенно (без разницы), что сайт не мой. Но неизвестно, насколько этот сайт стабилен, то есть если вероятность того, что он в один прекрасный момент "схлопнется" и как последствие кавитационного удара я лишусь всего своего материала. А материал, как вы догадываетесь, нужен не только для кого-то, но и в первую очередь - для меня самого, поскольку память человеческая небезгранична даже сейчас я изредка пользуюсь своими старыми записями.

Пожалуйста, отпишитесь в комментах, кто что думает по означенному поводу :)

Искренне Ваш, DRVTiny

02:31 

MultiMaster vs. Mirroring

По возможности не используйте Multimaster-репликацию в её полноценном виде:

- теоретически неограниченое количество мастер-серверов,

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

Дело в том, что это работает только в том случае, если все мастер-сервера создаются с нуля и практически одновременно. Это именно так в случае с простым тестом 050-multimaster, на который так любят ссылаться разработчики OpenLDAP. Тем не менее даже такой вроде бы стабильно работающий кластер взаимнореплицируемых серверов может потерять ноду... А потом вторую... В особенности это касается тех случаев, когда нод больше трёх: число три для режима Multimaster'а в OpenLDAP является каким-то магическим порогом, за которым начинаются эксперименты над критически важными данными с плохо прогнозируемыми последствиями.
Mirroring (зеркалирование) - технически тот же MultiMaster (найдите отличия в конфигурации? olcServerID?), но это иная стратегия репликации. Эта стратегия предполагает, что в штатном режиме работы запись производится лишь на одном сервере, а на второй сервер изменения пересылаются репликой. При этом чтение может осуществляться одновременно с двух серверов при помощи внешнего балансирующего нагрузку фронтэнда (не входит в поставку OpenLDAP можно использовать прокси-режимы работы OL). В случае отказа сервера, принимающего операции записи от клиентов, их начинает принимать неактивная часть "зеркала". Как только "отвалившаяся" часть зеркала поднимется, все операции записи, произведённые за время простоя, будут приняты репликой.
В общем, на самом деле, подчёркиваю, никакой принципиальной разницы между мультимастером и зеркалированием нет, кроме собственно количества нод. Но использование описанной стратегии даёт гораздо более предсказуемый результат, даже если вы не используете никаких внешних фронтэндов и все переключения осуществляете вручную.


P.S. Да, и в любом случае backup often ;)

@темы: серверы

21:39 

Одна из распространённых проблем репликации

Если ваша база OpenLDAP упорно отказывается реплицироваться, запустите сервер, на который вы хотите залить реплику, с ключом -d 16384 (отладка механизма репликации). И если там будет явная "ругань" на то, что с мастер-сервера невозможно получить entryUUID для некоторых записей, это значит, что в исходном каталоге не хватает служебных атрибутов, без которых репликация действительно не пойдёт. Отложим обсуждение вопроса о том, почему так бывает, просто пофиксим эту проблему:
Если база относительно небольшая, переведите её в read-only и сделайте полный slapcat:
А теперь... физически удалите файлы базы и залейте LDIF-дамп базы, полученный на шаге 1, обратно:
rm -f /path/to/db/files/*
slapadd -F /path/to/config/dir -n номер_базы -l my_db.ldif
chown -R openldap_user.openldap_group /path/to/db/files/


Примечание: под "номером базы" подразумевается то число, которое проставлено для этой базы в cn=config
То есть, например, для DN=olcDatabase={3}hdb,cn=config номер базы соответственно равен трём. Для самой cn=config номер всегда равен нулю (т.е. это всегда olcDatabase={0}config,cn=config)





@темы: серверы

12:17 

Сборка OpenLDAP для сервера-реплики

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

1. Качаем и распаковываем свежую версию сабжа:


(предполагается, что pwd=$HOME, а в $HOME есть каталоги Download и Compile)

2. Устанавливаем зависимости. В yum-based rpm-дистрибутивах это выглядит так:


3. Собираем OpenLDAP
Раз это сервер реплики, то можно и нужно ничего нового не придумывать, а просто скопировать его опции сборки из исходников мастер-сервера:

На мастер-сервере:


На реплике (не путать со слэйвом, реплика может быть и вторым мастер-сервером, если используется multimaster):

Как видите, в моём случае версии OpenLDAP для реплики и мастер-сервера не совпадают, но в ничего страшного в этом нет, если, конечно, разница в версиях не слишком велика. В моём случае мастер-сервер довольно активно используется, поэтому обновлять его приходится редко.
Команда "eval ..." извлекает из файла config.log строчку вызова ./configure, использовавшуюся для сборки мастер-сервера, и выполняет получившуюся команду

02:40 

sudo+ldap в Calculate Directory Server

Будьте внимательны: в популярном у ваятелей LDAP-based архитектур дистрибутиве CDS (Calculate Directory Server) sudo читает отнюдь не /etc/ldap.conf, а что-то другое. То есть конечно если вы внимательно изучали документацию по CDS, то знаете, что именно должен читать sudo в данном дистрибутиве, я же предпочёл попросту скачать свежую версию с офсайта sudo.ws и собрать её со следующими опциями:

./configure --prefix=/usr --with-ldap --with-ldap-conf-file=/etc/ldap.conf -with-ldap-secret-file=/etc/ldap.secret

02:01 

Чудеса на PADL.COM'е

Опытным путём сегодня благополучно выяснил, что в nss_ldap используется в режиме "nss_schema rfc2307bis" знаете какой атрибут членства в группе? uniqueMember! Что в этом необычного? А то, что в последней редакции RFC 2307bis, (которая так же, как и все предыдущие не утверждена IETF, а потому не совсем понятно, чего ради её тот же OpenDS использует по дефолту), в качестве атрибута членства в группе, хранящего полный DN, предлагается member, а не uniqueMember! Об этом по сути нигде толком не сказано, поди догадайся...
Кстати, само описание posixGroup в схеме я предлагаю в таком случае хакнуть при первой же возможности и сделать его следующим:

1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Abstraction of a group of accounts' SUP top STRUCTURAL MUST gidNumber MAY ( cn $ userPassword $ uniqueMember $ memberUid $ description )

Здесь cn вынесен в MAY атрибуты и добавлен MAY-атрибут uniqueMember
Я конечно понимаю, что это некоторое отклонение от стандарта, но... к сожалению иногда и стандарты страдают "несовершенством". Особенно это касается RFC 2307bis, где с одной стороны posixGroup стал вдруг AUXILIARY, что вынуждает добавлять в стек структурный класс, а с другой стороны - в objectClass'ах groupOfNames и groupOfUniqueNames, содержащих типы атрибутов member и uniqueMember соотв., они заявлены как MUST. Из сказанного следует, что даже если Member'ы формируются оверлеем dynlist, Вы всё равно обязаны постоянно держать в записи нечто вроде "uniqueMember: cn=dummy".
Редактирование же определения posixGroup в указанном ключе позволит вам избавиться от необходимости изворачиваться, стряпая противоестественного вида стек objectClass'ов с лишними значениями атрибутов или добавляя туда extensibleObject, что на мой взгляд - тоже хак в обход схемы.

Впрочем, всё сказанное касается исключительно тех, кто использует DN'ы для членов группы, для обычного memberUid'а хватает стандартной nis.schema, соответствующей RFC 2307

00:03 

Как сделать просто ноду, "без прикрас"?

Если нужно добавить элементарный узел в дерево LDAP, пользуйтесь чудесным objectClass'ом "applicationProcess" из RFC 2256.
Вот как выглядит типичный узел с objectClass=applicationProcess:

dn: cn=Accounts,cn=Security
objectClass: applicationProcess
cn: Accounts

Описание applicationProcess:

objectClasses: ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description )

Поскольку непонятно, что это ещё за application process такой (thread что ли?), то я думаю, нет ничего противоречащего "букве и духу" LDAP в использовании данного objectClass'а для создания узлов без дополнительной смысловой нагрузки..

04:11 

DNS+LDAP

Лучшим решением для интеграции DNS с LDAP является PowerDNS.
Почему?
1) Очень прост в настройке
2) Один объект используется для A и PTR-записей
3) В одном объекте можно указать сколько угодно A-записей (просто указываешь IP и хоть тысячу имён хостов к нему впридачу)
4) Отличная схема, в которой нет ничего лишнего и есть много полезного
5) В итоге - самое главное, DNS-зона получается очень наглядной, даже лучше, чем в Active Directory

Почему нельзя использовать BIND+LDAP? Можно конечно, только вместо преимуществ вы получите какой-то слабочитабельный бред в своём Каталоге, который не годится ни для чего, кроме собственно DNS.

19:56 

Специализированный LDAP-форум

Я понимаю, что diary.ru, как бы ни был он мне мил (и немил тоже), всё же ограничен чёткими рамками блогосферы. Потому и приходится делать тематический форум отдельно от блога. Первая попытка сделать такой форум на бесплатном хостинге, к сожалению, оказалась не совсем удачной. Поэтому я решил вместо самостоятельного сайта под эти нужды создать раздел на форуме freeadmins.org.ru. Я там довольно регулярно бываю и смогу ответить на ваши вопросы.в разумные сроки.
Да, комменты в блоге конечно никто не отменяет :)

17:20 

LDAP как источник аутентификации

Две мои статьи на тему LDAP-аутентификации - написаны относительно давно, но для ознакомления с вопросом должно быть в самый раз:
- Сервер каталогов LDAP как источник аутентификации - учётные записи
- Сервер каталогов LDAP как источник аутентификации - интеграция с AD

15:29 

LDAPCon 2010...

Замечательной конференции, посвящённой проблемам LDAP, в этом году не будет. Сказались финансовые трудности, поглощение Sun'а Ораклом, довольно слабая предыдущая конференция. В итоге, следующий LDAPCon запланирован на 2011-й год.

14:09 

Как научиться работать с LDAP?

Ответом на это, разумеется, может быть только RTFM.
А именно, лучшей книгой в онлайн на эту тему, бесспорно, является опубликованный на сайте zytrax.com хрестоматийный учебник "LDAP for Rocket Scientists". Несерьёзное название книги полностью соответствует стилю изложения: лёгкому, слегка ироничному и максимально доходчивому. Собственно. авторы просто не хотели называть её "LDAP для Чайников" - это было бы похоже на моветон, да и сразу понижало бы в глазах потенциального читателя важность и полезность данной работы.
Читать учебник от корки до корки особого смысла, на мой взгляд, не имеет: он содержит множество примеров и различной практически полезной информации, так что "если срочно" (а оно почти всегда так и бывает), ищите в нём ответы на свои конкретно поставленные вопросы, да обрящете. Во всяком случае, зачастую это куда полезнее чтения сильно фрагментированного, непоследовательного, находящегося в перманентном состоянии дописывания руководстве OpenLDAP Administration Guide, и это даже при том, что после "LDAP for Rocket Scientists" именно документация проекта OpenLDAP является, на мой взгляд, наиболее толковой.
P.S. Я очень признателен Zytrax'у за выложенные на их сайте книги, и не только по LDAP, но и по DNS-серверу ISC BIND, например. Зитракс - это вообще отличный пример того как коммерческий проект может без каких-то значительных вложений сделать полезное и нужное дело для всех.

18:01 

schema2ldif конвертер

Скрипт для преобразования схем
из формата .schema в формат .ldif, пригодный для загрузки в динамическую конфигурацию cn=config. Необходимый параметр - имя файла схемы без расширения, который нужно преобразовать. Скрипт отправляет результат в стандартный поток вывода, откуда вы его можете через пайп перенаправить утилите ldapadd или просто сохранить в файл.


Это, наверное, самый простой и самый немудрёный schema2ldif из всех, когда либо сочинённых. Но мне его обычно хватает.
А если вам нужен продвинутый вариант конвертера - пожалуйста, один есть прямо в поставке OpenLDAP (тоже на shell, тоже называется schema2ldif), а другой, на мой взгляд, самый развитый, написан на Perl'е, и он вот здесь: storm.alert.sk/soft/schema2ldif/schema2ldif

14:34 

Лучший графический LDAP-клиент

Уже очень давно пользуюсь во всех отношениях приятным LDAP-клиентом LDAP Browser/Editor. Эта компактная кроссплатформенная программа на Java с открытым исходным умеет всё или почти всё (не умеет, например, картинки JPEG напрямую в каталог запихивать). Её ближайшим конкурентом можно назвать Apache Directory Studio - клиент более функциональный, интеллектуальный и навороченный, но и более требовательный к ресурсам. Я предпочитаю пользоваться в основном LDAP Browser/Editor'ом и только в каких-то редких случаях - Apache Directory Studio. Из редких случаев стоит упомянуть работу со схемой, просмотр и редактирование Active Directory, а также загрузку любых файлов в каталог (для чего он совершенно не предназначен, поэтому такое кощунство требуется делать действительно редко).

И да, phpLDAPAdmin - штука довольно недоразвитая, ненаглядная и тормозная (как и большинство навязываемых нам "супер-пупер" веб-технологий), поэтому пользоваться ей рекомендую лишь в тех случаях, когда требуется админить LDAP-сервер удалённо из любой точки планеты, и не только под nix'ами, но и под форточками. Но по жизни для нервной системы полезнее будучи на Багамах всё же скачать автономный LDAP-клиент и пользоваться им.

Отличный обзор LDAP Browser/Editor можно найти на сайте LDAP-сервера OpenDS: www.opends.org/wiki/page/LDAPBrowserEditor Правда, указанная там ссылка на домашнюю страничку автора неактуальна уже (видимо, автор прекратил разработку или продолжил её в составе какого-то другого ПО). Тем не менее, программа очень популярна и скачать её можно во многих местах, например, здесь: www.novell.com/communities/files/Gawor_ldapbrow..., а RPM-пакет - здесь: rpm.pbone.net/index.php3/stat/4/idpl/11310306/d...


@темы: клиенты

17:14 

Mandriva Directory Server

Mandriva Directory Server is not a Directory Server. Ну почти как WINE Is Not An Emulator.
MDS не является сервером каталогов, это просто веб-интерфейс для настройки стандартных компонент Linux-дистрибутивов на взаимодействие с LDAP. Аналогом можно было бы назвать Microsoft Management Console, если бы... собственно, именно MMC называется ключевой компонент MDS'а (первое слово аббревиатуры конечно не Microsoft)! MDS дирижирует оркестром из DNS, DHCP, Samba, Kerberos, Postfix, подсистем NSS, PAM и собственно сервера каталогов для того, чтобы довольно странным методом при наличии весьма кривой документации делать то же, что умеет (только явно логичнее и проще) Calculate Directory Server. Последний, кстати, тоже ни разу не Directory Server, а просто хороший дистрибутив для ваяния либо аналога nix'ового NIS'а на современный лад, либо nix-based контролера домена Windows, причём последнее по известным причинам более востребовано IT-социумом. Но если краеугольным камнем Calculate DS является OpenLDAP, то чем же рулит чудесная веб-консолька MMC? В теории должна бы уметь работать как с тем же OpenLDAP, так и с Fedora Directory Server, на практике... ну не было у меня такой практики :) Но по смыслу офдоков в общем-то понятно, что разработка компании Mandriva c продукцией RedHat'а дружит хуже, чем с OpenLDAP.Да, и повторюсь, смысла в данном продукте в принципе не очень много, он пригодится разве что совсем новичкам или тем, кому надо развернуть доменный контролер предельно быстро на "чистом" каталоге. Если у вас уже есть каталог со своей структурой, отражающей логическую структуру организации, то MDS Вам точно ни к чему, потому что вы точно знаете, почему красивый веб-интерфейс на PHP и кучка модулей на Python - это всё-таки ещё не Сервер Каталогов :)

@темы: клиенты

21:10 

Подводные камни OpenLDAP

Если вы используете сервер каталогов OpenLDAP, в особенности для серьёзных Enterprise решений, избегайте следующего:
1) Консервативной склонности к редактированию конфигурационного файла slapd.conf. Сегодня, завтра и далее по расписанию мейнстримом является cn=config - схема, когда вся конфигурация доступна для динамического изменения через собственно протокол LDAP. Именно так это делается во всех без исключения известных мне современных серверах каталогов, и присутствие в OpenLDAP плоского файлика конфига было лишь временной мерой (при этом, заметьте, на этапе запуска OL ещё и время тратит на то, чтобы сделать из вашего slapd.conf'а всё тот же cn=config!)
2) Чрезмерного увлечения различными крутыми фичами OpenLDAP из любых придуманных Зейленгой RFC, носящих экспериментальный характер. Сегодня они есть, завтра их нет - такова жизнь :)
3) Если вам кажется, что "вот тот overlay/backend" делает как раз такой крутой хак с выворотом, который вам позарез нужен - больно бейте себя по рукам и сначала проверяйте статус разработки этого модуля. Нужно знать, насколько активно он разрабатывается, насколько подробно документирован, есть ли его более-менее подробное описание в официальном OL Admin Guide, а если есть, то подерживает ли он конфигурирование через cn=config. Если модуль не поддерживает cn=config - это верный признак того, что ему пора в топку, мейнтейниться он плохо или вообще никак, и в любой из новых версий OL, которые выходят, сами понимаете, нередко, он может просто кануть в небытие, оставив вас с носом
4) Боже упаси вас делать бэкапы непосредственно бинарных файлов баз типа bdb, hdb и пр. db. Знаете почему? Не только из-за потери транзакций (это как раз не так страшно: в LDAP интенсивные записи редки, а уж конкурентные подавно), но из-за перманентной проблемы несовместимости старых и новых версий библиотек для этих db. Во всяком случае, для BerkeleyDB нельзя быть уверенным даже в том, что минорные версии BDB будут совместимы между собой, а OL просто хлебом не корми, но подавай самые "свежие" библиотеки. Полагайтесь только на полноценные LDIF-дампы, переводя на время дампа базу в read-only, так вы получите заведомо соответствующий "неувядающему" фундаментальному стандарту формат бэкапа.

@темы: серверы

14:24 

LDAP-клиенты: SymLabs LDAP Browser

Написанный на Java LDAP-клиент полукоммерческого происхождения.
1) Под Mandriva Linux установился с правами, ограничивающими доступ даже на запуск исключительно админскими полномочиями (из чего видно, что сами разработчики LB работают в nix только под root'ом)
2) Квадратики вместо русских букв - просто фатальная ошибка
3) Возможности настройки ограничиваются выбором темы, используемой стандартным для Java откровенно уродливым GUI-движком

После того, как я попробовал это чудо, понял, что SymLabs LDAP Proxy, да ещё за деньги, меня совсем не интересует - пусть сами пользуются :)

@темы: клиенты

23:09 

LDAP-каталог для Zimbr'ы

Хотя разработчики Zimbra и призывают использовать чудесную реализацию как бы своего сервера каталогов, это, поверьте мне, совсем не обязательно. Zimbra 6 поставляется с самым обычным OpenLDAP в комплекте и двумя самопальными схемами, в одной из которых все типы атрибутов, кто бы мог подумать (surprise!), имеют наименования вида zimbraЧЕГО_ТО_ТАМ, а другая якобы просто позарез нужна Amavis'у (вирусный/антиспам фильтр). Если Вы где угодно поставите тот же OpenLDAP и подсунете ему две эти схемы - Zimbra не отличит этот каталог от родного. Ну а чтобы не мучаться с перенастройкой местоположения master-ldap'а (после установки Zimbr'ы это как-то дюже хитро делается, а в офдоках альтернативное местоположение master'а можно задать только на этапе установки) можно сделать проброс localhost:389 по SSH (см опцию -L), так, чтобы Zimbra коннектилась к LDAP локально, а реально попадала туда, куда вам угодно. При этом за счёт шифрования вы и секьюрность обеспечите, и откажетесь от совершенно небоснованных претензий Zimbr'овцев на создание очередного сервера каталогов.

LDAP - заметки на полях

главная