glusterfs.git/xlators/protocol/server/src/server.c, branch v3.7.16

glusterd: add defence mechanism to avoid brick port clashes

2016-05-05T03:23:19+00:00

Intro:
Currently glusterd maintain the portmap registry which contains ports that
are free to use between 49152 - 65535, this registry is initialized
once, and updated accordingly as an then when glusterd sees they are been
used.

Glusterd first checks for a port within the portmap registry and gets a FREE
port marked in it, then checks if that port is currently free using a connect()
function then passes it to brick process which have to bind on it.

Problem:
We see that there is a time gap between glusterd checking the port with
connect() and brick process actually binding on it. In this time gap it could
be so possible that any process would have occupied this port because of which
brick will fail to bind and exit.

Case 1:
To avoid the gluster client process occupying the port supplied by glusterd :

we have separated the client port map range with brick port map range more @
http://review.gluster.org/#/c/13998/

Case 2: (Handled by this patch)
To avoid the other foreign process occupying the port supplied by glusterd :

To handle above situation this patch implements a mechanism to return EADDRINUSE
error code to glusterd, upon which a new port is allocated and try to restart
the brick process with the newly allocated port.

Note: Incase of glusterd restarts i.e. runner_run_nowait() there is no way to
handle Case 2, becuase runner_run_nowait() will not wait to get the return/exit
code of the executed command (brick process). Hence as of now in such case,
we cannot know with what error the brick has failed to connect.

This patch also fix the runner_end() to perform some cleanup w.r.t
return values.

Backport of:
> Change-Id: Iec52e7f5d87ce938d173f8ef16aa77fd573f2c5e
> BUG: 1322805
> Signed-off-by: Prasanna Kumar Kalever 
> Reviewed-on: http://review.gluster.org/14043
> Tested-by: Prasanna Kumar Kalever 
> Reviewed-by: Atin Mukherjee 
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
> Reviewed-by: Raghavendra G 
> Signed-off-by: Prasanna Kumar Kalever 

Change-Id: Ief247b4d4538c1ca03e73aa31beb5fa99853afd6
BUG: 1323564
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/14208
Tested-by: Prasanna Kumar Kalever 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra G

server: send lookup on root inode when itable is created

2016-03-31T12:15:32+00:00

This is a backport of http://review.gluster.org/#/c/13837

 * xlators like quota, marker, posix_acl can cause problems
   if inode-ctx are not created.
   sometime these xlarors may not get lookup on root inode
   with below cases
   1) client may not send lookup on root inode (like NSR leader)
   2) if the xlators on one of the bricks are not up,
      and client sending lookup during this time: brick
      can miss the lookup
   It is always better to make sure that there is one lookup
   on root. So send a first lookup when the inode table is created

 * When sending lookup on root, new inode is created, we need to
   use itable->root instead

> Change-Id: Iff2eeaa1a89795328833a7761789ef588f11218f
> BUG: 1320818
> Signed-off-by: vmallika 
> Reviewed-on: http://review.gluster.org/13837
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Jeff Darcy 

Change-Id: I0abf45444c21b3bc77b5a75ab9a2049a411048d3
BUG: 1320892
Signed-off-by: vmallika 
Reviewed-on: http://review.gluster.org/13862
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

protocol/server: Race between server_reconfigure and server_setvolume

2016-01-26T06:28:17+00:00

During server_reconfigure we authenticate each connected clients
against the current options. To do this authentication we store
previous values in a dictionary during the connection establishment
phase (server_setvolume). If the authentication fails during
reconfigure then we will disconnect the transport.

Here it introduce a race between server_setvolume and reconfugure.
If a reconfigure called before doing a setvolume, the transport
will be disconnected

Backport of>
>Change-Id: Icce2c28a171481327a06efd3901f8a5ee67b05ab
>BUG: 1300564
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: http://review.gluster.org/13271
>Smoke: Gluster Build System 
>Reviewed-by: Raghavendra G 
>CentOS-regression: Gluster Build System 
>Reviewed-by: Raghavendra Talur 
>NetBSD-regression: NetBSD Build System 

(cherry picked from commit 16f6579cb3e1214b1386fb530b8e16c8cbfdef33)

Change-Id: I8ab7ad4bd5d2d70bcdae7bcbc233930bcfbeb411
BUG: 1300978
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/13280
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Raghavendra G

server/protocol: option for dynamic authorization of client permissions

2015-10-13T16:05:37+00:00

problem:
assuming gluster volume is already mounted (for gfapi: say client transport
connection has already established), now if somebody change the volume
permissions say *.allow | *.reject for a client, gluster should allow/terminate
the client connection based on the fresh set of volume options immediately,
but in existing scenario neither we have any option to set this behaviour nor
we take any action until and unless we remount the volume manually

