Need help resurrecting an old HA kludge for DynDNS failover

actualrootwyrm

Because pfSense does not support 'follow-me' ARP spoofing, I have a scenario where the public IP on the HA members differs and will always differ. Because I use dynamic DNS for IPv6 tunneling, OpenVPN, and HAProxy, this is a big deal. I found a very old post from someone with a kludge to do the job.

https://forum.netgate.com/topic/64388/enable-dynamic-dns-when-failing-over-to-backup/2

The relevant code:

/* Start DynDNS for CARP nodes */
$config['dyndnses']['dyndns'][strval((int)(SUBSTR($argv[1],-1)-1))]['enable'] = true;
write_config();
shell_exec("/etc/rc.dyndns.update");

/* Stop DynDNS for CARP nodes */
$config['dyndnses']['dyndns'][strval((int)SUBSTR($argv[1],-1)-1))]['enable'] = false;
write_config();
shell_exec("/etc/rc.dyndns.update");

This code sort of works as-is on 2.4.3_1. (Frankly it's just embarrassing that pfSense still does not have this very simple functionality. And still won't in 2.4.4.) The problem is that on a failover action, it will always add a bunch of blank RFC2136 dynamic DNS configuration entries.
I am absolutely not a PHP guy, so I'm completely stumped as to why it's adding a pile of broken RFC2136 entries, much less in the clients tab instead of the 2136 tab. The plan is to integrate it as a custom patch. Any help getting this back into working shape would be greatly appreciated.

actualrootwyrm

Figured it out on my own, found some stupidity in how ['dyndnses'] is handled in PHP. In $config it's always NULL. Set one way or the other, NULL becomes false. (Really? That's as bad as rm -f /$EMPTYVAR) Required a from scratch approach, but it's most of the way to working.

What you ACTUALLY get from $config['dyndnses'], which doesn't match the XML or UI:

array (
  'dyndns' =>
  array (
    0 =>
    array (
      'type' => 'he-net',
      'username' => 'user',
      'password' => 'XXXXXX',
      'host' => 'test1.example.com',
      'domainname' => '',
      'mx' => '',
      'enable' => '',
      'interface' => 'wan',
      'zoneid' => '',
      'ttl' => '',
      'updateurl' => '',
      'resultmatch' => '',
      'requestif' => 'wan',
      'descr' => 'never-moves entry',
      'id' => '0',
    ),
    1 =>
    array (
      'type' => 'he-net-tunnelbroker',
      'username' => 'user',
      'password' => 'xxxxxx',
      'host' => '123456',
      'domainname' => '',
      'mx' => '',
      'enable' => '',
      'interface' => 'wan',
      'zoneid' => '',
      'ttl' => '',
      'updateurl' => '',
      'resultmatch' => '',
      'requestif' => 'wan',
      'descr' => 'tunnelXXX.tunnel.tserv4.nyc4.ipv6.he.net',
      'id' => '1',
    ),
  ),

Need to finish it up, but I will not be permitting inclusion or distribution by Netgate or pfSense. Not going to reward bad behavior.

webmst

@actualrootwyrm

Hi, I wrote that code some years ago, freely publishing a pfsense customisation I had made for a service provider who had hired me some time before.

As you repeat here, I was surprised in seeing that such a feature (i.e. dns update on a CARP failover) required an ad-hoc script, so reading that another user was looking for the same, I had made it available with some remarks, knowing that it could have been useful later.

Still, as many changes have been introduced in the following pfsense releases, to make that code working again you have (and you will always have, because being a custom patch it will require continuous check/maintenance at every pfsense update, unless it becomes a standard feature as you hope) to:

ensure php is still the current scripting language for pfsense
verify the current release php syntax for the functions required to manipulate strings (I had already slightly modified it for a next pfsense release)
verify the current config.xml structure for setting the configuration keys to enable/disable dynamic dns entries (check the similar code used for the GUI)
verify the current rc.carpmaster/rc.carpbackup (see parameters and structure)

I don't have time for committing into this now, but let me suggest you'll have just to insist with some tests (possibly displaying intermediate string manipulation results) to get to the desired behaviour.

Let me say that even if you defined it just a "kludge", I had always been proud of that smart and quick snippet of code, tailored to solve a specific issue.

As it is your effort to create and maintain it (I really doubt it can be raised to a feature being it so specific), it'll be up to you to decide whether to publish it or keep it for yourself.

Good luck.