No, I still haven't heard anything from the community, and I just removed the ssh keys for the broken systems so they don't try to start up the "bad" replication configs (which is incredibly ugly). Someday soon I'm planning to build a test cluster to experiment on, though, and will follow up if I figure out a solution.<br><br>--Danny<br><br>Steve Dainard <sdainard@miovision.com> wrote:<br><br><div dir="ltr">Hi Danny,<div><br></div><div>Did you get anywhere with this geo-rep issue? I have a similar problem running on CentOS 6.5 when trying anything other than 'start' with geo-rep.</div><div><br></div><div>
Thanks,</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:16px"><strong>Steve </strong></span></div></div><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 9:45 AM, Danny Sauer <span dir="ltr"><<a href="mailto:danny@dannysauer.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=danny@dannysauer.com&cc=&bcc=&su=&body=','_blank');return false;">danny@dannysauer.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0B6CDA" text="#000000" vlink="#551A8B" alink="#EE0000" bgcolor="#ffffff">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
I have the current gluster 3.4 running on some RHEL6 systems. For
some reason, all of the geo-replication commands which change a
config file (start, stop, config) return failure. Despite this,
"start" actually starts it up. I'd be mostly ok with this if stop
also actually stopped it; but that does not happen. The "command
failed" behavior is consistent across all nodes. The binaries are
the result of downloading the source RPM and "rpm --rebuild"ing,
since the packages on the download server still don't install on
anything but the latest RHEL6 (that ssl library dependency thing); I
didn't change anything, just directly rebuilt from the source
package. I have working ssh between the systems, and files do
propagate over; I can see in the logs that ssh does connect and
start up the gsyncd. I just have several test configs that I'd like
to not have running now, but they won't stay dead. :)<br>
<br>
Is there a way to forcibly remove several geo-replication configs
outside of the shell tool? I tried editing the config file to
change the ssh command path for one of them, and my changes kept
getting overwritten by metadata from the other nodes (yes, time is
in sync on all nodes using ntp against the same server), so I'm
assuming that deleting the relevant block from the config file won't
do it?<br>
<br>
The really weird thing is that other volume management tasks work
fine; I can add/remove bricks from volumes, create, start and stop
regular volumes, etc. It's just the geo-replication management part
that fails.<br>
<br>
Thanks for any input you can provide. :) Some example output (with
username, IP, and hostnames changed to protect the innocent) is
below.<br>
<br>
- --Danny<br>
<br>
<br>
user@gluster1 [/home/user]<br>
$ sudo gluster v geo sec ssh://slave_73::geo_sec_73 stop<br>
<br>
geo-replication command failed<br>
user@gluster1 [/home/user]<br>
$ sudo gluster v geo sec ssh://slave_73::geo_sec_73 config<br>
gluster_log_file:
/var/log/glusterfs/geo-replication/sec/ssh%3A%2F%2Froot%401.2.3.4%3Agluster%3A%2F%2F127.0.0.1%3Ageo_sec_73.gluster.log<br>
ssh_command: ssh -oPasswordAuthentication=no
-oStrictHostKeyChecking=no -i
/var/lib/glusterd/geo-replication/secret.pem<br>
session_owner: ace6b109-ba88-4c2e-9381-f2fc31aa36b5<br>
remote_gsyncd: /usr/libexec/glusterfs/gsyncd<br>
socketdir: /var/run<br>
state_file:
/var/lib/glusterd/geo-replication/sec/ssh%3A%2F%2Froot%401.2.3.4%3Agluster%3A%2F%2F127.0.0.1%3Ageo_sec_73.status<br>
state_socket_unencoded:
/var/lib/glusterd/geo-replication/sec/ssh%3A%2F%2Froot%401.2.3.4%3Agluster%3A%2F%2F127.0.0.1%3Ageo_sec_73.socket<br>
gluster_command_dir: /usr/sbin/<br>
pid_file:
/var/lib/glusterd/geo-replication/sec/ssh%3A%2F%2Froot%401.2.3.4%3Agluster%3A%2F%2F127.0.0.1%3Ageo_sec_73.pid<br>
log_file:
/var/log/glusterfs/geo-replication/sec/ssh%3A%2F%2Froot%401.2.3.4%3Agluster%3A%2F%2F127.0.0.1%3Ageo_sec_73.log<br>
gluster_params: xlator-option=*-dht.assert-no-child-down=true<br>
user@gluster1 [/home/user]<br>
$ sudo gluster v geo sec ssh://slave_73::geo_sec_73 status<br>
NODE MASTER
SLAVE STATUS<br>
-
---------------------------------------------------------------------------------------------------<br>
gluster1 sec
ssh://slave_73::geo_sec_73 faulty<br>
user@gluster1 [/home/user]<br>
$ sudo gluster v geo sec ssh://slave_73::geo_sec_73 stop<br>
<br>
geo-replication command failed<br>
user@gluster1 [/home/user]<br>
$ sudo gluster v geo sec ssh://slave_73::geo_sec_73 status<br>
NODE MASTER
SLAVE STATUS<br>
-
---------------------------------------------------------------------------------------------------<br>
gluster1 sec
ssh://slave_73::geo_sec_73 faulty<br>
<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.14 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iEYEARECAAYFAlMMrHEACgkQvtwZjjd2PN8kpQCfVjtKeO7DCvhT9SpK+LEulZVZ<br>
c0wAn16xAT14V+oNOilbKwHDoM68EIbW<br>
=QfSZ<br>
-----END PGP SIGNATURE-----<br>
<br>
</div>
<br>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=Gluster-users@gluster.org&cc=&bcc=&su=&body=','_blank');return false;">Gluster-users@gluster.org</a><br>
<a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br></blockquote></div><br></div></div>