Bug 1279628
| Summary: | [GSS]-gluster v heal volname info does not work with enabled ssl/tls | |||
|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Harold Miller <hamiller> | |
| Component: | replicate | Assignee: | Ashish Pandey <aspandey> | |
| Status: | CLOSED ERRATA | QA Contact: | Nag Pavan Chilakam <nchilaka> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | rhgs-3.1 | CC: | aspandey, asrivast, biryulini, bkunal, ccalhoun, john, nchilaka, olim, pkarampu, ravishankar, rhinduja, rhs-bugs, sankarshan, smohan, storage-qa-internal | |
| Target Milestone: | --- | Keywords: | Triaged, ZStream | |
| Target Release: | RHGS 3.1.3 | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | glusterfs-3.7.9-2 | Doc Type: | Bug Fix | |
| Doc Text: |
When management encryption via SSL is enabled, glusterd only allows encrypted connections on port 24007. However, the self heal daemon did not use an encrypted connection when attempting to fetch its volfile. This meant that when management encryption was enabled, running the "gluster volume heal info" command resulted in error messages, and users could not see the list of files that needed to be healed. The self heal daemon now communicates correctly over an encrypted connection and "gluster volume heal info" works as expected.
|
Story Points: | --- | |
| Clone Of: | 1258931 | |||
| : | 1320388 (view as bug list) | Environment: | ||
| Last Closed: | 2016-06-23 04:56:32 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: | 1258931 | |||
| Bug Blocks: | 1299183, 1320388, 1321514, 1369170 | |||
|
Description
Harold Miller
2015-11-09 21:43:26 UTC
Can I get an update regarding this BZ to provide to my customer? Hi Pranith, From the customer: >Yes, basically I expect a fix as soon as it is possible. Release dates are >too far. We also have to plan any updates especially because they have an >impact on our customers' application. >Off course, the fix must be reliable, we only have prod environment, we >cannot play with them. So yes, if we can provide one that will fit the customer's requirements, a HOTFIX would be great. Cal Hello Ashish, I've queried the customer to confirm the version they're running in their prod environment. Can you confirm that this fix has been tested? The customer has expressed concerns because they have no environment to test in prior to applying it. Regards, Cal RHGS 3.1.2 rpm glusterfs-server-3.7.5-19.el7rhgs.x86_64 Customer has already applied a HOTFIX from BZ 1310740. If a HOTFIX results from this BZ, will they be cumulative? I am sorry, I don't understand your comment Cal. There is only one bugfix is needed to fix this bug, is that what you are asking. My apologies. One of my customers, on SF case 01587696, is interested in a hotfix when this BZ has been through QE. They have previously applied a hotfix from BZ 1310740 and would like to know if a hotfix resulting from this BZ would be safe to apply on top of the previous one. Yes, please go ahead. If you face any problem in applying let us know, but I don't think there should be any problem. QATP and the results: =================== BUG#1279628 - [GSS]-gluster v heal volname info does not work with enabled ssl/tls Description of Problem: When have enabled ssl/tls command "gluster v heal <VOLUME> info" return "VOLNAME: Not able to fetch volfile from glusterd Volume heal failed." Patch Info:http://review.gluster.org/#/c/13815/ glfs/heal: Use encrypted connection in shd When management encryption is enabled, GlusterD only allows encrypted connections for port 24007. SHD is trying to fetch it's volfile using an unencrypted connection. If /var/lib/glusterd/secure-access is present , i.e. if management ssl is enabled, use encrypted connection fecth info from glusterd. QATP: TC#1:for a New volume gluster v heal info should display the right information when ssl is enabled (both mngt and data traffic) -->PASS 1. Create a cluster and identify client(s) 2. Now enable SSL for both mngt and data traffic using steps mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Network_Encryption.html 3. Now create a dist-rep volume 4. Now issue heal info on that volume Heal info must give the right information and not throw "unable to fetch volfile" error TC#2:for an Existing volume gluster v heal info should display the right information when ssl is enabled (both mngt and data traffic) -->PASS 1. Create a cluster and identify client(s) 2. Create a distrep volume and populate some data 3. Now enable SSL for both mngt and data traffic using steps mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Network_Encryption.html 4. Now issue heal info on that volume Heal info must give the right information and not throw "unable to fetch volfile" error TC#3:for a New volume gluster v heal info should display the right information when only mngt layer (glusterd) ssl is enabled -->PASS 1. Create a cluster and identify client(s) 2. Now enable SSL for only mngt using steps mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Network_Encryption.html 3. Now create a dist-rep volume 4. Now issue heal info on that volume Heal info must give the right information and not throw "unable to fetch volfile" error TC#4:for an existing volume gluster v heal info should display the right information when only mngt layer (glusterd) ssl is enabled -->PASS 1. Create a cluster and identify client(s) 2. Now create a dist-rep volume 3. Now enable SSL for only mngt using steps mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Network_Encryption.html 4. Now issue heal info on that volume Heal info must give the right information and not throw "unable to fetch volfile" error TC#5: While IOs are going on gluster v heal info should display the right information when SSL is enabled (both mngt and data) -->FAIL 1. Create a cluster and identify client(s) 2. Now create a dist-rep volume 3. Now enable SSL for only mngt using steps mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Network_Encryption.html 4. Now mount the volume on fuse on multiple clients 5. Now trigger IOs using dd or anyother method IOs must not hang However IOs and heal info hangs and a bug has been raised already 1337863 - [SSL] : I/O hangs when run from multiple clients on an SSL enabled volume 6. Now also issue heal info on that volume Heal info must give the right information and not throw "unable to fetch volfile" error However IOs and heal info hangs and a bug has been raised already 1337863 - [SSL] : I/O hangs when run from multiple clients on an SSL enabled volume Note: Also I had set gluster volume set <volname> locking-scheme granular" while the IOs were going on so as to avoid false positives as mentioned in BUG#1311839 - False positives in heal info Test version: ============ root@dhcp35-191 ~]# rpm -qa|grep gluster glusterfs-cli-3.7.9-6.el7rhgs.x86_64 glusterfs-libs-3.7.9-6.el7rhgs.x86_64 glusterfs-fuse-3.7.9-6.el7rhgs.x86_64 glusterfs-client-xlators-3.7.9-6.el7rhgs.x86_64 glusterfs-server-3.7.9-6.el7rhgs.x86_64 python-gluster-3.7.9-5.el7rhgs.noarch glusterfs-3.7.9-6.el7rhgs.x86_64 glusterfs-api-3.7.9-6.el7rhgs.x86_64 Hi Laura, Text is not exactly giving the correct picture about the issue we faced. It was self heal daemon which was not using ssl connection to communicate with glusterd. Modified text is - ------------------ When management encryption is enabled, Glusterd only allows encrypted connections on port 24007. Self Heal Daemon is trying to fetch it's volfile using an unencrypted connection. This meant that when management SSL was enabled, running the "gluster volume heal info" command resulted in error messages, and users could not see the list of files that needed to be healed. Self Heal Daemon now communicates correctly over an encrypted connection and "gluster volume heal info" works as expected. ------------------ Laura, Description provided by you in comment #21 looks perfect to me. I don't have any more comment on that. 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-2016:1240 |