solution:
Introduce 'dynamic-auth' option (default: on).
If 'dynamic-auth' is 'on' gluster will perform dynamic authentication to
allow/terminate client transport connection immediately in response to
*.allow | *.reject volume set options, thus if volume permissions have changed
for a particular client (say client is added to auth.reject list), his
transport connection to gluster volume will be terminated immediately.

Backport of:
> Change-Id: I6243a6db41bf1e0babbf050a8e4f8620732e00d8
> BUG: 1245380
> Signed-off-by: Prasanna Kumar Kalever 
> Reviewed-on: http://review.gluster.org/12229
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 
> (cherry picked from commit 84e90b756566bc211535a8627ed16d4231110ade)

Change-Id: If7e5c9be912412ea388391ef406ee2c8bedb26b8
BUG: 1271065 
Signed-off-by: Prasanna Kumar Kalever 
Reviewed-on: http://review.gluster.org/12343
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

protocol/server : porting missing gf_log's to gf_msg

2015-08-31T09:45:09+00:00

        Backport of http://review.gluster.org/#/c/11895/

Cherry-picked form commit a26dbb38acdb2ec5fe16068caee189709faae76e
> Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
> BUG: 1252808
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/11895
> Tested-by: NetBSD Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I8818931fafea3c013551a5de23a9f77c81164841
BUG: 1257193
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/12018
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G

rpc,server,glusterd: Init transport list for accepted transport

2015-07-26T17:36:39+00:00

GlusterD or a brick would crash when encrypted transport was enabled and
an unencrypted client tried to connect to them. The crash occured when
GlusterD/server tried to remove the transport from their xprt_list due
to a DISCONNECT event. But as the client transport's list head wasn't
inited, the process would crash when list_del was performed.

Initing the client transports list head during acceptence, prevents this
crash.

Also, an extra check has been added to the GlusterD and Server
notification handlers for client DISCONNECT events. The handlers will
now first check if the client transport is a member of any list.
GlusterD and Server DISCONNECT event handlers could be called without
the ACCEPT handler, which adds the transport to the list, being called.
This situation also occurs when an unencrypted client tries to establish
a connection with an encrypted server.

Change-Id: Icc24a08d60e978aaa1d3322e0cbed680dcbda2b4
BUG: 1246809
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/11692
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Raghavendra G 
(cherry picked from commit a909ccfa1b4cbf656c4608ef2124347851c492cb)
Reviewed-on: http://review.gluster.org/11762

protocol/server: Correctly reconfigure auth.ssl-allow

2015-07-06T07:14:22+00:00

  Backport of https://review.gluster.org/11487

auth.ssl-allow wasn't being handled during reconfigure. This prevented
the ssl-allow list from being live reloaded.

Change-Id: If3435793a5684881b012de77cb254b1847b37810
BUG: 1238073
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/11492
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G

protocol/server: fail setvolume if any of xlators is not initialized yet

2015-07-02T11:14:09+00:00

We can only start recieving fops only when all xlators in graph are
initialized.

Change-Id: Id79100bab5878bb2518ed133c1118554fbb35229
BUG: 1214169
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/11504
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System

protocol/server: Include a check to validate xprt->client

2015-06-27T09:55:19+00:00

rpc_transport entries(xprt) are added to the conf->xprt_list
during client connection with the server. But the client object is created
and assigned to that transport object only during GF_HANDSK_SETVOLUME. Hence
till that period, there could be xprt entries in the xprt_list without client
associated with it. Added a check to validate the client object during upcall
notify.

This is a backport of the below fix -
http://review.gluster.org/#/c/11411/

BUG: 1236274

Change-Id: I00b9a140d6ee76e44c49146e90c20b3a87dc2de8
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/11411
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/11441
Tested-by: NetBSD Build System

protocol/server : port log messages to a new framework

2015-06-15T05:25:00+00:00

        Backport of http://review.gluster.org/#/c/9874/

Cherry picked from dc089a1a51988c2b407040e1684d7b0adbd79556
> Change-Id: I7901f55d06716161cc31d2b79a600a16b5ec2ef8
> BUG: 1194640
> Signed-off-by: Manikandan Selvaganesh 
> Reviewed-on: http://review.gluster.org/9874
> Tested-by: Gluster Build System 
> Reviewed-by: Raghavendra G 

Change-Id: I7901f55d06716161cc31d2b79a600a16b5ec2ef8
BUG: 1217722
Signed-off-by: Manikandan Selvaganesh 
Reviewed-on: http://review.gluster.org/10552
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G