Difference between revisions of "Bidirectional Rsync/Unison based SysVol replication workaround"

(Removed unnecessary install procedure and github branch stuff)
m (Updated links, some grammatical errors, and minor stuff)
Line 4: Line 4:
 
= Information on Osync replication =
 
= Information on Osync replication =
  
This HowTo describes a solution for SysVol replication, that is based on Osync (rsync is required). As Compare to the rsync method, it is bidirectional. But this howto only cover two DC setup.
+
This HowTo describes a solution for SysVol replication, that is based on Osync, which is two way sync system based on rsync. This howto covers the bidirectional synchronization of two DC servers.
  
It have the following advantages:  
+
This solution has the following advantages:  
 
* setup is fast
 
* setup is fast
 
* configuration is very easy
 
* configuration is very easy
* Can work with windows (Todo)
+
* Can work with windows (Windows can be used as master using the MinGW environment)
  
In this setup we will use rsync through a SSH tunnel.
+
Osnyc uses rsync through a SSH tunnel.
  
 
= Setup the SysVol replication =
 
= Setup the SysVol replication =
Line 17: Line 17:
 
== Installation ==
 
== Installation ==
  
I don't see any package but osync available on
+
There aren't any deb or rpm packages as osync is a script, but you can get a copy here:
[http://www.netpower.fr/projects/osync/osync.v1.00.tar.gz]http://www.netpower.fr/projects/osync/osync.v1.00.tar.gz
+
[http://www.netpower.fr/projects/osync/osync.v1.00a.tar.gz]http://www.netpower.fr/projects/osync/osync.v1.00a.tar.gz
  
 
You can then install osync with the following commands
 
You can then install osync with the following commands
  tar xvf osync.v1.00.tar.gz
+
  tar xvf osync.v1.00a.tar.gz
 
  cd ./osync
 
  cd ./osync
 
  sh ./install.sh
 
  sh ./install.sh
  
This will copy osync to /usr/local/bin
+
This will copy osync to /usr/local/bin and create an example configuration file at /etc/osync/sync.conf
  
 
=== Setup on the Domain Controller with the PDC Emulator FSMO role ===
 
=== Setup on the Domain Controller with the PDC Emulator FSMO role ===
 
Some assumption:
 
Some assumption:
 
* You are running all command as root.
 
* You are running all command as root.
* rsync is installed on both server
+
* rsync is installed on both servers
 
* sysvol is located /var/lib/samba/sysvol on both DC1 and DC2
 
* sysvol is located /var/lib/samba/sysvol on both DC1 and DC2
 
* osync is located /usr/local/bin/osync
 
* osync is located /usr/local/bin/osync
Line 38: Line 38:
 
* sysvolsync log is located /var/log/osync_*.log
 
* sysvolsync log is located /var/log/osync_*.log
 
* rsync must support extended ACLs
 
* rsync must support extended ACLs
* Install rsync by using your package manager or compile from source. Make sure, that you use a version that supports extended ACLs!
+
* Install rsync by using your package manager (eg: yum install rsync or apt-get install rsync) or compile from source. Make sure, that you use a version that supports extended ACLs (most versions do)!
 
* sysvol must be on disk which is mounted to support acl and also xattr
 
* sysvol must be on disk which is mounted to support acl and also xattr
 
* We don't need to setup rsync server.
 
* We don't need to setup rsync server.
Line 64: Line 64:
 
  DESTINATION_MAILS="your@email.com"
 
  DESTINATION_MAILS="your@email.com"
  
Osync have also backup and soft delete which will kept a copy of deleted files and folder.  
+
Osync also does backups and soft deletes which will keep a copy of deleted files and folders in a subfolder named .osync_workdir.  
You can choose to enable them.
+
Unless you have specific reasons to do so, leave these options enabled.
Osync have one benefit as it will only send email alert if there is problem.
+
Osync has one benefit as it will only send email alert if there is problem.
  
 
=== Setup on DC2 ===
 
=== Setup on DC2 ===
Line 83: Line 83:
 
Than unison setup copies only the extened attributes on files.
 
Than unison setup copies only the extened attributes on files.
  
<BR>Please make a '''backup''' on you sysvol just in case.
+
<BR>Before starting, make a '''backup''' of your sysvol just in case.
  
  /usr/bin/osync.sh /etc/osync/sync.conf --dry --verbose
+
  /usr/local/bin/osync.sh /etc/osync/sync.conf --dry --verbose
  
If this run successfully let remove the --dry and execute it.
+
If this runs successfully, you may remove the --dry option and run again.
  
  /usr/bin/osync.sh /etc/osync/sync.conf --verbose
+
  /usr/local/bin/osync.sh /etc/osync/sync.conf --verbose
  
 
== Add to Crontab on DC1 ==
 
== Add to Crontab on DC1 ==
 
On DC1 run the following:
 
On DC1 run the following:
 
  crontab -e  
 
  crontab -e  
  */5 * * * * root  /usr/bin/osync.sh /etc/osync/sync.conf --silent
+
  */5 * * * * root  /usr/local/bin/osync.sh /etc/osync/sync.conf --silent
  
:'''Warning: Make sure that the destination folder is really your SysVol folder, because the command will replicate to the given directory and sync everything in it that isn't also on the source! You could damage your system! So check the output carefully if the replication is doing, what you expect!'''
+
:'''Warning: Make sure that the destination folder is really your SysVol folder, because the command will replicate to the given directory and sync everything in it that isn't also on the source! You could damage your system! So check the output carefully to see if the replication is doing, what you expect!'''
  
 
= When you try to resync the folder =
 
= When you try to resync the folder =
 
:'''Warning: Please follow the steps below OR you can end up with an empty sysvol folder.'''
 
:'''Warning: Please follow the steps below OR you can end up with an empty sysvol folder.'''
 
# Disable Cron on DC1, like Add a "#" on the line with <tt>crontab -e</tt>
 
# Disable Cron on DC1, like Add a "#" on the line with <tt>crontab -e</tt>
# Check is any rsync or osync are currently running in <tt>ps -aux</tt> if yes, wait for it to finished OR kill it (if it is zombie)
+
# Check is any rsync or osync are currently running in <tt>ps -aux | grep sync</tt> if yes, wait for it to finished OR kill it (if it is zombie)
 
# Remove the .osync_workdir hash files on both DC1 and DC2 on <tt>MASTER/SLAVE_SYNC_DIR "/var/lib/samba/sysvol"</tt>
 
# Remove the .osync_workdir hash files on both DC1 and DC2 on <tt>MASTER/SLAVE_SYNC_DIR "/var/lib/samba/sysvol"</tt>
 
# Now check your sysvol and resync
 
# Now check your sysvol and resync
# Confirm that everything is ok again
+
# Confirm that everything is working again
 
# Re-enable the Cron on DC1 again
 
# Re-enable the Cron on DC1 again
  
Line 110: Line 110:
  
 
* How can I do this on windows?
 
* How can I do this on windows?
** I don't have an answer, please post on the mailing list
+
** Install the MSYS bash environment (read the osync documentation), then you may run osync as master from Windows.
 
 
  
 
* What to do if I've more than one DC?
 
* What to do if I've more than one DC?
Line 119: Line 118:
 
** DC1 <> DC3
 
** DC1 <> DC3
 
** DC1 <> DC2
 
** DC1 <> DC2
 +
  
  
 
* Why can't I simply use a distributed filesystem like GlusterFS, Lustre, etc. for SysVol?
 
* Why can't I simply use a distributed filesystem like GlusterFS, Lustre, etc. for SysVol?
 
** A cluster file system with Samba requires CTDB to be able to do it safely. And CTDB and AD DC are incompatible. Please check on the [https://lists.samba.org/archive/samba/2014-February/178546.html reply] from Samba Developer on the mailing list .
 
** A cluster file system with Samba requires CTDB to be able to do it safely. And CTDB and AD DC are incompatible. Please check on the [https://lists.samba.org/archive/samba/2014-February/178546.html reply] from Samba Developer on the mailing list .

Revision as of 13:48, 31 July 2015

Introduction

Samba AD currently doesn't provide support for SysVol replication. To achive this important feature in a Multi-DC environment, until it's implemented, workarounds are necessary to keep it in sync. This HowTo provides a basic workaround solution based on Osync.

Information on Osync replication

This HowTo describes a solution for SysVol replication, that is based on Osync, which is two way sync system based on rsync. This howto covers the bidirectional synchronization of two DC servers.

This solution has the following advantages:

  • setup is fast
  • configuration is very easy
  • Can work with windows (Windows can be used as master using the MinGW environment)

Osnyc uses rsync through a SSH tunnel.

Setup the SysVol replication

Installation

There aren't any deb or rpm packages as osync is a script, but you can get a copy here: [1]http://www.netpower.fr/projects/osync/osync.v1.00a.tar.gz

You can then install osync with the following commands

tar xvf osync.v1.00a.tar.gz
cd ./osync
sh ./install.sh

This will copy osync to /usr/local/bin and create an example configuration file at /etc/osync/sync.conf

Setup on the Domain Controller with the PDC Emulator FSMO role

Some assumption:

  • You are running all command as root.
  • rsync is installed on both servers
  • sysvol is located /var/lib/samba/sysvol on both DC1 and DC2
  • osync is located /usr/local/bin/osync
  • sync.conf is located /etc/osync/sync.conf
  • DC1 is at DC1
  • DC2 is at DC2 (And already join DC1)
  • sysvolsync log is located /var/log/osync_*.log
  • rsync must support extended ACLs
  • Install rsync by using your package manager (eg: yum install rsync or apt-get install rsync) or compile from source. Make sure, that you use a version that supports extended ACLs (most versions do)!
  • sysvol must be on disk which is mounted to support acl and also xattr
  • We don't need to setup rsync server.

Change the path if that don't fit your setup.

Creating SSH Public Key and ssh-copy to DC2

ssh-keygen -t dsa
ssh-copy-id -i ~/.ssh/id_dsa.pub root@DC2

You can try to access DC2 via ssh

ssh DC2

Osync Configuration Setup on DC1

Edit the /etc/osync/sync.conf and make some changes

#!/usr/bin/env bash
SYNC_ID="sysvol_sync"
MASTER_SYNC_DIR="/var/lib/samba/sysvol"
SLAVE_SYNC_DIR="ssh://root@DC2:22//var/lib/samba/sysvol"
SSH_RSA_PRIVATE_KEY="/root/.ssh/id_rsa"
PRESERVE_ACL=yes
PRESERVE_XATTR=yes
SOFT_DELETE=yes
DESTINATION_MAILS="your@email.com"

Osync also does backups and soft deletes which will keep a copy of deleted files and folders in a subfolder named .osync_workdir. Unless you have specific reasons to do so, leave these options enabled. Osync has one benefit as it will only send email alert if there is problem.

Setup on DC2

  • On DC2 Install rsync by using your package manager or compile from source. Make sure, that you use a version that supports extended ACLs!
  • Shutdown DC2 Samba AD DC
mv /var/lib/samba/private/idmap.ldb /var/lib/samba/private/idmap.ldb.backup"
rm /var/cache/samba/gencache.tdb"
  • Copy idmap.ldb from DC1 to sync the idmap.
  • Run the following command on DC1
scp /var/lib/samba/private/idmap.ldb root@DC2:/var/lib/samba/private/

1st Try

What happen is we use rsync to create the directory structure with extended attributes Than unison setup copies only the extened attributes on files.


Before starting, make a backup of your sysvol just in case.

/usr/local/bin/osync.sh /etc/osync/sync.conf --dry --verbose

If this runs successfully, you may remove the --dry option and run again.

/usr/local/bin/osync.sh /etc/osync/sync.conf --verbose

Add to Crontab on DC1

On DC1 run the following:

crontab -e 
*/5 * * * * root  /usr/local/bin/osync.sh /etc/osync/sync.conf --silent
Warning: Make sure that the destination folder is really your SysVol folder, because the command will replicate to the given directory and sync everything in it that isn't also on the source! You could damage your system! So check the output carefully to see if the replication is doing, what you expect!

When you try to resync the folder

Warning: Please follow the steps below OR you can end up with an empty sysvol folder.
  1. Disable Cron on DC1, like Add a "#" on the line with crontab -e
  2. Check is any rsync or osync are currently running in ps -aux | grep sync if yes, wait for it to finished OR kill it (if it is zombie)
  3. Remove the .osync_workdir hash files on both DC1 and DC2 on MASTER/SLAVE_SYNC_DIR "/var/lib/samba/sysvol"
  4. Now check your sysvol and resync
  5. Confirm that everything is working again
  6. Re-enable the Cron on DC1 again

FAQ

  • How can I do this on windows?
    • Install the MSYS bash environment (read the osync documentation), then you may run osync as master from Windows.
  • What to do if I've more than one DC?
    • By Theory, We would just make more cron jobs on DC1 and the complete sync will be perform next sync to all server. (Not tested)
    • Something like:
    • DC1 <> DC2
    • DC1 <> DC3
    • DC1 <> DC2


  • Why can't I simply use a distributed filesystem like GlusterFS, Lustre, etc. for SysVol?
    • A cluster file system with Samba requires CTDB to be able to do it safely. And CTDB and AD DC are incompatible. Please check on the reply from Samba Developer on the mailing list .