Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Обухов Дмитрий

Страницы: [1]
1
то есть Вы предлагаете приложению периодически опрашивать LDAP на предмет не изменилось ли чего?

а сервер настроить на то чтобы он скажем сам инициировал экшен при поступлении в него изменений можно?

наверно подошло бы следующее:

если бы на реплике (ну и на мастере) можно было складывать в некий log все поступающие изменения (прямо в виде ldif)
то есть чтобы реплика писала бы этакий длиинный ldif о том что меняется в ней. + разумеется ротейтинг этого ldif нужен.
тогда можно клиента по inotify бы подписать было.

2
Общий раздел / Re: атомарность ldif
« : 08 Январь 2015, 23:30:54 »
да все понятно, спасибо.

хгм, как же этим пользоваться тогда.

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

4
вот смотрите

1. имеется БД (в данном случае LDAP)
2. имеется сервер (набор серверов) программа в которых завязана на структуру БД (например на наличие объектного класса или атрибута)

теперь мы это развиваем

мы пишем в тестовом окружении некий скрипт up. который изменяет структуру БД и одновремено кладет новую версию кода клиента и далее рестартует клиент.

если что-то пошло не так (уже в продакшене) вызываем скрипт down. который изменяет структуру данных назад и откатывает код клиента.

так мы работаем со всеми БД и с LDAP хотим работать так же.

соответственно вопрос: есть ли для LDAP подобные up/down инструменты в готовом виде?


5
вопрос связанный с вот этим.

имеется проект, который разрабатывается много времени. на SQL.
на SQL мы применяем следующую парадигму разработки.

допустим надо добавить поле `age` в таблицу `users` и соответственно добавить код, который будет работать с этим полем в код сервера.
мы делаем два скрипта `up.sql` и `down.sql`

в первом стоит ALTER TABLE делающий апгрейд БД, во втором соответственно даунгрейд.

в итоге если вдруг выкатили на боевой что-то не то, то откатывается все вместе с git вызывая обратные изменения в БД.

сейчас думаем часть БД вынести в LDAP и для LDAP хотелось бы применять подобный подход.

вопрос: есть ли готовые инструменты для работы в подобной парадигме?

6
есть сейчас у меня БД SQL в ней лежит 100500 пользователей.
сейчас они реплицируются между несколькими проектами посредством своих наколеночных поделий.

хочу положить юзеров в LDAP и реплицировать их средствами LDAP.

и вот возник вопрос, кто как в подобных случаях делает?
берем готовые объектные классы с пользователями (там есть 100500 полей которые в моих проектах никогда не будут нужны + там нет каких-то нужных мне полей, которые придется добавлять) или лучше с нуля создавать пользователей?

7
хочу для начала сделать следующую структуру

1. главный LDAP
2. 100500 реплик ридонли
3. в LDAP в виде объектного класса описана конфигурация хоста (сейчас она лежит на каждом хосте в виде конфиг-файла)
4. на каждом хосте запускаем приложение, которое при изменениях в каких-то секциях записи перегенеривает конфигфайл и шлет сигнал приложению его перечитать.

вопрос: как можно внешним приложением (скажем на Perl) подписаться на изменения в БД?
причем идеально бы подписаться так чтобы если подписавшийся какое-то время простаивает, то когда он будет снова запущен, то чтобы он не потерял бы никаких произошедших за его отсутствие изменений

8
Общий раздел / атомарность ldif
« : 04 Январь 2015, 18:22:13 »
пока разбираюсь с LDAP, так что слишком много материала

вопрос:

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

и допустим где-то в конце этого ldif ошибка. вопрос: на этой ошибке что будет с базой?
вот эти успешные модифаи они откатятся или останутся в БД?

Страницы: [1]