[Csync2] 3-node masters and root-owned files

[Mark Hodge]

I found that csync2 doesn't care if a user exists on a target node, it 
sets the numerical value to the same as that on the source.

As a workaround for the root:root issue, I had to make sure csync2 was 
only running on one node at a time.
For 3 nodes, use something like this in cron:

Node 1: * * * * * root /etc/csync2.cron >> /var/log/csync2.log 2>&1
Node 2: * * * * * root sleep 20; /etc/csync2.cron >> /var/log/csync2.log 
2>&1
Node 3: * * * * * root sleep 40; /etc/csync2.cron >> /var/log/csync2.log 
2>&1

If all your files sync within 20 secs you can just run the csync2 binary 
here.
However if you have some large files that take mins or hours, you need a 
script like this:

#/etc/csync2.cron
cmd="pgrep -c csync2"
n0=`$cmd`
n1=`ssh -o ConnectTimeout=1 -q node2 $cmd`
n2=`ssh -o ConnectTimeout=1 -q node3 $cmd`
if [ -z $n1 ]; then n1="0"; fi
if [ -z $n2 ]; then n2="0"; fi
if [ $n1 -lt 1 ] && [ $n2 -lt 1 ]; then
  /usr/bin/flock -n /var/lock/csync2 /usr/sbin/csync2 -xv
fi

Modify accordingly for each node and you should have no more root:root 
issues.

It's not ideal because one node can 'hog' all the sync time meaning new 
files on the other nodes don't get updated until it's finished.

Mark.


On 07/08/2017 10:20, Lars Ellenberg wrote:
> On Wed, Aug 02, 2017 at 08:58:05PM -0500, Kevin Cackler wrote:
>> For those of you guys who are experiencing this issue: I noticed tonight,
>> after this happened yet again, that one of my files was owned by UID 1012 on
>> node3. The problem is that that uid does not exist on node3. That uid DOES
>> exist on node1, and was the affected user. So when csync2 copied this file
>> from node1 to node3, it copied the UID as well, and since that UID doesn't
>> exist on node3, the user on node3 did not have permission to access the
>> file.
>>
>> In other words:
>>
>> "user" on node1 has a UID of 1012
>> "user" on node3 has a UID of 1007
>> "user" updated a file on node1. When that file was copied to node3, the UID
>> of the owner and group was 1012 instead of 1007. This meant that "user"
>> could not access the file on node3.
>>
>> I really hope this can be resolved soon, as it's causing a ton of grief for
>> us.
> csync2 replicates numerical uid/gid.
> that has always been that way.
> If you find someone to write a "by name" feature,
> we are happy to take it.
>
> when authenticating against /etc/passwd and friends,
> you may want to put that into csync2 as well.
> otherwise, you have "centralized" authentication anyways (ldap or
> similar), and the id <-> name mapping is already covered.
>
>      Lars
>
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2