Bidirectional Rsync/Unison based SysVol replication workaround
- 1 Introduction
- 2 Information on Osync replication
- 3 Setup the SysVol replication
- 4 When you try to resync the folder
- 5 FAQ
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 (rsync is required). As Compare to the rsync method, it is bidirectional. But this howto only cover two DC setup.
It have the following advantages:
- setup is fast
- configuration is very easy
- Can work with windows (Todo)
In this setup we will use rsync through a SSH tunnel.
Setup the SysVol replication
At the time of writing this Osync is still at v.100pre. However, you should always get a stable branch when it is available. We are getting it done using master branch.
wget https://raw.githubusercontent.com/deajan/osync/master/osync.sh chmod +x osync.sh
Move osync to /usr/bin/ or your preferred dir
mv osync.sh /usr/bin/
Getting Osync Configuration
Move it to /etc/osync/
mkdir /etc/osync/ mv sync.conf /etc/osync/sync.conf
Setup on the Domain Controller with the PDC Emulator FSMO role
- You are running all command as root.
- rsync is installed on both server
- sysvol is located /var/lib/samba/sysvol on both DC1 and DC2
- osync is located /usr/bin/osync
- osync.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 or compile from source. Make sure, that you use a version that supports extended ACLs!
- 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
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="email@example.com"
Osync have also backup and soft delete which will kept a copy of deleted files and folder. You can choose to enable them.
- Branch Fix#22 fix the soft delete issue you can get them from the url below, however, it should be check in to stable branch soon.
Osync have 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/
What happen is we use rsync to create the directory structure with extended attributes Than unison setup copies only the extened attributes on files.
Please make a backup on you sysvol just in case.
/usr/bin/osync.sh /etc/osync/sync.conf --dry --verbose
If this run successfully let remove the --dry and execute it.
/usr/bin/osync.sh /etc/osync/sync.conf --verbose
Add to Crontab on DC1
On DC1 run the following:
crontab -e */5 * * * * root /usr/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!
When you try to resync the 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 crontab -e
- Check is any rsync or osync are currently running in ps -aux 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 MASTER/SLAVE_SYNC_DIR "/var/lib/samba/sysvol"
- Now check your sysvol and resync
- Confirm that everything is ok again
- Re-enable the Cron on DC1 again
- How can I do this on windows?
- I don't have an answer, please post on the mailing list
- 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 .