Bug 1228696

Summary:	geo-rep: gverify.sh throws error if slave_host entry is not added to know_hosts file
Product:	[Community] GlusterFS	Reporter:	M S Vishwanath Bhat <vbhat>
Component:	geo-replication	Assignee:	Matt Zywusko <mzywusko>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	mainline	CC:	avishwan, bugs, gluster-bugs, mzywusko
Target Milestone:	---	Keywords:	Reopened, Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.8rc2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1231678 (view as bug list)		Environment:
Last Closed:	2016-06-16 13:08:45 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:	1231678

Description M S Vishwanath Bhat 2015-06-05 13:07:34 UTC

Description of problem:
geo-rep requires passwordless ssh to be setup between geo-rep master to geo-rep slave. But even if password less ssh is setup but the slave file entry is not entered in the ~/.ssh/known_hosts file, gverify.sh throws error saying "passwordless ssh is not setup"


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

How reproducible:
Always

Steps to Reproduce:
1. Create a passwordless ssh between master and slave nodes, but do not have the entry in ~/.ssh/known_hosts file.
2. Run geo-rep create command.

Actual results:
geo-rep create fails with passwordless ssh not setup.

Expected results:
geo-rep create should succeed

Additional info:

Comment 1 Anand Avati 2015-06-09 10:25:36 UTC

REVIEW: http://review.gluster.org/11106 (gverify: Adding StrictHostKeyChecking=no for ssh verification) posted (#2) for review on master by M S Vishwanath Bhat (msvbhat)

Comment 2 Niels de Vos 2015-06-09 12:19:02 UTC

Please clone this bug for mainline, and update http://review.gluster.org/11106 to use the cloned bug.

The new clone should be added to the "depends on" field of this bug.

Once the patch has been merged in the master branch, you can send a backport to release-3.7:

  http://gluster.readthedocs.org/en/latest/Developer-guide/Backport%20Guidelines/

Comment 3 M S Vishwanath Bhat 2015-06-10 20:23:44 UTC

(In reply to Niels de Vos from comment #2)
> Please clone this bug for mainline, and update
> http://review.gluster.org/11106 to use the cloned bug.

Agh, I made a mistake while raising the bug I think. Can I just change the version to mainline instead?

I actually sent patch from master branch.

Does that work? I can clone to release-3.7 branch while cherry-pick'ing the patch.

> 
> The new clone should be added to the "depends on" field of this bug.
> 
> Once the patch has been merged in the master branch, you can send a backport
> to release-3.7:
> 
>  
> http://gluster.readthedocs.org/en/latest/Developer-guide/
> Backport%20Guidelines/

Comment 4 Nagaprasad Sathyanarayana 2015-10-25 15:18:34 UTC

Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.

Comment 7 Niels de Vos 2016-06-16 13:08:45 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report.

glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user