+++ This bug was initially created as a clone of Bug #1228696 +++ 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: --- Additional comment from Anand Avati on 2015-06-09 06:25:36 EDT --- 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) --- Additional comment from Niels de Vos on 2015-06-09 08:19:02 EDT --- 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/ --- Additional comment from M S Vishwanath Bhat on 2015-06-10 16:23:44 EDT --- (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/
REVIEW: http://review.gluster.org/11225 (gverify: Adding StrictHostKeyChecking=no for ssh verification) posted (#2) for review on release-3.7 by M S Vishwanath Bhat (msvbhat)
REVIEW: http://review.gluster.org/11225 (gverify: Adding StrictHostKeyChecking=no for ssh verification) posted (#3) for review on release-3.7 by M S Vishwanath Bhat (msvbhat)
REVIEW: http://review.gluster.org/11225 (gverify: Adding StrictHostKeyChecking=no for ssh verification) posted (#4) for review on release-3.7 by M S Vishwanath Bhat (msvbhat)
REVIEW: http://review.gluster.org/11225 (gverify: Adding StrictHostKeyChecking=no for ssh verification) posted (#6) for review on release-3.7 by Vijay Bellur (vbellur)
REVIEW: http://review.gluster.org/11225 (gverify: Adding StrictHostKeyChecking=no for ssh verification) posted (#7) for review on release-3.7 by M S Vishwanath Bhat (msvbhat)
COMMIT: http://review.gluster.org/11225 committed in release-3.7 by Venky Shankar (vshankar) ------ commit 5a8dd6f39ec6a536cf13b2758a754947ded16a23 Author: M S Vishwanath Bhat <vbhat> Date: Thu Jun 4 17:52:00 2015 +0530 gverify: Adding StrictHostKeyChecking=no for ssh verification Before actually checking the compatibility between master and slave, gverify checks if there is a passwordless ssh connection between master to slave. So if the entry of the slave was not present in 'known_hosts' file in master gverify used to complain that passwordless ssh has not been setup. This used to happen even if there is a passwordless ssh between master to slave. This patch fixes the above problem by using StrictHostKeyChecking=no while doing ssh to slave. Reviewed-on: http://review.gluster.org/11106 Change-Id: I01577ffa82a4504b4674fe26a5256ca890777557 BUG: 1231678 Signed-off-by: M S Vishwanath Bhat <vbhat> Reviewed-on: http://review.gluster.org/11225 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Aravinda VK <avishwan>
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.7.4, please open a new bug report. glusterfs-3.7.4 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://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12496 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user