[Samba] Proper sysvol replication solution...

[L.P.H. van Belle]

when i look on my sysvol and subfolders
and 
getfacl /home/samba/sysvol/internal.domain.tld/
the on both servers is the same. 
and when i look from within windows both shares are exacly the same with rights. 
share files and folders. 

maybe im lucky ;-) 

no, i dont need these mappings imo since i dont have any linux/unix user to the sysvol share. 
makes life lot easier.. 

Louis



>-----Oorspronkelijk bericht-----
>Van: ryana at reachtechfp.com 
>[mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>Verzonden: vrijdag 22 augustus 2014 16:47
>Aan: samba at lists.samba.org
>Onderwerp: Re: [Samba] Proper sysvol replication solution...
>
>Domain users don't enter the equation here though. We're talking the 
>"well-known" RID's like Rowland just mentioned. In other words, if my 
>"Authenticated Users" is XID 30001 on DC1 but it is 30009 on DC2, I 
>would not want to clone the UID/GID info from DC1 to DC2, only 
>the files 
>and directories. That where the "idmap.ldb" file comes into play. 
>Apparently it is created with random XID's when Samba is 
>configured and 
>ran for the first time on each machine. Does your script copy those 
>UID/GID numbers over? If so, I was under the impression that such a 
>thing was bad.
>
>I am currently setting up two virtual machines (VirtualBox) to 
>play with 
>your script. I want to understand how it works and this way I am not 
>worried about destroying a client's domain while I am toying around.
>
>On 08/22/2014 10:34 AM, L.P.H. van Belle wrote:
>>> -----Oorspronkelijk bericht-----
>>> Van: ryana at reachtechfp.com
>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>>> Verzonden: vrijdag 22 augustus 2014 15:30
>>> Aan: samba at lists.samba.org
>>> Onderwerp: Re: [Samba] Proper sysvol replication solution...
>>>
>>> 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.
>>>
>> Yes, your right, it can be different if you dont keep de the 
>default settings.
>> Which should be ok. I dont have any reason to change the 
>acls on sysvol.
>> And i only use my ADDC as DC and not as file server so i 
>dont have any idmap problems.
>> And i only use windows users to access these shares.
>> No linux users or what have access to these machines. only 
>me as linux user and windows user.
>> and that are 2 different accounts. my linux user is only use 
>to maintain the system.
>>
>>> 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.
>> Well normal questions.. so
>> If a file is remove from sysvol on DC1 it removes it also from DC2.
>> If at the same time a folder or file was remove from DC2 
>then it does the same with it on DC1.
>> just test it.. you see.
>> And best tip of the day.. make a backup of your sysvol 
>before you start,
>> when you rest things and you forget to remove the unison 
>hash files you can delete you sysvol..
>>
>> we need rsync to create the directory structure with 
>extended attributes,
>> the (now) unison setup copies only the extened attributes on files.
>>
>> cron does the sync every 5 min for me and you can also use 
>inotify for that.
>> You can search for that one on the list.
>>
>> Hope answere this helps you.
>>
>>
>>> 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
>>>>>
>>>>>
>>> -- 
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>>
>
>-- 
>To unsubscribe from this list go to the following URL and read the
>instructions:  https://lists.samba.org/mailman/options/samba
>
>