0

I have two Linux routers (RHEL 7) participating in a redundant VRRP configuration provided by the keepalived package version 2.0.20. These two routers used to be running RHEL 6 and keepalived version 2.0.16 but we recently upgraded them to the aforemented versions.

Before we upgraded I had a script that I could run on the backup router that would cause the router to take over as the master router. The script would glean the priority value of the current master router and then increment its own priority to be 1 higher and then restart the keepalived service. This would cause the backup router to take over as the master.

The script would glean the value of the current master router by issuing the following commands: 

kill -s $(keepalived --signum=DATA) $(cat /var/run/keepalived.pid)
vrrpPriority='more /tmp/keepalived.data | grep -m1 "Master priority" | awk '{print $4}''

Now that we've upgraded, it doesn't look like the first command does anything anymore. The command appears to execute without errors, but I never get a generated file in /tmp/keepalived.data. So the second command fails since that file doesn't exist.

Is there a better or different way of gleaning the priority value of the current master router?

Another difference is that when we were running in RHEL 6, keepalived was running as an upstart script whereas today keepalived is running as a systemd service. All other aspect of keepalived appear to be working correctly.

dutsnekcirf
  • 79
  • 1
  • 3
  • 14
  • I am using SNMP to get the priority : snmpget -c public 127.0.0.1 1.3.6.1.4.1.9586.100.5.2.3.1.7.1, but you need to configure SNMP server and keepalived to use it – Dom Mar 11 '20 at 20:16
  • I'm getting "SNMPv2-SMI::enterprises.9586.100.5.2.3.1.7.1 = No Such Object available on this agent at this OID" – dutsnekcirf Mar 11 '20 at 20:55
  • Just discovered something. When I run the "kill" command from above I noticed in the keepalived.service status that said, "Unable to open '/tmp/keepalived.data' - errno 13 (Permission denied). So this begs the question, why wouldn't the keepalived service be able to write to the /tmp directory? Could selinux be getting in my way? – dutsnekcirf Mar 11 '20 at 23:02
  • Just looked in /var/log/messages and found the following message, "setroubleshoot: SELinux is preventing /usr/sbin/keepalived from write access on the directory /tmp/keepalived.data" Does anyone know how to fix this? I'm not proficient with selinux at all. – dutsnekcirf Mar 11 '20 at 23:23

1 Answers1

0

I've been able to get this working. In the process of troubleshooting I discovered that selinux was preventing Keepalived from dumping its state to the /tmp directory. After working through the selinux issues and creating the needed selinux policy it started working as expected.

dutsnekcirf
  • 79
  • 1
  • 3
  • 14