One to one real time file sync and replication

How to troubleshoot Linux file replication connectivity issues

S. Dimitri Linux File Replication

Linux file replication and data replication on other platforms require execution of binaries, access to libraries, and connectivity. Several factors may impact access to the software and communication between the source and target of replication.

Visit https://www.enduradata.com/edpcloud-file-synchronization-and-file-replication-software-installation-and-configuration https://www.enduradata.com/linux-real-time-file-replication-and-synchronization-software   for more information about configuring EDpCloud.

The following are  pointers to address some of the issues system administrators may run into when they try to replicate data from a source to a replica target.

1. Connectivity between the source and the target

For successful communication in file replication, it’s essential that the source connects to the receiving side using a designated port. This ensures the data is transmitted without any issues.

1.1 First verify that you can ping the target

ping destination

1.2 Use Netcat (nc) to test access to the port:

  • Stop edpcloud (edpcloud.sh stopall) on the target
  • On the target : 

nc -lv 8888

  • On the source: 

nc -v 192.168.1.10 8888

If you cannot reach port 8888, you will need to check your firewall and make sure edpcloud is running (and see section 2 below).

2. Access and execution of the software

Under Linux, File Access Policy Daemon (fapolicyd) may prevent access to EnduraData EDpCloud and other software itself.

Check that fapolicyd is active:

systemctl status fapolicyd

if fapolicyd is active it may deny access. To fix this:

a. edit /etc/fapolicyd/fapolicyd.rules

b. add the following to /etc/fapolicyd/fapolicyd.rules

Assuming you installed EDpCloud under /usr/local/enduradata add this line.

   allow perm=any uid=0 : dir=/usr/local/enduradata

c. Restart fapolicyd using:

systemctl restart fapolicyd

3. Check name resolution and if NAT address is authorized  (see man eddist.cfg man page)

  1. if the target and the source cannot resolve host name of the source, you may test this by adding the hostname in /etc/hosts
  2. If the source uses NAT to communicate with the target. You will need to change eddist.cfg to allow NAT access. You can use aliases=”NAT_IP_ADDRESS”

example:

If host orion  connects through a NAT of 92.168.200.254 then add this NAT address using the alias keyword.

 

<link name=”o2uh8″ >

<sender hostname=”orion” alias=”192.168.200.254″ 

/>

 

The configuration above tells EDpCloud that in addition to orion’s hostname and IP address, his other alias (i.e a NAT address) is 192.168.200.254

(You will see that ed_receiver*log will have access denied to 192.168.200.254. Adding the alias above solves the issue.

 

4. SELinux may be restricting access to certain ports

 

4.1 Check SELinux status by running “sestatus

Example:

[root@uh8 ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 32

 

4.2 Use ” semanage port -l ” to check if EnduraData replication port 8888 is open:

[root@uh8 ~]# semanage port -l |grep 8888

http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 8888

matahari_port_t tcp 49000

matahari_port_t udp 49000

 

You can add a port as follows:

sudo semanage port -a -t http_port_t -p tcp 8888

 

For additional troubleshooting information:

  • Examine ed_receiver*log on the target to verify that replication connects to the target.
  • Examine eddist.log and ed_sender*log on the source

 

Related articles:

 

How to troubleshoot Linux file replication connectivity issues was last modified: June 14th, 2024 by S. Dimitri

Share this Post