• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Ограничить доступ

  • Автор темы deeeman
  • Дата начала

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
TaxaRat, вспоминаем азы Lotus в части механизма репликации. ;)
И уточняем условия задачи.
К примеру: Имеем два сервера, участвующих в репликации. При репликации проводится проверка по ACL прав на изменение каждого сервера. Если один из серверов будет Читателем, то изменения из его реплики БД не будут допущены в реплику БД на другом сервере.
где вы такое прочли то?
видать никогда в жизни не пробывали сделать неудачную реплику, когда с основного сервера всё пропало и появилось на сервере, который ничего сделать и не может? ;)

я на всякий случай поискал -
Репликация документов. Прием изменений документов на сервер-инициатор происходит, если вызванный сервер имеет доступ к базе (ACL) и документам (поля доступа к документам типа Readers и Authors), позволяющий создавать, изменять или удалять документы. Среди документов вызываемого сервера строится специальное представление, содержащее документы согласно формуле репликации. Затем репликатор создает список идентификаторов документов, которые были изменены со времени последней репликации. Если в настройках репликации включен параметр Receive documents from server - Smallest first, полученный список сортируется по размеру документа, в противном случае - по дате модификации. Далее для каждого документа по идентификатору ищется его собрат в своей реплике. Если этого не удалось, новый документ добавляется в реплику. Если документ не новый - сравниваются время последней модификации и последовательные номера этих документов. Если документ оказался измененным с момента последней репликации на обоих серверах - возникает репликационный конфликт (этот случай рассматривается ниже). В противном случае изменения передаются на сервер-инициатор репликации, модифицируя документ на его стороне. Причем, начиная с версии 4.x происходит не полное копирование всех полей, копируются только поля, имеющие неодинаковые флаги Seq Num. Это существенным образом сокращает объём передаваемой информации. Именно это и называют репликацией на уровне полей (пунктов, items). Далее, в зависимости от схемы репликации, либо репликатор сервера повторяет описанные в этом пункте действия в зеркальном направлении, выталкивая новые и модифицированные документы (схема Pull-Push), либо сразу переходит к следующему пункту, оставляя эту работу для чужого репликатора (Pull-Pull)
Обновление записи в истории репликаций. При успешном завершении предыдущих стадий репликации репликатор делает запись в истории репликаций своей реплики. Если репликация происходит по схеме Pull-Push, то подобную запись репликатор вносит и в историю репликации чужой реплики
Вот я и пытаюсь найти, где же механизм репликации описан более детально?

Я не утверждаю, я хочу найти подтверждение так или не так
Админ изменил данные на реплике №1, как эти изменения попали на реплику №2 и на реплику №3?, где у админа уже права не админа, но они всё равно туда попадают, кто и как заверяет подобные действия в репликации?
 

aameno2

Lotus Team
27.01.2009
734
140
BIT
142
Админ изменил данные на реплике №1, как эти изменения попали на реплику №2 и на реплику №3?, где у админа уже права не админа, но они всё равно туда попадают, кто и как заверяет подобные действия в репликации?
Понимать сервер? Продемонстируете?
 

Domino-Designer

Людям надо поморгать!
Lotus Team
06.12.2011
616
223
BIT
9
@aameno2, Я можно начать новую, а тут оставить ссылку, ибо не по теме пошли, да?
[DOUBLEPOST=1427883401,1427883304][/DOUBLEPOST]@aameno2, как я вас на карабль потом собирать буду?


Предлагаю ветку закрыть и открыть новую, там мы и перегрызёмся.
[DOUBLEPOST=1427883493][/DOUBLEPOST]Не портите тематику
 

Wanderstep

Lotus Team
23.03.2006
493
65
BIT
17
где вы такое прочли то?

видать никогда в жизни не пробывали сделать неудачную реплику, когда с основного сервера всё пропало и появилось на сервере, который ничего сделать и не может?

я на всякий случай поискал -
@ToxaRat, более 10 лет администрирую Domino, и каких только репликаций не повидал - так что не смеши меня :)
Речь идет о базовых знаниях механизма репликации из сертификационного курса по администрированию. Я проходил их давно еще в ИнтерТрасте. Там мы и рассматривали разные варианты репликации, и разбирали, что и как будет или не будет реплицироваться. И за свою практику я еще ни разу не столкнулся с репликацией, которая бы противоречила с заложенной логикой IBM.

Подробнее это можно найти в учебнике по администрированию. То ли у Некрасова, то ли у Кирклэнда эта тема с примерами расписана.

я на всякий случай поискал -

Репликация документов. Прием изменений документов на сервер-инициатор происходит, если вызванный сервер имеет доступ к базе (ACL) и документам (поля доступа к документам типа Readers и Authors), позволяющий создавать, изменять или удалять документы.
Вот выделенное первое предложение как раз и является основополагающим правилом репликации. Если его внимательно прочитать и правильно приложить на любую схему репликации - вопросов не будет возникать.

Я не утверждаю, я хочу найти подтверждение так или не так
Админ изменил данные на реплике №1, как эти изменения попали на реплику №2 и на реплику №3?, где у админа уже права не админа, но они всё равно туда попадают, кто и как заверяет подобные действия в репликации?
Прием изменений в реплике базы определяется не по тому, кто добавил документы в базу, а по участнику репликации. В данном случае участниками репликации являются сервера №1, №2 и №3. Таким образом, на серверах №2 и №3 по ACL будут проверяться права не админа, изменившего данные, а сервера №1, который участвует в репликации. А вот если админ попытается напрямую от себя среплицировать базу на сервера №2 и №3, вот только тогда будут браться в расчет его права в ACL, т.к. он уже будет являться участником репликации.
 
  • Нравится
Реакции: Мыш

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
216
Прием изменений в реплике базы определяется не по тому, кто добавил документы в базу, а по участнику репликации. В данном случае участниками репликации являются сервера №1, №2 и №3. Таким образом, на серверах №2 и №3 по ACL будут проверяться права не админа, изменившего данные, а сервера №1, который участвует в репликации. А вот если админ попытается напрямую от себя среплицировать базу на сервера №2 и №3, вот только тогда будут браться в расчет его права в ACL, т.к. он уже будет являться участником репликации.
я несколько раз это упомянул, но ToxaRat не воспринимает ;)
только мы обсуждали не сервера, а сразу "админа" (т.к. поднять/создать сервер - нет способа, без соответ прав и ИД сертификатора)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!