List of hooks?

Grimson

For example /etc/rc.gateway_alarm gets triggered when a gateway changes state (up/packetloss/latency/down) and is an OK place to add extra actions that you want to happen for those things, like sending additional alerts or killing states.

Not really, because the content of /etc/ gets overwritten when pfSense updates. So officially documenting it will likely cause an additional flood of complaints on every pfSense update. The only thing supported is: https://www.netgate.com/docs/pfsense/development/executing-commands-at-boot-time.html#shell-script-option

luckman212

I agree, modifying the /etc/rc.* files directly is not durable. It would be better if the rc* files tested for the existence of a user-defined script named /etc/{scriptname}_custom and executed that if it exists. This would be safer, and survive upgrades.

E.g. in the case of rc.gateway_alarm (at the end) instead of:

exit $?

It could be:

[ -x /etc/rc.gateway_alarm_custom ] && /etc/rc.gateway_alarm_custom 
exit $?

And then users could create /etc/rc.gateway_alarm_custom if they need to do any custom work there:

#!/bin/sh
logger -t rc.hook "doing extra stuff..."
[...stuff...]
echo '<?php include("notices.inc"); $msg = "stuff has completed"; notify_via_smtp($msg);?>' | php -q

jazzl0ver

Hi,

Just wanted to describe a use case where this might be an extremely useful.

We have 3 ISPs connected to pfSense (two of them actually for HA), each of them provides us 2 subnets (one for failover support and another one for our services). While DynDNS service perfectly changes pfSense's public IP when a gateway triggers its state, the other services (that hosted behind pfSense) can't change their public IP addresses allocated from the 2nd subnets.

It would be really useful to set up a hook on a gateway state change that would run a custom script with all required actions to update other services DNS records.

One thing that I'd probably change from the @luckman212 suggestion is to look for a custom script in a directory that won't be overwritten upon pfSense update, for example /usr/local/etc/rc.d/rc.gateway_alarm_custom.

Please, implement this in the next pfSense release!

jazzl0ver

After some researching I've found that there's a special plugin hook - plugin_gateway. So, here is the package which implements /usr/local/etc/rc.d/rc.gateway_alarm_custom start up upon a gateway up/down event - https://github.com/jazzl0ver/pfSense-pkg-gatewayhook

cosmor

@jazzl0ver
It's great that you discovered the script. However , could you describe according to your previous post what specific actions ( (for common use cases of multi-wan setups ) are needed after the hook, when a gateway is down and another one is selected from the group as default? Would you like to see specific dns servers declared (on general setup) to use a specific gateway change automatically to the new selected gateway? Update local dns service pointing to services to a dmz ? Also, according to your post, please state why a change is needed for dns in relation with the setup, configuration and limitations of dns service you have setup locally.

Thanks.

jazzl0ver

@cosmor, we host public DNS zones on a separate server (bind9), so when the ISP channel gets switched to another one on pfSense, we need something to reach that server out and somehow update the zones (by nsupdate if the zones are dynamic or a custom script otherwise).

In our case we use a custom script, which is triggered by ssh login called from rc.gateway_alarm_custom. The script discovers the current channel, substitutes predefined zone template for a zone, increases the zone serial and reloads the zone.

Let me know if you need more details on that.

lucifer1413

This post is deleted!

martintamare

@jazzl0ver thanks for sharing this !
We are going to use SIP to target and kill state for specific devices that don't like public IP changes (SIP Phones).

jazzl0ver

@Moderador-PfSense what are the steps to include my package to the "Available packages" list in the GUI?

Gertjan

@jazzl0ver You mean : what to so the package that you build yourself shows up in that list ?

First step : before writing a package, you should be able to read a package => packages code written by others.
This will learn you everything.
Install 'simple' packages like "Notes", "Cron", "Patches", etc.
Now, check here /usr/local/pkg/, read ALL the files. You will get the idea.

You also need to know how the FreeBSD program pkg works. Where it gets it 'packages from', how a package is assembled.

Btw : If you want to make a (your) package is part of the official pfSense package list, you should hos it on github. And wait before the Netgate pfSense team contact you when they decide to do so. This can take a very long time. Ask @BBcan177 - he knows what it takes ;)

jazzl0ver

@gertjan said in List of hooks?:

If you want to make a (your) package is part of the official pfSense package list,

Yeah, that's what I meant. My package is hosted on github (https://github.com/jazzl0ver/pfSense-pkg-gatewayhook).

This can take a very long time

Alright.. :( Thanks for the reply!

JeGr

@jazzl0ver said in List of hooks?:

@Moderador-PfSense what are the steps to include my package to the "Available packages" list in the GUI?

Just to follow up (no Netgate staff myself!), this user is NO Moderator of pfSense or related to Netgate at all. You should rather include @jimp or other Netgate folks in your shoutout :)

jazzl0ver

@jimp could you please advise?

Gertjan

Yeah, let that be clear : I'm just a pfSense consumer.

@jazzl0ver said in List of hooks?:

@jimp could you please advise?

As @JeGr said : forum user taht work for Netgate, click on this @jimp and you'll see

so you know he's from Netgate.

He is also the author of many Netgate / pfSense videos.
https://www.youtube.com/c/NetgateOfficial/videos

jimp

As a general rule do not tag specific people unless they asked to be notified. No matter their role.

JeGr

@jimp said in List of hooks?:

As a general rule do not tag specific people unless they asked to be notified. No matter their role.

My bad, sorry.

Gertjan

Same here.