This project is no longer maintained, as you most probably have understood.
If anyone are interested into continue this project, please get in touch and we'll make sure this can happen.
Oops! I thought I was on Sourceforge for some stupid
reason. These comments were meant for the package
author and not the general Freshmeat crowd. Oh well,
now you know what I think of it. The source looks
great (I haven't tested it in production yet), but it could
do with some changes and enhancements. Keep in
mind this is a 0.0.1 version release...
I'm just installing Bind 9 now, so I haven't used this
package yet, but here are some suggestions right off
1) Make the 'only connected when needed' an option.
For heavily used DNS servers this is going to be a
killer CPU hog and slow things down hugely. For
example, I'm using a DNS server on my network
management boxes and they constantly perform
lookups for all of the devices they monitor. Every time
a port goes down, every time an event gets generated,
a lookup is performed.
2) Make the modified reverse lookup changes optional.
111.222.233 is not an IP address, it's label, and it's full
name is 233.222.111.in-addr.arpa. 18.104.22.168
may be an IP address, but it should be left in the
traditional syntax to prevent confusion. There are
other types of data in the reverse lookup domains than
just IP addresses. There are NS records, of course,
and some people use subnet reverse lookups to find
the name of a subnet instead of an IP address. For
example, some network management packages will do
a reverse lookup on a subnet, say
223.222.111.in-addr.arpa for the subnet
111.222.223/24 to find out the name of the subnet that
it places on network maps. While this only works for
8-bit boundary subnets, it is still quite useful. The
changes make sense for those who only require IP
addresses themselves in the reverse lookup domains,
but it makes it unwieldy for those with more diverse
3) Change the names of all of the routines to epgsqldb
insted of using the names pgsqldb. pgsqldb is already
used by the "official" ISC Bind package and they are
likely to modify and expand these routines in future
versions. Your package is called epgsqldb, so why
create a name scope conflict by taking over the
function names of offical SDB? I'd actually like to load
both of them in one named binary at the same time in
order to perform some performance comparisons.
4) The reverse update triggers are a great idea! I
would expand this so that when a reverse entry is
edited it finds the forward entry and updates the IP
address automatically [This should be an option, of
course. There are two main practices for reverse
lookups. A practice used by some is to create different
PTR records for each interface on a host and have
these point to different names. This is most
commonly done so that your traceroutes show the
interface that the packet was received on. IMO this is
an incorrect use of the DNS, and I follow the other
practice. The alternative, which follows all of the
RFC's that state hosts have DNS names and
interfaces do not, is to point all PTR records to the
same name. If you follow the first practice you
may be safe in looking up the
interface name and updating its record -- if there is
one (some people insist on having interface IP's
resolve to different names, but don't have A records for
these IP's!). If you follow the second practice you will
update your A record to point to the last interface IP
that ws updated. A quick check would be to only
update the A record that the PTR record points to if
the A record had the old IP address that is being
changed in the PTR record!]. Another potentially
useful trigger would be to automatically update the SOA
record to increase the serial number whenever a
change is made to a domain. There are other more
esoteric checks that can be made to enforce database
entegrity, such as not allowing MX records to be
entered unless there is an IP address (A record) for
the destination. Lastly, I would attempt to program all
of the triggers in an embedded language if at all
possible, with PL/SQL being the prime candidate. It
should be available on all PostgreSQL installations, so
it makes the logical choice. I'm not sure if it has all of
the programming constructs that would be necessary,
but if it does there is no reason not to use it rather
than having a bunch of dynamically loaded object files
compiled from C.
All in all, I think the enhanced pgsql SDB is great, and
if I have time I'll try to contribute as much as I can.
Unfortunately, my time is rather tight at the moment (I
wonder how I made the time to type all this up!).
Thanks for the effort and good luck to any future
enhancements you make!
An open, cross-platform journaling program.
A scientific plotting package.