<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 8/30/24 04:17, Strahil Nikolov
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1254456708.942559.1725005867722@mail.yahoo.com">
      <div dir="ltr" data-setdir="false">
        <div dir="ltr" data-setdir="false">Have you done the following
          setup on the receiving gluster volume:<br>
        </div>
      </div>
    </blockquote>
    <br>
    <font face="FreeSerif">Yes. For completeness' sake:</font><br>
    <font face="monospace">grep geoacct /etc/passwd /etc/group<br>
      /etc/passwd:geoacct:x:5273:5273:gluster
      geo-replication:/var/lib/glusterd/geoacct:/bin/bash<br>
      /etc/group:geoacct:x:5273:</font><br>
    <font face="monospace"><br>
      gluster-mountbroker status<br>
+-----------+-------------+---------------------------+-------------+----------------+<br>
      |    NODE   | NODE STATUS |         MOUNT ROOT        |   
      GROUP    |     USERS      |<br>
+-----------+-------------+---------------------------+-------------+----------------+<br>
      |    pms    |          UP | /var/mountbroker-root(OK) |
      geoacct(OK) | geoacct(j, n)  |<br>
      | localhost |          UP | /var/mountbroker-root(OK) |
      geoacct(OK) | geoacct(n, j)  |<br>
+-----------+-------------+---------------------------+-------------+----------------+</font><br>
    <font face="FreeSerif"><br>
      restarted glusterd<br>
      ssh-keyed, no-password access established.<br>
    </font><font face="monospace">gluster system:: execute gsec_create</font><font
      face="FreeSerif"><br>
      reports success, and
      /var/lib/glusterd/geo-replication/common_secret.pem.pub exists on
      both systems, containing 4 lines.<br>
      created geo-rep session, and configured ssh-port, as before,
      successful.<br>
      Issued start command. Status report still says </font><font
      face="monospace">Created</font><font face="FreeSerif">.<br>
      <br>
    </font><font face="monospace">PRIMARY NODE    PRIMARY VOL    PRIMARY
      BRICK    SECONDARY USER    SECONDARY         SECONDARY NODE   
      STATUS     CRAWL STATUS    LAST_SYNCED          <br>
-------------------------------------------------------------------------------------------------------------------------------------------<br>
      pjs           j              /xx/brick/j      geoacct          
      geoacct@pms::n    N/A               Created    N/A             N/A</font><br>
    <br>
    <blockquote type="cite"
      cite="mid:1254456708.942559.1725005867722@mail.yahoo.com">
      <div dir="ltr" data-setdir="false">
        <div dir="ltr" data-setdir="false">Also, I think the source node
          must be able to reach the gluster slave. Try to mount the
          slave vol on the master via the fuse client in order to verify
          the status.</div>
      </div>
    </blockquote>
    <font face="FreeSerif"><br>
      Each has mounted the other's volume. A single file,
      /gluster/j/stuff, is seen by both and is not replicated into
      /gluster/n.<br>
      <br>
    </font>
    <blockquote type="cite"
      cite="mid:1254456708.942559.1725005867722@mail.yahoo.com">
      <div dir="ltr" data-setdir="false">
        <div>Also, check with the following command (found it in <a
            href="https://access.redhat.com/solutions/2616791"
            rel="nofollow" target="_blank" class=""
            moz-do-not-send="true">https://access.redhat.com/solutions/2616791
            )</a>:</div>
        <span>
          <pre><code>sh -x /usr/libexec/glusterfs/gverify.sh masterVol slaveUser slaveHost slaveVol sshPort logFileName</code></pre>
        </span></div>
    </blockquote>
    <font face="FreeSerif"><br>
      That must be the wrong URL, "libexec" doesn't appear there.<br>
      However, running it with locally-appropriate args:<br>
    </font><font face="monospace">/usr/libexec/glusterfs/gverify.sh j
      geoacct pms n 6427 /tmp/verify.log</font><font face="FreeSerif"><br>
      ...generates a great deal of regular logging output, logs nothing
      in /tmp/verify.log, but the shell execution trace made this
      complaint:<br>
    </font><font face="monospace">shell-init: error retrieving current
      directory: getcwd: cannot access parent directories: No such file
      or directory</font><font face="FreeSerif"><br>
      So I went looking for directories that might be restricted (it
      didn't tell me which one it didn't like), thus:<br>
    </font><font face="monospace">ls -ld / /gluster /gluster/? /xx
      /xx/brick /xx/brick/j<br>
      find /var/lib/glu* -type d | xargs ls -ld</font><font
      face="FreeSerif"><br>
      The only directory, on both systems, that was at all restricted
      was /var/lib/glusterd/geo-replication, so...<br>
    </font><font face="monospace">chmod ugo+rx
      /var/lib/glusterd/geo-replication</font><font face="FreeSerif"><br>
      ...to take care of that. Again, attempted start, to no effect, the
      session remains in Created state.<br>
      <br>
      I wish there was a single, exhaustive description of "problems
      causing georep not to initiate."<br>
      The fact that it reports apparent success without moving forward
      to Active state is odd, and maddening.<br>
      What event or state is which part of the process waiting for?
      Having started (in principle), what is evaluating conditions for
      moving to Active?</font><br>
  </body>
</html>