Bug 798169 - Volume set "auth.allow/auth.reject" should re initiate the client connection
Summary: Volume set "auth.allow/auth.reject" should re initiate the client connection
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: cli
Version: mainline
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Rajesh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-28 08:34 UTC by Shwetha Panduranga
Modified: 2013-07-04 22:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-15 10:40:03 UTC
Regression: ---
Mount Type: ---
Documentation: DP
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Shwetha Panduranga 2012-02-28 08:34:11 UTC
Description of problem:
create a volume with auth.allow set to <ip_address/subnet> of client nodes. Perform I/O operations from the mounts on client nodes. set auth.reject <ip_address/subnet> for same client nodes. 

Since the client has mounted to volume before the auth.reject option is set, client nodes are still able to access data and perform operations on data from the mount points. 
  
Ideally, the auth.reject or auth.allow volume set operations should re establish the client connections.

Comment 1 Rajesh 2012-03-15 10:40:03 UTC
This is the expected behavior. Antecedent connections should not be reset.

Comment 2 Shwetha Panduranga 2012-04-09 15:57:27 UTC
This bug has to be documented.


Note You need to log in before you can comment on or make changes to this bug.