Re: [Gluster-users] geo-replication {error=12} on one primary node

2024-02-15 Thread Stefan Kania 

Hi,

I,m still testing and I found that I can force the error by changing the 
shell from the unprivileged user, on the secondary node, from bash to 
sh. In the  first try I used "useradd -G geogruppe -m geobenutzer" so my 
user gets /bin/sh (the dash) as default shell. Then the error occurs. 
Then I switch the user to /bin/bash and the error is gone. After the 
test with the default shell I removed rsync to look for the error. So 
now I tested with /bin/bash as default shell but without rsync is 
installed. And I got:

---
2024-02-15 08:23:23.88036] E [syncdutils(worker 
/gluster/brick):363:log_raise_exception] : FAIL:

Traceback (most recent call last):
  File "/usr/libexec/glusterfs/python/syncdaemon/syncdutils.py", line 
393, in twrap

tf(*aargs)
  File "/usr/libexec/glusterfs/python/syncdaemon/primary.py", line 
2008, in syncjob

po = self.sync_engine(pb, self.log_err)
 ^^
  File "/usr/libexec/glusterfs/python/syncdaemon/resource.py", line 
1448, in rsync

get_rsync_version(gconf.get("rsync-command")) >= "3.1.0":
^
  File "/usr/libexec/glusterfs/python/syncdaemon/syncdutils.py", line 
682, in get_rsync_version

p = subprocess.Popen([rsync_cmd, "--version"],
^^
  File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'rsync'

---
as expected. Reinstalling rsync and everything is fine again :-). So the 
{error=12} came from /bin/sh as default shell. The missing rsync was not 
shown because geo-replication changed to faulty before rsync was used.


Stefan


Am 14.02.24 um 13:34 schrieb Stefan Kania:

Hi Anant,

shame on me ^.^. I forgot to install rsync on that host. Switching to 
log-level DEBUG helped me to find the problem. Without log-level DEBUG 
the host is not showing the missing rsync. Maybe that could be changed. 
So thank you for the hint.


Stefan

Am 13.02.24 um 20:32 schrieb Anant Saraswat:
gluster volume geo-replication 
privol01geobenutzer@s01.gluster::secvol01  config log-level DEBUG​









Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users




smime.p7s
Description: Kryptografische S/MIME-Signatur




Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] geo-replication {error=12} on one primary node

2024-02-14 Thread Stefan Kania 

Hi Anant,

shame on me ^.^. I forgot to install rsync on that host. Switching to 
log-level DEBUG helped me to find the problem. Without log-level DEBUG 
the host is not showing the missing rsync. Maybe that could be changed. 
So thank you for the hint.


Stefan

Am 13.02.24 um 20:32 schrieb Anant Saraswat:

gluster volume geo-replication privol01geobenutzer@s01.gluster::secvol01  
config log-level DEBUG​






smime.p7s
Description: Kryptografische S/MIME-Signatur




Community Meeting Calendar:

Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] geo-replication {error=12} on one primary node

2024-02-13 Thread Anant Saraswat 
Hi @Stefan Kania,

Please try to enable the geo-replication debug logs using the following command 
on the primary server, and recheck or resend the logs.

gluster volume geo-replication privol01 geobenutzer@s01.gluster::secvol01 
config log-level DEBUG​

Thanks,
Anant


From: Gluster-users  on behalf of Stefan 
Kania 
Sent: 13 February 2024 7:11 PM
To: gluster-users@gluster.org 
Subject: [Gluster-users] geo-replication {error=12} on one primary node

EXTERNAL: Do not click links or open attachments if you do not recognize the 
sender.

Hi to all,

Yes, I saw that there is a thread about geo-replication with nearly the
same problem, I read it, but I think my problem is a bit different.

I created two volumes the primary volume "privol01" and the secondary
volume "secvol01". All hosts are having the same packages installed, all
hosts are debian12 with gluster version 10.05. So  even rsync is the
same on any of the hosts. (I installed one host (vm) and clone it).
I have:
  Volume Name: privol01
