reestablish relayd
-
Any new progress in this? Having a working published relayd package is still of interest.
-
I'll probably publish something on github in a while, with both the compiled package and the instructions on how to build it.
However I cannot force people to test it, so unless I have some feedback I doubt it will ever come back as an official pacakge.
-
@xeba
I appreciate your work on this, but I haven't been able to test the package yet.
We wrote a cron job to mimic the relayd functionality and are currently happy with that solution. -
@jackdig
Yes that is "my" problem as well, we use HAproxy for webserver and other type of solutions for pure tcp connections, so I cannot really do the testing myself. -
@xeba I'll test it! I have some lab environments. I've also been looking for a reason to break into some BSD dev. Do you have some samples of what a proper HAProxy config should look like for failover web clustering with port 80 redirecting to 443 on the backend with SSL?
-
@jackdig do you have some samples of this HA cron job?
-
@mike115 said in reestablish relayd:
@jackdig do you have some samples of this HA cron job?
I do, but this is not for the faint of heart :-)
Some background:
We are using a cron script for our production environment.
We have two pfSense firewalls in a HA setup (using CARP IPs) and we have two internal web servers serving different sites (both servers are active). When either internal web server fail, we want to redirect all traffic to the working web server.Some problems:
Up until pfSense 2.5 (I think), there was no way of controlling fw rules (aliases) using scripts. Then /usr/local/bin/aliasmod came along and allowed us to add/remove IPs to aliases. This was not perfect, so we modified aliasmod to a new script (aliastool) that allow us to read or change the IP of an alias.
We want the script to work when our primary pfSense fw (CARP master) is down, so we need to run the script on all (master and slave) pfSense servers. We added checks in our script so that nothing will be done if the current server is not CARP master.
Cron will only allow us to run a script every minute, but we want to monitor our web servers more often (every 5 sec). We wrote the cron script so that it will run for just under 1 minute and then exit. It will not start a second instance if it is already running, but it will kill an old running instance after some time. All this code is needed to ensure that the monitoring script will never (fully) fail.
This script is written entirely for our own need and use case. The code is not perfect and the functionality might not fit you. You are, however, free to use it or enhance it anyway you'd like.
I uploaded our script (and the php based aliasool) here:
https://github.com/jackfagner/pfsense-ha-using-cron -
@jackdig Thanks for posting and good work! Unfortunately my exposure to shell scripts is somewhat limited. I understand the format and functions well enough but my knowledge of grep, sed, and awk is severely underdeveloped (my professor would be disappointed
)...something I'm working on.Anyways, have you tried an interface trigger? It may be a little redundant. I like those in my C# programs because then I don't have to write conditional tests at the granular level, although checking the IP like you did is good too because the interface may not always be reported as down. I also imagine you could further simplify this by using the built in watchdog.
I still have a lot to learn. This is a little more adventurous than I feel like getting into this morning, but thanks again for posting. I'll save it for later exploration.
-
@mike115 said in reestablish relayd:
Anyways, have you tried an interface trigger? It may be a little redundant. I like those in my C# programs because then I don't have to write conditional tests at the granular level, although checking the IP like you did is good too because the interface may not always be reported as down. I also imagine you could further simplify this by using the built in watchdog.
I'm not sure if we are talking about the same thing here?
Interface triggers could possible be used on the FW to determine if/when the FW interface changes (for tracking the CARP IP, for example), but it can not be used to determine if a web server on the internal network is working properly. For that functionality we need to use ping och http requests.
The reason for not using interface triggers for CARP monitoring is mainly simplicity. I'm not sure if interface triggers will survive a pfSense version upgrade. -
This post is deleted!