glusterfs.git/xlators/mgmt, branch v3.12.10

glusterd/geo-rep: Fix glusterd crash

2018-06-11T10:18:26+00:00

Using strdump instead of gf_strdup crashes
during free if mempool is being used.
gf_free checks the magic number in the
header which will not be taken care if
strdup is used.

Backport of:
> Patch: https://review.gluster.org/19993/
> Change-Id: Iab36496554b838a036af9d863e3f5fd07fd9780e
> Signed-off-by: Kotresh HR 
(cherry picked from commit 57632e3c1a33187d1d23f101f83cd8759142acac)

fixes: bz#1577868
Change-Id: Iab36496554b838a036af9d863e3f5fd07fd9780e
Signed-off-by: Kotresh HR

server/auth: add option for strict authentication

2018-04-22T22:13:37+00:00

When this option is enabled, we will check for a matching
username and password, if not found then the connection will
be rejected. This also does a checksum validation of volfile

The option is invalid when SSL/TLS is in use, at which point
the SSL/TLS certificate user name is used to validate and
hence authorize the right user. This expects TLS allow rules
to be setup correctly rather than the default *.

This option is not settable, as a result this cannot be enabled
for volumes using the CLI. This is used with the shared storage
volume, to restrict access to the same in non-SSL/TLS environments
to the gluster peers only.

Tested:
  ./tests/bugs/protocol/bug-1321578.t
  ./tests/features/ssl-authz.t
  - Ran tests on volumes with and without strict auth
    checking (as brick vol file needed to be edited to test,
    or rather to enable the option)
  - Ran tests on volumes to ensure existing mounts are
    disconnected when we enable strict checking

Change-Id: I2ac4f0cfa5b59cc789cc5a265358389b04556b59
fixes: bz#1570430
Signed-off-by: Mohammed Rafi KC 
Signed-off-by: ShyamsundarR

shared storage: Prevent mounting shared storage from non-trusted client

2018-04-22T22:12:32+00:00

gluster shared storage is a volume used for internal storage for
various features including ganesha, geo-rep, snapshot.

So this volume should not be exposed to the client, as it is
a special volume for internal use.

This fix wont't generate non trusted volfile for shared storage volume.

Change-Id: I8ffe30ae99ec05196d75466210b84db311611a4c
updates: bz#1570430
Signed-off-by: Mohammed Rafi KC

glusterd: import volumes in separate synctask

2018-04-06T12:46:32+00:00

With brick multiplexing, to attach a brick to an existing brick process
the prerequisite is to have the compatible brick to finish it's
initialization and portmap sign in and hence the thread might have to go
to a sleep and context switch the synctask to allow the brick process to
communicate with glusterd. In normal code path, this works fine as
glusterd_restart_bricks () is launched through a separate synctask.

In case there's a mismatch of the volume when glusterd restarts,
glusterd_import_friend_volume is invoked and then it tries to call
glusterd_start_bricks () from the main thread which eventually may land
into the similar situation. Now since this is not done through a
separate synctask, the 1st brick will never be able to get its turn to
finish all of its handshaking and as a consequence to it, all the bricks
will fail to get attached to it.

Solution : Execute import volume and glusterd restart bricks in separate
synctask. Importing snaps had to be also done through synctask as
there's a dependency of the parent volume need to be available for the
importing snap functionality to work.

>mainline patch : https://review.gluster.org/#/c/19357/
                  https://review.gluster.org/#/c/19536/

Change-Id: I290b244d456afcc9b913ab30be4af040d340428c
BUG: 1543708
Signed-off-by: Atin Mukherjee

glusterd: optimize glusterd import volumes code path

2018-03-08T06:44:17+00:00

In case there's a version mismatch detected for one of the volumes
glusterd was ending up with updating all the volumes which is a
overkill.

>mainline patch : https://review.gluster.org/#/c/19358/

Change-Id: I6df792db391ce3a1697cfa9260f7dbc3f59aa62d
BUG: 1543709
Signed-off-by: Atin Mukherjee 
(cherry picked from commit bb34b07fd2ec5e6c3eed4fe0cdf33479dbf5127b)

glusterd/store: handle the case of fsid being set to 0

2018-03-06T08:30:54+00:00

Generally this would happen when a system gets upgraded from an
version which doesn't have fsid details, to a version with fsid
values. Without this change, after upgrade, people would see reduced
'df ' output, causing lot of confusions.

Debugging Credits: Nithya B 

Change-Id: Id718127ddfb69553b32770b25021290bd0e7c49a
BUG: 1517260
Signed-off-by: Amar Tumballi

glusterd: fix tier-enabled flag op-version check

2018-02-13T05:49:48+00:00

tier-enabled flag in volinfo structure was introduced in 3.10, however
while writing this value to the glusterd store was done with a wrong
op-version check which results into volume checksum failure during upgrades.

>Change-Id: I4330d0c4594eee19cba42e2cdf49a63f106627d4
>BUG: 1544600
>Signed-off-by: Atin Mukherjee 

Change-Id: I4330d0c4594eee19cba42e2cdf49a63f106627d4
BUG: 1544637
Signed-off-by: hari gowtham

glusterd: process pmap sign in only when port is marked as free

2018-02-02T06:48:39+00:00

Because of some crazy race in volume start code path because of friend
handshaking with volumes with quorum enabled we might end up into a situation
where glusterd would start a brick and get a disconnect and then immediately try
to start the same brick instance based on another friend update request. And
then if for the very first brick even if the process doesn't come up at the end
sign in event gets sent and we end up having two duplicate portmap entries for
the same brick. Since in brick start we mark the previous port as free, its
better to consider a sign in request as no op if the corresponding port type is
marked as free.

>mainline patch : https://review.gluster.org/#/c/19263/

Change-Id: I995c348c7b6988956d24b06bf3f09ab64280fc32
BUG: 1537346
Signed-off-by: Atin Mukherjee 
(cherry picked from commit 9d708a3739c8201d23f996c413d6b08f8b13dd90)

glusterd: connect to an existing brick process when qourum status is NOT_APPLICABLE_QUORUM

2018-01-12T05:43:49+00:00

First of all, this patch reverts commit 635c1c3 as the same is causing a
regression with bricks not coming up on time when a node is rebooted.
This patch tries to fix the problem in a different way by just trying to
connect to an existing running brick when quorum status is not
applicable.

>mainline patch : https://review.gluster.org/#/c/19134/

Change-Id: I0efb5901832824b1c15dcac529bffac85173e097
BUG: 1511301
Signed-off-by: Atin Mukherjee

quota: fixes issue in quota.conf when setting large number of limits

2018-01-10T06:59:18+00:00

Problem: It was not possible to configure more than 7712 quota limits.
This was because a stack buffer of size 131072 was used to read from
quota.conf file. In the new format of quota.conf file each gfid entry
takes 17bytes (16byte gfid + 1 byte type). So, the buf_size was not a
multiple of gfid entry size and as per code this was considered as
corruption.

Solution: make buf size multiple of gfid entry size

Change-Id: Id036225505a47a4f6fa515a572ee7b0c958f30ed
BUG: 1489043
Signed-off-by: Sanoj Unnikrishnan 
(cherry picked from commit 2899a4f125735636fe7cd8db73c0b8a13289df9b)