Type: Replicate
Volume ID: 93ace064-2862-41fe-9606-af5a4af9f5ab
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: p01:/gluster/brick
Brick2: p02:/gluster/brick
Brick3: p03:/gluster/brick

and:

Volume Name: secvol01
Type: Replicate
Volume ID: 4ebb7768-51da-446c-a301-dc3ea49a9ba2
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: s01:/gluster/brick
Brick2: s02:/gluster/brick
Brick3: s03:/gluster/brick

resolving the names of the hosts is working in any direction

that's what I did:
on all secondary hosts:

groupadd geogruppe
useradd -G geogruppe -m geobenutzer
passwd geobenutzer
ln -s /usr/sbin/gluster /usr/bin

on one of the secondary hosts:
gluster-mountbroker setup /var/mountbroker geogruppe

gluster-mountbroker add secvol01 geobenutzer

on one of the primary hosts:
ssh-keygen

ssh-copy-id geobenutzer@s01.gluster

gluster-georep-sshkey generate

gluster v geo-replication privol01 geobenutzer@s01.gluster::secvol01
create push-pem


on one of the secondary hosts:
/usr/libexec/glusterfs/set_geo_rep_pem_keys.sh

All the commands exited with out an error message.

Restarted glusterd on all nodes

then on the primary host:
gluster volume geo-replication privol01
geobenutzer@s01.gluster::secvol01 start

The status is showing:

PRIMARY NODEPRIMARY VOLPRIMARY BRICK SECONDARY USER
SECONDARYSECONDARY NODESTATUS CRAWL
STATUSLAST_SYNCED
---
p03 privol01   /gluster/brickgeobenutzer
geobenutzer@s01.gluster::secvol01  PassiveN/A
  N/A
p02 privol01   /gluster/brickgeobenutzer
geobenutzer@s01.gluster::secvol01  PassiveN/A
  N/A
p01 privol01   /gluster/brickgeobenutzer
geobenutzer@s01.gluster::secvol01N/A   Faulty N/A
  N/A

For p01 the status is changing from "Initializing... to" "status=Active
status=History Crawl" to status=Faulty and then back to Initializing

But only for the primary host p01.

Here is the lock from p01:

[2024-02-13 18:30:06.64585] I
[gsyncdstatus(monitor):247:set_worker_status] GeorepStatus: Worker
Status Change [{status=Initializing...}]
[2024-02-13 18:30:06.65004] I [monitor(monitor):158:monitor] Monitor:
starting gsyncd worker [{brick=/gluster/brick}, {secondary_node=s01}]
[2024-02-13 18:30:06.147194] I [resource(worker
/gluster/brick):1387:connect_remote] SSH: Initializing SSH connection
between primary and secondary...
[2024-02-13 18:30:07.85] I [resource(worker
/gluster/brick):1435:connect_remote] SSH: SSH connection between primary
and secondary established. [{duration=1.6304}]
[2024-02-13 18:30:07.777971] I [resource(worker
/gluster/brick):1116:connect] GLUSTER: Mounting gluster volume locally...
[2024-02-13 18:30:08.822077] I [resource(worker
/gluster/brick):1138:connect] GLUSTER: Mounted gluster volume
[{duration=1.0438}]
[2024-02-13 18:30:08.823039] I [subcmds(worker
/gluster/brick):84:subcmd_worker] : Worker spawn successful.
Acknowledging back to monitor
[2024-02-13 18:30:10.861742] I [primary(worker
/gluster/brick):1661:register] _GPrimary: Working dir
[{path=/var/lib/misc/gluster/gsyncd/privol01_s01.gluster_secvol01/gluster-brick}]
[2024-02-13 18:30:10.864432] I [resource(worker
/gluster/brick):1291:service_loop] GLUSTER: Register time
[{time=1707849010}]
[2024-02-13 18:30:10.906805] I [gsyncdstatus(worker
/gluster/brick):280:set_active] GeorepStatus: Worker Status Change
[{status=Active}]
[2024-02-13 18:30:11.7656] I [gsyncdstatus(worker
/gluster/brick):252:set_worker_crawl_status] GeorepStatus: Crawl Status
Change [{status=History Crawl}]
[2024-02-13