# Репликация абонентов справочника между серверами

Маленькое определение:
"Корневая организация" - это та организация, которая будет реплицироваться на удалённые сервера
Здесь нужно заметить что, репликация в данном случае односторонняя (но много направленная).
Для репликации используется папка "replica", в которую и должны складываться файлы с изменениями (имена и расширения файлов значения не имеют, за исключением одного, того который использует "корневой" сервер (тот на котором находитса "Корневая организация", та которую мы реплицируем куда-то). Имя этого файла всегда должно быть "main-organization")
После того как вы установите в настройках сервера галочку напротив поля "Использовать репликацию" файл "main-organization" в папке "replica" будет создаваться автоматически. Для того чтобы реплицировать свои изменения на удалённый сервер нужно будет перекинуть (с переименованием) его в папку "replica" на удалённый сервер и закинуть в cron задание вызывающее обработчик "personal/utils/import-replicas.php". После того как вы скопируете файл "main-organization" на все необходимые сервера его нужно будет удалить с "Корневого" сервера.
Команда примерно такая (именно её и можно закинуть в планировщик)

$/usr/bin/php /var/www/personal/utils/import-replicas.php

Добавляем задание в Cron

$ sudo crontab -u www-data -e
20 2 * * * /usr/bin/php /var/www/personal/utils/import-replicas.php > /dev/null 2>&1

Генерируем сертификаты для связи с удалённым сервером без ввода пароля

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pk/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): если не хотим вводить пароль оставляем поле пустым
Enter same passphrase again: здесь тоже самое что и выше
...

Разрешаем на удалённом сервере авторизацию по ключам:

$ sudo nano /etc/ssh/ssh_config
ForwardX11Trusted yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

$sudo /etc/init.d/sshd restart

Копируем ключ на удалённую машину

$scp ~/.ssh/id_rsa.pub login@remote_host:~

Подключаемся к удалённому компьютеру

$ssh login@remote_host

Проверяем есть-ли директория .ssh и если нет, то предпринимаем ряд действий

$ls -la ~/.ssh
$ mkdir .ssh
$ chmod 700 .ssh

Копируем содержимое public ключа в файл authorized_keys

$ cat ~/id_rsa.pub >> .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys
$ rm id_rsa.pub

Проверяем работу

$scp /var/www/personal/replica/main-organization login@remote_host:/var/www/personal/replica/remote-organization1

Чтобы автоматизировать переброску файла добавляем задание в Cron

$ sudo crontab -u user_login -e
10 1 * * * scp /var/www/personal/replica/main-organization login@remote_host:/var/www/personal/replica/remote-organization1 > /dev/null 2>&1
15 1 * * * scp /var/www/personal/replica/main-organization login@remote_host2:/var/www/personal/replica/remote-organization2 > /dev/null 2>&1
15 3 * * * rm -f /var/www/personal/replica/main-organization > /dev/null 2>&1

Зачем менять имена файлов при копировании на новый сервер?
Всё очень просто, основной файл "main-organization" используется для репликации локальных изменений от нас (корневая организация) куда-то и этот файл обработчиком (/personal/utils/import-replicas.php) игнорируется. Любой файл (кроме выше указанного) находящийся в папке "/personal/replica" по умолчанию считается файлом предназначенным для импорта изменнений в нашу базу данных. Как вы уже поняли, если все файлы будут с одним и тем же именем, то нифига у нас не получится, ибо они замечательно перезапишут друг друга. После того как пройдёт обработка полученного из удалённого офиса файла с изменениями, он автоматически удаляется с диска.