Linux file replication and data replication software requires execution of binaries, access to libraries, and connectivity. Several factors may impact access to the replication software and communications between the source and target of replication. In this post we will cover:
- Connectivity between file replicas
- Operating system policies to access data replication binaries and libraries
- Access authorization to replicas
- Firewall restrictions of replication ports.
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)
- if the target and the source cannot resolve host name of the source, you may test this by adding the hostname in /etc/hosts
- 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:
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:
Share this Post