Re: [Csync2] 2-node masters and root-owned files

2017-08-29 Thread Roland van Laar

On 15-08-17 21:12, Lars Ellenberg wrote:

On Mon, Aug 14, 2017 at 07:00:23AM +0400, Vadim Abdulayev wrote:

Hello.

When replying to digests, please change the subject appropriately.
(Digest mode on a list that is so low volume as this one
is not useful anyways, really.)


All command executed on node1.

After resync i receive wrong owner on node1.
On node2, i always have
correct owner and permission.

node2 is backup node. No one working there.

csync2 is push only.

according to you, you execute all commands on node1.
node1 then is the source.
node2 is the target.

Still, according to you,
the ownership on the source changes.

Which means either your report is inconsistent,
or we are talking about a different "csync2",
or "something else is going on".

Sorry to chime in so late.
This is exactly what I see happening as well.
Node1 and node2 both have crobjobs.
Both run at "*/15 * * * * "
Files are uploaded via the web to node1.
Sometime the source node1 will have the permissions changed to root.root.
Node2 will have the correct permission.

csync2 itself will never change ownership
(or anything else) on the source.
It will apply changes on the target,
to try to make the target look like the source.

Hope that helps you drilling down further.

 Lars

___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2



___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2


Re: [Csync2] 2-node masters and root-owned files

2017-08-15 Thread Lars Ellenberg
On Mon, Aug 14, 2017 at 07:00:23AM +0400, Vadim Abdulayev wrote:
> Hello.

When replying to digests, please change the subject appropriately.
(Digest mode on a list that is so low volume as this one
is not useful anyways, really.)

> All command executed on node1.
> 
> After resync i receive wrong owner on node1.
> On node2, i always have
> correct owner and permission.
>
> node2 is backup node. No one working there.

csync2 is push only.

according to you, you execute all commands on node1.
node1 then is the source.
node2 is the target.

Still, according to you,
the ownership on the source changes.

Which means either your report is inconsistent,
or we are talking about a different "csync2",
or "something else is going on".

csync2 itself will never change ownership
(or anything else) on the source.
It will apply changes on the target,
to try to make the target look like the source.

Hope that helps you drilling down further.

Lars

___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2


Re: [Csync2] 2-node masters and root-owned files

2017-08-08 Thread Lars Ellenberg
On Tue, Aug 08, 2017 at 11:04:49AM +1000, Aristedes Maniatis wrote:
> On 8/8/17 10:06AM, Lars Ellenberg wrote:
> > but in this case, until proven otherwise,
> > I suspect you have some git command on the other node
> > running as root, and updating the index file there.
> 
> Hi Lars
> 
> I know you really need some detailed logs to understand the problem,
> however I can confirm anecdotally that it has happened for me
> recently. That is, random files owned by root instead of the correct
> user.

That's why I said "in this case" :-)

"similar" symptoms don't necessarily imply same root causes.

> For me, I have three nodes and syncing happening in all directions and
> use -B. I have probably 10,000 file operations per day and I've seen
> the problem happen maybe twice in four months. So logs are going to be
> very hard to get for you.

Your case sounds more like your csync2 connection is interrupted
at a very "inconvenient" time...

> Sorry I can't be of more direct help, but if I find a way to make it
> happen more frequently then I'll post here.

Thanks,

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT
___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2


Re: [Csync2] 2-node masters and root-owned files

2017-08-07 Thread Aristedes Maniatis
On 8/8/17 10:06AM, Lars Ellenberg wrote:
> but in this case, until proven otherwise,
> I suspect you have some git command on the other node
> running as root, and updating the index file there.

Hi Lars

I know you really need some detailed logs to understand the problem, however I 
can confirm anecdotally that it has happened for me recently. That is, random 
files owned by root instead of the correct user.

For me, I have three nodes and syncing happening in all directions and use -B. 
I have probably 10,000 file operations per day and I've seen the problem happen 
maybe twice in four months. So logs are going to be very hard to get for you.

Sorry I can't be of more direct help, but if I find a way to make it happen 
more frequently then I'll post here.


Ari


-- 
-->
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A



signature.asc
Description: OpenPGP digital signature
___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2


