gdnsd-plugin-api(3) gdnsd gdnsd-plugin-api(3)NAMEgdnsd-plugin-api - How to write gdnsd plugin code
SYNOPSIS
Mandatory preamble macro+header your source must include at the top:
#define GDNSD_PLUGIN_NAME foo
#include <gdnsd/plugin.h>
Callback hooks you may implement (all are optional, and executed in this order):
-- startup/config stuff:
# only 'checkconf', 'start', 'restart', 'condrestart' invoke plugin callbacks at all
mon_list_t* plugin_foo_load_config(const vscf_data_t* pc)
void plugin_foo_add_svctype(const char* name, const vscf_data_t* svc_cfg, const unsigned interval, const unsigned timeout)
void plugin_foo_full_config(unsigned num_threads)
void plugin_foo_add_monitor(const char* svc_name, mon_smgr_t* smgr)
# only 'start', 'restart', and 'condrestart' continue past this point
void plugin_foo_post_daemonize(void)
void plugin_foo_pre_privdrop(void)
void plugin_foo_init_monitors(struct ev_loop* mon_loop)
void plugin_foo_start_monitors(struct ev_loop* mon_loop)
void plugin_foo_pre_run(struct ev_loop* loop)
void plugin_foo_iothread_init(unsigned threadnum)
-- runtime stuff (called from iothread context, anytime after iothread_init())
bool plugin_foo_resolve_dynaddr(unsigned threadnum, unsigned resnum, const client_info_t* cinfo, dynaddr_result_t* result)
void plugin_foo_resolve_dyncname(unsigned threadnum, unsigned resnum, const uint8_t* origin, const client_info_t* cinfo, dyncname_result_t* result)
-- runtime stuff (called from main or zonefile thread, anytime after full_config())
-- (you won't get parallel calls to these, and in general they should be readonly
-- operations anyways)
int plugin_foo_map_resource_dyna(const char* resname)
int plugin_foo_map_resource_dync(const char* resname, const uint8_t* origin)
-- cleanup stuff:
void plugin_foo_exit(void)WARNING
Please note that in general, gdnsd's plugin API is poorly documented
and unstable. It often goes through fairly large and abrupt changes
during development cycles, although it tends to be stable for a given
stable release series. Write code against it at your own peril (or at
least, let me know so I can give you some warning on upcoming changes
and/or solicit your feedback!).
OVERVIEW
This file documents version 12 of the gdnsd plugin API.
gdnsd's plugin API offers the ability to write plugins that can do
either (or both) of two roles:
Dynamically generate virtual "A", "AAAA", and "CNAME" records according
to whatever logic the plugin author wishes. The plugin can make use of
gdnsd's monitoring services for being failover-aware, and the actual
zonefile records that trigger these lookups are "DYNA" for addresses
and "DYNC" for CNAMEs.
Provide custom protocols and implementations for the back-end of the
monitoring code for use by any plugin. In this case you mostly just
implement the protocl check code against a standard libev event loop
and use a helper function to report the results of each status check,
and the core takes care of the rest.
All callbacks can be implemented by all plugins; it is possible to
create a combined plugin that performs both roles. There is no clear
distinction between plugin "types" internally.
USER-LEVEL CONFIGURATION FOR DYNA/DYNC
If you haven't read the documentation for the overall configuration
file (gdnsd.config) and the zonefiles (gdnsd.zonefile), you might want
to read those before continuing.
From a user's perspective, there are two parts to configuring plugins.
The first is configuring the plugin via the gdnsd config file. The
config file has an optional "plugins" hash. The keys of this hash are
the names of plugins to load, and the values (which must be hashes) are
the configuration data for the plugin itself. e.g., to load two
plugins named "foo" and "bar", the plugins hash might look like this:
plugins => {
foo => {
opts => {
something = "quux\000<-an_embedded_null!",
somethingelse = { Z => z },
},
xyz = [x, y, z]
}
bar => { x => y }
}
Note that a short-form plugin name (e.g. "foo") maps to a shared
library named plugin_foo.so. Plugins will be loaded from the directory
$PREFIX/lib/gdnsd/ by default, but this path can be overridden in the
"options" section of the gdnsd configuration.
The basic syntactic structure of your plugin's config hash follows the
same rules as the gdnsd config as a whole. This is the "vscf" syntax,
which allows the user to specify nested data in the form of hashes,
arrays, and simple values. It's entirely up to the plugin author how
the contents of the hash should be interpreted, and to document the
plugin's config hash for users.
The second part of the configuration is inserting "DYNA" and/or "DYNC"
resource records into zonefiles. "DYNA" RRs use a plugin to
dynamically generate "A" and/or "AAAA" RRs, while "DYNC" RRs use a
plugin to dynamically generate "CNAME" RRs.
www 300 DYNA foo!prod_web
www.test 300 DYNA foo!test_web
web 300 DYNC bar!test_web_cname
The initial parts (the left-hand domainname, TTL, and RR-type) follow
the usual zonefile norms, other than the fact that "DYNA" is not a real
resource record type in the DNS protocol. The rdata section (e.g.
"foo!prod_web") contains two parts separated by an "!": A plugin name,
and a resource name.
The meaning of the resource name is entirely up to the plugin.
Typically it will reference a configuration key from the plugin's
configuration hash as a mapping to a specific set of parameters for the
plugin, but other uses of this field are possible.
Plugins may implement DYNA, DYNC, or both. The plugin signals which
RRs it supports by which runtime resolve callbacks it implements.
"plugin_foo_resolve_dynaddr" implies DYNA support, and
"plugin_foo_resolv_dyncname" implies DYNC support.
USER-LEVEL CONFIGURATION FOR MONITORING
DYNA/DYNC plugin code can optionally take advantage of monitoring
services, e.g. to not return "dead" addresses from a pool. Monitoring
is configured as a set of "service_types", each representing a
protocol, protocol-specific parameters, and some generic parameters
related to timing and anti-flap. e.g.:
service_types = {
prod_web = {
plugin = http_status
# plugin-specific parameters
vhost = www.example.com
url_path = /checkme
ok_codes = [ 200, 201 ]
# generic parameters
up_thresh = 24
down_thresh = 16
ok_thresh = 8
interval = 8
timeout = 4
}
}
A service type is meant to be re-used to monitor the same service at
several different addresses.
One of the service type parameters is "plugin", naming a custom
monitoring plugin to load. If this plugin was not listed directly in
the "plugins" hash to give it global-level configuration, it will be
loaded with no configuration at all ("_load_config(NULL)").
"http_status" is the default plugin, which does simplistic HTTP/1.0
requests and checks only the HTTP status code returned by the server.
PLUGIN SOURCE ORGANIZATION
There must be one primary plugin source file which implements the
callback hooks, and this file must include the following before any
other code:
#define GDNSD_PLUGIN_NAME foo
#include <gdnsd/plugin.h>
If you wish to split your implementation over multiple files, you can
access the relevant API interfaces via the other "gdnsd-*.h" headers
directly. However all of the actual callback hooks must be implemented
in the primary source file, and your other source files should not
include "gdnsd/plugin.h".
RUNTIME CALLBACK FLOW
To understand how plugins operate and how to write plugins, it is
necessary to understand the overall flow of gdnsd's execution, and
where in that flow various callbacks are made into the code of the
loaded plugins. If you haven't yet read the main gdnsd daemon
documentation at this point, now would be a good time, as it covers
some basic info about how gdnsd acts as its own initscript. All
callbacks have the name of the plugin in the function name, and we will
use the example name "foo" for documentation purposes. A brief summary
of all of the API interfaces and semantics follows in a later section,
but it would be good to read through this lengthy prose explanation at
least once.
CONFIGURATION
Anytime the gdnsd binary is executed (assuming there is no immediate
error in parsing the commandline arguments), if (and only if) the
action is "checkconf", or one of the startup actions ("start",
"restart", "condrestart"), it will load the gdnsd configuration file.
Other actions (such as "stop" or "status") do not load the daemon
config file, and do not load plugins or invoke their callbacks.
As soon as the configuration file as a whole has been validated and
loaded, gdnsd goes about setting various internal parameters from this
data. When it encounters the "plugins" hash, it will load and
configure the named plugins. Immediately after loading each plugin, it
will execute the "plugin_foo_load_config()" callback, providing the
plugin code with its vscf configuration hash. At this time the plugin
should walk (and validate) the provided configuration data and set up
its own internal parameters based on this data. In the case of many
simple daemon actions (e.g. "stop"), there will be no further plugin
callbacks after this point, and execution will cease shortly. Because
of this, any expensive configuration steps should be avoided in the
load_config callback. Your goal in load_config is to validate your
configuration data and store it somewhere, nothing more.
You may also return a "mon_list_t*" from load_config (or NULL if not
applicable). This defines the resources your plugin wants the core
daemon to monitor via its internal HTTP state checker, so that you can
implement simple failover policies easily.
Next, "service_types" are processed from the config. These may
autoload additional plugins that were not specified in the "plugins"
hash. They will also receive a "plugin_foo_load_config(NULL)" call if
autoloaded.
For each service type that uses a given plugin, the plugin will receive
a "plugin_foo_add_svctype()" callback. Use this to set up local data
structures for each service type you've been assigned.
Next, all of the "mon_list_t*"'s that were returned by all
"plugin_foo_load_config()" calls will be processed, which results in
per-address callbacks to monitoring plugins'
"plugin_foo_add_monitor()". This is when a monitoring plugin sets up
per-address data structures.
The next callback will be "plugin_foo_full_config()". This is an ideal
time for a monitoring plugin to do any global config/setup operations
that need to happen after all "plugin_foo_add_monitor()", or for a
resolver plugin to initialize per-iothread data. The sole argument
provided to this callback is num_threads, which is the total count of
I/O threads that will exist at runtime, in case you need it in order to
allocate per-thread data. They are numbered from zero to num_threads -
1. The thread number of the calling thread will be passed to to other
relevant callbacks later, when they are executed in I/O thread context.
After full_config, the daemon loads and parses all zonefiles,
constructing the internal runtime DNS database. During the zonefile
loading phase, when it encounters "DYNA" RRs in zonefiles, they will
trigger the plugin callback "plugin_foo_map_resource_dyna" once for
every "DYNA" RR. The same occurs with all "DYNC" RRs and
"plugin_foo_map_resource_dync". In the "DYNA" case, you get the
resource name and are expected to return an integer resource number.
In the "DYNC" case, you get both the resource name and an origin
argument indicating the current $ORIGIN in effect for the RR, and again
are expected to return an integer resource number which is greater than
or equal to zero.
The meaning and mapping of these resource numbers is entirely up to the
plugin. Any time the given RR is resolved at runtime, the resource
number you returned here will be passed back to your code for dynamic
resolution.
If your DYNC plugin supports variable origins (e.g. the same resource
name can be re-used in multiple zonefiles, and prepends some standard
domainname fragment to origin in effect for the given RR), it is
important that you validate that you can construct a legal domainname
(length limits) from the given origin, resource name, and your own
config at this time. This validation is the only reason the "origin"
parameter is provided for "plugin_foo_map_resource_dync".
Plugins should not return different resource numbers for the same
resname argument, even in the DYNC case where "origin" varies. You
will break things if you do so.
If your map_resource operation fails (e.g. unknown resource name, or
illegal origin-based CNAME construction), log the error and return -1.
Do not fail fatally, as these calls happen at runtime during dynamic
zonefile reloads.
In the case of the action "checkconf", execution stops here. Only the
"start" and "restart" actions continue on to become full-fledged daemon
instances.
RUNTIME
At this point in time, more daemon setup occurs, including the act of
daemonization if applicable. The next callback you will receive is
"plugin_foo_post_daemonize()". After that, the daemon does some
runtime setup such as creating DNS listening sockets, etc.
The next callback you will receive is "plugin_foo_pre_privdrop". This
is your plugin's last chance to take any actions which may require
special operating system privileges (such as opening low-numbered
listening sockets, or opening most files in general). Immediately
after the pre_privdrop callback, the daemon will "chroot()" itself into
the configured chroot directory and drop all privileges (if
applicable).
After dropping privileges, gdnsd will initialize (but not yet enter)
the libev event loop which controls the primary thread of execution at
runtime. This primary thread of execution handles all functionality
other than the actual handling of DNS requests. This includes such
things as reacting to process signals, reporting stats data to syslog
and to users via HTTP, and doing all monitoring-plugin actions to
monitor address resources. Two monitoring plugin callbacks happen at
this stage:
The first is "plugin_foo_init_monitors()". You will be passed the
event loop, and you are expected to set up events that will do a single
monitoring check on all monitored resources and then clear themselves
and not repeat. When all plugins have done their init_monitors(), the
loop will be run, and it is expected to terminate after a few seconds
when all monitoring states have been initialized with real-world data.
The next is "plugin_foo_start_monitors()". Again you are passed the
same libev loop, and you add all of your monitored resource callbacks,
but this time it's permanent: they're expected to repeat their
monitoring checks endlessly the next time the loop is invoked.
When your libev monitoring callbacks have determined a success or
failure for a monitored resource, they're expected to call the helper
function "gdnsd_mon_state_updater()" from gdnsd/mon.h to send the state
info upstream for anti-flap calculations and re-destribution to plugins
which are monitoring the given resource.
If your plugin (of any type) has asynchronous maintenance/management
tasks that can be implemented as libev watchers (sockets, timeouts,
etc), you may register libev events into the main loop at this time,
via the optional callback "plugin_foo_pre_run". The callback will be
provided with a pointer to the libev loop. You should not invoke the
loop, or alter any loop-global settings. The loop will already have
several watchers defined in it when your callback is executed which you
should not touch.
After pre_run, gdnsd will spawn the runtime DNS I/O threads. For each
such thread, the callback "plugin_foo_iothread_init" will be called
from within each I/O thread with the global thread number as the only
argument (0 through num_threads-1, where num_threads was provided to
you back at full_config). This would be the ideal time to malloc()
writable per-thread data structures from within the threads themselves,
so that a thread-aware malloc can avoid false sharing.
At this point, gdnsd is ready to begin serving DNS queries. After all
I/O threads have finished initialization (and thus moved on to already
serving requests), the primary thread will enter the libev loop
mentioned above and remain under its control until daemon exit time.
During this time the only direct callbacks your plugin will receive are
"plugin_foo_resolve_dynaddr" and/or "plugin_foo_resolve_dyncname".
They will only be called from I/O thread context. If you registered
any libev watchers during pre_run, you will also receive relevant
callbacks there in the main thread's execution context.
As a general style rule, the runtime resolver callbacks are not allowed
to block or fail. They are expected to respond immediately with valid
response data. It is your job as the plugin author to ensure this is
the case. That means pre-allocating memory, pre-loading data, and/or
pre-calculating anything expensive during earlier callbacks. Worst
case, you can return meaningless data, e.g. 0.0.0.0 for "DYNA" or some
hostname like "plugin.is.broken." for "DYNC", but ideally all possible
error conditions have been checked out beforehand.
"resolve_dynaddr" is supplied with a resource number, a thread number,
a result structure your code can use to supply address information to
the client, and a "client_info_t" structure giving network information
about the querying client.
The "client_info_t" structure contains the querying DNS cache's address
as well as optional edns-client-subnet address+mask information. If
the mask is zero, there was no (useful) edns-client-subnet information,
and the plugin must fall back to using the cache's address. When edns-
client-subnet information is present, the edns-client-subnet output
"scope" mask must be set in the result structure (to zero if the
information went unused, or to a specific scope as defined in the edns-
client-subnet draft (could be shorter or longer than the client's
specified mask)).
There is no distinction between A and AAAA requests (for that matter,
your plugin could be invoked to provide Additional-section addresses
for other requested types like MX or SRV). You must answer with all
applicable IPv4 and IPv6 addresses on every call. Generally speaking,
gdnsd treats A and AAAA much like a single RR-set. Both are always
included in the additional section when appropriate. In response to a
direct query for A or AAAA, the daemon returns the queried address RR
type in the answer section and the other in the additional section.
"resolve_dyncname" is similar, but also receives an origin argument in
"dname" format, and uses a different results structure. The origin
argument is always fully qualified, and can be used to construct a
complete domainname from a user configuration which specifies un-
terminated short names. Again, a pre-allocated results structure is
supplied for your code to fill out.
In both resolve callbacks' result structures, TTLs are pre-set from the
effective TTL of the triggering record in the zonefile, but can be
modified by the plugin (for example, to shorten the TTL during failure
or near-failure events for a plugin that uses monitoring).
"resolve_dynaddr" has a boolean return value. If your plugin makes use
of some sort of monitoring, and you detected what your plugin would
call "total failure", (or at least, failure to some threshold limit
that you consider very bad), you should return "false". If there's no
monitoring involved, or the monitored status was reasonably ok, return
"true". The idea here is a higher-level nested plugin will use this
result to consider your entire resource "dead" for possibly failing
over to an alternate resource that it knows about. You should still
return a valid address set (probably the whole set would be the best
bet in this scenario, for example).
When a signal is sent to stop the daemon, the primary thread's libev
loop will return and no further watcher callbacks (set up via pre_run()
or start_monitors()) will be invoked. The main daemon will syslog()
some final stats output and invoke "exit()" to terminate the process.
This in turn unwinds the stack of "atexit()" handlers. First will be a
handler which cancels and joins all of the outstanding I/O threads,
then comes another which invokes each plugin's "plugin_foo_exit()" from
the main thread's context. You can log any stats output you wish here,
and/or destruct any resources you wish (no worry about races from io
thread access, they're all dead now).
The "map_resource_dyna" amd "map_resource_dync" callbacks may also be
called at any time during normal runtime as a result of zonefiles being
dynamically reloaded. These should be readonly operations so there
shouldn't be any locking concerns. It's important that these calls
never fail fatally. Simply log an error and return -1.
THREADING
gdnsd uses POSIX threads. Only the runtime resolve callbacks (
"plugin_foo_resolve_dynaddr" and "plugin_foo_resolve_dyncname") need to
concern themselves with thread safety. They can and will be called
from multiple POSIX threads simultaneously for runtime requests.
The simplest (but least-performant) way to ensure thread-safety would
be to wrap the contents of these functions in a pthread mutex.
However, for most imaginable cases, it should be trivial to structure
your data and code such that these functions can be both lock-free and
thread-safe.
CORE API DETAILS
These are the functions exported by the core gdnsd code, which are
available for your plugin to call at runtime. They're implemented in a
library named "libgdnsd", which the gdnsd daemon has already loaded
before loading your plugin. You don't need to (and shouldn't)
explicitly link against libgdnsd. The interfaces are defined in a set
of header files grouped by functionality. Note that in your primary
plugin source file which includes gdnsd/plugin.h, all of these header
files have already been included for you indirectly.
For now, the documentation of these interfaces exists solely in the
header files themselves. I'm still trying to sort out how to document
them correctly, probably doxygen.
gdnsd/compiler.h
gdnsd/plugapi.h
gdnsd/vscf.h
gdnsd/net.h
gdnsd/misc.h
gdnsd/log.h
gdnsd/mon.h
gdnsd/dname.h
GENERAL PLUGIN CODING CONVENTIONS, ETC
All syslog/stderr -type output should be handled via the thread-safe
"log_*()" and "logf_*()" calls provided by gdnsd. Do not attempt to
use stderr (or stdout/stdin) or syslog directly. To throw a fatal
error and abort daemon execution, use "log_fatal()", which does not
return.
Build your plugin with "-DNDEBUG" unless you're actually debugging
development code, and make liberal use of "assert()" and "log_debug()"
where applicable.
You do not declare function prototypes for the callback functions
(plugin_foo_*). The prototypes are declared for you when you include
the gdnsd/plugin.h header. You need merely define the functions
themselves.
There is an internal API version number documented at the top of this
document and set in "gdnsd/plugapi.h". This number is only incremented
when incompatible changes are made to the plugin API interface or
semantics which require recompiling plugins and/or updating their code.
When gdnsd is compiled this version number is hardcoded into the daemon
binary. When plugins are compiled the API version they were built
against is also hardcoded into the plugin object automatically. When
gdnsd loads a plugin object, it checks for an exact match of plugin API
version. If the number does not match, a fatal error will be thrown
telling the user the plugin needs to be rebuilt against the gdnsd
version in use.
The current API version number is available to your code as the macro
"GDNSD_PLUGIN_API_VERSION". If necessary, you can test this value via
"#if" macro logic to use alternate code for different API versions (or
simply to error out if the API version is too old for your plugin
code).
API CHANGELOG
Prior to API version 3, there wasn't any good API documentation and no
known 3rd-party plugins.
Version 4
The API function gdnsd_mon_add() was removed completely.
The prototype for plugin_foo_load_config() changed: the return value
(previously void) is now "mon_list_t*". If you were previously using
gdnsd_mon_add() during plugin_foo_load_config(), you now return that
data via the return value instead. If you were not using
gdnsd_mon_add(), you can simply update the return value type and return
NULL from this callback now.
Also, while not technically an API change, the configuration file
format as a whole underwent some changes. Hash keys and values are now
separated by "=>" or "=" (rather than ":" or "="), and ":" is now
allowed in literal, unquoted keys and values.
Verion 5
"plugin_foo_map_resource" was replaced with
"plugin_foo_map_resource_dyna".
Two new callbacks added for "DYNC" support:
"plugin_foo_map_resource_dync" and "plugin_foo_resolve_dyncname".
All plugin callback hooks are now optional. Failure to implement
map_resource callbacks maps all resources to the number zero, failure
to implement load_config just means any plugin config hash information
is ignored, etc. Obviously, a plugin that defines no callbacks would
be useless. Similarly, if you don't implement at least one of
"plugin_foo_resolve_dynaddr" or "plugin_foo_resolve_dyncname" your
plugin will be fairly useless as well.
Version 9
Note: Versions 6-8 existed in the long-running 1.5.x dev series, but
never a release build, so the V9 info here summarizes all changes from
V5 -> V9.
"plugin_foo_resolve_dyna" and "plugin_foo_resolve_dyncname" had their
"const anysin_t* client" arguments replaced with "const client_info_t*
cinfo". If you don't wish to deal immediately with the new
complexities presented by the draft edns-client-subnet information in
this new structure, you can preserve existing behavior by (a) updating
your functions' arguments to the new prototype, and (b) adding the
following near the top: "const anysin_t* client = &cinfo->dns_client;".
Additionally, *if* your plugin makes dynamic decisions based on
"cinfo->dns_client", it *needs* to set "result->edns_scope_mask =
cinfo->edns_client_mask;" for correct behavior. Plugins whose
responses are static with regard to "cinfo" should not do so, as the
result scope mask defaults to the appropriate value of 0.
Previously an "extern bool dmn_debug" was available to query daemon
debug status, this has been replaced with a function call "bool
dmn_get_debug(void);". This means any plugin with "log_debug()"
statements loses binary compatibility and needs to be rebuilt, but
doesn't require a source change. Other new dmn accessors were also
added for previously unavailable information regarding
privdrop/chroot/daemonization status as well.
Added four new plugin callbacks to support pluggable monitoring:
void plugin_foo_add_svctype(const char* name, const vscf_data_t*
svc_cfg, const unsigned interval, const unsigned timeout)
void plugin_foo_add_monitor(const char* svc_name, mon_smgr_t* smgr)
void plugin_foo_init_monitors(struct ev_loop* mon_loop)
void plugin_foo_start_monitors(struct ev_loop* mon_loop)
The internal structure of the data type "anysin_t" changed. The old
typedef was:
typedef union {
struct sockaddr_in6 sin6;
struct sockaddr_in sin;
struct sockaddr sa;
} anysin_t;
... and the new one is:
typedef struct {
union {
struct sockaddr_in6 sin6;
struct sockaddr_in sin;
struct sockaddr sa;
};
socklen_t len;
} anysin_t;
Direct access to the union members via casting anysin_t to one of the
sockaddr structs should still technically work, although it would be
more proper to use the correct member. If you are creating new
anysin_t's in your plugin code, you need to set the "len" member
correctly. Generally, this would be the len returned by the library
call that created the sockaddr struct, e.g. ai_addrlen in the case of
"getaddrinfo()", and in any case should correspond to the "sizeof()"
one of the unioned sockaddr structs.
If passing a blank anysin_t to be filled out by system library code
(e.g. as an argument to "accept()"), the appropriate socklen value is
defined as "ANYSIN_MAXLEN", which is the length of the largest of the
unioned sockaddr structs. So set anysin_t.len to that, and pass
&anysin_t.len as the "socklen_t*" argument the library call will use to
fill in the correct value.
Also added new API helper function "gdnsd_anysin_getaddrinfo()" which
wraps the common process of converting a numeric string address +
optional numeric string port into an anysin_t using "getaddrinfo()",
and sets the len field correctly. "plugin_foo_resolve_dynaddr()" now
needs a return value of type "bool", was previously "void". Return
value should indicate whether other code can consider this resource
effectively-dead for failover purposes. You should still return some
valid result-set (common practice would be to return all if
everything's down, as if nothing in the resource were down).
Version 11
Note: Version 10 existed in the long-running 1.7.x dev series, but
never a release build, so the V11 info here summarizes all changes from
V9 -> V11.
All header files renamed from the form "gdnsd-X.h" to "gdnsd/X.h".
satom/mon stuff: The header file gdnsd/satom.h is no longer published,
and plugin code which directly includes it or uses things only defined
there (e.g. satom_t and various satom_*() accessors) needs to stop
doing so. It was probably never a good idea to expose this or use it
in the first place. The replacement is intentionally undocumented for
the plugin API.
s/monio/mon/ in general on any types/symbols/macros referenced from the
API include files, to clean up some package-internal naming conflict
stuff.
gdnsd_mon_min_state() renamed gdnsd_mon_get_min_state(), and is now the
only documented official interface for resolve plugins to fetch
monitored states.
gdnsd_mon_state_updater() is now the required interface for monitoring
plugins to send updates to the core, whereas it was merely recommended
in the past.
The embedded copy of libev was removed in favor of using an external
installation as a dependency. This means you'll need to have your own
copy of libev's development headers in place to build 3rd-party
plugins, and they should match the libev version gdnsd was built with.
A few other minor changes require just a recompile, even if none of the
above applies.
Version 12
This corresponds with the release of 1.10.0
Only the vscf config-file API changed in this version, which only
really affects plugins that were loading external vscf configuration
files on their own (as opposed to just receiving data from the main
config file's plugins stanza). There aren't any 3rd party plugins
doing this that I'm aware of, but it does technically warrant an API
compatibility bump.
The first of the vscf API changes was the removal of the fd and stream
input functions vscf_scan_fd() and vscf_scan_stream(), leaving only the
vscf_scan_filename() variant.
The other change is that the data item returned by vscf_scan_filename()
can now be a hash or an array, whereas before the syntax of vscf's
config language only permitted it to be a hash. Code which expects a
hash must now explicitly check that the result was not an array.
SEE ALSO
The source for the included addr/cname-resolution plugins "null",
"reflect", "static", "simplefo", "multifo", "weighted", "metafo", and
"geoip". The source for the included monitoring plugins "http_status",
"tcp_connect", and "extmon".
gdnsd(8), gdnsd.config(5), gdnsd.zonefile(5)
The gdnsd manual.
COPYRIGHT AND LICENSE
Copyright (c) 2012 Brandon L Black <blblack@gmail.com>
This file is part of gdnsd.
gdnsd is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation, either version 3 of the License, or (at your
option) any later version.
gdnsd is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License along
with gdnsd. If not, see <http://www.gnu.org/licenses/>.
gdnsd 1.11.0 2013-12-06 gdnsd-plugin-api(3)
