[Samba] Proper sysvol replication solution...

[Ryan Ashley]

If they're the same, have you tried running "samba-tool ntacl 
sysvolcheck" on both systems? My suspicion is that one of them will 
return an error or crash (sometimes the sysvolcheck crashes if an ID is 
incorrect, at least for me). I have one system up and am building the 
other one now. I'll let you know what my results are.

On 08/22/2014 11:03 AM, L.P.H. van Belle wrote:
> 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
>>
>>