[Samba] Proper sysvol replication solution...

[Ryan Ashley]

I know it is, on purpose. Copying the ACLs from one DC to another is bad 
because for some reason each DC may have a different ID for the built-in 
accounts. In fact I believe it was Rowland who was saying something 
about copying the "idmap.tdb" file over if you sync the ACLs. My method 
only copies over the files and directories so no ACLs get screwy. Maybe 
Rowland can reiterate what he said on the other thread.

I actually did use rsync for a while and then realized I was messing up 
after several machines stopped being able to access the sysvol share on 
the second DC. When I ran "samba-tool ntacl sysvolcheck" it would crash. 
I ran a reset and all was good, until the next rsync. I finally figured 
it out and removed rsync and the rsync cron job.

So tell me, why are you using rsync and unison? I am also trying to 
figure out how your script figures out which way to use rsync (DC1->DC2 
or DC2->DC1) based on what changes are on each DC. In other words, would 
your script work if a directory and file was created on DC1 AND a 
directory was removed on DC2? Would the new stuff get copied to DC2 and 
would the directory be removed on DC1? Forgive me, but I am not a bash 
scripting god. I know the basics and can get my work done, but I am not 
understanding how your script does two-way stuff via the rsync portion.

On 08/22/2014 02:21 AM, L.P.H. van Belle wrote:
> ah you didnt see my script...
>
> https://secure.bazuin.nl/scripts/3-setup-sysvol-bidirectional.sh
>
> You way is missing the ACL.. you need rsync with unison.
> its all in my script.
>
>
> Greetz,
>
> Louis
>
>
>
>> -----Oorspronkelijk bericht-----
>> Van: ryana at reachtechfp.com
>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>> Verzonden: vrijdag 22 augustus 2014 0:14
>> Aan: samba at lists.samba.org
>> Onderwerp: [Samba] Proper sysvol replication solution...
>>
>> I see the Samba guide suggests using rsync to keep sysvols in
>> sync, but
>> this poses a problem with ID's and it is only one-way. I have been
>> hesitant to suggest anything because of the flak I have been getting,
>> but I do believe I have a much better solution that transfers
>> files via
>> SSH, is bi-directional (no more only editing group policy on one
>> server), and does NOT set UID/GID information. In other words, it is
>> PERFECT for sysvol replication, and has been working on several of my
>> domains for around a year and a half without a hitch. The
>> solution I am
>> proposing is to use unison, which also works on Windows and (I
>> think) Mac.
>>
>> The way I have unison working on my systems is to install
>> unison on all
>> DC's, which is required. You also need an SSH server and client on all
>> DC's, but I assume most of you do anyway. Once they're
>> installed, it is
>> as simple as the command below. This will synchronizes changes
>> BOTH WAYS
>> without touching your UID/GID setup. If you're paranoid, you could
>> always do a sysvolreset when done though.
>>
>> unison -batch "/path/to/sysvol" "ssh://dc02.domain.lan//path/to/sysvol"
>>
>> If you do this at a command-line, it will prompt you for your password
>> on the remote machine. This would prevent a cron job, but I overcame
>> that as well. You can create an SSH key that does not require
>> a password
>> for the systems to use. This means you can now create a cron job to
>> handle the replication every fifteen minutes or so. You could also use
>> something like "incrond" to monitor for changes in the sysvol
>> and launch
>> unison as well, but I don't personally modify the sysvol often, so
>> replication every fifteen minutes works for me.
>>
>> To create an SSH key to allow password-less replication via unison, do
>> the following.
>>
>> ssh-keygen -t dsa
>>
>> When it prompts for a file to save the key in, it should be your home
>> directory in a ".ssh" directory. I run as root, so this is
>> "/root/.ssh/id_dsa" for me. It will then prompt for a password. Ignore
>> this and just press enter. It will ask you to verify the
>> password. Press
>> enter again. If you enter a password here, it cannot run
>> without user input!
>>
>> Next, you need to copy the key to your other domain
>> controllers. You can
>> do so as follows. Note that my example is run as root. Substitute your
>> user's path if needed.
>>
>> ssh-copy-id -i /root/.ssh/id_dsa.pub root at dc02.domain.lan
>>
>> Once that is done, login to the domain controller you copied
>> the key to
>> (in the example, dc02) and check "/root/.ssh/authorized_keys"
>> to verify
>> that the key was added and nothing unexpected is there. You
>> can do this
>> with "cat /root/.ssh/authorized_keys". You should see a key on
>> a single
>> line followed by the hostname of your primary domain controller. If it
>> is there, they may now connect via SSH without a password!
>>
>> You may now copy the key to any other domain controllers in
>> your domain
>> so they trust the primary DC as well. After that, all that is left is
>> the synchronization. I urge you to run the first synchronization
>> manually, like below.
>>
>> unison "/path/to/sysvol" "ssh://dc02.domain.lan//path/to/sysvol"
>>
>> Make sure everything looks good, synchronize it, then repeat
>> for each DC
>> on your domain. Once done, you can create cron jobs to sync
>> each server,
>> or use a script like mine below. This script is on my primary DC. I
>> actually only have two DC's, but I added more as an example here.
>>
>> #!/bin/bash
>> SERVERLIST="dc02.domain.lan dc03.domain.lan dc04.domain.lan"
>> SVPATH="/path/to/sysvol"
>>
>> # Synchronize all of the domain controllers
>> for sLoop in ${SERVERLIST}
>> do
>>    unison -batch "${SVPATH}" "ssh://${sLoop}/${SVPATH}"
>> done
>>
>> exit 0
>>
>> Now set that script to run in a cron job and you're golden. You could
>> also setup "incrond" on all of your DC's and have it call
>> unison to sync
>> the other DC's whenever a write happens in your sysvol, but I do not
>> need such a thing and have not personally tried it, though I have a
>> fellow IT lead who has and likes it. My crontab job entry is
>> listed below.
>>
>> 15 * * * * /root/sysvolsync.sh &> /dev/null
>>
>> I hope this helps somebody and if you see something wrong,
>> feel free to
>> let me know.
>> -- 
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>>