During mountbroker setup: 'gluster-mountbroker <mountbroker-root> <group>'
commad to set the permission and group for GEOREP_DIR directory
(/var/lib/glusterd/geo-replication) fails due to extra argument, which is
enssential for non-root geo-rep setup.

fixes: bz#1721441
Change-Id: Ia83442733bf0b29f630e8c9e398097316efca092
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>

CID: 1400730
updates: bz#789278
Change-Id: I0f6924050a31d3d2cc0b555f859920e349728e0a
Signed-off-by: Sheetal Pamecha <spamecha@redhat.com>

Problem:

Unable to setup mountbroker root directory while creating geo-replication
session for non-root user.

Casue:
With patch[1] which defines the max-port for glusterd one extra sapce
got added in field of 'option max-port'.
[1]. https://review.gluster.org/#/c/glusterfs/+/21872/

In geo-rep spliting of key-value pair form vol file was done on the
basis of space so this additional space caused "ValueError: too many values
to unpack".

Solution:
Use split so that it can treat consecutive whitespace as a single separator.

Fixes: bz#1709248
Change-Id: Ia22070a43f95d66d84cb35487f23f9ee58b68c73
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>

The gfid conflict resolution code path is not supposed
to hit in generic code path. But few of the heavy rename
workload (BUG: 1694820) makes it a generic case. So
logging the entries to be fixed as INFO floods the log
in these particular workloads. Hence convert them to DEBUG.

fixes: bz#1709653
Change-Id: I4d5e102b87be5fe5b54f78f329e588882d72b9d9
Signed-off-by: Kotresh HR <khiremat@redhat.com>

Problem:
Geo-rep sync hangs when tarssh is used as sync
engine at heavy workload.

Analysis and Root cause:
It's found out that the tar process was hung.
When debugged further, it's found out that stderr
buffer of tar process on master was full i.e., 64k.
When the buffer was copied to a file from /proc/pid/fd/2,
the hang is resolved.

This can happen when files picked by tar process
to sync doesn't exist on master anymore. If this count
increases around 1k, the stderr buffer is filled up.

Fix:
The tar process is executed using Popen with stderr as PIPE.
The final execution is something like below.

tar | ssh <args> root@slave tar --overwrite -xf - -C <path>

It was waiting on ssh process first using communicate() and then tar.
Note that communicate() reads stdout and stderr. So when stderr of tar
process is filled up, there is no one to read until untar via ssh is
completed. This can't happen and leads to deadlock.
Hence we should be waiting on both process parallely, so that stderr is
read on both processes.

Change-Id: I609c7cc5c07e210c504771115b4d551a2e891adf
fixes: bz#1707728
Signed-off-by: Kotresh HR <khiremat@redhat.com>

Problem:
When 'use_tarssh' is set to true, it exits with successful
message but the default 'rsync' was used as sync-engine.
The new config 'sync-method' is not allowed to set from cli.

Analysis and Fix:
The 'use_tarssh' config is deprecated with new
config framework and 'sync-method' is the new
config to choose sync-method i.e. tarssh or rsync.
This patch fixes the 'sync-method' config. The allowed
values are tarssh and rsync.

Change-Id: I0edb0319cad0455b29e49f2f08a64ce324735e84
fixes: bz#1707686
Signed-off-by: Kotresh HR <khiremat@redhat.com>

There are two ways for creating secret pem pub file during geo-rep
setup.
1. gluster-georep-sshkey generate
2. gluster system:: execute gsec_create

Below patch solves this problem for `gluster-georep-sshkey generate`
method.
Patch link: https://review.gluster.org/#/c/glusterfs/+/22246/

This patch is added to support old way of creating secret pem pub file
`gluster system:: execute gsec_create`.

Problem:  While Geo-rep setup when creating an ssh authorized_keys
          the geo-rep setup inserts an extra space before the "ssh-rsa" label.
          This gets flagged by an enterprise customer's security scan as a
          security violation.
Solution: Remove extra space while creating secret key.

fixes: bz#1679401
Change-Id: I92ba7e25aaa5123dae9ebe2f3c68d14315aa5f0e
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>

Problem:
   Geo-rep fails to sync the rename properly if destination exists.
It results in source to be remained on slave causing more number of
files on slave. Also heavy rename workload like logrotate caused
lot of ESTALE errors

Cause:
   Geo-rep fails to sync rename if destination exists if creation
of source file also falls into single batch of changelogs being
processed. This is because, after fixing problematic gfids verifying
from master, while re-processing original entries, CREATE also was
re-processed causing more files on slave and rename to be failed.

Solution:
   Entries need to be removed from retrial list after fixing
problematic gfids on slave so that it's not re-created again on slave.
   Also treat ESTALE as EEXIST so that the error is properly handled
verifying the op on master volume.

Change-Id: I50cf289e06b997adddff0552bf2466d9201dd1f9
fixes: bz#1694820
Signed-off-by: Kotresh HR <khiremat@redhat.com>
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>

Entries counter was incremented twice and decremented only
once. And entries count was being used in place of metadata
entries. This patch fixes both of them.

fixes: bz#1512093
Change-Id: I5601a5fe8d25c9d65b72eb529171e7117ebbb67f
Signed-off-by: Kotresh HR <khiremat@redhat.com>

Issue:

libgfchangelog.so: cannot open shared object file

Due to hardcoded shared library name runtime loader looks for particular version of
a shared library.

Solution:

Using find_library to locate shared library at runtime solves this issue.

Traceback (most recent call last):
  File "/usr/libexec/glusterfs/python/syncdaemon/gsyncd.py", line 323, in main
    func(args)
  File "/usr/libexec/glusterfs/python/syncdaemon/subcmds.py", line 82, in subcmd_worker
    local.service_loop(remote)
  File "/usr/libexec/glusterfs/python/syncdaemon/resource.py", line 1261, in service_loop
    changelog_agent.init()
  File "/usr/libexec/glusterfs/python/syncdaemon/repce.py", line 233, in __call__
    return self.ins(self.meth, *a)
  File "/usr/libexec/glusterfs/python/syncdaemon/repce.py", line 215, in __call__
    raise res
OSError: libgfchangelog.so: cannot open shared object file: No such file or directory

Change-Id: I3dd013d701ed1cd99ba7ef20d1898f343e1db8f5
fixes: bz#1699394
Signed-off-by: Sunny Kumar <sunkumar@redhat.com>