Difference between revisions of "Rsync based SysVol replication workaround"

m (Change link to script)
(Being more specific, why rsync is used in this HowTo)
Line 1: Line 1:
 
= Introduction=
 
= 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 solution based on a script that uses rsync.
+
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 a script that uses rsync.
  
 
'''Like on every change/enhancement, it's highly recommended to test the procedure in a save environment and have a [[Backup_and_Recovery|recoverable backup]]!'''
 
'''Like on every change/enhancement, it's highly recommended to test the procedure in a save environment and have a [[Backup_and_Recovery|recoverable backup]]!'''
Line 9: Line 9:
  
  
= Requirements =
+
= Information on rsync-based replication =
  
 
[[Image:DC_PDC_emulator.png|thumb|Group Policy Management Console option for PDC]]
 
[[Image:DC_PDC_emulator.png|thumb|Group Policy Management Console option for PDC]]
  
This HowTo describes a way to setup rsync on your DC, that contains the FSMO role „PDC“. The script, that is used below to keep all other servers in sync, retrieves the content from the PDCs SysVol share via rsync.
+
This HowTo describes a solution for SysVol replication, that is based on rsync. As the nature of this tool, it is unidirectional. This means, files can only be transfered in one direction. That's why for rsync-based SysVol replicaton, you have to choose one DC, on which you do all modifications (GPO edits, logon script changes, etc.). And all other DCs are retrieving the changes from this host, because modifications on them are overwritten when syncing.
  
If you prefer to use rsync through a SSH tunnel, you can adapt the script to your needs. But typically there's no confidential content on the SysVol share. It should be alright for most if the transfer is unencrypted. The rsync module on the PDC is also defined as read only, because it is used only as source. So no content can be pushed to it.
+
A good choice for this "master" host is the one, that contains the FSMO role "PDC Emulator", because you can configure the Group Policy Management Console to connect especially to this machine (default), instead of choosing any of your DC. To which machine the GPMC connects, you can define at „Action“ / „Change Domain Controller“. There you should select „The domain controller with the Operations Master token for the PDC emulator“ (default).
  
Because the SysVol share on your PDC is the source where all other DCs are pulling their content from, it is required, that you only do changes (e. g. GPO, logonscripts, etc.) on this server. Changes made on the other DCs are overwritten on every sync script run.
+
Even if you say the unidirectional replication of rsync is a limitation, it has also many advantages:
 +
- already available on most distributions and can be installed through it's packet manager (if not already installed anyway)
 +
- setup is fast done
 +
- configuration is very easy
 +
- etc.
  
E. g. the Group Policy Management Console can be configured, to use the PDC to connect to. If you choose „Action“ / „Change Domain Controller“, you should select „The domain controller with the Operations Master token for the PDC emulator“ (should be already default), to do changes automatically on your PDC.
+
If you prefer to use rsync through a SSH tunnel, you can adapt the script to your needs. But typically there's no confidential content on the SysVol share. It should be sufficient for most if the transfer is unencrypted. The rsync module on the PDC is also defined as read only, because it is used only as source. So no content can be pushed to it.
  
  
Line 27: Line 31:
 
= Setup the SysVol replication =
 
= Setup the SysVol replication =
  
== Setup on the Domain Controller with the PDC role ==
+
== Setup on the Domain Controller with the PDC Emulator FSMO role ==
  
 
* Install rsync by using your paket manager or compile from source. Make sure, that you use a version that supports extended ACLs!
 
* Install rsync by using your paket manager or compile from source. Make sure, that you use a version that supports extended ACLs!

Revision as of 21:54, 24 July 2013

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 a script that uses rsync.

Like on every change/enhancement, it's highly recommended to test the procedure in a save environment and have a recoverable backup!



Information on rsync-based replication

Group Policy Management Console option for PDC

This HowTo describes a solution for SysVol replication, that is based on rsync. As the nature of this tool, it is unidirectional. This means, files can only be transfered in one direction. That's why for rsync-based SysVol replicaton, you have to choose one DC, on which you do all modifications (GPO edits, logon script changes, etc.). And all other DCs are retrieving the changes from this host, because modifications on them are overwritten when syncing.

A good choice for this "master" host is the one, that contains the FSMO role "PDC Emulator", because you can configure the Group Policy Management Console to connect especially to this machine (default), instead of choosing any of your DC. To which machine the GPMC connects, you can define at „Action“ / „Change Domain Controller“. There you should select „The domain controller with the Operations Master token for the PDC emulator“ (default).

Even if you say the unidirectional replication of rsync is a limitation, it has also many advantages: - already available on most distributions and can be installed through it's packet manager (if not already installed anyway) - setup is fast done - configuration is very easy - etc.

