Re: DB extensions

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Sat, 31 Oct 2009 17:53:27 +1100

On Saturday 31 October 2009 10:39:17 Murray S. Kucherawy wrote:
> There are two important DB-related things that need to be addressed after
> the overhaul I did this week. Looking for feedback on one of them.
>
> The first one is the fact that the new DB code does not yet cover the
> internal/external host lists, since they're not stored as simple linked
> lists; they are in fact data structures that contain either a hostname or
> an IP address and mask (as 32-bit quantities). I need to come up with a
> way to add those as special database types which also be queried,
> preferably without any changes to the new interface. So that's still to
> be done before 1.2.0 is ready for real testing.

sounds like two keycolumns in the DSN syntax for IP,mask is maybe the easy
way. This would make the query at least simple. Though overkill for
internal/external host lists other policy items it could potentially use a
good CIDR lookup mechanism.

> The one I'm interested in feedback on: Right now it's possible to have
> certain values like the list of headers to sign or the list of headers to
> omit be taken from a database. These are sent to the library only when
> it's set up, i.e. when the program starts. That might mean someone thinks
> it's possible to set up the list of headers to sign/omit to reference a
> database, and think the program will adapt to changes to that database,
> when that's currently the case. I think this should just be documented;
> in reality, how often are these likely to be changed in-flight or in an
> automated way? On the other hand, if they really do need to be dynamic,
> then a mechanism for either signaling a reload request or a periodic check
> for changes will need to be done. Anyone feel strongly in either
> direction?

i'm thinking truely dynamic is definite overkill and if desired could be
handled in a policy API way perhaps.

I've got small inclinations towards signaling/periodic checks.

note for doco - requires openDBX 1.3.7 or later though 1.3.11 recommended if
your going to compile it yourself (to avoid stupid compile error in opendbx)
Received on Sat Oct 31 2009 - 06:53:53 PST