[BlueOnyx:11625] Re: BX BIND files

[Michael Stauber]

Hi George,

> I've just spent several days trying to fathom the files and locations for
> BIND under the BX/RedHat 'chroot jail' scheme.
> 
> Where some files are seems to vary according to the RH/Fedora
> distribution... some want to put the usual database entries for BIND
> ( /etc/named/<db.hosts> ) into the /var/named/ directory instead.
> 
> So under the chroot jail scheme, those directories become instead:
> 
>         /var/named/chroot/etc/named/<db.hosts>
> or                        ***
> 
>         /var/named/chroot/var/named/<db.hosts>
>                           ***

Yeah, I can see how that happened. The jail that BlueOnyx creates is in
the same style and layout that Cobalt introduced for jailing Bind back
in the days of old. Back then RedHat didn't have provisions for that.
Eventually BlueQuartz used the same scheme and we also kept it the same.
Eventually when RedHat came up with their own jail for Bind, it ended up
being something slightly different.

> I'd really love to see a list what BX *really* expects in terms of
> 
>         - all BIND nameserver related files
>         - files that the BX CCE wants/writes/changes
>         - owner and group for the files
>         - full paths/directories for all the files
>         - permissions for directories and files
>         - anything else that might bite back

These two scripts handle the setup of the jail:

The first one runs only once during initial setup and creates the
symlinks for the jail:

/usr/sausalito/scripts/initNamed.sh

The second one runs every time CCEd is restarted:

/usr/sausalito/constructor/base/dns/fixDNS.pl

As for when does CCE update the Bind config files? Pretty much every
time you save something in the DNS related GUI pages. Owner of the
files? UID/GID = named

One of the major shortcomings of the DNS management in the BlueOnyx GUI
is of course the storage of DNS records in the CODB backend of CCE. We
don't just have the generic DNS server settings stored in CODB, but also
one CODB object for every single DNS record. You create an A-Record? A
CODB object gets created. You add an MX record? Another CODB object gets
created. So for a typical domain you already have half a dozen CODB
objects just for covering the DNS of that domain.

Now most people usually like to centralize their DNS servers. Even if
they run a dozen or more BlueOnyx servers (VPS's or real), the DNS is
hosted on centrally on two boxes dedicated to that task. Which then
might have thousands of DNS records. Which then gets really squeaky, as
CODB might run into design limits and performance issues. Trying to
import +1500 zone files with dnsImport.pl shows these limitations
easily. It'll take ages to complete and near the end the import will
slow down to a crawl.

In the longer run I want to get away from the fact that the DNS
management uses CODB so liberally and extensively. Either by using Json
encoding for storing an entire zone file into a single CODB object, or
by offloading the DNS records from CODB entirely. However, this requires
a much stricter input verification and handling. Which is something that
CODB currently helps us with. Because when we say "this database entry
is for A-Records", then saving anything else but the expected data will
yield an error message. But in the longer run it may be better if the
GUI just parses the existing zone files directly, presents the data and
lets you edit them directly - without the need to store that data
permanently in CODB. Of course an approach like that would require a lot
more "logic" in the GUI pages, but could be done. It just doesn't have a
high priority at the moment, but it's on the list of things I eventually
want to do.

-- 
With best regards

Michael Stauber