If you prefer to use rsync through a SSH tunnel, you can adapt the script to your needs. But typically there's no confidential content on the SysVol share. It should be sufficient for most if the transfer is unencrypted. The rsync module on the PDC is also defined as read only, because it is used only as source. So no content can be pushed to it.



Setup the SysVol replication

Setup on the Domain Controller with the PDC Emulator FSMO role

  • Install rsync by using your paket manager or compile from source. Make sure, that you use a version that supports extended ACLs!
  • If you start your rsync-server through xinetd, you can use the following configuration file (/etc/xinetd.d/rsync):
service rsync
{
   disable         = no
   only_from       = 10.99.0.0/28     # Restrict to your DC address(es) or ranges, to prevent other hosts retrieving the content, too.
   socket_type     = stream
   wait            = no
   user            = root
   server          = /usr/bin/rsync
   server_args     = --daemon
   log_on_failure += USERID
}
  • Create the file /etc/rsyncd.conf (adapt the path variable to your PDCs SysVol path):
[SysVol]
path = /usr/local/samba/var/locks/sysvol/
comment = Samba Sysvol Share
uid = root
gid = root
read only = yes
auth users = sysvol-replication
secrets file = /usr/local/samba/etc/rsyncd.secret
  • Create a file /usr/local/samba/etc/rsyncd.secret (permissions must not be world-readable!) with the following content (adapt the password!):
sysvol-replication:pa$$w0rd
  • Restart xinetd.



Setup on all other Domain Controller(s)

It's suggested to test the script on a save place, to avoid any problems in production! The script comes without any warranty!

  • Install rsync by using your paket manager or compile from source. Make sure, that you use a version that supports extended ACLs!
  • Create a file /usr/local/samba/etc/rsync-sysvol.secret and fill it with the password, set on the PDC for the sysvol-replication rsync account (permissions of that file must not be world-readable!):
pa$$w0rd
  • If you use a different rsync username than mentioned above and/or a different path to the rsync-sysvol.secret file, change it in the configuration area in the head of the script.
  • First run the script in dry-run mode:
# /path/to/rsync-sysvol-replication.sh -d
  • The script auto-discovers the path to the local SysVol share through testparm. As the share is automatically setup in your smb.conf when joining as DC, this should work without any problems.
  • The PDC IP is auto-discovered through DNS (_ldap._tcp.pdc._msdcs.your.domain.). If you encounter any problems, you can define the PDC host by -p [IP].
  • If everything looks fine on the dry-run, you can start the real replication process:
# /path/to/rsync-sysvol-replication.sh
2013-07-23 21:05:24 **********************************************************************
2013-07-23 21:05:24 Auto-discovered PDC: 10.99.0.1
2013-07-23 21:05:24 Replicating from 10.99.0.1:
2013-07-23 21:05:25      receiving file list ... done
2013-07-23 21:05:25      ./
2013-07-23 21:05:25      samdom.example.com/
2013-07-23 21:05:25      samdom.example.com/Policies/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/GPT.INI
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/MACHINE/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/MACHINE/Registry.pol
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/USER/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/USER/Documents & Settings/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/USER/Scripts/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/USER/Scripts/Logoff/
2013-07-23 21:05:25      samdom.example.com/Policies/{31B2F340-016D-11D2-945F- 00C04FB984F9}/USER/Scripts/Logon/
2013-07-23 21:05:25      samdom.example.com/Policies/{6AC1786C-016F-11D2-945F- 00C04FB984F9}/
2013-07-23 21:05:25      samdom.example.com/Policies/{6AC1786C-016F-11D2-945F- 00C04FB984F9}/GPT.INI
2013-07-23 21:05:25      samdom.example.com/Policies/{6AC1786C-016F-11D2-945F- 00C04FB984F9}/MACHINE/
2013-07-23 21:05:25      samdom.example.com/Policies/{6AC1786C-016F-11D2-945F- 00C04FB984F9}/USER/
2013-07-23 21:05:25      samdom.example.com/scripts/
2013-07-23 21:05:25      samdom.example.com/scripts/logonscript.bat
2013-07-23 21:05:25      
2013-07-23 21:05:25      sent 191 bytes  received 1908 bytes  1399.33 bytes/sec
2013-07-23 21:05:25      total size is 1207  speedup is 0.58
  • Run the script with the -h option for further information and parameters.
  • To automatically syncronize the SysVol share every 5 minutes incl. logfile creation, setup a Cron job:
*/5 * * * *     /path/to/rsync-sysvol-replication.sh -l /var/log/sysvol-replication.log > /dev/null
  • Repeat this steps on every DC (except your PDC!).