Re: [Csync2] 2-node masters and root-owned files

2017-08-07 Thread Lars Ellenberg
On Mon, Aug 07, 2017 at 11:26:38PM +0400, Vadim Abdulayev wrote:
> Hello.
> 
> Thank you for help.
> Sometimes = one time per day or more often
> 
> example:
> 

would have been useful if you also included the node name in the command
line...

> #ll /home/myuser/.git/index
> -rw--- 1 root root 9955696 авг  7 18:03 /home/myuser/.git/index
> 
> #chown myuser:myuser /home/myuser/.git/index
> 
> …RESYNC...

From where to where?

> # ll /home/myuser/.git/index
> -rw--- 1 root root 9955696 авг  7 22:05 /home/myuser/.git/index

and still the "wrong" uid, even immediately after a "successful" update?

> LOG:

"check" log is boring.

"update" log may be interesting, 
especially on the *receiving* ("server") side
(the side where the "wrong" uid/gid is observed)

This seems to be the log of the "client" side.
which exact command produced this?
Still,

> File /home/myuser/.git/index is different on peer (cktxt char #18).
> >>> PEER:  v1:mtime=0:mode=33204:uid=1000:gid=1000:type=reg:size=9955696
> >>> LOCAL: v1:mtime=0:mode=33152:uid=1000:gid=1000:type=reg:size=9955696

differing permissions trigger the sync,

> SQL: DELETE FROM dirty WHERE filename = '/home/myuser/.git/index' AND 
> peername = 'node2.domain.local'
> SQL: SELECT command, logfile FROM action GROUP BY command, logfile
> SQL Query finished.
> Connection closed.
> Finished with 0 errors.

and to csync2 the sync looks as if it was ok.

debug level logs and maybe even strace from the "receiving" side would be 
interesting.

but in this case, until proven otherwise,
I suspect you have some git command on the other node
running as root, and updating the index file there.


-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT
___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2


Re: [Csync2] 2-node masters and root-owned files

2017-08-07 Thread Vadim Abdulayev
Hello.

Thank you for help.
Sometimes = one time per day or more often

example:

#ll /home/myuser/.git/index
-rw--- 1 root root 9955696 авг  7 18:03 /home/myuser/.git/index

#chown myuser:myuser /home/myuser/.git/index

…RESYNC...

# ll /home/myuser/.git/index
-rw--- 1 root root 9955696 авг  7 22:05 /home/myuser/.git/index


LOG:

Match (+): /home/myuser/* on /home/myuser/.git/index
Checking /home/myuser/.git/index.
SQL: SELECT checktxt FROM file WHERE filename = '/home/myuser/.git/index'
File has changed: /home/myuser/.git/index
SQL Query finished.
SQL: DELETE FROM file WHERE filename = '/home/myuser/.git/index'
SQL: INSERT INTO file (filename, checktxt) VALUES ('/home/myuser/.git/index', 
'v1%3Amtime=1502118184%3Amode=33152%3Auid=1000%3Agid=1000%3Atype=reg%3Asize=9955696')
Match (+): /home/myuser/* on /home/myuser/.git/index
Match (+): /home/myuser/* on /home/myuser/.git/index
Marking file as dirty: /home/myuser/.git/index
SQL: DELETE FROM dirty WHERE filename = '/home/myuser/.git/index' AND peername 
= 'node2.domain.local'
SQL: INSERT INTO dirty (filename, forced, myname, peername) VALUES 
('/home/myuser/.git/index', 0, 'node1.domain.local', 'node2.domain.local')


…. CUT...


Connecting to host node2.domain.local (SSL) ...
Bound to XX.XX.XX.XX:0 as node1.domain.local.
Connect to XX.XX.XX.XX:30865 (node2.domain.local).
sign handshake cert vrfy: picked RSA-SHA256 with SHA256
SQL: SELECT certdata FROM x509_cert WHERE peername = 'node2.domain.local'
SQL Query finished.
Peer x509 certificate is: 
30820300308201E8020900F8C003A63D885485300D06092A864886F70D01010505003042310B30090603550406130258583115301306035504070C0C44656661756C742043697479311C301A060355040A0C1344656661756C7420436F6D70616E79204C7464301E170D3137303732313132343931375A170D3139303331333132343931375A3042310B30090603550406130258583115301306035504070C0C44656661756C742043697479311C301A060355040A0C1344656661756C7420436F6D70616E79204C746430820122300D06092A864886F70D01010105000382010F003082010A0282010100CD04D1479DFEBEDEB1284BC21044047E5B4A1B8A89D32B678D5DB4D82AF0925AF024B14265AC967D25722EEC4BCCD8F7E8B9BED7BAF903D8DC004EC3A6A7D2B1A36C359A256F5FAD4770ED7E767C266BA9B92E99AB768B28C735DD40758E5126015F3001DF8F6DEA27821ABF9705656493D36AC786860D0300745D8BCB0E1741695818321D6BD3BD3C64D03BE9D164E2BE902855AB24810D8B6A9150B49521D13508DA7B37304A4FC9F9E0CE8A3C5F8DC8AFF5E2FB2C8A0E895E409BD3EE6A80874924EDFBC6BCF9722E87A6296A098898D09ADEEC58481F2EF79906656F3B6B6882895EE2220DF831BD20815E4275C12E942DBC4DF9055331E2759E01DF19190203010001300D06092A864886F70D010105050003820101009D1CC7FA9B6A62DB4E04EC163F2DAF79D661A6FFC586E9626782B53F0AD1227A3E9B13D0BED68403608359BE6781ED98E0B31CC86EF931F7C0A8D19E65BD4A5CD41F4DF6E606D4F05641B5E9759E209EDFEC33B0FBB1835DE6EAB21FFD9A40A804CC0ED6B1891A8E77F19CB22337EF2FA7C7B469F750765578121A830DB1F39A6D25E0CF4B51D3106B6981DD43D32AE55906AB5B71CA7045497B1D474B0F4E7EB07E5FECC5282AF00A2491EB0B7DB3BA555285587D47A0787EA558DE64F497107ABF0F0CC598158932D37D2BAF31187E32BCAA8E499BC9341D61DCA8ECDA181DBE7D9DAB93481DC54B4D75BBA8617C626A84BE92F29B085096BB16F21330574C
While syncing file /home/myuser/.git/index:
Match (+): /home/myuser/* on /home/myuser/.git/index
Updating /home/myuser/.git/index on node2.domain.local ...
While syncing file /home/myuser/.git/index:
File /home/myuser/.git/index is different on peer (cktxt char #18).
>>> PEER:  v1:mtime=0:mode=33204:uid=1000:gid=1000:type=reg:size=9955696
>>> LOCAL: v1:mtime=0:mode=33152:uid=1000:gid=1000:type=reg:size=9955696
While syncing file /home/myuser/.git/index:
While syncing file /home/myuser/.git/index:
Database idle in transaction. Forcing COMMIT.
SQL: COMMIT
While syncing file /home/myuser/.git/index:
While syncing file /home/myuser/.git/index:
While syncing file /home/myuser/.git/index:
While syncing file /home/myuser/.git/index:
SQL: DELETE FROM dirty WHERE filename = '/home/myuser/.git/index' AND peername 
= 'node2.domain.local'
SQL: SELECT command, logfile FROM action GROUP BY command, logfile
SQL Query finished.
Connection closed.
Finished with 0 errors.


Best regards,
Vadim
___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2


Re: [Csync2] 2-node masters and root-owned files

2017-08-07 Thread Lars Ellenberg
On Fri, Aug 04, 2017 at 11:01:17AM +0400, Vadim Abdulaev wrote:
> Hello.
> 
> I have a problem with Csync2 replication. 2 servers with centos 7 and
> csync2.0.2 (from okay repo). Files owner name, user ID and group ID are
> same on each server.
> 
> Sometimes, on only 2 files owner changed to root.root and permissions to
> 600 on first node (on second node owner and permissions are correct).
> If i change file owner to correct on first node. After syncing it changed
> again to root.root.
> 
> Any advice?

Try to narrow down "sometimes".
If we can reproduce, we can at least explain,
and most likely fix it.

Note that csync2 replicates numerical uid/gid.

You can try to increase verbosity, and when it happens,
the log lines about that file may give us some clues.

Lars

___
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2