Bug 1759810

Summary: [samba-gdeploy] "group samba" volume option needs to be implemented as a part of samba setup via "smb=yes"
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Vivek Das <vdas>
Component: gdeployAssignee: Sachidananda Urs <surs>
Status: CLOSED ERRATA QA Contact: Vivek Das <vdas>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rhgs-3.5CC: amukherj, rhs-bugs, storage-qa-internal, surs
Target Milestone: ---   
Target Release: RHGS 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gdeploy-2.0.2-35 Doc Type: Bug Fix
Doc Text:
The configuration options 'group=samba' and 'user.cifs=enable' are now set on the volume during Samba setup, ensuring setup is successful.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-30 12:19:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1696809    

Description Vivek Das 2019-10-09 07:45:10 UTC
Description of problem:

While setting up samba using gdeploy, it doesn't setup 'group samba' & enable user.cifs in regular volumes. As of now it is only setting up by default for a ctdb volume.

gdeploy has an option that takes care of complete samba setup over a volume i.e 'smb=yes' & 'action=smb-setup'. Ideally these options should take care of newly introduced mandatory volume options for samba. But this is not happening.

Version-Release number of selected component (if applicable):

gdeploy-2.0.2-34.el7rhgs.noarch
ansible-2.8.5-2.el7ae.noarch

How reproducible:
Always

Steps to Reproduce:
1.Use smb=yes for a new volume creation in conf file
2.Use action=smb-setup for an existing volume in conf file
3. Post successful run of gdeploy check gluster volume info

Actual results:
gluster volume set <volname> group samba and user.cifs is not enabled

Expected results:
gluster volume set <volname> group samba and user.cifs is not enabled

Additional info:

work around : 
Customer can add separate parameters to enable "group samba" & "user.cifs"

Comment 6 Sachidananda Urs 2019-10-14 06:39:31 UTC
Commit https://github.com/gluster/gdeploy/commit/392d9b992b03a fixes the issue.

Comment 8 Vivek Das 2019-10-14 09:14:35 UTC
Tested both the scenarios and the issue is fixed with "gdeploy-2.0.2-35"

[volume1]
action=smb-setup
volname=gdeploy-test2
#transport=tcp
#replica_count=2
force=yes


[volume1]
action=create
volname=gdeploy-test
transport=tcp
replica_count=2
force=yes
brick_dirs=10.70.43.185:/bricks/brick2/brick,10.70.43.189:/bricks/brick2/brick,10.70.43.181:/bricks/brick2/brick,10.70.43.178:/bricks/brick2/brick
smb=yes
smb_username=smbuser3
smb_password=foobar
smb_mountpoint=/mnt/smb


Volume Name: gdeploy-test2
Type: Distributed-Replicate
Volume ID: f11009a6-5bb7-4916-ab51-6930eca9a4b7
Status: Started
Snapshot Count: 0
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.70.43.185:/bricks/brick2/brick
Brick2: 10.70.43.189:/bricks/brick2/brick
Brick3: 10.70.43.181:/bricks/brick2/brick
Brick4: 10.70.43.178:/bricks/brick2/brick
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
server.allow-insecure: on
storage.batch-fsync-delay-usec: 0
features.cache-invalidation: on
features.cache-invalidation-timeout: 600
performance.cache-samba-metadata: on
performance.stat-prefetch: on
performance.cache-invalidation: on
performance.md-cache-timeout: 600
network.inode-lru-limit: 200000
performance.nl-cache: on
performance.nl-cache-timeout: 600
performance.readdir-ahead: on
performance.parallel-readdir: on
user.cifs: enable

Comment 12 errata-xmlrpc 2019-10-30 12:19:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3250