geo-replication using ssh fails with the following error on master. [2012-05-09 08:48:24.21287] E [resource:166:errfail] Popen: command "ssh -oPasswordAuthentication=no -oStrictHostKeyChecking=no -i /var/lib/glusterd/geo-replication/secret.pem -oControlMaster=auto -S /tmp/gsyncd-aux-ssh-SI9luN/gsycnd-ssh-%r@%h:%p geoaccount@rhs20b2-02 /usr/local/libexec/glusterfs/gsyncd --session-owner a2565b7b-5beb-4df6-9002-7367dc27d976 -N --listen --timeout 120 gluster://localhost:vol01_slave" returned with 1, saying: It looks the the default location of gsyncd is hardcoded as "/usr/local/libexec/glusterfs/gsyncd". I confirmed that using the following soft-link could be a workaround. # ls -l /usr/local/libexec/glusterfs/gsyncd lrwxrwxrwx. 1 root root 29 5月 9 08:44 2012 /usr/local/libexec/glusterfs/gsyncd -> /usr/libexec/glusterfs/gsyncd My setup is RHS2.0Beta2. # rpm -qa | grep gluster gluster-swift-1.4.8-3.el6.noarch glusterfs-3.3.0qa38-1.el6.x86_64 glusterfs-fuse-3.3.0qa38-1.el6.x86_64 gluster-swift-container-1.4.8-3.el6.noarch glusterfs-server-3.3.0qa38-1.el6.x86_64 glusterfs-geo-replication-3.3.0qa38-1.el6.x86_64 gluster-swift-proxy-1.4.8-3.el6.noarch gluster-swift-account-1.4.8-3.el6.noarch gluster-swift-plugin-1.0-1.noarch glusterfs-rdma-3.3.0qa38-1.el6.x86_64 gluster-swift-object-1.4.8-3.el6.noarch
The location of the remote gsyncd is not hardcoded. Only its _default value_ is hardcoded. The real problem is that the way OP tries to use geo-rep is _deprecated_ (albeit he does not have a chance to get a clue, as documention does not tell about that). Solution is: set up geo-rep over ssh as described in Section 9.2.5.1 of the RHS docs, http://docs.redhat.com/docs/en-US/Red_Hat_Storage/2/html/User_Guide/chap-User_Guide-Geo_Rep-Preparation-Settingup_Slave.html *** This bug has been marked as a duplicate of bug 809724 ***
Which part of the RHS docs specifies the non-default location of gysncd? If you mean 'command="PREFIX/glusterfs/gsyncd" ssh-rsa AAAAB3Nza....' part of authorized_keys in slave, I exactily followed it and still have the same error. The following is the authorized_keys in my setup. # cat authorized_keys command="/usr/libexec/glusterfs/gsyncd" ssh-rsa AAAAB3NzaC1y...snip...AZiAi0HkwcFfSw== root@master01
Csaba, Ahhh, my apology. >If you mean 'command="PREFIX/glusterfs/gsyncd" ssh-rsa AAAAB3Nza....' part of >authorized_keys in slave, I exactily followed it and still have the same error. It's a mistake. By setting the above SSH restriction, geo-rep worked as intended without the sym-link. By the way, it looks a little bit tricky way to specify the location of gsyncd as it is redirected by ssh config, not a part of gluster config. Is there any other way to specify the location of gsyncd as a part of gluster config?
(In reply to comment #3) > By the way, it looks a little bit tricky way to specify the location of > gsyncd as it is redirected by ssh config, not a part of gluster config. Is > there any other way to specify the location of gsyncd as a part of gluster > config? Well, as long as we use ssh as the auth + wire encryption + transport mechanism, I doubt we had any other choice (and if, say, we were to support https as an alternative -- we would have to set up the config in the web server's scope, not in gluster's). Actually the description of the configuration is a bit overcomplicated at referred place. As far as RHS is concerned, the installation prefix is known, so all you have to do is to prepend the master's public key with command="/usr/libexec/glusterfs/gsyncd" (without further thinking or research; this is not a tunable so that its management should be under gluster namespace, it's a rigid instruction). Given that you do have to set up key based auth for geo-rep anyway, I don't feel this would hurt much. (I asked for the deprecation marker and making the above outlined simplification from docs folks -- just it haven't gone through yet.)